JP4961123B2 - 自動化されたテストケース実行に関して疎結合された自動化されたテストケース検証 - Google Patents

Description

本発明は、テスト用途のためのソフトウェアに関し、詳細には、かかるテストソフトウェアにおける期待結果と実結果の間の疎結合された（ｌｏｏｓｅｌｙ ｃｏｕｐｌｅｄ）比較に関する。

本出願は、本出願と共に出願された"System and Method for Selecting Test Case Execution Behaviors for Reproducible Test Automation"という名称の米国特許出願整理番号ＭＳＦＴ−４１４８、および本出願と共に出願された"Test Automation Stack Layering"という名称の米国特許出願整理番号ＭＳＦＴ−４１５０に関連している。

ソフトウェア開発のライフサイクルにおける主要ステージは、設計フェーズ、コーディングフェーズ、コード完成フェーズ、アルファフェーズ、ベータフェーズであり、そして最終的にはマーケットへのリリースとなる。設計フェーズ中に、このソフトウェア製品では、顧客の問題に対処することになり、このソフトウェア製品の機能が定義される。一般的に、この機能仕様の完成により、設計フェーズの終了が示される。コーディングフェーズについては、すでに開始されていてもよい。コード完成フェーズについては、このコードが書き終えられているが、必ずしもデバッグされているとは限らないときに到達される。アルファフェーズは、この製品が安定になる時点を示している。すなわち、主要なバグのほとんどが見出されている。ベータフェーズにおいて、この製品は、すべての主要なバグがなくなっていることが理想的である。したがって、残存するバグは、基本的に無害なものしかないはずである。この製品が最終的な品質保証チェックリストをパスするときには、この製品は、マーケットへのリリースの準備が整っている。

動作しないソフトウェアは誰も欲しないので、テストは、このライフサイクルのうちの重要な部分であり、いくつものフェーズにまたがる可能性がある。ソフトウェアテストは、テストケース（または、さらに可能性が高いのは１組のテストケース）を考案すること、このテストケースを入力として用いてこのソフトウェアを実行すること、ならびにこのテストケースを入力としてもつこのソフトウェアの性能が、この期待結果をもたらすことを検査することを含む。ソフトウェアテストは、人間が手動で行い、あるいはプログラム的に行うことができ、これについては自動化ソフトウェアテストと呼ばれる。理想的には、このソフトウェアのテストは、このソフトウェアのライフサイクルにおいてできる限り早期に開始すべきである。しかし、一般には、この設計フェーズが完了するまでは期待結果を決定することができないので、設計フェーズが完了するまで、このソフトウェアは、全くテストすることができない。一般的に、コーディングフェーズ中において、開発者は、コードを書くときに自分のコードを手作業でテストする。自動化ソフトウェアテストについては通常、この開発プロセスにおけるずっと後になるまで開始することができない。

時には、行われるテストが、コーディングするときに手作業でテストする開発者によってしか行われないこともある。しかし、自分自身の仕事をテストする開発者は、そのコードにそれほど気分的にお金を払いたくない誰かなら見出すことになるバグを見落としてしまう可能性が高い。さらに、この開発者のテストの範囲は、一般的に開発者のコードの機能、ならびに開発者のコードと限られた数の他のソフトウェアアプリケーションとの統合だけに限定されている。

これらの欠点に対処するために、多数のソフトウェア開発ハウスは、しばしば少なくとも部分的に自動化されたテスト技法を使用して、このソフトウェアのテストも行う別のソフトウェアテストグループを有する。一般的に、このテストグループは、テストケースを書き実行することにより、複数の機能および複数のアプリケーションにまたがる複雑なインタラクションについてテストを行う。この製品ライフサイクルにおいて、早ければ設計フェーズさえ含めて早期にこのテストグループが関与することにより、機能仕様の矛盾の識別、テストするのが困難な領域の識別などを含めて多くの利益が得られることについては、一般に合意がなされている。しかし、一般に、機能定義、実装およびＵＩ（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：ユーザインターフェース）チューニングが絶えず変化する中で、各テストケースを最新に保つために必要とされる努力により、このアプローチは非現実的なものになってしまう。したがって、テストケースを書き実行することは、一般的に製品開発の最終段階で行われるあわただしい事柄となる。したがって、テスト、特に自動化テストは、永久に時勢に取り残されてしまう傾向にある。ソフトウェア製品のライフサイクルにおいてできる限り早期に、理想的にはその設計フェーズ中において、テストケースを書き、自動化テストを使用する方法があるとすれば、助けとなるはずである。

テストケーススイート（ｓｕｉｔｅ ｏｆ ｔｅｓｔ ｃａｓｅ）の開発は、これが行われるときはいつでも難しい課題となる。あるアプリケーションの特定の機能をテストするためには、非常に多数の組のテストを書く必要がある。例えば、あるアプリケーションは、マウス、キーボード、デジタイザ、ユーザ補助（ａｃｃｅｓｓｉｂｉｌｉｔｙ）ソフトウェアを介して、プログラム的になど、ある機能との多数のインタラクションモード（ｍｏｄｅ ｏｆ ｉｎｔｅｒａｃｔｉｏｎ）を可能にすることができる。したがって、この機能についての包括的テストを行うためには、テストスイートは、マウスを介してこの機能とインタラクションを行う１組のテスト、（ちょうどユーザが行うようにテキストをタイプして）キーボードを介してこの機能とインタラクションを行う１組、デジタイザを介してこの機能とインタラクションを行う１組、ユーザ補助ソフトウェアを介してこの機能とインタラクションを行ってデフォルトアクション（ｄｅｆａｕｌｔ ａｃｔｉｏｎ）を呼び出し、そうでなければユーザ補助アプリケーションを模倣する１組、およびこのアプリケーションのコーディングモデルを介してこの機能とインタラクションを行う１組などを含んでいる必要がある。生成されたテストケーススイートが、この機能またはアプリケーションの包括的テストを確実に行うようにし、さらにこの包括的テストを行うために書く必要があるテストケース総数を低減する方法があれば、助けとなるはずである。

さらに、これらのテストの各組におけるロジックの多くまたはすべては、他のテストの組におけるロジックと同一であり、一般的に処理結果の検証の多くまたはすべても同様に同一となる。したがって、多数のテストは、同一または非常によく似ており、単に実行オプションが変化しているだけである。例えば、前述の入力のすべての複数の形式では、期待結果が同一の可能性がある。したがって、これらの各入力ソースについてのテストケースを書くためには、一般的にこれらの各入力ソースについてのテストを実行するための別の方法を書く必要があり、このテストスクリプトの残りのほとんどを複製する必要がある。この同じテストを些細な変化だけで何度も何度も書くことは、うんざりするような時間のかかることである。この複製によるコーディングをなくし、またはかなり低減し、書く必要があるテストケースの総数を低減する方法があれば、助けとなるはずである。

（結果の検証、または検証と呼ばれる）このテストケースを実行した実結果が、期待結果と一致するかどうかを判定するために書かれるコードは、しばしばこのテストケース内に含まれる。特定の結果検証の詳細を変更し、あるいは新しい結果検証を追加するには、一般的に各テストケースの修正が必要になる。検証コードがこのテストケースから別になっており、テストケースを理解することがより簡単になり、この検証コードを再利用し維持することがより簡単になれば、助けとなるはずである。

実行の詳細は、しばしばこのテストケース中にハードコード化され、このテストケースが書かれる前にこの設計フェーズが完了していることが必要とされる。特定の実行の詳細ではなくて、ユーザアクションの観点からテストケースを定義し、その結果、このソフトウェア開発ライフサイクルにおいてより早期にテストケースを書くことができる方法があれば、助けとなるはずである。アプリケーションをテストすることは、このアプリケーションの初期開発における極めて重大なステップである。アプリケーションをテストすることは、このアプリケーションに対する修正を実装する際にも非常に重要である。開発者、科学者、製造業者などは、このテストフェーズに多くの努力を行う。かかるテストは、このアプリケーションが特定の刺激に対して期待される方法で応答するようにする助けを行う。このテストは、一般的にテストケースの実行と、テストケースの実行結果の検証を介して完了される。

テストケースは、一般的にアプリケーションに対して刺激を課する。テストケースはまた、このアプリケーションが、期待される方法で応答し、予期しない方法では応答しないことも検証する必要がある。包括的には、全体アプリケーション状態の多くを検証して、この刺激が期待結果をもたらし、予期せぬ結果はもたらさないようにする必要がある。

テストケースは、一般的にアプリケーションの特定の機能または態様をテストする目的のために実行される。同様に、このテストケースの結果の検証では、テストすることを意図した機能に焦点を合わせることもできる。しかし、このテストケースの実行は、このアプリケーション状態の他の態様に影響を及ぼすこともあり、またそれを変化させることもある。かかる態様は、このテストケースの目的からは逸脱しているように見えることもある。これらの逸脱した態様が非常に多いこともあり、このテストケースを開発するテスタ（ｔｅｓｔｅｒ）にとって、それらの態様のすべて、またはそのほとんどでさえ定量化し、または指定することが難しいこともある。

テストケースコードを書いてこのアプリケーション状態の多くを検証することは、様々な理由から問題があることが判明している。比較的簡単なアプリケーションでさえ、このアプリケーションを包括的にテストするには、おびただしい数のテストケースが必要とされることもある。各テストケースに対して非常に長い詳細にわたる検証コードを追加することは、たとえ解決できないタスクでないにしても手ごわいはずである。さらに、テストケースメンテナンスは通常、テストケース作成（以上ではないにしてもそれ）と同様に労働集約型の時間のかかるものである。アプリケーションが変更されるときには、このテストケースならびに検証コードも変更してこのアプリケーションと引き続き互換性があるようにする必要がある。各テストケースに非常に長い包括的な検証コーディングを追加することは、たとえ不可能でないにしてもかかるメンテナンスを非実用的にするはずである。

したがって、各テストケースと共に膨大でうんざりするような時間のかかる検証コードを書く必要なしに、アプリケーションに適用されるテストケースの結果を包括的に検証する必要がある。また、セットアップし、実行し、または維持する、このテスタによる最小限の明示的なアクションしか必要としない検証についての必要性も存在する。

テストケース実装の検証は、このテストケースから分離することができ、また専用の検証マネージャによって完了することもできる。このテストケースは、どのような検証も含む必要がないようにすることができ、実際に、このテスタは、実施されている検証のすべてについて知る必要があるとさえ限らない。各テストケースが、アクションの結果の特定の検証を可能にせずにアクションを実行できるように、この検証マネージャを使用して、１つまたは複数のテストケースを検証することができる。

専用検証マネージャを用いて、検証をより包括的なものにすることができる。この検証マネージャは、期待状態ジェネレータ（ｅｘｐｅｃｔｅｄ ｓｔａｔｅ ｇｅｎｅｒａｔｏｒ）の大規模なライブラリを使用してテストケースの結果をより包括的に検証することができる。このライブラリ中に含まれる各期待状態ジェネレータは、アプリケーションの様々な別のコンポーネントおよび異なるコンポーネントに対して焦点を合わせることができる。ある期待状態ジェネレータでは、このテスタがこのテストケースの目的に特に関連すると考えることができるアプリケーション状態の一態様に焦点を合わせることができる。第２の期待状態ジェネレータでは、このテスタが、このテストケースの目的から逸脱しており、または無関係であると考えることができるアプリケーションの一態様に焦点を当てることもできる。したがって、テストケースに含まれる焦点の合わせられた検証を行う代わりに、このライブラリは、すべてのテストケースについての広範な検証を可能にすることができる。

この検証マネージャは、指定されたアプリケーションプロパティの期待値（ｅｘｐｅｃｔｅｄ ｖａｌｕｅ）をこれらの同じプロパティの実効値（ａｃｔｕａｌ ｖａｌｕｅ）と比較することによってテストケース結果を検証することができる。この比較を行う際に、この検証マネージャは、現行アプリケーション状態と期待アプリケーション状態が実質的に合っていないインスタンスを決定できることになる。最後に、この検証マネージャは、任意のテスト故障をそのテストケース、テストケースイグゼキュタ（ｔｅｓｔ ｃａｓｅ ｅｘｅｃｕｔｏｒ）、または他の指定された任意のエンティティに対して伝えることもできる。

例えばこのテストケースがグラフィックアプリケーションを呼び出して青色の長方形を書くときに、ファイルメニュー上のボタンの状態が検証されていることさえテストケースが知らなくてもよいように、この検証プロセスは、完了することができる。この包括的な検証を得るに際しては、適切なパラメータを用いてこのアクションを実行すること以外に、このテスタについてのアクションは必要とされない。

さらに、この検証がアップデートまたは変更されるときに、テストケースのメンテナンスは、最小限にされ、または取り除かれる。例えば、アプリケーションがアップデートされ、それとも変更されるときに、この検証マネージャまたは期待状態ジェネレータは、継続してこのアプリケーションと整合しているようにするために同様にして改訂を要することもある。この検証はこのテストケースから分離できるので、このテストケースについては、どのようなメンテナンスも必要がないようにすることができる。

さらに、テストケースが、アプリケーションの特定のコンポーネントの故障をもたらすときには、さらにこの同じ故障についての通知を絶えず受け取ることなくテストケースを実行することもできる。この機能により、故障を考慮し、このアプリケーションのテストを継続して行う機会がもたらされる。

前述の概要、ならびに以下の例示の実施形態の詳細な説明については、添付図面を併せ読むときにさらに良好に理解されよう。本発明を例証する目的で、図面中には本発明の代表的な構成が示されている。しかし、本発明は、開示の特定の方法および手段だけに限定されるものではない。

概要
本発明の実施形態の一例においては、その検証プロセスは、そのテストケースから分離される。期待状態ジェネレータと呼ばれる各検証エレメントは、検証マネージャと呼ばれる専用デバイスに記憶することができる。各検証プロセスをこれらの個別のテストケースから分離することによって、各テストケースは、各テストケース中で検証コードを複製する必要なしに、より包括的に検証することができる。さらに、この検証マネージャは、それぞれが他とは独立に動作し、それぞれがそのアプリケーションの１つまたは複数のコンポーネントの期待状態を計算する非常に多くの期待状態ジェネレータを含むこともできる。検証は、オフライン、すなわちテストケース実行中以外の時、および／またはオンライン、すなわちテスト実行中に、完了することができる。

期待状態ジェネレータは、ローカル検証フレームワーク中に埋め込むこともでき、また動的にロードされ、ランタイムにおいて有効および無効にされる独立なオブジェクトとすることもできる。かかる期待状態ジェネレータは、データベースまたはネットワークロケーションからロードすることができる。基本的に、この期待状態ジェネレータは、この検証フレームワークにプラグインすることができる。

これらの個別のテストケースから検証を分離することにより、アプリケーションのより包括的なテストが可能になる。さらに、専用検証マネージャを有することにより、検証コードを各テストケース中に含める必要なしに、テストケースを検証することができるようになる。検証コードは各テストケース中に含まれていないので、アプリケーションにおける修正に対応するように検証アルゴリズムが変更されるときに、かかる変更がこれらのテストケースに影響を及ぼすことはない。したがって、検証をテストケースから分離することにより、これらのテストケースに対して必要とされるメンテナンスを減少させることができる。

コンピューティング環境の例
図１および以下の説明では、本発明の実施形態の一例を実装することができる適切なコンピューティング環境の簡潔な一般的な説明を行うことを意図している。しかし、ハンドヘルドデバイス、ポータブルデバイス、および他のすべての種類のコンピューティングデバイスが、本発明に関連して使用されることについて企図されていることを理解されたい。汎用コンピュータが以下では説明されているが、これは一例にすぎないものである。本発明は、ネットワークサーバのインターオペラビリティおよびインタラクションを有する小型軽量クライアント上で動作可能とすることもできる。したがって、本発明の実施形態の一例は、非常にわずかなまたは最小限のクライアントリソースしか関与していない、ネットワーク化されたホストサービスの環境、例えばこのクライアントデバイスが、単にワールドワイドウェブに対するブラウザまたはインターフェースとしてしか機能しないネットワーク環境中で実装することもできる。

必要ではないが、本発明は、開発者またはテスタが使用するためのＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ：アプリケーションプログラミングインターフェース）を介して実装し、または１つまたは複数のコンピュータ（例えば、クライアントワークステーション、サーバ、または他のデバイス）が実行する、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明されることになるネットワークブラウジングソフトウェア（ｎｅｔｗｏｒｋ ｂｒｏｗｓｉｎｇ ｓｏｆｔｗａｒｅ）内に含め、あるいはその両方を行うことができる。一般に、プログラムモジュールは、個々のタスクを実施し、または個々の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。一般的にこのプログラムモジュールの機能は、様々な実施形態中で必要に応じて結合し、または分散することができる。さらに、本発明は、他のコンピュータシステムコンフィギュレーションを用いて実行することができることが当業者には理解されよう。本発明と共に使用するのに適したものとすることができる他のよく知られているコンピューティングシステム、コンピューティング環境、および／またはコンピューティングコンフィギュレーションには、それだけには限定されないが、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ：パーソナルコンピュータ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブルな家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明の一実施形態はまた、分散コンピューティング環境中でも実行することができ、ここでは、タスクは、通信ネットワークまたは他のデータ伝送媒体を介してリンクされるリモート処理デバイスによって実施される。分散コンピューティング環境においては、プログラムモジュールは、メモリストレージデバイスを含めて、ローカルコンピュータストレージ媒体中にもリモートコンピュータストレージ媒体中にも配置することができる。

したがって、図１は本発明を実装することができる適切なコンピューティングシステム環境１００の一例を示すが、以上で明らかにされたように、コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の用途または機能の範囲についてどのような限定を示唆することも意図してはいない。また、コンピューティング環境１００は、例示の動作環境１００中に示されるコンポーネントの任意の１つまたは組合せに関連したどのような依存性または要件を有するものとも解釈すべきではない。

図１を参照すると、本発明を実装するシステムの一例は、コンピュータ１１０の形態で汎用コンピューティングデバイスを含んでいる。コンピュータ１１０のコンポーネントは、それだけには限定されないが、処理装置１２０、システムメモリ１３０、およびこのシステムメモリを含めて様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１を含むことができる。システムバス１２１は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および様々なバスアーキテクチャのうちのどれかを使用したローカルバスを含めて、いくつかのタイプのバス構造のうちのどれにすることもできる。限定するものではないが例として、かかるアーキテクチャは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ：業界標準アーキテクチャ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ：マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ：拡張ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ：ビデオエレクトロニクス規格協会）ローカルバス、および（メザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られている）ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ：ペリフェラルコンポーネント相互接続）バスを含んでいる。

コンピュータ１１０は、一般的に様々なコンピュータ読取り可能媒体を含んでいる。コンピュータ読取り可能媒体は、コンピュータ１１０がアクセスすることができる使用可能な任意の媒体とすることができ、揮発性媒体および不揮発性媒体、着脱可能媒体および固定媒体を含んでいる。限定するものではないが例として、コンピュータ読取り可能媒体は、コンピュータストレージ媒体および通信媒体を含むことができる。コンピュータストレージ媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、他のデータなどの情報の記憶のための任意の方法または技術で実装される揮発性媒体および不揮発性媒体、着脱可能媒体および固定媒体を含んでいる。コンピュータストレージ媒体は、それだけには限定されないが、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ランダムアクセスメモリ）、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：読取り専用メモリ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ−Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ：電気的に消去可能なプログラマブルな読取り専用メモリ）、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：コンパクトディスク読取り専用メモリ）、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ：デジタル多用途ディスク）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータ１１０によってアクセスすることができる他の任意の媒体を含んでいる。通信媒体は、一般的に搬送波や他の搬送メカニズムなどの被変調データ信号の形のコンピュータ読取り可能命令、データ構造、プログラムモジュールまたは他のデータを実施し、任意の情報配信媒体を含んでいる。この用語「被変調データ信号」は、その１つまたは複数の特性が、その信号中の情報を符号化するようにして設定または変更された信号を意味する。限定するものではないが例として、通信媒体は、有線ネットワークや直接配線接続などの有線媒体と、音響、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ：無線周波数）、赤外線、他の無線媒体などの無線媒体を含んでいる。以上のうちの任意の組合せもまた、コンピュータ読取り可能媒体の範囲内に含められるべきである。

システムメモリ１３０は、ＲＯＭ１３１やＲＡＭ１３２などの揮発性メモリ、および／または不揮発性メモリの形態のコンピュータストレージ媒体を含んでいる。起動中などにコンピュータ１１０内のエレメント間で情報を転送する助けをする基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ：基本入出力システム）１３３は、一般的にＲＯＭ１３１に記憶される。ＲＡＭ１３２は一般的に、処理装置１２０にとって直ちにアクセス可能であり、または処理装置１２０によって現在動作させられており、あるいはその両方が行われるデータおよび／またはプログラムモジュールを含んでいる。限定するものではないが例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。ＲＡＭ１３２は、他のデータおよび／またはプログラムモジュールを含むこともある。

コンピュータ１１０は、他の着脱可能／固定の、揮発性／不揮発性コンピュータストレージ媒体を含むこともできる。例にすぎないが、図１は、固定不揮発性磁気媒体から情報を読み取り、それに情報を書き込むハードディスクドライブ１４１、着脱可能な不揮発性磁気ディスク１５２から情報を読み取り、それに情報を書き込む磁気ディスクドライブ１５１、ならびにＣＤ−ＲＯＭや他の光媒体など着脱可能な不揮発性光ディスク１５６から情報を読み取り、またはそれに情報を書き込む光ディスクドライブ１５５を示している。この例の動作環境中で使用することができる他の着脱可能／固定の、揮発性／不揮発性コンピュータストレージ媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は、一般的にインターフェース１４０などの固定メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、一般的にインターフェース１５０などの着脱可能なメモリインターフェースによってシステムバス１２１に接続される。

前述の図１に示すこれらのドライブおよびこれらに関連するコンピュータストレージ媒体は、コンピュータ１１０のためのコンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。図１において、例えばハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じまたは異なるものとすることが可能である。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すためにここでは異なる番号が付与されている。ユーザは、キーボード１６２や一般的にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含むことができる。これらおよび他の入力デバイスはしばしば、システムバス１２１に結合されるユーザ入力インターフェース１６０を介して処理装置１２０ａ〜ｆに接続されるが、これらは、パラレルポート、ゲームポートまたはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ：ユニバーサルシリアルバス）など他のインターフェースおよびバス構造によって接続することもできる。

モニタ１９１または他のタイプのディスプレイデバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１に加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６など他のペリフェラル出力デバイスを含むこともでき、これらの出力デバイスは、出力ペリフェラルインターフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク環境中で動作することもできる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、一般的にコンピュータ１１０に関連して以上で説明したエレメントの多くまたはすべてを含んでいるが、メモリストレージデバイス１８１だけしか、図１には示していない。図１に示す論理接続は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ローカルエリアネットワーク）１７１およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ：ワイドエリアネットワーク）１７３を含んでいるが、他のネットワークを含んでいてもよい。かかるネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて、一般的なものである。

ＬＡＮネットワーキング環境中で使用されるときには、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境中で使用されるときには、コンピュータ１１０は、一般的にインターネットなどのＷＡＮ１７３上で通信を確立するためのモデム１７２または他の手段を含んでいる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク環境においては、コンピュータ１１０に関連して示すプログラムモジュール、またはその一部分は、このリモートメモリストレージデバイスに記憶することもできる。限定するものではないが例として、図１は、リモートアプリケーションプログラム１８５をメモリデバイス１８１上に常駐するものとして示している。図に示すこれらのネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立する他の手段を使用することもできることが理解されよう。

コンピュータ１１０または他のクライアントデバイスは、コンピュータネットワークの一部分として展開できることが当業者には理解することができよう。この点で、本発明は、任意数のメモリユニットまたはストレージユニット、ならびに任意数のストレージユニットまたはボリュームにまたがって行われる任意数のアプリケーションおよびプロセスを有する任意のコンピュータシステムに関する。本発明の一実施形態は、リモートストレージまたはローカルストレージを有する、ネットワーク環境中で展開されるサーバコンピュータおよびクライアントコンピュータを伴う環境に対して適用することができる。本発明は、プログラミング言語機能、解釈機能および実行機能を有するスタンドアロンコンピューティングデバイスに適用することもできる。

テストケース実行に関して疎結合されたテストケース検証のためのシステムおよび方法
図２は、本発明の一実施形態による、テストケース実行に関して疎結合されたテストケース検証のためのテスト検証システム１のブロック図である。このシステム１は、図１に関して説明したコンピュータ１１０とすることもできるコンピュータ上に常駐することができる。システム１は、以下のもの、即ち検証マネージャ３０、テストケース２０、コンペアラ３５、期待アプリケーション状態データ構造３６、現行アプリケーション状態データ構造３７、およびデータベース３１のうちの１つまたは複数を含むことができる。このシステムは、テストすべきアプリケーション１０を含むことができる。このアプリケーション１０は、任意のプロセス、マシン、製品、または組成物、あるいはその任意の改良とすることができる。アプリケーション１０はまた、任意のプログラム、ソフトウェア、ハードウェア、デバイス、メカニズム、または材料、あるいはその任意の改良とすることもできる。例えば、アプリケーション１０は、任意のコンピューティングシステム上で実行されるソフトウェアプログラムであってもよい。また、例えばアプリケーション１０は、あるデバイスが、ドアノブを叩いて、このドアノブ、このドアノブが取り付けられたドア、このドアに取り付けられたヒンジ、このヒンジが取り付けられたドアフレームなどの強度、弾力性、操作性をテストするドアテストメカニズムであってもよい。アプリケーション１０については、最初のアプリケーションの開発中、以前のアプリケーションのアップデートされたバージョン、エンドユーザが何らかの方法で修正している以前にリリースされたアプリケーションなどであってもよい。

アプリケーション１０は、図１においてテストケース２０ａ、ｂ、ｃ．．．ｆなどによって表される１つまたは複数のテストケースによってテストすることができる。テストケース２０ａ〜ｆは、統合テストまたは機能テストのために呼び出すことができる。統合テストは、複数の相互作用するコンポーネントが結合し、一緒に動作し、互いに影響を及ぼす方法についてテストする。機能テストにおいては、このテストケースは、テストケースの特定の機能動作に対して焦点を合わせる。

一般に、各テストケース２０ａ〜ｆは、アプリケーション１０に対して適用すべき明確なパラメータを伴う明確なアクションを含んでいる。これらのテストケース２０ａ〜ｆはそれぞれ、アプリケーション１０が実行すべき１つまたは複数のステップを含むことができる。これらの各テストケース２０ａ〜ｆは、アプリケーション１０に適用される１つのテスト、または一連のテストであってもよい。テストケース２０ａ〜ｆは、例えばＣ、Ｃ＃、Ｃ＋＋、パスカル（Ｐａｓｃａｌ）、オブジェクト指向言語などの適切な任意のプログラミング言語で書くことができる。テストケース２０ａ〜ｆ、またはテストケース２０ａ〜ｆの組合せでは、例えばグラフィックアプリケーションを呼び出して、様々なカラーの他の形状を含むドキュメント上に青色の長方形を描くことができる。テストケース２０ａ〜ｆはまた、コンピュータプログラミング言語に無関係とすることもできる。例えば、テストケース２０ａは、ドアに取り付けられたドアノブに対して４フィート（１２１．９センチメートル）上に３０°の角度でつるされた１０ポンド（４．５４ｋｇ）のモール（ｍａｕｌ）の手動レリーズ（ｍａｎｕａｌ ｒｅｌｅａｓｅ）を呼び出すことができる。この明細書の全体にわたって提供されるグラフィックアプリケーション、ドアノブアプリケーションおよび他の任意の例は、本出願の請求範囲を決して限定するものではなく、その代わりに理解を容易にするために説明される例示の実施形態にすぎないことが理解されよう。

図２に示すテストケース２０ａ〜ｆはそれぞれ、アプリケーション１０の異なる態様をテストすることができる。テストケース２０ａ〜ｆは、単に可能性のあるテストケースを表しているにすぎず、アプリケーション１０をテストする任意数のテストケース２０ａ〜ｆが存在し得ることを理解されたい。さらに、各テストケース２０ａ〜ｆは、同時にまたは異なる時刻に実行することもできることを理解されたい。さらに、例えばテストケース２０ａは、１回実行することができるが、テストケース２０ｅは、１０回実行することもできることを理解されたい。さらに、テストケース２０ａ〜ｆは、テスタによって実行することもできることを理解されたい。代替実施形態においては、これらのテストケースは、テストケースイグゼキュタまたは同様なデバイスによって実行することができる。

本発明の実施形態の一例においては、テストケース２０ａ〜ｆは、検証マネージャ３０と直接情報をやりとりすることができる。本発明の代替実施形態においては、テストケース２０ａ〜ｆは、検証マネージャ３０と情報をやりとりする他のサブルーチンを呼び出すことができる。テストケース２０ａ〜ｆは、どのようにして検証が完了したかについて知らないこともある。例えば、多くのテストケース２０ａ〜ｆが、青色の長方形を必要とする場合に、青色の長方形を描くサブルーチンを書くこともできる。このサブルーチンは、検証マネージャ３０と情報をやりとりすることができる。このサブルーチンを使用したテストケース２０ａ〜ｆは、このサブルーチンが青色の長方形を描くことを知っているはずであるが、このサブルーチンが検証マネージャ３０と情報をやりとりしていることについては必ずしも知っているとは限らないはずである。

検証マネージャ３０は、期待状態ジェネレータ３２ｔ〜ｚ、コンペアラ３５、期待アプリケーション状態データ構造３６，および現行アプリケーション状態データ構造３７を含むことができる。各期待状態ジェネレータ３２ｔ、ｕ...ｚなどの期待状態ジェネレータは、１つまたは複数の特定のコンポーネント、データポイント、またはプロパティに関連づけることもできる。例えば、テストケース２０ａ〜ｆのうちの１つ、一部、またはすべてがアプリケーション１０を呼び出して、ある位置に青色の長方形を描くグラフィックアプリケーションをテストすることに関しては、期待状態ジェネレータ３２ｔ〜ｚは、このアプリケーション状態の異なるコンポーネントに焦点を合わせることができる。期待状態ジェネレータ３２ｔは、この長方形のカラーに焦点を合わせることができる。期待状態ジェネレータ３２ｕは、この長方形の位置に焦点を合わせることができる。期待状態ジェネレータ３２ｖは、新しく描かれた青色の長方形と同じドキュメント上の三角形のロケーションなど、このテストケース２０ａ〜ｆの実行からのあまり明らかでない結果に対して焦点を合わせることもできる。代わりに、期待状態ジェネレータ３２ｕ、３２ｖは、一体化することができ、またこのドキュメント上のあらゆる形状のロケーションに関係のある１つの期待状態ジェネレータ（図示せず）によって置き換えることもできる。期待状態ジェネレータ３２ｗは、新しいドキュメントをオープンするオプションなど、このツールバー上の関係のないオプションのステータスに焦点を合わせることができる。

また例えば、テストケース２０ａ〜ｆがモールを用いてドアノブを叩くことにより、ドアに取り付けられたドアノブを個別にまたは一括してテストする場合には、期待状態ジェネレータ３２ｔは、このドアノブの回転する機能に焦点を合わせることができる。期待状態ジェネレータ３２ｕおよび３２ｖは、このドアに取り付けられた上側ヒンジおよび下側ヒンジに焦点を合わせることができ、あるいは一体化することもでき、またこのヒンジの状態に関係のある１つの期待状態ジェネレータ（図示せず）によって置き換えることもできる。期待状態ジェネレータ３２ｗは、このドアノブ周囲のこのドアの木材部分に焦点を合わせることもできる。他の期待状態ジェネレータは、アプリケーション１０の他のエリアに焦点を合わせることもできる。

期待状態ジェネレータ３２ｔ〜ｚのすべては、１つまたは複数のテストケース２０ａ〜ｆがアプリケーション１０に適用されるときに呼び出すことができ、あるいは期待状態ジェネレータ３２ｔ〜ｚの１つまたは一部だけを呼び出すこともできる。実施形態の一例においては、期待状態ジェネレータ３２ｔ〜ｚは、テストケース２０ａ〜ｆと独立に実行することができ、したがってこれらのテストケースと疎結合とすることができる。このようにして、テストケース２０ａ〜ｆは、テストケース２０ａ〜ｆの適用中にどの期待状態ジェネレータ３２ｔ〜ｚを呼び出すべきかをこの検証マネージャに対して指定する必要はない。テストケース２０ａ〜ｆは、この場合には検証メカニズムを含まないこともある。実際に、テストケース２０ａ〜ｆは、任意の検証が行われることについて知らなくてもよいこともある。検証マネージャ３０は、テストケース２０ａ〜ｆの結果を検証する責任を負うこともあり、またテストケース２０ａ〜ｆの目的が、アプリケーション１０に対して特定のパラメータを用いて刺激を与えることだけに制限されることもある。

しかし、実施形態の一例と整合して、テストケースが、検証コーディングを含むことができることが当業者には理解されよう。特にテストケース２０ａ〜ｆを実行する目的が、特定の問題が是正されているかどうかを判定することにある場合には、このようになる場合もある。代替実施形態においては、テストケース２０ａ〜ｆは、呼び出すべき１つまたは複数の期待状態ジェネレータ３２ｔ〜ｚを指定することもでき、ある種の他の期待状態ジェネレータ３２ｔ〜ｚを使用すべきでないことを指定することもできる。

テストケース２０ａ〜ｆから検証を分離することにより、この検証は、テストケース２０ａ〜ｆについてより包括的なものにすることができる。検証マネージャ３０は、以前には個々のテストケースの一部分であったこともある期待状態ジェネレータ３２ｔ〜ｚを含むことができる。例えば、検証マネージャ３０は、青色の正方形、赤色の円、黄色の三角形、または楕円を描き、プルダウンメニュー上のオプションを使用し、マウスまたはそのキーボードの使用を介して様々なユーザ入力に応答するなどのグラフィックアプリケーションの機能をテストするように設計された従来技術のテストケース２０ａ〜ｆの期待状態ジェネレータ３２ｔ〜ｚを含むことができる。これらのテストケースのそれぞれは、このテストケースのアクションの目的に焦点を合わせた特定の検証を含んでいるはずである。期待状態ジェネレータ３２を含む専用の検証マネージャ３０を用いて、グラフィックアプリケーションにおいて青色の長方形を描くテストケース２０ａ〜ｆは、より包括的に検証することができる。検証マネージャ３０は、青色の長方形、赤色の円、黄色の三角形、プルダウンメニュー、マウスおよびキーボードによる入力などに特有の期待状態ジェネレータ３２を呼び出すことができる。このようにして、この青色の長方形を描くことを求めて呼び出すテストケース２０ａ〜ｆは、期待状態ジェネレータ３２ｔ〜ｚを呼び出して、アプリケーション１０上のテストケース２０ａ〜ｆの明らかな効果およびそれほど明らかでない効果を検査することができる。このテスタは、例えばこの青色の長方形が描かれるときにこの赤色の円が検証されつつあることを知らなくてよいことさえある。これらのテスト結果が、この赤色の円がテストケース２０ａ〜ｆによる影響を受けずにいるようになっている場合、またこれが期待結果であった場合には、このテスタおよび／またはテストケースは、この赤色の円が検証されたことを知らなくてもよい。しかし、この赤色の円が思いがけなくわずかに移動した場合には、検証マネージャ３０は、予期せぬ結果が起こったことをこのテスタに警告することができる。

同様に、テストケース２０ａ〜ｆが、モールを用いてドアに取り付けられたドアノブを叩くことに関与する場合には、この検証プロセスは、このドアノブに対するテストの効果だけでなく、このドア、ドアフレーム、ヒンジなどに対するテストの効果も決定することを含むことができる。

さらに、アプリケーション１０が変更され、アップデートされるなどの場合に、テストケース２０ａ〜ｆの検証は、あまり影響を受けずにいることもできる。アプリケーション１０が動作する方法を変更し得るアプリケーション１０の新しいバージョンを作成することもできる。これにしたがって、テストケース２０を、変更する必要があることもある。例えば、グラフィックアプリケーションをテストするためのテストケース２０ａ〜ｆは、青色の長方形の描画をそれがどのように呼び出すかについての改訂を必要とすることもある。また例えば、テストすべき新しいドアノブが以前のバージョンよりも大きな弾力性を有する場合、ドアに取り付けられたドアノブをテストするテストケース２０ａ〜ｆは、モールの重さおよび高さを変更する必要があることもある。しかし、期待状態ジェネレータ３２はそれぞれ、変更する必要がないこともある。このグラフィックアプリケーションの例においては、期待状態ジェネレータ３２は、アプリケーション１０が変更される以前と同様にして、新しい青色の正方形、既存の赤色の円、黄色の三角形、および楕円のロケーションを検査し続けることができる。同様に、期待状態ジェネレータ３２は、この新しいドアノブが追加され、テストケース１０が修正される以前と同様にして、そのドアノブ、そのドア、そのヒンジ、およびそのドアフレームを検証することができる。

期待状態ジェネレータ３２ｔ〜ｚは、検証マネージャ３０を介してデータベース３１と情報をやりとりすることができる。データベース３１は、期待状態ジェネレータ３２に情報を提供し、その結果、この期待状態ジェネレータは、テストケース２０からのアプリケーション１０の期待状態をより良好に決定できるようにもなる。例えば、テストケース２０ａ〜ｆは、モールを用いてドアに取り付けられたドアノブを叩くことを伴うこともある。期待状態ジェネレータ３２ａは、またこのドアに取り付けられた１／８インチ（３．１７ミリメートル）の厚さ、２インチ（５．０８センチメートル）の長さの黄銅ヒンジに対するテストケースの効果を決定することができる。それを行う際に、この期待状態ジェネレータ３２ａは、データベース３１に照会して、例えば黄銅の引張り強度に関する情報を検索することができる。代替実施形態においては、各期待状態ジェネレータ３２は、検証マネージャ３０とは独立の１つまたは複数のデータベース３１と情報をやりとりすることができる。代わりに、各期待状態ジェネレータ３２は、プラグ可能なコンポーネントから情報を検索し、または情報を受け取ることもできる。

期待状態ジェネレータ３２ｔ〜ｚは、コンペアラ３５と情報をやりとりすることができる。図２に示すように、コンペアラ３５は、検証マネージャ３０の一部分とすることができる。しかし、コンペアラ３５は、この検証マネージャの外側に配置することもできることが当業者には理解されよう。この場合には、このコンペアラは、検証マネージャ３０および／または期待状態ジェネレータ３２と情報をやりとりすることができる。コンペアラ３５は、期待状態データ構造３６を実効状態データ構造３７と比較することができる。

より詳細には、１つまたは複数のテストケース２０ａ〜ｆが、実行されようとしているときに、テストケース２０ａ〜ｆまたはテストイグゼキュタは、検証マネージャ３０に通知することができる。検証マネージャ３０は、このアプリケーションの現行グローバル状態のスナップショットを取ることができる。すなわち、この検証マネージャは、このアプリケーションのプロパティの現行値の、メモリへのコピーを行うことができる。次いで、検証マネージャ３０は、実行すべき待ち状態にあるテストケース２０について期待状態ジェネレータ３２に通知することができる。実施形態の一例においては、テストケース２０ａ〜ｆ中において関与し得るこれらの期待状態ジェネレータ３２だけについて通知することができる。代替実施形態においては、期待状態ジェネレータ３２のすべてについて通知することもできる。

このアクション、および実行されようとしているアクションのパラメータ、ならびにこの現行グローバル状態の、検証マネージャのスナップショットに基づいて、各期待状態ジェネレータ３２は、アプリケーション１０上のテストケース２０ａ〜ｆの見込みのある実行から、このアプリケーションのコンポーネントに関するその期待結果状態を計算する。例えば、アプリケーション１０がグラフィックアプリケーションであり、テストケース２０ａ〜ｆが、一括して青色の長方形の描画を必要とする場合には、各期待状態ジェネレータ３２は、このアクションに関するその期待アプリケーション状態を決定する。期待状態ジェネレータ３２ｔは、この結果が長方形を含むべきことを決定することができる。期待状態ジェネレータ３２ｕは、この長方形が青色であるべきことを決定することができる。期待状態ジェネレータ３２ｖは、この長方形から離れた赤色の円に焦点を合わせることができ、その期待状態が、テストケース２０によって変更されないままに留まるべきことを決定することができる。各期待状態ジェネレータは、この期待コンポーネント状態を検証マネージャ３０に対して伝え、検証マネージャ３０は、コンペアラ３５中の期待アプリケーション状態データ構造３６にこのデータを配置することができる。このようにして、検証マネージャ３０は、テストケース２０ａ〜ｆの実行に先立ってグローバル期待アプリケーション状態を有することができる。さらに、これは、このグローバル期待アプリケーション状態をいつでもオンデマンドで決定することができることを意味している。テストケース２０ａ〜ｆの実行からの期待結果は、決定論的とすることができる。代わりに、期待状態ジェネレータ３２ｔ〜ｚが非決定論的な結果が受け入れ可能であることを理解する場合には、期待結果は、非決定論的とすることもできる。

テストケース２０が完了すると、検証マネージャ３０は、別のスナップショットを取ることもでき、またこのアプリケーションのプロパティの現行値の、メモリへのコピーを行うこともできる。このスナップショットは、アプリケーションの現行グローバル状態を示すことができる。このプロパティの現行値は、現行アプリケーション状態データ構造３７に記憶することができる。次いで、コンペアラ３５は、期待アプリケーション状態データ構造３６を現行アプリケーション状態データ構造３７と比較する。どのような不一致も、さらなる注目を認可することができるエリアを指し示している。代替実施形態においては、データ構造３６、３７を、比較を実施するための適切な手段に送ることができる。例えば、この比較は、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ：拡張マークアップ言語）の使用を介して完了することもできる。

期待アプリケーション状態データ構造３６と現行アプリケーション状態データ構造３７の間の不一致は、このテスタに警告し、代替的な結論をもたらすこともある。この期待アプリケーション状態と現行アプリケーション状態の間の不一致は、アプリケーション１０が、適切な方法で動作していないエリアを示すこともある。かかるケースでは例えば、ソースコードのデバッギングまたは材料の構造の変更を必要とすることもある。すなわち例えば、テストケース２０ａ〜ｆが、青色の正方形の描画をもたらすように意図されており、代わりにテストケース２０ａ〜ｆが、赤色の正方形が描画される結果をもたらす場合には、このテスタは、アプリケーション１０を修正しテストケース２０ａ〜ｆを再び実行したいと思うこともある。このテスタがこのアプリケーションを開発する人でない場合には、このテスタは、バグをバグ追跡システムに記録し、電子メールを送信し、開発者のオフィスに歩いて行き、または他の何らかの通知システムを使用して、この開発者にこの正しくない動作（この赤色の正方形）について通知することができる。また例えば、テストケース２０ａ〜ｆが動作し続けるドアノブをもたらすように意図されていたが、代わりにドアノブを叩くモールが、このドアからこのドアノブをノックしてはずしてしまった場合には、このテスタは、より強度の高いファスナ（ｆａｓｔｅｎｅｒ）を使用して、このドアノブをこのドアに保持したいと思うこともある。代わりに、このテスタがこのドアを製造してもいない場合には、このテスタは、このドア製造業者に、より強度の高いファスナを使用するように勧めることができる。

不一致は、期待状態ジェネレータ３２の期待アプリケーション状態が非現実的であったことを示すこともできる。かかるケースでは、期待状態ジェネレータ３２に対する変更を認可することができる。例えば、テストすべきアプリケーション１０は、グラフィックアプリケーションとすることができる。１つまたは複数のテストケース２０ａ〜ｆは、マウスを使用して長方形を描くことを含むことができる。この場合に、１つまたは複数の期待状態ジェネレータ３２は、完全な長方形が描かれることを期待することができる。マウスを用いて完全な長方形を描くことがアプリケーション１０において現実的に可能ではない場合に、コンペアラ３５は、このテストがこの結果長方形における不完全性のために失敗したことを示すことができる。この場合には、テスタは、この適用可能な期待状態ジェネレータ３２に許容範囲を追加して、基本的に長方形であるが全く完全ではない長方形を含む期待アプリケーション状態を可能にすることもできる。

実施形態の一例においては、期待状態ジェネレータ３２は、テストケース２０ａ〜ｆ中で呼び出されるアクションおよびパラメータだけでなく、この現行アプリケーション状態にも基づいて期待状態を決定することができる。これにより、検証マネージャ３０は以前のテストケース故障を考慮に入れ、これらの故障に基づいて期待状態を決定することができるようになる。例えば、テストケース２０ａ〜ｆは、モールを用いてドアに取り付けられたドアノブを叩くことに関与することもある。このテストケースを実行する際に、このドアに取り付けられたヒンジが、損傷を受ける場合、将来のテストケース２０ａ〜ｆについてのこのヒンジの検証では、この以前の損傷に基づいて故障が示されないこともある。代わりに、検証マネージャ３０は、この以前の損傷を考慮に入れて、このヒンジの期待状態を決定することもできる。

図３Ａは、疎結合された検証を実施する方法の一例の流れ図を示している。検証方法２００は、テストケース２０ａ〜ｆを用いてステップ２０５から開始することができる。代替実施形態においては、テストケースイグゼキュタが、この検証マネージャに対して開始イベントを送り、または検証マネージャ３０を呼び出すことができる。この開始イベントまたは呼出しから、検証マネージャ３０は、待ち状態にあるテストケース２０について通知を受けることができる。テストケース２０ａ〜ｆは、このアクションのパラメータを含むアプリケーション１０に課されることになる明確なアクションを含むことができる。通知を受けると、検証マネージャ３０は、この現行グローバル状態のスナップショットを取ることができる。ステップ２１０において、検証マネージャ３０は、どの期待状態ジェネレータ３２が待ち状態にあるテストケース２０ａ〜ｆに関与し得るかを決定し、この適用可能な期待状態ジェネレータ３２に通知することができる。代わりに、検証マネージャ３０は、待ち状態にあるテストケース２０ａ〜ｆについて期待状態ジェネレータ３２のすべてに通知することもできる。ステップ２１５において、期待状態ジェネレータ３２は、テストケース２０ａ〜ｆの適用可能なアクションおよびパラメータを検討することになる。その１つまたは複数のコンポーネントのプロパティの現行値に基づいて、この期待状態ジェネレータは、テストケース２０の完了に応じて期待される期待コンポーネント状態を計算することができる。次いで、通知済みの各期待状態ジェネレータ３２は、その期待コンポーネント状態を検証マネージャ３０に送ることができる。このデータは、コンペアラ３５の期待アプリケーション状態データ構造３６に記憶することができる。適用可能な期待状態ジェネレータ３２のすべてが期待コンポーネント状態データを用いて報告したときには、（ステップ２２０において）検証マネージャ３０は、グローバル期待アプリケーション状態を有することになる。次いでステップ２２５において、検証マネージャ３０は、テストケース２０を実行することができることについてテストケース２０ａ〜ｆまたはテストイグゼキュタに通知することができる。このようにして、コントロールは、テストケース２０ａ〜ｆ（またはテストイグゼキュタ）に対して戻される。ステップ２３０において、テストケース２０ａ〜ｆを実行することができる。

図３Ｂは、図３Ａの流れ図に継続している。ステップ２３５において、テストケース２０ａ〜ｆは、このグローバルスナップショットをアップデートして実行することができる。テストケース２０の完了に応じて、ステップ２４０において、検証マネージャ３０は、テストケース２０ａ〜ｆが完了していることについて通知を受けることができる。ステップ２４５において、検証マネージャ３０は、現行アプリケーション状態のスナップショットを取ることができる。このスナップショットは、このアプリケーション上におけるこのテストケースの実際の結果を反映することができる。このスナップショットはまた、このアプリケーションのプロパティの値を表すこともできる。ステップ２５０において、検証マネージャ３０は、現行アプリケーション状態データ構造３７にこのスナップショットを記憶することができる。次いでステップ２５５において、検証マネージャ３０は、この期待アプリケーション状態データと現行アプリケーション状態データを比較し、ステップ２６０においてこの全体的な比較結果、またはこのプロパティの期待値および現行値が実質的に同じでない場合の任意の結果を報告することができる。本発明の代替実施形態においては、期待状態および現行状態のスナップショットをテストケースの実行中に完了することができる。すなわち、ステップ２１０ないし２６０のうちのすべてまたは一部をテストケース内で複数回実行することができる。

期待状態データ構造３６および現行状態データ構造３７の比較は、検証マネージャ３０内において完了することができる。代わりに、データ構造を拡張マークアップ言語（ＸＭＬ）に直列出力し（ｓｅｒｉｚｌｉｚｅ ｏｕｔ）、その結果ＸＭＬを用いてこの比較を完了することもできるようになる。かかるケースにおいては、このＸＭＬがデータ構造３６と３７を比較し、これらの結果を検証マネージャ３０、テストケース２０、またはこのテストイグゼキュタに送ることができる。本発明の代替実施形態においては、コンペアラ３５は、このテストケース実行プロセスから分離することができる。この分離により、テストケース実行に関係のない時にこの期待アプリケーション状態と現行アプリケーション状態の間の比較を完了できるようにすることができる。かかる場合には、この期待状態データおよび現行状態データは、データベースまたは他のデータストアに保存することもでき、またコンピュータメモリに保存することもできる。

本発明の実施形態の一例において、検証マネージャ３０は、この個々の検証結果のうちの結果を通知することもでき、またこの期待アプリケーション状態データと現行アプリケーション状態データが異なる（すなわち、故障が存在しているときの）これらのインスタンスだけを通知することもできる。この通知は、このテストケースが実行を終了した後のある時に行うことができ、このテストケースに全く関係のない手段を介して届けることもできる。例えば、コンペアラ３５は、検証結果を指定された連絡先に電子メールすることもできる。

この同じテストケース２０ａ〜ｆが再び実行される場合、あるいは異なるテストケース２０ａ〜ｆが実行される場合には、図３Ａ〜３Ｂに示す方法２００のステップのすべてが必要とされるとは限らないこともあることを理解されたい。例えば、検証マネージャ３０は、このコンペアラ３５中に待ち状態にあるテストケース２０についての期待状態データ構造を含むこともある。その場合には、検証マネージャ３０は、テストケース２０ａ〜ｆが実行されるのに先立って、期待状態ジェネレータ３２から期待コンポーネント状態データを取得する必要がないこともある。したがって、方法２００のすべてのステップが、テストケース２０ａ〜ｆが実行されるごとに完了される必要があるとは限らない。

図４は、本発明の代替実施形態による、テストケース実行に関して疎結合されたテストケース検証のためのシステムの一例のブロック図である。この代替実施形態においては、１つまたは複数のテストケース２０ａ〜ｆをアプリケーション１０に対して適用することができる。以上で説明したように、テストケース２０ａ〜ｆは、統合テストケースでもよく、あるいは機能テストケースでもよい。一般に、各テストケース２０ａ〜ｆは、アプリケーション１０に適用すべき明確なパラメータを伴う明確な刺激を有する。テストケース２０ａ〜ｆはそれぞれ、アプリケーション１０が実行すべき１ステップまたは非常に多数のステップとすることができる。各テストケース２０ａ〜ｆは、アプリケーション１０が動作する１つのテストまたは一連のテストとすることができる。検証マネージャ３０は、期待アプリケーション状態データ構造３６、および現行アプリケーション状態データ構造３７を有するコンペアラ３５を含むことができる。以上で説明したように、コンペアラ３５は、検証マネージャ３０から分かれており、検証マネージャ３０と情報をやりとりするものでもよいことを理解されたい。さらに、期待状態ジェネレータ３２ｘ〜ｚは、検証マネージャ３０から分かれていてもよい。この期待状態ジェネレータ３２は、検証マネージャ３０と情報をやりとりすることができる。この期待状態ジェネレータ３２と検証マネージャ３０の機能は、図２に関して説明したこれらの機能と同様または同じものとすることができる。各期待状態ジェネレータ３２ｔ〜ｚが焦点を合わせることができるコンポーネントは、アプリケーション１０内のデータポイントとすることができる。このデータポイントは、プロパティ値とすることができ、したがって各期待状態ジェネレータ３２ｔ〜ｚは、テストケース実行に先立って検証マネージャ３０に期待プロパティ値を供給することができる。さらに、この期待状態ジェネレータ３２は、他の期待状態ジェネレータ３２を含むことができる。この期待状態ジェネレータ３２は、検証マネージャ３０と情報をやりとりすることができる。さらに、この期待状態ジェネレータ３２は、プラグ可能なコンポーネントとすることができる１つまたは複数のデータベース３１ａ〜ｂと情報をやりとりすることもできる。

例えば、テストケース２０ａ〜ｆがモールを用いてドアに取り付けられたドアノブを叩くことに関与する場合、期待状態ジェネレータ３２ｘは、このドアに取り付けられたヒンジの期待状態を決定することができる。それを行う際に、期待状態ジェネレータ３２ｘは、期待状態ジェネレータ３２ｘ₁を呼び出して、このヒンジの下側部分について報告することができる。同様に、期待状態ジェネレータ３２ｘは、期待状態ジェネレータ３２ｘ₂を呼び出して、このヒンジの上側部分について報告することができる。期待状態ジェネレータ３２ｘは、期待状態を決定する際にこのデータを結合し、この結合済みのデータを、適切な時刻に、検証マネージャ３０に対して伝えることができる。さらに、期待状態ジェネレータ３２ｘがこのドアに取り付けられた１／８インチ（３．１７ミリメートル）の厚さの、２インチ（５．０８センチメートル）の長さの黄銅ヒンジに対するテストの効果を決定する場合に、期待状態ジェネレータ３２ｘは、データベース３１ａに照会して、例えば、黄銅の引張り強度に関する情報を検索することができる。

本明細書中で説明している様々な技法は、ハードウェアまたはソフトウェア、あるいは適切な場合にはこれら両者の組合せに関連して実装することができる。したがって、本発明の方法および装置、あるいはそのある種の態様または一部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読取り可能ストレージ媒体などの有形媒体の形で実施されるプログラムコード（すなわち、命令）の形態を取ることができ、ここで、このプログラムコードがコンピュータなどのマシンにロードされ、それによって実行されるときに、このマシンは、本発明を実行するための装置になる。プログラマブルコンピュータ上でプログラムコードを実行する場合には、このコンピューティングデバイスは、一般的にプロセッサと、（揮発性および不揮発性のメモリおよび／またはストレージエレメントを含めて）プロセッサによって読取り可能なストレージ媒体と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含むことになる。例えば、データ処理ＡＰＩなどの使用を介して、本発明のドメイン特有のプログラミングモデル態様の作成および／または実装を利用することができる１つまたは複数のプログラムは、高レベル手続き型プログラミング言語またはオブジェクト指向プログラミング言語で実装されて、コンピュータシステムと情報をやりとりすることが好ましい。しかし、この１つ（または複数）のプログラムは、必要に応じてアセンブリ言語またはマシン語で実装することができる。いずれにしても、この言語は、コンパイラ言語またはインタープリタ言語とすることができ、ハードウェア実装と組み合わせることができる。

本発明は、様々な図面に示す好ましい実施形態に関連して説明してきたが、本発明を逸脱することなく本発明の同じ機能を実施するために、他の実施形態も使用することができ、またこれら説明した実施形態に変更および追加を行うこともできることを理解されたい。本明細書全体にわたって、２つの主要な例、すなわち仮想グラフィックアプリケーションを取り扱う一方の例、およびドアに取り付けられたドアノブを伴う他方の例が提供されている。これらの特定の例は、理解を高めるために提供されている。本発明は、決してグラフィックアプリケーションまたはドアに取り付けられたドアノブを伴うアプリケーションだけに限定されるものではない。さらに、本発明は、任意のプロセス、マシン、製品、組成物、プログラム、ソフトウェア、ハードウェア、デバイス、メカニズム、または材料、あるいはこれらの任意の改良を含めて、任意のアプリケーションを含む任意のテストに含めることができる。したがって、本発明は、どのような一実施形態だけにも限定すべきではなく、そうではなくて添付の特許請求の範囲に従う広がりと範囲で解釈すべきである。

テストケース実行に関して疎結合されたテストケース検証の態様を実装することができるコンピューティング環境の一例を示すブロック図である。 本発明の一実施形態による、テストケース実行に関して疎結合されたテストケース検証のためのシステムのブロック図である。 本発明の一実施形態による、テストケース実行に関して疎結合されたテスト検証のための方法の流れ図である。 本発明の一実施形態による、テストケース実行に関して疎結合されたテスト検証のための方法の流れ図である。 本発明の代替実施形態による、テストケース実行に関して疎結合されたテストケース検証のためのシステムのブロック図である。

符号の説明

１０ アプリケーション
２０ａ、２０ｂ、２０ｃ、２０ｄ、２０ｅ、２０ｆ テストケース
３０ 検証マネージャ
３１ データベース
３２ｔ、３２ｕ、３２ｖ、３２ｗ、３２ｘ、３２ｙ、３２ｚ 期待状態ジェネレータ
３５ コンペアラ
３６ 期待状態
３７ 現行状態

Claims (26)

1. アプリケーションに適用されるアクションの複数の結果を検証するためのシステムであって、前記アクションはテストケースにより定義され、前記システムは、
   互いに独立に、かつ前記テストケースと独立に動作し、各々が前記アプリケーションに前記アクションを適用することの結果として前記アプリケーションの１または複数のコンポーネントの期待コンポーネント状態を計算し、期待アプリケーション状態をアップデートするための複数の期待状態ジェネレータと、
   現行アプリケーション状態を保持し、前記期待アプリケーション状態を前記現行アプリケーション状態と比較するための検証マネージャと
   を備えることを特徴とするシステム。
2. 前記複数の期待状態ジェネレータは、前記アクションの実行に先立って前記期待コンポーネント状態を決定することを特徴とする請求項１に記載のシステム。
3. 前記複数の期待状態ジェネレータは、オンデマンドで前記期待コンポーネント状態を決定することを特徴とする請求項１に記載のシステム。
4. 前記複数の期待状態ジェネレータは、前記期待コンポーネント状態を前記検証マネージャに伝えることを特徴とする請求項１に記載のシステム。
5. 前記複数の期待状態ジェネレータは、前記検証マネージャの外部にあることを特徴とする請求項４に記載のシステム。
6. 前記複数の期待状態ジェネレータと情報をやりとりするコンポーネントデータベースをさらに備え、前記コンポーネントデータベースは、前記期待状態ジェネレータが前記コンポーネントの前記期待コンポーネント状態を決定する際に円滑にすることを特徴とする請求項４に記載のシステム。
7. 前記アクションを実行するための、前記検証マネージャと情報をやりとりし、前記検証マネージャから独立したテストケースをさらに含むことを特徴とする請求項１に記載のシステム。
8. 前記アクションは、
   刺激と、
   パラメータと
   を含むことを特徴とする請求項１に記載のシステム。
9. 前記アクションは、機能テストおよび統合テストのうちの少なくとも一方であることを特徴とする請求項１に記載のシステム。
10. 期待アプリケーション状態データ構造と、現行アプリケーション状態データ構造とをさらに備えることを特徴とする請求項１に記載のシステム。
11. 前記期待アプリケーション状態データ構造は、前記複数の期待状態ジェネレータから受け取った情報を含むことを特徴とする請求項１０に記載のシステム。
12. 前記現行アプリケーション状態データ構造は、前記検証マネージャから受け取った情報を含むことを特徴とする請求項１０に記載のシステム。
13. 前記検証マネージャは、前記期待アプリケーション状態を前記現行アプリケーション状態とオフラインで比較することを特徴とする請求項１に記載のシステム。
14. 前記検証マネージャは、前記期待アプリケーション状態を前記現行アプリケーション状態とオンラインで比較することを特徴とする請求項１に記載のシステム。
15. 前記複数の期待状態ジェネレータは、データベースおよびネットワークロケーションのうちの少なくとも一方からロードされることを特徴とする請求項１に記載のシステム。
16. 前記検証マネージャは、前記期待アプリケーション状態の前記現行アプリケーション状態との比較の通知を提供することを特徴とする請求項１に記載のシステム。
17. 前記通知は、オフラインで完了されることを特徴とする請求項１６に記載のシステム。
18. アプリケーションに適用されるアクションの結果を検証するための方法であって、前記アクションはテストケースにより定義され、前記方法は、
    前記アプリケーションの現行アプリケーション状態を保存するステップと、
    前記アプリケーションに適用すべきアクションから期待アプリケーション状態を計算するステップであって、
    複数の期待状態ジェネレータの各々により、前記アプリケーションに前記アクションを適用することの結果として前記アプリケーションの１または複数のコンポーネントの期待コンポーネント状態を計算し、前記複数のジェネレータが、互いに独立に、かつ前記テストケースと独立に動作するステップ
    を含むステップと、
    前記期待アプリケーション状態を保存するステップと、
    前記アクションを実行するステップと、
    前記アプリケーションの前記現行アプリケーション状態をアップデートするステップと、
    前記アプリケーションの前記期待アプリケーション状態と前記アプリケーションの前記現行アプリケーション状態とを比較するステップと
    を備えることを特徴とする方法。
19. 最初の現行状態のコピーを作成するステップをさらに備えることを特徴とする請求項１８に記載の方法。
20. 前記アプリケーションの複数のコンポーネントについて複数の期待コンポーネント状態を受け取るステップをさらに備えることを特徴とする請求項１８に記載の方法。
21. 前記複数の期待コンポーネント状態は、期待アプリケーション状態データ構造に記憶されることを特徴とする請求項２０に記載の方法。
22. 前記複数の期待状態ジェネレータは、前記期待アプリケーション状態を前記現行アプリケーション状態と比較するための検証マネージャの外部に設置されることを特徴とする請求項２１に記載の方法。
23. 前記期待アプリケーション状態と前記現行アプリケーション状態とが等しくない場合に、テスタに通知するステップをさらに含むことを特徴とする請求項１８に記載の方法。
24. 前記アプリケーションの現行アプリケーション状態を保存するステップは、前記アクションが適用された後に完了することを特徴とする請求項１８に記載の方法。
25. 前記期待アプリケーション状態を保存するステップは、前記アクションが完了する前に完了することを特徴とする請求項１８に記載の方法。
26. コンピュータにより実行されたときに、請求項１８ないし２５のいずれかに記載の方法を実行する命令を記憶したことを特徴とするコンピュータ読取り可能記憶媒体。

Images