目標に基づくパフォーマンステスト

目標ベースのパフォーマンステストは、特にパフォーマンステストにおいて、ソフトウェアシステムがさまざまな条件下で特定のパフォーマンス目標を達成していることを保証するために使用されるソフトウェアテストの戦略です。目標ベースのパフォーマンステストでは、単にテストを行うのではなく、あらかじめ定義された目標や目的に基づいてテストプロセスが推進されます。

目標ベースのテストは以下のステップで進行します：

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

パフォーマンステストは主にアプリケーションの速度と信頼性の確認に焦点を当て、ロードテスト（目標志向型）とストレステストに分かれます。アジャイル開発手法の台頭により、ロードテストの結果を容易に再現できることが重要になっています。

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

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

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

• ステークホルダーの期待との整合：具体的なパフォーマンス目標を定義することにより、エンドユーザー、クライアント、プロジェクトスポンサーを含むステークホルダーの期待にソフトウェアのパフォーマンスが合致していることを保証します。
• パフォーマンス要件の検証：目標ベースのテストは、ソフトウェアがパフォーマンス要件を満たしているかどうかを検証し、パフォーマンスの妥当性を評価する具体的な指標を提供します。
• リソース使用の最適化：目標ベースのテストは、システムリソースの非効率や過剰使用を特定し、より効率的なリソース配分とコスト削減につながります。
• スケーラビリティ：負荷や同時ユーザー数の増加に対するパフォーマンスを測定することで、ソフトウェアのスケーラビリティを評価し、増加するユーザーベースや作業負荷に対応できることを保証します。
• リスク軽減：あらかじめ定義されたパフォーマンス目標に対して積極的にテストを行うことで、ソフトウェアの展開前にパフォーマンス関連のリスクを特定し軽減し、ダウンタイム、ユーザー不満、財務損失の可能性を減少させます。

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

新しいCRMアプリケーションで20人の同時ユーザーが1時間に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 Recorderによって自動的に追加されることを覚えておいてください。
• 1つのスクリプトに複数のThinkTimesが存在することがあります。
• 単一スクリプトのテスト実行ではThinkTimesは無視されます。
• ThinkTimesはキャリブレーション/ベースライン取得で使用されます。
• ThinkTimesは応答時間の測定には寄与しません。
• ストレステストではThinkTimesは無視されます。

ユーザー同時接続数（オプション）：

• EveryStep Web Recorderに新しい「WaitFor（ユーザー数）」キーワードを導入します。
• これはグローバルな待機ポイントで、指定されたユーザー数がスクリプトの特定部分に達するまでシミュレートされたユーザーをブロックします。

応答時間の閾値（オプション）：

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

ベースライン／キャリブレーション（必須）：

• LoadViewは単一ユーザーテストを実行します。
• ThinkTimesはスクリプト通りに使用されます。
• LoadViewはセッション時間を計算します：セッション時間 = スクリプト実行時間 + ThinkTime。

ワークロード／実行計画の設定（必須）：

• 顧客はランプアップ時間を指定します。
• 顧客は目標トランザクション率を定義します。
• 顧客は目標セッション時間を設定します。
• システムはユーザー数を計算します。
• 顧客はランプアップ中に応答時間を計算するかどうかを決定します。

テストの実行（必須）：

• LoadViewは設定されたワークロード／実行計画に従ってテストを実施します。
• LoadViewはシミュレートされたスクリプトまたはトランザクションの応答時間を収集します。
• LoadViewは期待されるスループットを達成するためにThinkTimeを動的に調整します；もし対象アプリケーションが遅くなる場合はThinkTimesを減らします。もしThinkTimesがゼロでセッション時間が目標を超えた場合、期待スループットに達しなかったことを示すエラーメッセージが表示されます。
• LoadViewはThinkTimesを除いた実際のトランザクションおよびタイマーの応答時間を計算します。

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

EveryStep Web Recorder

• 新しいThinkTimeキーワードの導入。
• 単一ユーザーテスト実行時にはThinkTimeを無視。
• スクリプト記録中にThinkTimeを追加。
• 新しいWaitFor（ユーザー数）キーワードの導入。
• 新しいSetBoundary（TimerName, B1, B2）キーワードの導入。
• WaitForキーワードは作成されたスクリプトに手動で追加する必要があります。
• SetBoundaryキーワードの活用。

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

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

実行計画／ワークロード

オプション1：

• 新しいワークロード構成機能を追加。
• 実行計画をワークロード機能に置き換え。
• ストレステスト、トランザクション目標などをサポートするワークロード設定ダイアログを作成。
• ランプアップ時間を指定。
• ランプアップ中に応答時間を計算するかどうかのチェックボックスを用意（はい／いいえ）。

オプション2：

• 強化された実行計画設定機能を使用。
• テストタイプを選択（ストレス、目標ベース）。
• トランザクション目標の詳細を設定。
• ランプアップ時間を指定。
• ランプアップ中に応答時間を計算するかどうかのチェックボックスを用意（はい／いいえ）。

テストの実行

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

レポート

• タイマーごとの応答時間の実績と閾値の比較セクションを設定。
• スループットの実績と期待値の比較セクションを設定。

Dotcom-Monitor統合のヒント：FAQ

ユーザー入力は何ですか？

• ThinkTimes（浮動小数点、＞0）
• 時間あたりの目標トランザクション数（整数）
• 最大ユーザー数（整数）
• ランプアップ時間（分）
• ランプアップ中の応答時間計算（はい／いいえ）

ベースラインとは何ですか？

ThinkTimesを含むデバイスまたはスクリプトの単一ユーザー実行です。スクリプト実行時間が計算され、実行に必要なリソースなどの追加情報と共にセッション時間として保存されます。

トランザクション速度が対象システムで変化した場合、どのように負荷テストを動的に調整できますか？

• キャリブレーション時にセッション時間を計算
• ThinkTimesを使って要求される目標セッション時間に達する
• テスト実行中に実際のセッション時間を再計算
• 実際のセッション時間に応じてThinkTimesを動的に調整
• スクリプト実行時間が目標セッション時間を超えた場合、エラーメッセージを記録
• ワークロード計算で最大ユーザー数を指定

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

複雑なユーザーシナリオ、特に同時実行の状況をシミュレートし、複数ユーザーが同時にリソースにアクセスした場合に特定の機能が正しく動作するかテストするのに有用です。

SetBoundaryキーワードとは何ですか？

指定されたSLA応答時間の境界に対して、特定のアクションまたはタイマーの実際の速度を検証するのに役立ちます。許容境界が破られた場合、エラーメッセージが表示されテストレポートに記録され、SLA検証が容易になります。

ロードテストにおける目標は何にすべきですか？

• 異なるリリースや実行間で100パーセント比較可能なパフォーマンステストを保証する。
• 通常またはピーク負荷パターンをシミュレートする機能を含める。
• 対象システムが合意された範囲内で期待負荷に耐えられることに自信を持つ。
• 合意された境界を破るユーザーアクションにパフォーマンス最適化を集中させる。

どのようなレポートを設定すべきですか？

• 現在のレポートに類似したレポートを作成。
• 平均、最小、最大、標準偏差、パーセンタイルの応答時間を含める。
• トランザクションの成功数、失敗数、エラー率を追跡。
• すべての応答時間はThinkTimesを含まないものとする。

制限事項

目標セッション時間が高すぎると、セッションタイムアウトや誤検知が発生する可能性があります。ウェブセッションタイムアウトが短いシナリオでは、セッションタイムアウトによる失敗を防ぐためにThinkTimesを適切に配置することが重要です。

目標に到達しなかった場合はどうなりますか？

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

目標ベースのワークロードのサンプルはどのようなものですか？

• ランプアップ時間：15分
• ランプアップ中の応答時間を測定：はい／いいえ
  ST：セッション時間
• GST：目標セッション時間
• TPH：時間あたりのトランザクション数
• ユーザー：LoadViewによる計算（3600 / TPH） * GST = 72