多くの SOAtest ユーザーは、Parasoft SOAtest でテスト スイートを生成するに従い、何千ものテスト ケースを作成します。これらのテストを効率的かつ効果的に維持できることは重要です。なぜならテスト対象のシステムは変化するからです。
このセクションでは、多数のテストの管理や更新にかかる時間を節約するための機能やアドバイスについて説明します。
サービス定義およびスキーマの変更管理
サービス定義またはスキーマで定義された Web サービスをテストする場合、次のベスト プラクティスを推奨します。
- フォーム入力を使用してテストを WSDL/WADL/スキーマ/ OpenAPI/Swagger/RAML 定義に従わせます。SOAP Client ツールと Messaging Client ツールでは、それぞれ [WSDL] タブ (SOAP Client) および [スキーマ] タブ (Messaging Client) に “～に従う” オプションがあります。REST Client ツールにも、WADL および RAML/OpenAPI/Swagger 定義の類似したオプションがあります。このオプションがオンの場合、セッションでテストが実行されると (たとえば、夜間テスト中にコマンドラインからテストを実行した場合など) 次の事象が生じます 。まず、指定の場所にある定義ファイルがパースされます。次に、[フォーム入力] および [フォーム JSON] ビューから生成されたリクエストが、自動的に直近にパースされた定義ファイルに従います。 この機能の詳細については、以下に記載されています。
- エンドポイント URL は、環境変数を使用してグローバルに更新を管理するか、SOAP Client で“WSDL” オプションを選択して URL が WSDL に基づいて自動的に更新されるようにします。
- 変更アドバイザーを使用して更新が必要なテストを確認し、変更テンプレートを適用して適切なテストを更新します。
- Parasoft の検索と置換の機能を使用して、Assertion ツールや Data Bank ツールの XPath 値などのツールの値を更新します。
- テストに関連する WSDL、 WADL、 そして/または スキーマの回帰テストを作成します。SOAtest の テスト スイート ウィザードには機能テストに加えて WSDL/WADL テストを作成するオプションが含まれています。これらの WSDL/WADL テストのひとつは回帰テストです。最新バージョンの WSDL/WADLをキャプチャして変更指標として働きます。定義ファイルがサーバー上で変更されるとテストは失敗し、変更を通知します。
- テスト スイートレベルでの回帰コントロールの更新機能を使用します。
フォーム入力の自動更新
[定義/スキーマ に従う] オプションがオンの場合、SOAP Client ツール、 Message Stub ツール、および Messaging Client ツールの [フォーム入力] ビューが自動的に更新されます。REST Client ツールで WADL、RAML または OpenAPI/Swagger 定義 に従うオプションをオンにした場合も同様です。この動作は、これらのツールの [リフレッシュ] ボタンをクリックして定義ファイルを "リフレッシュ" することで実行されます。Parasoft SOAtest は既存のフォーム入力設定を保存しようとするので、最低限の手動変更のみ必要です。Parasoft SOAtest は、既存のテスト データをマップする精巧なヒューリスティックを使用しています。
たとえば、 既存の要素に影響を与えることなく、新しい要素は追加され削除される要素は削除されます。また、要素タイプの変更は可能な限り現行の値を引き継ごうとします。新しい定義ファイルに応じたテスト データの再マップは、いつも成功するとは限りません。一般的にこのプロセスは、比較的小さな変更である、スキーマ ファイルによって定義されたデータ タイプの変更の際に成功する傾向にあります。しかし、比較的大きな変更である、定義ファイルの文書によって定義されたオペレーションの変更は成功する可能性が低いです。
変更アドバイザー、 変更影響度分析でフォーム入力で指定したメッセージを更新
変更アドバイザーを用いて、メッセージ ツールが送信するメッセージに、サービス定義の変更 (たとえば、操作の名前変更、要素やタイプの追加、名前空間の変更など) がどのように影響するかを確認するために変更影響度分析を実行できます。
次のいずれかを分析します。
テストが作成されたときにアクセスされた元のサービス定義と、同じサービス定義の現状とを比較する。
元のサービス定義を異なるサービス定義ファイルと比較する。
この解析結果は、テストをアップデートする必要がある変更のスコープと性質を評価するのに役立ちます。ユーザーや、設計者などの他のチーム メンバーによって、どのように新しいサービスを以前のサービスにマップするかを定義する変更テンプレートが定義されたら、自動的にテストをアップデートするためにその変更テンプレートを個別またはまとめて適用できます。
詳細については、「変更アドバイザーでメッセージを更新」を参照してください。
Diff ツールの回帰コントロールを自動更新
XML Diff ツールを使用したサービス レスポンスの検証は、一般的であり効果的な方法です。完全性を検証するためにすべてのレスポンス メッセージをキャプチャするのに便利です。また、右クリックをして [回帰コントロールの作成/更新] を選択し、ウィザードの指示に従うことで、さまざまなバッチ更新メカニズムが、テストまたはテスト スイート レベルで実行されることを可能にします。より選択的に回帰コントロールの更新を管理したい場合、テスト スイートのエディターを開き、[実行オプション] タブの [回帰オプション] サブタブを開いて、テスト スイート レベルで回帰コントロールが更新されたときにどのテストが更新されるべきかを選択します。
検索と置換を使用してその他のツールの値を更新
Parasoft の検索と置換機能は、サービスや環境が発展するに従って変更する必要がある値を確認し、更新するのに役立ちます。たとえば、要素や名前空間を変更した場合、Assertion ツール、 Diff ツール、 Data Bank ツールで影響のあった XPath の値に検索と置換を使用できます。
詳細については、「検索と置換を使用してツールの値を更新」を参照してください。
テスト更新のワークフロー
上記の機能で試験者は次のステップに従います。
- WSDL/WADL/スキーマの回帰テストの失敗を検知する。
- 差異がリクエスト メッセージの構成の変更を示す場合、テストの更新が必要な可能性がある。
- 差異がこのテスト スイートでテストしていない エンドポイントまたはメッセージ/操作の変更を示す場合、回帰コントロールを更新してテストが成功することを確認する。
- いくつかのレスポンス エラーを検査する。
- 予期していたコンテンツと異なるために、リクエスト メッセージがサーバーに拒否されることを示した場合は、変更影響度分析を実行してください。
- その他の場合は失敗は、サービスまたはサービスへ導入された実際の回帰/バグに予期されていたデータの変更に関連しているかもしれません。
- 次のように、必要に応じて影響のあったツールを更新します。以下のことが可能です:
- 単純な変更には、フォーム入力の自動更新を有効にします。
- より複雑な変更をカバーするために、変更テンプレートを適用します (たとえば、名前を変更した操作のアドレス指定、追加された要素やタイプ、変更された名前空間など)。
- 検索と置換を使用して他のツールの値 (アサーション、 XPath など) を更新する。
- 必要に応じて Diff ツールで回帰コントロールを自動更新する。
変更管理に関するその他の推奨事項とプラクティス
- 高揮発性のサイクル中にサービスをテストする場合は、Diff 回帰コントロールの代わりに XML Assertor ツールを使用します。テスト ケースに関係があるメッセージの特定部分の検証を構成できるので、サービスが発展するに従って更新する手間を最小限にできます。
- SOAP ヘッダーはテスト スイート レベルで定義し管理できます。ツールバーの [プロパティの追加] ボタンをクリックし、[グローバル プロパティ] > [SOAP Headers] オプションを選択します。他にもさまざまな生成物や構成をこのダイアログで設定でき、重複を防いで更新アクティビティのより良い管理をするためにテスト スイート レベルで再利用できます。
- 「変更アドバイザー」や「Parasoft 検索と置換」といった機能を適用していないテスト資産に、大量更新を実行するのは比較的簡単です。しかし、多数のテストに実行する必要がある場合は、上級者なら 直接 tst ファイルの内容に検索/すべて置換を実行することを考慮するかもしれません。SOAtest の tst ファイルは XML 形式で保存されているので、.tst ファイルをテキスト エディターで開き、そのような更新を実行できます。これを行う最善の方法としては、現行の値でファイルを検索し、必要な変更に置換します。直接編集する前に必ずバックアップを取得してください。
- 「テスト作成のベスト プラクティス」に従ってください。
