このセクションでは、グローバルに共有および参照できる、JMS、 XPath、 SOAP ヘッダー、データベース プロパティの作成方法について説明するほか、グローバル認証、キーストア、ツール、WS-Policy バンクについて説明します。このセクションの内容:

グローバルな [JMS 接続プロパティ]

複数のツールがある大規模なテストを作成する場合、一部のツール (SOAP Client、Messaging Client、および Call Back Tool) が同じ JMS 接続プロパティを使用する場合があるかもしれません。複数のツールで同じ JMS 接続設定を使用したい場合があります。各ツールに同じ情報を手動で入力したり、ツール間で設定をコピー & ペーストしたりするよりも、各ツールが参照できる JMS 設定を作成すると簡単です。この場合、テストまたはアクション スイート レベルで [JMS 接続プロパティ] を作成できます。グローバルな JMS プロパティを作成するには、次の作業を実施します。

  1. 目的のノードを選択し、ツールバーの [プロパティの追加] をクリックします。

  2. [グローバル プロパティの追加] ウィザードで [グローバル プロパティ] > [JMS 接続プロパティ] を選択し、[終了] をクリックします。[プロパティ] ノードが表示され、GUI 左側に [JMS 接続プロパティ] パネルが表示されます。
  3. [JMS 接続プロパティ] パネルに次のように設定を指定します。
    1. (任意) [名前] フィールドに新しい名前を入力します。この名前は、これらのプロパティを参照するツールに表示される名前です。グローバルな JMS 接続プロパティのリファレンスは 1 つ以上作成できるので、入力する名前は直観的に目的が分かるものであるべきです。

    2. [すべてのテストにプロパティを追加] をクリックします。このボタンをクリックしない場合、追加したグローバル プロパティはアクション スイートのツールに無視されます。ドロップダウン リストから [共有プロパティのみ使用] を選択した場合、アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティだけを使用できます。 および、個々のツールで設定したプロパティだけを使用できます。

    3. [プロバイダー URL] フィールドで、JMS 管理オブジェクトの場所を指定します。 
    4. [初期コンテキスト] フィールドで、すべての JMS プロパティのマッピングを含む Java クラスを指定します。
    5. [接続ファクトリ] フィールドで、初期コンテキストから MOM 固有ファクトリのルックアップに使用されるキーを指定します。キュー接続ファクトリまたはトピック接続ファクトリのどちらでもかまいません。
    6. [認証] エリアでは、[認証の実行] をオンにし、リクエストを認証するためのユーザー名とパスワードを入力します。不正なユーザー名とパスワードが使用された場合、リクエストは認証されません。

グローバルな JMS 接続プロパティを参照できるのは、SOAP Client、Messaging Client、および Call Back ツールだけです。

グローバルな JMS 接続プロパティの設定が完了すると、これらのSOAtest ツールの複数のインスタンスでプロパティを共有できます。

グローバルな [無視する XPath] プロパティ

グローバルな JMS プロパティの場合と同様に、同じ XPath 設定を使用する複数の Diff ツールが存在するケースがあるかもしれません。複数の Diff ツールで同じ XPath 設定を使用したい場合があります。各 Diff ツールに同じ情報を手動で入力したり、Diff ツール間で設定をコピー & ペーストしたりするよりも、各 Diff ツールが参照できる XPath 設定を作成すると簡単です。この場合、アクションまたはテスト スイート レベルでグローバルな XPath プロパティを作成できます。

グローバルな無視する Xpath のリストを作成するには、次の作業を実施します。

  1. 目的のスイート ノードを選択し、ツールバーの [プロパティの追加] をクリックします。

  2. [グローバルの追加] ウィザードで [グローバル プロパティ] > [無視する XPath] を選択し、[終了] をクリックします。[プロパティ] ノードが表示され、GUI 左側に [JMS 接続プロパティ] パネルが表示されます。
  3. [無視する XPath] パネルに次のように設定を指定します。
    1. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。この名前は、これらのプロパティを参照する Diff ツールに表示される名前です。グローバルな XPath の一覧リファレンスは 1 つ以上作成できるので、入力する名前は直観的に目的が分かるものであるべきです。

    2. [すべてのテストにプロパティを追加] をクリックします (このボタンをクリックしない場合、追加したグローバル プロパティはアクション スイートのツールに無視されます)。ドロップダウンからオプションを選択します。

      • 共有プロパティのみ使用: アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティだけを使用できます。

      • ローカルプロパティと共有プロパティを使用: アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティおよび個々のツールで設定されたプロパティを使用できます。

    3. [追加] をクリックします。[無視する XPath のリスト] の [XPath] 列に空のフィールドが表示されます。デフォルトでは、[設定] 列は自動的にすべての XPath 操作を指定した状態が入力されます。つまり、ユーザーが追加したすべての XPath は無視されます。

    4. [XPath] 列をダブルクリックします。[無視する XPath の設定] ダイアログが表示されます。XPath のポジションを指定します。入力した XPath はスイート中の複数の Diff ツールによって共有できます。要素の XPath の場所で 1 つ以上の属性を無視したい場合、属性名を空のままにするか、ワイルドカード * を使用します (例: myAttribute*)。

グローバルな [SOAP ヘッダー] プロパティ

複数のツールがある大規模なテストを作成する場合、SOAP Client ツールが同じ SOAP ヘッダー プロパティを使用するケースがあるかもしれません。複数のツールに同じ SOAP ヘッダー設定を使用したい場合があります。各ツールに同じ情報を手動で入力したり、ツール間で設定をコピー & ペーストしたりするよりも、各ツールが参照できる SOAP ヘッダー設定を作成すると簡単です。この場合、テストまたはアクション スイート レベルでグローバルな SOAP ヘッダー プロパティを作成できます。

グローバルな SOAP ヘッダーを作成するには、次の作業を実施します。

  1. 目的のスイート ノードを選択し、ツールバーの [プロパティの追加] をクリックします。

  2. [グローバルの追加] ウィザードで [グローバル プロパティ] > [SOAP ヘッダー] を選択し、[終了] をクリックします。[プロパティ] ノードが表示され、GUI 左側に [SOAP ヘッダー] パネルが表示されます。
  3. [SOAP ヘッダー] パネルに次のように設定を指定します。
    1. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。

    2. [すべてのテストにプロパティを追加] をクリックします (このボタンをクリックしない場合、追加したグローバル プロパティはアクション スイートのツールに無視されます)。ドロップダウンからオプションを選択します。

      • 共有プロパティのみ使用: アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティだけを使用できます。

      • ローカルプロパティと共有プロパティを使用: スイート セット中の関連するツールは、ユーザーが追加したグローバル プロパティおよび個々のツールで設定されたプロパティを使用できます。

    3. [追加] をクリックします。[新規 SOAP ヘッダーの追加] ダイアログが表示されます。

    4. 利用可能なヘッダー タイプから、SOAP ヘッダーのタイプを選択し、[OK] をクリックします。

    5. 必要に応じて、SOAP ヘッダーのパラメーターを設定します。各 SOAP ヘッダーの詳細については、「SOAP ヘッダーの追加」を参照してください。

グローバルなデータベース アカウント プロパティ

複数のツールがある大規模なテスト スイートを作成する場合、DB ツールが同じデータベースプロパティを使用するケースがあります。複数のツールに同じデータベース設定を使用したい場合があります。各ツールに同じ情報を手動で入力したり、ツール間で設定をコピー & ペーストしたりするよりも、各ツールが参照できるデータベース アカウントを作成すると簡単です。この場合、スイート レベルでグローバルなデータベース アカウント プロパティを作成できます。

グローバルなデータベース アカウントを作成するには、次の作業を実施します。

  1. 目的のスイートを選択し、ツールバーの [プロパティの追加] をクリックします。

  2. [グローバル プロパティの追加] ウィザードで [グローバル プロパティ] > [データベース アカウント] を選択し、[終了] をクリックします。[プロパティ] ノードが表示され、GUI 左側に [データベース アカウント] パネルが表示されます。
  3. [データベース アカウント] パネルに次のように設定を指定します。
    1. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。

    2. [すべてにプロパティを追加] をクリックします (このボタンをクリックしない場合、追加したグローバル プロパティはアクション スイートのツールに無視されます)。ドロップダウンからオプションを選択します。

      • 共有プロパティのみ使用: アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティだけを使用できます。

      • ローカルプロパティと共有プロパティを使用: アクション スイート中の関連するツールは、ユーザーが追加したグローバル プロパティおよび個々のツールで設定されたプロパティを使用できます。
    3. 必要に応じて残りのデータベース アカウント設定をします。
      • ファイルにアカウント設定を格納している場合、[ファイル] をオンにしてファイルのパスを指定します。
        • ファイルをリフレッシュ/リロードするには (たとえば外部で編集した場合など)、[構成設定のリフレッシュ] をクリックします。

      • このパネルで設定を指定したい場合、 [ローカル] を有効にし、ドライバー設定を指定します。次を参照: 

        詳細については「データベース構成パラメーター ( SOAtest)」 または 「データベース構成パラメーター (Virtualize)」を参照してください。

        • これらの値をファイルにエクスポートするには [構成設定のエクスポート] をクリックします。ファイルに値をエクスポートしたら、[ファイル]> [入力ファイル] コントロール (上記で説明) からファイルをインポートできます。この方法を用いれば、この同じアカウントを別のスイートに追加したいときに値を再入力する必要がありません。 

          なお、エクスポートされたプロパティ ファイルには以下のプロパティが含まれます:

          • driver
          • url
          • username
          • password
          • close.connection

          例:

          version=1
          driver=org.hsqldb.jdbcDriver
          url=jdbc:hsqldb:hsql://localhost/parabank username=sa
          password=dGVzdA==
          close.connection=true


グローバル認証

テスト スイートに認証方法を追加して、テストごとに認証設定を定義しなくてもテスト間で共有できるようにすることができます。すべてのテストに自動的に適用されるデフォルトの認証方法をテスト スイートに設定できますが、必要に応じて別の認証方法を使用するように個々のテストを構成することもできます。テスト スイートには複数の認証方法を作成できますが、デフォルトとして設定できるのは 1 つだけです。

共有認証方法を追加するには、次の操作を行います。

  1. テスト スイートを右クリックし、[新規追加] > [グローバル プロパティ] を選択します。  
  2. [認証] リストを展開し、認証方法を選択します。
  3. OAuth 2.0 を選択した場合は、[次へ] をクリックして付与タイプを選択し、[終了] をクリックします。他のすべてのタイプについては、[終了] をクリックします。認証方法がテスト スイートの Authentications ノードに追加されます。このテスト スイートで最初に作成された共有認証の場合、Authentications ノードは自動的に作成されます。
  4. ワークスペースに構成タブが開きます。設定をどのように完了させるかは、選択した認証方法によって異なります。
    • Basic
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 認証に使用するユーザー名とパスワードを入力します。
    • Digest
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 認証に使用するユーザー名とパスワードを入力します。
    • Kerberos
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 認証に使用するサービス プリンシパルを入力します。
        • Kerberos 認証の詳細については「その他の設定」の「セキュリティ設定」を参照してください。
    • NTLM
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 認証に使用するユーザー名とパスワードを入力します。
    • OAuth 1.0
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 認証に使用するカスタマー キーとカスタマー シークレットを入力します。
      3. [モード] ドロップダウンから認証モードを選択します。入力する必要があるその他のフィールドは、選択内容によって異なります。
        • リクエスト トークンの取得 (コンシューマー キーおよびシークレットを使用してサーバーにリクエスト トークンを要求します)
          1. スコープ: アクセスできる情報を制限します。この情報はコンシューマー キーに埋め込まれます。
        • リクエスト トークンとアクセス トークンの交換 (リクエストトークンとアクセストークンの検証コードを交換します)
          1. リクエスト トークン: サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
          2. リクエスト トークンのシークレット: サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
          3. 検証コード: サーバーから提供される検証コードを指定します。リソースのオーナーが許可を与えることを確認します。
        • OAuth 認証のリクエストに署名 (指定されたアクセス トークンおよびアクセス トークン シークレットを使用し、ユーザーのプライベートなリソースへのアクセス権限をクライアントに与えます)
          1. アクセス トークン: クライアントがユーザーのプライベート リソースにアクセスできるようにするために使用するアクセス トークンを指定します。
          2. アクセス トークンのシークレット: クライアントがユーザーのプライベート リソースにアクセスできるようにするために使用するアクセス トークン シークレットを指定します。

      4. Oauth の追加パラメーター (timestamp や nonce など) があれば、[パラメーター] に追加します。
        機能テストで OAuth 1.0 を使用する方法の詳細については、「OAuth 認証」を参照してください。

    • OAuth 2.0
      1. [名前] フィールドにわかりやすい名前を入力します。
      2. 付与タイプを選択します。入力する必要があるその他のフィールドは、選択内容によって異なります。
        • Login Suite: OAuth 2.0 認証コードを取得するために構成したテストを識別します。このテストは、必要に応じてリダイレクト URI、クライアント ID、スコープ、対象ユーザーなど、この構成から OAuth 設定を受け入れるように構成する必要があります。テストの実行後、認証コードは、後続の API テストで使用されるアクセス トークンと自動的に交換されます。このフィールドは、選択した付与タイプが Authorization Code または Authorization Code with PKCE である場合にのみ表示されます。
        • Redirect URI: OAuth 2.0 で保護されたアプリケーションの URI を指定します。これは、OAuth サーバーが認証コードを取得してトークンと交換するために必要になる場合があります。SOAtest は、実際にはこの URI にリクエストを送信しません。このフィールドは、選択した付与タイプが Authorization Code または Authorization Code with PKCE である場合にのみ表示されます。
        • Token URI: OAuth 2.0 認証サーバーのアクセス トークン エンドポイントを指定します。
        • Client ID: これらのパラメーターは、クライアント シークレットと共に、認証サーバーで認証するための資格情報を提供します。
        • Client Secret: これらのパラメーターは、クライアント ID と共に、認証サーバーで認証するための資格情報を提供します。
        • Scope: このパラメーターは、アプリケーションへの制限付きアクセスを要求するためにクライアントによって使用されます。認証サーバーに固有の値のカンマ区切りリストを入力できます。スコープが指定されていない場合、デフォルトのスコープが返されることがあります。
        • Audience: リソース サーバーの URI を指定します。
        • Code Verifier: Code Verifier を生成する方法を指定します。デフォルトは Automatic で、これが推奨設定です。他の方法を使用する場合、結果は、文字 A ～ Z、a ～ z、0 ～ 9、および - . _ ~ (ハイフン、ピリオド、アンダースコア、チルダ) を使用した暗号的にランダムな文字列であり、長さは 43 から 128 文字である必要があります。このフィールドは、選択した付与タイプが Authorization Code with PKCE である場合にのみ表示されます。
        • Challenge Method: コード チャレンジがプレーン テキスト バージョンのコード ベリファイアであるか、SHA-256 バージョンのコード ベリファイアであるかを指定します。このフィールドは、選択した付与タイプが Authorization Code with PKCE である場合にのみ表示されます。

      3. ヘッダーを使用してアクセス トークンを送信するか、クエリ パラメーターを使用して送信するかを選択します。 機能テストで OAuth 2.0 を使用する方法の詳細については、「OAuth 認証」を参照してください。

グローバル キーストア

キー ストアには、Web サービスを介して安全なサーバー/クライアント認証、XML 暗号化、XML デジタル署名を実行するために必要な証明書や秘密鍵が格納されます。キー ストアで指定した値は、SOAP Client、XML Encryption、および XML Signer ツールで使用できます。

SOAP Client ツールは、キー ストアの証明書を使用してサーバーとのハンドシェークを実行できます。XML Encryption ツールは、キー ストアの証明書を使用して XML ドキュメントを暗号化でき、また XML Signer ツールは、キー ストアの証明書および秘密鍵を使用して XML ドキュメントに署名したり作成者の証明を行うことができます。

Unlimited Strength Java Cryptography Extension が必要

キー ストアを使用するには、Unlimited Strength Java Cryptography Extension をダウンロードし、インストールする必要があります。詳細については 「JCE 前提条件」 を参照してください。

MQ SSL

MQ のグローバル テスト スイート プロパティを構成する場合は、キーストアとトラストストアを構成する必要があります。キーストア設定では、[証明書] タブで必要事項を記入するだけです。[証明書エイリアス] フィールドは必須ではありません。[秘密鍵] タブは MQ SSL には適用されません。

ローカル キー ストアの構成

ローカル キー ストアの構成は、テスト スイートのすべてのクライアントとツールに関係します。

  1. テスト スイート エクスプローラーでテスト スイートを右クリックし、[新規追加] > [グローバル プロパティ] を選択します。 
  2. [Global Key Store] を選択し、[終了] をクリックします。キー ストアの子を持つキー ストア ノードがテスト ケースに追加されます。
  3. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。
  4. [ローカル] オプションを選択し、[キー ストア] パネルの [証明書] タブで次の設定を指定します。
    1. キー ストアに証明書の秘密鍵が含まれている場合は [秘密鍵に同じキー ストアを使用] オプションを有効にします。
    2. [キー ストア ファイル] フィールドでキー ストア ファイルを指定します。[相対パスとして保持] を有効にし、相対パスとして (たとえばプロジェクトの共有を促進するために) 場所を保存します。
    3. [キー ストア パスワード] フィールドにキー ストアのパスワードを入力します。
    4. [キー ストア タイプ] ドロップダウンから、使用されているキー ストアのタイプ (JKS、PKCS12、BKS、UBER、PEM) を選択します。
    5. [ロード] をクリックし、利用可能な証明書/キーでエイリアスを入力します。パス、タイプ、およびキー ストア パスワードが有効でない場合、証明書/キーはロードされません。 
    6. [証明書のエイリアス] ドロップダウンで証明書のエイリアスを選択します。
  5. [秘密鍵] タブをクリックします。 
  6. [証明書] タブで [秘密鍵に同じキー ストアを使用] が無効になっている場合 (手順 4.a-4.d を参照)、適切なフィールドでキー ストア ファイル、キー ストアのパスワード、およびキー ストア タイプを指定します。 
  7. [ロード] をクリックし、利用可能な証明書/キーでエイリアスを入力します。パス、タイプ、およびキー ストア パスワードが有効でない場合、証明書/キーはロードされません。 
  8. [秘密鍵のパスワード] フィールドで秘密鍵のパスワードを指定し、変更を保存します。

キー ストア ファイルが外部で編集されている場合、[構成設定のリフレッシュ] をクリックして構成フィールドを再ロードし、グローバル キー ストアが最新の値を使用するようにできます。

グローバル キー ストア設定のエクスポート

グローバル キー ストアを構成した後、設定を .properties ファイルにエクスポートし、他の .tst ファイルでこの設定を参照して、プロジェクトのすべてのスイートに同じキー ストア設定を構成する必要がないようにすることができます。

  1. ローカル キー ストア設定を構成し、[構成設定のエクスポート] をクリックします。
     
  2. .properties 構成ファイルを保存する場所を選択します。

グローバル キー ストア設定のインポート

別のテスト シナリオからエクスポートされたキーストア構成を参照できます。これにより、証明書の設定を一度構成し、プロジェクト間で共有できます。ソース キー ストアの .properties 構成ファイルが更新されると、そのファイルを参照するテスト ケースも更新されます。

  1. テスト スイート エクスプローラーでテスト スイートを右クリックし、[新規追加] > [グローバル プロパティ] を選択します。 
  2. [Global Key Store] を選択し、[終了] をクリックします。キー ストアの子を持つキー ストア ノードがテスト ケースに追加されます。
  3. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。
  4. [ファイル] オプションを選択し、キー ストア設定の .properties ファイルを参照します。
  5. 変更を保存します。


グローバル ツール

Data Bank などのグローバル ツールをテスト スイートに追加し、テスト シナリオ全体で必要に応じて参照することで、毎回再作成する必要がなくなります。 

  1. テスト スイートを右クリックし、[新規追加] > [グローバル プロパティ] を選択します。 
  2. [グローバル ツール] メニューからツールを選択し、[終了] をクリックします 。新しいツール ノードがテストケース エクスプローラーに表示されます。
  3. ツールのコンフィギュレーション パネルでツールの設定をカスタマイズします。
  4. 「出力の追加」で説明されているとおり、ツールにさらに別のツールを連結できます。

テストでグローバル ツールを使用するには、テストまたは出力を追加する際に表示される [既存ツール] リストからツールを選択します。

スイート内の他のツールまたはグローバル ツールによって参照されているグローバル ツールを削除すると、参照も削除するように求められます。

ツールを削除しても参照を保持することを選択した場合、参照は非アクティブ化され、スイートに残ります。削除されたツールと同じ名前の新しいグローバル ツールが追加されると、参照は再び有効になります。

グローバル WS-Policy バンク

Web サービスの大きな特徴の 1 つが相互運用性です。Web サービスは、サービス コンシューマーが満たすべき要件を宣言するための標準化されたインターフェイスに依拠してサービス プロバイダーと相互に通信します。標準的な WSDL 仕様には、複雑なクライアント サイドの要件を宣言する機能がありません。これを補うため、WSDL は WS-Policy および WS-PolicyAttachment によって拡張され、サービス プロバイダーが WSDL 内で付加的な要件を定義することが可能になっています。WS-Policy は、他の WS-* 仕様に独自のポリシーのセットの定義を委ねています。そのような仕様の 1 つが、WS-Security に関するポリシーを定義する WS-SecurityPolicy です。

SecurityPolicy 拡張を使用する WSDL を読み取ると、SOAtest はポリシーに関する必要な設定をすべて備えたテスト ケースを自動的に生成します。テスト ケースの一部の属性については手動で設定する必要がありますが、基盤となるテストは自動的にセットアップされます。

注意

WS-Policy は簡易的な仕様です。WS-Policy はポリシーの設計を他の WS-* 仕様に委ねています。また、ベンダーに依存するポリシーの大規模なセットも存在します。WS-* の範囲は広大であるため、SOAtest は WS-SecurityPolicy のアサーションだけをサポートしていますが、他の一般的なアサーション セットも処理できるよう、プロセッサの拡張が続けられています。

WS-Policy バンクを追加するには、以下の操作を行います。

  1. 目的のテスト スイート ノードを選択し、ツールバーの [プロパティの追加] をクリックします。
  2. [グローバルの追加] ウィザードで [WS-Policy バンク] を選択し、[終了] をクリックします。テスト ケース エクスプローラー ツリーに WSDL ポリシー ノードが表示されます ( [WS-Policy バンク] ブランチの下に追加されます。[WS-Policy バンク] ブランチがまだない場合は、ブランチが追加されます)。GUI の右側に WSDL ポリシーの設定パネルが表示され、SOAP client ツールにさまざまな WSDL-security テストが連結されます。
  3. [WSDL ポリシー] パネルで、以下のように設定を設定します。
    1. デフォルトの名前を変更したい場合は、[名前] フィールドに新しい名前を入力します。
    2. [WSDL URL] フィールドに、この Web サービスがアクセスできる WSDL URL を指定します。WSDL を入力するか、[参照] をクリックして指定します。
    3. 指定されたロケーション URL から WSDL をリフレッシュして再解析するには、[WSDL のリフレッシュ] をクリックします。
    4. [グローバル ポリシー] エリアで、非 XML 形式で表現されたポリシーの定義とともに、WSDL が示唆する代替ポリシーを確認します。左側のツリーの各セクションは、WSDL 内のグローバル ポリシー要素を表しています。

  • No labels

Need assistance? Visit our support page