このセクションでは、テスト生成のために HTTP、JMS、MQ トラフィックを記録する方法を説明します。
このセクションの内容:
Parasoft Virtualize が (CTP のシン クライアント インターフェイスから) 生成したトラフィック ファイルは、仮想アセットの作成だけでなく、テストの作成にも使用できます。
Parasoft Virtualize がない場合、SOAtest のプロキシ トラフィック記録機能を使用し、アプリケーションを実行しながらサービスの HTTP、JMS、MQ トラフィックをモニターしてキャプチャできます。 これらのプロキシは、複数のエンドポイントを通過するトラフィックを同時にキャプチャできます。
アプリケーションの実行中、レコーディング プロキシが指定のトランスポートでトラフィックをモニターします。SOAtest はトラフィック リクエストおよびレスポンスをモニターし、適切なリクエスト/レスポンスのペアを記録したトラフィック ファイルを作成します。このトラフィックを使用して、、あらかじめ設定されたテスト クライアント ツールでキャプチャされた振る舞いを表現するテスト スイートを生成できます。
JMS、MQ、HTTP、HTTPS (SSL)、ベーシック、ダイジェスト および Kerberos 認証がサポートされています。NTLM はサポートされていません。
HTTP チャンキングおよび continue ヘッダーはサポートされていません。
この方法でトラフィック ファイルからテストを記録して生成するには、大きく分けて次の 2 つの手順を実行します。
1 つ以上のエンドポイントを通過するトラフィックをキャプチャするには、次の操作を行います。
トラフィックがキャプチャされたら、ビューを切り替えて各エンドポイントのリクエストおよびレスポンスを参照できます。
トラフィックがキャプチャされたら、以下の 2 つの方法でテストを生成できます。
このセクションでは、HTTP トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。
HTTP、HTTPS (SSL)、ベーシック、ダイジェスト および Kerberos 認証がサポートされています。NTLM はサポートされていません。
プロキシのトラフィック記録機能ウィザードで、次のように HTTP 設定を指定します。
SSL の性質上、SOAtest の HTTP プロキシのトラフィック記録機能は、それ自身の証明書認証局によって署名された動的サーバー証明書を生成します。 この動的サーバー証明書を受け入れるため、HTTPS 上でリクエストを生成するクライアントは、すべての証明書を受け入れる必要があります。また、SOAtest はサービスが提示する証明書を信頼するよう構成されていなければなりません。そのためには、次の操作を行います。
SSL の性質上、SOAtest の HTTP プロキシのトラフィック記録機能は、それ自身の証明書認証局によって署名された動的サーバー証明書を生成します。 この動的サーバー証明書を受け入れるため、HTTPS 上でリクエストを生成するクライアントは、すべての証明書を受け入れる必要があります。また、SOAtest はサービスが提示する証明書を信頼し、適切なクライアント証明書を送信するよう構成されていなければなりません。そのためには、次の操作を行います。
サーバーサイド SSL または双方向 SSL を使用するサービスの HTTPS トラフィックをキャプチャしたトラフィック ファイルを生成するには、前述の「トラフィックのキャプチャ」の説明に従ってウィザードを実行します。
HTTP ウィザードのページで、SSL オプションを適切に有効化します。
このセクションでは、JMS トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。
このセクションの内容:
「JMS の前提条件」を参照してください。
トラフィックがキューを介して送受信される場合、クライアント接続先キューにリクエストを送信するクライアント アプリケーションがあり、キューからメッセージを受信するサーバー アプリケーションがあり、別の (リプライ) メッセージをクライアントが受信するための 2 つ目のキューに送信すると仮定されます。
このようなシナリオを考慮し、Parasoft SOAtest はクライアントとサーバー間の「仲介者」(プロキシとも呼ばれます) として動作します。このような仲介を容易にするために、メッセージ プロバイダー上に 2 つのキューがさらに必要になります。SOAtest のプロキシは、クライアントがメッセージを送信したキューからメッセージを取得し、メッセージのコンテンツを記録して (記録が有効化されている場合)、サーバーが受信するキューにメッセージを put します。同様に、クライアントがメッセージを取得するためのキューにサーバーがメッセージを送信すると、メッセージを記録して (記録が有効化されている場合)、クライアントが返信レスポンスを期待しているキューにメッセージを戻します。
結果として、2 つの追加のキューと、以下のどちらかの操作が必要になります。
クライアントまたはサーバーのどちらかだけを変更する必要があります。
JMS を設定するには、次の操作を行います。
JMS のキューまたはトピックのどちらを使用するか、プロバイダー URL、初期コンテキスト、および接続ファクトリを指定します (関連する jar ファイルを必ず SOAtest のクラスパスに追加してください)。また、その他の初期コンテキスト JNDI プロパティ、認証情報、モニターしてトラフィックを収集するキュー/トピックを指定します。
このオプションは、メッセージの JMSReplyToQueueName ヘッダーを使用してプロキシがレスポンスを送信する宛先を決定するかどうかを指定します。[レスポンスに JMSReplyTo を使用する] オプションがオンの場合、受信リクエストの値を使用してレスポンスの送信先を決定します。 このオプションがオフの場合、UI で指定されたキューにレスポンスが送信され、JMS メッセージ ヘッダーの値は無視されます。 |
このセクションでは、MQ トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。
このセクションの内容:
「必要な JAR ファイルをクラスパスへ追加」を参照してください。
トラフィックがキューを介して送受信される場合、クライアント接続先キューにリクエストを送信するクライアント アプリケーションがあり、キューからメッセージを受信するサーバー アプリケーションがあり、別の (リプライ) メッセージをクライアントが受信するための 2 つ目のキューに送信すると仮定されます。
このようなシナリオを考慮し、Parasoft SOAtest はクライアントとサーバー間の「仲介者」(プロキシとも呼ばれます) として動作します。このような仲介を容易にするために、メッセージ プロバイダー上に 2 つのキューがさらに必要になります。SOAtest のプロキシは、クライアントがメッセージを送信したキューからメッセージを取得し、メッセージのコンテンツを記録して (記録が有効化されている場合)、サーバーが受信するキューにメッセージを put します。同様に、クライアントがメッセージを取得するためのキューにサーバーがメッセージを送信すると、メッセージを記録して (記録が有効化されている場合)、クライアントが返信レスポンスを期待しているキューにメッセージを戻します。
結果として、2 つの追加のキューと、以下のどちらかの操作が必要になります。
クライアントまたはサーバーのどちらかだけを変更する必要があります。
MQ を設定するには、次の操作を行います。
このオプションは、メッセージの replyToQueueName ヘッダーを使用してプロキシがレスポンスを送信する宛先を決定するかどうかを指定します。このオプションの設定は、MQMT_REQUEST タイプの MQ メッセージのレスポンスに影響を与えます。 [レスポンスに replyToQueueName を使用する] オプションがオンの場合、受信リクエストの値を使用してレスポンスの送信先を決定します。 このオプションがオフの場合、UI で指定されたキューにレスポンスが送信されます。具体的には、次の処理が実行されます。
|
このセクションでは、WebSphere MQ およびポイントツーポイントのJMS を記録する (トピックではなくキューが使用される場合) ための構成方法について説明します。
SOAtest が JMS の ポイントツーポイント メッセージングおよび WebSphere MQ を記録する際に使用する方法では、SOAtest がプロキシ (別の言葉で言えば媒介/仲介者) の役割を果たす必要があります。
接続先キューである REQUEST_QUEUE にリクエストを送信/put/push し、RESPONSE_QUEUE からレスポンス/リプライを受信/取得/pull するクライアント/コンシューマー アプリケーション (クライアントと呼びます) があるとします。また、接続先キューである REQUEST_QUEUE からリクエストを受信/取得/pull し、RESPONSE_QUEUE にレスポンス/リプライを送信/put/push するサーバー/プロバイダー アプリケーション (サーバーと呼びます) があるとします。
トラフィックの記録に際しては、2 つの構成オプションが考えられます。1 つは、クライアント アプリケーション側が使用するキューを変更することです。もう 1 つは、サーバーが使用するキューを変更することです。
最良のアプローチは、どちら側にアクセスして変更できるかによります。どちらの場合も、記録プロセスを実現するには、2 つのキューを追加する必要があります。ここでは、新しいキューを PROXY_REQUEST_QUEUE および PROXY_RESPONSE_QUEUE とします。
(キューではなくトピックを使用する) パブリッシュおよびサブスクライブ スキームを採用している場合、システムに新しいトピックを導入する必要はありません。そのため、ウィザードでは、次の 2 つの接続先しか入力する必要はありません。
|
このシナリオでは、クライアント アプリケーションのデプロイメント構成にアクセスして、使用するキューを変更できなければなりません。クライアントがサーバーとの通信に使用するキューを次のように変更します。
この場合、サーバーのキューを変更する必要はありません。
MQ または JMS 記録ウィザードで、次のようにキュー名を指定します。
| クライアントのキュー | |
|---|---|
| Destination/Put Queue | PROXY_REQUEST_QUEUE |
| Reply to/Get Queue | PROXY_RESPONSE_QUEUE |
| サーバーのキュー | |
| Reply to/Get Queue | REQUEST_QUEUE |
| Destination/Put Queue | RESPONSE_QUEUE |
このシナリオでは、サーバー アプリケーションのデプロイメント構成にアクセスして、使用するキューを変更できなければなりません。サーバーがクライアントとの通信に使用するキューを次のように変更します。
この場合、クライアントのキューを変更する必要はありません。
MQ または JMS 記録ウィザードで、次のようにキュー名を指定します。
| クライアントのキュー | |
|---|---|
| Destination/Put Queue | REQUEST_QUEUE |
| Reply to/Get Queue | RESPONSE_QUEUE |
| サーバーのキュー | |
| Reply to/Get Queue | PROXY_REQUEST_QUEUE |
| Destination/Put Queue | PROXY_RESPONSE_QUEUE |