はじめに

この記事では、サービス指向インテグレーション (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 では要約レポートまたは詳細レポートのいずれかを指定することもできます。

上に戻る

設計

ITF のオブジェクト

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

ITF のプロセス・フロー

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

入力:

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. 成功および失敗したエンドポイント、グループ、およびテスト・ケースの要約情報を返します。

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

入力:

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 は正規文字列による比較を行います。

入力:

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 からの出力に対するレスポンスを期待するように設定することもできます。

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

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

JMS から JMS へのフロー

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

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

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

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

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

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

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

データベース設計

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 テーブル。テスト・ケース実行詳細に関するすべての情報が格納されます。

上に戻る

まとめ

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

参考文献

学ぶために

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

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

• IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
  
  

議論するために

• developerWorks blogs から developerWorks コミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• インターフェース・テスト・フレームワークの目的
• ITF の機能
• アーキテクチャー
• 設計
• ITF のテスト・サイクル
• まとめ
• 参考文献
• 著者について
• コメント