...
Table of Contents | ||
---|---|---|
|
推奨する準備手順
「テストの構成」の説明に従ってテストを負荷テスト向けに構成し、次に「テストの検証」の説明に従ってテストが適切に動作しているか検証することを推奨します。
ただし、構成のステップを行わない場合 (既にテストが構成済みであり、追加した手動の構成を上書きしたくない場合など)、検証ステップに合格する限り、構成は必須ではありません。
Load Test パースペクティブの開き方
Load Test パースペクティブは、Web シナリオを負荷テスト用に準備するのに役に立つよう設計されています。Load Test パースペクティブを開くには、[ウィンドウ] > [パースペクティブ] > [パースペクティブを開く] > [Parasoft Load Test] を選択します。
...
- 自動でテストの構成と検証を行うための 2 つのツールバーボタン ([負荷テスト用に構成] および [負荷テスト用に検証])。また、Load Test を開始するツールボタン。
- 利用可能な Web シナリオを表示する Load Test エクスプローラー。負荷テストに関係のないシナリオ コンポーネント (たとえばブラウザーベースの検証またはデータ バンクなど) はこのビューに表示されないことに注意してください。
- 自動でテストの構成および検証を行うための Load Test エクスプローラーの右クリック メニュー (ツールバー ボタンと同じコマンドがあります)。
- Load Test エクスプローラーでテストをダブルクリックすると表示される、負荷テスト用の構成パネル。
Anchor | ||||
---|---|---|---|---|
|
テストを構成する理由
負荷テストは、ブラウザー テストが使用するリクエストのセットを受け取り、それらの結果をブラウザーのコンテキストの外で送信します。ブラウザーのリクエストをブラウザーの外で再度サブミットすると、リクエストが無効になる場合があります。たとえば、リクエストにセッション ID などのセッション依存の値が含まれている場合などです。そのような場合に構成が必要です。構成を容易にするため、SOAtest はこのような問題を検出し、ブラウザーなしの負荷テスト環境で実行できるようにリクエストを自動的に構成します。
...
- 動的なパラメーター (セッション ID など) を検出するために、テストを 2 回実行します。
- Text Data Bank をセットアップして動的なリクエストパラメーターの有効な値を抽出します (前のテストから抽出した値や前のレスポンスの値を現在のテストで使用するなど)。Text Data Bank ツールの詳細については、「Text Data Bank」を参照してください。
- 動的パラメーターに対して、抽出された適切な値を使用するよう構成します。リクエストは適切なテストと共に保存されており、下記の「SOAtest が構成したリクエストの参照と変更方法」で説明されている方法に従ってアクセスできます。
以下のどちらかの場合に構成が必要です。
- 負荷テストの検証が成功しなかった場合。
- アプリケーションが変更され、既存の負荷テスト構成がアプリケーションの機能に一致しなくなった場合。
テストの構成方法
Warning | ||
---|---|---|
| ||
構成を行うと、アプリケーションの既存の状態に基づく既存の負荷テストリクエストがすべて再作成されます。結果として、SOAtest でセットアップした既存の負荷テスト構成 (たとえば、パラメータライズされた値やスクリプトの値を使用して設定するよう手動で構成された URL またはリクエスト ボディなど) が上書きされます。 |
...
- Load Test エクスプローラーで構成対象のテスト スイートを選択します。
- [負荷テスト用に構成] ボタンをクリックするか、テスト スイートを右クリックしてショートカット メニューの [負荷テスト用に構成] をクリックします。
次に、「テストの検証」の説明に従ってテストを検証します。
Anchor | ||||
---|---|---|---|---|
|
(Load Test パースペクティブの) Load Test エクスプローラーで Browser Playback ツールをダブルクリックすると、特別な構成パネルが表示され、テストで送信される予定のリクエストを参照できます。URL、HTTP メソッド、およびリクエスト ボディが表示され、必要に応じてそれらを変更できます。構成パネルの右側に表示されるコントロールを使用して、リクエストを追加および削除することもできます。
...
パラメータライズされた値の詳細については、「Parameterizing Tests with Data Sources, Variables, or Values from Other Tests」を参照してください。
スクリプト値の詳細については「スクリプトを使用した拡張機能の基礎Extensibility or Scripting Basics」を参照してください。
固定値では、
${var_name}
という構文を使用してデータ ソースの値にアクセスできます。 定義済みの環境変数を使用することもできます。環境の詳細については、「」を参照してください。 Configuring Testing in Different Environments
Anchor | ||||
---|---|---|---|---|
|
リクエストの一部として動的な値を使用する場合、データ ソースの値または別のテストから抽出した値でリクエストをパラメータライズできます。カスタム スクリプトが返す値や固定値も使用できます。
...
- (Load Test パースペクティブの) Load Test エクスプローラーでテストをダブルクリックし、構成パネルを開きます。
- 値をパラメータライズするリクエストを選択します。
- リクエストのパラメータライズする部分に応じて [URL] または [リクエスト ボディ] タブのどちらかで、パラメータライズするテキストをハイライトします。
- [選択したテキストをパラメータライズ] をクリックします。
- ダイアログが開いたら、パラメータライズされた値の名前を指定します。[URL] または [リクエスト ボディ] タブの実際の値が変数への参照に置き換えられ、テスト構成パネル下部の [パラメータライズされた値] エリアに変数のエントリが追加されます。
- 固定値を使用するよう変数を構成するには、[値] フィールドで [固定] を選択し、右隣のボックスに値を指定します。
- データ ソースに格納された値または別のテストから抽出された値を使用するよう変数を構成するには、[値] フィールドで [パラメータライズ] を選択し、右隣のボックスで適切なデータ ソース列を選択します。テストのパラメータライズの詳細については、「Parameterizing Tests with Data Sources, Variables, or Values from Other Tests」を参照してくださ い。
- カスタム スクリプトの結果を使用するよう変数を構成するには、[値] フィールドで [スクリプト] を選択し、[スクリプトの編集] をクリックしてスクリプトの詳細を記述します。カスタムスクリプトの使用の詳細については、「スクリプトを使用した拡張機能の基礎Extensibility or Scripting Basics」を参照してくださ い。
- パラメータライズされたテキストをより大きな値 (URL またはリクエスト ボディ) の一部として挿入する前に URL エンコーディングを適用するには、[URL エンコード値] オプションが有効化されていることを確認します。
...
機能テストが既にパラメータライズされた値を使用するよう構成されている場合、構成処理を行うと、パラメータライズされた値が負荷テストでも使用されるようにテストがセットアップされます。
テストコンフィギュレーション中に起きていること
[負荷テスト用に構成] 処理を実行中に、SOAtest はテストスイートを 2 回実行し、3 種類の自動構成を行います。
- 機能テストシナリオで既にデータソースの値を使用するよう設定されている HTTP リクエストは、同じデータソースの値を負荷テストコンフィギュレーションでも使用するように自動構成します。
下の図は、HTTP リクエストの username および password パラメーターを、既に機能テストで構成されたのと同じデータ ソースの値を使用するようにパラメータライズした例です。
password パラメーターが Login Values データ ソースの Password 列の値を使用するよう構成されていることに注目してください。 - HTTP リクエスト内の動的なパラメーターの値 (セッション ID など) を、現在のセッションで更新された値を使用するよう構成します。
SOAtest は、HTTP レスポンスに Text Data Bank ツールを作成し、動的な値を格納することでこれを実現します。このデータ バンクの値は、後に適切な HTTP リクエストで使用されます。
たとえば次の例では、Test 2 に Text Data Bank が追加されています。
qid という列に値が抽出されていることに注目してください。テキストの左右の境界は自動構成されています。
HTTP リクエストの 1 つは、抽出された値を使用するように構成されます。
Text Data Bank ツールの詳細については、「Text Data Bank」を参照してください。 - 機能テストで抽出されていたのと同じデータ バンクの値を抽出するようシナリオを構成します。
このように構成することで、値が Web/SOA 混合負荷テストシナリオの他のツールで使用できるようになります。
たとえば、Test 2: Click “Google Search” に Browser Data Bank があり、“Extracted: bookName” という列を抽出しているとします。 SOAtest は同じ値を含む HTTP レスポンスを検出し、値を同じ名前の列 (“Extracted: bookName”) に抽出する Text Data Bank を追加します。この値は、次の図のように後で SOAP Client によって使用されます。
Anchor | ||||
---|---|---|---|---|
|
テストを検証する理由
テストの検証を行うと、SOAtest はテストを負荷テストモードで実行し、正しく構成されていないHTTP リクエストなど、負荷テストに影響を与える可能性がある未解決の問題をレポートします。これによって、実際に負荷テストを開始する前に問題を解決することができます。
テストの検証方法
テストを自動的に検証するには、次の操作を行います。
...
潜在的な問題が検出された場合、このテスト スイートを負荷テストで実行するには、n 個の問題を解決する必要があるというメッセージがレポートされます。レポートされた問題は [品質タスク] ビューで確認できます。
ブラウザーで描画されたテスト ステップの参照方法
各テスト ステップで何が起きているかをより明確に判断するため、負荷テストをブラウザーで描画した内容を表示できます。それには、関連するテストに追加されたブラウザー コンテンツ ビューアーをダブルクリックします。
この機能は、テストが期待される結果を生成していない理由を視覚的に確認したい場合に特に便利です。たとえば、描画されたページから、ログインが正しく行われていないことがわかるかもしれません。エラー メッセージの確認と合わせてこのツールを使用すると、問題の原因を突き止め、解決するのに役立ちます。
検証対象
検証を実行中、SOAtest はシナリオに対して構成を行う必要があるかどうか (SOAtest による自動構成または手動での構成で) を確認します。 検証が成功しなかった場合、自動構成を実行する必要があることを表しているか、あるいは既に自動構成を実行済みの場合は手動でパラメーターを構成する必要があることを表しています。
問題がレポートされた場合
[負荷テスト用に構成] の実行によって動的パラメーターを正しく自動構成できなかった場合、以下のいずれか、または両方の状況が発生します。
...
このような問題が発生した場合、[負荷テスト用に構成] を実行してください。 既に [負荷テスト用に構成] を実行したにもかかわらず、依然としてエラーがレポートされる場合、問題の原因になっている HTTP リクエストおよびパラメーターのどちらか、または両方を手動で構成する必要があるでしょう。
手動でパラメーターを設定する場合
SOAtest が自動では構成できない動的パラメーター値の種類があります。それは、通常はブラウザーで JavaScript によって構築または変換される値です。 (変換された) パラメーター値が HTTP レスポンスには存在しないため、SOAtest はそれらの値を抽出して HTTP リクエストの必要な個所で使うことができません。
これらのパラメーターは、手動で構成する必要があります。この種の動的パラメーターがあり、セッションごとに Web アプリケーションを更新する必要がある場合、検証によって問題がレポートされます。
手動でパラメーターを設定する方法
「リクエスト値のパラメータライズやスクリプトの書き方」で説明されている手順に従います。
次の図は、現在時刻をパラメーターとしてサーバーに渡すサンプルです。 これは動的なパラメーターであり、JavaScript によって値が生成されるため、それまでの HTTP レスポンスには値が存在していません。 そのため、現在時刻を計算して返すスクリプトを使用してパラメータライズするよう手動で構成されています。
Web 負荷テストのヒント
- Web 負荷テストは、テキストでレスポンスが返されるリクエストに特化しています。画像などのバイナリ ファイル、flash ファイル、JavaScript、CSS などは送信しません。これによって、すべてがユーザーのマシンでキャッシュされたモードをシミュレートし、リピート訪問者/既存ユーザーにとって正確なレスポンス時間を提供します。
- Web 負荷テストのリクエストは、テスト スイートの [ブラウザー再生オプション] タブで指定されたブラウザーをシミュレートします。適切なヘッダーコンテンツ (User-Agent および Accept) によってブラウザータイプのシミュレーションが行われます。
- アプリケーションがベーシック認証または NTLM 認証を要求する場合、テストスイートの [ブラウザー再生オプション] タブで指定された設定が Web 負荷テストにも適用されます。
ブラウザー テストを構成して Binary データを送信
前述のとおり、Web シナリオを負荷テストする場合、ブラウザーは使用されません。Load Test は、ブラウザーでのユーザー アクションの結果をシミュレートする一連のリクエストを送信します。そのため、ブラウザー リクエストでバイナリ データを送信する場合、Load Test がコンテンツをテキストとして送信しないようにテストを構成する必要がありますよくあるケースとして、Web ページを経由してバイナリ ファイルをサブミットする場合があります。
シナリオを記録した後、まず [負荷テスト用に構成] を使用してシナリオを実行します (「テストの構成」を参照)。これによって、負荷テスト中にリクエストを送信するために必要な動的パラメーターを備えたシナリオが構成されます。
...
これで、Load test でシナリオを実行するか、SOAtest で [Validate for Load Test] テスト コンフィギュレーションを使用してシナリオを実行したとき、PDF ファイルのコンテンツがバイナリ データとして送信されるようになりました。
ブラウザー テストを構成してカスタム ヘッダーを追加
サーバーが受信するすべてのリクエストに特定の HTTP ヘッダーが存在することを期待しているが、そのヘッダーが実際には存在しないために [負荷テスト用に検証] が失敗する場合があります。そのような場合、Web ブラウザー負荷テストの実行中にリクエストと共に送信されるグローバルなカスタム HTTP ヘッダーを追加できます。
...
このサンプルは、簡易性のために Jython を使用していますが、この Extension ツールは負荷テストのコンテキストで使用されるため、Java でスクリプトを定義するほうがパフォーマンスが高いことに注意してください。
Web 負荷テストで GWT アプリケーションをサポート
Google Web Toolkit アプリケーションは、クロスサイト リクエスト フォージェリ (XSRF) として知られるセキュリティの問題を防ぐため、すべての HTTP リクエストにカスタム HTTP ヘッダーを追加する場合があります。 たとえば、smart-gwt toolkit を使用するアプリケーションなどでこの処理が行われます。GWT の JavaScript ライブラリによって、X-GWT-Permutation
と呼ばれるカスタム ヘッダーがリクエストに追加されます。
...