QAスタッフは、見えないキャッシングロジックをどのようにテストできますか？
私はWebアプリケーションにキャッシングレイヤーを実装したばかりですが、キャッシングはユーザーに対して透過的であるため、QAがそれをどのようにテストすることになっているのだろうと思います。
私が持っているアイデアの1つは、キャッシュにデータを入力するコードを呼び出すメソッドにログを記録し、オブジェクトがキャッシュからプルされたときと、データベースからの再作成が必要なときを記録し、テスターがログを表示して、たとえば、特定のオブジェクトは、ページビューごとではなく、10分ごとにdbからリロードされます。
しかし、誰もがこの状況のためのいくつかのより良い実践を提案できますか？
1つの質問は、キャッシュ自体が本当にQAでテストする必要がある要件であるかどうかです。キャッシングによりパフォーマンスが向上するため、パフォーマンスの違いをテストして、要件を満たしていることを確認できます。
しかし、キャッシングを担当する人なら誰でも、キャッシングに関するテストを行うことをお勧めします。パフォーマンスカウンターを使用しました。キャッシュシステムがこれらを利用する場合、それらは簡単です。キャッシュ自体からカウントを取得する方法がある場合、それは別のオプションです。
あなたのアプローチを使用することもいいです。これらのいずれかが結果をチェックする自動テストにラップされている場合、答えを見つけるためにログを調べる必要はありません。
システムが十分に機能していないため、キャッシュを実装しました（私はそう思います）。 Thatは、ユーザーに関連するものです。 QAで確認できる項目は次のとおりです。
- キャッシュが導入された後のシステムはまだ正しいです。つまり、キャッシュをだまして古いデータを提供しようとする必要があります。これはQAが確認できるものであり、他に何も壊れていないことを確認します。
- システムがパフォーマンスを改善することを決定したときに満たされなかったパフォーマンスしきい値を満たしていること。彼らは古い測定値を比較し、新しいものと比較することができます。
ユーザー（および、ひいてはQA）は、問題を解決した方法を気にしません。彼らは問題が解決されたであることを気にし、新しい問題を作成しませんでした。これは、キャッシュを実装したり、文字列解析を改善したり、ハードウェアをアップグレードしたり、サーバーに魔法の妖精の粉をまき散らしたりしても当てはまります。
アンディの答えに示されているように、パフォーマンスをテストします。
多くの組織でキャッシング（およびパフォーマンス）を実装する上での最大の障害は、実際に優れたパフォーマンステストを実行し、さまざまな実世界の負荷およびパフォーマンステストのテストを実行できる環境にあることです。
これを実現するには、performanceテスト環境をセットアップし、可能な限り厳密に、コストを考慮して、本番環境をミラーリングする必要があります。これはおそらく、現在の開発環境ではなく、アプリケーションの迅速な開発を可能にするために、より小さく、より自己完結型である必要があります。また、開発環境ではキャッシュの使用量が少なくなる傾向があるため、パフォーマンステストでは本番環境をうまく表現できません。
パフォーマンステスト環境では、アプリは本番「モード」で実行する必要があります。本番環境の場合は複数のサーバー、データベース接続プールとキャッシングを本番環境用に設定する必要があります。
また、負荷テストに役立つツールを検討する必要があります。
jmeterは非常に人気がありますが、使用するのは非常に不親切で原始的です。
私が使用した別のルートは、Rubyスクリプトを使用してcurl 'sをURL化することです。
明確にするために
- ベースラインパフォーマンステストは、ONEリクエストが行う時間をテストするためのものです。
- 負荷テストはパフォーマンステストに似ていますが、システムが他の要求からも負荷がかかっている場合の応答を調べます。
次のリンクも役立ちます。
重要なビジネスロジックまたはシステム状態をブラックボックスの奥深くに埋め込むと、正しいシステム動作の検証が困難になります。システム全体ではなく、システム内の1つのコンポーネントの動作を徹底的にテストする方が簡単です。私はそのようなものを何らかのメカニズムを通じて明示的に公開することを好むので、それは何らかの意味のある方法でユニット/回帰/統合/ QAテストを行うことができます。
キャッシュのオプションの1つは、キャッシュ（コンテンツ、状態など）に関する詳細を提供する特別なページを公開することです。これは、開発および場合によっては本番環境でのデバッグに役立ちます。キャッシュの予想される動作についての詳細が提供されている場合、QAはこのページを使用してキャッシュのテストケースを作成することもできます。パフォーマンスカウンターやログファイルを使用してキャッシュの動作を明示的に文書化することも、あまり目立たないが実行可能なアプローチです。
このアプローチは、エンドツーエンドのパフォーマンステストの代わりにはなりません。これは、キャッシュ自体が正しく動作することを保証するメカニズムです。パフォーマンステストを使用して、キャッシュがパフォーマンスに意図した影響を及ぼしているかどうかを判断する必要があります。
また、システムのコンポーネントを、キャッシュの導入などの同じインターフェースを実装する新しいコンポーネントと交換すると、不安定になり、一見複雑な変更になる可能性があることに注意してください。キャッシュの例では、以前はステートレスであったものに状態を導入しているため、発見または再現が困難なバグが作成される可能性があります。このような変更には、予期されるシステム動作を検証するための完全な回帰テストを常に伴う必要があります。
テスターにサーバーを再起動させ、入力したデータがまだ残っていることを確認することを忘れないでください。何ヶ月にも及ぶテストが行われたシステムを確認しましたが、テストが失敗しました！
テストするのが最も難しいのは、データが更新されても、キャッシュから返される古い結果がneverあることです。
これは、常にキャッシュ内のデータを使用して、ユーザーが変更を加えた後に表示される確認ページにデータを入力することで、部分的に役立ちます。たとえば、データベースの更新に使用したオブジェクトを使用せずに、キャッシュからデータを要求し、次にデータベースからデータを要求します。少し遅くなりますが、バグが早く表示される可能性が高くなります。
これは実際には非常に簡単な答えがあり、キャッシングのレベルに関連しています。キャッシングが正しい場合に観察されるのは、リクエストのターゲットにリクエストがないことです。つまり、「期待される結果」というハッキングされたQAフレーズに帰着します。
Web層にキャッシュを実装する場合、キャッシュの対象となるアイテムは、テストされたユーザーセッションごとに1回（クライアントキャッシュを実装する場合）または複数のユーザー（CDNスタイルキャッシュを実装する場合）に1回だけ表示されると予想します。一般的な結果を得るためにデータ層にキャッシュを実装している場合、データ層のプロファイルログにクエリが存在しないことに加えて、キャッシュ層のキャッシュヒット率が高くなることが予想されます。
等...
キャッシングロジックは、QAが主にブラックボックステストを行うため、開発者によるユニットテストが必要です。
QAは、パフォーマンスの側面またはこのように実装した修正だけを考慮します。QAに、キャッシュを有効/無効にするメカニズムや、パフォーマンスを向上させるために使用したメカニズムを提供し、パフォーマンスの違いを確認できます。もちろん、QAは、パフォーマンスが改善されたリリースに対して古いリリースを検証することもできます。
いくつかの事柄は、ユニットテストを使用して、おそらくコードを書いたプログラマーによってよりよくテストされます。キャッシュコードの正当性をテストすることは、その1つです。 （あなたがこの質問をする方法から、あなたのQAの人々はアプリケーションを「ブラックボックス」として扱い、その外部インターフェースを通してそれをテストすると思います。）