(57)【要約】【課題】  ソフトウェア製品のライフサイクルにおいてできるだけ早く、理想的には設計フェーズにテストケースを作成し、自動テストを使用するやり方を提供すること。【解決手段】  自動テストの側面を複数のアーキテクチャ層に分離することによって、自動テストがよりすぐに、より速く行われ、またより包括的なテストを提供することを可能にする。物理層は、アプリケーションのユーザインターフェースについてのオブジェクトモデルを提供する。論理層は、アプリケーションの機能に関するオブジェクトモデルを提供する。テストケースエグゼキュータは、テストケースを実行し得る。データマネージャは、テストケースデータの可変性を保証し得る。振舞いマネージャは、特定のテストケースに適した実行詳細を決定し得る。検証マネージャは、テストケースが実行された後に、検証処理を実施する。【選択図】  図３
2006099737.tif 000002
【特許請求の範囲】
【請求項１】
アーキテクチャテスト自動化スタックを含む自動テストシステムであって、該アーキテクチャテスト自動化スタックは、
テストされるアプリケーションの１組のユーザアクションに関連付けられ、物理層の１組のオブジェクトへの直接アクセスを有する、論理層を含む１組のオブジェクトと、
前記１組のユーザ動作に関連する実行オプションを対象とする１組のオブジェクトを含む、前記物理層の１組のオブジェクトと
を含むことを特徴とする自動テストシステム。
【請求項２】
前記論理層の前記１組のオブジェクト内のオブジェクトを参照するテストケースをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記物理層の前記１組のオブジェクト内のオブジェクトを参照しないテストケースをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項４】
前記テストケースは検証コードを含まないことを特徴とする請求項２に記載のシステム。
【請求項５】
前記テストケースは実行オプションを含まないことを特徴とする請求項２に記載のシステム。
【請求項６】
前記テストケースは、前記テスト自動化スタックのテストケース層内に常駐することを特徴とする請求項２に記載のシステム。
【請求項７】
テストケースによって必要とされる可変のテストデータを提供するデータマネージャをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項８】
テストデータ選択に関連するオブジェクトは、前記テスト自動化スタックではなく、第２の論理層内に格納されることを特徴とする請求項１に記載のシステム。
【請求項９】
テストケースの実行オプションを選択する振舞いマネージャをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項１０】
テストされる前記アプリケーションの前記１組のユーザ動作のうちのユーザ動作の実行パスに関連するオブジェクトは、自動化スタックではなく、実行振舞い論理層内に格納されることを特徴とする請求項１に記載のシステム。
【請求項１１】
テストされる前記アプリケーションの前記１組のユーザ動作のうちのユーザ動作の実行パスに関連するオブジェクトは、前記自動化スタック内の前記論理層内に格納されることを特徴とする請求項１に記載のシステム。
【請求項１２】
テストケースの実行結果を決定する検証マネージャをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項１３】
テスト結果の検証に関連するオブジェクトは、前記自動化スタック内ではなく、検証層内に格納されることを特徴とする請求項１に記載のシステム。
【請求項１４】
テスト結果の検証に関連するオブジェクトは、前記自動化スタックの前記論理層内に格納されることを特徴とする請求項１に記載のシステム。
【請求項１５】
前記検証マネージャは、前記テストケースの実際の実行結果を前記テストケースの期待された実行結果と比較することを特徴とする請求項１２に記載のシステム。
【請求項１６】
テストケース作成および保守の効率をもたらすための方法であって、
少なくとも１つのステートメントを含むテストケースを受信するステップであって、前記少なくとも１つのステートメントは、ユーザ動作に関連する、複数階層化ライブラリの論理層内のオブジェクトを参照するステップと、
前記ユーザ動作に関連する振舞いを選択するステップであって、前記振舞いは、前記ユーザ動作の特定の実行パスに関連するステップと
選択された前記特定の実行パスを使用して前記テストケースを実行するステップであって、前記特定の実行パスは、前記複数階層化ライブラリの物理層内のオブジェクトを参照するステップと
を含むことを特徴とする方法。
【請求項１７】
前記テストケースが実行されることの通知を送信するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記テストケースの実行によってもたらされる、テスト前の期待される状態を保存するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記テストケースの実行によってもたらされる、テスト前の前記期待される状態を、前記テストケースの実行によってもたらされる、テスト後の実際の状態と比較するステップをさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
テスト結果の検証に関連するオブジェクトは、実行オプションに関連するオブジェクトから分離されることを特徴とする請求項１６に記載の方法。
【請求項２１】
コンピュータ実行可能命令を含むコンピュータ読取り可能媒体であって、
少なくとも１つのステートメントを含むテストケースを受信することであって、そこでは、前記少なくとも１つのステートメントは、ユーザ動作に関連する、複数階層化ライブラリの論理層内のオブジェクトを参照すること、
前記テストケースが実行されることの通知を送信すること、
前記ユーザ動作に関連する振舞いを選択することであって、前記振舞いは、前記ユーザ動作の特定の実行パスに関連すること、
前記選択された特定の実行パスを使用して前記テストケースを実行することであって、前記特定の実行パスは、前記複数階層化ライブラリ内の物理層内のオブジェクトを参照すること、および
テスト前の期待される状態を、テスト後の実際の結果と比較すること
のためのコンピュータ実行可能命令を含むことを特徴とするコンピュータ読取り可能媒体。
【請求項２２】
前記テストケースの実行によってもたらされる、テスト前の期待される状態を保存するための命令をさらに含むことを特徴とする請求項２１に記載のコンピュータ読取り可能媒体。
【請求項２３】
前記テストケースの実行によってもたらされる、テスト前の前記期待される状態を、前記テストケースの実行によってもたらされる、テスト後の実施の状態と比較するための命令をさらに含むことを特徴とする請求項２２に記載のコンピュータ読取り可能媒体。
【請求項２４】
前記テストケースを構文解析するための命令をさらに含むことを特徴とする請求項２１に記載のコンピュータ読取り可能媒体。
【請求項２５】
前記テストケースが実行されたことの通知を送信するための命令をさらに含むことを特徴とする請求項２１に記載のコンピュータ実行可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアのテストに関し、より詳細には、階層化アーキテクチャを使用した自動ソフトウェアテストに関する。
【背景技術】
【０００２】
ソフトウェア開発のライフサイクルにおける主な段階は、設計フェーズ、コーディングフェーズ、コード完成フェーズ、アルファフェーズ、ベータフェーズ、および最後に市場リリースである。設計フェーズでは、ソフトウェア製品が対処する顧客問題、およびソフトウェア製品の機能が定義される。一般に、機能仕様の完成は、設計フェーズの終了を表す。コーディングフェーズは、既に開始していることがある。コード完成フェーズは、コードが作成されているが、必ずしもデバッグされていない場合に達せられる。アルファフェーズは、製品が安定している、すなわち主要なバグが発見された時点を表す。ベータフェーズでは、製品は理想的には、すべての主要なバグが除かれており、唯一残っているバグは、基本的に無害であるべきである。製品は、最終的な品質保証チェックリストに合格する場合には、市場リリースの準備が整っている。
【０００３】
機能しないソフトウェアを誰も望んでいないので、テストは、ライフサイクルの重要な一環であり、いくつかのフェーズに渡り得る。ソフトウェアテストは、テストケースを考案し（１組のテストケースを考案する可能性がより高い）、入力としてのテストケースによってソフトウェアを実行し、入力としてのテストケースによるソフトウェアパフォーマンスが、期待された結果をもたらすことをチェックすることを伴う。ソフトウェアテストは、人間によって手作業で行われることも、自動ソフトウェアテストと称される、プログラムによって実施されることもある。理想的には、ソフトウェアのテストは、ソフトウェアのライフサイクルにおいて、できるだけ早く開始すべきである。しかし、一般にソフトウェアは、設計フェーズが完了するまで期待される結果が決定され得ないので、設計フェーズが完了するまでまったくテストされることができない。一般にコーディングフェーズでは、開発者は、それを作成するときにそのコードを手作業でテストする。自動ソフトウェアテストは通常、開発プロセスのずっと後になってようやく開始され得る。
【０００４】
実施される唯一のテストは時々、手作業でテストする開発者によって、それがコーディングするときに行われる。しかし、それ自身の仕事をテストする開発者は、そのコードに感情的にそれほど入れ込んでいない誰かが見つけるバグを見落とす可能性が高い。さらに、開発者によるテストの範囲は一般に、そのコードの機能、およびそのコードを制限された数の他のソフトウェアアプリケーションと統合することに制限される。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
こうした欠点に対処するために、多くのソフトウェア開発会社は、少なくとも部分的に自動化されたテスト技術をしばしば使用してソフトウェアを同様にテストする別個のソフトウェアテストグループを有する。一般にテストグループは、テストケースを作成し実行することによって、複数の特徴に渡り、また複数のアプリケーションに渡る複雑な対話をテストする。製品ライフサイクルの初期に、さらには早くも設計フェーズでテストグループを含むと、機能仕様の矛盾の識別、テストし難い領域の識別などを含めて、多くの利益が得られることは大体同意されている。しかし一般に、特徴定義、実装、およびユーザインターフェース（ＵＩ：ｕｓｅｒ  ｉｎｔｅｒｆａｃｅ）調整の継続した変更にもかかわらず各テストケースを最新に保つのに必要とされる労力が、この手法を非実用的にする。したがって、テストケースの作成および実行は一般に、製品開発の最後に行われる大急ぎの事柄である。したがって、テスト、具体的には自動テストは、常に遅れている傾向にある。ソフトウェア製品のライフサイクルにおいてできるだけ早く、理想的には設計フェーズにテストケースを作成し、自動テストを使用するやり方があれば有用である。
【０００６】
テストケーススイートの開発は、それがいつ行われようとも難題である。アプリケーションの特定の特徴をテストするために、複数のテストセットが作成されなければならない。例えば、あるアプリケーションは、マウス、キーボード、デジタイザ、アクセシビリティソフトウェアを介して、プログラムによってなど、特徴との多数の対話モードを可能にし得る。したがって、特徴についての包括的なテストを提供するために、テストスイートは、マウスを介して特徴と対話する（ユーザが行い得るようにテキストを入力する）１組のテスト、キーボードを介して特徴と対話する１組、デジタイザ介して特徴と対話する１組、既定の動作を呼び出し、またその他にアクセシビリティアプリケーションを模倣するためにアクセシビリティソフトウェアを介して特徴と対話する１組、アプリケーションのコーディングモデルを介して特徴と対話する１組などを含むべきである。作成されたテストケーススイートがアプリケーションまたは特徴の包括的なテストをもたらして、さらに、その包括テストを提供するために作成されなければならないテストケースの総数を減少させるようにするやり方があれば有用である。
【０００７】
さらに、こうしたテストセットのそれぞれの論理の多くまたはすべては、他のテストセットの論理と同一であり、また一般に、結果検証の処理も同様に同一である。したがって、多くのテストは同一であり、また非常にそれに近く、実行オプションが異なっているにすぎない。例えば、上述の複数の入力形態のすべてについて、期待される結果は同一である可能性が高い。したがって、こうした入力ソースのそれぞれについてテストケースを作成することは一般に、入力ソースのそれぞれについてテストを実行するための別個の方法を作成し、テストスクリプトの残りのほとんどを複製することを必要とする。小さい違いを伴う同じテストを繰り返し作成することは、退屈で時間がかかることである。こうした繰返しのコーディングを取り除き、または大幅に減少させ、また作成されなければならないテストケースの総数を減らすやり方があれば有用である。
【０００８】
テストケース実行の実際の結果が、期待される結果と一致するかどうか判定する（結果の検証、または検証と称される）ために作成されるコードは、テストケース内にしばしば含められる。特定の結果検証の詳細を変更し、または新しい結果検証を追加するには、それぞれのテストケースの修正が一般に必要である。検証コードがテストケースから分離され、テストケースがさらに理解しやすく、また検証コードの再利用および維持がより容易になれば、有用である。
【０００９】
実行の詳細は、テストケース内にしばしばハードコーディングされ、テスト作成の前に設計フェーズが完了していることを必要とする。テストケースがソフトウェア開発ライフサイクルのより早期に作成されるように、特定の実行詳細に関してではなく、ユーザ動作に関してテストケースを定義するやり方があれば有用である。
【００１０】
テストケースが作成された後に実行詳細および検証への変更を行うには、多くのテストケースが発見され、修正されなければならない多大な保守労力を一般に必要とする。修正が各テストケースにおいてではなく、一箇所で行われるように、保守労力が局所化されれば有用である。
【課題を解決するための手段】
【００１１】
自動化スタックを使用した自動テストシステムによって、テストケースが早くもソフトウェア開発の設計フェーズに作成され、コンパイルされることが可能になり得る。テストケースは、テストされる特徴を実装するコードが作成されるとすぐに実行され得る。
【００１２】
自動テストシステムは、テストケースエクゼキュータ、データマネージャ、振舞いマネージャおよび振舞いデータバンク、検証マネージャ、ならびに自動化スタックのうちの１つまたは複数を含み得る。テストケースエクゼキュータは、テストケースを実行し得る。データマネージャは、データのテストにおける可変性を保証し得る。振舞いマネージャは、特定のテストケースに適した実行詳細を決定し得る。検証マネージャは、テストケースが実行された後に、検証処理を実施することができる。自動化スタックは、テストケース実行の詳細を複数の層またはオブジェクトセットに分離することを可能にするアーキテクチャを提供し得る。自動化スタックは論理層および物理層を含むことができ、テストケース層は、論理層の上に構築され得る。テストケースは、特定の実行詳細／ユーザインターフェース詳細に関してではなく、特徴またはユーザ動作に関して定義されることができ、したがって、テストケースをソフトウェア開発ライフサイクルのより早期に作成することを可能にし、また実行詳細およびユーザインターフェース詳細への変更を、テストケース詳細から切り離し、分離することを可能にする。
【００１３】
テストケース実行およびテストケース検証は、実行振舞い層および検証層への分離によって切り離され得る。結果検証の処理は、テストケースから離れることができ、それによって、テストケースをより理解しやすく、また検証コードの再利用を容易にすることができる。保守は、自動化スタック内、あるいは検証層または振舞い層内の単一箇所の変更に局所化することによって、簡略化されることができ、したがって、テストケースが基本的に保守を伴わないことを可能にする。
【００１４】
テストケース内の様々なステップがどのように実行されるかについての各詳細をそれ自体の層またはオブジェクトセットに分離することによって、こうした要素のそれぞれは、独立に変化することができる。それぞれの層は、その下の層に対する可変性を取り入れることができ、それによって、作成されなければならないテストの数を減少させる。例えば、５回実行される、より高い層に対して作成された１つのテストは、より下の層に対して作成された５、１０、さらには５０個のテストと同じ効力を有し得る。層に編成することによって、テスト自体は、より単純に、より容易に理解できるようになり、また１組の実行パスを網羅するために作成されなければならないテストケースの数を減らすことに加えて、テストケースを作成するのに要する時間量を減らすことができる。
【００１５】
論理層は、ユーザインターフェースの特定の詳細（例えば、「ファイルメニューを開き、開くをクリックし、ファイルを開くダイアログボックスが開くのを待ち、開くファイルの名前を入力し、ＯＫを押下し、ファイルを開くダイアログボックスが消えるのを待ち、アプリケーションがドキュメントを開くのを待ち、さらなる入力の準備を整える」など）ではなく、取られ得る動作（例えば「ドキュメントを開く」動作など）に基づいて、アプリケーションのビューを提供し得る。論理層は、ユーザインターフェースが変化する場合に、この層に対して作成されたテストが編集される必要がないように、ユーザインターフェースについての知識をできるだけ抽象化することもできる。論理層は、この層に対して作成された単一のテストが、テストケースへの変更を行わずにマウスやキーボードなどを介して実行され得るように、様々な物理的な実行方法に対する可変性を取り入れることもできる。
【００１６】
物理層は、特定のコントロールの識別コードなどの詳細、およびコントロールがアクセスされるやり方（マウス、キーボード、アクセシビリティ、またはタブレットなどを介する）を含めて、特定のコントロールと対話することについての非常に具体的な詳細から、テストを分離する。物理層は、ユーザインターフェースへの強く型付けされた（ｓｔｒｏｎｇｌｙ  ｔｙｐｅｄ）アクセスをテストが有するように、アプリケーションのユーザインターフェースに関するオブジェクトモデルを提供し得る。物理層は、実行方法の数に関係なく、単一のオブジェクトモデルだけが必要とされるように、実行方法がコントロールとは独立に定義されることを可能にすることもできる。
【００１７】
検証層は、検証詳細の変更によってテストの変更が必要とされないように、テストケースとの直接の接触から独立し、そこから切り離され得る。
【００１８】
実行振舞い層は、どの実行動作が使用可能であるかに対する変更、および任意の特定の振舞いの実装への変更がテストケースへの最小限の変更を伴って、またはそれなしに行われ得るように、テストケースとの直接の接触から独立し、そこから切り離され得る。
【００１９】
データ管理層は、テストケースがテストデータを必要とする場合に、テストケースによって使用され得る。データ管理層は、すべてのテストデータの集中ストアを提供し、またテストケースへの最小限の変更だけを必要とし、または変更を必要とせずに、テストデータ、またはそのテストデータが生成されるやり方に変更を加えることを可能にし得る。
【００２０】
それぞれの層は、それより下の層への（直接）アクセスを提供し得るが、テストケースは、必要に応じて任意の層への呼出しを行い得る。メニューの振舞いを明示的に検証するテストケースは、例えば、論理層を使用して、様々な形状を含む図面を作成し、次いで物理層を使用して、メニューを直接に操作し得る。テストケースは、結果検証のため、物理層まで、オペレーティングシステムサービスまで下へと進み得る。したがって、テストケースは、より高い層の全パワーを使用し、またより低い層によって提供される全コントロールをも使用することができる。
【００２１】
上記要約、および例示的な実施形態についての以下の詳細な説明は、添付の図面と併せ読めばよりよく理解される。本発明を例示するために、図面に本発明の例示的な構成が示されているが、しかし、本発明は、開示する特定の方法および手段に限定されない。
【発明を実施するための最良の形態】
【００２２】
概要
テストケース開発の一課題は、包括的なテストを提供する１組のテストケースを準備することである。テストケースの大部分によって、テスト対象のユーザ動作のほんの一部だけが実行される。これがどうして生じ得るかを理解するために、個々の操作は通常、複数の異なるユーザ動作を介して実行され得ることを考慮されたい。例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ内の新しいドキュメントの作成は、以下によって行われ得る。
【００２３】
ファイルメニューをクリックし、新しいサブメニューをクリックし、次いで新しいドキュメントメニューアイテムをクリックする。
【００２４】
Ａｌｔ＋Ｆを入力して、ファイルメニューを呼び出し、Ｎを入力して、新しいサブメニューを呼び出し、次いでＮを入力して、新しいドキュメントメニューアイテムを呼び出す。
【００２５】
Ａｌｔを入力して、メインメニューを呼び出し、ファイルメニューが選択されるまで左矢印キーを繰り返し押下し、新しいサブメニューアイテムが選択されるまで下矢印キーを繰り返し押下し、左矢印キーを１回だけ押下して、新しいサブメニューを展開し、新しいドキュメントメニューアイテムが選択されるまで下矢印キーを繰り返し押下し、次いで、Ｅｎｔｅｒを押下して、新しいドキュメントメニューアイテムを呼び出す。
アクセシビリティＡＰＩを介して、新しいドキュメントメニューアイテムを呼び出す。
新しいドキュメントツールバーボタンをクリックする。
アクセシビリティＡＰＩを介して、新しいドキュメントツールバーボタンを呼び出す。
Ｃｔｌ＋Ｎを入力する。
新しいドキュメントを作成するスクリプト記述オブジェクトモデルメソッドを実行する。
【００２６】
それぞれが別のコードパスを潜在的に呼び出す、ドキュメントを開くこうした様々なやり方のそれぞれが、テストされるべきである。本発明の一部の実施形態によれば、すべての可能な実行パスおよびデータ値が実行される。
【００２７】
複数の実行パスは一般的であるので、検証処理は、セット内のテストケースのうちの多くで複製されている。検証コードはしばしば、各テストケースにコピーアンドペーストされる。退屈で時間がかかることに加えて、保守問題がそれによってもたらされる。例えば、変更が後に実行または検証処理において行われる場合、影響を受けるテストケースのセット全体が発見され、改訂されなければならない。本発明の一部の実施形態によれば、テストケースの保守は、自動化スタック内の単一箇所に局所化され、保守テストケースがほとんど保守を伴わないことを可能にし得る。
【００２８】
典型的なテストケースでは、テストケースの実行を対象とするコード、および実行の結果を判定することを対象とするコード（検証コード）は、テストケース自体内にハードコーディングされる。実行コードはしばしば、検証コードと混合される。本発明の一部の実施形態では、検証処理、および実行処理の詳細は、互いに、またテストケースから分離される。
【００２９】
テストケースはしばしば、テストがテストしている操作と、それがその動作を呼び出すためにとるステップとの間の区別を行わない。明示的なテストはしばしば、それぞれの実行方法について作成される。例えば、それぞれのテストは、テストされる操作を呼び出すために複製されなければならない、各一連のマウスの動き、ボタンクリックおよびキーストロークについてのコードを含み得る。ＵＩテストに関して、それぞれのテストは、各ＵＩコンポーネントによって使用されるコントロールのタイプについて追跡し、使用される特定のコントロールを識別し、ＵＩ階層内のどこにコントロールが発見され得るかを指定しなければならないことがある。本発明の一部の実施形態によれば、テストケースは、実行詳細に関してではなく、ユーザ動作に関して作成される。したがって、ユーザインターフェースの詳細は、ユーザ動作の詳細から分けられる。
【００３０】
自動テストケースは一般に、テストされている特定のソフトウェアに非常に密接にバインドされ、すなわち典型的なテストケースは、それがテストしているオブジェクトに対して直接にコーディングされる。例えば、テストケースを用いたアプリケーションの自動テストはしばしば、アプリケーションの状態を直接に操作する。ユーザインターフェース（ＵＩ）の自動テストのためのテストケースはしばしば、ＵＩの１つまたは複数のコントロールに対して直接作成され、テストケース内にコントロールの名前または一意の識別子を明示的にコーディングすることによって、コントロールを識別する。コントロールが（例えばボタンからリストボックスに、さらにはあるボタン（ボタン３６など）から別のボタン（ボタン４２など）に）変化する場合、ＵＩについてのすべてのテストケースが変更されなければならない。
【００３１】
こうしたおよび他の問題に対処するために、スクリプト記述されたテストケース、モデルベーステスト、および単体テストから使用可能である複数階層化されたライブラリが作成され得る。ライブラリは、物理層、論理層、検証層、実行振舞い管理層およびデータ管理層のうちの１つまたは複数を含み得る。物理層、論理層およびテストケースは自動化スタックを含むことができ、検証層、実行振舞い管理層およびデータ管理層は、論理層と同じレベルではあるが、分離され得る。
【００３２】
論理層は、ユーザインターフェースの特定の詳細（例えば、「ファイルメニューを開き、開くをクリックし、ファイルを開くダイアログボックスが開くのを待ち、開くファイルの名前を入力し、ＯＫを押下し、ファイルを開くダイアログボックスが消えるのを待ち、アプリケーションがドキュメントを開くのを待ち、さらなる入力の準備が整える」など）ではなく、取られ得る動作（例えば「ドキュメントを開く」動作など）に基づいて、アプリケーションのビューを提供し得る。また論理層は、ユーザインターフェースが変化する場合に、論理層に対して作成されたテストが編集される必要がないように、ＵＩについての知識をできるだけ抽象化する。論理層は、論理層に対して作成された単一のテストが、テストケースへの変更を必要とせずにマウスやキーボードなどを介して実行され得るように、様々な物理的な実行方法に対する可変性を取り入れることもできる。
【００３３】
物理層は、特定のコントロールの識別コードが何か、およびコントロールがどのようにアクセスされるか（マウス、キーボード他を介して）などの詳細を含めて、特定のコントロールと対話することについての非常に具体的な詳細から、テストケースを分離し得る。物理層は、そのＵＩへの強く型付けされたアクセスをテストが有するように、アプリケーションのＵＩに関するオブジェクトモデルを提供し得る。物理層は、実行方法の数に関係なく、単一のオブジェクトモデルだけが必要とされるように、実行方法がコントロールとは独立に定義されることを可能にすることもできる。
【００３４】
検証層は、検証処理へ変更によってテストケースの変更が必要とされないように、テストケースとの直接の接触から独立し、そこから切り離され得る。検証層は、実際の状態を期待される状態と比較して、テストケース結果が期待通りであったかどうか判定し得る。
【００３５】
実行振舞い管理層は、実行動作の使用可能性への変更、または任意の具体的な振舞いの実装への変更がテストケースの最小限の変更を伴って、またはそれなしに行われ得るように、テストケースとの直接の接触から独立し、そこから切り離され得る。実行振舞い層は、テストケースに適用可能な１つまたは複数の適切な動作を選択し得る。実行振舞い層は、すべての可能な実行パスが実行されるようにし得る。
【００３６】
データ管理層は、テストケースがテストデータを必要とする場合に、テストケースによって使用され得る。データ管理システムは、すべてのテストデータの集中ストアを提供し、またテストケースへの最小限の変更だけを必要とし、または変更を必要とせずに、テストデータ、またはそのデータが生成されるやり方に変更を加えることを可能にし得る。データ管理層はすべての可能なデータ値が使用されることを保証することができる。
【００３７】
それぞれの層は、それより下の層への（直接）アクセスを提供するが、テストケースは、必要に応じて任意の層への呼出しを行い得る。メニューの振舞いを明示的に検証するテストケースは、例えば、論理層を使用して、様々な形状を含む図面を作成し、また物理層を使用して、メニューを直接に操作し、結果検証のため、オペレーティングシステムサービスに進み得る。実行方法の詳細は、隠され得る。論理層に対して作成されるテストは、実行方法が切り換わる場合に、変更を不要とし得る。テストケースが実行方法から完全に切り離される場合は、テストケースの外部にある、それとは別個の機構をコンパイル時または実行時に使用して、テストの具体的な実行についてどの実行方法が使用されるべきかを指定することができる。
【００３８】
例示的なコンピューティング環境
図１および以下の議論は、本発明が実施され得る適切なコンピューティング環境についての簡潔で一般的な説明を提供することを意図している。しかし、ハンドヘルド、ポータブル、およびすべての種類の他のコンピューティング装置が、本発明に関連して使用されるように企図されていることを理解されたい。汎用コンピュータについて以下で説明するが、これは一例にすぎず、本発明は、ネットワークサーバの相互運用性および相互作用性を有するシンクライアントだけを必要とする。したがって、本発明は、非常に少ないまたは最小限のクライアントリソースが関与するネットワークホストサービスの環境、例えばクライアント装置が単にブラウザ、またはワールドワイドウェブとのインターフェースとして働くネットワーク環境内で実施され得る。
【００３９】
必須ではないが、本発明は、開発者によって使用するために、アプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）を介して実施され、および／またはネットワークブラウズソフトウェア内に含められることができ、このネットワークブラウズソフトウェアは、クライアントワークステーション、サーバ、または他の装置などの１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明される。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。一般に、プログラムモジュールの機能は、様々な実施形態で望まれるように組み合わせることも、分散されることもできる。さらに、本発明は、他のコンピュータシステム構成で実施され得ることが当業者には理解されよう。本発明での使用に適し得る他の周知のコンピューティングシステム、環境および／または構成には、それだけに限らないが、パーソナルコンピュータ（ＰＣ：ｐｅｒｓｏｎａｌ  ｃｏｍｐｕｔｅｒ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブルな家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明は、通信ネットワークまたは他のデータ伝送媒体を介してリンクされたリモート処理装置によってタスクが実施される分散コンピューティング環境で実施されることもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含めて、ローカルとリモートの両方のコンピュータ記憶媒体内に配置され得る。
【００４０】
したがって、図１に、本発明が実施され得る適切なコンピューティングシステム環境１００の一例を示すが、上記で明らかにしたように、コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する制限を示唆することを意図していない。コンピューティング環境１００は、例示的なオペレーティング環境１００内に示した構成要素のいずれか１つまたはその組合せに関するいずれかの依存関係または要件を有していると解釈すべきでない。
【００４１】
図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形の汎用コンピューティング装置を含んでいる。コンピュータ１１０の構成要素は、それだけに限らないが、処理装置１２０、システムメモリ１３０、およびシステムメモリ１３０を含めて様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１を含み得る。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを用いたローカルバスを含めて、複数タイプのバス構造のいずれかであり得る。限定するためではなく、例を挙げると、こうしたアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロチャネルアーキテクチャー（ＭＣＡ：Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ：Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、および周辺コンポーネント相互接続（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス（メザニンバスとも呼ばれる）が含まれる。
【００４２】
コンピュータ１１０は一般に、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１１０からアクセスすることができ、また揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含む任意の使用可能媒体であり得る。限定のためではなく、例を挙げると、コンピュータ読取り可能媒体は、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、または他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含み得る。コンピュータ記憶媒体には、それだけに限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは所望の情報を格納するために使用することができ、またコンピュータ１１０によってアクセスされ得る他の任意の媒体が含まれる。通信媒体は一般に、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、または搬送波や他のトランスポート機構などの変調されたデータ信号内の他のデータを実装し、また任意の情報送達媒体を含む。用語「変調されたデータ信号」は、信号の情報を符号化するなどのやり方でその特性の１つまたは複数が設定されまたは変更された信号を意味する。限定のためではなく、例を挙げると、通信媒体には、有線ネットワークや直接有線接続などの無線媒体、ならびに音響などの無線媒体、ＲＦ、赤外線、および他の無線媒体が含まれる。上記内容のいずれかの組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。
【００４３】
システムメモリ１３０は、読出し専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）１３１およびランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）１３３は一般に、ＲＯＭ１３１に格納される。ＲＡＭ１３２は一般に、処理装置１２０によってすぐにアクセス可能であり、および／またはそれによる操作を現在受けているデータおよび／またはプログラムモジュールを含む。限定のためではなく、例示するために、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を示す。
【００４４】
コンピュータ１１０は、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体をも含み得る。例示するためにだけに、図１に、取外し不可能な不揮発性の磁気媒体から読み出しまたはそこに書き込むハードディスクドライブ１４１、取外し可能な不揮発性の磁気ディスク１５２から読み出しまたはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体などの取外し可能な不揮発性の光ディスク１５６から読み出しまたはそこに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境内で使用され得る他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体には、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は一般に、インターフェース１４０などの取外し不可能なメモリインターフェースによってシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェース１５０などの取外し可能なメモリインターフェースによってシステムバス１２１に接続される。
【００４５】
上記で説明し、図１に示したディスクドライブおよびその関連のコンピュータ記憶媒体によって、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、およびコンピュータ１１０のための他のデータの記憶域がもたらされる。図１に、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を格納するように示されている。こうした構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであることも、それとは異なることもあることに留意されたい。少なくともそれらがそれぞれ異なるコピーであることを示すために、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７に異なる番号が付与されている。ユーザは、キーボード１６２、および一般にマウス、トラックボールまたはタッチパッドと称されるポインティング装置１６１などの入力装置を用いて、コンピュータ１１０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）は、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナなどを含み得る。これらのおよび他の入力装置はしばしば、システムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）など、他のインターフェースおよびバス構造によって接続されることもできる。
【００４６】
モニタ１９１または他のタイプの表示装置もまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。ノースブリッジなどのグラフィックスインターフェース１８２もまた、システムバス１２１に接続され得る。ノースブリッジは、ＣＰＵすなわちホスト処理装置１２０と通信するチップセットであり、アクセラレイテッドグラフィックスポート（ＡＧＰ：ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）通信の役割を担う。１つまたは複数のグラフィックス処理装置（ＧＰＵ：ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）１８４は、グラフィックスインターフェース１８２と通信し得る。この点について、ＧＰＵ１８４は一般にレジスタ記憶装置などのオンチップメモリ記憶装置を含み、またＧＰＵ１８４は、ビデオメモリ１８６と通信する。しかし、ＧＰＵ１８４はコプロセッサの一例にすぎず、したがって、様々なコプロセッシング装置が、コンピュータ１１０内に含まれ得る。モニタ１９１または他のタイプの表示装置もまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続され、このインターフェースは、ビデオメモリ１８６と通信し得る。コンピュータは、モニタ１９１に加えて、出力周辺インターフェース１９５を介して接続され得るスピーカ１９７およびプリンタ１９６などの他の周辺出力装置をも含み得る。
【００４７】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、また図１にはメモリ記憶装置１８１だけが示されているが、コンピュータ１１０に関して上述した要素の多くまたはすべてを一般に含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）１７１、および広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）１７３を含むが、他のネットワークをも含み得る。こうしたネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットでは一般的である。
【００４８】
ＬＡＮネットワーキング環境内で使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境内で使用される場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどのＷＡＮ１７３を介して通信を確立する他の手段を含む。内部にあることも、外部にあることもあるモデム１７２は、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続され得る。ネットワーク環境内では、コンピュータ１１０に関して示したプログラムモジュール、またはその一部は、リモートメモリ記憶装置内に格納され得る。限定のためではなく、例示するため、図１に、メモリ装置１８１内に常駐するリモートアプリケーションプログラム１８５を示す。図示するネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段が使用され得ることが理解されよう。
【００４９】
コンピュータ１１０または他のクライアント装置が、ネットワークコンピュータの一部として配置され得ることが当業者には理解されよう。この点に関して、本発明は、任意の数のメモリまたは記憶ユニット、ならびに任意の数の記憶ユニットまたはボリュームに渡って生じる任意の数のアプリケーションおよびプロセスを含む任意のコンピュータシステムに関する。本発明は、リモートまたはローカル記憶装置を含む、ネットワーク環境内に配置されたサーバコンピュータおよびクライアントコンピュータを備えた環境に適用され得る。本発明は、プログラミング言語機能、解釈および実行能力を有するスタンドアロンコンピューティング装置に適用することもできる。
【００５０】
自動化スタック階層化
本発明の一部の実施形態では、アプリケーションは、オブジェクトモデルのビューまたは他のタイプのビューとは異なり、そのアプリケーションのユーザ中心のビューをとる論理機能モデルを介して定義される。繰り返し使用されるコードは、ユーザ中心のやり方でコンポーネント化され得る。動作は、論理層内のターゲットによってグループ化されることができ、ＳｃｅｎｅＥｌｅｍｅｎｔｓは、作成、選択、選択解除、カット、コピー、ペースト、削除要素などの動作シーンに関する１組の要素に影響を及ぼすメソッドを含み得る。メソッドの変換グループは、回転し、スケーリングし、またその他にシーン要素に変換を適用するためのメソッドを含み得る。パスは、パスであるシーン要素を操作するためのメソッドなどを含み得る。ほとんどのアプリケーションにおいて、ユーザ動作のほとんどは、複数の異なるやり方で実行され得る。それぞれ異なる実行パスに必要な基盤は一般に、同一である。したがって、本発明の一部の実施形態では、実行振舞いマネージャは、複数のテストケースに渡って共有され、テストケースに適した振舞い（論理機能モデルメソッド）を選択する。本発明の一部の実施形態では、テストケースまたは論理機能モデルメソッドが操作を実行する前に、検証マネージャは、通知を受ける。検証マネージャは、アプリケーションの完全な現在の状態のコピーを保存し得る。このコピーは、操作が完了する場合の期待される状態の基礎を形成する。本発明の一部の実施形態では、テストケースは、動作がどのように実行されまたは検証されるかについての知識なしに、動作シーケンスを実行する。
【００５１】
図２は、本発明の一実施形態による、階層化アーキテクチャを使用した例示的な自動テストシステムを示すブロック図である。図２の自動テストシステムは、より少ないテストケースを用いてより包括的なテストが行われ得るように、テストケース作成および保守の効率化を可能にし得る。テストケースは、より作成しやすく、より保守しやすく、また理解しやすくなり得る。
【００５２】
自動テストシステム２５０は、図１に関して説明した例示的なコンピュータ１１０などの１つまたは複数のコンピュータ内に常駐し得る。自動テストシステム２５０は、テストエグゼキュータ２５２、データマネージャ２５４、振舞いマネージャ２５６、および関連の振舞いデータバンク（図示せず）、検証マネージャ２６８ならびに自動化スタック２００のうちの１つまたは複数を含み得る。テストエグゼキュータ２５２は、アプリケーション２６２に対してテストケース２６０を実行し得る。本発明の一部の実施形態のデータマネージャ２５２は、テストケース２６０によって必要とされるテストデータを提供し得る。データマネージャは、すべてのテストデータの集中データストアへのアクセスを提供し、またテストケースへの最小限の変更だけを必要とし、または変更を必要とせずに、テストデータ、またはそのテストデータが生成されるやり方に変更を加えることを可能にする。
【００５３】
振舞いマネージャ２５６は、振舞いデータバンクから、テストケース２６０に適した振舞いを選択し得る。検証マネージャ２５８は、テストケース２６０の実行結果の検証を提供し得る。
【００５４】
図３は、本発明の一実施形態による自動テストシステムの自動化スタックの例示的な階層化アーキテクチャを示すブロック図である。図３は、図２のシステムの一部のより詳細なブロック図である。図３で、自動化ライブラリ２００は、１つまたは複数の層を含み得る。自動化ライブラリ２００の各層は、１つまたは複数のオブジェクトセットを含み得る。自動化ライブラリ２００の層は、物理層２０２、論理層２０４、テストケース層２０６内の１つまたは複数のテストケース、包括的検証層２０８、振舞い層２１０、およびデータマネージャ層２１３のうちの１つまたは複数を含み得る。振舞い層２１０は、実行振舞いマネージャ２１２および実行振舞いデータバンク２１４を含み得る。代わりに、実行振舞いは、論理層２０４内に常駐し得る。
【００５５】
自動化ライブラリ２００は物理層２０２、論理層２０４、テストケース層２０６内の１つまたは複数のテストケースのうちの１つまたは複数を含み、実行振舞い層２１０、包括的検証層２０８およびデータマネージャ層２１３は、自動化アーキテクチャスタック２３０の外部に存在し得る。本発明の一部の実施形態では、実行振舞い層２１０、包括的検証層２０８およびデータマネージャ層２１３は、論理層２０４から離れているが、論理層２０４内に統合される。実行振舞い層２１０、包括的検証層２０８およびデータマネージャ層２１３は、論理層２０４から離れているので、アーキテクチャスタックの外部からアクセスされ得る。
【００５６】
自動化ライブラリ２００は、例えば、オペレーティングシステム、外部ツール、グラフィックスアニメーションサブシステムなどのうちの１つまたは複数を含めて、１つまたは複数のコンポーネントを含むシステムライブラリの上の層を表し得る。図２で、例示的なシステムライブラリ２４０は、内部テスト自動化モジュール２１６、アクセシビリティモジュール２１８、ＵＩ自動化モジュール２２２、グラフィックスアニメーションサブシステム２２８（グラフィックスアニメーションオブジェクト２２０およびグラフィックスアニメーションアプリケーション２２４を含む）、ならびにシステムレベルアプリケーションを含んでいる。
【００５７】
自動化ライブラリ２００は、グラフィックスアニメーションサブシステム２２８のレイアウトおよびコントロールを含み得る。自動化ライブラリ２００のレイアウト部分は、グラフィックスアニメーションサブシステム２２８の視覚要素の各インスタンスについてのクラスを含み得る。すなわち、レイアウト部分は、それだけに限らないが、新しいプロジェクトダイアログ、１つまたは複数のツールボックスペイン、およびメインメニューなど、グラフィックスサブシステム２２８の「最上位レベル」の視覚要素を表すすべてのクラスを含み得る。コントロール部分は、それぞれのタイプの視覚要素についてのクラスを含み得る。すなわち、コントロール部分は、それだけに限らないが、ボタンクラス、コンボボックスクラス、テキストボックスクラスおよびカラーピッカークラスなど、グラフィックスアニメーションサブシステムで使用されるすべてのシステムおよびカスタムコントロールのクラスを含み得る。こうしたコントロールは、最上位レベル要素によって（メインメニュー、ツールボックスペインまたは新しいプロジェクトダイアログなどによって）だけアクセス可能であり得る。自動化ライブラリ２００のコントロール部分内の各コントロールは、すべての入力方法（キーボード、マウス、アクセシビリティなどによる）についての実装を含めて、コントロールにアクセスし、それを操作するのに必要なすべてのメソッドおよびプロパティを含み得る。
【００５８】
自動化ライブラリ２００を使用して、モデルベース、統合、パフォーマンス、負荷、ストレス、受入れ、単体、ビルド検証、基本機能、完了基準（ｅｘｉｔ  ｃｒｉｔｅｒｉａ）、包括的／拡張機能、ローカライゼーション、グローバリゼーション、アクセシビリティ、および他のテストを含めて、任意のタイプのテストを実施することができる。自動化ライブラリ２００は、スクリプト記述されたテストケースによってアクセスされ、またはそれを含み得る。代わりに、自動化ライブラリ２００にアクセスし、またはそれに含まれるテストケースは、ＸＭＬで、コンパイル言語で、バイトコードで、データベース内で、テキスト内で、テーブル内などで表現され得る。
【００５９】
自動化ライブラリ２００の各層は、下の層への直接アクセスを有する（呼出しを行うことができる）。すなわち、テストケース層２０６は、論理層２０４への直接アクセスを有する。論理層２０４は、物理層２０２への直接アクセスを有するなどである。本発明の一部の実施形態では、ある層がそれよりも深い層にアクセスし、またはそれへの呼出しを行うための手段が提供され、すなわち、例えば、そうすることが望ましい場合には、テストケースが内部テスト自動化層２１６、物理層２０２などに直接にアクセスすることが可能であり得る。
【００６０】
テストケース層２０６は、テストされるアプリケーションまたはモジュール、特徴または機能に適用される１つまたは複数のテストケースを含み得る。テストケースは、スクリプト記述され得る。論理層２０４に対して作成される例示的なテストケースは、例えば以下の通りであり得る。 
グラフィックスアニメーションサブシステムを開始する
新しいプロジェクトを追加する
０，０〜４，４に長角形を描画する
長方形の色を赤に設定する
プロジェクトを保存する
グラフィックスアニメーションサブシステムをシャットダウンする
【００６１】
上記の例示的なテストケースに欠落しているのは、結果検証を対象とするコード、実行オプションを対象とするコード、コントロールなどの特定のＵＩ要素の識別を対象とするコードなどであることが理解されよう。したがって、自動化ライブラリ２００内の変更がアプリケーションの論理操作のカプセル化のせいであるという理由から、論理層２０４に対して作成された、テストケース層２０６のテストケースは、まれにしか変更する必要がない。
【００６２】
本発明の一部の実施形態では、論理層２０２は、それぞれの機能の操作がどのように実施されるかでなく、アプリケーションが実施すると思われる機能を対象とする。論理層２０２は、グラフィックスアニメーションサブシステム２２８の論理操作をカプセル化し、またはラップすることができ、論理操作の実装の詳細を抽象化する。本発明の一部の実施形態では、論理層２０２は、ＵＩについてのすべての知識を抽象化し、テストケース層２０６のテストケースと、検証層２０８、振舞い層２１０およびデータマネージャ層２１３との間のインターフェースを提供する。論理層２０２は、グラフィックスアニメーションオブジェクトモデル２２０（グラフィックスアニメーションアプリケーション２２４の内部状態）とテストケースの間のインターフェースを提供することもできる。論理層は、単一のユーザ動作を実行するために使用される動作シーケンスに対する可変性を提供し得る。
【００６３】
物理層２０２は、物理層に対して作成されたテストケースが、マウスまたはキーボード、アクセシビリティソフトウェアなどを使用してコントロールが呼び出されたかどうかなどの実行詳細に対処する必要がないように、実行方法を抽象化する。物理層は、特定のコントロールと対話するために使用される方法に対する可変性を提供し得る。物理層２０２は、ＵＩに関するオブジェクトモデルを提供することもでき、すなわち、物理層２０２は、ＵＩへのインターフェースを提供し得る。したがって、アプリケーションまたはＵＩの要素が変化する場合、変更は、すべてのテストケースではなく、物理層内で行われ得る。
【００６４】
物理層に対して作成された別の例示的なテストケースは、例えば以下の通りであり得る。 
グラフィックスアニメーションサブシステムを開始する
ファイルメニューを呼び出す
新しいサブメニューを呼び出す
新しいプロジェクトメニューアイテムを呼び出す
新しいプロジェクトを提供するために名前を入力する
新しいプロジェクトダイアログボックスを閉じる
グラフィックスアニメーションサブシステムが新しいプロジェクトの作成を終了するのを待つ
長方形形状ツールをアクティブ化する
マウスを０，０から４，４までドラッグする
色プロパティペイン内の可能なストローク色のリストから「赤」を選択する
ファイルメニューを呼び出す
保存メニューアイテムを呼び出す
グラフィックスアニメーションサブシステムがプロジェクトの保存を終了するのを待つ
ファイルメニューを呼び出す
終了メニューアイテムを呼び出す
グラフィックスアニメーションサブシステムがシャットダウンするのを待つ
【００６５】
上記の例示的なテストケースは、動作（「ファイルメニューを呼び出す」など）がどのように実行されるかを指定しない（すなわち実行パスを指定しない）ことが理解されよう。実行マネージャは可能な実行パスの領域から選択を行うので、テストケースを複数回実行することによって、すべての使用可能な実行パスが複数回実行される。すべての検証コードがテストケースの外部に常駐するので、検証処理は、テストケースの変更を必要とせずに、より完全に行われ得る。同様に、テストケースは、それが含む動作のいずれかの期待される結果が変化する場合に、変更する必要はない。テストケースは、ＵＩへの参照を含まないことが理解されよう。したがって、テストケースは、ＵＩが変化する場合に変更する必要はない。テストケースの焦点は、ユーザが取り得る動作に当てられることが理解されよう。
【００６６】
テストコードが作成される対象の物理層内の対応するコードは、以下の通りであり得る。
【００６７】
【表１】
2006099737.tif 000003
【００６８】
論理層２０４は実装の詳細には関係せず、機能にだけに関係し、またほとんどのテストケースが論理層２０４に対して作成されるので、テストケースは、ソフトウェアライフサイクルのはるかに早期に作成されることができる。コードが完成するとすぐに、テストケースが実行されることができ、したがって、より多くのテストがよりすぐに、より速く行われ得る。
【００６９】
本発明の一部の実施形態の包括的検証層２０８は、検証処理をカプセル化する。本発明の一部の実施形態の論理層２０４は、論理層２０４がテストケースを実行する前に検証層２０８に通知して、検証層２０８がテスト前状態のスナップショットを取ることができるようにする。テストケースを実行された後に、論理層２０４は、テストケースが実行されたことを検証層２０８に通知する。次いで、検証層２０８は、実際の結果が期待された結果に一致するかどうか判定し得る。さらに、検証層に関する情報は、関連出願の米国特許出願整理番号第ＭＳＦＴ−４１４９号明細書、「Automated Test Case Verification That Is Loosely Coupled With Respect To Automated Test Case Execution」中で見ることができる。
【００７０】
一部の実施形態の論理層２０４は、論理操作を実行する各メソッドについての（実行振舞い２１４の）特定の振舞いを実装する。例えば、本発明の一部の実施形態では、ＣｒｅａｔｅＮｅｗＰｒｏｊｅｃｔの振舞いでは、これは、アプリケーションのオブジェクトモデルを実装し、キーストロークのシーケンスを送信し、アクセシビリティモジュールを介してメニューアイテムを呼び出し、マウスを使用してメニューアイテムを呼び出し、メニュー内を移動するために矢印キーを使用してメニューを呼び出し、メニュー内を移動するために簡略文字を使用してメニューアイテムを呼び出すことを含む。実行振舞い層は、どの振舞いが論理操作に関係するかを決定し得る。
【００７１】
本発明の一部の実施形態では、論理操作を実行する各メソッドについて、（実行振舞いデータバンク２１４、論理層２０２または別のところに格納された）別個の振舞いが実装され得る。振舞いの使用によって、同じ程度の包括的なテストを依然として提供しながら、はるかに少ないテストケースを作成することが可能になる。本発明の一部の実施形態の実行振舞い層２１０の実行振舞いマネージャ２１２は、実行振舞い２１４のどの振舞いが考慮対象の論理操作に関係するかを決定する。本発明の一部の実施形態では、加重係数および他の設定を使用して、特定の振舞いを選択することができる。振舞い層２１０に関するさらなる情報は、関連出願の米国特許出願整理番号第ＭＳＦＴ−４１４８号明細書、「System for Selecting Test Case Execution Behaviors for Reproducible Test Automation」中で見ることができる。
【００７２】
次いで、論理層２０４は、選択された振舞いを使用して操作を実行し得る。本発明の一部の実施形態の選択機構は、実行時に構成可能である。この特徴によって、テストの振舞いは、テストケース自体を修正せずに修正されることができる。例えば、メニュー機構が最近書き換えられた場合には、新しいコードに適切なテストを提供するために、メニュー機構を使用して動作を実施することが望まれ得る。代わりに、ショートカットキー処理内に既知のバグがある場合、バグが修正されるまで、ショートカットキーを使用するメソッドの使用を控えるのが望まれ得る。この変更は、テストケース自体ではなく、振舞い層を介して行われ得る。
【００７３】
図４は、自動テストにおいてアーキテクチャスタックを使用する方法のフローチャートである。ステップ４０２で、アーキテクチャスタックに対して作成されたテストケースが受信される。テストケースは、論理層に対して作成され得る。代わりに、テストケースは、スタック内のより深い層に対して作成され得る。ステップ４０４で、テストケースが実行されることの通知が、検証層に送信され得る。本発明の一部の実施形態では、テストされるアプリケーションのテスト前の期待される状態のスナップショットが取られる。ステップ４０６で、テストケースのステートメントが構文解析される。本明細書の一部の実施形態では、テストケースの各ステートメントは、論理操作を表している。ステップ４０８で、論理操作に関係する振舞いが決定される。テストケースは、各ステップ自体の詳細を実装するのではなく、実行振舞いマネージャに適切な振舞いを求めることができる。本発明の一部の実施形態では、実行振舞い層の実行振舞いマネージャは、実行振舞いデータバンク内のどの振舞いが考慮対象の論理操作に関係するかを決定する。実行振舞いマネージャは、テストケース内のステップを実行するために使用され得る個々の振舞い間の１組の関係を詳しく見ることができ、選択を行い得る。加重係数および他の設定を使用して、特定の振舞いを選択することができる。ステップ４１０で、選択された振舞いを使用して、操作が実行され得る。ステップ４０６から４１０は、テストケース内の各ステートメントについて繰り返され得る。ステップ４１２で、検証層は、テストケースが実行されたことの通知を受け得る。検証層は、実際の結果が期待された結果に一致するかどうか判定し得る。代わりに、検証処理は、テストケース内の各ステートメントが実行された後に行われ得る。
【００７４】
本明細書で説明した様々な技術は、ハードウェアまたはソフトウェアと共に、あるいは適切な場合には、その両方の組合せで実装され得る。したがって、本発明の方法および装置、あるいは特定の態様またはその一部は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読取り可能記憶媒体などの有形媒体内で実装されたプログラムコード（すなわち命令）の形を取ることができ、該プログラムコードがコンピュータなどのマシン内にロードされ、それによって実行される場合に、該マシンは、本発明を実施するための装置になる。プログラマブルコンピュータ上のプログラムコード実行の場合、コンピューティング装置は一般に、プロセッサ、プロセッサによって読取り可能な記憶媒体（揮発性と不揮発性のメモリおよび／またはストレージ要素を含む）、少なくとも１つの入力装置、ならびに少なくとも１つの出力装置を含む。例えばデータ処理ＡＰＩなどを使用することによって、本発明の特定領域（ｄｏｍａｉｎ  ｓｐｅｃｉｆｉｃ）プログラミングモデル側面の作成および／または実装を使用し得る１つまたは複数のプログラムは、好ましくは、コンピュータシステムとの対話のため、高水準の手続き型またはオブジェクト指向プログラミング言語で実装される。しかし、そのプログラムは、所望であれば、アセンブリまたはマシン言語で実装され得る。いずれの場合も、言語は、コンパイルされまたは解釈される言語であり、ハードウェア実装と組み合わせられ得る。
【００７５】
本発明について、様々な図面の好ましい実施形態に関連して説明したが、他の類似の実施形態を使用することができ、またそこから逸脱せずに、本発明の同じ機能を実施するために、説明した実施形態に対して修正および追加が行われ得ることを理解されたい。したがって、本発明は、単一の実施形態に限定されるべきでなく、添付の特許請求の範囲による幅および範囲において解釈すべきである。
【図面の簡単な説明】
【００７６】
【図１】本発明の態様が実施され得る例示的なコンピューティング環境を示すブロック図である。
【図２】本発明の一実施形態による、階層化アーキテクチャを使用した自動ソフトウェアテストのための例示的なシステムのブロック図である。
【図３】本発明の一実施形態による、図２のシステムの一部のより詳細なブロック図である。
【図４】本発明の一実施形態による、図２の自動ソフトウェアテストシステムを使用するための例示的な方法のフローチャートである。
【符号の説明】
【００７７】
１００  コンピューティング環境
１２０  処理装置
１２１  システムバス
１３０  システムメモリ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１４０  取外し不可能な不揮発性メモリインターフェース
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  他のプログラムモジュール
１４７  プログラムデータ
１５０  取外し可能な不揮発性メモリインターフェース
１６０  ユーザ入力インターフェース
１６１  マウス
１６２  キーボード
１７０  ネットワークインターフェース
１７１  ローカルエリアネットワーク
１７２  モデム
１７３  広域ネットワーク
１８０  リモートコンピュータ
１８２  グラフィックスインターフェース
１８５  リモートアプリケーションプログラム
１８６  ビデオメモリ
１９０  ビデオインターフェース
１９１  モニタ
１９５  出力周辺インターフェース
１９６  プリンタ
１９７  スピーカ
１１０  コンピュータ
２００  自動化スタック
２５０  自動テストシステム
２５２  テストＥＸＥＣ
２５４  データＭＧＲ
２６０  テストケース
２６２  アプリケーション
【図１】
2006099737.tif 000004
【図２】
2006099737.tif 000005
【図３】
2006099737.tif 000006
【図４】
2006099737.tif 000007