概要

CTP の「トラフィックからの作成」機能を利用すると、記録済みの HTTP/S、JMS、MQ トラフィックから、パラメーターライズされた仮想アセットをすばやく作成でき、複雑なレスポンスを定義する時間や手間を省くことができます。また、データの編集と拡張が容易になり、1 つの環境 (機能テストなど) でキャプチャされたデータを簡単に他の環境 (パフォーマンス テスト、開発、セキュリティ テストなど) でも再利用できます。

ウィザードを実行するたびに、1 つの仮想アセット (.pva) ファイルが作成され、Parasoft Data Repository サーバーに作成されたリポジトリの値でパラメータライズされたメッセージ レスポンダーが自動的に設定されます。データ値は、仮想アセットとは独立して操作できます。 

CTP のトラフィックからの作成機能は、JSON または XML フォーマットのメッセージを処理するよう設計されています。他のメッセージ フォーマット (EDI、プレーン テキストなど) のトラフィック ファイルから仮想アセットを作成するには、デスクトップ版の Virtualize でフォーマットに応じたパラメータライズされたメッセージの生成機能を使用します。

前提条件

トラフィックから仮想アセットを作成するには、以下が必要です。

• Virtualize 9.10 以上が CTP に接続されていること (詳細については「Virtualize Server/SOAtest サーバーと CTP の統合」を参照)
• 仮想アセットを作成する Virtualize サーバーの recorded_traffic フォルダーにサポート対象のトラフィック ファイルが格納されていること以下のフォーマットがサポートされています。
  • Vritualize のメッセージ プロキシまたはレコーディング プロキシによって生成されたログ (詳細については「メッセージ プロキシの構成」を参照)
  • ネットワーク監視ツールを使用してネットワーク レベルでキャプチャされたメッセージ トレースまたはログ
  • アプリケーションでトラフィックを記録した HTTP ログ
• Parasoft Data Repository サーバーが実行され、CTP と接続されていること (詳細については「 Test Data Assistant のセットアップ」を参照)

仮想アセットの作成 

トラフィックから仮想アセットを作成するには、次の操作を行います。

1. 左側のペインで新規仮想アセットを追加するサーバーまたはフォルダーを選択します。
2. ページレベルのアクション メニューの [仮想アセットの作成] をクリックします。
   
3. (任意) 新しく作成される仮想アセットの名前を変更します。
4. [作成] に [トラフィック] を指定します。

5. (Virtualize サーバーの traffic_templates フォルダーに格納された) テンプレート ファイルの設定を適用するには、[テンプレート ファイルの適用] オプションをオンにし、適用するテンプレート ファイルを選択します。  テンプレートを適用すると、ウィザードの残りのページの設定に、あらかじめ値が設定されます。必要に応じて設定値を変更できます。テンプレートの値は変更されません。変更後の設定を新しいテンプレートとして保存することもできます。  
   

6. [リポジトリ サーバー] の下で、関連データを保存する Data Repository サーバーを選択します。
7. [リポジトリ名] の下で、関連データを保存するデータ リポジトリの名前を選択するか、新しい名前を入力し、[次へ] をクリックします。
   
   
8. ウィザードの次のページで、推奨されるグループ化計画を確認し、必要に応じてストラテジを変更して [次へ] をクリックします。利用可能なグループ化ストラテジの詳細については「グループ化計画について」を参照してください。以下はオプションの概要です。
   • HTTP メソッド: HTTP メソッドによってメッセージを処理するかどうかを決定します。  
   • URL パス: URL パスによってメッセージを処理するかどうかを決定します。 
   • URL パラメーター: URL パラメーターによってメッセージを処理するかどうかを決定します。 
   • リクエスト ボディ: XPath によってメッセージを処理するかどうかを決定します。
     
     
9. ウィザードの次のページで、メッセージのグループ化の結果を確認します。
   
   • 処理されたリクエスト/レスポンス ペアの合計数と無効なペアの数が上部に表示されます。
   • 表示される列のタイプは、適用されたグループ化計画によって異なります。 
   • テーブルの各行は、グループを定義する条件に対応します。テーブルの各行に 1 つのグループが生成されます。各グループに 1 つのレスポンダーが生成されます。 
     
     

10. 自動設定されたリクエスト応答条件を変更したい場合、および/または WSDL/スキーマを指定したい場合、関連する行を展開して WSDL/スキーマおよび応答条件を構成します。応答条件を構成する方法の詳細については、「データ ソース応答条件のカスタマイズ」を参照してください。

    
    

    WSDL/スキーマを指定する理由

    WSDL またはスキーマを指定すると、トラフィックからの推測ではなく、WSDL/スキーマに合わせてデータ定義が作成されます。さらに、デスクトップ版の Virtualize でこの仮想アセットを操作するとき、より豊富な編集機能や変更アドバイザー機能を利用できるようになります。

11. ウィザードで使用した設定を保存するには、[再利用可能なテンプレートをエクスポート] をオンにして任意のファイル名を指定します。デフォルトでは、トラフィックは現在のサーバーの recorded_traffic フォルダー (フォルダーが存在しない場合は作成されます) に %n_%d_%t.traffictemplate というファイル名で記録されています。ファイル名を指定する場合、%d (現在日付)、%t (現在時刻)、%n (名)、%u (時間ベースのユニークな ID) などの変数を使用できます。  

12. [アセットの作成] をクリックします。

以下のアイテムが作成され、設定されます。

• 要素がパラメータライズされ、レスポンダー応答条件およびデータ ソース応答条件が設定された Message Responder が追加されます。
• (新規データ リポジトリの場合) 適用可能なデータ セットおよびレコード タイプが追加された Data Repository が追加されます。トラフィックの解析によって識別されたメッセージの「グループ」ごとに 1 つのデータ セットが追加されます。
• (既存のデータ リポジトリの場合) 新規データ セットおよびレコード タイプが既存のリポジトリに追加されます。
• 追加されたデータ セットごとに 1 つのリポジトリ データ ソースが追加され、Message Responder がこのデータ ソースを使用するよう設定されます。
  
  

グループ化計画について

トラフィックから仮想アセットを作成する場合、Virtualize サーバーはリクエスト/レスポンス ペアを操作/タイプによってグループ化します。グループ化メソッドは、a) 指定されたトラフィックを Virtualize が解析した結果、および b) 選択されたグループ化条件の両方に影響されます。推奨されるグループ化計画が自動的に選択されます。必要に応じて、それらの推奨を調整し上書きすることができます。 

Virtualize は、トラフィックを解析する際、2 段階のアプローチを採ります。まず、有効化するべきグループ化計画を推奨し、選択された計画を使用してメッセージをグループに分割します。PVA を作成する際、各グループに 1 つのレスポンダーが生成されます。

推奨されるグループ化計画は、次のロジックで決定されます。

• リクエスト ボディに基づくグループ化は、以下の場合に選択されます。
  • SOAP トラフィック
  • 非 XML メッセージ フォーマット
  • 非 HTTP トラフィック
• HTTP メソッドおよび URL パスに基づくグループ化は、その他の場合に選択されます (HTTP メソッドは、指定されたトラフィック内に異なるメソッドが含まれている場合にだけ選択されます)。

グループ化する際、Virtualize は以下の処理を行います。

• 一般的な条件より特化した条件を優先します。グループ内のすべてのメッセージにだけ一致する (他のグループのメッセージには一致しない)、できる限り特殊な式を生成します。これにより、生成されるレスポンダーは、同じトラフィックに正確に応答できます。
• グループ化の順序 (HTTP メソッド、URL パス、URL パラメーターの後にリクエスト ボディ コンテンツ) に従います。たとえば、URL パスだけでグループを区別できる場合、リクエスト ボディなどのグループ化条件に対応する応答条件は作成されません。

以下のグループ化計画を適用できます。

• HTTP メソッド
• URL パス
• URL パラメーター
• リクエスト ボディ

HTTP メソッド

生成されたメッセージ レスポンダーを HTTP メソッド (POST、GET、PUT など) に基づいて分割します。この計画が有効な場合、異なる HTTP メソッドに対してそれぞれメッセージ レスポンダーが生成されます。

たとえば、トラフィックに 10 個の POST メッセージと 15 個の GET メッセージが含まれている場合 (メッセージの順序は問わない)、Virtualize は生成される PVA に 2 つのレスポンダーを作成します。1 つは POST メッセージに対応し、もう 1 つは GET メッセージに対応します (他のグループ化計画によってさらに分割されない場合)。

結果のグループをカスタマイズし、1 つのグループが複数の HTTP メッセージに対応するようにできます。たとえば、1 つのグループ内で POST および PUT の両方が有効化されている場合、POST メソッドを使用するメッセージと PUT メソッドを使用するメッセージがグループに一致し、グループに割り当てられます。言い換えれば、グループに基づいて生成されるレスポンダーは、POST および PUT メッセージの両方に応答します (どちらも受け入れます)。

URL パス

生成されたメッセージ レスポンダーを URL パスに基づいて分割します。固有の HTTP URL ごとに 1 つのメッセージ レスポンダーが生成されます。HTTP URL パスによるグループ化を指定すると、HTTP URL の固有性に基づいてグループが定義されます。

最初にこの計画に基づいてグループ化が行われると、パスを解析してメッセージ タイプを最もよく表すパス式のセットが生成されます。タイプの決定には、本質的に主観に基づくパス解析アルゴリズムが使用されます。アルゴリズムは最も一般的な REST サービスのパターンに対応するよう設計されていますが、最適な結果を得るには、生成された条件を微調整する必要がある場合もあります。

たとえば、トラフィックに以下の HTTP URL パスが含まれるとします (簡略化のため、HTTP メソッド、URL パラメーターなどは省略してあります)。

/service/order/v1/1/summary
/service/order/v1/2/summary
/service/order/v1/2/summary
/service/customer/v1/a/contact
/service/customer/v1/b/contact
/Foo
/Foo

Virtualize は、PVA に以下の 3 つのレスポンダーを作成します。

• Responder 1: summary パス用 (3 メッセージ)
• Responder 2: contact パス用 (2 メッセージ)
• Responder 3: Foo パス用 (2 メッセージ)

これらのレスポンダーは、* がゼロ個以上の文字に一致し、** がゼロ個以上のディレクトリに一致する、Ant スタイルのワイルドカードを使用して生成されます。

URL パラメーター

生成された Message Responder を HTTP URL パラメーターに基づいて分割します。固有の URL パラメーターごとに 1 つの Message Responder が生成されます。

たとえば、トラフィックに以下の URL パラメーターが含まれているとします。

?oid=1&category=women
?oid=2&category=women
?oid=1&category=babies
?ssn=1234567890&state=CA&category=silver
?ssn=1234567891&state=CA&category=gold

Virtualize は、以下のように PVA のレスポンダーを oid、ssn、および sate パラメーターの存在に基づいて分割します (各レスポンダーには、以下のレスポンダー応答条件が設定されます)。

• Responder 1: URL パラメーター oid が存在する (3 メッセージ)
• Responder 2: URL パラメーター ssn および state が存在する (2 メッセージ)

リクエスト ボディ

生成されたメッセージ レスポンダーをリクエスト コンテンツの評価を行う XPath 式のリストに基づいて分割します。各 XPath 式は 1 つのグループおよび XML メッセージ応答条件に対応します。

この計画が有効な場合、SOAP メッセージは (デフォルトの設定では) Body の下の最初の要素名に基づいてグループ化されます。非 SOAP XML コンテンツについては、ルート要素名に基づいてメッセージがグループ化されます。

カスタム メッセージ フォーマット (またはビルトインの非 XML フォーマット) が使用されている場合、XPath 式はリクエストを変換した後の XML フォーマットに基づきます。

データ ソース応答条件のカスタマイズ

(上で説明した) レスポンダー応答条件は、メッセージ レスポンダーがどのメッセージを受け入れて処理するかを決定します。仮想アセット URL に送信されるさまざまなメッセージは、ここでの設定に基づいて特定のメッセージ レスポンダー ツール (それぞれ異なる操作に対応する) に振り分けられます。たとえば、1 つの Message Responder Tool は顧客登録メッセージに応答し、別のメッセージ レスポンダーは支払メッセージに応答し、さらに別のレスポンダーは、他のレスポンダーに一致しない場合に使用されるデフォルトの「キャッチ オール」として機能する場合があるでしょう。 

自動設定されたレスポンダー応答条件の処理の後、受信メッセージの値が (リテラルにまたは式を使用して) データ ソースの値と比較され、レスポンダーは一致するデータ行を使用してレスポンス メッセージを作成します。指定された受信メッセージ値と一致するデータ ソース行が見つからなかった場合、Virtualize は (デフォルトのフェイルオーバー設定を使用して) 検索を続行し、レスポンダー スイート内でレスポンダー応答条件が一致するレスポンダーを見つけようとします。

Virtualize は以下のデータ ソース応答条件 (適用可能な場合) に自動的に値を指定しますが、ユーザーは初期応答条件をカスタマイズできます。

• リクエスト ボディ応答条件
• リクエスト URL パス応答条件
• リクエスト URL パラメーター応答条件
  
  

テンプレートを指定しなかった場合、ページの初期状態では、現在のトラフィック ファイルから自動設定されたデータ ソース応答条件が表示されます。

テンプレートを指定した場合、ページの初期状態では、テンプレートに定義されたデータ ソース応答条件が表示されます。この場合、データ ソース応答条件は現在のトラフィック ファイルから自動設定されません。

自動設定されたデータ ソース応答条件をカスタマイズするには、次の操作を行います。

1. [自動構成] チェック ボックスをオフにします。
2. 応答条件をカスタマイズするレスポンダーの行を展開します。
   
   
   
3. 表示されるコントロールを使用して応答条件を設定します。 

• • リクエスト ボディ応答条件は、XPath ビルダー (「XPath の指定」で説明) を使用して、またはテーブルに値を入力することで設定できます。
  • URL パラメーターおよび URL パス応答条件は、テーブルに行を追加することで設定できます。
  • 応答条件を設定する際、データ ソース列名を入力するか、ツールに関連付けられたデータ ソース (設定エリア上部の [データ ソース] 列で選択されている) の利用可能な行をリストから選択できることに注意してください。
    

リクエスト ボディ応答条件

Virtualize は各操作/グループに対して「名前」ベースの XPath を生成し、操作のレスポンダー応答条件を設定するのに使用します。たとえば、SOAP Body の下の要素名が "SubmitOrder" である場合、XPath 式はレスポンダー応答条件セクションに local-name(/*/*[local-name(.)="Body"]/*)="SubmitOrder" のような条件を設定します。

メッセージが XML ではない場合、リクエスト メッセージを変換した後の XML に対して XPath およびパラメーターの選択が適用されることに注意してください。

同じ操作に属するメッセージのグループごとに、リクエストが相互比較され、リクエスト間で異なっているパラメーターが決定されます。Virtualize のトラフィックからの自動構成機能は、リクエスト要素間の差異を自動的に解析し、その結果を使用して操作/グループ内で利用可能なレスポンスのための XPath 式を生成します。目的は、個別のリクエスト要素に対して自動的にレスポンスを生成することです。トラフィックが SOAP エンベロープである場合、操作要素 (SOAP ボディの最初の要素) が共通である限り、メッセージの構造的な差異は許容されます。トラフィックが汎用的な XML である場合、ルート ノードが共通である限り、メッセージの構造的な差異は許容されます。

ウィザードのページに表示される初期設定を上書きするには、表示されているコントロールを使用して XPath および列名を指定します。XPath セレクターの詳しい使用方法については、「XPath の指定」を参照してください。

リクエスト URL パラメーター応答条件

リクエスト URL パラメーターについては、1 つのメッセージ グループに所属する呼び出しの中で URL パラメーターに、パラメーター数が異なる、パラメーター (名前) が異なる、パラメーター値が異なるなどの差異がある場合、Virtualize のトラフィックからの自動構成機能は、それらの差異に基づいて自動的に応答条件を設定します。

たとえば、特定のメッセージ グループの呼び出しに以下のパラメーターがあるとします。

countryCode=US&brandCode=HG
countryCode=Uk&brandCode=HG&channelCode=3
countryCode=US
countryCode=UK
brandCode=HG

パラメーターの差異に基づいて、Virtualize はこのメッセージ グループに対し、countryCode、brandCode、channelCode の 3 つのデータ ソース応答条件行を自動的に設定します。

ウィザードのページに表示される初期設定を上書きするには、表示されているコントロールを使用してパラメーターおよび列名を指定します。たとえば、productCode パラメーターに対してデータ応答条件を設定するには、次のように指定します。

リクエスト URL パス応答条件

URL パスについては、1 つのメッセージ グループに所属する呼び出しの中で URL に差異がある場合、Virtualize のトラフィックからの自動設定機能は、それらの差異に基づいて自動的に応答条件を設定します。

たとえば、特定のメッセージ グループの呼び出しに以下のパスがあるとします。

/customer/123/account/1920384
/customer/203/account/4922434
/customer/302/account/7349463

Virtualize はこのメッセージ グループに対し、セグメント 1 および 3 (インデックスは 0 から開始されます) の違いに基づいて、ndex 1 および index 3 に対応する 2 つのデータ ソース応答条件行を追加します。

ウィザードのページに表示される初期設定を上書きするには、表示されているコントロールを使用して応答条件として使用するパス セグメントを指定します。パス セグメントは、1 つまたはそれ以上のデータ ソース列名と比較し、さまざまなデータ ソース列でパラメータライズすることができます。ダイアログが開いたら、使用するパス セグメントを指定し (パス セグメントをクリックするか、パス インデックスを入力します)、データ ソース列名を指定します。

たとえば、パス インデックス 2 を使用して account データ ソース列と比較するには、次のように応答条件を設定します。