パフォーマンステスト計画テンプレート

パフォーマンス要件の観点からプロジェクトのニーズに合わせてそのまま使用することも、変更することもできるパフォーマンステスト計画テンプレート。



1。目的

このセクションの目的は、で従う必要のあるパフォーマンステストアプローチの概要を説明することです。事業。これは、関連するすべての利害関係者に提示する必要があり、コンセンサスを得るために話し合う必要があります。



2.はじめに

の提供の一環として、ソリューションが機能領域と非機能領域の両方の点で受け入れ基準を満たしている必要があります。このドキュメントの目的は、の非機能テストの概要を提供することです。解決。


このドキュメントの内容は次のとおりです。

  • 入退場基準
  • 環境要件
  • ボリュームおよびパフォーマンステストアプローチ
  • パフォーマンステスト活動


3.エントリー基準

実際のパフォーマンステストアクティビティを続行するには、次の作業項目を事前に完了/合意する必要があります。


  • によって提供される非機能テスト要件ドキュメント、可能な場合は定量化されたNFR
  • 重要なユースケースは機能的にテストされ、重大なバグが未解決でないようにする必要があります
  • 設計アーキテクチャ図が承認され、利用可能
  • 主要なユースケースが定義され、範囲が限定されています
  • 合意されたパフォーマンステストの種類
  • ロードインジェクターのセットアップ
  • 必要なデータ設定-例: で作成された適切な数のユーザー


4.終了基準

パフォーマンステストアクティビティは、次の場合に完了します。

  • NFRの目標が達成され、パフォーマンステストの結果がチームに提示されて承認されました。


5.環境要件

パフォーマンステストは、の安定バージョンに対して実行されます。ソリューション(すでに機能テストに合格しています)は、パフォーマンステストの過程でその環境に展開せずに、パフォーマンステストに割り当てられた専用の本番環境のような環境(製品前?)で実行されます。

5.1ロードインジェクター

パフォーマンステストに必要な負荷を開始するために、1つ以上の専用の「ロードインジェクター」がセットアップされます。ロードインジェクターは、JMeterのインスタンスが実行されているVMまたは複数のVMであり、要求を開始します。

5.2テストツール

ボリュームテストとパフォーマンステストに使用されるテストツールは次のとおりです。


5.2.1 JMeter

オープンソースの負荷テストツール。主にボリュームとパフォーマンスのテストに使用されます。

5.2.2 Splunk

Splunkはロギングに使用されます(別のツールを使用できます-パフォーマンステストチームに確認する必要があります)。



6.ボリュームおよびパフォーマンステストアプローチ

ソリューションは、次の負荷基準を管理するのに十分なパフォーマンスを備えている必要があります。

N.B.次の表の数値はサンプルのみです。実際の値は、で確定したら挿入する必要があります。 NFRドキュメント。


6.1対象サービス量

[Y2019]の現在のソリューションから、1時間ごとのターゲットが検出されます。プランテンプレートから他の「例」の値をクリアしました。

時間ごとのピーク値は高くないため、固定負荷テストの対象とします。現在、スケーリング係数は未定です。

6.2ユーザー数

パフォーマンステストは、最大1000 [?]ユーザーで実行されます。ユーザーはで作成されます事前にからアクセスできますログインAPI。各リクエストは異なるユーザーIDでログインします。

6.3アサーション

JMeterツールは、パフォーマンステストスクリプトを実行するために使用されます。スクリプト内には、上記のメトリックをチェックするためのアサーションと、各要求に対して正しい応答が受信されることを確認するためのいくつかの基本的な機能チェックがあります。


6.4負荷プロファイル

負荷プロファイルは、への一般的な1日のトラフィックを模倣するように設計する必要があります。地点。トラフィックは、サイトの顧客IDおよびアクセス管理部分にのみ割り当てられ、制限されることに注意してください。

  • ログイン
  • 登録
  • パスワードを再設定する
  • パスワードをお忘れですか
  • 顧客を設定する
  • 顧客を獲得する

以下は、1日のプロファイルの例です。

6.4.1ベースライン

最初の行動方針は、ベースラインを見つけることです。 1人のユーザーのみを使用して、一定期間(5分など)シミュレーションを実行し、各エンドポイントの平均応答時間を取得します。これにより、1人のユーザーだけで、実際に1秒あたりのピークリクエストを達成できるようになります。


6.4.2負荷テスト

ベースラインメトリックが収集された後、負荷プロファイルをシミュレートする同じシミュレーションが、ターゲットボリュームに対してテストするために、より多くのユーザーで実行されます。この負荷テストのアイデアは、典型的な1日の負荷に対してシステムをテストし、ランプアップ、1日のピーク、およびランプダウンをシミュレートすることです。

6.4.3ストレステスト

ストレステストの目的は、システムのブレークポイント、つまりシステムが応答しなくなるポイントを見つけることです。自動スケーリングが実施されている場合、ストレステストは、システムがスケーリングされ、新しいリソースが追加される時点での優れた指標にもなります。ストレステストでは、負荷テストに使用されたものと同じシミュレーションが使用されますが、予想よりも高い負荷がかかります。

6.4.4スパイクテスト

スパイクテストは、比較的短時間でシステムに大きな負荷をかけます。このテストの目的は、たとえば、多数のユーザーが比較的短時間でアカウントに同時にアクセスする場合の販売イベントをシミュレートすることです。

6.4.5ソークテスト

ソークテストは、長期間にわたって負荷テストを実行します。目的は、ソークテストの過程でメモリリークや無応答またはエラーを明らかにすることです。通常、負荷の80%(負荷テストに使用)を24時間使用するか、負荷の60%を48時間使用します。

6.4.6飽和点テスト

飽和点テストでは、負荷を着実に増加させて、システムが応答しなくなるポイントを特定します。つまり、負荷の観点からシステムのブレークポイントを見つけます。



7.パフォーマンステスト活動

パフォーマンステストを完了するために、次のアクティビティを実行することをお勧めします。

7.1パフォーマンステスト環境の構築

  • ロードインジェクターには十分な容量があり、リモートで管理する必要があります。また、インジェクターの位置についても合意する必要があります
  • リアルタイムの監視およびアラートメカニズムを導入し、アプリケーション、サーバー、およびロードインジェクターをカバーする必要があります。
  • アプリケーションログにアクセスできる必要があります。

7.2ユースケーススクリプト

  • 使用するパフォーマンステストツールはJMeterです。
  • スクリプト化するユースケースのデータ要件について説明しました

7.3テストシナリオの構築

  • 実行するテストのタイプ(荷重/応力など)
  • 負荷プロファイル/負荷モデルは、テストタイプ(ランプアップ/ダウン、ステップなど)ごとに合意する必要があります
  • 思考時間をシナリオに組み込む

7.4テストの実行と分析

次のテストは、次の順序で実行する必要があります。

  • ベースラインテスト
  • 負荷テスト
  • ストレステスト
  • スパイクテスト
  • ソークテスト
  • 飽和点テスト

理想的には、各テストタイプの2つのテスト実行が実行されます。各テストの実行後、パフォーマンスを向上させるためにアプリケーションを微調整してから、別のテストサイクルを開始する場合があります。

7.5テスト後の分析とレポート

  • 関連するすべてのデータレポートとアーカイブをキャプチャしてバックアップします。
  • テスト結果をパフォーマンス目標と比較して、成功または失敗を判断します。目標が達成されない場合は、適切な変更を行う必要があり、その後、別のテスト実行サイクルが開始されます。合意された目標を達成するために必要な実行サイクル数は不明です。
  • テスト結果を文書化してチームに提示します。