このセクションの内容:
はじめに
Parasoft WebSocket Transport Extension は、SOAtestのメッセージクライアントツールに適切なWebSocketトランスポートのサービスを追加します。WebSocket を介して送られるメッセージを設定、送信、検証するときに、SOAtest の豊かなインターフェイスをフルに活用できます。WebSocket Transport Extension は、RFC 6455 規格に従って、WS または WSS プロトコルを介して送られるメッセージをサポートします。
前提条件
- SOAtest 9.10.0 以降
- Oracle Java 8
インストール
MQTT Extensions は UI またはコマンドラインからインストールできます。
UI からのインストール
- [Parasoft] > [設定] を選択します。
- [システム プロパティ] ページで [JAR の追加] をクリックします。
- 表示されたファイル選択ダイアログで websockettransport.jar を選択します。
- [適用] をクリックし、SOAtest を再起動します。
コマンドラインからのインストール
設定プロパティ ファイルで、system.properties.classpath プロパティに websockettransport.jar ファイルを追加します。例:
system.properties.classpath=<path to jar>/websockettransport.jar
使用方法
WebSocket Transport は、以下のツールで使用します。
設定は[トランスポート] タブで行います。WebSocket Transport を使用するには、[トランスポート] ドロップダウンメニューから [WebSocket] を選択し、オプションを設定します(「オプションの設定」を参照)。
オプションの設定
以下のオプションを設定できます。
接続の設定
URI | アクセスするURI を指定します。プロトコル(ws:// または wss://) を含めます。 これは新しい接続を作成するために必要です。初期接続を作成したら、接続ID を使ってどの接続を使用するかを制御できます。 |
---|---|
Connection ID | 複数の接続をテストしている場合、接続 ID を指定します。接続 ID には任意の文字列を使用できます。 URI と同時にすでにオープンしている接続 ID を指定した場合、URI は無視されます。 テスト スイートで1 つの接続だけを使用している場合、接続ID を指定する必要はありません。SOAtest は接続 ID にデフォルト値 ( ただし、同じシナリオで複数の接続をオープンしてメッセージを送受信したい場合、接続ごとに固有の接続 ID を指定する必要があります。 デフォルト: |
Mode | WebSocket Transport のメッセージモードを指定します。以下のモードを指定できます。
デフォルト: |
Frame Type | メッセージのフレームタイプを指定します。 WebSocket プロトコルは、データフレームを使ってペイロードを送信します。データフレームはテキストタイプまたはバイナリタイプで設定していなければなりません。バイナリメッセージを送信する場合を除き、すべてのケースでデフォルト値(text) を使用してください。バイナリメッセージの場合はbinary を使用してください。 https://tools.ietf.org/html/rfc6455#section-5.6 を参照。 デフォルト: |
Connection Timeout | 接続の確立を待機するタイムアウト時間をミリ秒で指定します。 デフォルト: |
Log Level | コンソールと[モニターの開始] ビューに表示する情報の量を指定します。以下のレベルを指定できます。
デフォルト: |
HTTP ヘッダーの設定
WebSocket の接続がオープンされた際、HTTP Upgrade リクエストであるopening ハンドシェイクが存在します。このセクションでは、このHTTP Upgrade リクエストとして送るべきHTTP ヘッダーを設定します(https://tools.ietf.org/html/rfc6455#section-1.3 を参照)。
最大で10 までの HTTP ヘッダーを設定できます。ヘッダーはname:value の形式で設定します。 例:User-Agent:Mozilla/5.0
受信メッセージの処理
SOAtest が接続をオープンすると、WebSocket Transport はサーバーからのすべての受信メッセージをリッスンし、内部キューに追加します。receive
または sendAndReceive
モードの場合、WebSocket Transport は Message Selector 設定の指定に一致するメッセージを探します。内部キューが最初にチェックされます。一致するメッセージがあった場合、そのメッセージをレスポンス メッセージとしてTraffic Viewer に送ります。また、そのメッセージはクライアント ツールのレスポンス出力に連結されたツールにも送られます。一致するメッセージが内部キューに存在しない場合、WebSocket Transport は Message Selector 設定の指定に一致する、サーバーからのメッセージを待機します。指定のタイムアウト時間内にメッセージが受信されない場合は、エラー メッセージをレポートします。
SOAtest が接続をクローズするまで、メッセージは内部キューに残ります。サーバーが接続をクローズする場合、接続をクローズする直前にサーバーがクライアントに送信した可能性のあるメッセージをユーザーが検証できるよう、メッセージは内部キューに残り続けます。
Message Selector | どの受信メッセージをWebSocket Transport が処理するかを選択するXPath を指定します。XPath は、以下の形式でメッセージのノードとその値を選択しなければなりません。xpath=value (例: XPath の and 演算子を使って、メッセージから複数のノードを選択することもできます。例: XPath がBoolean 型の デフォルト: |
---|---|
Message Format | Message Selector で照合する受信メッセージの形式( XML、JSON など) を指定します。このフィールドを指定する必要があるのは、期待されるメッセージがXML またはJSON 形式ではなく、Message Selector の値を指定している場合だけです。 デフォルトでは、WebSocket Transport は自動的にXML またはJSON 形式を検出します。メッセージが別の形式の場合、このフィールドで形式を指定する必要があります。 指定する形式は、XML Converter に表示される形式名、あるいはカスタムメッセージ形式で定義された型式名に一致させてください。Message Format を指定すると、指定したメッセージ形式のデフォルトの変換オプションに基づいて、SOAtest はメッセージをXML に変換します。 Default: |
Timeout | 受信メッセージを待機するタイムアウト時間をミリ秒で指定します。 デフォルト: |
サンプル事例
内部キューとMessage Selector は、特定の順序でサーバーから受信したメッセージの依存関係を取り除きます。また、サーバーから受信したメッセージについて、クライアントが必ずリッスンしていることを保証する必要もありません。
たとえば、異なる 2 つのメッセージをサーバーが期待する場合、メッセージの受信順序に関係なく、「メッセージが受信されたこと」および「その内容が正しいこと」を検証できます。この例であれば、それぞれのメッセージに一致するXPath を使って2 つのクライアント ツールを設定します。
2 番目のツールが一致するよう設定したメッセージが、1 番目に期待されるメッセージよりも先に到着した場合、2 番目のメッセージはキューに追加されます。1 番目のツールが一致するよう設定したメッセージは、到着時に処理されます。その後、2 番目のツールはすでにキューにあるメッセージを処理できます。
接続の管理設定
[Keep connection alive] または[Close connection after test execution] オプションのいずれかを有効化できます。WebSocket Transport は、複数のアクティブな接続の使用を許可します。
すでにオープンしている接続の ID に接続 ID が一致する場合、その接続は再利用されます。クローズした接続の ID 、あるいは接続のオープンに一度も使用されていない接続の ID に接続 ID が一致する場合、新しい接続が作成されます。
[Keep connection alive] が有効な場合、テスト実行の最後にSOAtest は接続に対してclose() を呼び出しません。[Close connection after test execution] が有効な場合、テスト実行の最後にSOAtest は接続をクローズします。ビルトイン トランスポートと異なり、カスタム トランスポートの場合、実行の完了時にオープンしている接続のクリーンアップは行われません。そのため、接続の最後のテストについて [ Close connection after text execution] を有効化するべきです。有効化しない場合、接続はオープンのままになります。
サンプル シナリオ
以下のシナリオでは、テスト実行が終わった後、両方の接続がオープンのままになります。
- Connection A (キープアライブ)
- Connection B (キープアライブ)
- Connection A (キープアライブ)
- Connection B (キープアライブ)
これを解決するには、特定の接続を使用する最後のテストについて[Close Connection after test execution] を有効化します。
- Connection A (キープアライブ)
- Connection B (キープアライブ)
- Connection A (接続クローズ)
- Connection B (接続クローズ)
負荷テストでの注意事項
共有の WebSocket 接続をオープンするクライアントに対して負荷テストを実行する際、親テストスイートで、[実行オプション] の [グループとしてテストを実行] オプションを有効化するべきです。このオプションは、各仮想ユーザーがシナリオ全体を実行できるようにします。それによって、各仮想ユーザーは自身の WebSocket 接続を作成および再利用できます。[グループとしてテストを実行] ではなく [個別にテストを実行可能] が有効な場合は、接続を共有することなく、各仮想ユーザーはそれぞれ独立してテスト スイートのテストのうちの1 つのテストを実行します。
サード パーティのコンテンツ
この拡張機能は、以下のサード パーティのコンテンツを含みます。
- Saxon HE (Mozilla Public License 2.0)
- JCS Core (Apache License 2.0)
- SLF4J (MIT License)
- Tyrus (CDDL1.1 and GPL 2.0 with Classpath Exception)
その他のライセンスの詳細については、プラグインの licenses フォルダーを参照してください。