difference between performance test plan
パフォーマンステスト計画とテスト戦略の違いは何ですか？
これで パフォーマンステストシリーズ 、以前のチュートリアルでは、 機能テストとパフォーマンステスト 詳細に。
=> 完全なパフォーマンステストチュートリアルシリーズについては、ここをクリックしてください
このチュートリアルでは、パフォーマンステスト計画とテスト戦略の違いと、これらのドキュメントの一部として含まれるコンテンツについて学習します。
これら2つのドキュメントの違いを理解しましょう。
学習内容：
パフォーマンステスト戦略
パフォーマンステスト戦略ドキュメントは、テストフェーズでパフォーマンステストを実行する方法に関する情報を提供する高レベルのドキュメントです。ビジネス要件をテストする方法と、製品をエンドクライアントに正常に配信するために必要なアプローチについて説明します。
これには、ビジネスプロセスに関するすべての情報が非常に高いレベルで含まれます。
このドキュメントは、プロジェクトの初期段階、つまり要件分析フェーズ中または要件分析フェーズ後に作成されるため、利用できる情報は限られているため、通常、このドキュメントはパフォーマンステストマネージャーによって以前の経験に基づいて作成されます。
つまり、パフォーマンステスト戦略ドキュメントは、パフォーマンステストの目標を達成するために、プロジェクトの開始時に採用するアプローチで設定した方向性に他なりません。
典型的なパフォーマンステスト戦略ドキュメントには、何をテストするかというパフォーマンステストの全体的な目標が含まれていますか？どの環境が使用されますか？どのツールが使用されますか？どのような種類のテストが実行されますか？入場と退場の基準、利害関係者のどのようなリスクが軽減されますか？さらに、このチュートリアルでさらに進んでいくときに、さらに詳しく見ていきます。
上の図は、パフォーマンステスト戦略ドキュメントがプロジェクトの要件分析フェーズ中またはフェーズ後に作成されることを説明しています。
パフォーマンステスト計画
パフォーマンステスト計画ドキュメントは、プロジェクトの後の段階で、要件と設計ドキュメントがほぼ凍結されたときに作成されます。パフォーマンステスト計画ドキュメントには、要件分析フェーズで説明した戦略またはアプローチを実装するためのスケジュールのすべての詳細が含まれています。
現在、設計ドキュメントはほぼ準備ができており、パフォーマンステスト計画には、テストするシナリオに関するすべての詳細が含まれています。また、パフォーマンステストの実行に使用される環境、テスト実行のサイクル数、リソース、出入り基準などについての詳細もあります。パフォーマンステスト計画は、パフォーマンスマネージャーまたはパフォーマンステストリードによって作成されます。
上の図は、パフォーマンステスト計画が、設計ドキュメントの可用性に基づいて、プロジェクトの設計中または設計フェーズの後に作成されることを明確に説明しています。
パフォーマンステスト戦略ドキュメントの内容
ここで、パフォーマンステスト戦略ドキュメントに何を含める必要があるかを見てみましょう。
＃1）はじめに： その特定のプロジェクトについて、パフォーマンステスト戦略ドキュメントに含まれる内容の概要を説明します。また、このドキュメントを使用するチームについても言及してください。
Java開発者インタビューの質問と回答
＃2）範囲： スコープを定義することは、パフォーマンステストの正確な内容を教えてくれるので非常に重要です。スコープやその他のセクションを定義する際には、非常に具体的にする必要があります。
一般化されたものは絶対に書かないでください。スコープは、プロジェクト全体で正確に何がテストされるかを示します。スコープの一部としてスコープ内とスコープ外があります。スコープ内はパフォーマンステストされるすべての機能を説明し、スコープ外はテストされない機能を説明します。
＃3）テスト アプローチ： ここでは、パフォーマンステストで従うアプローチについて説明する必要があります。たとえば、各スクリプトは1人のユーザーで実行されてベースラインが作成され、このベースラインテストは後の時点でベンチマークの参照として使用されます。テスト実行中の時間。
また、各コンポーネントは、統合する前に個別にテストされます。
＃4）テスト タイプ： ここでは、負荷テスト、ストレステスト、耐久性テスト、ボリュームテストなど、対象となるさまざまなタイプのテストについて説明します。
＃5）テスト 成果物： テスト実行レポート、エグゼクティブサマリーレポートなど、プロジェクトのパフォーマンステストの一部として提供されるすべての成果物について言及します。
＃6）環境： ここでは、環境の詳細について説明する必要があります。環境の詳細は、パフォーマンステストに使用されるオペレーティングシステムを説明するため、非常に重要です。
環境が本番環境のレプリカになる場合、または本番環境からサイズアップまたはサイズダウンされる場合、およびサイズアップとサイズダウンの比率、つまり、本番環境の半分のサイズになるか、本番環境の2倍のサイズになる場合？
また、セットアップされた環境の一部として、またパフォーマンステストの実行中に考慮されるパッチまたはセキュリティアップデートについて明確に言及する必要があります。
＃7）ツール： ここでは、欠陥追跡ツールのように使用されるすべてのツールについて言及する必要があります。 管理ツール 、パフォーマンステスト、および監視ツール。いくつか 例 欠陥追跡のためのツールの JIRA 、Confluenceなどのドキュメントの管理用、パフォーマンステスト用 Jmeter および監視用 Nagios 。
＃8）リソース： パフォーマンステストチームに必要なリソースの詳細は、このセクションに記載されています。 例えば 、パフォーマンスマネージャー、パフォーマンステストリード、パフォーマンステスターなど。
＃9）エントリー ＆ 出口 基準： このセクションでは、開始基準と終了基準について説明します。
例えば、
エントリー基準 –パフォーマンステスト用のビルドを展開する前に、アプリケーションは機能的に安定している必要があります。
終了基準 –すべての主要な欠陥がクローズされ、ほとんどのSLAが満たされます。
＃10）リスクと軽減： パフォーマンステストに影響を与えるリスクは、その軽減計画とともにここにリストする必要があります。これにより、パフォーマンステスト中にリスクが発生する可能性があります。または、少なくともリスクの回避策が事前に計画されます。これは、成果物に影響を与えることなく、パフォーマンステストスケジュールを時間どおりに完了するのに役立ちます。
＃11）略語： 略語に使用されます。 例えば、 PT –パフォーマンステスト。
＃12）ドキュメント履歴： これには、ドキュメントのバージョンが含まれています。
パフォーマンステスト計画文書の内容
パフォーマンステスト計画のドキュメントに含めるべきものをすべて見てみましょう。
＃1）はじめに： これは、パフォーマンステスト戦略のドキュメントに記載されているものとすべて同じです。パフォーマンステスト戦略ではなく、パフォーマンステスト計画についてのみ説明します。
＃2）目的： このパフォーマンステストの目的は何ですか、パフォーマンステストを実行することによって何が達成されるか、つまり、パフォーマンステストを実行することの利点は何であるかをここで明確に説明する必要があります。
＃3）スコープ ：パフォーマンステストの範囲は、範囲内と範囲外の両方のビジネスプロセスで定義されています。
＃4）アプローチ： ここでは全体的なアプローチについて説明しますが、パフォーマンステストはどのように実行されますか？環境を設定するための前提条件は何ですか？などが含まれています。
＃5）アーキテクチャ： アプリケーションサーバー、Webサーバー、DBサーバー、ファイアウォール、3の総数など、アプリケーションアーキテクチャの詳細をここに記載する必要があります。rddパーティアプリケーション負荷発生機など
＃6）依存関係： パフォーマンステスト対象のコンポーネントが機能的に安定している、環境が1つのような本番環境にスケーリングされて利用可能かどうか、テスト日が利用可能かどうか、パフォーマンステストツールがライセンスで利用可能であるなど、すべてのパフォーマンス前テストアクションをここで説明する必要があります。もしあれば、など。
＃7）環境： IPアドレス、サーバーの数など、システムのすべての詳細について言及する必要があります。また、前提条件、更新するパッチなど、環境の設定方法についても明確に言及する必要があります。
＃8）テストシナリオ： テストするシナリオのリストは、このセクションに記載されています。
＃9）ワークロードミックス： ワークロードミックスは、パフォーマンステストを正常に実行する上で重要な役割を果たします。ワークロードミックスがリアルタイムのエンドユーザーアクションを予測しない場合、すべてのテスト結果が無駄になり、本番環境でのパフォーマンスが低下します。アプリケーションが稼働するとき。
したがって、ワークロードを適切に設計する必要があります。ユーザーが本番環境でアプリケーションにアクセスしている方法を理解し、アプリケーションがすでに利用可能かどうかを理解するか、ビジネスチームから詳細を取得して、アプリケーションの使用法を適切に理解し、ワークロードを定義します。
＃10）パフォーマンス実行サイクル： このセクションでは、パフォーマンステストの実行回数の詳細について説明します。 例えば、 ベースラインテスト、サイクル150ユーザーテストなど。
＃11）パフォーマンステストメトリクス： 収集されたメトリックの詳細はここで説明されます、これらのメトリックは 合否基準 合意されたパフォーマンス要件で。
＃12）テスト成果物： 成果物に言及し、該当する場合はドキュメントへのリンクも組み込みます。
＃13）欠陥管理： ここで、欠陥がどのように処理されるかについて言及する必要があります。 重大度レベルと優先度レベル また、説明する必要があります。
＃14）リスク管理： アプリケーションが安定していない場合や優先度の高い機能上の欠陥がまだ開いている場合など、緩和計画に伴うリスクについて言及します。これはパフォーマンステストの実行スケジュールに影響します。前述のように、これはパフォーマンステスト中に発生するリスクに役立ちます。少なくともリスクの回避策は、かなり前もって計画されます。
＃15）リソース： チームの詳細とその役割および責任について言及します。
＃16）バージョン履歴： ドキュメントの履歴を追跡します。
Javaで配列の順序を逆にする方法
＃17）ドキュメントのレビューと承認： これには、最終的なドキュメントをレビューして承認する人のリストがあります。
したがって、基本的にパフォーマンステスト戦略にはパフォーマンステストへのアプローチがあり、パフォーマンステスト計画にはアプローチの詳細があるため、それらは一緒になります。一部の企業は、アプローチがドキュメントに追加されたパフォーマンステスト計画を持っているだけですが、一部の企業は、戦略と計画の両方のドキュメントを別々に持っています。
これらのドキュメントを作成するためのヒント
パフォーマンステストを正常に実行するための戦略または計画ドキュメントを設計するときは、以下のガイドラインに従ってください。
- パフォーマンステスト戦略またはテスト計画を定義するときは、テストの目的と範囲に焦点を当てる必要があることを常に忘れないでください。テスト戦略または計画が要件または範囲に沿っていない場合、テストは無効です。
- システムのボトルネックを特定したり、アプリケーションのパフォーマンスを確認したりするために、テスト実行中にキャプチャすることが重要なメトリックを集中して組み込むようにしてください。
- すべてのシナリオを一度にテストしてシステムをクラッシュさせないように、テストの実行を計画します。多数のテストを実行し、シナリオとユーザーの負荷を徐々に増やします。
- あなたのアプローチでは、アプリケーションにアクセスするすべてのデバイスを追加してみてください。これは通常、モバイルデバイスに適用されます。
- 要件は随時変更されるため、戦略ドキュメントには常にリスクと軽減のセクションがあります。この変更は、実行サイクルと期限に大きな影響を与え、クライアントに事前に対処する必要があります。
結論
このチュートリアルでは、パフォーマンステスト戦略と計画の違いを、その内容、モバイルアプリケーションパフォーマンステストのアプローチ、クラウドアプリケーションパフォーマンステストの例とともに詳細に説明したと思います。
パフォーマンステストを過給する方法について詳しくは、今後のチュートリアルをご覧ください。
=> 完全なパフォーマンステストチュートリアルシリーズについては、こちらをご覧ください
前のチュートリアル | 次のチュートリアル