(57)【要約】【課題】  テストケースから実行挙動を分離し、実行挙動ライブラリを備え、または実行挙動ライブラリと通信する実行挙動マネージャ内に実行挙動を統合するシステムおよび方法を提供すること。【解決手段】  この方法は、テストケース中のステップまたはアクションを実行する実行挙動を選択すること、および実行挙動を実行のためにテストケースに送ることを含む。さらに、このシステムおよび方法は、全体的重み付けおよび局所的重み付けを実行挙動選択プロセスに適用することを実現し、以前に実行した挙動でテストケースを再実行することを可能にする。【選択図】  図２
2006099743.tif 000002
【特許請求の範囲】
【請求項１】
動作を実行する実行挙動を選択するシステムであって、
前記実行挙動を選択する実行挙動マネージャと、
前記実行挙動に関するデータを前記実行挙動マネージャに提供する挙動自動化ライブラリと
を備えたことを特徴とするシステム。
【請求項２】
複数の実行挙動のリストを含む挙動のレジスタをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項３】
前記実行挙動マネージャは、前記挙動のレジスタから動作を実行する潜在的な実行挙動を決定することを特徴とする請求項２に記載のシステム。
【請求項４】
前記動作は、複数の実行挙動のうちの１つによって実行されることを特徴とする請求項１に記載のシステム。
【請求項５】
前記動作は、一続きの複数の実行挙動を実行することによって実行されることを特徴とする請求項１に記載のシステム。
【請求項６】
前記実行挙動マネージャは、任意の順序でシーケンスを実行することを特徴とする請求項５に記載のシステム。
【請求項７】
前記実行挙動マネージャは、全体的重み付けおよび局所的重み付けの少なくとも一方に基づいて前記実行挙動を選択することを特徴とする請求項１に記載のシステム。
【請求項８】
前記局所的重み付けは、前記全体的重み付けを上書きすることを特徴とする請求項７に記載のシステム。
【請求項９】
前記実行挙動マネージャは、以前に選択した実行挙動に基づいて実行挙動を選択することを特徴とする請求項１に記載のシステム。
【請求項１０】
前記実行挙動マネージャは、使用可能にする実行挙動を選択することを特徴とする請求項１に記載のシステム。
【請求項１１】
前記動作は、機能テスト、機能テスト中の１つのステップ、統合テスト、統合テスト中の１つのステップのうちの少なくとも１つであることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記実行挙動マネージャは、前記挙動自動化ライブラリによって提供されたデータをインスタンス化して、選択した実行挙動を作成することを特徴とする請求項１に記載のシステム。
【請求項１３】
前記実行挙動は、属性を含むことを特徴とする請求項１に記載のシステム。
【請求項１４】
前記実行挙動マネージャは、前記選択した実行挙動を記録することを特徴とする請求項１に記載のシステム。
【請求項１５】
前記実行挙動マネージャは、前記選択した実行挙動を再実行することを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記実行挙動は、マウス、キーボード、アクセシビリティアプリケーションプログラミングインターフェース、およびオブジェクトモデルのうちの少なくとも１つによる入力を含むことを特徴とする請求項１に記載のシステム。
【請求項１７】
データ構造が格納されたコンピュータ読取可能な媒体であって、
テストケースによって適用される動作を各々実行する複数の実行挙動を表すデータを含む挙動自動化ライブラリに格納されたデータフィールドを
備えたことを特徴とするコンピュータ読取可能な媒体。
【請求項１８】
前記データ構造は、実行挙動を表すデータを実行挙動マネージャに提供することを特徴とする請求項１７に記載のコンピュータ読取可能な媒体。
【請求項１９】
動作を実行する実行挙動を選択する方法であって、
動作を受け取るステップと、
前記動作を実行するために複数の実行挙動を評価するステップと、
前記複数の実行挙動から１つの実行挙動を選択するステップと
を備えたことを特徴とする方法。
【請求項２０】
前記複数の実行挙動は、挙動のレジスタによって提供されることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記動作は、テストケース中の１つのステップであることを特徴とする請求項１９に記載の方法。
【請求項２２】
選択した実行挙動を前記テストケースに送るステップをさらに備えたことを特徴とする請求項２１に記載の方法。
【請求項２３】
前記選択するステップは、局所的重み付けと全体的重み付けの少なくとも一方に基づくことを特徴とする請求項１９に記載の方法。
【請求項２４】
選択した実行挙動を作成するステップをさらに備えたことを特徴とする請求項１９に記載の方法。
【請求項２５】
動作を実行するために実行挙動を選択する方法であって、
動作を受け取るステップと、
前記動作を実行するために複数の実行挙動を評価するステップと、
予め定められた一連の実行挙動の各々を選択するステップと
を備えたことを特徴とする方法。
【請求項２６】
前記一連の実行挙動中の各実行挙動は、予め定められた順序で選択されることを特徴とする請求項２５に記載の方法。
【請求項２７】
テストケースから動作を受け取るステップと、
前記動作を実行することができる複数の実行挙動を評価するステップと
を実施するコンピュータ実行可能命令を備えたことを特徴とするコンピュータ読取可能な媒体。
【請求項２８】
前記複数の実行挙動から１つの実行挙動を選択するステップを実施するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２７に記載のコンピュータ読取可能な媒体。
【請求項２９】
選択した実行挙動を前記テストケースに送るステップを実施するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３０】
予め定められた一連の実行挙動の各々を選択するステップを実施する別のコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２７に記載のコンピュータ読取可能な媒体。
【請求項３１】
前記一連の実行挙動中の各実行挙動が予め定められた順序で選択されることを特徴とする請求項３０に記載のコンピュータ読取可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション用のソフトウェアのテストに関し、詳細には、テストケースから実行挙動を抽出することに関する。
【背景技術】
【０００２】
本願は、本明細書と共に出願された「Automated Test Case Verification That Is Loosely Coupled With Respect To Automated Test Case Execution」という名称の米国特許出願整理番号ＭＳＦＴ−４１４９と、本明細書と共に出願された「Test Automation Stack Layering」という名称の米国特許出願整理番号ＭＳＦＴ−４１５０とに関連する。
【０００３】
ソフトウェア開発のライフサイクル上の主な段階は、設計段階、コーディング段階、コード完成段階、アルファ段階、ベータ段階、および最後に、市場へのリリースである。設計段階において、ソフトウェア製品が対処すべき顧客問題、およびソフトウェア製品の機能が定義される。通常は、機能仕様の完成によって設計段階が終了する。コーディング段階が既に始まっている場合もある。コード完成段階に到達すると、コードは書かれているが、必ずしもデバッグがされている必要はない。アルファ段階は、製品が安定した時点を表す。すなわち、主なバグの大部分が見つかっている。ベータ段階では、製品は主なすべてのバグを十分解決している。残りのバグは本質的に無害なものだけでなければならない。製品が最終品質保証チェックリストをパスすると、製品は市場へのリリースの準備が完了する。
【０００４】
ソフトウェアは正しく動作する必要があるので、テストはライフサイクルの重要な一部であり、いくつかの段階に及ぶことがある。ソフトウェアテストには、テストケース（おそらくは１組のテストケース）を考案すること、テストケースを入力として用いてソフトウェアを実行すること、およびテストケースを入力として用いたソフトウェアの実行によって期待した結果が得られるかをチェックすることが含まれる。ソフトウェアテストは、人間が手動で実施するか、または自動化ソフトウェアテストと呼ばれるようにプログラムで実行することができる。理想的には、ソフトウェアのテストは、ソフトウェアのライフサイクル上の可能な限り早い時期に始めるべきである。しかし一般には、設計段階が完了するまで、期待される機能を決定することができないので、設計段階が完了するまでソフトウェアを全くテストすることができない。通常、コーディング段階の間、開発者は、コードを書くときに開発者のコードを手動でテストする。自動化ソフトウェアテストは通常、開発プロセスのずっと後になるまで始めることができない。
【０００５】
コーディング時に開発者によって手動でテストされるものが唯一行われるテストであるときもある。しかし、自身の製品をテストする開発者は、そのコードを開発した本人であるから感情的になってしまい、そうでない人が見つけることができるバグを見落としてしまう可能性が高い。さらに、開発者のテスト範囲は通常、開発者のコードの機能、ならびに開発者のコードと限られた数の他のソフトウェアアプリケーションと統合したものに限定される。
【０００６】
こうした欠点に対処するため、多くのソフトハウスは、さらにソフトウェアをテストする別々のソフトウェアテストグループに、少なくとも部分的に自動化されたテスト技法をしばしば使用させる。通常、このようなテストグループは、テストケースを書いて実行することによって機能間およびアプリケーション間の複雑なやりとりをテストする。製品ライフサイクル中の設計段階という早い時期にテストグループを参加させることにより、機能仕様内の矛盾の識別、テスト困難なエリアの識別、およびその他を含む多くの利点が得られるが一般的には言えるであろう。しかし一般には、機能定義、実装、およびユーザインターフェース（ＵＩ）調整などが継続的に変化していく段階で各テストケースを最新に保つことは多くの労力を必要とすることから、この手法は非現実的である。結果的に、テストケースを書いて実行するのは通常、製品開発の最後に行われる慌ただしい事柄となってしまう。したがって、テスト、具体的には自動化テストは、いつまでも解決できない問題となりうる。ソフトウェア製品のライフサイクル中の可能な限り初期に、理想的には設計段階中にテストケースを記述し、自動化テストを利用する方法が求められているはずである。
【０００７】
１組のテストケースを開発するのは、それがいつ行われたとしてもかなり困難なものである。ましてアプリケーションの特定の機能をテストするには、多数の組のテストを書かなければならない。例えば、アプリケーションは、マウス、キーボード、デジタイザ、アクセシビリティソフトウェアにより、プログラム化するなど、要求される機能を実現するための多くの対話方法が可能である。したがって、ある機能に関する包括的テストを実現するには、１組のテストには、（ユーザが行うのと同様にテキストを打ち込む）マウスを介して機能を対話的に使用する１組のテスト、すなわちキーボードを介して機能を対話的に使用する１組、デジタイザを介して機能を対話的に使用する１組、デフォルトアクションを起動し、あるいはアクセシビリティアプリケーションを模倣するためのアクセシビリティソフトウェアを介して機能を対話的に使用する１組、アプリケーションのコーディングモデルを介して機能を対話的に使用する１組などが含まれなければならない。生成される１組のテストケースが機能またはアプリケーションの包括的テストを提供するか否かを確認し、さらにはその包括的テストを提供するために書かなければならない全テストケース数を削減する方法が求められているはずである。
【０００８】
さらに、これらのそれぞれの組のテスト内の論理の多くまたはすべてが、他の組のテスト内の論理と同一であり、結果処理の検証の多くまたはすべても同一である。したがって、多くのテストは同一であり、または非常に類似しており、したがって単に実行オプションを変更するだけで済むものである。例えば、上述の複数の形態の入力すべてについて、期待される結果は同一である可能性が高い。したがって、こうした各入力源についてのテストケースを作成することは通常、各入力源のためのテストを実行する別々の方法を書くことを必要とし、テストスクリプトの残りの大部分が重複することになる。わずかな変更で何度も同一のテストを書くことは冗長であり、工数を要する。この重複するコーディングをなくし、または著しく低減させ、書かなければならない全テストケース数を削減する方法が求められているはずである。
【０００９】
テストケースを実行した実際の結果が期待される結果と一致するかどうか（結果の検証、または検証）を判定するためのコードが、しばしばテストケース内に作成される。特定の結果検証の詳細を変更し、または新しい結果検証を追加すると、通常は各テストケースの修正が必要となる。検証のためのコードがテストケースと別々であれば利点が多くなるはずであり、テストケースの理解が容易となり、検証のためのコードの再利用および維持も容易となる。
【００１０】
実行の詳細はしばしばテストケース内で固定的にコーディングされ（ｈａｒｄ−ｃｏｄｅｄ）、テストケースが作成される前に設計段階を完了しておく必要がある。ソフトウェア開発ライフサイクルでテストケースをより容易に作成することができるように、特定の実行の詳細によってではなくユーザ操作によってテストケースを定義する方法が求められているはずである。
【００１１】
ソフトウェアアプリケーションをテストすることは、アプリケーションの初期の開発の段階およびアプリケーションに対し修正を実装する際に極めて重要なステップである。ソフトウェアアプリケーション開発者は、アプリケーションの開発のテスト段階で多くの労力を払う。このようなテストによって、アプリケーションが特定の操作に対して期待した仕方で応答することを保証することが可能となる。
【００１２】
通常、テストケースは、具体的にはアプリケーションのコンポーネントをテストするためにコーディングされる。例えば、ユーザインターフェース（ＵＩ）テストケースは、テキストボックス、ボタン、メニューなどの識別を表すコードを含んでおり、一方アプリケーションプログラミングインターフェース（ＡＰＩ）テストケースは、テストするＡＰＩと直接通信することができる。こうした実行の方法の各々についてテストケースを作成するためには、ほとんどの部分が同一のテストケースを作成する必要があり、テストケース間の違いは実行の仕方だけである。すなわち、あるテストケースは、ボタンを使用してアプリケーションのコンポーネントをテストすることを指定し、別のテストケースは、オブジェクトモデルを使用してコンポーネントをテストすることを指定することを定める場合がある。実行方法を除くと、こうしたテストケースおよび予想されるその実装の結果は同一である可能性がある。
【００１３】
さらに、テストケースには、各オペレーションがいくつかの実行方法（例えば、マウスでボタンまたはメニューを起動する、キーボードでボタンまたはメニューを起動する、マウスでメニューを起動し、キーボードでボタンを起動するなど）のいずれかを使用して完了することができる複数のオペレーションの実行が必要となる可能性がある。アプリケーションの複数のオペレーションを完了する実行方法のすべての考えられる組合せをテストするのに必要なテストケースの数は、比較的単純なアプリケーションであっても相当数に上る可能性がある。
【００１４】
すべての実行方法によってアプリケーションをテストするため、そのような大量のテストケースを開発することは困難であると予想される。そのような作業は、実行方法だけが変化した、多数のほぼ同一のテストケースを書き込むだけのものである可能性がある。さらに、テストケースの保守は、テストケースの作成に比してより労働集約的で時間がかかる可能性がある。アプリケーションが変更されると、適用可能なテストケースは、引き続き互換性を保証するために更新が必要となる可能性がある。各実行方法について書かれたそのような多数のテストケースを更新することも同様に困難な作業である。
【００１５】
さらに、一部の実行方法は、テストケースによっても全くテストされない可能性がある。テストケースは、アプリケーションが予期せぬ結果を引き起こすことなく特定のアクションを行うかどうかを判定するために設計されることがある。このようなテストケースは、テストケースの目的とはあまり関係のないように見える操作の実行方法とは無関係である可能性がある。しかし、テストの焦点がアプリケーションの何らかの他の面に当てられる可能性がある場合であっても、テストケースのあまり関係のないステップさえも様々な実行方法によってテストされるならば有利となるはずである。テストケースが主に、例えば青色の矩形を描画するアプリケーションの能力をテストするためのものである場合、テストケースは、新しい文書を開くステップを含む可能性ができる。新しい文書を開くことはテストケースの目的とはあまり関係のない可能性があるので、テストケースは、マウスだけを使用して完了するような操作となる可能性がある。しかし、新しい文書を開くためのすべての実行方法をテストすることは有用であるはずである。例えばキーボードを使用して新しい文書を開くことにより、青色の矩形が実際には赤色で作成され、円として作成され、あるいは期待される結果とは異なることが発見される可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
したがって、各実行方法または可能な実行方法のあらゆる組合せごとに、ほぼ同一のテストケースを作成することなく、様々な実行方法を使用してアプリケーションをテストすることが求められている。
【課題を解決するための手段】
【００１７】
本発明は、多数の実行方法または実行方法の組合せによって単一のテストケースを実行することを可能にする。こうした実行方法は「実行挙動（ｅｘｅｃｕｔｉｏｎ  ｂｅｈａｖｉｏｒ）」と呼ばれる。本発明は、実行挙動の多数の組合せを反映するために工数のかかる詳細なテストケースコードを必要とすることなく、様々な実行挙動によって単一のテストケースを実行することを可能にする。
【００１８】
本発明は、テストケースから実行挙動を分離し、「実行挙動マネージャ」と呼ばれる別々の装置に実行挙動の選択を委ねる。テストケースまたはテストケース中のステップは、実行挙動マネージャを呼び出すことができる。実行挙動マネージャは実行挙動を選択し、テストケースで実行するために実行挙動を送り戻す。実行挙動マネージャは、テストケースからの以前の呼出しに対して送った以前の実行挙動に基づいて実行挙動を選択することができる。実行挙動マネージャは、以前に提供した実行挙動を追跡し、利用可能なすべての実行挙動を循環することができる。これにより、利用可能なすべての実行挙動によるアプリケーションのテストの平衡が得られる。
【００１９】
さらに、適切な実行挙動の選択に関するすべての決定において、実行挙動マネージャによって「グローバルな」重み付けを適用することができる。例えば、アプリケーションでメニューが再構築された場合、８０％の時間メニューを使用し、２０％の時間ツールバーボタンを使用するように実行挙動マネージャに伝える全体的重み付けを適用することができる。この全体的重み付けは、各実行挙動を等しい回数選択する実行挙動マネージャの通常オペレーションを上書きすることができる。
【００２０】
さらに、テストケースは、「ローカル」重み付けによって全体的重み付けを上書きすることができ、例えばツールバーボタンを使用してテストケースの「新しい文書を開く」ステップを実行するように実行挙動マネージャに伝えることができる。例えばツールバーが最近再構築され、それが特定のテストケースで適切に動作することを保証するように試験者が望む場合、この上書きは重要である。あるいは、どちらの重み付けも挙動を実行する際に考慮するように、局所的重み付けを全体的重み付けと同時に使用することができ、または局所的重み付けを全体的重み付けと直交して使用することができる。
【００２１】
上記の概要ならびに例示的実施形態の以下の詳細な説明は、添付の図面と共に読むときにより良く理解することができる。本発明を例示するために、図面では本発明の例示的構成を示す。しかし、本発明は開示の特定の方法および手段に限定されない。
【発明を実施するための最良の形態】
【００２２】
概要
テストケースから実行挙動を分離して実行挙動マネージャで実行挙動を統合することにより、アプリケーションをより徹底的にテストすることが可能となる。本発明は、すべての実行挙動および実行挙動の組合せを使用することによって単一のテストケースを実行することを可能にすることにより、より完全なテストを提供する。テストケースから実行挙動を分離することにより、実行挙動マネージャは、テストケースの各ステップについて様々な実行挙動のすべてを繰り返し実行し続けることができる。このようにして、各ステップについて様々な実行方法の多数の組合せをテストすることができ、より高い包括性が得られる。本発明では、テストケースの各ステップについて実行方法の特定の組合せることにより、以前気付かなかった可能性のあるバグを検出することが可能となる。さらに、本発明により、厳密な実行挙動を用いてそのようなテストケースを再実行し、バグが修復されたかどうかを判定することが可能となる。
【００２３】
例示的コンピューティング環境
図１および以下の説明は、本発明を実施することができる適切なコンピューティング環境の簡潔で一般的な説明である。しかし、前述のように、ハンドヘルド装置、ポータブル装置、およびその他のすべての種類のコンピューティング装置が、本発明と共に使用するように企図されることを理解されたい。汎用コンピュータについて以下で説明するが、これは一例である。本発明は、ネットワークサーバ相互運用性および対話を有するシンクライアント上でも動作可能である。したがって、非常にわずかな、または最小のクライアント資源しかないネットワークホストサービスの環境、例えばクライアント装置が単にワールドワイドウェブに対するブラウザまたはインターフェースとして働くネットワーク環境で本発明の例示的な実施形態を実施することができる。
【００２４】
必須ではないが、本発明は、開発者または試験者が使用するアプリケーションプログラミングインターフェース（ＡＰＩ）を介して実装することができ、および／または１つ若しくは複数のコンピュータ（例えばクライアントワークステーション、サーバ、若しくはその他の装置）によって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的文脈で説明されるネットワーク閲覧ソフトウェア内に含めることができる。一般に、プログラムモジュールには、特定のタスクを実行し、あるいは特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、様々な実施形態で必要に応じて組み合わせることができ、または分散させることができる。さらに、本発明を他のコンピュータシステム構成を用いて実施できることを当業者は理解されよう。本発明に使用するのに適している可能性のある他の周知のコンピューティングシステム、環境、および／または構成には、限定はしないが、パーソナルコンピュータ（ＰＣ）、現金自動預払機、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明の一実施形態は、通信ネットワークあるいはその他のデータ伝送媒体を通じてリンクされたリモート処理装置でタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルとリモートのどちらのコンピュータ記憶媒体にも配置することができる。
【００２５】
したがって、図１は本発明を実施することのできる適切なコンピューティングシステム環境１００の一例を示すが、上記で明らかにしたようにコンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用法または機能の範囲について何らかの制限を示唆するものではない。例示的な動作環境１００に示す構成要素のいずれか１つあるいはその組合せに関して、コンピューティング環境１００が何らかの依存関係または要件を有すると解釈すべきでもない。
【００２６】
図１を参照すると、本発明を実施する例示的なシステムは、コンピュータシステム１１０の形態の汎用コンピューティング装置を備える。コンピュータシステム１１０の構成要素には、限定はしないが、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む数種類のバス構造のいずれでもよい。例えばこうしたアーキテクチャには、限定はしないが、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス（メザニンバスとも呼ばれる）が含まれる。
【００２７】
通常、コンピュータシステム１１０は様々なコンピュータ読取可能な媒体を含む。コンピュータ読取可能な媒体は、コンピュータシステム１１０がアクセスできる利用可能ないずれの媒体でもよく、それには不揮発性媒体と揮発性媒体の両方、取り外し可能媒体と固定媒体の両方が含まれる。例えば、限定はしないが、コンピュータ読取可能な媒体にはコンピュータ記憶媒体と通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュール、あるいはその他のデータなどの情報を格納するために任意の方法または技術で実装された揮発性媒体と不揮発性媒体の両方、取り外し可能媒体と固定媒体の両方が含まれる。コンピュータ記憶媒体には、限定はしないが、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、電気消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、またはその他のメモリ技術、コンパクトディスク読取り専用メモリ（ＣＤＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）、またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、またはその他の磁気記憶装置、あるいは所望の情報を格納するのに使用することができ、コンピュータシステム１１０がアクセスが可能な他のいずれの媒体も含まれる。通信媒体は通常、コンピュータ読取可能命令、データ構造、プログラムモジュール、あるいはその他のデータを、搬送波や他の移送機構などの被変調データ信号で具体化し、それには任意の情報送達媒体が含まれる。「被変調データ信号」という用語は、信号の特性集合のうちの１つまたは複数を有する信号、または情報を信号内に符号化するように変化する信号を意味する。例えば、限定はしないが、通信媒体には、有線ネットワークやダイレクトワイヤード接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、他のワイヤレス媒体などのワイヤレス媒体が含まれる。上記のいずれかの組合せもコンピュータ読取可能な媒体の範囲内に含めるべきである。
【００２８】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータシステム１１０内の要素間で情報を転送する助けとなる基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、処理装置１２０から即座にアクセス可能であり、かつ／若しくは処理装置１２０によって現在操作されているデータおよび／またはプログラムモジュールを含む。例えば、限定はしないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。ＲＡＭ１３２は、他のデータおよび／またはプログラムモジュールを含むことができる。
【００２９】
コンピュータシステム１１０は、その他の取り外し可能／固定、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単なる例に過ぎないが、図１に、固定な不揮発性の磁気媒体を読み書きするハードディスクドライブ１４１、取り外し可能な不揮発性の磁気ディスク１５２を読み書きする磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭやその他の光学媒体などの取り外し可能な不揮発性の光ディスク１５６を読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用することができるその他の取り外し可能／固定、揮発性／不揮発性のコンピュータ記憶媒体には、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インターフェース１４０などの取外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００３０】
上記で説明し、図１に図示するドライブとその関連するコンピュータ記憶媒体は、コンピュータシステム１１０に関するコンピュータ読取可能命令、データ構造、プログラムモジュール、および他のデータの記憶を実現する。例えば図１では、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして図示している。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であっても、異なっていてもよいことに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが相異なるコピーであることを示すために異なる番号を付けてある。ユーザは、キーボード１６２や、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータシステム１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらの入力装置や他の入力装置はしばしば、システムバス１２１に結合されるユーザ入力インターフェース１６０を介して処理装置１２０ａ〜ｆに接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。
【００３１】
モニタ１９１または他のタイプのディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１に加えて、コンピュータシステムはまた、スピーカ１９７やプリンタ１９６などの他の周辺出力装置も含むことができ、その周辺出力装置は、出力周辺インターフェース１９５を介して接続することができる。
【００３２】
コンピュータシステム１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般に、コンピュータシステム１１０に関して上記で述べた要素のうちの多数またはすべてを含むが、図１にはメモリ記憶装置１８１だけを示している。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００３３】
ＬＡＮネットワーキング環境で使用する際、コンピュータシステム１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータシステム１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２またはその他の機器を含む。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インターフェース１６０、またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータシステム１１０に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。例えば、限定はしないが、図１に、リモートアプリケーションプログラム１８５を、メモリ装置１８１上に常駐するものとして示す。図示するネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されよう。
【００３４】
コンピュータ１１０またはその他のクライアント装置をコンピュータネットワークの一部として使用できることを当業者は理解されよう。この点で、本発明は、任意の数のメモリまたは記憶装置、および任意の数の記憶装置またはボリューム間で行われる任意の数のアプリケーションおよびプロセスを有する任意のコンピュータシステムに関する。本発明の一実施形態は、リモート記憶装置またはローカル記憶装置を有する、ネットワーク環境内に配置されたサーバコンピュータおよびクライアントコンピュータを有する環境に適用することができる。本発明は、プログラミング言語機能、解釈機能、および実行機能を有するスタンドアロンコンピューティング装置にも適用することができる。
【００３５】
実行挙動の抽出を介してアプリケーションをテストするシステムおよび方法
図２に、本発明の一実施形態による実行挙動抽出を用いたテストケースを実施するためのシステム５のブロック図を示す。システム５は、テスト実行プログラム５０、テストケース２０、挙動マネージャ３０、レジスタ３１、および挙動自動化ライブラリ４０のうちの１つまたは複数を含むことができる。
【００３６】
テスト実行プログラム５０は、１つのテスト実行プログラム５０ａでよく、または複数のテスト実行プログラム５０ａ〜ｃなどでよい。テスト実行プログラムは各々、１つまたは複数のコンピュータ上に常駐する。各コンピュータは、図１に関して説明したコンピュータ１１０でよい。各テスト実行プログラム５０はすべて、テストケース２０などの同一のテストケースを実行することができ、または異なるテストケースを各々実行することができる。さらに、テスト実行プログラム５０ａ〜ｃは、１つの挙動マネージャ３０と通信することができ、またはそれぞれ挙動マネージャ（図示せず）と通信することができるテスト実行プログラム５０ａ〜ｃは、ユーザ（図示せず）が例えばテスト実行プログラム５０ａ〜ｃ上のボタンを押下することによってテストケース２０を実行することができる。あるいは、テスト実行プログラム５０ａ〜ｃは、開始イベントを起動してテストケース２０を実行する実験テスト自動化プロジェクトの一部とすることができる。テスト実行プログラム５０ａ〜ｃは、他の手段によってテストケース２０を実行することもできる。
【００３７】
テストケース２０は、アプリケーション（図示せず）の１つまたは複数のコンポーネントまたはプロパティをテストすることができる。アプリケーションは、任意のプロセス、マシン、製造、物質の組成、プログラム、ソフトウェア、ハードウェア、装置、機構、または材料、あるいはそれらの任意の改良でよい。例えば、アプリケーションは、任意のコンピューティングシステムまたは環境上で動作するソフトウェアプログラムとすることができる。さらに、例えば、アプリケーションはコンピュータハードウェアとすることもできる。またはこれに代えて、アプリケーションは、ドアに取り付けられたドアノブおよびヒンジの強度、弾力性、操作性をテストするためにハンマがドアノブをたたくドアテスト機構とすることができる。アプリケーションは、新規に開発中のもの、以前のアプリケーションの更新バージョン、エンドユーザが何らかの方式で修正した、以前にリリースしたアプリケーションなどとすることができる。
【００３８】
テストケース２０は、アプリケーションの機能テスト、統合テスト、またはその他のテストを実施することができる。機能テストは、アプリケーションの特定の機能コンポーネントのテストを含むことができる。機能レベルでは、コンポーネントは、各々テストを必要とする可能性のある多数の挙動を含むことができる。さらに、コンポーネントについての実行挙動の各組合せについては、テストがすべての可能性のある組合せおよびすべての異なる可能性の範囲にわたってテストすることを保証することが必要となる可能性がある。統合テストは、２つ以上の対話するコンポーネントが結合し、一緒に機能し、互いに影響を及ぼす仕方をテストする。
【００３９】
テストケース２０は、実行挙動のうちの１つまたは複数の実行を包含することができ、または要求することができる。「実行挙動」は、アプリケーション上で、またはアプリケーションによって実行すべき操作を記述したものである。実行挙動は、例えば「新しい文書を開く」、または「青色の矩形を描画する」、または「ハンマでドアノブをたたく」とすることができる。様々なタイプの実行挙動が存在する。
【００４０】
一種の実行挙動では、可能な実行の方法を１つだけ含めることができる。例えば、そのような実行挙動により、キーボード上のスペースバーを押下して、アプリケーションがテキストボックス上のボタンを起動することが要求されるようにすることができる。この挙動は、１つの方式でのみ実行することができるので、「ｄｏ  ｉｔ」挙動と呼ぶことができる。「ｄｏ  ｉｔ」挙動は、実行の前に追加の情報またはアクションを必要とすることなく実行することができる。「ｄｏ  ｉｔ」挙動は、テストケース２０の「ｄｏ  ｉｔ」挙動としてシステム５に含まれる。
【００４１】
実行挙動は、他の子実行挙動から構成される親実行挙動とすることができる。このような親実行挙動は、選ばれる複数の子実行挙動から構成することができるので、「ｃｈｏｏｓｅ  ａｎｙ」挙動と呼ぶことができる。この親実行挙動は「ｃｈｏｏｓｅ  ａｎｙ」挙動とすることができ、代替の実行挙動を使用して実行することができる。
【００４２】
テストケース２０は、挙動自動化ライブラリ４０から挙動を選択するように実行挙動マネージャに要求する「ｃｈｏｏｓｅ  ａｎｙ」挙動に対する呼出し２１を含むことができる。テストケース２０はまた、挙動自動化ライブラリ４０に格納された「ｄｏ  ｉｔ」挙動の実行を開始する「ｄｏ  ｉｔ」挙動に対する呼出し２２も含むことができる。
【００４３】
図３は、いくつかの例示的な実行挙動を示し、例示的な実行挙動間の関係を示すブロック図２００である。「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０は、新しい文書を開くための挙動とすることができる。新しい文書を開く「ｃｈｏｏｓｅ  ａｎｙ」挙動は、３つの子実行挙動のいずれかによって実行することができる。「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０の１つの子実行挙動は、マウスを使用して新しい文書を開く別の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１５とすることができる。「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０の別の子実行挙動は「ｄｏ  ｉｔ」挙動２２０とすることができ、この「ｄｏ  ｉｔ」挙動２２０は、キーボード上のスペースバーを押下することによりテキストボックス上のボタンを起動することによって新しい文書を開くためのものとすることができる。「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０の第３の子挙動は、以下で説明する「ｅｘｅｃｕｔｅ  ｉｎ  ａｎｙ  ｓｅｑｕｅｎｃｅ」挙動２３０とすることができる。以下で説明するように、実行挙動マネージャ３０は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０を実行するため、子実行挙動２１５、２２０、２３０のうち１つを選択することができる。
【００４４】
上述のように、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０の第１の子実行挙動は、それ自体「ｃｈｏｏｓｅ  ａｎｙ」挙動２１５とすることができ、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１５は、マウスを使用して新しい文書を開くための挙動とすることができる。「ｃｈｏｏｓｅ  ａｎｙ」挙動２１５は、２つの子挙動から構成することができる。一方の子挙動は、マウスを使用して一定のボタンをクリックして新しい文書を開く「ｄｏ  ｉｔ」挙動２１７とすることができる。実行挙動マネージャ３０が「ｄｏ  ｉｔ」挙動２１７を選択した場合、この挙動が実行のため「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０に送り戻される。あるいは、実行挙動マネージャ３０は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１５の他方の子挙動に注目することもできる。他方の子挙動は、マウスを使用してメニューを起動して新しい文書を開く「ｃｈｏｏｓｅ  ａｎｙ」挙動２１６とすることができる。
【００４５】
「ｃｈｏｏｓｅ  ａｎｙ」挙動２１６はまた２つの子挙動を有することができる。一方の子挙動は、マウスを使用してメニューを起動し、メニュー上の「新しいファイル」ボタンをクリックして新しい文書を開く「ｄｏ  ｉｔ」挙動２１８とすることができる。第２の子挙動は、マウスを使用してメニューを起動し、適用可能なメニュー項目を直接起動するキーボード「ホットキー」またはニーモニックショートカットを使用して新しい文書を開く「ｄｏ  ｉｔ」挙動２１９とすることができる。ホットキーは、メニュー上の「新しいファイル」ボタンを起動することができる。したがって、「ｄｏ  ｉｔ」挙動２１９は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０の「曾孫」とし、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０を実行するために選択される「ｄｏ  ｉｔ」挙動とすることができる。
【００４６】
「ｄｏ  ｉｔ」挙動および「ｃｈｏｏｓｅ  ａｎｙ」挙動に加えて他の実行挙動も存在する場合がある。任意のシーケンスで実行するためにすべての子挙動の選択を要求することができる「ｅｘｅｃｕｔｅ  ｉｎ  ａｎｙ  ｓｅｑｕｅｎｃｅ」挙動２３０が存在する場合がある。例えば、「ｅｘｅｃｕｔｅ  ｉｎ  ａｎｙ  ｓｅｑｕｅｎｃｅ」挙動が３つの子挙動「ｄｏ  ｉｔ」挙動２３１、「ｄｏ  ｉｔ」挙動２３２、および「ｄｏ  ｉｔ」挙動２３３を有する場合、実行挙動マネージャ３０は、実行のために任意の順序で各々の子「ｄｏ  ｉｔ」挙動２３１、２３２、２３３を「ｃｈｏｏｓｅ  ａｎｙ」挙動２１０に送ることができる。
【００４７】
さらに、図３に図示していない他の実行挙動も考えることができる。要求した順序で実行するために子挙動の選択を要求することができる「ｅｘｅｃｕｔｅ  ｉｎ  ｓｅｑｕｅｎｃｅ」挙動を考えることができる。何らかの条件を満たすまで１つまたは複数の実行挙動の実行を要求することができる「ｄｏ  ｕｎｔｉｌ」挙動が存在することができる。例えば、「ｄｏ  ｕｎｔｉｌ」挙動は、子挙動を２０回実行するまで子挙動を実行すること要求する。本明細書に記載の実行挙動は実行挙動の例であることを理解されたい。本発明の実施形態で使用される他の実行挙動が存在できることを当業者は理解されよう。
【００４８】
各実行挙動は、属性またはプロパティを有することができる。こうした属性またはプロパティは、例えばＣ＃または．ＮＥＴ属性機構により記述することができる。この機構は、実行挙動に関する実行方法を含む様々なプロパティを実行挙動に適用することができる。例えば、あるプロバティは、マウスを使用して実行挙動を実行することを指定することができ、別のプロバティは、キーボードを使用して実行を指定することができる。
【００４９】
実行挙動は、それが「ｃｈｏｏｓｅ  ａｎｙ」挙動などのより大きい親挙動の一部であることを「知る」ことができない。しかし実行挙動は、その子挙動を「知る」ことができる。このことも例えばＣ＃属性または．ＮＥＴ属性によって定義することができる。すなわち、実行挙動を例えば「ｃｈｏｏｓｅ  ａｎｙ」挙動と呼ぶ属性を、実行挙動に割り当てることができる。この属性はまた、「ｃｈｏｏｓｅ  ａｎｙ」挙動にその子挙動を与えることができる。
【００５０】
図２に戻ると、上述のように、テストケース２０は、複数の実行挙動を有するようにすることができる。例えば、グラフィックスアプリケーションに関するテストケース２０は、文書上の特定の位置で青色の矩形を描画することを要求することができる。そのようなテストケース２０は、新しい文書を開くステップと、特定の位置に矩形を描画するステップと、その矩形に青色を塗るステップとを含むことができる。テストケースの各ステップは、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１、「ｄｏ  ｉｔ」挙動２２、またはその他の任意の種類の実行挙動とすることができる。例えば、新しい文書を開くステップは、マウスを使用してメニューを起動して新しい文書を開く、マウスを使用してツールバー上のツールを起動して新しい文書を開く、キーボードを使用してメニューを起動して新しい文書を開くなどの「ｄｏ  ｉｔ」挙動を含む「ｃｈｏｏｓｅ  ａｎｙ」挙動２１とすることができる。矩形を描画するステップと、矩形に色を塗るステップとは各々、様々な子「ｄｏ  ｉｔ」挙動によってプロジェクトパネルまたはメニューを起動することを要求する「ｃｈｏｏｓｅ  ａｎｙ」挙動２１とすることができる。マウス、キーボード、オブジェクト、または例えばコンピュータ画面を見ることが困難なユーザ用のアクセシビリティアプリケーションプログラミングインターフェースによってメニューを起動することができる。キーボードを使用して「ホットキー」または矢印キーを発行し、メニューに導くことができる。
【００５１】
テストケース２０の実行時に、ステップが「ｄｏ  ｉｔ」挙動２２を含む場合、テストケース２０はその挙動を実行することができる。例えばそのステップを完了するための実行方法が１つしかない場合、テストケースは「ｄｏ  ｉｔ」挙動ステップを含むことができる。例えば、このステップは、キーボード上の「エンター」キーを押下することによってボタンを起動することを要求することができる。この挙動を実行する方法が１つだけしかないので、テストケース２０は、実行挙動マネージャを呼び出すことなくこの「ｄｏ  ｉｔ」挙動を実行することができる。
【００５２】
しかし、ステップが例えば「ｃｈｏｏｓｅ  ａｎｙ」挙動２１を含む場合、実行挙動マネージャ３０は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１の子実行挙動を選択し、実行するために親「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に選択した挙動を送ることができる。
【００５３】
実行挙動マネージャ３０は、図１に関して説明したようにコンピュータ１１０上に常駐することができる。実行挙動マネージャ３０は、実行挙動のレジスタ３１を含むことができる。実行挙動のレジスタ３１は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１などの親実行挙動および関連する子挙動のリストを含むことができる。レジスタ３１を用いると、実行挙動マネージャ３０は、例えばどの子挙動または挙動が親「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に属するかを判定することができる。
【００５４】
各実行挙動または各実行挙動についてのコーディングは、実行挙動マネージャ３０と通信する挙動自動化ライブラリ４０に配置することができる。実行挙動マネージャ３０は、子挙動を選択して実行することを求めるテストケース２０の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１からの要求の処理を担うことができる。
【００５５】
上述のように、例えば「ｃｈｏｏｓｅ  ａｎｙ」挙動２１を含むテストケース２０の実行時に、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１は、実行挙動マネージャ３０が子（または孫など）「ｄｏ  ｉｔ」挙動を選択し、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に送り戻すように実行挙動マネージャ３０に呼び掛けることができる。挙動マネージャは、親「ｃｈｏｏｓｅ  ａｎｙ」実行挙動に関連する子挙動のリストを調べ、子実行挙動の１つを選択することができる。このオペレーションを完了する際に、実行挙動マネージャ３１は、例えばリフレクションメソッドを使用することができる。リフレクションメソッドは、動的プログラミングを可能にするメソッドを含むことができ、実行挙動などのオブジェクトの属性をプログラムにより調べるメソッドを含む。このメソッドにより、実行挙動マネージャ３０は、実行挙動などのオブジェクトを調べ、その名前、実行挙動がサポートするメソッド、およびそのプロパティまたは属性を判定することができる。次いで実行挙動マネージャ３０は、例えば「ｃｈｏｏｓｅ  ａｎｙ」挙動２１の子実行挙動のプロパティまたは属性を判定し、（子が「ｄｏ  ｉｔ」挙動であると仮定して）実行のために子挙動を選択することができる。リフレクションメソッドを使用することにより、子挙動をインスタンス化し、実行のために「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に戻すことができる。子実行挙動自体も「ｃｈｏｏｓｅ  ａｎｙ」挙動である場合、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に関係する「ｄｏ  ｉｔ」挙動を選択するまでシーケンスを反復する。あるいは、レジスタがデータベースまたはその他のデータストアである場合に、レジスタが１組の関数ポインタで初期化される場合、リフレクションメソッドが実行挙動を実行するのを不要にすることができる。さらに、レジスタをテストケース実行中に要求初期化する（ｄｅｍａｎｄ−ｉｎｉｔｉａｌｉｚｅ）のではなく、テストケース実行の前に完全に初期化できることを当業者は理解されよう。
【００５６】
実行挙動マネージャ３０は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１について次に実行すべき子実行挙動を選択することができる。例えば、最初に「ｃｈｏｏｓｅ  ａｎｙ」挙動２１を含むテストケース２０が実行されると、実行挙動マネージャ３０は、例えばメニューを起動して新しい文書を開くためにマウスの使用を必要とする「ｄｏ  ｉｔ」挙動を選択することができる。テストケース２０が再び実行されると、実行挙動マネージャ３０は次に、キーボードホットキーを使用して新しい文書を開くことを必要とする「ｄｏ  ｉｔ」挙動を選択することができる。このようにして、実行挙動マネージャ３０は、テストケース２０が実行方法を指定することなく、親「ｃｈｏｏｓｅ  ａｎｙ」挙動２１についての実行方法を自動的に交替させることができる。このテストケース２０からの実行挙動の抽出により、テストケース２０を実行する異なる方法を反映するような異なるテストケース２０の作成を要することなく、同じ量だけ各実行方法をテストすることが可能となる。もちろん、他の様々な選択アルゴリズムも思い浮かべることができる。
【００５７】
親がテストケース２０内の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１である場合であっても、子実行挙動は実行挙動マネージャ３０によって選択するために常に動作可能および利用可能であるわけではないことに留意されたい。例えば、矩形を描画する「ｃｈｏｏｓｅ  ａｎｙ」挙動２１について５つの異なる子「ｄｏ  ｉｔ」挙動が存在する可能性がある。子「ｄｏ  ｉｔ」挙動の１つは、マウスを用いてフリーハンドで矩形を描画するためのものである可能性がある。テストケース２０が厳密な寸法の矩形を描画することを必要とする場合、実行挙動マネージャ３０が挙動のプロパティまたは属性を調べる際に子実行挙動が厳密な寸法の矩形を描画するようには設計されていないと判定したときは、フリーハンドで矩形を描画する子「ｄｏ  ｉｔ」挙動を使用不能にすることができる。したがって、実行挙動マネージャは、実行挙動の属性またはプロパティを調べることによってどの「ｄｏ  ｉｔ」挙動を使用可能にすべきでないかを判定することができる。あるいは、実行挙動マネージャ３０は、「ｄｏ  ｉｔ」挙動をインスタンス化し、次いで、この例を続けると、子実行挙動が厳密な寸法の矩形を描画することができるかどうかを判定することにより、どの実行挙動を使用可能にすべきでないかを判定することもできる。あるいは、実行挙動マネージャは、子挙動に添付された属性を検査し、または他の場所を捜して、挙動が使用可能にされるかどうかを判定するのに使用するメソッドを見つけることもできる。
【００５８】
それとは別に、全体的重み（ｇｌｏｂａｌ  ｗｅｉｇｈｔ）因子を実行挙動マネージャ３０に付与して、実行挙動マネージャ３０が他の子「ｄｏ  ｉｔ」挙動よりも頻繁に、または他の子「ｄｏ  ｉｔ」挙動を除外して１つの子「ｄｏ  ｉｔ」挙動を選択することができる。実行挙動マネージャ３０は、各挙動に関連する重みに基づいて、どの挙動をテストケース２０の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に送るかを決定することができる。実行挙動マネージャは、こうした重みを考慮して、実行すべき動作（ａｃｔｉｏｎ）のマトリックス全体を構築することができる。このようにして、試験者は、必要なら、すべてのテストケースについて、他の実行挙動よりも頻繁に一定の実行挙動をテストすることができる。例えば、キーボード操作がアプリケーションで修正されている場合、この重み付けは有用である。「ｃｈｏｏｓｅ  ａｎｙ」挙動がマウス入力およびキーボード入力を対象とする子「ｄｏ  ｉｔ」挙動を有することができる間、例えば時間の８０％、時間の１００％、または時間の９６．３％でキーボード入力を要求する子挙動を実行挙動マネージャ選択が選択するように全体的重み付けを適用することができる。このようにして、重み付けが適用されない場合よりもキーボード入力を徹底的にテストすることができる。さらに、例えばホットキーがアプリケーションで機能しない場合、全体的重み付けを適用して、どんなテストケースでもホットキーを決して使用しないように実行挙動マネージャ３０に伝えることができる。このようにして、無効なホットキーによって障害が引き起こされることなくテストケースを実行することができる。
【００５９】
局所的重み付け（ｌｏｃａｌ  ｗｅｉｇｈｔ）を使用して全体的重み付けを上書きすることができる。テストケース２０の一部として局所的重み付けを含めることができ、挙動自動化ライブラリ４０内のすべての挙動にではなく特定の挙動に局所的重み付けを適用することができる。例えば、全体的重み付けがホットキーの使用を除外し、試験者がテストケースのあるステップの間にホットキーを使用したい場合、テストケース２０内で局所的重み付けを使用して、ホットキーの使用を含む子「ｄｏ  ｉｔ」挙動を選択するように実行挙動マネージャ３０に伝えることができる。このようにして、局所的重み付けにより、任意の適用可能な全体的重み付けを上書きすることができる。
【００６０】
本発明の代替の実施形態において、実行挙動マネージャ３０は、テストケース２０のうちの「再実行可能性（ｒｅｐｌｙａｂｉｌｉｔｙ）」を実行可能にすることができる。このようにして、回帰テスト、すなわち以前に障害またはバグが生じたのと同じ方式でアプリケーションをテストして問題が修復されたかどうかを判定するテストを実施することができる。実行挙動マネージャ３０は、テストケース２０の間に実行された実行挙動を記憶または記録することができる。このようにして、実行挙動マネージャ３０は、呼びだされると以前に実行したのと全く同様にテストケース２０を再実行する（ｒｅｐｌａｙ）ことができる。テストケースの実行の結果として障害が発生し、問題を修復するために変更が行われた場合、試験者は、回帰テストを実施して問題が解決したたことが保証されることを望むことがある。問題が解決したことを保証するため、障害が発生したテストケース実行中に実行挙動マネージャ３０によって送られた同一の子「ｄｏ  ｉｔ」挙動を使用してテストケース２０の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１を実行する必要がある。したがって実行挙動マネージャ３０は、以前のテストケース実行中に実行のために送った各「ｄｏ  ｉｔ」挙動を記録することができ、「ｄｏ  ｉｔ」挙動を実行した順序も記録することができる。
【００６１】
さらに、実行挙動マネージャ３０は、複数のクライアントマシン上で動作する複数のテストケースで正しく機能することに留意されたい。例えば、アプリケーションをテストする際に、ある時点で、アプリケーションに関する５０００個のテストケースを２０台のコンピュータに各々実行させることができる。本発明の一実施形態において、テストケースを実行中のすべてのクライアントマシンと１つの実行挙動マネージャとが通信することができる。代替の実施形態において、各クライアントマシンは実行挙動マネージャ３０を備えることができる。
【００６２】
図４に、本発明の一実施形態によるテストケースからの実行挙動の抽出を用いたテストケース実施のための方法２５０のフローチャートを示す。ステップ２５１では、テストケース２０の「ｃｈｏｏｓｅ  ａｎｙ」挙動２１が実行挙動マネージャ３０に通知することができる。実行挙動マネージャは、子実行挙動、「ｄｏ  ｉｔ」挙動を選択し、子実行挙動を「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に送るように要求される。ステップ２５２では実行挙動マネージャ３０は、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１の子挙動を検討することができる。ステップ２５３では、実行挙動マネージャ３０は、子挙動を選択し、選択した子挙動を実行のために親「ｃｈｏｏｓｅ  ａｎｙ」挙動に送ることができる。
【００６３】
図５Ａ〜５Ｂに、本発明の代替の実施形態によるテストケースからの実行挙動の抽出を用いたテストケース実施のための方法３００のフローチャートを示す。方法３００は、ステップ３０５でテストケース開始イベントから開始することができる。開始イベントは、試験者が図２のテスト実行プログラム５０ａなどのクライアントコンピュータ上のボタンの押下とすることができ、これによりテスト実行プログラム５０ａにテストケース２０を実行するように知らせることができる。あるいは開始イベントは、例えば、テストケース２０または複数のテストケースを実行するテスト実行プログラム５０ａ〜ｃなどの１つまたは複数のクライアントコンピュータを管理する実験自動化プロセスを実行することができる。実験自動化プロジェクトは実行挙動マネージャ３０を作成または初期化することもでき、その結果、実行挙動マネージャ３０はテストケース２０または複数のテストケースからの要求に対して動作するよう準備をしておくことができる。
【００６４】
開始イベントの後、ステップ３１０でテストケース２０を実行することができる。テストケース２０は、例えばグラフィックスアプリケーションを対象とすることができ、例えば新しい文書を開くステップと、新しい文書上に矩形を描画するステップと、矩形に青色を塗るステップとを含むことができる。テストケース２０の各ステップ（すなわち、新しい文書を開くステップ、矩形を描画するステップ、矩形に青色を塗るステップ）に適用される方法３００は同一である。ステップ３１５では、テストケースのステップを実行する。
【００６５】
テストケース２０のステップが「ｄｏ  ｉｔ」挙動２２である場合、テストケース２０は、ステップ３２０で、実行挙動マネージャ３０を使用することなく実行挙動を実行する。ステップが例えば「ｃｈｏｏｓｅ  ａｎｙ」挙動２１である場合、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１が、ステップ３２５で、実行のために子「ｄｏ  ｉｔ」挙動を選択するように実行挙動マネージャ３０に要求することができる。例えば、新しい文書を作成するテストケース２０のステップは、一方がメニューを起動するためにマウスを使用して新しい文書を作成し、他方がメニューを起動するためにキーボードを使用して新しい文書を作成する２つの子「ｄｏ  ｉｔ」挙動を有する「ｃｈｏｏｓｅ  ａｎｙ」挙動とすることができる。
【００６６】
ステップ３３０では、実行挙動マネージャ３０は、その挙動のレジスタ３１上で「ｃｈｏｏｓｅ  ａｎｙ」挙動を探索することができる。代替の実施形態において、実行挙動マネージャ３１は、実行挙動の属性またはプロパティを調べることによって「ｃｈｏｏｓｅ  ａｎｙ」挙動２１の子挙動を決定することができる。
【００６７】
次に実行挙動マネージャ３０は、ステップ３３５〜３５０で、実行のためにどの子挙動を「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に送るべきかを判定する。実行挙動マネージャは、その判定を行う際にいくつかの因子を考慮することができる。実行挙動マネージャは、ステップ３３５で、子挙動のいずれかを使用可能にすべきでないかどうかを判定することができる。すなわち、テストケースのステップが、「ｃｈｏｏｓｅ  ａｎｙ」挙動の子挙動のうちの１つを実行中に「ｃｈｏｏｓｅ  ａｎｙ」挙動を満たすことができないものである場合、実行挙動マネージャは、子挙動を使用可能にすべきでないと判定することができる。上述のように、そのような状況の一例は、５つの子「ｄｏ  ｉｔ」挙動を含む矩形を描画するための「ｃｈｏｏｓｅ  ａｎｙ」挙動２１である。子「ｄｏ  ｉｔ」挙動の１つは、マウスを用いてフリーハンドで矩形を描画するためのものとすることができる。テストケース２０が厳密な寸法の矩形を描画することを必要とする場合、子実行挙動が厳密な寸法の矩形を描画するようには設計されないと実行挙動マネージャ３０が判定するときは、フリーハンドで矩形を描画する子「ｄｏ  ｉｔ」挙動は使用不能にすることができる。
【００６８】
次に、ステップ３４０では、実行挙動マネージャ３０は、テストケース２０またはその他の何らかの機構が子「ｄｏ  ｉｔ」挙動の選択に対して局所的重み付けを課しているかどうかを判定することができる。局所的重み付けがなされている場合、実行挙動マネージャはその重み付けを適用することができる。ステップ３４５では、実行挙動マネージャ３０は、子挙動を選択する前に何らかの全体的重み付けを適用すべきかどうかを判定することができる。局所的重み付けおよび全体的重み付けが実行挙動の同じプロパティに当てはまる場合、実行挙動マネージャ３０は、子挙動を選択する際に両方の重み付けを考慮することができる。例えば、全体的重み付けは、時間の２０％でマウスの使用を要求することができる。同時に、局所的重み付けは時間の５０％でマウスの使用を要求することができる。実行挙動マネージャ３０は、子挙動を選ぶ際にこれらの重み付けを組み合わせることができ、またはどちらも考慮することができる。さらに、全体的重み付けおよび局所的重み付けは直交することができることを理解されたい。すなわち、全体的重み付けは、マウスを使用しないように要求することができ、局所的重み付けは、キーボードを使用しないように要求することができる。実行挙動マネージャ３０は、子挙動を選ぶときに直交重み付けを考慮に入れることができる。
【００６９】
適切な重み付けを適用した後、または適用可能な全体的重み付けが存在しない場合、実行挙動マネージャは、ステップ３５０で子挙動を選択することができる。この選択は、以前の選択に基づいて行うことができる。例えば、以前に選択した子挙動が、メニューを起動するマウスを用いて新しいファイルを開くためのものであった場合、実行挙動マネージャ３０は、メニューを起動するキーボードを用いて新しいファイルを開くための異なる子挙動を選ぶことができる。このようにして、実行挙動マネージャ３０は、実行挙動を各テストケースとして書くことなく、すべての実行挙動のテストを実現することができる。さらに、テストケースは、新しいファイルを開くのにどの実行方法が使用されたかさえも知らないことがあり、知っているのは新しいファイルが開かれたことだけといった場合がある。
【００７０】
しかし、全体的重み付けが実行挙動マネージャ３０の子挙動の選択に課される場合、実行挙動マネージャ３０は、適切な子挙動の選択で重み付けを適用することができる。例えば、全体的重み付けによりマウスを使用する実行挙動を時間の８０％で選択すべきであり、キーボードを使用する実行挙動を時間の２０％で選択すべきであるとされる場合、実行挙動マネージャ３０は、この全体的重み付けに準拠して選択を行うべきである。
【００７１】
ステップ３５０でどの子挙動を選択すべきであるかを決定した後、実行挙動マネージャ３０は、ステップ３５５で挙動自動化ライブラリ４０を調べ、選択した子挙動が以前に作成されているかどうかを判定する。あるいは、実行挙動マネージャ３０は、コンパイルしたときに子挙動を作成することができる関数ポインタを求めて挙動自動化ライブラリ４０を調べる。子実行挙動が作成されていない場合、または関数ポインタが存在しない場合、ステップ３６０で、実行挙動マネージャは、選択した子実行挙動を作成することができる。例えば、ステップ３５０で、実行挙動マネージャがマウスを使用してメニューを起動して新しい文書を開く子挙動を選択し、ステップ３５５で、マウスを使用してメニューを起動して新しい文書を開く子実行挙動が存在しないと実行挙動マネージャが判定した場合、ステップ３６０で、実行挙動マネージャ３０は子挙動を作成することができる。上述のように、実行挙動マネージャ３０は、実行挙動のプロファイルまたは属性を使用し、挙動自動化ライブラリに格納されたコードをインスタンス化することによって「ｄｏ  ｉｔ」実行挙動を作成することができる。ステップ３５５で、子挙動が存在すると実行挙動マネージャ３０が判定した場合、実行挙動マネージャはステップ３６０をスキップすることができる。あるいは、ステップ３５５は不要な場合があることを理解されたい。外部データストアからレジスタ３１にデータを追加した場合、ステップ３５５が必要である。しかし、テストケース実行の前またはテストケース実行中に動的にレジスタ３１にデータを追加した場合、実行挙動マネージャ３０は、レジスタ３１が存在しなかった挙動を含まないと仮定することができる。
【００７２】
既存の子挙動または新たに作成した子挙動を選択した後、次に実行挙動マネージャ３０は、ステップ３６５で子挙動の選択を記録することができる。上述のように、このようにして、必要なら、実行挙動マネージャ３０は、以前に実行したのと全く同様にテストケース２０を再実行することができる。これは、アプリケーションをテストしてバグが除去されたかどうかを判定するときに重要である。
【００７３】
ステップ３７０では、実行挙動マネージャは、選択した子「ｄｏ  ｉｔ」挙動をテストケース２０の親「ｃｈｏｏｓｅ  ａｎｙ」挙動２１に送り戻して実行させることができる。ステップ３７５では、「ｃｈｏｏｓｅ  ａｎｙ」挙動２１またはテストケース２０は、実行挙動マネージャ３０によって送られた挙動を実行することができる。さらに、テストケース２０の残りのステップも方法３００のステップ３１５〜３７５で示したのと同様に実行することができる。
【００７４】
本明細書に記載の様々な技法をハードウェアまたはソフトウェア、あるいは適切ならば両者の組合せと共に実装することができる。したがって、本発明の方法および装置、またはその何らかの態様または部分は、フロッピィディスケット、ＣＤ−ＲＯＭ、ハードドライブ、またはその他の任意の機械読取可能な記憶媒体などの有形媒体として具体化されたプログラムコード（すなわち命令）の形を取ることができ、プログラムコードがコンピュータなどのマシンにロードされて実行されたとき、そのマシンが本発明を実施する装置になる。プログラム可能コンピュータ上でプログラムコードを実行する場合、コンピューティング装置は一般に、プロセッサ、プロセッサによって読取り可能な記憶媒体（揮発性および不揮発性メモリおよび／または記憶素子を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。本発明のドメイン特有のプログラミングモデル態様の作成および／または実装を使用することのできる１つまたは複数のプログラムは、例えばデータ処理ＡＰＩなどを使用することにより、コンピュータシステムと通信するように高レベル手続き型またはオブジェクト指向プログラミング言語で実装することが望ましい。しかし、望むならアセンブリ言語または機械語でプログラムを実装することもできる。いずれの場合も、言語はコンパイル型言語またはインタプリタ型言語でよく、ハードウェア実装と組み合わせることができる。
【００７５】
様々な図の好ましい実施形態と共に本発明の実施形態を説明したが、他の実施形態も使用することができ、あるいは本発明から逸脱することなく本発明と同じ機能を実行するために記載の実施形態に修正や追加を行うことができることを理解されたい。明細書全体を通して、青色の矩形を描画することを扱う主な例を与えた。この例およびその他のどんな例も理解を高めるために与えたものである。本発明は本明細書で与えた例に決して限定されない。さらに、本発明の一実施形態をプロセス、マシン、製造、物質の組成、プログラム、ソフトウェア、ハードウェア、装置、機構、材料、またはそれらの任意の改良に関係する任意のアプリケーションを含む任意のテストに含めることができる。したがって、本発明をどんな単一の実施形態にも限定すべきではなく、特許請求の範囲による広さおよび範囲で理解すべきである。
【図面の簡単な説明】
【００７６】
【図１】テストケースからの実行挙動抽出を用いたテストケース実施の諸態様を実施することのできる例示的コンピューティング環境を示すブロック図である。
【図２】実行挙動抽出を用いたテストケース実施のためのシステムの例示的実施形態のブロック図である。
【図３】例示的実行挙動のブロック図である。
【図４】テストケースからの実行挙動抽出を用いたテストケース実施のための方法のフローチャートである。
【図５Ａ】テストケースからの実行挙動抽出を用いたテストケース実施のための代替方法のフローチャートである。
【図５Ｂ】テストケースからの実行挙動抽出を用いたテストケース実施のための代替方法のフローチャートである。
【符号の説明】
【００７７】
１００  コンピュータ
１２０  処理装置
１２１  システムバス
１３０  システムメモリ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１４０  固定、不揮発性メモリインターフェース
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  他のプログラムモジュール
１４７  プログラムデータ
１５０  取り外し可能、不揮発性メモリインターフェース
１６０  ユーザ入力インターフェース
１６１  マウス
１６２  キーボード
１７０  ネットワークインターフェース
１７１  ローカルエリアネットワーク
１７２  モデム
１７３  広域ネットワーク
１８０  リモートコンピュータ
１８５  リモートアプリケーションプログラム
１９０  ビデオインターフェース
１９１  モニタ
１９５  出力周辺インターフェース
１９６  プリンタ
１９７  スピーカ
【図１】
2006099743.tif 000003
【図２】
2006099743.tif 000004
【図３】
2006099743.tif 000005
【図４】
2006099743.tif 000006
【図５Ａ】
2006099743.tif 000007
【図５Ｂ】
2006099743.tif 000008