パフォーマンス テストでは、主にアプリケーションの速度と信頼性を検証し、 ロード テスト (目標ベース) と ストレス テストに分けられます。 アジャイル開発手法の台頭以来、ロード テストの結果を再現できることが最優先事項になっています。
ストレステストの理由は何ですか?
パフォーマンス テストを構成する最も簡単な方法は、多くのユーザーがテスト スクリプトを反復的に実行できるようにすることです。 この種類のテストは ストレス テスト と呼ばれ、ビジネス アプリケーションのブレークポイントを特定するためによく使用されます。 欠点は、アプリケーションの実際の応答時間が主にシミュレートされた負荷に影響を及し、実際のスループットを制御できないことです。 スケーラビリティ テストでは、これは問題ではありませんが、異なるリリース間のパフォーマンス比較では問題が発生する可能性があります。
目標ベースのパフォーマンス テストの理由は何ですか。
このタイプのテストの主な利点は、現実的で再現可能な条件とスループットの境界の下での速度測定が可能であるということです。 目標ベースのパフォーマンス テストは、運用環境に似ている環境でサービス レベル契約を検証するためによく使用されます。
次の状況を考えてみましょう。
20 人の同時ユーザーが 1 時間あたり新しい CRM アプリケーションで 2,000 のトランザクションを作成すると仮定します。 このアプリケーションの応答時間が次の 4 つのリリースで達成できることを確認するパフォーマンス テストを作成する必要があります。 ストレス テストでは、応答時間が実際のリリースと同じ状態になるとは想定できないため、4 つのリリース パフォーマンス テストで予想されるスループットの正確なシミュレーションが許可されない可能性があります。
解決：
- スクリプトに ThinkTimes を追加する
- セッション時間を取得するためのベースラインおよびシングルユーザースクリプトランタイムを見つける
- 最大ユーザー数、目標ベースのトランザクションレート、目標ベースのトランザクション時間を含むワークロードの構成
- 目標ベースのパフォーマンス テストを実行して、予想される負荷をシミュレートします。
- テスト レポートを確認し、 テスト 対象のアプリケーションが合意された応答時間の境界内で負荷を処理できたかどうかを確認します。
- 次の 4 つのリリースでこのテストを繰り返し実行し、アプリケーションがスループットと応答時間のしきい値を保持できたかどうかを確認します。
エブリステップツールの設定に関するヒント
待ち時間 (必須)
EveryStep Web レコーダー (ThinkTimes) で新しいキーワードを作成するか、既存のキーワードを再利用する
許容値が浮動小数点値であることを確認する 0.0 ~ 999.99
ユーザーがスクリプトに手動で ThinkTimes を追加できることを確認する
ThinkTimes は待ち時間であり、ユーザーアクションの記録中に EveryStep Web レコーダーによって自動的に追加されることを覚えておいてください。
1つのスクリプトにNのThinkTimesがある可能性があります
ThinkTimes は、単一のスクリプト テストの実行で無視されます。
ThinkTimes は、キャリブレーション/ベースラインの取得で使用されます。
待ち時間は応答時間の測定の一部ではありません
ストレステストではThinkTimesは無視される
ユーザー同時実行 (オプション)
EveryStep Web レコーダーの新しい “WaitFor (ユーザー数)” キーワード
これは、スクリプトの特定の時点でシミュレートされたユーザーを、予想される数のユーザーがスクリプトのこのセクションに達するまでブロックするグローバル待ちポイントです。
応答時間のしきい値 (オプション)
EveryStep ウェブ レコーダーの新しい SetBoundary キーワード
構文: SetBoundary(タイマー名、バインド済み 1、バインド 2)
ベースライン/キャリブレーション(必須)
LoadView は、単一のユーザー テストの実行を実行します。
ThinkTimes はスクリプトとして使用されます。
ロードビュー はセッション時間を計算します
セッション時間 = スクリプト実行時間 + ThinkTime
ワークロード/実行プランの設定 (必須)
顧客は、時間を立ち上げる設定
顧客設定目標トランザクション レート
顧客が目標セッション時間を設定
システムはユーザー数を計算します
顧客は、ランプアップ中に応答時間を計算するかどうかを決定します
テストの実行 (必須)
LoadView は、構成されたワークロード/実行プランに従ってテストを実行します。
LoadView は、シミュレートされたスクリプトまたはトランザクションの応答時間を収集します。
LoadView は、テスト対象アプリケーションが遅くなる場合に、期待されるスループットに到達するように ThinkTime を動的に調整します。 ThinkTimes が 0 で、セッション時間が > ゴール セッション時間を取得する場合、予想されるスループットに達し得ないことを示すエラー メッセージが表示されます。
LoadView は、実際のトランザクションと待ち時間のないタイマーの応答時間を計算します。
ドットコムモニターとの統合に関するヒント
エブリステップウェブレコーダー
新しい ThinkTime キーワードの紹介
シングルユーザーテストの実行中に ThinkTime を無視する
スクリプトの記録中に ThinkTime を追加する
新しい WaitFor (番号ユーザー) キーワードの導入
新しいセットバウト (タイマー名、B1、B2) キーワードの導入
WaitFor キーワードは、作成されたスクリプトに手動で追加する必要があります。
セット境界キーワードを使用する
キャリブレーション/ベースラインの取得
キャリブレーション中のセッション時間の計算
実行計画/ワークロード
オプション 1:
新しいワークロード構成機能の追加
実行プランをワークロード機能に置き換える
ストレス テスト、トランザクションの目標、およびその他の種類をサポートする [ワークロード構成] ダイアログ ボックス
ランプアップ時間の指定
ランプアップ中の応答時間を計算するチェックボックスをオンにします(はい/いいえ)。
オプション 2:
拡張実行プラン構成機能の使用
テストタイプを選択する(応力、目標ベース)
トランザクション目標の詳細を設定する
ランプアップ時間の指定
ランプアップ中の応答時間を計算するチェックボックスをオンにします(はい/いいえ)。
テストの実行
実際のスクリプト実行時間/セッション時間の計算
実際のセッション時間に基づいて ThinkTimes を動的に調整
予想されるスループットに達できなかった場合に警告を発生させる
報告
応答時間、タイマーあたりの実際のしきい値とのしきい値のセクションを構成する
スループットのセクションを構成する(実際と予想される)
ユーザー入力とは何ですか?
思考時間 (浮動小数点 > 、0)
1 時間あたりの目標トランザクション (整数)
ユーザーの最大数 (整数)
ランプアップ時間(分)
ランプアップ中の応答時間を計算する(はい/いいえ)
「ベースライン」とは何ですか?
デバイスまたはスクリプトの単一のユーザーの実行。 パラメーターには、待ち時間が使用されます。 スクリプトの実行時間が計算され、セッション時間として保存されます。 必要な実行リソースなど、追加の詳細も計算されます。
ターゲット システムでトランザクション速度が変化した場合にロード テストを動的に調整する方法はありますか
キャリブレーション中のセッション時間の計算
ThinkTimes を使用して、要求されたゴール セッション時間に到達する
テスト実行中の実際のセッション時間を再計算する
実際のセッション時間に応じて ThinkTimes を動的に調整
スクリプトの実行時間が > ゴール セッション時間の場合、ログ エラー メッセージ
ワークロード計算の最大ユーザー数を指定します。
WaitFor キーワードとは何ですか?
これは、同時実行状況などの複雑なユーザー シナリオをシミュレートするのに役立ちます。 x ユーザー数が同時にリソースにアクセスしている場合に、特定の機能が正しく動作するかどうかをテストする必要がある場合に非常に便利です。
セットバウンダリーキーワードとは何ですか?
SLA は、顧客の検索などのユーザーアクションの応答時間の境界を指定します。 SetBoundary キーワードを使用すると、特定のアクションまたはタイマーの実際の速度を確認できます。 許可された境界に違反すると、エラー・メッセージが表示され、テスト・レポートにログ出力されます。 SLA の検証は、この新しい SetBoundary キーワードではるかに簡単です。
ロード テストの目標は何ですか?
- 異なるリリース/実行で 100% の同等のパフォーマンス・テストを実施
- 通常またはピーク負荷パターンのシミュレーションのための機能
- テスト対象のシステムが、合意された境界内で予想される負荷を処理できる自信
- 合意された境界に違反したユーザーアクションにパフォーマンスの最適化を集中させる
どのような種類のレポートを構成する必要がありますか。
- 現在のレポートに似たレポートを作成する
- 平均、最小、最大、標準偏差、百分位数応答時間
- トランザクションは問題です、トランザクションは失敗しました
- エラー率
- すべての応答時間は、ThinkTimesなしであるべきです
制限
目標セッション時間が長いと、セッションのタイムアウトや誤検知が発生する可能性があります。 ウェブ セッションのタイムアウトが非常に低い状況 (10 分など) を考慮します。 ログインと顧客検索を実行する単純なスクリプトを使用して目標ベースのパフォーマンス テストを実行する場合は、ログインと検索の間に ThinkTime を配置する必要があります。 この仮定の状況では、セッション時間はゴールセッション時間700秒の10秒でなければなりません。 このシナリオでは、ThinkTime はテスト対象のアプリケーションのセッション タイムアウトよりも高くなります。 スクリプトは ウェブ セッションのタイムアウトで実行され、顧客の検索を実行できないため、シミュレートされたトランザクションはすべて失敗します。
目標を達成できない場合はどうなりますか?
ロード テスト中のアプリケーションの応答時間が遅くなり、セッション時間が目標セッション時間よりも長くなると、予想されるトランザクション レートに達しません。
LoadView は、テスト実行中の実際のセッション時間を監視し、予想される目標ベースのトランザクション レートに到達するために ThinkTimes を調整します。
また、セッション時間がゴールセッション時間より大きくなると、LoadView は監視画面にエラーメッセージを表示します。
目標トランザクション レートを達成できない場合、LoadView はテストの実行を続行します。 この状況では、テストの実行は失敗状態でマークされます。 このテストでは、応答時間の遅れにより予想されるスループットに達しないこと、および影響を受けるデバイスを示す結果が明確に報告されます。
目標に基づくワークロードのサンプルはどのようなものでしょうか。
| スクリプト/デバイス | ST (秒)
編集不可 |
GST (秒)
ユーザー入力 |
TPH
ユーザー入力 |
利用者
編集不可 |
| Search_User | 25 | 10 | 500 | 72 |
| Inser_User | 25 | 60 | 1000 | 216 |
ランプアップ時間:15分
ランプアップ中の応答時間を測定する:はい/いいえ
ST: セッション時間
GST: ゴールセッション時間
TPH: 1 時間あたりのトランザクション数
ユーザー: ロードビュー (3600 / TPH) * GST = 72 で計算