QAスタッフは、表示できないキャッシュロジックをどのようにテストできますか？

Webアプリケーションにキャッシングレイヤーを実装しましたが、キャッシングはユーザーに対して透過的であるため、QAがどのようにテストするのか疑問に思っています。

私が持っているアイデアの1つは、キャッシュに入力するコードを呼び出すメソッドにログを記録し、オブジェクトがキャッシュからプルされたときと、データベースからの再作成が必要なときを記録し、テスターがログを表示して、たとえば、特定のオブジェクトは、すべてのページビューではなく、10分ごとにデータベースからリロードされます。

しかし、この状況に対してより良い実践を提案できる人はいますか？

1つの質問は、キャッシュ自体が本当にQAによってテストされる必要がある要件であるかどうかです。キャッシュによりパフォーマンスが向上するため、パフォーマンスの違いをテストして、要件を満たしていることを確認できます。

ただし、キャッシュを担当する人はだれでも、キャッシュに関するテストを行うことをお勧めします。パフォーマンスカウンターを使用しました。キャッシュシステムがこれらを利用する場合、簡単です。キャッシュ自体からカウントを取得する方法がある場合、それは別のオプションです。

あなたのアプローチを使用することもいいです。これらのいずれかが結果をチェックする自動テストにラップされている場合、誰もログを調べて回答を見つける必要はありません。

システムのパフォーマンスが十分ではなかったため、キャッシュを実装しました（私は推測します）。それはユーザーに関連するものです。QAが確認できることは次のとおりです。

• キャッシュが導入された後、システムがまだ正しいこと。これは、キャッシュをだまして失効したデータを提供しようとする必要があることを意味します。
• システムがパフォーマンスのしきい値を満たすようになったことは、パフォーマンスを改善することを決定したときに満たされていなかったことです。古い測定値と新しい測定値を比較できます。

ユーザー（ひいてはQA）は、問題の解決方法を気にしないことを忘れないでください。彼らは、問題が解決したことだけを気にし、新しい問題を作成しませんでした。これは、キャッシュの実装、文字列解析の改善、ハードウェアのアップグレード、または魔法の妖精の粉塵をサーバーに振りかけた場合に当てはまります。

重要なビジネスロジックやシステム状態をブラックボックスの奥深くに埋めると、正しいシステム動作の検証が困難になります。システム全体よりも、システム内の単一のコンポーネントの動作を徹底的にテストする方が簡単です。このようなことを何らかのメカニズムを通じて明示的に公開することで、ユニット/回帰/統合/ QAを何らかの意味のある方法でテストできるようになりました。

キャッシュを使用する1つのオプションは、キャッシュの詳細（コンテンツ、状態など）を提供する特別なページを公開することです。これは、開発および潜在的に本番環境でのデバッグに役立ちます。QAはこのページを使用して、キャッシュの予想される動作に関する詳細が提供されている場合、キャッシュのテストケースを作成することもできます。パフォーマンスカウンターやログファイルを使用してキャッシュの動作を明示的に文書化することも、あまり見られないが実行可能なアプローチです。

このアプローチは、エンドツーエンドのパフォーマンステストに代わるものではないことに注意してください。これは、キャッシュ自体が正しく動作することを保証するメカニズムです。キャッシュがパフォーマンスに意図した影響を与えるかどうかを判断するには、パフォーマンステストを使用する必要があります。

また、システムのコンポーネントを、キャッシュの導入など、同じインターフェースを実装する新しいコンポーネントと交換することは、不安定で一見複雑な変更になる可能性があることに注意してください。キャッシュの例では、以前はステートレスであった状態を導入しているため、発見や再現が困難なバグを作成する可能性があります。このような変更には、予想されるシステムの動作を検証するための完全な回帰テストを常に伴う必要があります。

Andyの答えに示されているように、パフォーマンスをテストします。

多くの組織でキャッシング（およびパフォーマンス）を実装する際の最大の障害は、実際にさまざまな実世界の負荷およびパフォーマンステストのために優れたパフォーマンステストとテストを実行できる環境を持っていることです。

これを実現するには、できる限り厳密にコストを考慮して、本番環境をミラーリングするパフォーマンステスト環境をセットアップする必要があります。これはおそらく、迅速なアプリケーション開発を可能にするために小さく、より自己完結型である必要がある現在の開発環境ではないでしょう。また、開発環境ではキャッシュの使用量が少なくなる傾向があるため、パフォーマンステストのために実稼働環境を適切に表すことはできません。

パフォーマンステスト環境では、アプリを実稼働「モード」で実行する必要があります。本番環境では複数のサーバーを使用する必要があり、データベース接続プールとキャッシュは本番環境などに設定する必要があります。

また、負荷テストに役立つツールを検討する必要があります。
jmeterは非常に人気がありますが、使用するのは非常に非友好的で原始的です。
私が使用した別のルートはcurl、Rubyスクリプトでurlを使用することです。

明確にする

• ベースラインパフォーマンステストは、1つのリクエストが行う時間をテストするためのものです。
• 負荷テストはパフォーマンステストに似ていますが、システムが他の要求からも負荷を受けている場合の応答を調べます。

また、次のリンクが役立つ場合があります。

• キャッシュを多用する単体テスト方法のベストプラクティス
• キャッシュのロードテスト方法
• サイトが負荷下でどのように機能するかをテストする方法はありますか
• http://www.procata.com/cachetest/

テスターに​​サーバーをリブートさせ、入力したデータがまだ存在することを確認してください。私は、何ヶ月もテストを行ったシステムを見ましたが、それが完了すると失敗しました！

テストが最も難しいのは、データが更新されても、キャッシュから古い結果が返されることは決してないということです。

これは、キャッシュ内のデータを常に使用して、ユーザーが変更を行った後に表示される確認ページにデータを入力することにより、部分的に役立ちます。たとえば、データベースの更新に使用したオブジェクトは使用しませんが、キャッシュからデータを要求し、次にデータをデータベースから要求します。少し遅くなりますが、バグがより早く表示される可能性が高くなります。

これは実際には非常に簡単な答えがあり、キャッシングのレベルに関連しています。キャッシングが正しいときに観察するのは、リクエストのターゲットにリクエストがないことです。そのため、「期待される結果」というハックされたQAフレーズに帰着します。

Web層でキャッシュを実装する場合、キャッシュの対象となるアイテムは、テストされた各ユーザーセッション（クライアントキャッシュを実装する場合）ごとに1回、または複数のユーザー（CDNスタイルキャッシュを実装する場合）ごとに1回しか表示されないと予想します。一般的な結果を得るためにデータ層にキャッシュを実装する場合、データ層のプロファイルログにクエリがないことに加えて、キャッシュ層のキャッシュヒット率が高いことが予想されます。

等...

おそらく、ユニットテストを使用して、コード（おそらくコードを作成したプログラマー）によってテストされるものがあります。キャッシングコードの正確性をテストすることは、その1つです。（あなたがこの質問をする方法から、私はあなたのQAの人々がアプリケーションを「ブラックボックス」として扱い、その外部インターフェースを通してそれをテストすると推測します。）

QAは主にブラックボックステストを行うため、キャッシングロジックは開発者がユニットテストする必要があります。

QAはパフォーマンスの側面または実装した修正のみに関心があるため、QAにキャッシュを有効/無効にするメカニズムまたはパフォーマンスを改善するために使用したメカニズムを提供し、パフォーマンスの違いを検証できます。もちろん、QAは古いリリースをパフォーマンスが改善されたリリースと照合することもできます。

キャッシングソリューションをテストしていたときに、基本的にパフォーマンスをテストしたものを実装しました。XML結果のキャッシュソリューションを実行しました。キャッシュ後、応答に非常に短い時間がかかります。また、ログエントリを確認して、サーバーログで確認しました。