このセクションでは、記録した HTTP、JMS、MQ トラフィックからテストを作成する方法の概要について説明します。このセクションの内容:

この方法と「JMS/TIBCO/Sonic ウィザードからのテスト生成」との違い

この方法では、JMS だけでなく HTTP および MQ もサポートされます (他のウィザードからのテスト生成では、JMS しかサポートされません)。また、複数の接続を一度に記録できます (他のウィザードからのテスト生成では、一度に 1 つの JMS 接続しかサポートされません)。さらに、この方法では常にキューにメッセージが残されます (他のウィザードからのテスト生成では、オプションを選択したときにだけメッセージが残されます)。

ただし、この方法では、2 つのステップを実行する必要があります (トラフィックをファイルにキャプチャし、ファイルからテストを作成します)。他のウィザードでは、1 つのステップだけしか必要ありません。

他のウィザードでは、最初にウィザードを終了したときに自動的にテストが生成されます。また、TIBCO および Sonic に対応した構成パネルが表示され、プロバイダー固有の設定の一部が自動的に構成されます。一方、レコーディング ウィザードは汎用的な JMS 構成インターフェイスを表示します。

トラフィックからのテスト生成の概要

SOAtest は、以下のようなトラフィック ログにキャプチャされたアプリケーションの振る舞いを検証するテストを作成できます。

  • テスト生成のための HTTP、JMS、MQ トラフィックの記録」で説明するように、SOAtest レコーディング プロキシ (JMS、MQ、HTTP など) で作成されたトラフィック ファイル。
  • Parasoft Virtualize または Parasoft CTP で生成されたトラフィック ファイル。
  • 他のソースから作成されたログ。 例:
    • ネットワーク監視ツールなどを使用してネットワーク レベルでキャプチャされたメッセージログまたはログ
    • アプリケーションでトラフィックを記録した HTTP ログ

サポートされるトラフィック ログ フォーマット

SOAtest は、以下のトラフィック ログ フォーマットをサポートします (どのようなファイル拡張子でも構いません)。

HTTP トラフィック ログ

HTTP パーサー タイプの場合、SOAtest は POST、GET および PUT メソッドのトラフィックを認識し、解析できます。  DELETE はサポートされていません。SOAtest は、次のように、ログにメッセージの HTTP ヘッダーが含まれ、その後にメッセージ ボディ コンテンツが続いていると期待します。

HTTP request 1 headers HTTP request 1 body HTTP response 1 headers HTTP response 1 body HTTP request 2 headers HTTP request 2 body HTTP response 2 headers HTTP response 2 body ...

また、SOAtest はメッセージ ボディと次の HTTP ヘッダーのセットの間に 2 つの改行 (Windows または Unix) があることを期待します。

このフォーマットは、SOAtest のレコーディング ウィザードや、HTTP ソケット接続上で送受信される HTTP トラフィックを記録できる他の HTTP トラフィック監視ツールがキャプチャするものと似ています。

HTTP チャンキングおよびチャンクされたトラフィックが記録されたトラフィック ファイルがサポートされています。ただし、チャンクされたメッセージまたは "continue" ヘッダーを含む raw HTTP トラフィック ファイルはサポートされていません。

JMS および MQ トラフィック ログ

SOAtest は、SOAtest のトラフィック レコーディング ウィザードで作成された JMS および MQ トラフィック ファイルからのテスト生成をサポートしています。

メッセージ形式

パラメータライズされたメッセージの場合、トラフィック ファイルには SOAtest がサポートする任意のメッセージ形式 (EDI、JSON、固定長、およびカスタム メッセージ形式など) を含めることができます。固定メッセージの場合、XML および JSON だけがサポートされています。

パラメーターが使用される場合と固定メッセージが使用される場合

SOAtest には、トラフィック ログからテストを生成する際のオプションが 2 つあります。

  • パラメータライズされたメッセージを生成 オプションは、テスト クライアントを作成し、Parasoft データ リポジトリ (このオプションを選択した場合、データ リポジトリも自動的に作成されます) の値で自動的にパラメータライズします。このオプションを選択すると、大規模で複雑なデータ ソースを操作するためのグラフィカルなインターフェイスを使用してリクエスト メッセージの値をすばやく追加したり変更したりできます。データはテスト クライアントや .tst ファイルとは独立して格納され、操作されます。
  • 固定メッセージの生成 オプションは、検出されたリクエストごとに 1 つのテスト クライアントを作成します。すべてのリクエスト メッセージ データはテスト クライアント内に格納され、操作されます。これらのテスト クライアントは、後でパラメータライズできます。

サンプル

上記の 2 つのオプションの違いを理解するため、次のサンプルを考えてみましょう。サンプルは getItemByTitle オペレーションの 3 つのメッセージを含む単純な HTTP トラフィック ファイルです。

パラメータライズされたメッセージ

[パラメータライズされたメッセージを生成] オプションを選択すると、SOAtest はトラフィック ファイルの 3 つの getItemByTitle リクエストから 1 つのテスト クライアントを作成し、次のようにパラメータライズします。



さらに、編集と拡張が可能な次のデータ リポジトリが作成されます。

固定メッセージ

[固定メッセージの生成] オプションを選択すると、SOAtest はトラフィック ファイルの 3 つの getItemByTitle リクエストから 3 つのテスト クライアントを作成します。次の図は、キーワード "Java" を使用した書籍の検索から作成されたテスト クライアントを示しています。



キーワード "Linux" および "C++" を使用した書籍の検索に対しても、同様のテスト クライアントが追加されます。

  • No labels