このセクションの内容:

はじめに

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 からのインストール

  1. [Parasoft] > [設定] を選択します。
  2. [システム プロパティ] ページで [JAR の追加] をクリックします。
  3. 表示されたファイル選択ダイアログで websockettransport.jar を選択します。
  4. [適用] をクリックし、SOAtest を再起動します。

コマンドラインからのインストール

localsettings プロパティ ファイルの system.properties.classpath プロパティに websockettransport.jar を追加します。例:

system.properties.classpath=<path to jar>/websockettransport.jar

使用方法

WebSocket Transport は、以下のツールで使用します。

設定は[トランスポート] タブで行います。WebSocket Transport を使用するには、[トランスポート] ドロップダウンメニューから [WebSocket] を選択し、オプションを設定します(「Configuration Options」を参照)。

オプションの設定

以下のオプションを設定できます。

接続の設定

URI

アクセスするURI を指定します。プロトコル(ws:// または wss://) を含めます。

これは新しい接続を作成するために必要です。初期接続を作成したら、接続ID を使ってどの接続を使用するかを制御できます。

Connection ID

複数の接続をテストしている場合、接続 ID を指定します。接続 ID には任意の文字列を使用できます。

URI と同時にすでにオープンしている接続 ID を指定した場合、URI は無視されます。

テスト スイートで1 つの接続だけを使用している場合、接続ID を指定する必要はありません。SOAtest は接続 ID にデフォルト値(<default>) を使用します。

ただし、同じシナリオで複数の接続をオープンしてメッセージを送受信したい場合、接続ごとに固有の接続 ID を指定する必要があります。

デフォルト: <default>

Mode

WebSocket Transport のメッセージモードを指定します。以下のモードを指定できます。

send: WebSocket Transport はメッセージを送信しますが、サーバーからの受信メッセージを待機しません。

receive: [受信メッセージの処理] オプションで指定した条件に一致する受信メッセージをWebSocket Transport は待機します。

sendAndReceive: WebSocket Transport は、SOAtest で設定したメッセージをまず送信します。次に、[受信メッセージの処理] オプションで指定した条件に一致する受信メッセージを待機します。

デフォルト: <sendAndReceive>

Frame Type

メッセージのフレームタイプを指定します。 text または binaryです。

WebSocket プロトコルは、データフレームを使ってペイロードを送信します。データフレームはテキストタイプまたはバイナリタイプで設定していなければなりません。バイナリメッセージを送信する場合を除き、すべてのケースでデフォルト値(text) を使用してください。バイナリメッセージの場合はbinary を使用してください。 ?https://tools.ietf.org/html/rfc6455#section-5.6 を参照。

デフォルト: text

Connection Timeout

接続の確立を待機するタイムアウト時間をミリ秒で指定します。

デフォルト: 5000

Log Level

コンソールと[モニターの開始] ビューに表示する情報の量を指定します。以下のレベルを指定できます。

1: error

2: warn

3: info

4: debug

デフォルト: 2

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 (例: /root/name=”Bob”)。

XPathのand 演算子を使って、メッセージから複数のノードを選択することもできます。例: /root/name=”Bob” and /root/age=”40”

XPath がBoolean 型の true、ゼロ以外の数字、またはノードとして評価される場合、XPath は一致したと見なされます。XPath が false、数字の 0、空のノードとして評価される場合、XPath は不一致と見なされます。Boolean 型の一致規則はW3C勧告に基づきます(https://www.w3.org/TR/xpath-functions/#func-boolean を参照)。

デフォルト: select next messageこのフィールドを空白にした場合、デフォルト設定が使用されます。この場合、WebSocket Transport は次のメッセージを処理します。このメッセージは、「キューにある次のメッセージ」か、あるいはキューにメッセージがない場合は「サーバーからの次のメッセージ」です。

Message Format

Message Selector で照合する受信メッセージの形式( XML、JSON など) を指定します。このフィールドを指定する必要があるのは、期待されるメッセージがXML またはJSON 形式ではなく、Message Selector の値を指定している場合だけです。

デフォルトでは、WebSocket Transport は自動的にXML またはJSON 形式を検出します。メッセージが別の形式の場合、このフィールドで形式を指定する必要があります。

指定する形式は、XML Converter に表示される形式名、あるいはカスタムメッセージ形式で定義された型式名に一致させてください。Message Format を指定すると、指定したメッセージ形式のデフォルトの変換オプションに基づいて、SOAtest はメッセージをXML に変換します。

デフォルト: auto-detect

Timeout

受信メッセージを待機するタイムアウト時間をミリ秒で指定します。

デフォルト: 30000

サンプル事例

内部キューと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 つのテストを実行します。

サード パーティのコンテンツ

Parasoft Burp Suite Extensions は、以下のサード パーティのコンテンツを含みます。

その他のライセンスの詳細については、Parasoft Burp Suite Extensions の licenses フォルダーを参照してください。

  • No labels

Need assistance? Visit our support page