JP5437493B2 - ウェブ・アプリケーションを自動的にテストする方法およびシステム - Google Patents

Description

本発明は、全般的に、ソフトウェア・アプリケーションの開発に関し、特に、ウェブ・アプリケーションをテストする方法に関する。

ウェブ・アプリケーションの大きな課題は、ウェブ・インターフェイスのテスト自動化の効果的な手法を発見することである。この問題は、ｗｅｂ２．０（例えばＤｏｊｏなど、ＡＪＡＸまたはＪａｖａＳｃｒｉｐｔフレームワークなど）の新技術を用いて構築されたウェブ・インターフェイスとより大きな関連がある。ｗｅｂ２．０アプリケーションのウェブ・ページは、単に動的であるだけではなく、多数のオブジェクト指向言語のＤＯＭ要素が複合した結果の、非常に複雑なアプリケーションである（ＤＯＭは、ドキュメント・オブジェクト・モデル（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）であり、ＨＴＭＬページの表現およびＨＴＭＬでのオブジェクト管理のための、ハードウェアおよび言語独立モデルである）。クライアント・サイド・ウェブ・アプリケーションを作成するためにバックエンドと対話してＡＪＡＸ（ａｓｙｎｃｈｒｏｎｏｕｓ ＪａｖａＳｃｒｉｐｔ ａｎｄ ＸＭＬ：非同期ＪａｖａＳｃｒｉｐｔおよびＸＭＬ）技術を実装し、さらにクライアント・サイドからの外観の変更を可能にするためにＣＳＳスタイル・シートを適用するＪａｖａＳｃｒｉｐｔ（ＪａｖａＳｃｒｉｐｔは、ＳＵＮ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．、またはその子会社の米国および他の国々における商標または登録商標）コードによって、各ＤＯＭ要素を動的に構築可能である。さらに、ＤＯＭ要素を作成するためのコードは、多数のポイントに散在し、さらに、単一の機能性を実装するために別個に書かれるウィジェット（ｗｉｄｇｅｔ）（ＡＪＡＸフレームワークを用いて作成される）によって生成されることもあり得る。

単一の機能性、単一のウィジェット・クラスをテストする単体テスト・スイートのシステムを実装することのみではなく、ウィジェットによって生成されるＤＯＭ要素、およびＤＯＭ要素を生じさせる他のパーティによって生成されるＤＯＭ要素間の実際の対話をテストすることも主な問題である。

ウェブ・アプリケーションをテストする従来技術のツールは、ウェブ・ページもしくはアプリケーションの「外部の」外観のみに基づくか、またはたとえＤＯＭ要素を認識しても、アプリケーションの内部は完全に見落とす。逆に、そうしたソフトウェアはホスティング環境に強く依存し（例えば、これらアプリケーションはブラウザで動作する）、それ自体の「外の」挙動にアクセスして駆動する手段がないことが理由で、アプリケーションにはこの重要な領域のテストを強制することができない。そのようなウェブ・アプリケーションを自動的にテストすることは、今日の課題である。

米国特許出願公開第２００４／００２５０８３（Ａ１）号は、プログラムがその機能性をテストできるようテスト・コードをプログラムに埋め込む概略の考えを記載している。しかし、この発明の広い範囲にもかかわらず、当該方法を使用して、ブラウザおよびそれをホストするオペレーティング・システムのコンテキストにおいてアプリケーションの内部を完全にテストすることの問題を解決することはできない。環境の違いに依存するアプリケーションの一部コード部分は、テストすることができない。さらに、そうした違いのみではなく、そうした違いが実行をもたらし得る異なるコード・パスにも依存するアプリケーションの一部コード部分もテストされない。例えば、ウェブ・アプリケーションは、サポートされるブラウザそれぞれ、例えばＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎの米国、他の国々、またはその両方における商標）、Ｆｉｒｅｆｏｘ（Ｆｉｒｅｆｏｘは、Ｍｏｚｉｌｌａ Ｆｏｕｎｄａｔｉｏｎの登録商標）、Ｏｐｅｒａ（Ｏｐｅｒａは、Ｏｐｅｒａ Ｓｏｆｔｗａｒｅ ＡＳＡの商標または登録商標のいずれか）などにおいて別々にテストされなければならない。しかし、テストのために、各ブラウザがもたらし得る違いを無視してソフトウェア関数に対する直接の呼び出しのみを考慮に入れるテスト・コードを用いるのでは信頼性がない。

ブラウザおよびそれをホストするオペレーティング・システムのコンテキストにおいてアプリケーションの内部をテストするために、ウェブ・インターフェイスのページにおけるユーザ入力をシミュレートするコードを、ウェブ・インターフェイス・コードに組み込む方法が必要である。

したがって、ウェブ・インターフェイスのページにおけるユーザ入力をシミュレートして、ブラウザおよびそれをホストするオペレーティング・システムのコンテキストにおいてウェブ・アプリケーションのウェブ・インターフェイスの内部データ構造（ｉｎｔｅｒｎａｌ ｄａｔａ ｓｔｒｕｃｔｕｒｅ）を検証する、自動テスト方法を得ることが、本発明の目的である。

この目的は、請求項１によれば、テスティング・コンピュータ（ｔｅｎｓｔｉｎｇ ｃｏｍｐｕｔｅｒ）のウェブ・ブラウザ内で動作しているウェブ・アプリケーションを自動的にテストする方法を用いて達成され、ウェブ・アプリケーションは、テスト・コードを組み込まれており（４００）、前記方法は、
−ユーザ入力をシミュレートするようＨＴＴＰサーバに求める、ＨＴＴＰサーバへのメッセージを、ウェブ・アプリケーション内で実行されているテスト・コードから、ウェブ・アプリケーション内で定義されているＡＰＩを介して送信するステップ（４１０）であって、前記ユーザ入力は、ウェブ・アプリケーション内で動作しているテスト・コードに関係する、ステップ（４１０）と、
−ＨＴＴＰサーバがメッセージを受信するステップ（４２０）、メッセージに従い少なくとも１つのシステム・イベントによってユーザ入力をシミュレートするステップ、およびそれをウェブ・ブラウザに提供するステップと、
−シミュレートされた該少なくとも１つのシステム・イベントを、ウェブ・ブラウザが処理するステップ（４３０）であって、該少なくとも１つのシステム・イベント自体がウェブ・アプリケーション内の或るコードの実行をトリガする、ステップ（４３０）と、
−該少なくとも１つのシステム・イベントによるウェブ・アプリケーション内の或るコードのトリガの結果の妥当性を、ＪａｖａＳｃｒｉｐｔおよびＤＯＭオブジェクトを含むウェブ・アプリケーションの内部データ構造を検査することによって、ウェブ・アプリケーション内のテスト・コードが確認するステップ（４４０）と、
を含む。ウェブ・アプリケーションの内部データ構造は、ウェブ・ページから可視であるＨＴＭＬ要素、ならびに内部カウンタまたはその他の可能な変数およびオブジェクトを含む。

本方法は、シミュレートされたユーザ入力の後にデータ構造を検査することによってアプリケーションのデータ構造をテストすることも可能にする。本方法は、シミュレートされたユーザ入力が発生した後のオブジェクト・ステータスと、保存されているモデル・オブジェクト・ステータスとを比較することによって、アプリケーションの内部データ構造を確認することも可能にする。

オブジェクトは、ＨＴＭＬ、ＤＯＭ、またはＪａｖａＳｃｒｉｐｔオブジェクトであってもよい。自動テスト・システムは、ＨＴＴＰサーバと、テストされるシステム入力に対応するシミュレートされたシステム・イベントを生成するコードとを含む。

ウェブ・アプリケーションを完全にテストするために、本発明の本方法は、何らかのテスト・コードを書いてそれをアプリケーションに埋め込むことを含むだけではなく、ウェブ・アプリケーションに、ユーザとウェブ・インターフェイスとの実際の対話を再現する能力を含む「外の」環境へのアクセスも与える。この方法は、人間のユーザまたは或る外部イベント・ソースにより入力がもたらされているかのように、入力を受信することができるよう、外部入力をシミュレートできるようにする。このようにして、ホスティング環境も、イベントを処理して、同じくアプリケーション挙動に直接作用するホスティング環境自体のデータ構造を更新することができるようになる。このシステムが整備されなければ、ソフトウェア機能性全体をカバーできるテストはない。

このウェブ・アプリケーションは、外部サービスを用いて「外」からそれ自体と対話する能力を有する。サービスは、ブラウザおよび外部システム（ディスクなど）を制御し、特別にエンコードされたＵＲＬを用いたＨＴＴＰ接続によってサービスをウェブ・アプリケーションに提供する。その結果として、ウェブ・アプリケーションは、提供されるサービスを使用して、その内部状態を「外」から操作および制御するが、これは、現在のテスト自動化システムでは、通常は不可能である。

以下の方法およびシステムは、人間のユーザ入力を再現およびシミュレートして現在のテスト方法論の制限を打開し、このシミュレーションを使用してその内部データ構造およびアルゴリズムを検証する。本方法は、ウェブ・ページ自体の中のＪａｖａＳｃｒｉｐｔコードからユーザ入力によって生成されるシステム・イベントを呼び出し、ウェブ・インターフェイスに対する（したがって例えばオブジェクト・モデル要素、ＤＯＭ要素に対する）変更を生じさせる。変更がＤＯＭ要素に反映されると（ユーザ・イベント・リクエストによって）、ＪａｖａＳｃｒｉｐｔコードは、期待される値と比較して内部データ構造のステータスを確認できる。

本発明の方法は、以下の利点を提供する：
−アプリケーション・ウェブ・ページ内のすべてのＤＯＭ要素をテストすることによって、顧客シナリオを再現するＤＯＭ要素のあらゆることをテストできる。このソリューションは、他のタイプの製品ではカバーできない、上記の高度な例のセクションに関する興味深いテスト・ケースをカバーできるようにする。
−ウェブ・ページを、ページ自体の中および外でテスト可能である。
−ＤＯＭ確認に基づき、もしくはＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪａｖａＳｃｒｉｐｔオブジェクト表記法）のことであり、文字列を用いてオブジェクトを表現する簡素な形式である）オブジェクト比較により、またはその両方で、検証ポイントを確認する方法。
−このソリューションは、ＤＯＪＯフレームワークに適用されるだけではなく、ウェブ・ページのＤＯＭ要素を生成するために使用されるすべての技術に関して活用できる。
−本発明の方法は、テスト・スイートおよびアプリケーションに使用される言語がＪａｖａＳｃｒｉｐｔと異なっても実装可能である。言語は、ブラウザにより理解可能であればよい。

従来技術の自動テスト製品および方法論に関して、特にウェブ・アプリケーション用のものについては、現在最先端のものは多数の機能を提供しているが、結局のところ、テスト結果は、アプリケーションの「出力」と、正確であることが分かっている何らかのテンプレートとを比較することによって取得される。ウェブ・アプリケーションに関して出力とは、基本的に、ウェブ・アプリケーションが生じさせる、または変更するＨＴＭＬページであり、すなわち言い換えると、そのＤＯＭ表現である。本発明の方法を用いると、ウェブ・アプリケーションは、「外の」環境にアクセスでき、単純なコード・インストルメンテーションではできないと考えられる実際の挙動（人間の入力を含む）をシミュレートできる。プログラムの「外観」のみを検査できるツールは、内部構造を検査する能力を欠く。

本発明のソリューションを実装できるウェブ・アプリケーションの通常のコンテキストを示す。 ウェブ・アプリケーションの通常のコンテキストにおける好適な実施形態の方法の実装を示す。 好適な実施形態によるシミュレートされたイベントが横断するウェブ・アプリケーション環境の図である。 好適な実施形態による本発明の方法の概略のフローチャートである。

図１は、本発明のソリューションを実装できるウェブ・アプリケーションの通常のコンテキストを示す。ウェブ・アプリケーションの通常のコンテキストは、ユーザ・ワークステーション（１０５）のブラウザ（１１０）で動作しているウェブ・クライアント・アプリケーション（１１５）を含む。ブラウザは、ユーザのワークステーションのオペレーティング・システムのファイル・システム（１２０）を使用する。ウェブ・クライアント・アプリケーションは、ウェブ・アプリケーション・サーバ（１００）から、ウェブ・アプリケーション・サーバがリモートであればネットワークを介してダウンロードされたものである。ウェブ・アプリケーションは、ＪａｖａＳｃｒｉｐｔで書かれていてもよい。ユーザは、ブラウザによって生成されるウェブ・ページを介してアプリケーションと相互作用する。ユーザ入力は、システム・イベントを生成する、ウェブ・ページ・フィールドに記入されるデータであってもよい（例えばキーボードまたはマウスから）。

図２は、ウェブ・アプリケーションの通常のコンテキストにおける好適な実施形態の方法の実装を示す。テスティング・ホスト（２４０）上で動作するウェブ・アプリケーション（１１５）としての、ブラウザにより理解可能な言語、例えばＪａｖａＳｃｒｉｐｔで書かれたテスト・スイート。ウェブ・テスト自動化システム（２００）は、テスティング・ホストで動作しているウェブ・アプリケーション（１１５）にテスト・サービスを提供する。テスト・サービスは、コマンドを受信するＨＴＴＰサーバ（２１０）、指定されたシステム・イベントを生成するシステム・イベント・ジェネレータ（２１５）、およびテスト・コンピュータがリモートである場合にテスト・スイートが動作するホストにイベントを送信するリモート・イベント・ディスパッチャ（２２５）の３つのサブシステムを含む。こうしたサブシステムは、ソフトウェア・プログラムとして実装されてもよい。リポジトリ（２２０）は、アプリケーションのステータスを表現するシリアル化されたオブジェクトまたは他のデータを読み込み／保存するためにテスト・サービスのサブシステムによって使用される（ＪＳＯＮを、リポジトリに記憶される線形化オブジェクト・エンコーディングの例とすることができるであろう）。

テスティング・ホストで動作しているウェブ・アプリケーションでは、ＪａｖａＳｃｒｉｐｔ ＡＰＩが、ＪａｖａＳｃｒｉｐｔテスト・コードのセルフ・パイロット（Ｓｅｌｆ−Ｐｉｌｏｔｉｎｇ）を可能にする。ＪａｖａＳｃｒｉｐｔ ＡＰＩのセルフ・パイロット・コマンド（２３５）は、ブラウザ（ウェブ・アプリケーション）からのＪａｖａＳｃｒｉｐｔコードと、テスト・サービスとの通信を可能にする。ブラウザ・スタータ（２３０）はオプションであり、テスティング・ホストのＵＲＬでブラウザを立ち上げるためのものである。使用される場合、これは、リモート・イベント・ディスパッチャ（２２５）からイベントを受信する。リモート・イベント・ディスパッチャ（２２５）自体はシステム・イベント・ジェネレータ（２１５）からイベントを受信しており、それをブラウザに送る。ブラウザ・ランチャがない場合、ブラウザは、ウェブ・アプリケーション内のテスト・コード実行より前に起動されるため、ブラウザはシミュレートされたシステム・イベントを直接受信できる。ブラウザ（１１０）は、テスティング・ホスト上で同イベントを受信して処理する。ウェブ・アプリケーション内では、テスト・スイート・コード（ｈｔｍｌ／ＪａｖａＳｃｒｉｐｔ／Ｄｏｊｏコードを含むウェブ・ページ）が、オブジェクトをテストするコードを含み、ＪａｖａＳｃｒｉｐｔ ＡＰＩのセルフ・パイロット・コマンド（２３５）を使用して検証ポイントを確認し、テスト・サービスを提供するＨＴＴＰサーバ（２１０）へ向けたアクションをトリガする。

なお、テスト自動化システムおよびテスティング・サーバのコンポーネントを含むテスト・システム全体が、単一のコンピュータ上に存在することが可能であろう。テスト自動化システムおよびテスティング・サーバが単一のコンピュータ上に存在するこうした場合には、リモート・イベント・ディスパッチャ（２２５）を備える必要はなく、リポジトリはウェブ・アプリケーションのローカルにある。

ＪａｖａＳｃｒｉｐｔ ＡＰＩは、ＨＴＴＰサーバとの通信を確立して、ウェブ・アプリケーションがイベント・コマンドを送信できるようにする。サービスは、コマンドを得て、ブラウザ（常に一番上のウィンドウとして動作する）がキャッチするキーボードまたはマウス・イベントを、システム・イベント・ジェネレータを介して生成し、イベントおよびウェブ・ページの変更が、ユーザ自身により引き起こされたかのように発生する。この時点で、テスト自動化コードは、それ自体の実行をウェブ・アプリケーション内で続ける。

例えばＤＯＭ確認などのウェブ・ページ・オブジェクト確認に基づく検証ポイントの例は、以下のとおりである。

ウェブ・インターフェイスがボタンを提供すると仮定する。ユーザがボタンをクリックすると、新しいパネルが表示される。この例では、テスト自動化のＪａｖａＳｃｒｉｐｔコードは次のとおりであるべきである：ＪａｖａＳｃｒｉｐｔが、上記のボタンの要素上でのマウスのクリックをリクエストする。続いて、サービスが、ＪａｖａＳｃｒｉｐｔ ＡＰＩを介してコマンドを受信し、関係するシステム・イベントを生じさせる。イベントが受信されると、新たなパネルを含むよう新たなコンテナ構造（＜ＤＩＶ＞）がＤＯＭ内に生成される（サブＤＯＭ）。続いてＪａｖａＳｃｒｉｐｔは、ＤＯＭ要素が期待どおりに挿入されたかどうかを確認できる。

オブジェクト・ステータス確認に基づく例示としての検証ポイントは、以下のとおりである。

検証ポイントを実装するもう１つの方法は、オブジェクト（例えばＪＳＯＮ文字列（ＪＳＯＮ ｓｔｒｉｎｇ）として線形化）を保存してから、シミュレートされたシステム・イベントをリクエストすることであり、その結果、シミュレートされたシステム・イベントが受信されてＤＯＭに対して変更が適用されると、先に保存されたＪＳＯＮオブジェクトが読み込まれて、変更されたオブジェクトと比較されることができる。ウェブ・アプリケーションが、マウスが上にあるときに背景色を変更するウィジェットをウェブ・ページ内に含むと仮定する。マスタ値（ｍａｓｔｅｒ ｖａｌｕｅ）としてシリアル化されたウィジェット・オブジェクトをマスタ・リポジトリに有すると想定する（マウスがウィジェット上にあるときの色に関して期待される背景色を備える）。この場合、ＪａｖａＳｃｒｉｐｔテストは、ＪａｖａＳｃｒｉｐｔコマンド・イベント、ウィジェットの「マウス・オーバ」をリクエストすることにあり、続いてイベントがブラウザに到着し、マウスが自動的にウィジェットの上に移動されると、ＪａｖａＳｃｒｉｐｔテストは、実際のウィジェット・ステータスと、リポジトリ内に残ったものとを比較するようサービスにリクエストする。これらテスト・スイートそれぞれが、次のアクションを生成する：動的ウェブ・ページに関するＨＴＴＰリクエストを行い、ＪＳＯＮオブジェクトを現在のステータスとして保存し、イベント・コマンドを生成し、（ブラウザが）イベントをキャッチしてウェブ・ページが変化し、結果とマスタ値（テンプレート）とを比較してＤＯＭの変更を検証し、ＪＳＯＮオブジェクトとマスタ値とを比較する。各テスト・スイートは、ブラウザとシステムとの、任意の種類の通常の対話を生成する。

以下の例示的なテストが実装可能である：
・「予測」（検索する文字列の第１の文字をタイプするイベントを生成）。
・「フィールド検証」（すべてのキーボード文字を生成）。
・「ページ保存」（ブラウザ・メニューにアクセスしてページを保存するイベントを生成）。
・「ファイル・アップロード」（ファイルをタイプしてブラウザ・ポップアップで開くイベントを生成）。
・「ローカライズ」（ブラウザ・メニューにアクセスしてブラウザ言語を変更するイベントを生成）。
・同じキーボードおよびマウス・イベントを生成して種々のブラウザ上でのイベントの異なる挙動をテストする「ブラウザ依存」。
・（ｔａｂ，ｅｎｔｅｒ）キーボード・イベントのシーケンスを使用する「アクセシビリティ・テスト・ケース」。

ＪａｖａＳｃｒｉｐｔ ＡＰＩのセルフ・パイロット・コマンドは、ＨＴＴＰサーバにポート上で非同期的に送信される。例えば：
ｈｔｔｐ：／／Ｓｅｒｖｉｃｅｈｏｓｔｎａｍｅ：ｐｏｒｔ／？ｒｅｃｅｉｖｅｒｈｏｓｔ＝ｈｏｓｔｎａｍｅ＆ｃｏｍｍａｎｄ＝＜ｎａｍｅ＞＆ａｒｇ１＝ｖａｌｕｅ１＆……＆ａｒｇＮ＝ｖａｌｕｅＮ

基本的なＡＰＩコマンドの一部は、次のとおりであってもよい：
ｃｌｉｃｋ（ｘ，ｙ）
ｄｏｕｂｌｅｃｌｉｃｋ（ｘ，ｙ）
ｋｅｙ（ｋ）’特別なキーは（ｔａｂ，ｅｎｔｅｒ，ｌｅｆｔ，ｒｉｇｈｔ，ｕｐ，ｄｏｗｎ）
ｐａｕｓｅ（ｄｅｌａｙ）
ｆｉｌｅｌｏａｄ（ｆｉｌｅｎａｍｅ）
ｆｉｌｅｓａｖｅ（ｆｉｌｅｎａｍｅ）

ＪＳＯＮ比較に基づく検証ポイントの一部のＡＰＩコマンドは、次のとおりであってもよい：
ｓａｖｅＡｓＪＳＯＮ（ｏｂｊｅｃｔ，ｎａｍｅ）、オブジェクトをＪＳＯＮ文字列として保存する。
ｏｂｊｅｃｔ ｌｏａｄＪＳＯＮ（ｎａｍｅ）、ＪＳＯＮ文字列をオブジェクトに変換する。
ｃｈｅｃｋＪＳＯＮ（ｏｂｊｅｃｔ，ｏｂｊｅｃｔ）、２つのＪＳＯＮオブジェクトを比較する。

図３は、好適な実施形態によるシミュレートされたイベントが横断するｗｅｂ２．０アプリケーション環境の図である。イベント処理の観察によって、コードをプログラムに埋め込むことのみを提案する従来技術のテスト方法との違いを理解できるようになる。ｗｅｂ２．０アプリケーションは、重要なコンポーネント（例えばＨＴＭＬレンダリング、ドキュメントのＤＯＭ表現、ＪａｖａＳｃｒｉｐｔ言語インタプリタおよび関数ライブラリ、ＨＴＴＰおよびＨＴＴＰＳネットワーク通信など）のサポート、ならびにシステムからのイベントを（例えばユーザ・アクションまたは入力に応答して）受信するメカニズムを提供するコンテナ（例えばウェブ・ブラウザ）内にある。そのようなコンテナおよび関係するコンポーネントすべての実装および挙動が、ｗｅｂ２．０アプリケーションには重大である。この複雑な環境がテスト中に考慮されなければ、ｗｅｂ２．０アプリケーションを完全にテストすることはできない。

図３において、ステップ番号２にて開始する場合（システムへのイベント生成リクエスト）。これは基本的に、ユーザ・アクションに関しても同じ開始点である。図面に示されているように、イベントは、かなり移動をし、いくつかのコンポーネントおよびコードのレイヤによって処理されてから、ｗｅｂ２．０アプリケーションに送信される。その際に、通常、そのようなコードのレイヤおよびコンポーネントに、例えばそのデータ構造を変更することなどによって「跡を残す」。イベントが最終的に送信され、ウェブ・アプリケーションによって処理されると、アプリケーションは、イベントが実際の世界の状況で「実際に」トリガされたかのようにイベントに応答できる。すなわち、ウェブ・アプリケーションは、その環境もイベントを処理したこと、およびそれに反応するチャンスがあったことを発見する。これは、アプリケーションがこの長い処理をすべて無視してイベントの受信をすべてアプリケーションのみでシミュレートする場合は、不可能である。

ウェブ・アプリケーションが、或る種の「抽象的な」イベント、つまり未知であり環境およびウェブ・アプリケーション・コンテナに影響を及ぼさないイベントへのウェブ・アプリケーションの応答しかテストできない場合、この場合は完全にコードをカバーすることは不可能である。それどころか、ウェブ・アプリケーションの場合は特にこれが当てはまるが、あらゆるコンテナ（例えばウェブ・ブラウザ）は他のどのコンテナとも違い、多くの場合はそれ自体の他のバージョンとも違う。これが理由で、サポートされているあらゆる環境でウェブ・アプリケーションをテストすることが必要であり、これは、環境がテスト・シナリオに完全に統合されていると、この場合もやはり確実に不可能である。

図３は、イベントがどのようにして生成されソフトウェア・アプリケーションに送信されることが可能であると考えられるかの例である。イベントが処理されている間、埋め込まれたコードのみでは再現できない、ホスティング環境に影響を及ぼすステップがある（図面のステップ番号３．イベントを処理してイベントをシミュレートおよび５．イベント処理がブラウザによるイベントを再現）。

図４は、好適な実施形態による本発明の方法の概略のフローチャートである。本方法は、１つのホストまたは２つのホスト上、ただし２つのサーバ上で実装される。１つのサーバが、その環境（ウェブ・ブラウザ）内でウェブ・アプリケーションを実行し、ウェブ・アプリケーションとインターフェイスで接続する１つのテスト・サーバが、テストを運用する。ウェブ・アプリケーションを自動的にテストする方法は、ウェブ・アプリケーションをテストするためにテスト・コードをウェブ・アプリケーション・コード内に実装する第１のステップ（４００）を含む。第２のステップ（４１０）は、コマンドを含むメッセージをテスト・サーバにＡＰＩを介して送信する１つのテスト・コードによって実行される。第３のステップ（４２０）において、テスト・サーバはメッセージを受信し、コマンドを解釈して、ウェブ・アプリケーションのページにおけるユーザ入力をシミュレートするか、またはウェブ・アプリケーションの環境およびウェブ・アプリケーションによっても理解可能なシステム・イベントを生成する。ユーザ入力またはシステム・イベントは、ウェブ・アプリケーションにおいて動作しているテスト・コードと関係する。テスト・サーバは、シミュレートされたユーザ入力またはシステム・イベントを、前記ウェブ・アプリケーションを含むウェブ・ブラウザに送信する。ウェブ・ブラウザ（４３０）は、ユーザ入力またはシステム・イベントを処理し、これが、テストされる通常のウェブ・アプリケーションの実行をトリガする。ウェブ・アプリケーション内のテスト・コードは、ウェブ・アプリケーションの内部データ構造をプログラムで検査すること、またはウェブ・アプリケーションの内部データ構造の表現と既知のテンプレートとを比較することによって検査することにより、ウェブ・アプリケーション・コード実行の結果の妥当性を確認する（４４０）。

本方法の一部の特定のステップは、ＨＴＭＬオブジェクト確認に基づく検証ポイントの例に関係する。例えば、ウェブ・ページの一部であるウェブ・パネルにおけるユーザのマウス・クリックが、アプリケーションによって表示される新たなウェブ・パネルを生成すると仮定すると、ステップ４１０は、マウス・クリックのシミュレーションを要求することにあり、ステップ４３０はさらに、ウェブ・アプリケーションが、その通常のコード実行（テスト・コード実行を含まない）において、表示される新たなウェブ・ページに対応する１つのＨＴＭＬオブジェクト（ＤＯＭオブジェクト）インスタンス化に対応する新たなコンテナ構造を生成することを含む。ステップ４４０は、この新たなウェブ・ページに対応するオブジェクトがウェブ・アプリケーション内で適切にインスタンス化されたことをテスト・コードが確認することを含むことになる。

本方法の他の特定のステップは、オブジェクト・ステータス確認に基づく検証ポイントの例に関係する。例えば、ユーザによるウィジェットの使用がＨＴＭＬページの背景の色を適切に変更したことを確認することである。ウェブ・アプリケーションのテスト・コードからのリクエスト（４１０）は、ウィジェット・オブジェクトの初期のステータスが保存される（例えばウィジェットがリポジトリ内にＪＳＯＮ文字列として保存される）よう求めること、およびユーザに表示されウィジェットを含むウェブ・ページにおける、このウィジェット上でのマウス移動などのシステム・イベントをシミュレートするよう、ＪａｖａＳｃｒｉｐｔコマンドを介して求めることにあり得るであろう。その結果、シミュレートされたシステム・イベントの受信時、シミュレートされたマウス移動をブラウザが実行すると、ウェブ・アプリケーションは、対応する関数を実行して、テスト・コード（４４０）は、ウェブ・ページ変更を捕捉して、保存されているオブジェクト（ＪＳＯＮ文字列）をリポジトリから読み出す新たなリクエストをテスト・サービスに送信して（４１０）、保存されているオブジェクトをウェブ・アプリケーションＡＰＩを介して受信して、さらにテスト・コードは、現在のウィジェット・ステータスを読み取り、ＪＳＯＮオブジェクトとリポジトリ内の保存されたオブジェクトとを比較してＤＯＭ変更を検証する。各テスト・スイートは、ブラウザとシステムとの、任意の種類の通常の対話を生成する。

要約すれば、本方法は、ウェブ・アプリケーションの内部構造（４４０）およびウェブ・アプリケーションの外のコンテキスト（４３０）の両方をテストするため、ウェブ・アプリケーションを自動的にテストする本方法は完全である。

内部構造のテストを示す一例は、エラー状態のウィジェットの数がゼロより大きければパネル全体が無効であり処理できないように、この数の記録を付ける内部カウンタをウェブ・アプリケーションが保持すると仮定する場合である。ユーザからの無効入力に対するウェブ・アプリケーションの正しい応答を確認するテストは、３つのテストを含むことができるであろう。
１）エラーを示すために、対応するウィジェットが背景色を変更すること
２）ユーザに知らせるためのメッセージが表示されること
３）内部カウンタが１単位インクリメントされること。
ポイント３）は、アプリケーションの内部データ構造を参照する。内部カウンタは、ウェブ・アプリケーション内のみに存在し、ＨＴＭＬ要素または外部表現でこのカウンタに対応するものはないため、外部入力をテストすることによってはテストできない。コードは、それ自体を分析できる。ＨＴＭＬ、ＤＯＭ、またはＪａｖａＳｃｒｉｐｔオブジェクトは、ウェブ・アプリケーションのウェブ・インターフェイスを介して可視であるものとして外部であるデータ構造、および上記のカウンタのようにウェブ・アプリケーションの内部のデータを含む場合は内部であるデータ構造を有する。

ウェブ・アプリケーションの外のコンテキストのテストを示す一例は、ウェブ・アプリケーションをホストしているコンピュータのオペレーティング・システムにおいて、ウェブ・アプリケーション外で何かが発生すると仮定することである。このテスト方法は、システム・イベントに応答してどのようにアプリケーションが反応するかをテストできる。ブラウザを変更するか、またはウェブ・アプリケーションが実行されるホストのオペレーティング・システムを変更するときの、異なる挙動である。結果として、従来技術の方法の埋め込まれたテスト・コードのように外部イベントに応答して内部構造をテスト可能であり、アプリケーションの内部構造を、システム・コンテキストによってではなくテスト・コード自体によってシミュレートされる内部入力のみに応答してテスト可能である。

Claims (13)

1. テスティング・コンピュータのウェブ・ブラウザ内で動作しているウェブ・アプリケーションを自動的にテストする方法であって、前記ウェブ・アプリケーションは、テスト・コードを組み込まれており、前記方法は、
   前記テスティング・コンピュータが、ユーザ入力をシミュレートするようウェブ・サーバに求める、前記ウェブ・サーバへのメッセージを、前記ウェブ・アプリケーション内で実行されている前記テスト・コードから、前記ウェブ・アプリケーション内で定義されているＡＰＩを介して送信するステップであって、前記ユーザ入力は、前記ウェブ・アプリケーション内で動作している前記テスト・コードに関係している、前記送信するステップを実行すること、
   前記ウェブ・サーバが、前記メッセージを受信するステップ、前記ユーザ入力に対応する少なくとも１つのシステム・イベントをシミュレートするようにシステム・イベント・ジェネレータをトリガするステップ、および前記少なくともシステム・イベントを前記ウェブ・ブラウザに提供するステップを実行すること、
   前記テスティング・コンピュータが、前記シミュレートされた少なくとも１つのシステム・イベントを、前記ウェブ・ブラウザで処理するステップであって、前記少なくとも１つのシステム・イベント自体が前記ウェブ・アプリケーション内のコードの実行をトリガする、前記処理するステップを実行すること、
   前記テスティング・コンピュータが、前記ウェブ・アプリケーション内の前記テスト・コードを使用して、前記少なくとも１つのシステム・イベントによる前記ウェブ・アプリケーション内のコードの実行の前記トリガの結果の妥当性を、前記ウェブ・アプリケーションのウェブ・インターフェイスの内部データ構造を検査することによって確認するステップであって、前記内部データ構造は、前記ウェブ・アプリケーションによって表示されるウェブ・ページから可視であるＨＴＭＬ要素及び内部カウンタを含む、前記確認するステップを実行すること
   を含む、前記方法。
2. 前記確認するステップが、
   前記ウェブ・アプリケーションによって表示されるウェブ・ページの変化に対応する内部データ構造を、前記ウェブ・アプリケーションが正しく生成することを確認するステップを含む、
   請求項１に記載の方法。
3. 前記シミュレートされた少なくとも１つのシステム・イベントは、前記ウェブ・ページの変化を要求するマウス・クリックである、請求項２に記載の方法。
4. 前記送信するステップが、
   前記テスト・コードが、ウェブ・ページ内の内部または外部のオブジェクト・データ構造の初期のステータスを保存するステップと、
   それを前記ウェブ・サーバがリポジトリ内に記憶して前記ウェブ・ページ内の前記オブジェクトに関係する少なくとも１つのシステム・イベントをシミュレートすることを、前記メッセージ内で要求するステップと
   を含み、
   前記確認するステップが、
   前記ウェブ・ページ内の前記外部または内部のオブジェクト・データ構造を前記ウェブ・アプリケーションが変更したことを確認するステップと、
   前記ウェブ・ページの変更の後の前記オブジェクト・データ構造を捕捉するステップと、
   前記ウェブ・アプリケーション内で定義されている同じ前記ＡＰＩを介して、新たなメッセージ内で、テスト・サーバが前記リポジトリから前記オブジェクトの前記初期のステータスを読み出すことを要求するステップと、
   この読み出された初期のオブジェクト・ステータスを受信するステップと、
   前記初期および前記変更された内部データ構造を比較することによって、前記変更が正しいことを検証するステップと
   を含む、
   請求項１に記載の方法。
5. 前記シミュレートされた少なくとも１つのシステム・イベントは、ウェブ・ページにおける、ウィジェットであるオブジェクト上のマウス移動である、請求項４に記載の方法。
6. 前記各ステップは、ＨＴＭＬ、ＤＯＭ、またはＪａｖａＳｃｒｉｐｔオブジェクトに対して実行される、請求項１〜５のいずれか１項に記載の方法。
7. 前記オブジェクトがＪａｖａＳｃｒｉｐｔオブジェクトであれば、前記送信するステップおよび前記確認するステップにおいて、前記オブジェクトは、前記ウェブ・サーバによってリポジトリ内にＪＳＯＮ文字列として記憶され、読み出される、請求項６に記載の方法。
8. 前記ウェブ・サーバがリモートである場合は、前記送信するステップが、
   前記少なくとも１つのシステム・イベントを、前記ウェブ・アプリケーションが実行されている前記サーバへ、前記ウェブ・サーバから送信するステップ
   をさらに含む、請求項１〜７のいずれか１項に記載の方法。
9. 前記テストおよび前記ウェブ・アプリケーションを前記ブラウザによって理解可能な言語でコーディングするステップをさらに含む、請求項１〜８のいずれか１項に記載の方法。
10. 前記テストおよび前記ウェブ・アプリケーションをＪａｖａＳｃｒｉｐｔでコーディングするステップをさらに含む、請求項１〜９のいずれか１項に記載の方法。
11. 前記送信するステップおよび前記確認するステップが、
    パイロット・アプリケーションを介して、前記アプリケーション内の前記テスト・コードを手動でトリガするステップ
    をさらに含む、請求項１〜１０のいずれか１項に記載の方法。
12. 前記送信するステップおよび前記確認するステップが、一度起動された前記ウェブ・アプリケーションの実行によって自動的に実行される、請求項１〜１０のいずれか１項に記載の方法。
13. テスティング・コンピュータとウェブ・サーバとを備えているシステムであって、前記テスティング・コンピュータのウェブ・ブラウザ内で動作しているウェブ・アプリケーションを自動的にテストする前記システムにおいて、前記ウェブ・アプリケーションは、テスト・コードを組み込まれており、
    前記テスティング・コンピュータが、ユーザ入力をシミュレートするようウェブ・サーバに求める、前記ウェブ・サーバへのメッセージを、前記ウェブ・アプリケーション内で実行されている前記テスト・コードから、前記ウェブ・アプリケーション内で定義されているＡＰＩを介して送信することであって、前記ユーザ入力は、前記ウェブ・アプリケーション内で動作している前記テスト・コードに関係している、前記送信することを実行し、
    前記ウェブ・サーバが、前記メッセージを受信すること、前記ユーザ入力に対応する少なくとも１つのシステム・イベントをシミュレートするようにシステム・イベント・ジェネレータをトリガすること、および前記少なくともシステム・イベントを前記ウェブ・ブラウザに提供することを実行し、
    前記テスティング・コンピュータが、前記シミュレートされた少なくとも１つのシステム・イベントを、前記ウェブ・ブラウザで処理することであって、前記少なくとも１つのシステム・イベント自体が前記ウェブ・アプリケーション内のコードの実行をトリガする、前記処理することを実行し、
    前記テスティング・コンピュータが、前記ウェブ・アプリケーション内の前記テスト・コードを使用して、前記少なくとも１つのシステム・イベントによる前記ウェブ・アプリケーション内のコードの実行の前記トリガの結果の妥当性を、前記ウェブ・アプリケーションのウェブ・インターフェイスの内部データ構造を検査することによって確認することであって、前記内部データ構造は、前記ウェブ・アプリケーションによって表示されるウェブ・ページから可視であるＨＴＭＬ要素及び内部カウンタを含む、前記確認することを実行する、
    前記システム。

Images