ここまでの操作で、共有メカニズム、コラボレーション ワークフロー、およびテスト手法が確立されました。このセクションでは、効果的で保守できるテストを効率的に作成するために、SOAtest の最適な使い方のヒントを説明します。
SOAtest テスト作成ウィザードを使用する
SOAtest は、WSDL、OpenAPI/Swagger または RAML の定義、UDDI レジストリ、WADL、WSIL ファイル、ESB モニタリング、トラフィック ログ ファイルから新規に Web サービス テスト プロジェクトを作成できます。Web UI テストは、ブラウザーを使って記録することで作成されます。これらの機能は、ユース ケース シナリオ テストの初期ビルディング ブロックの作成をすぐに開始するのに役立ちます。
コピー/切り取り/貼り付けを使用する
テストとテスト スイートを新規に作成するときに、1 個ずつ最初から作成するのではなく、既存のテストとテスト スイートを活用します。利用できる .tst ファイル、テスト スイート、テスト、および連結されたツールに対して、コピー/切り取り/貼り付けを実行できます。これらのコマンドは、キーボードから実行することも (CTRL+C、CTRL+X、CTRL+V)、右クリックから実行することもできます。
複数のテスト スイート (.tst) ファイルにテストを分割する
少ないテスト スイート (.tst) ファイルにすべてのテストをまとめてはいけません。少ない .tst ファイルに大量のテストをまとめると、オープンされてメモリ上に置かれるテストが増えるため、SOAtest の速度が低下することがあります。さらに、リポジトリでリビジョン コントロールを使用するメリットが減り、ネットワークを介するリモート ユーザーがパフォーマンスの低下を経験する可能性があります (その理由は、転送する .tst ファイルのサイズが大きくなるからです)。
SOAtest は、大量のテスト ケースの管理を容易にするために、ユーザーがファイルをプロジェクトとディレクトリにまとめて管理するのを助けます。その結果、リソース ツリーのバランスが取れ、ユーザーは、プロジェクト、フォルダー、テスト スイート ファイル、およびテスト スイートの整理された階層から、より多くのものを得ることができます。
一貫したパターンに従ってテスト スイート (.tst) ファイルを分割する
Web サービスの規模によって、分割パターンは「各テスト ファイルが 1 つの WSDL に関連付けられるパターン」または「各テスト ファイルが WSDL 中の 1 つの操作に関連付けられるパターン」になるでしょう。Web アプリケーションの場合、Web サイトの特定エリアのテストは、エリア名に基づいて複数の .tst ファイルに分割できます。
理想的な分割方法は、「ファイルの数」と「含まれるテストの数」のバランスを取ることによって、テストが探しやすくなるようにし、そしてレポートが理解しやすくなるようにすることです ( レポートはテストの編成を反映するからです)。
サービス定義テスト、サービス単体テスト、機能テストを複数のテスト スイートに分離する
テスト スイート ファイルごとに、3 種類の主要なテスト スイートを用意することを推奨します。
- WSDL/OpenAPI/Swagger/RAML/WADL テスト
- 単体テスト
- 機能テスト
このようにテストを編成すると、これらの検証的側面がすべてカバーされたかどうかを、簡単に評価することができます。
サービス単体テストをポジティブ/ネガティブ テスト スイートにまとめる
効率的で良く編成された単体テスト用の適切なレイアウトを使ってプロジェクトを新規作成する理想的な方法は、WSDL からテストを生成するウィザードで [ポジティブおよびネガティブ単体テストとして構成] レイアウトを選択することです。両方のタイプのテストを作成することは、十分なテスト カバレッジを達成するために重要であり、このレイアウトはさらにポジティブまたはネガティブ テストが必要かどうかを素早く判断するのに役立ちます。
テストとテスト スイートに適切に名前を付ける
個々のテストとテスト スイートに、ユーザーやチームにとって意味のある名前を必ず付けるようにしてください。
デフォルトでは、SOAtest は Web サービス テスト スイート名には WSDL バインディング名を使用し、SOAP Client テスト名には操作名を使用し、Browser Playback テスト名にはブラウザー アクションを使用します。ただし、これらの名前はテスト対象をより反映した名前に変更することもできます。デフォルトの名前 (たとえば Test Suite、Test 1、Test 2 など) を変更するには、テストまたはテスト スイートの構成パネルで新しい値を入力します。
意味のある名前を付けることは、テストの保守に役立つだけでなく、レポートの外観と読みやすさを向上させます。もうひとつの有用な方法は、個々のテストまたはテスト スイートの [注釈] パネルで詳細とコメントをさらに追加することです。
回帰コントロール、アサーション、または他の成功インジケーターをすべてのテストに追加する
成功条件をテスト側に設定することが重要です。成功条件がない場合、SOAtest は何がテストの失敗を構成するのかを把握できないため、回帰エラーが検出されない可能性があります。
テストの失敗を正確に特定するには、SOAP Fault レスポンスを取得するだけでなく、回帰コントロールまたは成功インジケーターがテストに必要です。 適切なレベルと種類の検証を XML メッセージまたは HTML コンテンツに追加するために、XML Assertor ツール、Diff ツール、Extension Tool (以前の Method ツール)、Search Tool などを連結して組み合わせることができます。
繰り返し実施するツールの構成やテストには “既存ツール” を使用する
SOAtest では、テスト スイート ファイル レベルでアクセスできるグローバル ツールを追加することができます。複数のテストで 1 個の検証ツールを使うことを考えている場合 (たとえば再利用できる回帰コントロールと Diff ツール)、その検証ツールをテスト スイートに追加し、既存のツールとして参照します。そうすれば、複数のテストで何度もツールを最定義する必要がありません。
繰り返し実施する構成には “共有プロパティ” を使用する
SOAtest では、グローバル プロパティを追加できます。無視される Diff ツール XPath、 JMS 接続設定、データベース接続設定といった設定をテスト スイート ファイル レベルで一箇所で定義し、この設定を参照して再利用できます。その結果、今後テストを管理したり変更するのが簡単になります。
テスト スイート参照を使用する
テスト スイートを右クリックして [テストの追加] > [テスト スイートの参照] を選択して、1 つのテスト スイートから別のテスト スイートへの参照を作成できます。この機能を使用すれば、すべてのプロジェクト ファイルでするべきテスト セット (一般的なログオンや認証のテストなど) を定義し、複数のファイルで参照して再利用できます。
環境を使用する
Parasoft SOAtest では、変数と値のセットを定義することができ、これらの変数をほとんどあらゆる編集可能フィールドで参照できます。多くの場合、これはホスト名と URL を設定するのに役立ちます。そうすることで、異なる環境で同じテストを実行できます。作成した環境の構成は、1 つのテスト スイート ファイルで共有することも、環境構成ファイルを参照して複数のテスト スイート ファイルで共有することもできます。
