自動インターフェース・テスト・フレームワーク

サービス指向インテグレーション (SOI) サービス

自動化されたインターフェースのテストは、手動でテストする場合に生じる矛盾を軽減します。コードが変更されるたびにリグレッション・テストによってコードを保証するにはインターフェースのテストを包括的に行うことが極めて重要となりますが、テストを手動で行うのでは、すべてのテスト・ケースを完全にはテストしきれないものです。この記事で紹介するフレームワークは、サービス指向インテグレーション・ソリューション用の自動インターフェース・テストを作成するための基礎となります。

Sravana Krishna, Senior Architect, IBM

Sravana Krishna は、エンタープライズ・インテグレーション・チームのシニア・アーキテクトです。これまで 12 年以上、さまざまなミドルウェア製品と技術を使用して、多くのクライアントの EAI プロジェクトを実装してきました。



Saran Sankar, Architect, Blue Connect

Saran Sankar は、SOI においてアーキテクトとしての経験が数年あります。これまで 8 年以上、さまざまなミドルウェア製品と技術を使用して、多くのクライアントの EAI プロジェクトを実装してきました。



2010年 4月 14日

はじめに

この記事では、サービス指向インテグレーション (SOI) タイプのインターフェースを対象とした、実績のある自動インターフェース・テスト・フレームワーク (ITF) を紹介します。このフレームワークは、インターフェースのユニット・テストに使用するテスト・ケースの管理機能とグループ化機能、そしてテスト実行後のレポートを作成するための機能を提供します。ここで説明する手法は、あらゆるエンタープライズ・サービス・バス (ESB) やミドルウェア製品に適用することができます。

サービス指向インテグレーションには、ミドルウェア環境の外部にあるアプリケーションやデータベースとの統合が必要になってきます。このようなソリューションの開発はミドルウェア製品を使用して行われることが多く、ミドルウェア製品に付属のグラフィカル・エディターを使用したり、ミドルウェア製品によってコード・スニペットを実行可能コードに変換したりします。そのため自動テスト・フレームワークがなければ、インターフェースを構成する個々のコンポーネントを徹底的にテストするのは容易なことではありません。

自動インターフェース・テスト・フレームワークは、サービス指向インターフェースのホワイトボックス・テストを行う手段となります。ホワイトボックス・テストでは、内部構造を理解していないと、システムを完全にテストする最善の方法がわかりません。そこで強力なツールとなるのが、自動インターフェース・テスト・フレームワークです。このフレームワークが提供するユニット/コンポーネント・テスト環境では、コンポーネントを単独でテストすることも、適切なスタブやドライバーと併せてテストすることもできます。また、このフレームワークは、さまざまな環境でインターフェースのリグレッション・テストおよびスモーク・テストをサポートするように簡単に拡張することができます。このフレームワークには以下の機能があります。

  • 期待される結果に対するテスト
  • 共通テスト・データの共有
  • テスト・ケースの選択的実行、またはテスト・ケース・グループの実行

さらにこのフレームワークは、要件を形式化したり、アーキテクチャーを明確にしたりする上でも役立つ他、コードのデバッグ、統合、リリース、最適化、テストにも利用することができます。


インターフェース・テスト・フレームワークの目的

フレームワークを使用してテスト・ケースを作成するという行為によって、設計や実装の不備が見えてくることは珍しくありません。ESB システムで最初に行われるのはユニット・テストで、ユニット・テストでは設計の問題や足りない機能が頻繁に検出されます。普通の開発者にとって、ITF を使い慣れるまでには時間も訓練も要するものですが、いったんユニット・テスト・スイートを作成すれば、それは ESB システムを使用するためのドキュメントとしての機能を果たします。ITF では、ユニット・テストをデータ・ソース内のレコードごとに 1 回実行し、それによって集められたデータにユニット・ソースが完全にアクセスするという、データ駆動型のユニット・テストを簡単に作成することができます。

ITF の最も重要なメリットの 1 つとして考えられるのは、しっかりとしたテスト・スイートが作成されていれば、コードの開発者は自分が作成したコードを他の開発者に渡して、そのコードの保守や機能の強化を任せられることです。コードを渡された開発者がバグのあるコードを元の機能に紛れ込ませてしまったとしても、ユニット・テストによってその失敗が検出され、問題を診断できる可能性が十分にあります。

ITF は、リグレッション・テストに不可欠の要素です。リグレッション・テストには、新しい機能が追加された後、ソフトウェアを再テストしてエラーやバグが入り込んでいないことを確実にするという作業が伴いますが、ITF を使用すれば、リグレッション・テストにかかる時間が大幅に短縮されます。


ITF の機能

以下に、ITF がサポートする重要なソフトウェアのテスト機能のいくつかを抜粋して説明します。

テスト駆動開発

テスト駆動開発 (TDD) とは、ユニット・テストを作成してからテスト対象のコードを作成する開発プラクティスのことです。このプラクティスでは開発者に、システムを設計して構築する前に、仕様に基づいてテスト・ケースを作成するように奨励しています。TDD により、その後の継続的開発サイクルで必要となる手順が少なくなり、管理しやすくなります。TDD 実装をサポートする ITF は、企業のなかで中心的な役割を担うことが可能です。

アサーション

ユニット・テストが成功したかどうかを判断するのに最も一般的な方法は、期待される結果と実際の結果とを比較することです。アサーションとは、開発者がテスト結果として期待される結果を指定し、テスト実行後の実際の結果と比較する作業を容易にする ITF の機能を指します。期待される結果に、実行時に設定される動的な値が含まれる場合、その値は比較に応じた正規表現を使用して処理されます。この機能は、テストの実行結果を比較するには不可欠です。

コード・カバレッジ (テスト対象範囲)

ITF には、コード・カバレッジに対する完全なサポートが備わっています。コード・カバレッジはテストの実行中に追跡ロジックを自動的に組み込み、プロセス内のどのアクティビティーが実行されるかをモニターします。その最も重要な成果は、テストで網羅されなかったコードの領域を特定できることです。コードには一般的な状況では実行されない分岐ロジックや例外処理ロジックが含まれている場合がよくあります。このような領域を特定するためには、コード・カバレッジを使用することが非常に重要になります。コード・カバレッジは有用なツールではあるものの、これだけに頼ってユニット・テストの有効性を判断するべきではありません。コード・カバレッジはコードがどのように実行されたのかに関する情報を提供しないため、データやタイミングが異なる場合に発生するエラーを見逃してしまう可能性があるからです。コードが正確かつ完全で回復力に優れていることを確実にするには、多種多様な入力および実行順序で行う一連のユニット・テストが役立ちます。したがって、コード・カバレッジはテストで見逃しているコードを特定するための支援ということになります。

ネガティブ・テスト (失敗するパターンのテスト)

堅牢なコードには、あらゆる例外のシナリオを、中断することなく簡潔に処理することが期待されます。そのため、開発者は大抵の場合、例外発生時にコードが正常に振る舞うことを検証したいと思うものです。例外は、誤った入力データや無効な入力データを提供することによって発生させることができます。一般に、例外をスローするユニット・テストは失敗したとみなされますが、ITF はネガティブ・テストのシナリオをサポートするので、開発者はテスト・ケースが成功するパターンであるのか、失敗するパターンであるのかを指定することができます。

ロギングと例外カバレッジ

優れたコーディング・プラクティスには、コードによる効率的なロギングおよび例外処理が必要です。ユニット・テストの一環として、開発者はコードがメッセージを期待通りにログに記録するかどうか、そして例外が正しく処理されるかどうかを検証しなければなりません。一般的に、企業ではグローバル監査ロギング (GAL) フレームワークとグローバル例外処理 (GEH) フレームワークを使用しています。ITF は、GAL および GEH フレームワークと問題なく統合することができます。ITF では開発者が特定のテスト・ケースに期待されるログおよび例外メッセージの数を指定することができるため、開発者はこの機能を使用して、コードがすべてのログと例外メッセージを正しくルーティグしているかどうかを知ることができます。

リグレッション・テスト

リグレッション・テストの目的は、検出されたエラーに基づいて、バグが正常に修正されたことを確実にすると同時に、当初の問題を修正するプロセスで他のエラーが紛れ込んでいないことを保証することです。リグレッション・テストは、バグの修正によって変更されたソフトウェアのコード/要件を適切に網羅するのに必要な最小限のテスト・スイートを体系的に選択するという方法で、バグの修正を効率的にテストするためによく使用されます。リグレッション・テストの一般的手法には、前に実行したテストを再実行し、修正したエラーが再発するかどうかをチェックするという作業も含まれます。ITF からはテスト・ケースを極めて簡単かつ素早く再実行できるため、ITF はリグレッション・テスト・プラットフォームとして使用するのに最適です。

パフォーマンス・テスト

パフォーマンス・テストは、システムの特定の側面が、特定の作業負荷でどれだけの速度で実行されるかを判断するために行われます。また、システムに備わった他の品質特性 (スケーラビリティー、信頼性、リソース使用量など) の有効性の確認や検証を行う役目も果たします。パフォーマンス・テストが目標とするのは、実際のコーディング作業に取り掛かる前に、システムの設計とアーキテクチャーにパフォーマンスを盛り込むことです。ITF で作成されたテスト・ケースは、複数のマシンから同時に実行することも、繰り返し実行することもできることから、ITF は優れたパフォーマンス・テスト・プラットフォームになります。

フレームワークの要件

ITF が満たす重要な要件としては、以下のものが挙げられます。

  1. ITF では新しいテスト・ケースを追加できる必要があります。
  2. ITF は関連する複数のテスト・ケースを 1 つのテスト・スイートにグループ化できる必要があります。
  3. ITF は個別のテスト・ケースを実行してそれぞれの要約レポートを生成することも、テスト・ケース・グループや ITF で作成されたすべてのテスト・ケースをまとめて実行し、要約レポートを生成することもできる必要があります。
  4. ITF では各種のエンドポイントを作成し、さまざまなテスト・ケースで再利用できる必要があります。
  5. ITF のテスト・ケースには以下の情報が含まれます。
    1. 固有名
    2. 説明
    3. テスト・ケースが属するグループ
    4. 入力エンドポイントの詳細
    5. 出力エンドポイントの詳細
    6. タイムアウト値
  6. ITF のエンドポイントには以下の情報が含まれます。
    1. エンドポイント・タイプ: WS (Web サービス) または JMS (ava Message Service)。エンドポイントのタイプにより、テスト対象のサービス (JMS-JMS、WS-WS など) が決まります。
    2. メッセージ・タイプ: バイト、テキストなど
    3. エンコーディング・タイプ: この情報は、バイト・メッセージの場合に必要となります。デフォルトは、UTF-8 です。
    4. 比較フラグ: このフラグは、フレームワークが実際の出力を期待される出力と比較して、テストをアサートする必要があるかどうかを示します。
    5. ヘッダーの詳細
      1. destinationQueue: 宛先キューの名前
      2. replyToQueue: replyTo キューの名前。WS エンドポイントの場合にのみ必要となります。デフォルトは一時キューです。
      3. JMSPriority: JMS メッセージ優先度。デフォルトは、4 です。
      4. JMSDeliveryMode: JMS 配信モード (PERSISTENT または NON_PERSISTENT)。デフォルトは PERSISTENT です。
      5. JMSCorrelationID
      6. requestTimeout: メッセージのタイムアウト値。WS エンドポイントの場合にのみ必要です。
    6. プロパティーの詳細
      1. SOAPAction: WS エンドポイントの場合にのみ必要です。
    7. Body: JMS エンドポイントの場合にのみ必要です。
    8. Request: WS エンドポイントの場合にのみ必要です。Web サービスの SOAP エンベロープが含まれる必要があります。
    9. Reply: WS エンドポイントの場合にのみ必要です。Web サービスの SOAP エンベロープが含まれる必要があります。
  7. ITF テストの結果には、以下のいずれかが含まれます。
    1. Success: すべて正常に機能したことを示します。
    2. Failure: 受信した出力が期待される出力とは異なっていたことを示します。
    3. Error: テスト対象のプロセスにエラーが発生し、比較用の出力を生成できなかったことを示します。
  8. ITF は、デプロイ可能なあらゆる環境で実行可能です。
  9. ITF は GAL および GEH に記録されたログ・エントリーをチェックすることができます。
  10. ITF はテスト・ケース実行のバージョン管理に対応可能です。

アーキテクチャー

ITF のテスト・エンジン・コンポーネントは、テスト・ケースの追加/作成/変更、テスト・ケースの実行、実行結果の生成を行うためのユーティリティーを備えています。ITF は、テストするインターフェースをビルドするために使用するミドルウェア製品と一緒に実装することが可能です。そのように実装した場合、統合開発環境 (IDE) とのシームレスな統合が容易になります。

ITF はテスト・ケース、エンドポイントおよびテストの実行に関するすべての情報を、バックエンドのデータベースのテーブルに保管します。すべてのテスト・ケース情報をデータベースに保管することで、開発者がリポジトリーに任意のロケーションからアクセスできるというメリットがあります。しかも、このリポジトリーは特定のワークステーションと密に結合しているわけではないため、同じテスト・ケースを異なるロケーションから実行することができます。ITF は、コードが使用するのと同じ接続パラメーターとクライアント・ライブラリーを利用することから、コードがアクセスするすべての ESB コンポーネントに完全にアクセスすることができます。さらに、構成パラメーターはオンザフライで変更することが可能です。そのため、多種多様な環境で容易にテストできるようになっています。エンタープライズ・メッセージング・サービス、Java データベース接続性 (JDBC) コンポーネント、SOAP エンドポイントなどの ESB の各種コンポーネントには、ITF の組み込み接続設定によって簡単にアクセスすることができます。

ITF はバックエンドのテーブルに対してクエリーを実行し、ユーザー定義のカスタマイズ可能レポートを生成します。これらのレポートは、テスト・ケース関連のレポートにすることも、またはテスト実行関連のレポートにすることもできます。また、ITF では要約レポートまたは詳細レポートのいずれかを指定することもできます。

図 1. ITF のコンポーネント
ITF のコンポーネント

設計

ITF のオブジェクト

ITF が使用するオブジェクトは、TestCase、InputEndpoint、OutputEndpoint、Group の 4 つです。TestCase オブジェクトはテスト・ケースを定義します。表 1 に、TestCase オブジェクトのすべての属性を記載します。InputEndpoint は、ITF と入力側のテスト対象のコードとの間でやりとりされるメッセージのタイプを定義するオブジェクトです。表 2 に、InputEndpoint オブジェクトのすべての属性を記載します。OutputEndpoint は、ITF と出力側でのテスト対象のコードとの間でやりとりされるメッセージのタイプを定義するオブジェクトです。表 3 に、OutputEndpoint オブジェクトのすべての属性を記載します。Group オブジェクトは、テスト・ケースとテスト・スイートの関係を定義します。表 4 に、Group オブジェクトのすべての属性を記載します。

表 1. TestCase オブジェクト
フィールド名必須/オプション説明
Name文字列必須テスト・ケースの名前
Description文字列必須テスト内容の説明
Outcome文字列必須テストの結果 (Success または Failure)
InputEndpointオブジェクト必須表 2 で説明する入力エンドポイント
OutputEndpointオブジェクト必須表 3 で説明する出力エンドポイント
Timeout整数必須テスト・ケースのタイムアウト値
ExpectedGALCount整数必須監査ログに期待されるエントリー数
ExpectedGEHCount整数必須例外ログに期待されるエントリー数
Groupオブジェクト必須テスト・ケースが属するグループ (表 4 で説明)
表 2. InputEndpoint オブジェクト
フィールド名必須/オプション説明
Name文字列必須エンドポイントの名前
JMSPriority整数必須リクエストの JMS 優先度
Request文字列必須テスト・ケースのリクエスト・メッセージ
Replyオブジェクト必須テスト・ケースのレスポンス・メッセージ
表 3. OutputEndpoint オブジェクト
フィールド名必須/オプション説明
Name文字列必須エンドポイントの名前
Body文字列必須エンドポイントでのメッセージ本文
表 4. Group オブジェクト
フィールド名必須/オプション説明
Name文字列必須テスト・ケース・グループの名前

ITF のプロセス・フロー

以下に示す図 2、3、および 4 のそれぞれで、テスト・ケース/グループ/エンドポイントの定義プロセス、テスト・ケース/グループの実行プロセス、ITF によるテスト実行レポートの生成プロセスを説明します。

図 2. テスト・ケース/グループ/エンドポイントの作成
テスト・ケース/グループ/エンドポイントの作成

入力:

  1. テスト・ケースの名前
  2. テスト・ケースの説明
  3. テスト・ケースが属するグループ
  4. 入力メッセージと出力メッセージ。メッセージの内容は以下のとおりです。
    1. エンドポイント参照
    2. WS エンドポイントの場合はリクエスト/レスポンス・メッセージ
    3. JMS エンドポイントの場合は本文
    4. その他すべてのエンドポイント・フィールドに対する優先内容
  5. 期待される GAL/GEH カウント
  6. 期待される結果 – Success、Failure または Error
  7. タイムアウト – フレームワークが入力エンドポイントでメッセージを送信した後に、出力エンドポイントで出力を待機する時間
入力例
<?xml version = "1.0" encoding = "UTF-8"?>
<Input xmlns:def = "http://www.ibm.com/ams/common/unittestframework/definition">
	<TestCase>
		<def:Name>Sample</def:Name>
		<def:Description>Sample TestCase for illustration</def:Description>
		<def:Outcome>S</def:Outcome>
		<def:InputEndpoint>
			<def:Name>SampleWSEndpoint</def:Name>
			<def:JMSPriority>7</def:JMSPriority>
			<def:Request><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
                <SOAP-ENV:Envelope xmlns:SOAP-ENV=
                                        "http://schemas.xmlsoap.org/soap/envelope/">
                <SOAP-ENV:Body></SOAP-ENV:Body></SOAP-ENV:Envelope>]]>
                                         </def:Request>
			<def:Reply>Some reply with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Reply>
		</def:InputEndpoint>
		<def:OutputEndpoint>
			<def:Name>SampleJMSEndpoint</def:Name>
			<def:Body>Some body with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Body>
		</def:OutputEndpoint>
		<def:Timeout>10</def:Timeout>
		<def:ExpectedGALCount>1</def:ExpectedGALCount>
		<def:ExpectedGEHCount>0</def:ExpectedGEHCount>
		<def:Group>
			<def:Name>Sample</def:Name>
		</def:Group>
	</TestCase>
</Input>

ステップ:

  1. 入力を取得します。
  2. データベース内の既存の定義に照らし合わせて入力をチェックします。
  3. 必要に応じてエンドポイントを作成します。
  4. 必要に応じてグループを作成します。
  5. テスト・ケースを作成します。
  6. グループとテスト・ケースの間の関係を作成します。
  7. 成功および失敗したエンドポイント、グループ、およびテスト・ケースの要約情報を返します。

出力: テスト・ケース/グループ/エンドポイントが作成されます。

図 3. テスト・ケース/グループの実行
テスト・ケース/グループの実行

入力:

  1. テスト・ケースの名前
  2. グループの名前
入力例
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
  <TestCases>
    <TestCase xmlns = "http://www.ibm.com/ams/common/unittestframework/execution">
	<Name xmlns = "http://www.ibm.com/ams/common/unittestframework/definition">
             testcase1</Name>
		</TestCase>
	</TestCases>
</Input>

メイン・ステップ:

  1. 入力を取得します。
  2. 入力に基づき、データベースから該当するすべてのテスト・ケースを取得します。
  3. テスト・ケースごとにプロセスを実行します。
  4. テスト・ケースごとに結果を収集します。
  5. データベース内の要約情報を更新します。
  6. 要約情報および詳細情報を返します。

サブステップ:

  1. メッセージのタイプ、入力エンドポイント、出力エンドポイントをチェックします。
  2. 出力エンドポイントのリスナーを起動します。
  3. 入力エンドポイントでメッセージを送信します。
  4. 入力エンドポイントが WS の場合は、レスポンスを待機します。
  5. 出力エンドポイントが WS の場合は、メッセージを受信した時点でレスポンスを送信します。
  6. 比較フラグが true の場合、出力エンドポイントでのメッセージと期待されるメッセージとを比較します。ITF による比較方法についての詳細は、以下の検証コンポーネントの説明を参照してください。
  7. 比較フラグが true の場合、入力エンドポイントでレスポンスと期待されるメッセージとを比較することもできます。
  8. GAL および GEH データベースからカウントを取得し、期待されるカウントと比較します。
  9. 結果を返します。

出力: 実行されたテスト・ケース/グループと実行の詳細がデータベースに保管されます。

検証コンポーネント

期待される結果には、タイプスタンプや相関 ID などの動的な値が含まれることがあります。その場合には、結果の動的な部分が「除外」パターンで置き換えられます。これにより、ITF は実際の出力と期待される出力を正規表現で比較することになります。この機能がなければ、比較は常に不一致の結果となってしまいます。出力結果に動的コンポーネントが含まれなければ、ITF は正規文字列による比較を行います。

図 4. テスト実行レポートの生成
Generate Test Execution Report

入力:

  1. テスト・ケースの名前
  2. グループの名前
  3. バージョン番号
入力例
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
	<Report>
		<TestCase xmlns = 
"http://www.ibm.com/ams/common/unittestframework/report">
			<Name xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Name>
			<Version xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Version>
		</TestCase>
	</Report>
</Input>

ステップ:

  1. グループ/テスト・ケースおよびバージョンを取得します。
  2. ITF データベースに対してクエリーを実行し、テスト実行の詳細を取得します。
  3. 実行の要約を設定したファイルを生成します。

出力: 実行要約レポートが生成されます。


ITF のテスト・サイクル

図 5 に、ITF のテスト・サイクルを示します。開発者/テスターがテスト・ケース、テスト・グループ、およびエンドポイントを識別し、その内容を ITF 指定の入力テンプレートを使用して定義すると、ITF がテスト・ケース、テスト・グループ、およびエンドポイントを作成してデータベースに保管します。テスト・ケースの実行中、テスト対象のコード (CBT) は事前定義された入力エンドポイントのいずれかを介して ITF からの入力を受け取ります。実行が完了すると、CBT は ITF へのレスポンスを事前定義された出力エンドポイントのいずれかで送信します。オプションで、ITF から入力を受け取るたびに CBT が入力に対するレスポンスを返し、ITF に出力を送信するたびに、コードが ITF からの出力に対するレスポンスを期待するように設定することもできます。

図 5. ITF のテスト・サイクル
ITF のテスト・サイクル
図 6. ITF のプロセス・フロー
ITF のプロセス・フロー

SOI 統合パターンに従い、CBT と ITF 間の 4 つのタイプのメッセージ・フローを抜粋して説明します。

  1. JMS から JMS へのフロー
  2. Web サービスから Web サービスへのフロー
  3. JMS から Web サービスへのフロー
  4. Web サービスから JMS へのフロー

JMS から JMS へのフロー

この場合、CBT の入力ポイントと出力ポイントはどちらも JMS キューです。したがって、オプションのレスポンスは必要ありません。入力メッセージは CBT の入力キューで送信され、出力は出力キューに送信されます。ITF が出力キューから読み込んだメッセージを比較する対象は、実行中のテスト・ケースと関連付けられた期待される出力メッセージです。この比較に基づき、ITF はテスト・ケースの合否を判断します。

図 7. JMS 間の対話
JMS 間の対話

Web サービスから Web サービスへのフロー

この場合、CBT の入力ポイントと出力ポイントは Web サービスなので、両方ともオプションのレスポンスが必要です。CBT の入力キューで入力メッセージが送信されると、ITF はリクエストの replyTo キューでコードから返されるレスポンスを待機します。CBT がリクエストに対する入力レスポンスを生成すると、ITF がこれを取り込み、期待されるレスポンスと比較します。ITF はコードによって呼び出されているサービスを模倣するために、事前定義されたレスポンスを CBTが設定した出力 replyTo キューに返します。その結果、レスポンスは CBT によって入力 replyTo キューに送信されます。ITF はこの入力レスポンスを取り込み、期待されるレスポンスと比較します。この比較に基づき、ITF はテスト・ケースの合否を判断します。

図 8. Web サービス間の対話
Web サービス間の対話

JMS から Web サービスへのフロー

この場合、CBT は入力レスポンスを生成しません。CBT が期待するのは出力レスポンスだけです。ITF が入力メッセージを入力キューに送信すると、CBT は入力メッセージを処理し、出力キューでリクエストを送信します。すると ITF がそのリクエストを取り込み、期待される出力と比較します。ITF はコードによって呼び出されているサービスを模倣するために、事前定義された出力レスポンスを CBTが設定した出力 replyTo キューで返します。

図 9. JMS から Web サービスへの対話
JMS から Web サービスへの対話

Web サービスから JMS へのフロー

この場合、CBT は入力リクエストに対するレスポンスを生成しますが、出力メッセージに対するレスポンスは期待しません。入力メッセージが入力キューで送信されると、送信側は入力 replyTo キューでレスポンスを待機します。CBT はリクエストを処理すると、出力キューでメッセージを送信します。そのメッセージを ITF が取り込み、期待される出力と比較します。CBT は入力 replyTo キューで返すレスポンスも生成することになっています。ITF はこの入力レスポンスを取り込み、期待されるレスポンスと比較します。

図 10. Web サービスから JMS への対話
Web サービスから JMS への対話

データベース設計

  1. ITF は必要なすべての情報を保管するために、以下の 6 つのテーブルを使用します。
  2. UT_DEF_TEST_CASE テーブル。テスト・ケース関連のすべての情報が格納されます。
  3. UT_DEF_GROUP テーブル。テスト・ケース・グループ関連のすべての情報が格納されます。
  4. UT_DEF_ENDPOINT テーブル。エンドポイント関連のすべての情報が格納されます。
  5. UT_DEF_CASE_GROUP_REL テーブル。テスト・ケースとグループの関係に関するすべての情報が格納されます。
  6. UT_EXE_SUMMARY テーブル。テスト・ケース実行要約に関するすべての情報が格納されます。
  7. UT_EXE_DETAILS テーブル。テスト・ケース実行詳細に関するすべての情報が格納されます。
図 11. ER モデル
ER モデル
表 5. UT_DEF_TEST_CASE
列名サイズ説明DBA 情報
idvarchar2256GUID主キー (PK)
namevarchar21024各テスト・ケースに指定された固有名固有
descriptionvarchar24000テスト・ケースの説明-
created_byvarchar21024テスト・ケースの作成者-
create_datetimestamp-作成時のタイムスタンプデフォルトはシステム・タイムスタンプ
expected_outcomechar1テストに期待される結果を示すフラグ。S は成功、F は失敗、E はエラーを意味します。成功とは、すべてが正常に機能し、出力が期待される出力と一致し、GAL および GEH でのメッセージ数が期待されるカウントと一致したことを意味します。失敗は、テスト・ケースは実行されたけれども、実際の結果と期待された結果が一致しなかったことを示します。エラーは、テストでタイムアウトやその他のエラーが発生したことを意味します。このフラグが F を示す場合、フレームワークは出力と期待される出力を突き合わせません。この値が E の場合には、フレームワークがタイムアウトになります。フラグの値が何であっても、フレームワークは GAL および GEH のメッセージ数の突き合わせを行います。-
input_messageclob-テストする必要があるエンドポイントへの入力メッセージ。入力メッセージに含まれる UNIQUE_TRANSACTIONID_REPLACEMENT という単語は、トランザクション ID に置き換えられます。-
output_messageclob-実際の出力メッセージの比較対象となる、期待される出力メッセージ。期待される出力メッセージに含まれる UNIQUE_TRANSACTIONID_REPLACEMENT という単語は、トランザクション ID に置き換えられます。-
input_endpointvarchar2256ut_def_endpoint テーブルを参照する ID外部キー (FK)
output_endpointvarchar2256ut_def_endpoint テーブルを参照する ID外部キー (FK)
timeout_intervalnumber-ミリ秒単位の時間間隔。この時間間隔内で出力を受信しないと、テスト・ケースには失敗のマークが付けられます。-
expected_gal_countnumber-トランザクション ID が作成された GAL に期待されるエントリーの数-
expected_geh_countnumber-トランザクション ID が作成された GEH に期待されるエントリーの数-
表 6. UT_DEF_GROUP
列名サイズ説明DBA 情報
idvarchar2256GUID主キー (PK)
namevarchar21024グループの固有名固有
descriptionvarchar24000テスト・グループの説明-
created_byvarchar21024グループの作成者-
create_datetimestamp-作成時のタイムスタンプデフォルトはシステム・タイムスタンプ
表 7. UT_DEF_ENDPOINT
列名サイズ説明DBA 情報
idvarchar2256GUID主キー (PK)
namevarchar21024エンドポイントの固有名固有
descriptionvarchar24000エンドポイントの説明-
created_byvarchar21024エンドポイントの作成者-
create_datetimestamp-作成時のタイムスタンプデフォルトはシステム・タイムスタンプ
typevarchar2256JMS または WS-
message_typevarchar2256バイトまたはテキスト-
encodingvarchar2256バイト・メッセージのエンコード方式デフォルトは UTF8
comparechar1Y または N-
destination_queuevarchar21024リクエストの宛先キュー-
reply_to_queuevarchar21024レスポンスの返信用キュー-
prioritynumber-リクエストの優先度-
delivery_modevarchar21024メッセージの配信モード-
correlation_idvarchar21024メッセージの相関 ID-
timeoutnumber-タイムアウト値-
soap_actionvarchar21024Web サービスの SOAP アクション-
表 8. UT_DEF_CASE_GROUP_REL
列名サイズ説明DBA 情報
idvarchar2256固有 ID。GUID が使用されます。PK
created_byvarchar21024関係の作成者-
create_datetimestamp-作成時のタイムスタンプデフォルトはシステム・タイムスタンプ
def_group_idvarchar2256ut_def_group テーブルを参照する IDFK
def_test_case_idvarchar2256ut_def_test_case テーブルを参照する IDFK
表 9. UT_EXE_SUMMARY
列名サイズ説明DBA 情報
idvarchar2256GUIDPK
user_namevarchar21024テスト・ケースの実行者-
descriptionvarchar24000実行されたテスト・ケースの説明-
external_referencevarchar21024欠陥番号の詳細など-
test_requestclob-テストのリクエスト全体-
start_timetimestamp-実行開始時のタイムスタンプ-
end_timetimestamp-実行終了時のタイムスタンプ-
success_countnumber-実行結果が成功となったテスト・ケースの数-
failure_countnumber-実行結果が失敗となったテスト・ケースの数-
error_countnumber-実行結果がエラーとなったテスト・ケースの数-
total_countnumber-テスト・ケースの合計数-
表 10. UT_EXE_DETAILS
列名サイズ説明DBA 情報
idvarchar2256GUIDPK
exe_summary_idvarchar2256ut_exe_summary テーブルを参照する IDFK
def_test_case_idvarchar2256ut_def_test_case テーブルを参照する IDFK
actual_outcomechar1S、F、または E。テストの実際の結果です。ut_def_test_case.outcome の説明を参照。-
test_outcomechar1S、F、または E。実際の結果が期待される結果と比較され、これがテスト・ケースの最終結果となります。ut_def_test_case.outcome の説明を参照。-
test_inputclob-実際の入力-
test_outputclob-実際の出力-
start_timetimestamp-テスト・ケース開始時のタイムスタンプ-
end_timetimestamp-テスト・ケース終了時のタイムスタンプ-
gal_countnumber-実際の GAL カウント-
geh_countnumber-実際の GEH カウント-
errorvarchar24000エラー・メッセージ、説明、スタック・トレースなどが記載されます。-

まとめ

ITF は、SOI 実装のテスト・フェーズで極めて重要なさまざまなタスクを効率的に実行するためのツールです。ITF は簡単に構築できるだけでなく、ほとんどのミドルウェア統合製品とシームレスに統合します。ITF を採用した開発/テスト・チームでは、コスト効果の大幅な増加が認められています。また、ITF を使用しているチームは、これを使用していないチームに比べ、コードで発生する問題の数も少なくなっています。

参考文献

学ぶために

  • developerWorks の SOA and web services エリアにアクセスして、スキル上達には欠かせないリソースを入手してください。
  • Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=491819
ArticleTitle=自動インターフェース・テスト・フレームワーク
publish-date=04142010