目標ベースのパフォーマンステスト

目標ベースのパフォーマンステストは、ソフトウェアテスト、特にパフォーマンステストで採用される戦略であり、ソフトウェアシステムがさまざまな条件下で特定のパフォーマンス目標を満たしていることを確認するためです。 目標ベースのパフォーマンス テストでは、テスト プロセスは、単にテストを行うのではなく、事前に定義された目標または目的によって推進されます。

目標ベースのテストは、次の手順で行います。

1. パフォーマンス目標の定義: 最初のステップでは、テスト対象のソフトウェアシステムにとって重要なパフォーマンス目標を定義します。 これらの目標には、応答時間のしきい値、スループット要件、リソース使用率の目標、およびスケーラビリティのベンチマークが含まれます。
2. テストシナリオの設計: テストシナリオは、定義されたパフォーマンス目標に基づいて設計されます。 これらのシナリオでは、さまざまなユーザーの動作、負荷、およびシステム構成をシミュレートして、さまざまな条件下でソフトウェアがどのように動作するかを評価します。 たとえば、シナリオには、ピーク使用期間、大量のトランザクション負荷、またはユーザー アクティビティの突然の急増が含まれる場合があります。
3. テストの実行: テストシナリオは、テスト要件の下でソフトウェアシステムに対して実行されます。 このフェーズでは、応答時間、スループット、リソース使用率、システムのスケーラビリティなどのパフォーマンス指標が測定および監視されます。
4. 結果の分析と改善: 収集されたパフォーマンス データが分析され、システムが事前定義された目標を満たしているかどうかが評価されます。 この分析は、パフォーマンスのボトルネック、スケーラビリティの制限、およびシステムがパフォーマンス要件を満たさない可能性がある領域を特定するのに役立ちます。 テスト結果の分析に基づいて、ソフトウェアシステムに必要な改善と最適化を行います。
5. このプロセスを繰り返します。 目標ベースのパフォーマンス テストは、反復的なプロセスです。 改善を行った後、テストサイクルを繰り返して、パフォーマンス目標が達成されたかどうかを検証し、発生した可能性のある新しいパフォーマンスの問題を特定します。

パフォーマンス テストは、主にアプリケーションの速度と信頼性のチェックに重点を置いており、負荷テスト (目標指向) とストレス テストに分かれています。 アジャイル開発手法の台頭に伴い、ロード テストの結果を簡単に再現できることが重要になっています。

パフォーマンス目標を定義することの重要性

パフォーマンス目標の定義は、目標ベースのパフォーマンス テストの基礎です。 これらの目標は、ソフトウェアのパフォーマンスを測定する基準として機能します。 これらは、通常の使用、ピーク負荷、ストレス シナリオなど、さまざまな条件下でソフトウェアがパフォーマンス要件を満たしているかどうかを評価するための具体的なフレームワークを提供します。

目標ベースのパフォーマンステストの主な理由

• 利害関係者の期待に沿う: 特定のパフォーマンス目標を定義することで、ソフトウェアのパフォーマンスがエンドユーザー、クライアント、プロジェクトスポンサーなどの利害関係者の期待に沿うようにすることができます。
• パフォーマンス要件の検証: 目標ベースのテストは、ソフトウェアがパフォーマンス要件を満たしているかどうかを検証するのに役立ち、パフォーマンスの妥当性を評価するための具体的な指標を提供します。
• リソース使用率の最適化: 目標ベースのテストは、システムリソースの非効率性や過剰使用を特定することでリソース使用率を最適化するのに役立ち、より効率的なリソース割り当てとコスト削減につながります。
• 拡張性: 目標ベースのテストでは、負荷の増加やユーザーの同時実行性の下でパフォーマンスを測定することで、ソフトウェアのスケーラビリティを評価し、増大するユーザーベースとワークロードを処理できることを確認します。
• リスクの軽減: 事前定義されたパフォーマンス目標に対してプロアクティブにテストすることで、ソフトウェアを展開する前にパフォーマンス関連のリスクを特定して軽減し、ダウンタイム、ユーザーの不満、または経済的損失の可能性を減らすことができます。

目標ベースのユースケース:問題

20人の同時ユーザーが、新しいCRMアプリケーションで毎時2,000件のトランザクションを生成するとします。 目的は、次の 4 つのリリースで 8 秒の応答時間を確保するパフォーマンス テストを考案することです。 ストレス テストでは、応答時間が現在のリリースと異なる可能性があるため、これらの今後のリリースで予想されるスループットを正確に再現できない場合があります。

目標ベースのユースケース:ソリューション

1. ThinkTimesをスクリプトに統合して、ユーザーアクションの間に一時停止を導入します。
2. ベースラインを決定し、シングルユーザースクリプトの実行時間を測定して、セッション時間を計算します。
3. 最大ユーザー数、目標ベースのトランザクション率、目標ベースのトランザクション時間などのワークロードパラメータを設定します。
4. 目標ベースのパフォーマンス テストを実行して、アプリケーションで予想される負荷をシミュレートします。
5. テスト・レポートを検討して、アプリケーションが事前定義された応答時間境界内で負荷を処理できたかどうかを確認します。
6. 後続の 4 つのリリースでテスト実行を繰り返して、アプリケーションがスループットと応答時間のしきい値を長期にわたって維持するかどうかを評価します。

LoadView の EveryStep ツールを構成するための推奨事項とヒント

ThinkTime (必須):

• EveryStep Web Recorder (ThinkTimes) で新しいキーワードを作成するか、既存のキーワードを再利用します。
• 許容値が浮動小数点 0.0 から 999.99 であることを確認します。
• ユーザーがスクリプトに ThinkTimes を手動で追加できるようにします。
• ThinkTimes は待機時間を表し、ユーザー操作の記録中に EveryStep Web レコーダーによって自動的に追加されることに注意してください。
• 1つのスクリプトに複数のThinkTimesが存在できます。
• ThinkTimes は、1 回のスクリプト テストの実行では無視されます。
• ThinkTimesは、キャリブレーション/ベースラインの取得に利用されます。
• ThinkTimesは、応答時間の測定には寄与しません。
• ThinkTimesはストレステストでは無視されます。

ユーザーの同時実行 (オプション):

• 新しい “WaitFor (ユーザー数)” キーワードを EveryStep Web レコーダーに導入します。
• このグローバル待機ポイントは、予想されるユーザー数がスクリプトのこの部分に到達するまで、特定のスクリプト セクションでシミュレートされたユーザーをブロックします。

応答時間しきい値 (オプション):

• 新しい SetBoundary キーワードを EveryStep Web レコーダーに実装します。
• 構文: SetBoundary(Timername, Bound 1, Bound 2)。

ベースライン/キャリブレーション(必須):

• LoadView は、1 つのユーザー テストの実行を実行します。
• ThinkTimesはスクリプトどおりに使用されます。
• LoadView は、セッション時間 = スクリプト実行時間 + ThinkTime というセッション時間を計算します。

ワークロード/実行計画の構成 (必須):

• お客様はランプアップ時間を指定します。
• 顧客は目標トランザクションレートを定義します。
• お客様は、目標セッション時間を設定します。
• システムによってユーザー数が計算されます。
• 立ち上げ時の応答時間を計算するかどうかは、お客様が決定します。

テストの実行 (必須):

• LoadView は、構成されたワークロード/実行計画に従ってテストを実行します。
• LoadView は、シミュレートされたスクリプトまたはトランザクションの応答時間を収集します。
• LoadView は、予想されるスループットを達成するために ThinkTime を動的に調整します。テスト対象のアプリケーションの速度が低下すると、ThinkTimes が短縮されます。 ThinkTimes が 0 で、セッション時間が目標セッション時間を超えると、予期されたスループットに到達できなかったことを示すエラー メッセージが表示されます。
• LoadView は、実際のトランザクションと待ち時間のないタイマーの応答時間を計算します。

Dotcom-Monitor と統合するための推奨事項とヒント

エブリステップウェブレコーダー

• 新しいThinkTimeキーワードのご紹介です。
• シングルユーザーテストの実行中にThinkTimeを無視します。
• スクリプトの記録中に ThinkTime を追加します。
• 新しい WaitFor(Number user) キーワードを導入しました。
• 新しい SetBoundary(TimerName, B1, B2) キーワードを導入しました。
• WaitFor キーワードは、作成したスクリプトに手動で追加する必要があります。
• SetBoundary キーワードを利用します。

キャリブレーション/ベースラインの取得

• キャリブレーション中にセッション時間を計算します。

実行計画/ワークロード

オプション 1:

• 新しいワークロード構成機能を追加します。
• 実行計画をワークロード機能に置き換えます。
• ワークロード構成ダイアログを作成して、ストレス テスト、トランザクション目標、およびその他の種類をサポートします。
• ランプアップ時間を指定します。
• ランプアップ時の応答時間を計算するためのチェックボックスをオンにします(はい/いいえ)。

オプション 2:

• 拡張された実行プラン構成機能を使用します。
• テストの種類(ストレス、目標ベース)を選択します。
• トランザクション目標の詳細を設定します。
• ランプアップ時間を指定します。
• ランプアップ時の応答時間を計算するためのチェックボックスをオンにします(はい/いいえ)。

テストの実行

• 実際のスクリプト実行時間/セッション時間を計算します。
• 実際のセッション時間に基づいてThinkTimesを動的に調整します。
• 期待されたスループットに到達できなかった場合は、警告を発します。

報告

• 応答時間、タイマーごとの実際のしきい値のセクションを設定します。
• スループットのセクションを、実際のスループットと予想値で構成します。

Dotcom-Monitor と統合するためのヒント: FAQ

ユーザー入力とは何ですか?

• 思考時間 (浮動小数点 > 、0)
• 1 時間あたりの目標トランザクション (整数)
• ユーザーの最大数 (整数)
• ランプアップ時間(分)
• ランプアップ中の応答時間を計算する(はい/いいえ)

ベースラインとは

ThinkTimes を組み込んだデバイスまたはスクリプトの 1 人のユーザーによる実行。 スクリプトの実行時間は、必要な実行リソースなどの追加の詳細とともに、セッション時間として計算され、保存されます。

ターゲット システムでトランザクション速度が変化した場合にロード テストを動的に調整する方法はありますか

• キャリブレーション中のセッション時間の計算
• ThinkTimes を使用して、要求されたゴール セッション時間に到達する
• テスト実行中の実際のセッション時間を再計算する
• 実際のセッション時間に応じて ThinkTimes を動的に調整
• スクリプトの実行時間が > ゴール セッション時間の場合、ログ エラー メッセージ
• ワークロード計算の最大ユーザー数を指定します。

WaitFor キーワードとは何ですか?

これは、複雑なユーザー シナリオ (特に同時実行の状況) をシミュレートし、複数のユーザーが同時にリソースにアクセスした場合に特定の機能が正しく動作するかどうかをテストするのに役立ちます。

セットバウンダリーキーワードとは何ですか?

特定のアクションまたはタイマーの実際の速度を、指定された SLA 応答時間の境界に照らして検証するのに役立ちます。 許可された境界に違反すると、エラーメッセージが表示され、テストレポートに記録されるため、SLAの検証が簡素化されます。

ロード テストの目標は何ですか?

• 異なるリリース/実行間で100%比較可能なパフォーマンステストを確保します。
• 通常の負荷パターンまたはピーク負荷パターンをシミュレートするための機能を含めます。
• テスト対象のシステムが、合意された境界内で予想される負荷を処理できることを確信できます。
• 合意された境界に違反するユーザーアクションにパフォーマンスの最適化を集中させます。

どのような種類のレポートを構成する必要がありますか。

• 現在のレポートに類似したレポートを作成します。
• 平均、最小、最大、標準偏差、パーセンタイルの応答時間を含めます。
• トランザクション ok、トランザクションの失敗、およびエラー率を追跡します。
• すべての応答時間は、ThinkTimesを含めずにする必要があります。

制限

目標セッション時間が長いと、セッションのタイムアウトや誤検知につながる可能性があります。 Web セッションのタイムアウトが短いシナリオを検討し、セッションのタイムアウトによる障害を防ぐために ThinkTimes を適切に配置することが重要です。

目標に到達できなかったらどうなるのか?

• ロード テスト中のアプリケーションの応答時間が遅くなり、セッション時間が目標セッション時間を超えると、予想されるトランザクション レートに到達できません。
• LoadView は、テスト実行中に実際のセッション時間を監視し、予想される目標ベースのトランザクション レートに到達しようとするように ThinkTimes を調整します。
• LoadView は、セッション時間が目標セッション時間を超えた場合、監視画面にエラー メッセージを表示します。
• LoadView は、目標トランザクション レートを達成できない場合、テストの実行を続行し、テストの実行を失敗としてマークし、影響を受けるデバイスをレポートに示します。

目標に基づくワークロードのサンプルはどのようなものでしょうか。

• 立ち上げ時間:15分
• ランプアップ中の応答時間を測定する:はい/いいえ
  ST: セッション時間
• GST: ゴールセッション時間
• TPH: 1 時間あたりのトランザクション数
• ユーザー: LoadView (3600 / TPH) * GST = 72 によって計算されます