目次


アジャイルな世界での Rational ツールによる機能テストの自動化

Rational ツールを拡張して手作業によるテスト手順を回避する

Comments

このチュートリアルでは、複数のコンポーネントからなる大規模システムの機能とシステムのリグレッション・テストを自動化する方法を説明します。また、テスト・ツールに自動化機能を追加するために作成したカスタム成果物のいくつかを紹介します。

急速に変化する世界に企業が適応していくには、社内の IT システムも変化する要件とテクノロジーに適応させなければなりません。IT システムの規模が大きい場合、そのシステムを構成する多数のコンポーネントがそれぞれに異なるチームで開発されることがあります。それらのチームは、常に移り変わる要件、スケジュール、優先順位に対応し続けることになります。

進化を続ける大規模システムで、新しい機能の追加や既存の機能への変更に影響されることなく、システムが有効に機能し続けるように維持するのは簡単なことではありません。新しいリリースをデプロイする際は、既存の機能のリグレッション・テストを行うことが標準的な慣例となっています。アジャイル開発の場合、予定されている本番環境への公式リリースでないとしても、それぞれのスプリントの終了時に、コードがリグレッション・テストで合格することが要件となります。早い段階の機能テストで合格したテスト条件であっても、テスト・フェーズの終わりのほうで再び実行すると失敗する場合があるからです。その理由は、関連する機能のバグ・フィックスによって不当な問題がもたらされたり、開発サイクルの後期にリリースされた新機能が既存の機能に影響を及ぼしたりするなど、さまざまにあります。

リグレッション・テストは、そのような問題の回避に直結します。リグレッション・テストには以下の目的があります。

  • 既存の機能が前のリリースから引き続き有効であることを確認する
  • 現在のリリースで導入されているすべての機能が完全であることを確認する

これまでに何百ものテスト・ケースが蓄積されている複雑なシステムを扱う場合、毎回それらのテスト・ケースを手作業で再実行するのは、実際的でも経済的でもありません。また、しばらく経ってからテスト・チームの編成が変更された場合、新しくチームに参加したメンバーが所定のテスト・ケースの内容を細部にわたるまで理解しきれずに、毎回テスト結果を手作業で検証して問題を分析しなければならない状況に陥る可能性もあります。

システムの説明

このチュートリアルでは、私たちが IBM デジタル・マーケティング用に作成してテストしたシステムについて説明します。作成したのは連絡先および組織の情報を保管する基幹システムです。以下の図に示されているように、データは IBM InfoSphere Master Data Management (MDM) のインスタンスに保管されます。システムに保管されるデータは、IBM 情報バス (エンタープライズ・サービス・バス) または IBM InfoSphere DataStage の ETL ジョブでソース・システム・データベースから直接読み取られるか、フラット・ファイルを処理して取り込まれます。

このチュートリアルで取り上げるアプリケーションの概要図
このチュートリアルで取り上げるアプリケーションの概要図

機能テストとシステム・テストは、IBM Rational Performance Tester で実行します。Rational Performance Tester テストのオーケストレーションは、Rational Quality Manager によって行います。自動化された機能とシステムのリグレッション・テストにより、既存のすべてのコンポーネントと機能が有効であり、連動することを検証します。このようにリグレッション・テストを自動化すれば、テスト・チームがリグレッション・テストから解放されて、新しい機能とコンポーネントのテストに集中できるようになります。

IBM 情報バス

IBM 情報バス (エンタープライズ・サービス・バス (ESB) とも呼ばれています) は中継ミドルウェア・アプリケーションとして、各種のソース・システムとターゲット・システムとの間でメッセージ・プロトコルとフォーマットを変換してメッセージをルーティングする、信頼性の高い統合メカニズムです。ESB はリアルタイムおよびバッチのデータ転送により、インターフェース間でのデータ整合性を確保します。

  • ソース・システムが MQ リクエストを送信すると、このシステムによってリクエストが処理されて、レスポンスがソース・システムに返されるという仕組みです。したがって、すべてのコンシューマーが、同じリクエスト/レスポンス・メッセージ・フォーマットおよびメッセージ転送プロトコルを引き続き使用できます。
  • ESB は、InfoSphere MDM 向けの変換サービスと統合サービスを提供します。ESB は共通コード値 (国名、言語など) を受け取ると、それを MDM で必要とするコードに変換します。また、MDM レスポンス・コードを変換して共通コード値に戻します。さらに変換処理の一環として、MDM 固有の要素を挿入し、変換後のメッセージをスキーマに照らし合わせて検証します。

InfoSphere DataStage

InfoSphere DataStage は各種のソースからデータを抽出し、データを加工して MDM で処理可能な XML フォーマットに変換してから MDM に渡します。IBM InfoSphere DataStage はデータを一時的に IBM PureData (Netezza アプライアンス) に保管し、そこでデータに ETL 処理を適用して XML を作成します。

このシステム内で DataStage が果たす役割は以下のとおりです。

  • データ・クレンジング: システム内のデータのうち、フリー・フォームのエンド・ユーザー入力から直接取り込まれるデータの中には、意味のないデータ (name = ‘Mickey Mouse') や、曖昧または理解不可能なデータ (name = ‘Mike123@#$') が含まれる可能性があります。そのため、DataStage に実装されたクレンジング・サービスで一連のクレンジング・ルールを実行して、無効なデータを特定します。すべてのデータがクレンジングされるように、クレンジング・サービスはシステム・メッセージ・フローの数カ所に実装されます。
  • ソース・システムからの抽出: すべてのソース・データが MQ リクエストによってシステムに取り込まれるわけではありません。DataStage がソース・システムのデータベース内で変更を直接検出して XML を生成し、その XML を MQ またはフラット・ファイルを介して MDM に送信することもあります。
  • フラット・ファイルの処理: 一部のソース・システムは、データをフラット・ファイルで送信します。DataStage はこれらのフラット・データを処理して XML を生成し、その XML を MQ キューに入れます。MQ キューで XML が変換されて、処理対象として MDM に送信されます。

InfoSphere MDM

InfoSphere MDM は、このプロジェクト・ソリューションの中心となるコンポーネントです。MDM は複数のソースから新しい連絡先や既存の連絡先に対する更新を受信し、それらのデータを、プロジェクト固有の拡張を加えた MDM スキーマを使用して DB2 データベースに維持します。MDM に組み込まれた確率的マッチング・エンジンが重複候補を処理し、場合によっては異なるソースからの重複する連絡先のコピーを単一のゴールデン・レコードに集約します。MDM には以下のサブコンポーネントがあります。

  • MDM Server Advanced Edition: MDM Server Advanced Edition はマスター連絡先データ・ストアとして、企業全体のさまざまなアプリケーションで使用する連絡先レコードのゴールド・コピーを提供するとともに管理するコンポーネントです。このコンポーネントは、DataStage で変換されて QualityStage で標準化されたソース・データを使用して、MDM サーバーとの直接やり取りを必要とする他のアプリケーションにデータ・サービスを提供します。MDM サーバーに備わっている業界標準のインターフェースには、Java ベースのリモート・メソッド呼び出し (RMI)、JMS メッセージング・サービス、SOAP ベースの Web サービスが組み込まれています。これらのインターフェースを基盤に、多種多様なアプリケーションが今後 MDM サーバーと直接やり取りできるようになります。MDM サーバーは確率的マッチング・エンジン (PME) を使用します。
  • MDM バッチ・プロセッサー: 初期ロードと差分ロードに使用される MDM サーバーのコンポーネントです。バッチ・プロセッサーで処理するバルク MDM リクエストをフラット・ファイル・フォーマットで作成することを目的とした、専用の DataStage ジョブがいくつかあります。
  • MDM データベース: MDM サーバー用にデータを保管する DB2 データベースです。
  • MDM DSUI: データを定期的に保守するための DSUI (Data Stewardship User Interface) です。

リグレッションの自動化

IBM Rational テスト・ツール・スイートには、機能およびシステムのリグレッション・テスト関連の問題を解消するツールが揃っています。これらのツールは、リグレッション・テスト・フェーズ全体にかかる時間を短縮する上でも役立ちます。フェーズ全体の時間を短縮することで、テスト・チームはテスト・サイクルのコストや所要時間を増やすことなく、リグレッション・テストを必要なだけ再実行できるようになります。

このセクションでは、複数のリリースにわたって確実かつ効率的な機能およびシステム・リグレッション・テスト・バケットを作成するための手法をいくつか取り上げます。さらに、テスト・ケースの完全な自動化を試みる際にチームが直面した問題、それらの問題を解決した方法についても詳しく説明します。

テスト環境は、以下のツールで構成されています。

  • Rational Service Tester
  • Rational Performance Tester
  • Rational Quality Manager
  • Rational Team Concert

Rational Service Tester と Rational Performance Tester

Rational Service Tester では、HTTP、JMS、および MQ プロトコルを使用してバックエンド・サービスの自動テストを実行できます。通常、この製品はアプリケーションの機能検証テスト (FVT) に使用されますが、サービスの負荷テストとスケジューリングされたテストを実行する機能も備えています。また、パフォーマンス・テストと負荷テストの機能を備えた Rational Performance Tester は、その自然な延長として Rational Service Tester と同様の自動サービス・テストをサポートします。

Rational Service Tester と Rational Performance Tester はそれぞれに機能が異なりますが、両方とも Eclipse ベースのツールです。私たちの目的にはどちらを使っても同じなので、このチュートリアルではこの 2 つを同等のものとして扱います。Rational Service Tester と Rational Performance Tester を使用することで、テストで一連のメッセージをテスト対象のシステムに送信し、その応答を検証できます。一部のテストは Rational Service Tester または Rational Performance Tester のいずれかでしか実行できませんが、それらの違いについては割愛します。

Rational Quality Manager

オープンソースの Jazz プロジェクトに基づく Rational Quality Manager は、コラボレーティブな Web ベースの品質管理ソリューションです。この製品は、テスト計画、マニュアル・テスト、レポート作成、ステータス追跡の包括的なサポートを提供し、テスト・アーキテクトやテスト・リード、テスターを含むさまざまな役割のテスト・チーム・メンバーをサポートします。このような包括的なサポートを可能にしているのは、Rational Service Tester と Rational Performance Tester のような他の IBM Rational テスト・ツールとやり取りする機能を備えているためです。

Rational Team Concert

Rational Team Concert は、反復の計画、プロセス定義、変更管理、障害追跡、ソース管理、レポート作成などの機能を備えた、変更構成管理ツールです。このプロジェクトでの Rational Service Tester および Rational Performance Tester のテスト・ケースはすべて、Rational Team Concert を使用して保守します。

リグレッション・テスト・バケットの作成

Rational Quality Manager でテストのために作成できる主要なエンティティーは 2 つあります。その 1 つは、個々のテスト・ケースの定義です。Rational Quality Manager に定義されたテスト・ケースは、最終的には Rational Service Tester や Rational Performance Tester に定義された実行可能なテスト・ケースを指すことになります。Rational Quality Manager でテスト・ケースを実行すると、そのテスト・ケースとリンクされた、リモート・マシン上で稼働する Rational Service Tester に定義されたテスト・ケースがトリガーされるという仕組みです。もう 1 つの主要なエンティティーはテスト・スイートの定義です。これは Rational Quality Manager に定義されているテスト・ケースを疎結合した集合を意味します。

リグレッション・テスト・バケットは、Rational Quality Manager のテスト・スイートとして定義します。テスト・スイートに、機能別に大まかにグループ化できる既存の Rational Quality Manager テスト・ケースを集めます。テスト・スイートを構成するテスト・ケースは排他的ではありません。つまり、所定のリグレッション・バケットでテスト対象とする機能の範囲と、リグレッション・バケットでのそのテスト・ケースの関連性に基づいて、所定の Rational Quality Manager テスト・ケースを複数のテスト・スイートに含めることができます。以下に、この概念を図解します。

私たちは、MDM で重要な機能をテストする個別の Rational Quality Manager テスト・スイートをいくつか作成しました。さらに、MQ と ETL 機能を対象とした個別のテスト・スイートもあるため、特定のリリースに MDM の機能だけ、あるいは ETL の変更だけが含まれている場合は、テスト・スイートのサブセットを実行するという選択肢があります。

RQM テスト・スイートとテスト・ケースの概念と、同じテスト・ケースを複数のテスト・スイートに含めることができることを示す図
RQM テスト・スイートとテスト・ケースの概念と、同じテスト・ケースを複数のテスト・スイートに含めることができることを示す図

Rational Quality Manager と Rational Service Tester の接続

テスト・スイートを定義した後は、Rational Quality Manager アダプターがインストールされた Rational Service Tester が稼働する任意のマシン上で、Rational Quality Manager サーバーがそのテスト・スイートを実行できます。複数の異なるマシンごとに、1 つのアダプターを有効にすることができます。その場合、Rational Quality Manager はテスト・スイートに含まれるテスト・ケースを分割して、これらのアダプターで並行して実行します。各マシン上では、Rational Team Concert から最新バージョンのテスト・ケースが抽出されます。私たちのセットアップでは、専用の Linux クラウド・イメージが、リグレッション・テストに使用する Rational Performance Tester を実行します。場合によっては、テスト・ケースを並行して実行するために、個々のテスターのラップトップ上のアダプターを使用することもあります。1 台のマシンで実行できる Rational Performance Tester のインスタンスは 1 つだけなので、テスターのラップトップをリグレッション・テストに使用すると、リグレッション・テストを実行している間、そのテスターは別の Rational Performance Tester テスト・ケースを実行できないからです。

このプロセスには 2 つのステップがあります。まず、Rational Service Tester 内の Rational Quality Manager アダプターを構成する必要があります。Rational Service Tester で、「Windows (ウィンドウ)」 > 「Preference (設定)」 > 「Quality Manager Adapter (Quality Manager アダプター)」の順に選択します。

RST に表示された RQM アダプター構成ダイアログ・ウィンドウのスクリーン・キャプチャー
RST に表示された RQM アダプター構成ダイアログ・ウィンドウのスクリーン・キャプチャー

複数の Rational Service Tester インストール済み環境からのアダプターがプロジェクト領域に関連付けられている場合は、環境内でアダプター名が一意になるようにしてください。アダプター名が一意であれば、Rational Quality Manager でテスト・ケースを実行する際に、テスト・ケースを確実に目的の Rational Service Tester インスタンス上で実行できるようになります。

アダプターを起動する方法は 2 つあります。その 1 つは、Rational Performance Tester からアダプターを起動するという方法です。それには、Rational Quality Manager アダプター・ビューを開き (「Window (ウィンドウ)」 > 「Show View (ビューの表示)」 > 「Other (その他)」の順に選択し、「Quality Manager」を見つけます)、「Connect to Rational Quality Manager (Rational Quality Manager に接続)」アイコンをクリックします。このビューには、Rational Quality Manager がテスト・ケースを実行する間、ログ・メッセージが表示されます。テスト・ケースの実行中には、Rational Performance Tester にもビューが表示されます。

RPT 内の RQM アダプターのステータスを示す画面のスクリーン・キャプチャー
RPT 内の RQM アダプターのステータスを示す画面のスクリーン・キャプチャー

アダプターを実行するもう 1 つの方法は、ヘッドレス・モードを使用することです。このモードでは、Rational Performance Tester GUI は実行されず、アダプターがバックグラウンドでサイレントに実行されます。アダプターを起動するには、SDPShared ディレクトリーの下のアダプターが格納されているディレクトリーで、DOS ウィンドウ (または Linux ターミナル) を開きます。私たちのテスト・マシン上でアダプターが格納されている場所は C:\RationalPerformanceTester85\RationalPerformanceTester-RationalService Tester_RationalQualityManagerAdapter です。config\adapter.config 内の構成ファイルを更新します。アダプターを起動または停止するには、cd でカレント・ディレクトリーを bin ディレクトリーに変更して、コマンド Rational Quality ManagerAdapter.bat [START | STOP | STATUS] を使用します。

事例証拠として、このアダプターは、Rational Performance Tester または Rational Service Tester で実行するよりも、ヘッドレス・モードで実行したほうがパフォーマンスに優れています。特に多数のテスト・ケースを実行する場合には、このパフォーマンスの違いが顕著になります。Rational Performance Tester/Rational Service Tester でアダプターを実行すると、より多くのウィンドウが開かれるため、それによってリソースの消費量が増えて、最終的にはアダプターがハングすることになるというのが、私たちの見解です。

テスト・スイートの実行

Rational Quality Manager でテスト・スイートを実行する手順は以下のとおりです。

  • Rational Quality Manager Web クライアント上で実行するテスト・スイートを表示します。
  • ページの最上部にある「Run Test Suite (テスト・スイートを実行)」アイコン (上記の図に丸で囲んで示されているアイコン) をクリックします。
  • 表示されるウィンドウで、テスト・スイートに含まれるテスト・ケースの中から実行するテスト・ケースを選択するか、すべてのテスト・ケースを選択し、テスト・スイートを実行するアクティブな Rational Quality Manager アダプターを選択します。テスト・スイートのすべてのテスト・ケースを単一の Rational Service Tester インストール済み環境に対して実行することも、複数の Rational Service Tester インストール済み環境に対して実行することもできます。
  • Rational Quality Manager で、テスト・スイートの実行をスケジューリングすることもできます。このスケジューリング機能は、通常の勤務時間中には他のテスト・アクティビティー、コードのデプロイ、保守などを実行して、勤務時間外にリグレッション・テスト・ケースを実行する場合に役立ちます。
  • 前のテストからの実行変数を後続のステップに渡せるようにするかどうかを選択します。また、テスト・ケースが 1 つでも失敗した場合にはテスト・スイートの実行を停止するか、あるいはテスト・ケースが失敗しても実行を継続してテスト・スイート全体を完了するかを選択することもできます。典型的なテスト・スイートでは、いずれかのテスト・ケースが失敗したとしても、選択したすべてのテスト・ケースを実行することが推奨されます。
ネットワーク全体から登録されている RQM アダプターのリストを示す画面のスクリーン・キャプチャー
ネットワーク全体から登録されている RQM アダプターのリストを示す画面のスクリーン・キャプチャー

テスト結果とトラブルシューティング

テスト・スイートの実行中、Rational Quality Manager にはテスト・スイートに含まれる個々のテスト・ケースの進捗状況が表示されます。必要に応じて、実行中のプロセスを中断できます。テスト・スイートの実行が終了すると、各テスト・ケースのステータスが「Pass (合格)」または「Fail (失敗)」として表示されます (いずれかのテスト・ケースが失敗したとしてもすべてのテスト・ケースを実行するように構成されている場合)。

リグレッション環境の構成

Rational Quality Manager のテスト・スイート、テスト・ケース、Rational Service Tester および Rational Performance Tester のテスト・ケースを準備してセットアップする手順を説明したので、次は、以下の図に示す物理的なリグレッション・テスト環境の構成について説明します。以下の点に注意してください。

  • テスト・チーム・メンバーが企業ネットワークに接続し、Rational Quality Manager にその Web インターフェースを介してアクセスします。
  • Rational Quality Manager サーバーは、ネットワーク内の任意の場所で実行できます。
  • Rational Service Tester と Rational Performance Tester のテスト・ケースが収容されている Rational Team Concert リポジトリーは、ネットワーク内の任意の場所で実行できます。
  • Rational Service Tester または Rational Performance にインストールされた Rational Quality Manager アダプターは、Rational Quality Manager サーバー・インスタンスに接続するように構成されています。
  • システムを実行するアプリケーション・テスト・サーバーは、同じネットワーク内でテストされています。
リグレッション・テスト環境の物理的構成を示す図
リグレッション・テスト環境の物理的構成を示す図

Rational Service Tester と Rational Performance Tester のカスタマイズ

Rational Service Tester には、さまざまなタイプのテスト要件に対処する機能が備わっています。けれども、何らかの拡張手段を使わずに、すべての問題を解決できるソフトウェア製品などというものはありません。テストを完全に自動化するために、私たちには以下の機能が必要でした。

  • RMI サービスの呼び出し
  • JMS ソースからのメッセージの読み取り
  • SQL コマンドの実行

幸い、Rational Service Tester には機能の拡張手段が用意されているため、私たちはその手段を利用して上記の課題を解決することができました。これらの課題はテスト・ケースでの手作業によるステップで解決することもできましたが、そうすると、機能およびシステム・リグレッション・テスト作業の完全な自動化という目標を達成することはできません。

RMI テスト・ハーネス

Rational Service Tester では、HTTP、JMS/WebSphere MQ、および Microsoft .NET プロトコルを使用してテスト対象のアプリケーションを呼び出せるようになっています。MDM ではサービス・インターフェースと JMS インターフェースがサポートされていますが、私たちのアプリケーションでは RMI だけをサポートするように MDM デプロイメントを構成してセットアップしてあります。その理由は、システムのニーズを前提に初期段階で決定したアーキテクチャーに基づいているだけでなく、複雑さを軽減するためでもあります。

Rational Service Tester で RMI ベースのアプリケーションをテストできるようにするために、私たちは RMI テスト・ハーネス・サーブレット Web アプリケーションを開発しました。このテスト・ハーネスが、Rational Service Tester と MDM との間でリクエスト・メッセージとレスポンス・メッセージを交換する中継アプリケーションとして機能します。「Transport (トランスポート)」タブに表示される Rational Service Tester/Rational Performance Tester の各テスト・ステップに、受信側テスト・サーバーを指す HTTP URL のパラメーターがあります。RMI テスト・ハーネスを使用するために、Rational Service Tester のテスト・ステップは「Transport (トランスポート)」タブで設定されたテスト・ハーネスの URL を使用するようになっています。RMI テスト・ハーネスが JNDI ルックアップを処理し、RMI と MDM の接続をセットアップして MDM に必要なセキュリティーを追加した後、XML リクエストを MDM に送信します。RMI テスト・ハーネスは、MDM アプリケーションを実行する WAS サーバー上に WAR ファイルとしてデプロイされています。

RST からの RMI/JMS 呼び出しを可能にするカスタム・テスト・ハーネスを示す図
RST からの RMI/JMS 呼び出しを可能にするカスタム・テスト・ハーネスを示す図

JMS 通知ハーネス

独自の事情により、テスト対象のサービスのうちの 1 つは、RMI インターフェースでリクエストとレスポンスに対応するだけでなく、特定の状況では JMS 通知も生成します。自動テスト・ケースの一環として、これらの JMS メッセージを読み取って検証しなければなりません。Rational Service Tester はリクエスト/レスポンスでは JMS をサポートしますが、JMS メッセージを読み取る機能は同梱されていません。この機能をテストするために、IBM WebSphere MQ メッセージを読み取り、解析するサーブレット・ベースの Web アプリケーションを開発しました。メッセージ自体の自動検証には Rational Service Tester の組み込み機能を使用した上で、JMS テスト・ハーネスを WAR ファイルとして、MDM アプリケーションを実行する WAS サーバー上にデプロイしました。

Rational Service Tester で JMS メッセージをテストするには、Rational Service Tester のカスタム・ステップの「Transport (トランスポート)」タブに、JMS テスト・ハーネスの URL を入力する必要があります。また、キュー内で特定のメッセージを検索するために、Rational Service Tester のステップにメッセージの ID を指定します。すると、JMS テスト・ハーネスが該当する MQ キューに接続し、キュー内のメッセージで XML ペイロードに含まれる指定のメッセージ ID を検索します。キュー内のメッセージにその ID が含まれている場合は、そのメッセージが検証対象として Rational Service Tester テストに返されます。このハーネスは、該当するメッセージ ID が設定された、キュー内のメッセージの数をカウントすることもできます。

SQL 呼び出し

テスト・ケースに含まれるステップのうち、データ条件を作成するステップをテストする必要がありました。このことから必要になったのは、アプリケーション・データベースの変更です。データベースの変更を実装するために、Rational Service Tester に Java 拡張を適用しました。

この Java 拡張プログラムは、Rational Service Tester を実行するマシンから DB2 に接続した後、SQL ステートメントを DB2 に送信して実行し、その結果セットを取得します。SQL ステートメントを提供して、この Java 拡張プログラムを呼び出すのは、テスト・ケースの役目です。

まとめ

このチュートリアルでは、Rational スイートを使用して、動的でアジャイルな世界での複雑なビジネス・アプリケーションのシステム・リグレッション・テストを自動化する方法を説明しました。複数の Rational 製品を統合し、これらの製品の組み込み機能を拡張できるようにすることで、既存の機能の SVT テストを柔軟に自動化し、新しい機能の作成に集中できるようになります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1041024
ArticleTitle=アジャイルな世界での Rational ツールによる機能テストの自動化
publish-date=01122017