JP5535484B2 - 自動ソフトウェアテストフレームワーク - Google Patents

Description

本出願は、２００５年１２月１２日に出願された第１１／２９９，５７２に基づく優先権を主張する。

本発明は、一般にコンピュータシステムおよびソフトウェアの質を保証するテストに関する。

ソフトウェアプログラムまたはシステムの開発中に自動的にテストする周知の多くの取り組みがある。機能／テスト開発段階では、例えば、品質保証のエンジニアは、開発中のシステムに行われる一連の静的なテストケースを立案する。一連のテストケースあるいは一群のテストケースは、テスト群と呼ばれることもある。

複数のソフトウェアプラットホームに散在する複数の展開されたイメージをテストする周知の自動ソフトウェアテストシステムが、米国特許第６，６６２，３１２に記載されている。この特許では、展開された各イメージは、テストポートの接続を受けるテスト構成要素を備えている。展開されたイメージのテスト構成要素は、開発環境に挿入され、展開されたイメージに統合される。このシステムは、テストエンジンおよびユーザインタフェースを備えている。テストエンジンは、展開された複数のイメージに複数のテストを行うように構成されている。このテストエンジンは、周知のテストポート上の対応するテスト構成要素への接続を要求し、および接続を介した送信コマンドを送信することによりテストにより、イメージのテストを行う。ユーザインタフェースはテストエンジンに接続され、ユーザがテストエンジンを制御でき、テストの結果を確認できる。

同じような別の自動システムが、米国特許第６，３０１，７０１に記載されている。この特許は、トランザクションベースのソフトウェアアプリケーションの開発中およびその他のライフサイクル段階で使用する自動的なテスト方法を説明している。トランザクション評価員は、テストにおいてトランザクションの定義からテストデータを生成することによりトランザクションのインテグリティを評価する。フィールドの通常の値は、トランザクションの定義内に含まれ、通常のテスト値として再利用される。テストの結果が生成され、既知のよい値と比較され、代替的に、反対に、期待されるテスト結果は、トランザクション定義から生成される。また、メニュー構造を含む他のソフトウェア構成要素がテストされる。メニュー構造の定義は、各メニューの各エントリが完全にテストおよび報告されるように厳密に網羅される。結果は、既知のよい結果と自動的に比較および照合され、またはテスト結果は自動的に再検討される。トランザクションテストおよびメニューテスト双方は、回帰テストに組み込んでもよい。

米国特許第６，００２，８６９は、ソフトウェアプログラムの機能テストを実施する自動テストシステムを説明している。このシステムは、それぞれがソフトウェアプログラムの個々の要素をテストするように構成された複数のテスト機能を備えている。ユーザが定義し且つプログラムに関連するテスト仕様書は、プログラムで実行される各種類のテスト処理の所望のテスト方法を明記する状態定義を提供する。テストエンジンは、ユーザが選択したテスト種類に適した総てのテストケースを生成し、ソフトウェアプログラムを制御し、テスト仕様書に従ってテスト機能および状態定義を利用する。テスト仕様書およびソフトウェアプログラム仕様書のデータは、ユーザが定義したテスト機能および仕様書に配置される一方、総ての一般的なテストシステムの処理はテストエンジンに属する。テスト仕様書は、修正可能なテキストファイルで実行され、ソフトウェアプログラムの展開と同時並行性を維持する。テストエンジンは、所望のテストを実施する可能な順列および組み合わせを生成する。これらのテスト仕様書は、ソフトウェアプログラムが保持する状態、一の状態と他の可能な状態との間を遷移するよう要求するテスト機能、および特定の入力が有する値に関連する情報などのアイテムを含む。処理中、テストエンジンは、テスト仕様書の一により実施されたテスト結果を示すテスト歴を生成する。

米国特許第５，５１３，３１５は、決定許容テスト（deterministic acceptance test）およびランダムなコマンドシーケンス選択を用いてコンピュータソフトウェアのエラーを明らかにする自動的にソフトウェアをテストするシステムおよび方法を説明している。結果のアナライザは、一連の所定のテストコマンドおよび一連のランダムなテストコマンドそれぞれの実行の後にテストパラメータをチェックし、コマンドが正しく実行されたかを判断する。テストコマンドシーケンスと、結果アナライザにより決定されるテスト結果が、評価者により調べられるログファイルに格納される。ランダムに選択されたテストコマンドシーケンスは、追跡用ログファイルに格納される。このシステムはまた、エラー回復を提供する。エラーが検出されると、システムはコンピュータソフトウェアのテストを再び開始し、ログファイルおよび追跡ファイルの管理を続ける。このシステムはまた、エンドユーザが特定のスクリーンディスプレイまたはプログラム情報に応じて作成する様々な応答の可能性（probability）を利用する。このシステムは、この可能性に対応するランダムな応答を選択してもよい。これらの可能性は、個別のスクリーンディスプレイまたはソフトウェア状態ごとに計算される。このシステムはコマンドシーケンスのランダムな選択を実行するため、プログラムが複数のマシンでテストされ、これにより、許容テストに要する全体の時間を削減する。

米国特許第５，７５１，９４１は、ソフトウェアをテストするオブジェクト指向のフレームワークを説明している。この特許では、ソフトウェアテストシステムは、設定および制御システムと、当該設定および制御システムに接続される１またはそれ以上のテストシステムを備えている。設定および制御システムは、ソフトウェアテストシステムのユーザと情報をやり取りするユーザインタフェースを備えている。設定および制御システムは、テストデータおよびテストコンフィグレーションを格納する。各テストシステムは、設定および制御システムに格納されたテストデータおよびテストコンフィグレーションからテストケースを設定する。各テストケースは、テストシステム内の少なくとも一つのテストオブジェクトから属性を継承する。継承された属性は、テストケースを有するテストシステムのインタラクションを促進する。

他の自動テストシステムは、例えば、米国特許第５，０２１，９９７、５，３５７，４５２、５，３５９，５４６、５，４９０，２４９、５，５００，９４１、５，５４２，０４３、５，５９０，３３０、５，６３４，００２および６，１６７，５３７に記載されている。また、既知の従来のテストフレームワークは、ＳＴＡＦ（ソフトウェアテスト自動化フレームワーク）などの解決手段を備えている。

通常、前述した特許およびシステムは有用であるはあるが、これらの技術は、テストケースが様々なプログラミング言語で記述された環境で自動ソフトウェアテストを実行するほど順応性がない。さらに、このような従来のシステムはしばしば、テストが行われるアプリケーションまたはシステムに密接に関連しており、このため、汎用的なテスト能力を提供するのに有益ではない。これに関連する欠点は、システムが通常、開発中のアプリケーションのための特定のテストまたはテストの種類に準拠して記述または制御されていることである。したがって、自動システムは、必然的に開発される特定のアプリケーションあるいはシステムに従属し、一般的なプログラムセットまたはテスト群のテストを容易にサポートできない。

本発明の目的は、テストされるシステムの最新のバージョンを自動的に割り当て、インストールしおよび検証し、「ハンドオフ」による客観的な方法で一連のテストをシステムに適用し、１以上の開発者のレポジトリ（問い合わせ可能なデータベース、電子メールリスト、開発者のウェブサーバ、ソースコードバージョン制御システム、ディフェクトトラッキングシステム等）にテストの情報をエクスポートする汎用的なテストフレームワークを提供することである。このフレームワークは、テストがコマンドラインまたはコンフィグレーションファイルを介して命令を発行できる限り、特定のインプリメンテーション言語に「注意を払う」あるいは考慮しない。複数のテストを有する所定のテスト群の自動テスト中、および特定のテストが実行された後は、フレームワークは、テスト群の追加のテストが行われる場合でも、テストされるシステムの「イメージ（image）」を生成し、開発者が利用可能な情報を生成するのが好適である。この方法では、フレームワークは、システムの「状態」を保護し、現在のデバッグまたは事後のデバッグを容易にする。このフレームワークはまた、所定のテストが破壊的であり、またはシステムを許容不能な状態にするイベントに不可欠なテストにおいてシステムの最新のバージョンを再インストールし、検証する。

テスト情報を開発者のレポジトリに記録することにより、開発者は、開発中にテストデータに即座にアクセスする。したがって例えば、開発者はテストデータベースに問い合わせでき、特定の日またはシステムコンフィグレーションで失敗した特定のテストを判断できる。ウェブサーバ内の結果を公開し、特定のテスト運転について開発者に（例えば、電子メール等により）通知することにより、開発者は、簡単且つ効率的な方法で（例えば、電子メール内のリンクを選択することにより）、このようなデータにアクセスできる。また、テストされる特定のシステムの「イメージ」は、デバッグあるいは開発工程において非常に有用である。さらに、特定のテスト運転は、ディフェクトトラッキングシステムに報告する必要のある失敗を生成するために、フレームワークは、必要とされるこのようなシステムに容易にデータをエクスポートすることが好適である。

汎用的なテストフレームワークは、他のスタンドアロン論理モジュール（ルーチン、処理等）をコールして、クライアントアプリケーションが要求する様々な機能を実行するスタンドアロンのクライアントアプリケーション（または「デーモン」）として実装される。したがって、例えば、第１のこのような論理モジュールは、テストされるシステムの最新のソフトウェアビルドをフェッチするソフトウェアプログラムでもよく、第２の論理モジュールは、テストされるシステムにソフトウェアビルドをインストールすべく個別のプログラムで使用されてもよく、第３の論理モジュールは、バージョン制御システムにアクセスしてインストールされたソフトウェアビルドに用いられるテスト群の一連のテストを特定するソフトウェアプログラムでもよい。一実施例では、クライアントアプリケーションおよび関連する論理モジュールは、所定のマシン上で実行される。分散システムでは、クライアントアプリケーションは一のマシンで実行されるが、１またはそれ以上の論理モジュールは、１またはそれ以上の他のマシンで実行される。この方法では、所定のクライアントアプリケーションは、テスト群を実行するのに用いられる様々なツールまたは機能が、他のマシンプラットホーム、オペレーティングシステム等で実行されるとともに、所定のテスト群を開始し「所有」する。論理モジュールはまた、１またはそれ以上のクライアントアプリケーションにより共有され、それぞれが異なるクライアントマシン上で動作する。

典型的な実施例では、クライアントアプリケーションデーモンは要求の待ちを実行し、テスト群（あるいはテスト群のうちの所定のテスト）を開始する。要求を受信すると、フレームワークは、インストールする前に必要に応じてシステムを整理し、テストされるシステムの最新のソフトウェアビルドをダウンロードしてインストールする。フレームワークは、自動的なビルドシステム（例えば、ＣｒｕｉｓｅＣｏｎｔｒｏｌ）から最新のソフトウェアビルドをダウンロードしてもよい。最新のソフトウェアビルドがインストールされると、またはインストールに従うと、フレームワークは、場合によっては、インストールが成功しているかあるいは成功したかを自動的に検証する。次に、フレームワークは、テスト群および当該テスト群に関連するテストファイル／データを定義するテスト群の定義をデータベースから自動的に検索する。テスト群の定義は、これらのファイル、例えばコードレポジトリ（Ｐｅｒｆｏｒｃｅ、ＣｌｅａｒＣａｓｅ、ＣＶＳ等）の位置をフレームワークに通知し、フレームワークはそれらを取得する。前述したように、テスト群またはテスト群のうちの所定のテストは、インプリメンテーション言語に関係なくフレームワークでテストされる。フレームワークはテスト群をインストールし、好適には各テストが独立した状態でテストの実行を開始する。テストは任意の順序で、例えば順々にまたはランダムに実行してもよい。各テストは合格または失敗する。テスト群の所定のテストの後、フレームワークは、テストされるシステムのイメージを作成し、これにより、現在または将来の分析のためにシステムの「状態」を保護する。必要であれば（例えば、従来の破壊的なテストのために）、フレームワークは、テストされるシステムまたは最新のソフトウェアビルドを再インストールし、テスト群の次のテストを継続する。このシステムコンフィグレーションは、再インストールする間に変更してもよい。テスト群の総てのテストが終了した後、フレームワークは、テストデータおよびイメージを集め、Ｗｅｂサービス等を介してアクセス可能な中央データベースなどのテストデータを問い合わせ可能なデータストアにエクスポートする。次いで、テスト群が記載された電子メールが、電子メール分配リスト上の１またはそれ以上の人物に配信される。フレームワークはまた、所定のテストデータをディフェクトトラッキングシステム（例えばＢｕｇｚｉｌｌａ）に選択的にエクスポートする。

一般化すると、自動テストフレームワークは、テストされるシステムを自動的に割り当て、インストールし、検証するテストランナーまたはテストハーネスであり、割り当てられたシステムで実施されるテストのために「クリーンルーム」環境を提供し、テスト中のシステムの「スナップショット」を取得し、好適には高いレベル（「合格」または「失敗」）でテストの結果について報告し、あるいはフレームワークは、実行されるテストの方法に依存しない。フレームワークは、開始から終了に至るまで、テストされるシステムの管理を自動化するとともに、テスト（ホワイトボックステスト、ブラックボックステスト等）を実施し、好適には再利用可能あるいは外部のツールおよび構成要素および言語に依存しないテスト（language-agnostic）を用いる。

自動テストフレームは順応性があり、拡張が容易であり、テスト言語およびクライアントプラットホームに依存しないことが好適である。これは、任意のテストを任意の言語で実施する方法で実現される。実際には、テストは複数のクライアントホストおよびクライアントオペレーティングシステムでテストが実施されるように記述できる。

前述の記載は、本発明の関連する特徴の一部の概要である。これらの特徴は、単に説明するために記載されている。開示された発明を異なる方法で利用することにより、または以下に説明するように本発明を修正することにより、多くの他の有益な結果を得ることができる。

本発明および本発明の利点をより完全に理解すべく、ここで、添付図面と関連して以下の説明が参照される。

本発明の自動テストフレームワークは、一のマシン（または複数のマシン）で実行可能なプログラムコードとして実現されることが好適である。特定のマシンの詳細または動作環境は、本発明に特に関連しない。前述したような一の実施例では、コードは、フレームワークが要求する様々な機能を実行する他のモジュールをコールするスタンドアロンのアプリケーションまたは「デーモン」として動作する。このようなモジュールの一つは、フレームワークまたは外部システムの一部に由来してもよい。また、デーモンは一のマイン上で動作するが、１またはそれ以上のサービスモジュールは、同じまたは他のマシンで動作してもよい。これは、フレームワークのクロスプラットホームの互換性を保証する。

図１Ａ、１Ｂおよび１Ｃは、一の例示的なシナリオでは（以下に説明する）分配されるソフトウェアアプリケーションである、所定の「テストされるシステム」（またはＳＵＴ）に対する本発明の自動テストフレームワークの基本的な動作を示している。「テストされるシステム」の語は、任意のシステム、製品、アプリケーション、処理、マシン、またはこれらの組み合わせを網羅するように広義に解釈すべきである。本発明の技術的な利益は、フレームワークが、テストされるシステムまたはシステムのための特別なテストが記述された言語に依存しないことである。したがって、自動テストフレームワークは、テストされる特定のシステムまたは特定の種類のシステムで利用することに限定されない。むしろ、フレームワークは、システムがスタンドアロンまたは分散システムであるかに拘わらず、システム環境または目的に拘わらず、システムで動作するアプリケーションの特性および種類に拘わらず、テストされる任意のシステムの自動テストをサポートする。

図１Ａを参照すると、自動テストフレームワークは、ステップ１００においてデーモンテストのように、実行要求がフーレムワークにより受信されたかを判断することが好適である。受信していない場合は、ルーチンサイクルはワークを待つ。実行要求を受信した場合は、ステップ１０２において、デーモンが要求を解析し、要求されているリソースを特定する。通常、要求はテストされる特定のシステム（またはＳＵＴコンフィグレーション）、所定のソフトウェアビルド、テスト群、およびテストの結果がエクストートされるべきデータレポジトリを特定するが、要求の意味（request semantics）は通常、テストされるシステムの特性に依存する。デーモンはステップ１０４に分岐し、所望のリソースが利用不能である場合、通知／リスタートコマンドを発行し、この場合、制御はステップ１００に戻る。リソースが利用可能である場合、ステップ１０６において、フレームワークはソフトウェアを検索する。通常、この検索は（以下に説明する１またはそれ以上の機能のように）、個別に呼び出し可能な論理モジュールにより実行される。代替的に、自動テストフレームワークは勿論、本来のコードなどのモジュールを備えてもよい。ソフトウェアビルドを検索する通信は、ローカルで、またはネットワークを介して行ってもよい。ステップ１０６で検索されたソフトウェアは、テストされるシステムの最新のソフトウェア「ビルド」であることが有益である。周知の通り、複雑なソフトウェアまたはソフトウェアシステムはしばしば、開発および所定のソフトウェアアプリケーションの耐用年数の間、多数（数十または数百）のソフトウェア「ビルド」を処理する。ステップ１０６において、自動テストフレームワークは、例えば、ソースコードまたは他のレポジトリから論理モジュールをビルドにフェッチすることにより、最新のソフトウェアビルド（あるいは要求で特定される他の設計されたビルド）を検索することが好適であり、次いで、ステップ１０８において検証ステップを実行する。この検証の特定および範囲は、テストされるシステムに依存する。検索されたビルドが検証できない場合、ルーチンは一旦ステップ１０４に分岐し、新たなワークを待つ。ソフトウェアビルドが検証できた場合、ステップ１１０において、フレームワークがインストールを実行する。このステップの詳細は図１Ｂに示されており、以下に説明する。ステップ１１２では、フレームワークが別の検証を実行し、ソフトウェアビルドが適切にインストールされたか否かを判断する。ステップ１１２は２つのステップを備えてもよい。ステップ１１４では、フレームワークは待ち状態になり（リソースが設定されているが）、ステップ１１６で、様々なリソースの利用可能性を検証できるか否かについてテストを開始する。フレームワークがインストール処理としてリソースの利用可能性を検証できない場合、制御は一旦ステップ１０４に戻る（したがって、ステップ１００に戻る）。ステップ１１２の検証の結果、テストされるシステムが利用可能であることが分かった場合、ステップ１１８において処理は、テストされるシステムへのアクセスを要する１以上のデバイスまたはシステム（または「アクセスベクトル」）を検証する。アクセスベクトルの失敗またはアクセス不能により、フレームワークは、前述したようにステップ１１６に分岐する。ステップ１２０では、フレームワークは最後の検証を実行して、（最新のソフトウェアビルドに加え、様々なワードウェアおよびソフトウェアを備えることがある）テストされるシステム全体の状態が許容可能であるか、またはテスト群を実行する必要があるかを判断する。ステップ１２０のテストの結果が否定的である場合、ルーチンは前述したように一旦ステップ１１６に分岐し、１以上のリソースが正しくインストールするのを待つ。

ここで、インストールが実行され、ＳＵＴの状態が検証されたとすると、フレームワークはテスト群を実行する準備ができる。したがって、ステップ１２０ではフレームワークはテストメタデータを特定し、ステップ１２２では任意のテストの従属性（dependencies）を特定する。従属性がある場合、ステップ１２４において、フレームワークがテストの従属性を同期させ、ステップ１２６において、フレームワークが、この同期が成功したことを保証すべく検証を実行する。失敗した場合、ルーチンはステップ１０４に分岐し、場合により通知あるいはリスタートする。ステップ１２０および１２２の後、ステップ１２８において、フレームワークがテスト群のうちの１以上のテストを実行する。図１Ｃはテスト実行処理を示しており、以下に説明する。テスト群の所定のテストが実行された後、ステップ１３０において、フレームワークは、テストを受けるシステムが再インストールする必要があるか否かを判断する（前述したように、システムコンフィグレーションは再インストールの際に変更してもよい）。これは、例えば所定のテストがシステムまたはテストされるシステムの所定のリソースを破壊するため必要であろう。代替的に、ユーザは再インストールを要求するフラグを設定してもよい。ステップ１３０において、テストの結果が、システム（またはこれの構成要素）の再インストールが必要ないこと示す場合、フレームワークは、ステップ１３２でテストを実行し、テスト群の総てのテストが終了したか否かを判断する。終了していない場合、デーモンはステップ１２８に戻り、テスト群の次のテストを取得し実行する。システムコンフィグレーションは、再インストールが要求あるいは実行されてない場合でも、テスト群の次のテストが実行される前に変更してもよい。ステップ１３２のテストの結果が、テスト群の総てのテストが終了したことを示している場合、ステップ１３４において、デーモンがテストデータを集めて報告する。次に、デーモンは自動的にステップ１３６の結果を公表する。図示するように、通常の公表処理は、ステップ１３８に示すようなデータベースへの公表またはステップ１４０に示すようなウェブサーバへの公表を含む。データデースは集中化され、通常、データベースクエリー（例えば、ＳＱＬ）が実行されるデータベースマネージメントシステムを備える。ウェブサーバは、イントラネット上で利用可能でもよく、通常はｈｔｔｐ、ｈｔｔｐまたはｆｔｐサービスを備えている。これらは単なる典型的なデータレポジトリである。さらに、デーモンは、結果または電子メールリストで特定される電子メールの購読者に通知することによりテストが終了したことを公表してもよい。これは、ステップ１４２に示されている。処理フロー図のこの部分のステップの特定の順序は勿論制限されない。さらに、デーモンは１以上のテストに関する所定の情報をディフェクトトラッキングシステムに公表し、これはステップ１４４である。

前述したように図１Ｂは、典型的なインストール機能の処理フローを示しており、これは図１Ａのステップ１１０である。ステップ１４６で処理が開始し、デーモンが実行要求のロードコマンドおよびロードオプションを解析する。ステップ１４８では、デーモンがテストに必要な特定のシステムコンフィグレーションを特定するロードコンフィグレーションファイルを取得する。ロードコンフィグレーションファイルは通常、必要な１以上のロードアシスタントモジュール１５０と、使用されるロギングシステム１５２のセットを特定する。ステップ１５４では、デーモンはロードコンフィグレーションファイルで特定されるリソースの可用性を検証し、インストールを開始する。具体的には、ステップ１５６で、テストが実行され、いずれの種類のインストールが要求されているかを判断する。処理フローの左側の枝は基本的なインストールを示しており、図の右側の枝はアップグレードなインストールを示している。基本的な枝では、デーモンは、ステップ１５８でテストされるシステムからソフトウェアをアンインストールすることにより開始する。ステップ１６０の検証の結果が肯定的である場合、デーモンは、ステップ１６２でローカルまたは取り付けられたストレージをフォーマットし、必要であれば、フレームワークはステップ１６４で、ローカルまたは取り付けられたストレージが既存のストレージの設定を継承する。ステップ１６６では、フレームワークはオペレーティングシステムをプッシュ／インストールする。ステップ１６８では、デーモンは、ターゲットソフトウェア（例えば、実際のソフトウェアビルド）をプッシュ／設定する。ステップ１７０では、フレームワークは、テストに要するデータベースを初期化する。ステップ１７２では、フレームワークは任意のシステムパッチをプッシュ／インストールし、ステップ１７４でシステムを保護する。したがってステップ１７６では、フレームワークは総てのリソースをリブートする。これらのステップは、テストされるシステムの「クリーンルーム」環境を保証する。ステップ１７５では、テストが実行され、総てのシステムの状態が検証される。これは、図１Ａのステップ１２０のテストに対応する。システムの状態が検証できない場合、ルーチンが中断し、エラーログに書き込む。

僅かな変更を有するアップグレード方法のパスを進む並行処理も同様である。このパスでは、ステップ１７８において、処理が必要に応じて既存のリソースを継承することにより開始する。フレームワークはまた、ステップ１７５に分岐し、依存のリソースを継承した後にシステムの状態を検証する。ステップ１６０の検証が成功した後、ステップ１８０で、フレームワークはデータベースシステムをアップグレードする。ステップ１６６では、任意の必要なオペレーティングシステムのアップグレードインストールが行われ、このパスは、ステップ１６８で、テストされる実際のターゲットソフトウェアのプッシュ／設定が行われる。前述したように、ステップ１７２では、フレームワークが任意のシステムパッチをプッシュ／インストールし、ステップ１７４でシステムを保護する。この後、フレームワークは、ステップ１７６で総てのソフトウェアリソースをリブートする。

図１Ｃは、テストがどのように実行されるかを示している。前述したように、本発明の利点は、フレームワークが言語に依存しないことである。すなわち、フレームワークは、テスト言語がコマンドラインまたはコンフィグレーションファイルを介して命令を発行できる場合に、テストが記述された形式に捕らわれない。実行ルーチンはステップ１８２で開始し、テスト実行モジュールをコールする。このルーチンは、ステップ１８４で必要に応じてフラグを解釈する。このステップは、１以上のコマンドラインまたはコンフィグレーションファイルの命令を解釈する必要のある所定の言語でテストが記述されている場合に要求され、テスト実行モジュールにより理解される。ステップ１８６では、（テストが開始から終了まで行わ「パス」した場合に）所定のテストが実施される。ステップ１８８では、フレームワークは標準的な出力を記録し、ステップ１９０では、（テストが終了せずに「失敗」した場合に）任意のエラー出力を記録する。テストが実行されている間、実行モジュールは、ステップ１９２でテストの状態を判断するためにチェックし、ステップ１９３でテストの状態を判断するために定期的にテストする。テストが終了していない場合、ルーチンはステップ１９２に戻る。ステップ１９２のテストの結果が、テストが終了したことを示している場合、ステップ１９４において、ルーチンはテストされるシステムのイメージを作成し、１以上のＳＵＴリソースの「スナップショット」を取得する。この「スナップショット」は、迅速且つ正確なデバッグまたは他の保守を容易にする特定の価値ある情報を提供する。この「イメージを作成する」処理は、１以上のサブステップを有することが好適であり、ステップ１９６ではフレームワークが様々なリソースのログをチェックし、ステップ１９８ではＳＵＴの履歴がダンプされ、ステップ２００ではＳＵＴのデータベースの履歴がダンプされ、ステップ２０２では、例えば、デーモンが実行されるクライアントにこれらのログが複製される。次いで、ステップ２０４では、イメージおよびパス／失敗の情報が、後のデータレポジトリへのエクスポートで利用可能な編集物（compilation）に追加される。ステップ２０６では、実行モジュールがテストが終了したことを報告する。次いで、ステップ２０８でテストが実行され、再インストールのフラグがあるか、あるいは要求されているかを判断する。これは、図１Ａのステップ１３０である。この場合、ルーチンは分岐し、再インストールを行う。ステップ２０８の後は、ステップ２１０でテストが行われ、テスト群の総てのテストが終了したかを判断し、終了していない場合はルーチンが回帰する。これにより処理が終了する。

図２に示すような典型的な実施例では、テストされるシステムは、アーカイブ記憶領域管理システムを提供するアーカイブクラスタアプリケーションである。この種の記憶領域管理システムは、潜在的に異なるハードウェア、すなわち「異種」であると考えられるハードウェアを備える一組のノードにより定義される。ノードは通常、１以上のストレージディスクにアクセスし、このストレージディスクは、実際の物理的なストレージディスク、またはストレージエリアネットワーク（ＳＡＮ）などに見られる仮想的なストレージディスクでもよい。各ノードでサポートされるアーカイブクラスタアプリケーションは、同一または実質的に同一でもよい。本システムを利用することにより、企業は、文書、電子メール、ビデオ等の多くの異なる種類の一定のコンテント情報のための恒久的なストレージを作ることができる。米国広報第２００５／０１２００２５に記載されているように、アーカイブクラスタアプリケーションは、デジタルアセットを取得、保護、管理、および検索する各ノードで実行される分配されたソフトウェアアプリケーションである。図２に示すように、個別のアーカイブの物理的な境界はクラスタと呼ばれる。通常、クラスタは単一のデバイスではなく、複数のデバイスである。デバイスは、同種または異種である。通常のデバイスは、Ｌｉｎｕｘなどのオペレーティングシステムを動作させるコンピュータまたはマシンである。コモディティハードウェアに搭載されるＬｉｎｕｘベースのシステムのクラスタは、僅かなストレージノードサーバから、数千テラバイトのデータを格納する多くのノードまで記録できるアーカイブを提供する。データはクラスタを超えて複製され、アーカイブがデバイスの失敗から保護されるのが好適である。ディスクまたはノードが失敗した場合、クラスタは、同一のデータの複製を管理するクラスタ内の他のノードにフェイルオーバーにより自動的に切り替える。

図示するクラスタは、ノード２０２と、一対のネットワークスイッチ２０４と、電力配分装置（ＰＤＵ）２０６と、任意で無停電電源装置（ＵＰＳ）２０８とを備える。ノード２０２は通常、１以上のコモディティサーバを備え、ＣＰＵ（例えば、Ｉｎｔｅｌ ｘ８６、好適なランダムアクセスメモリ（ＲＡＭ）、１以上のハードウェアドライブ（例えば、標準的なＩＤＥ／ＳＡＴＡ、ＳＣＳＩ等））、ネットワークインタフェース（ＮＩＣ）カードを備える。ネットワークスイッチ２０４は通常、ノード間のピアツーピア通信を可能にする内部スイッチ２０５と、各ノードへの外部のクラスタアクセスを可能にする外部スイッチ２０７とを備える。ＰＤＵ２０６は、総てのノードおよびスイッチに電力を供給するのに利用され、ＵＰＳは総てのノードおよびスイッチを保護するのに利用される。通常、クラスタは、公衆インターネット、企業のイントラネット、他のワイドエリアまたはローカルエリアネットワークなどのネットワークに接続可能である。エンドユーザは、従来のインタフェースまたはアクセスツールを用いてクラスタにアクセスする。したがって例えば、クラスタへのアクセスは、ＩＰベースのプロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、ウェブサービス等）により、ＡＰＩまたは他の既知または後に開発されるアクセス方法、サービスまたはツールを介して実行してもよい。クライアントアプリケーションは、標準的なＵＮＩＸファイルプロトコルまたはＨＴＴＰＡＰＩなどの１以上の種類の外部ゲートウェイを介してクラスタにアクセスする。アーカイブは、標準的なＵＮＩＸファイルプロトコル指向設備に設けられた仮想ファイルシステムを介して公開されるのが好適である。

環境をテストする実施例では、アーカイブクラスタアプリケーションは、クラスターのように（例えばイーサネットを介して）ネットワーク化された独立したノードの冗長配列（Ｈ−ＲＡＩＮ）上で動作する。各ノードは、図３に示すいくつかのランタイム要素で構成された分散型アプリケーションのインスタンス３００を動作させる。前述したように、本発明は、テストされるシステムのためにテストケースを生成する。ソフトウェア要素は、ゲートウェイプロトコル層３０２と、アクセス層３０４と、ファイルトランザクションおよびアドミニストレーション層３０６と、コア要素層３０８とを備える。ゲートウェイは、ＮＦＥ３１０およびＳＭＢ／ＣＩＦＳ３１２などの本来のファイルサービスや、ＷｅｂサービスＡＰＩを提供し、カスタムアプリケーションを作成する。ＨＴＴＰサポート３１４も提供される。アクセス層３０４は、アーカイブへのアクセスを提供する。一定のコンテントのファイルシステム（ＦＣＦＳ）３１６は、本来のファイルシステムを模倣し、アーカイブオブジェクトへの完全なアクセスを提供する。アクセス層３０４は、Ｗｅｂユーザインタフェース（ＵＩ）３１８と、ＳＮＭＰゲートウェイ３２０とを備えている。Ｗｅｂユーザインタフェース３１８は、ファイルトランザクションおよびアドミニストレーション層３０６内のアドミニストレーションへの双方向のアクセスを提供する。ＳＮＭＰゲートウェイ３２０は、アドミニストレーションエンジン３２２へのアクセスするストレージ管理アプリケーションを提供し、クラスタの活動を安全に管理および制御する。アドミニストレーションエンジンは、システムおよびポリシーイベントを含むクラスタ活動を監視する。

また、ファイルトランザクションおよびアドミニストレーション層３０６は、要求管理処理３２４を備えている。要求管理３２４は、（アクセス層３０４を介した）外部からの要求や、コア要素層３０８内のポリシー管理３２６からの内部要求を管理する。ポリシー管理３２６に加え、要素は、メタデータ管理３２８と、ストレージ管理３３０の１以上のインスタンスとを備えてもよい。所定のノードのストレージ管理３３０は、物理的なストレージデバイスを管理する責任を有する。要求管理３２４は、システム内の他の要素と相互通信することによりアーカイブアクションを実行するのに必要な一組の処理を実行する責任を有する。メタデータ管理３２８は、各ノードにインストールするのが好適である。総合的に、クラスタ内のデータ管理は、分散型データベースのように動作し、アーカイブオブジェクトを管理する。ストレージ管理３３０は、分散型アプリケーション内の総ての他の要素が利用可能なファイルシステム層を提供する。これは、ノードのローカルファイルシステム内のデータオブジェクトを格納する。また、ストレージ管理３３０は、システム情報、データの完全性のチェック、およびローカルな構造に直接的にトラーバースする能力を提供する。図３に示すように、クラスタは、通信ミドルウェア層３３２およびＤＮＳ管理３３４を介して内部および外部の通信を管理する。アプリケーションインスタンスは、オペレーティングシステム３３６に基づいて動作する。

クラスタの主な責任は、ディスク上の非制限的な数のファイルを確実に格納することである。前述した自動テストフレームワークは、動作中の処理環境またはテスト設備またはラボラトリ内のクラスタを用いるのに利用される。したがって、一のテストシナリオでは、自動テストフレームワークは、（局所的あるいはコンピュータネットワークを介して）テストラボラトリ内のノードを利用することができ、ＲＡＩＮまたはＳＡＮクラスタを設定する。この処理では、フレームワークは、自身の本来の分散ソフトウェアを使用し、または外部モジュールを利用して様々な構成のクラスタをインストールする。これは、クラスタの状態を確認し、テスト群を実行する。テストはクラスタを用いるが、実際には、自動テストフレームワーク自体の問題ではなく、テストハーネスとしてのみ機能する。具体的には、自動テストフレームワークは、所定のクラスタを自動的に割り当て、インストールし、検証し、割り当てられたクラスタに行われるテストのための「クリーンルーム」環境を提供し、これは、テスト中のクラスタのスナップショップを取得し、ダンプログおよびデータベースイメージが好適である。しかしながら、フレームは所定のテストまたはテスト群の方法に関わりなく、テストの成功または失敗を容易に記録する。したがって、フレームワークは通常、所定のテストと連動せず、テストは通常、フレームワークと通信し、テストの結果をパスする。フレームワークは、テストの結果を記録および格納するが、テストスクリプトは、所定のテスト群を損なうことなく、クラスタを損傷あるいは変更する場合がある。このような深刻な損傷または変更は、例えば、ノードのドロッピング、データベースの破損、データの破損等を含む。フレームワークは、テスト群の次のテストが実行される前に、「クリーンな」環境を再インストールすることによりこのような破壊または変更の問題に取り組む。実際には、多くのインスタンスにおいて、肯定的にフレームワークにフラグを付してテスト中にクラスタを再インストールし、クラスタが、各テストのために、実際に（例えば、総てのゲートウェイがアップであり機能的であり、総てのクラスタが健全であり、所望のソフトウェアがインストールされ、動作し、パッチされることを保証することにより）安定的な「クリーンルーム」環境で動作することが所望される。

したがって、本発明の目的によると、所定のテスト群のテストは、任意のフレームワークの制御機能（フレームワークまたはフレームワークのデーモンを備えるオブジェクト、方法、クラス等）を直接的または間接的に参照しない。実際には、フレームワークは、テストされる基本システムとテスト自体から抽出される。この構造は、中央制御または管理スキームを取り除き、従来技術にはない利益を提供し、クローズシステムまたはテストが特定のテスト環境のために記述されたシステムのように動作する。テスト群の各テストは独立しており、任意の順序で動作できる。

前述したように、フレームワークデーモンは、多数のサポートツール、すなわち、要求される様々な機能を提供する実行可能なモジュールを有することが好適である。クラスタの例では、フレームワークデーモンは、テスト群（またはバッチ）を動作させ、結果をデータベースに記録し、ノードイメージまたはログをウェブでアクセス可能なローカルマシンのウェブサーバ上のディレクトリに格納できる。デーモンは、総ての例外、失敗、クラッシュ等を電子メールの受信者のターゲットセットに電子メールを送信し、またはこのような情報をバグトラッキングシステムにエクスポートする。したがって、フレームワークは、高度に構成され、テスト言語に依存しないハーネスを動作させる機能的なクラスタレベル回帰（regression）テストを提供する。

また、フレームワークはホワイトボックステストを実施できる。一組のホストまたは単一のホスト上で実施可能な任意のテストは、自動テストフレームワーク内で実施できる。前述したように、フレームワークの利点の一つは、動作する任意のクラスタをテストできるのに十分な寛容性または順応性があることである。クラスタの大きさを拡張するテストが存在し、これらは、クラスタを修復し、要素テストドライバ、インストールシステム自体をテストするテストである。フレームワークは、テストの方法に拘わらず前述したこの適応性を提供する。したがって、所定の品質保証のエンジニアまたは開発者がハーネス内に組み込むものに関する理論上の制限はない。

ここで図４を参照すると、ブロック図は、例えば、分散クラスタアプリケーションを有を用いて使用する自動テストフレームワークの特定の実施例を示している。図示するように、フレームワークは、デーモン形式のラッパ（wrapper）を有するツールボックスである。これは拡張可能なフレームワークであり、機能的なクラスタレベルのテストを提供し、好適には共通の拡張可能な簡単なツール、日々のクラスタの管理で利用できるツールで作られる。

図４に示すように、本実施例のフレームワーク４００は、２つの層、フレームワーク層４０２およびツール層４０４を備えている。フレームワーク層４０２は、論理、モジュール、それ自体を「知る」ためにフレームワークが要するスクリプトまたはデータベース、クラスタ（およびこれらのノード）、および所望のテスト（これらのテストの実行）を備えている。対照的にツール層４０４は、クラスタの非中央的な管理を容易にし、限定ではないが、ビルドインストレーション、ログ管理、クラスタクリーニング、データベースクエリ等を含む様々なタスクを実行するツールを備える。ツール（または少なくともこれのらの一部）は、インタラクティブではなく、自動および再利用可能であり、中央管理または制御を要しない。

図４を参照すると、デーモン４０６は、個別の論理モジュールを用いることにより、クラスタを割り当て、インストールし、検証するネットワークアクセス可能なスクリプトである。前述したように、このデーモンは、ターゲットクラスタに対する所定のテスト群を実施すべく到来する要求を受ける。結果ハンドラモジュール４０８は、テスト中に生成されたデータを管理する。したがって、例えば、デフォルトの結果は、結果ディレクトリ内のレコードであり、これは、日／時間／群／テスト名がキーにされることが好適である。各テストの結果は、フラットなテキストファイル形式で格納され、現在の結果用のデータベースシステムにアップロードされる。動作が終了した後、結果のアップロードフラグがイネーブルである場合には、デーモン４０６はこれらの結果を結果データベースにアップロードする。結果ハンドラモジュール４０８は、別のシステムをアップロードするために、ＣＳＶ形式の結果を電子メールで送り、この結果をデータベースに送り、またはアクセスの可能性を最大にすべくディスク上のファイルに結果を格納する。テスト動作モジュール４１０は、最終的に実際のテスト群の責任を有するスクリプトである。このスクリプトは、テストに必要な総ての詳細を扱う（例えば、マウントポイントの設定、リソースの初期化等）。このモジュールは、非ブロック／タイムアウト方法でテストを実行するのが好適である。これはテストが継続し、または終了しないことを期待し、これらのテストを監視し、必要に応じて終了する。マスタテストシステムモジュール４１２は、テスト動作モジュール４１０を使用し、マスタレベル群（個別の群とは反対に、フレームワーク群）を生成し、システムレベル分類のためのバッチシステムとして利用される（例えば、長いバーンイン（burn in）、クイックスモーク、性能等）。コードレポジトリ同期モジュール４１４は、総てのレポジトリ（例えば、必然的）リフレッシュを処理し、ソース制御サーバからコードビルドを取得する責任がある。データベースモジュールは、所望のテストがどこに存在するのか、これらのテストを更新するのかしないのかをモジュールに伝える。テストを更新すべき場合、このモジュールは、これらのテストをレポジトリから直接的にダウンロードする。コードレポジトリ同期モジュールは、ローカルコピーを有するか否かに関わらず、所定のテスト群のファイルを同期させる。したがって、ソース制御システムはマスタコピーと見なされ、対照的にフレームワークはローカルコピーを信用しない。データベース更新モジュール４１６は、任意および総てのデータベース接続性を扱う。このモジュールは、クラスタに関する情報を取得し、この情報をデーモンに提供するのに利用される。リフレッシュモジュール４１６はまた、所望のテスト／群情報を取得するのに利用される。テスト情報データベース４１８は、テスト群の各テストに関する情報と、実行すべきこのようなテストの所望の情報を備えるデータベースである。クラスタ情報データベース４２０は、
フレームワークが用いられる適切な情報を備えてる。このデータベースは、任意のテストが動作する前に（または所定のテスト群が実施される前に）ポーリングされ、所望の情報を発見する。

ツール層４０４要素は、層のツールにラップされる分散コマンドハンドラモジュール４２２を備える。モジュール４２２は、ＳＳＨ接続を介してアクセス可能であり、ツールが、インタラクティブではなく、またはスクリプトあるいはオープンＡＰＩを介してクラスタと交信する。分散コマンドハンドラモジュールへのアクセスは、認証を要求するのが好適である。ログ交換（rotate）または「イメージャ（imager）」モジュール４２４は、システムログをダンプし、クラスタノードのログのエラーメッセージをチェックし、テストが終了した後に、クラスタノードを超えてデータベースのイメージを作成する。デーモンマスタモジュール４２６は、開始および終了などのクラスタのデーモンに対する粒度の細かい制御を可能にするスクリプトである。データベーススナップショットモジュール４２８が提供され、クラスタを介して展開するデータベースのスナップショットを取得し、これらのスナップショットをローカルマシンに提供する。スナップショットモジュール４３０は、実際にクラスタのイメージを作成するツールであり、ログ回転モジュールにより動作し、所定のテスト群の様々なテスト動作中に、総てのクラスタノードからログを取得する。スナップショットモジュール４３０はまた、クラスタの総てのノードの現在のデータベースのイメージを取得し、これらのファイルをローカルマシンにコピーし、これらをテスト／群の動作のログとともに格納する。スナップショットモジュールはまた、クラスタの完全性を検証する。ビルドインストーラモジュール４３２は、分散コマンドハンドラモジュールを利用して、ターゲットクラスタを介して規定のビルドをインストールするスクリプトであり、任意および総ての所望の構成のスクリプトを含む。モジュール４３２は、コンフィグレーションデータベースの情報に基づいて、所望の値を自動的に決定するスクリプトとして実現してもよい。クラスタクリーンモジュール４３４は、非インタラクティブにターゲットクラスタを掃除または整理し、ディスク、データベース、ログ、ファイル等をフォーマットする。クラスタ状態監視４３６は、動作するクラスタの完全性を検証するスクリプトであり、有効／無効処理、スワッピングの利用法等をチェックする。任意の時点で、クラスタ状態監視４３６がコールされ、クラスタをチェックする。最後に、ゲートウェイマウント検証モジュール４３８は、様々なクラスタゲートウェイの状態を検証し、ゲートウェイに対する様々なアクセス方法を実行するために用いられ、したがって、このモジュールは、所定のクラスタ（および当該クラスタ内のノード）の可用性を検証するために動作する。このモジュールは、テストランナモジュールのマウントシステムとして利用し、所望のリソースを実装するためにコールしてもよい。

図４に示すツールは、様々な他のツールおよびモジュールがフレームワークにより使用されるように、必ずしも包括的または排他的ではない。さらに、ツール層と機能／デーモン層との間の図４の線は単なる例示であり、本発明の範囲を限定するものではない。前述したように、フレームワーク（どのように実装されているかに関係なく）は、テストを容易に実施する単なるプラットホームであり、処理する「クリーンルーム」を提供し、テスト群の進捗のようなクラスタの状態を保証する。典型的な実施例では、自動テストネットワークは、コモディティハードウェアおよびＬｉｎｕｘオペレーティングシステムを動作させるマシン上で動作する。これは限定的ではないが、前述したように、デーモンは所定のマシン上で実行され、図４に示す１以上のモジュールは、同一のマシンまたは１以上の他のマシン上で動作してもよい。したがって、フレームワークは、Ｓｏｌａｒｉｓ、ＨＰＵＸ、ＡＩＸ、ＩＲＩＸ、ＯＳ／Ｘ、ＷｉｎＸＰ、Ｗｉｎｄｏｗｓ２００等上で動作するクライアントなどの非Ｌｉｎｕｘベースのクライアントを割り当ておよび利用することができる。したがって、代替的な実施例では、フレームワークは、所定のテストのプラットホームを検出し、この検出に基づいてテストの実行を、それをサポートできる特定のプラットホームに送る適切な機能を有する。

以下は、
［root@client/home/daemon］#./daemon -s risfs -c clusterfoo -b
http:pathbuildrpm/foo.rpm --refresh --report
などの実行要求を受信した場合に、自動テストフレームワーク処理がどのように動作するのかを示した例である。
この要求により以下の処理が行われる。
・デーモンの動作
・ｒｉｓｆｓテスト群の実行
・ｃｌｕｓｔｅｒｆｏｏに対する
・ｂｕｉｌｄ ｆｏｏにより
・およびＰｅｒｆｏｒｃｅからテストを更新し、最新のテスト群を取得する
・結果をデータベースに報告
したがって、要求に応じて、フレームワークは、デーモンラッパ（daemon wrapper）を実行し、クラスタ情報を取得し（クラスタが動作しているか、あるいはビルドしているかチェックし、必要に応じてクリーニングする）、規定のビルドをダウンロードし、ビルドをクラスタに展開し（インストール）、クラスタを開始し、クラスタの状態をチェックし、データベースから所望のテストを取得し（必要に応じてコードレポジトリからテストを同期させ）、必要に応じてローカルテスト設定を実行し（例えば、マウントポイントを生成し）、テストを実行し、テスト中のシステムのイメージを作成し（完全性のチェック、ログの取得など）、テストが終了した場合にシャットダウンし、テストの結果およびイメージを報告／公表する。

図５は、自動テストフレームワーク（ＡＴＦ）の別の図を提供する。この実施例では、ＡＦＴサーバ５００ａ（例えば、サーバ５００ａ乃至ｎのセットの一つ）は、ＡＴＦスケジューラーを実行する。ＡＴＦサーバ５００ａは、マシン５０２で動作するＡＴＦクライアントにジョブを発行する。ＡＴＦクライアントはデーモンを動作させる。この例では、デーモンは、順に選択された（または最新の）ＱＡビルドおよび必要なテストツールをビルドサーバ５０６からダウンロードする命令をＡＴＦサーバ５００ａ（一のサーバグループ内の他のサーバの一つ）に発行し、ターゲットクラスタ５０４を特定し（例えば、利用可能なクラスタのデータベースから）、ターゲットクラスタ５０４にビルドをインストールし、インストールを検証する。デーモンの制御の下、サーバ５００は、クラスタに対する１以上のテスト群をダウンロードし、動作させる。この特定の例では、これは、ＡＦＴサーバ５００にスクリプト実行ルールのための中央データベース５０８をチェックさせ、選択されたスクリプトをソースサーバ５１０からフェッチし、スクリプトを実行することにより実現される。次に、ＡＴＦサーバ５００は、結果を１以上の特定のユーザ、または通常は、メーリングリストに送信する（例えば、電子メールサーバ５１２を用いて）。図６は、所定の夜間テストが実行されたことを示し、システム、その構成、テストの結果等に関する情報を示す典型的な電子メールの一部である。また、電子メールは、システムのイメージデータを含む完全なテストデータへのリンクを備えていることが好適である。リンクを選択することにより、ユーザは、詳細な結果を直接的に参照できる。電子メールの結果は、前述したように、ウェブサーバ５１４に保持され、あるいはディフェクトトラッキングシステムに供給してもよい。一実施例では、テストは、様々なサイズおよび構成の専用クラスタに対し周期的、例えば夜間に実施される。

前述したように、図示するマシンは、異なるハードウェア、異なるソフトウェア、または異なるハードウェアおよび異なるソフトウェアを動作させてもよい。この結果、フレームワークは拡張性が高くなる。これは順応性があり、容易に拡張でき、テスト言語やクライアントプラットホームに依存しない。この実装により、フレームワークが、任意の言語の任意のテストを実行できる。

以下は所定のテストのためにデータベースに格納される情報の種類を示している。
・テスト群
・テストサブ群
・テスト名／コード／シリアル
・テスト位置（必然的）
・実行に必要なテストフラグ（すなわち、-n $testnum, -s $port等）
・これはファイルテストか？（すなわち、マウントポイントが必要か）
・ｔｒｕｅの場合
・ 所定のマウントが必要か？
・ ｎｆｓマウントが必要か？
・ 両方必要か？
・ これはｈｔｔｐテストか？
・ ｔｒｕｅの場合
・ どれだけのｈｔｔｐ ｕｒｌが共有されたか？
・ループエラーか？
・エラーのエラー回数（最大ｎ）

処理フロー図および前述の説明は、本発明の特定の実施例により実行される特定の順序の処理を示しているが、このような順序は例示であり、代替的な実施例は、異なる順序で実施され、特定の処理を組み合わせ、特定の処理を重複させることができると理解すべきである。所定の実施例に対する明細書における参照は、示されている実施例が、特定の機能、構造、または特徴を備えるが、総ての実施例が、特定の機能、構造または特徴を必ずしも備えるわけではないことを示している。

本発明は方法または処理のコンテキストで説明されているが、本発明は、ここに記載された処理を実行する装置に関する。この装置は、所望の目的のために特別に構成してもよく、コンピュータに格納されたコンピュータプログラムにより、選択的に駆動または再構成される汎用的なコンピュータを備えてもよい。このようなコンピュータプログラムは、限定ではないが、光学ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、読出し専用記憶装置 （ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気または光学カード、または電子命令を格納するのに好適な任意の種類の媒体を含む任意の種類のディスクなどのコンピュータが読み取り可能な媒体に格納してもよく、これらの媒体はコンピュータシステムバスに接続される。前述したように、本発明の所定の実施例は、Ｌｉｎｕｘなどのオペレーティングシステムを動作させる標準的なハードウェアプラットホーム上で動作する所定のプログラミング言語で記述されたソフトウェアである。

本システムの所定の要素が個別に説明されているが、当業者であれば、所定の命令、プログラムシーケンス、コード部分等において一部の機能を組み合わせ、または共有してもよいことは理解できるであろう。

我々の発明を説明したが、我々が請求する発明は請求項の記載の通りである。

図１Ａは、本発明の自動テストフレームワークの動作を示した処理フロー図である。 図１Ｂは、本発明の自動テストフレームワークの動作を示した処理フロー図である。 図１Ｃは、本発明の自動テストフレームワークの動作を示した処理フロー図である。 図２は、テストされる典型的なシステムの単純化した図であり、分配されたソフトウェアアプリケーションインスタンス実行する一組のノードを備え、自動テストフレームワークは、ノード対しテスト群を実施するのに用いられる。 図３は、図２のシステムの所定のノードで実行されるアーカイブクラスタアプリケーションの様々な要素の高いレベルの図である。 図４は、図２および３に示すクラスタを実行するのに利用される自動テストフレームワークの好適な実施例のブロック図を示している。 図５は、企業環境における自動テストフレームワークの一実施例を示している。 図６は、所定のテスト群が実行された後に、自動フレームワークにより自動的に生成される結果用の電子メールを示している。

Claims (32)

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. 請求項２２に記載の方法において、前記情報が、所定のテストが成功または失敗したかを含むことを特徴とする方法。
27. 請求項２２に記載の方法において、先行するテストに関して前記システムあるいはシステムが有する一部の要素が破損または変更された場合、あるいはコンフィグレーションパラメータの設定に応答して、前記リソースを選択的に再び割り当て、インストールし、および検証するステップが実行されることを特徴とする方法。
28. 請求項２２に記載の方法において、前記ステップのうちの少なくとも一つが、所定のテストの実行と独立して実行されるデーモンの制御下で行われることを特徴とする方法。
29. 請求項２２に記載の方法において、前記所定のリソースが、所定のハードウェア、所定のソフトウェア、あるいは所定のハードウェアおよび所定のソフトウェアの組み合わせのうちの一つを含むことを特徴とする方法。
30. 請求項２２に記載の方法において、データベース、ウェブサーバ、電子メールリスト、またはディフェクトトラッキングシステムのうちの少なくとも一つを含むレポジトリに前記テストの実行結果に関する情報を出力することを特徴とする方法。
31. 請求項２８に記載の方法において、前記デーモンが前記システムで実行され、前記テスト群の少なくとも一つのテストが第２のマシンで実行されることを特徴とする方法。
32. 請求項３１に記載の方法において、前記システムおよび前記第２のマシンが、異なるオペレーティングシステムを実行することを特徴とする方法。

Images