SOAtest の Web シナリオ (ブラウザーからの記録で自動生成されたテストや、手動で作成された Browser Playback ツールのテストを含みます) は、ブラウザーで実行するよう設計されています。負荷テストはブラウザーでは実行されないため、サーバーにリクエストを送信することによって Web テストを行う負荷テスト環境で Web 機能テストを再利用するには、いくつかのオプションを構成する必要があります。
Parasoft SOAtest は、ブラウザーベースの機能テストを自動的に負荷テスト用に構成します。また、それらのテストをシミュレートされた負荷テスト環境で実行して、テストを検証します。これによって、意味のある Web 負荷テストを作成するために必要なセットアップ作業を大幅に減らし、実際に負荷テストを始める前に潜在的な負荷テストの問題を検出し、解決するのに役立ちます。
このセクションでは、Web シナリオを負荷テスト用に準備する方法について説明します。セクションの内容:
推奨される手順は、「テストの構成」の説明に従ってテストを負荷テスト向けに構成し、次に「テストの検証」の説明に従ってテストが適切に動作しているか検証することです。
ただし、構成のステップを行わない場合 (既にテストが構成済みであり、追加した手動の構成を上書きしたくない場合など)、検証ステップに合格する限り、構成は必須ではありません。
Load Test パースペクティブは、Web シナリオを負荷テスト用に準備するのに役に立つよう設計されています。Load Test パースペクティブを開くには、次の操作を行います。
このパースペクティブは、SOAtest パースペクティブと似ていますが、以下の機能が加わっています。
負荷テストは、ブラウザー テストが使用するリクエストのセットを受け取り、それらの結果をブラウザーのコンテキストの外で送信します。ブラウザーのリクエストをブラウザーの外で再度サブミットすると、リクエストが無効になる場合があります。たとえば、リクエストにセッション ID などのセッション依存の値が含まれている場合などです。そのような場合に構成が必要です。構成を容易にするため、SOAtest はこのような問題を検出し、ブラウザーなしの負荷テスト環境で実行できるようにリクエストを自動的に構成します。
構成モードでは、SOAtest は次の処理を行います。
以下のどちらかの場合に構成が必要です。
構成を行うと、アプリケーションの既存の状態に基づく既存の負荷テストリクエストがすべて再作成されます。結果として、SOAtest でセットアップした既存の負荷テスト構成 (たとえば、パラメータライズされた値やスクリプトの値を使用して設定するよう手動で構成された URL またはリクエスト ボディなど) が上書きされます。 |
自動で構成を実行するには、次の操作を行います。
次に、「テストの検証」の説明に従ってテストを検証します。
(Load Test パースペクティブの) Load Test エクスプローラーで Browser Playback ツールをダブルクリックすると、特別な構成パネルが表示され、テストで送信される予定のリクエストを参照できます。URL、HTTP メソッド、およびリクエスト ボディが表示され、必要に応じてそれらを変更できます。構成パネルの右側に表示されるコントロールを使用して、リクエストを追加および削除することもできます。
呼び出すメソッドは、固定値、パラメータライズされた値、またはスクリプト値として指定できることに注意してください。
パラメータライズされた値の詳細については、「テストのパラメータライズ (データ ソース、変数、または他のテストの値を使用)」を参照してください。
スクリプト値の詳細については、「スクリプトを使用した拡張機能の基礎」を参照してください。
固定値では、${var_name} という構文を使用してデータ ソースの値にアクセスできます。 定義済みの環境変数を使用することもできます。環境の詳細については、「」を参照してください。 異なる環境でのテスト構成
リクエストの一部として動的な値を使用する場合、データ ソースの値または別のテストから抽出した値でリクエストをパラメータライズできます。カスタム スクリプトが返す値や固定値も使用できます。
次の操作を行います。
機能テストが既にパラメータライズされた値を使用するよう構成されている場合、構成処理を行うと、パラメータライズされた値が負荷テストでも使用されるようにテストがセットアップされます。
[負荷テスト用に構成] 処理を実行中に、SOAtest はテストスイートを 2 回実行し、3 種類の自動構成を行います。
テストの検証を行うと、SOAtest はテストを負荷テストモードで実行し、正しく構成されていないHTTP リクエストなど、負荷テストに影響を与える可能性がある未解決の問題をレポートします。これによって、実際に負荷テストを開始する前に問題を解決することができます。
テストを自動的に検証するには、次の操作を行います。
検証が成功した場合、テスト スイートは負荷テストで使用する準備ができているというメッセージが [負荷テスト用に検証] タブにレポートされます。
潜在的な問題が検出された場合、このテスト スイートを負荷テストで実行するには、n 個の問題を解決する必要があるというメッセージがレポートされます。レポートされた問題は [品質タスク] ビューで確認できます。
各テスト ステップで何が起きているかをより明確に判断するため、負荷テストをブラウザーで描画した内容を表示できます。それには、関連するテストに追加されたブラウザー コンテンツ ビューアーをダブルクリックします。
この機能は、テストが期待される結果を生成していない理由を視覚的に確認したい場合に特に便利です。たとえば、描画されたページから、ログインが正しく行われていないことがわかるかもしれません。エラー メッセージの確認と合わせてこのツールを使用すると、問題の原因を突き止め、解決するのに役立ちます。
検証を実行中、SOAtest はシナリオに対して構成を行う必要があるかどうか (SOAtest による自動構成または手動での構成で) を確認します。 検証が成功しなかった場合、自動構成を実行する必要があることを表しているか、あるいは既に自動構成を実行済みの場合は手動でパラメーターを構成する必要があることを表しています。
[負荷テスト用に構成] の実行によって動的パラメーターを正しく自動構成できなかった場合、以下のいずれか、または両方の状況が発生します。
このような問題が発生した場合、[負荷テスト用に構成] を実行してください。 既に [負荷テスト用に構成] を実行したにもかかわらず、依然としてエラーがレポートされる場合、問題の原因になっている HTTP リクエストおよびパラメーターのどちらか、または両方を手動で構成する必要があるでしょう。
SOAtest が自動では構成できない動的パラメーター値の種類があります。それは、通常はブラウザーで JavaScript によって構築または変換される値です。 (変換された) パラメーター値が HTTP レスポンスには存在しないため、SOAtest はそれらの値を抽出して HTTP リクエストの必要な個所で使うことができません。
これらのパラメーターは、手動で構成する必要があります。この種の動的パラメーターがあり、セッションごとに Web アプリケーションを更新する必要がある場合、検証によって問題がレポートされます。
「リクエスト値のパラメータライズやスクリプトの書き方」で説明されている手順に従います。
次の図は、現在時刻をパラメーターとしてサーバーに渡すサンプルです。 これは動的なパラメーターであり、JavaScript によって値が生成されるため、それまでの HTTP レスポンスには値が存在していません。 そのため、現在時刻を計算して返すスクリプトを使用してパラメータライズするよう手動で構成されています。
前述のとおり、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-- |
このサンプルを構成するには、次の操作を行います。
テストの [リクエスト ボディ] タブでファイルのコンテンツをハイライトし、[選択したテキストをパラメータライズ] をクリックします。
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 でスクリプトを定義するほうがパフォーマンスが高いことに注意してください。
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