SOAtest の Web シナリオ (ブラウザーからの記録で自動生成されたテストや、手動で作成された Browser Playback ツールのテストを含みます) は、ブラウザーで実行するよう設計されています。負荷テストはブラウザーでは実行されないため、サーバーにリクエストを送信することによって Web テストを行う負荷テスト環境で Web 機能テストを再利用するには、いくつかのオプションを構成する必要があります。

Parasoft SOAtest は、ブラウザーベースの機能テストを自動的に負荷テスト用に構成します。また、それらのテストをシミュレートされた負荷テスト環境で実行して、テストを検証します。これによって、意味のある Web 負荷テストを作成するために必要なセットアップ作業を大幅に減らし、実際に負荷テストを始める前に潜在的な負荷テストの問題を検出し、解決するのに役立ちます。

このセクションでは、Web シナリオを負荷テスト用に準備する方法について説明します。セクションの内容:

推奨する準備手順

推奨される手順は、「テストの構成」の説明に従ってテストを負荷テスト向けに構成し、次に「テストの検証」の説明に従ってテストが適切に動作しているか検証することです。

ただし、構成のステップを行わない場合 (既にテストが構成済みであり、追加した手動の構成を上書きしたくない場合など)、検証ステップに合格する限り、構成は必須ではありません。

Load Test パースペクティブの開き方

Load Test パースペクティブは、Web シナリオを負荷テスト用に準備するのに役に立つよう設計されています。Load Test パースペクティブを開くには、次の操作を行います。

[ウィンドウ] メニューの [パースペクティブ] > [パースペクティブを開く] > [Parasoft Load Test] をクリックします。

このパースペクティブは、SOAtest パースペクティブと似ていますが、以下の機能が加わっています。

自動でテストの構成と検証を行うための 2 つのツールバーボタン ([負荷テスト用に構成] および [負荷テスト用に検証])。また、Load Test を開始するツールボタン。
利用可能な Web シナリオを表示する Load Test エクスプローラー。負荷テストに関係のないシナリオコンポーネント (たとえばブラウザーベースの検証またはデータバンクなど) はこのビューに表示されないことに注意してください。
自動でテストの構成および検証を行うための Load Test エクスプローラーの右クリックメニュー (ツールバーボタンと同じコマンドがあります)。
Load Test エクスプローラーでテストをダブルクリックすると表示される、負荷テスト用の構成パネル。

テストの構成

テストを構成する理由

負荷テストは、ブラウザーテストが使用するリクエストのセットを受け取り、それらの結果をブラウザーのコンテキストの外で送信します。ブラウザーのリクエストをブラウザーの外で再度サブミットすると、リクエストが無効になる場合があります。たとえば、リクエストにセッション ID などのセッション依存の値が含まれている場合などです。そのような場合に構成が必要です。構成を容易にするため、SOAtest はこのような問題を検出し、ブラウザーなしの負荷テスト環境で実行できるようにリクエストを自動的に構成します。

構成モードでは、SOAtest は次の処理を行います。

動的なパラメーター (セッション ID など) を検出するために、テストを 2 回実行します。
Text Data Bank をセットアップして動的なリクエストパラメーターの有効な値を抽出します (前のテストから抽出した値や前のレスポンスの値を現在のテストで使用するなど)。Text Data Bank ツールの詳細については、「Text Data Bank」を参照してください。
動的パラメーターに対して、抽出された適切な値を使用するよう構成します。リクエストは適切なテストと共に保存されており、下記の「SOAtest が構成したリクエストの参照と変更方法」で説明されている方法に従ってアクセスできます。

以下のどちらかの場合に構成が必要です。

負荷テストの検証が成功しなかった場合。
アプリケーションが変更され、既存の負荷テスト構成がアプリケーションの機能に一致しなくなった場合。

テストの構成方法

警告

構成を行うと、アプリケーションの既存の状態に基づく既存の負荷テストリクエストがすべて再作成されます。結果として、SOAtest でセットアップした既存の負荷テスト構成 (たとえば、パラメータライズされた値やスクリプトの値を使用して設定するよう手動で構成された URL またはリクエストボディなど) が上書きされます。

自動で構成を実行するには、次の操作を行います。

Load Test エクスプローラーで構成対象のテストスイートを選択します。
[負荷テスト用に構成] ボタンをクリックするか、テストスイートを右クリックしてショートカットメニューの [負荷テスト用に構成] をクリックします。

次に、「テストの検証」の説明に従ってテストを検証します。

SOAtest が構成したリクエストの参照と変更方法

(Load Test パースペクティブの) Load Test エクスプローラーで Browser Playback ツールをダブルクリックすると、特別な構成パネルが表示され、テストで送信される予定のリクエストを参照できます。URL、HTTP メソッド、およびリクエストボディが表示され、必要に応じてそれらを変更できます。構成パネルの右側に表示されるコントロールを使用して、リクエストを追加および削除することもできます。

呼び出すメソッドは、固定値、パラメータライズされた値、またはスクリプト値として指定できることに注意してください。

パラメータライズされた値の詳細については、「テストのパラメータライズ (データソース、変数、または他のテストの値を使用)」を参照してください。
スクリプト値の詳細については、「スクリプトを使用した拡張機能の基礎」を参照してください。
固定値では、${var_name} という構文を使用してデータソースの値にアクセスできます。定義済みの環境変数を使用することもできます。環境の詳細については、「」を参照してください。異なる環境でのテスト構成

リクエスト値のパラメータライズやスクリプトの書き方

リクエストの一部として動的な値を使用する場合、データソースの値または別のテストから抽出した値でリクエストをパラメータライズできます。カスタムスクリプトが返す値や固定値も使用できます。

次の操作を行います。

(Load Test パースペクティブの) Load Test エクスプローラーでテストをダブルクリックし、構成パネルを開きます。
値をパラメータライズするリクエストを選択します。
リクエストのパラメータライズする部分に応じて [URL] または [リクエストボディ] タブのどちらかで、パラメータライズするテキストをハイライトします。
[選択したテキストをパラメータライズ] をクリックします。
ダイアログが開いたら、パラメータライズされた値の名前を指定します。[URL] または [リクエストボディ] タブの実際の値が変数への参照に置き換えられ、テスト構成パネル下部の [パラメータライズされた値] エリアに変数のエントリが追加されます。
固定値を使用するよう変数を構成するには、[値] フィールドで [固定] を選択し、右隣のボックスに値を指定します。
データソースに格納された値または別のテストから抽出された値を使用するよう変数を構成するには、[値] フィールドで [パラメータライズ] を選択し、右隣のボックスで適切なデータソース列を選択します。テストのパラメータライズの詳細については、「テストのパラメータライズ (データソース、変数、または他のテストの値を使用)」を参照してください。
カスタムスクリプトの結果を使用するよう変数を構成するには、[値] フィールドで [スクリプト] を選択し、[スクリプトの編集] をクリックしてスクリプトの詳細を記述します。カスタムスクリプトの使用の詳細については、「スクリプトを使用した拡張機能の基礎」を参照してください。
パラメータライズされたテキストをより大きな値 (URL またはリクエストボディ) の一部として挿入する前に URL エンコーディングを適用するには、[URL エンコード値] オプションが有効化されていることを確認します。

- [負荷テスト用に構成] を実行し、SOAtest が動的な値またはデータソースの値によるパラメータライズを自動的に行う場合、このオプションの値はコンテキストに応じて適切に設定されます。
  - パラメータライズされた値が URL の一部になる場合、[負荷テスト用に構成] を実行すると、このオプションは自動的に有効化されます。
  - パラメータライズされた値がリクエストボディの一部になる場合、[ 負荷テスト用に構成] を実行すると、通常、このオプションは自動的には有効化されません。ただし、リクエストボディの Content-Type が "application/xwww-form-urlencoded" である場合、このオプションは自動的に有効化されます。Content-Type が "multipart/form-data" の場合、SOAtest は値を自動的には 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 によって使用されます。

テストの検証

テストを検証する理由

テストの検証を行うと、SOAtest はテストを負荷テストモードで実行し、正しく構成されていないHTTP リクエストなど、負荷テストに影響を与える可能性がある未解決の問題をレポートします。これによって、実際に負荷テストを開始する前に問題を解決することができます。

テストの検証方法

テストを自動的に検証するには、次の操作を行います。

Load Test エクスプローラーで検証対象のテストスイートを選択します。
[負荷テスト用に検証] ボタンをクリックするか、テストスイートを右クリックしてショートカットメニューの [負荷テスト用に検証] をクリックします。

検証が成功した場合、テストスイートは負荷テストで使用する準備ができているというメッセージが [負荷テスト用に検証] タブにレポートされます。

潜在的な問題が検出された場合、このテストスイートを負荷テストで実行するには、n 個の問題を解決する必要があるというメッセージがレポートされます。レポートされた問題は [品質タスク] ビューで確認できます。

ブラウザーで描画されたテストステップの参照方法

各テストステップで何が起きているかをより明確に判断するため、負荷テストをブラウザーで描画した内容を表示できます。それには、関連するテストに追加されたブラウザーコンテンツビューアーをダブルクリックします。

この機能は、テストが期待される結果を生成していない理由を視覚的に確認したい場合に特に便利です。たとえば、描画されたページから、ログインが正しく行われていないことがわかるかもしれません。エラーメッセージの確認と合わせてこのツールを使用すると、問題の原因を突き止め、解決するのに役立ちます。

検証対象

検証を実行中、SOAtest はシナリオに対して構成を行う必要があるかどうか (SOAtest による自動構成または手動での構成で) を確認します。検証が成功しなかった場合、自動構成を実行する必要があることを表しているか、あるいは既に自動構成を実行済みの場合は手動でパラメーターを構成する必要があることを表しています。

問題がレポートされた場合

[負荷テスト用に構成] の実行によって動的パラメーターを正しく自動構成できなかった場合、以下のいずれか、または両方の状況が発生します。

[負荷テスト用に構成] によってエラーがレポートされます。以下は、レポートされる可能性があるエラーとその意味です。
1. HTTP のエラーコード (404 - Not Found または 401 - Not Authorized など)。これは、HTTP リクエストに不適切な動的パラメーター値があるか、またはその他の構成の問題があることを表しています。
2. 「ユーザーアクションを実行できません」または「検証または抽出できません」といった機能テストエラー。これらのエラーは、失敗したテストで指定されているページ要素が見つからないために発生します。通常、ページ要素が見つからない理由は、HTTP レスポンスに予期しないデータが含まれていることです。また、HTTP リクエストに不適切な動的パラメーター値があるか、またはその他の構成の問題がある場合にも、このエラーが発生する可能性があります。
誤った動的パラメーターが使用された時点で、ブラウザーコンテンツビューアーに正しくないページまたは予期しないページが表示されます。

このような問題が発生した場合、[負荷テスト用に構成] を実行してください。既に [負荷テスト用に構成] を実行したにもかかわらず、依然としてエラーがレポートされる場合、問題の原因になっている 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 ページを経由してバイナリファイルをサブミットする場合があります。

シナリオを記録した後、まず [負荷テスト用に構成] を使用してシナリオを実行します (「テストの構成」を参照)。これによって、負荷テスト中にリクエストを送信するために必要な動的パラメーターを備えたシナリオが構成されます。

たとえば、PDF バイナリファイルをアップロードするとします。通常、Web ページからファイルがサブミットされ、リクエストは "multipart/form-data" という Content-Type を使用し、リクエストボディは次のようになります。

 -----------------------------7d9271373005fa 
Content-Disposition: form-data; name="comment1"
first comment
-----------------------------7d9271373005fa
Content-Disposition: form-data; name="binaryFile"; filename="binary.pdf" Content-Type: application/pdf
the contents of the file
which will contain binary data if this is a PDF file
 -----------------------------7d9271373005fa 
Content-Disposition: form-data; name="comment2"
second comment
-----------------------------7d9271373005fa 
Content-Disposition: form-data; name="submit"
submit
-----------------------------7d9271373005fa--

このサンプルを構成するには、次の操作を行います。

SOAtest の Load Test パースペクティブで PDF ファイルをサブミットするテストを開きます。上のサンプルシナリオでは、Test 4: Click submit がそうです。
テストの [リクエストボディ] タブでファイルのコンテンツをハイライトし、[選択したテキストをパラメータライズ] をクリックします。
ファイルコンテンツがリクエストボディのテキストボックスに収まらない場合
PDF ファイルのサイズが大きい場合、リクエストボディを表すテキストボックスにコンテンツが収まらない可能性があります。その場合は、次の対応を行います。
1. 小さいファイルを使用するようシナリオを設定する。
2. [Configure for Load Test] テストコンフィギュレーションを実行します。
3. パラメータライズされた値を作成します。
4. 目的の PDF を使用するようシナリオを再設定します。
パラメータライズされた値に fileContents という名前を付け、[スクリプト] 値を使用します。
スクリプト値として、次の Jython コードを使用します (ユーザー環境でのバイナリファイルへのパスに変更します)。

from com.parasoft.api import IOUtil 
from java.io import File
def readBinaryFile(context):
     binaryFile = File("c:\\tmp\\binary.pdf")
     return IOUtil.readBinaryFile(binaryFile)

スクリプトの値は、byte[] 型の値を返す必要があります。これは Java の型です。Jython の配列を返すことはできません。ユーティリティメソッド IOUtil.readBinaryFile() を使用して byte[] 値を作成できます。Jython の jarray を返すこともできます (jarray オブジェクトの作成方法について詳しくは Jython のマニュアルを参照してください)。

リクエストボディでパラメータライズされた ${fileContents} 値を使用する必要があります。

-----------------------------7d9271373005fa
Content-Disposition: form-data; name="comment1"
first comment
-----------------------------7d9271373005fa
Content-Disposition: form-data; name="binaryFile"; filename="binary.pdf" Content-Type: application/pdf
${fileContents}
-----------------------------7d9271373005fa Content-Disposition: form-data; name="comment2"
second comment
-----------------------------7d9271373005fa Content-Disposition: form-data; name="submit"
submit
-----------------------------7d9271373005fa--

これで、Load test でシナリオを実行するか、SOAtest で [Validate for Load Test] テストコンフィギュレーションを使用してシナリオを実行したとき、PDF ファイルのコンテンツがバイナリデータとして送信されるようになりました。

ブラウザーテストを構成してカスタムヘッダーを追加

サーバーが受信するすべてのリクエストに特定の HTTP ヘッダーが存在することを期待しているが、そのヘッダーが実際には存在しないために [負荷テスト用に検証] が失敗する場合があります。そのような場合、Web ブラウザー負荷テストの実行中にリクエストと共に送信されるグローバルなカスタム HTTP ヘッダーを追加できます。

これを実現するには、ヘッダーを追加する必要があるシナリオのコンテキスト内の Extension ツールで BrowserTestUtil.addHttpHeader() メソッド (SOAtest のパブリック API にドキュメントがあります) を呼び出します。必ずヘッダーを追加するテストより前にこの Extension ツールを配置してください。Extension ツールの後に実行されるすべてのシナリオテストにヘッダーが追加されます。ヘッダーは、負荷テスト中にツールが送信するすべてのリクエストに付加されます。

複数のシナリオがある場合、各シナリオにこの Extension ツールを追加します。そのような場合、この Extension ツールをグローバルツールとして定義し、使用する各シナリオに追加することを推奨します。あるいは、この Extension ツールを含む .tst を作成し、参照 .tst ファイルとしてアクセスすることもできます。

次のコードは、ヘッダーを設定する Jython スクリプトのサンプルです。

from com.parasoft.api import *
def addHeader(x, context):
    BrowserTestUtil.addHttpHeader("HeaderName", "HeaderValue", context)

このサンプルは、簡易性のために Jython を使用していますが、この Extension ツールは負荷テストのコンテキストで使用されるため、Java でスクリプトを定義するほうがパフォーマンスが高いことに注意してください。

Web 負荷テストで GWT アプリケーションをサポート

Google Web Toolkit アプリケーションは、クロスサイトリクエストフォージェリ (XSRF) として知られるセキュリティの問題を防ぐため、すべての HTTP リクエストにカスタム HTTP ヘッダーを追加する場合があります。たとえば、smart-gwt toolkit を使用するアプリケーションなどでこの処理が行われます。GWT の JavaScript ライブラリによって、X-GWT-Permutation と呼ばれるカスタムヘッダーがリクエストに追加されます。

このような場合、GWT アプリケーションに対して [負荷テスト用に検証] を実行すると、500 - Internal Server Error のようなエラーが発生する可能性があります。サーバーサイドのログを確認すると、次のようなエラーが記録されています。

java.lang.SecurityException: Blocked request without GWT permutation header (XSRF attack?)

このエラーは、負荷テストのコンテキストでは JavaScript が実行されないため、JavaScript が実行されず、リクエストの一部として X-GWT-Permutation ヘッダーが設定されないために発生します。

この問題を解決するには、このヘッダーを追加する簡単なスクリプトを作成し、負荷テスト中にすべてのリクエストと共にヘッダーが送信されるようにします。ヘッダーがないために失敗しているシナリオの最初のテストの前に Extension ツールを追加します。

ヘッダーの名前: X-GWT-Permutation
ヘッダーの値: アプリケーションが設定する値を使用します。この値を確認するには、シナリオを機能テストとして実行し、トラフィックビューアーでヘッダーの値を確認します。

Page tree

負荷テスト用の機能テストの用意