(57)【特許請求の範囲】
【請求項１】
ウェブ・アプリケーションのテストケースを生成する情報処理装置であって、
前記ウェブ・アプリケーションのサーバ・コードから解析により抽出された、それぞれパラメータに対する制約条件を含む１以上のリソース識別子パターンを格納するパターン格納部と、
前記サーバ・コードから生成されたクライアント・コードを解析し、前記１以上のリソース識別子パターンのうちの少なくとも１つに適合する１以上のイベント・シーケンスを発見するクライアント・コード解析部と、
前記クライアント・コードから構築されるクライアント状態を取り込み、前記１以上のイベント・シーケンスそれぞれを前記クライアント状態上で実行し、前記イベント・シーケンスの実行結果として生成されるリソース識別子を含むテストケースを生成するテストケース生成部と
を含む、情報処理装置。
【請求項２】
前記情報処理装置は、生成された前記テストケースを基礎として、前記ウェブ・アプリケーションとの相互作用を通じて、前記クライアント状態を新たなクライアント状態に発展させる要求部を含み、
前記クライアント・コード解析部および前記テストケース生成部は、前記新たなクライアント状態に対する処理を行うことによって、他のリソース識別子パターンに対応するテストケースを生成する、請求項１に記載の情報処理装置。
【請求項３】
前記要求部は、前記１以上のリソース識別子パターンすべてがカバーされない間、前記新たなクライアント状態の取得を試み、前記テストケースの生成は、前記１以上のリソース識別子パターンすべてがカバーされた場合に完了する、請求項２に記載の情報処理装置。
【請求項４】
前記テストケースは、前記イベント・シーケンスと、前記イベント・シーケンスが実行された前記クライアント状態とをさらに含む、請求項３に情報処理装置。
【請求項５】
前記情報処理装置は、前記サーバ・コードを解析し、前記１以上のリソース識別子パターンを抽出するサーバ・コード解析部を含む、請求項４に情報処理装置。
【請求項６】
ウェブ・アプリケーションのテストケースを生成するために情報処理装置が実行する方法であって、
前記情報処理装置が、前記ウェブ・アプリケーションのサーバ・コードから解析により抽出された、それぞれパラメータに対する制約条件を含む１以上のリソース識別子パターンを格納するステップと、
前記情報処理装置が、前記サーバ・コードから生成されたクライアント・コードを解析し、前記１以上のリソース識別子パターンのうちの少なくとも１つに適合する１以上のイベント・シーケンスを発見するステップと、
前記情報処理装置が、前記クライアント・コードから構築されるクライアント状態を取り込み、前記１以上のイベント・シーケンスそれぞれを前記クライアント状態上で実行し、前記イベント・シーケンスの実行結果として生成されるリソース識別子を含むテストケースを生成するステップと、
を含む、テストケース作成方法。
【請求項７】
前記テストケース作成方法は、前記情報処理装置が、生成された前記テストケースを基礎として、前記ウェブ・アプリケーションとの相互作用を通じて、前記クライアント状態を新たなクライアント状態に発展させるステップをさらに含み、
前記１以上のイベント・シーケンスを発見するステップおよび前記テストケースを生成するステップは、前記新たなクライアント状態について、前記１以上のリソース識別子パターンすべてがカバーされるまで、または新たなクライアント状態が得られなくなるまで、繰り返される、請求項６に記載のテストケース作成方法。
【請求項８】
前記テストケース作成方法は、前記サーバ・コードを解析し、前記１以上のリソース識別子パターンを抽出するステップを含む、請求項７に記載のテストケース作成方法。
【請求項９】
ウェブ・アプリケーションのテストケースを生成するためのコンピュータ実行可能なプログラムであって、
前記ウェブ・アプリケーションのサーバ・コードから解析により抽出された、それぞれパラメータに対する制約条件を含む１以上のリソース識別子パターンを格納するパターン格納部、
前記サーバ・コードから生成されたクライアント・コードを解析し、前記１以上のリソース識別子パターンのうちの少なくとも１つに適合する１以上のイベント・シーケンスを発見するクライアント・コード解析部、および
前記クライアント・コードから構築されるクライアント状態を取り込み、前記１以上のイベント・シーケンスそれぞれを前記クライアント状態上で実行し、前記イベント・シーケンスの実行結果として生成されるリソース識別子を含むテストケースを生成するテストケース生成部
をコンピュータに実現するためのコンピュータ実行可能なプログラム。
【請求項１０】
前記プログラムは、さらに、生成された前記テストケースを基礎として前記ウェブ・アプリケーションとの相互作用を通じて、前記クライアント状態を新たなクライアント状態に発展させる要求部をコンピュータに実現するためのコードを含み、前記クライアント・コード解析部および前記テストケース生成部は、前記新たなクライアント状態に対する処理を行うことによって、他のリソース識別子パターンに対応するテストケースを生成する、請求項９に記載のプログラム。
【請求項１１】
前記要求部は、前記１以上のリソース識別子パターンすべてがカバーされない間、前記新たなクライアント状態の取得を試み、前記テストケースの生成は、前記１以上のリソース識別子パターンすべてがカバーされた場合に完了する、請求項１０に記載のプログラム。
【請求項１２】
請求項９〜１１のいずれか１項に記載のコンピュータ実行可能なプログラムをコンピュータ可読に格納する記録媒体。
【請求項１３】
ウェブ・アプリケーションのテストケースを生成する情報処理装置であって、
前記ウェブ・アプリケーションのサーバ・コードを解析し、それぞれパラメータに対する制約条件を含む１以上のリソース識別子パターンを抽出するサーバ・コード解析部と、
前記サーバ・コードから抽出された前記１以上のリソース識別子パターンを格納するパターン格納部と、
前記サーバ・コードから生成されたクライアント・コードを解析し、前記１以上のリソース識別子パターンのうちの少なくとも１つに適合する１以上のイベント・シーケンスを発見するクライアント・コード解析部と、
前記クライアント・コードから構築されるクライアント状態を取り込み、前記１以上のイベント・シーケンスそれぞれを前記クライアント状態上で実行し、前記イベント・シーケンスの実行結果として生成されるリソース識別子と、前記イベント・シーケンスと、前記イベント・シーケンスが実行された前記クライアント状態とを含むテストケースを生成するテストケース生成部と、
生成された前記テストケースを基礎として、前記ウェブ・アプリケーションとの相互作用を通じて、前記クライアント状態を新たなクライアント状態に発展させる要求部と
を含み、前記クライアント・コード解析部および前記テストケース生成部は、前記新たなクライアント状態に対する処理を行うことによって、他のリソース識別子パターンに対応するテストケースを生成し、前記要求部は、前記１以上のリソース識別子パターンすべてがカバーされない間、前記新たなクライアント状態の取得を試み、前記テストケースの生成は、前記１以上のリソース識別子パターンすべてがカバーされた場合に完了する、情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアテスト技術に関し、より詳細には、ウェブ・アプリケーションのソフトウェアテストにおけるテストケースを自動的に生成する情報処理装置、テストケース生成方法、プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
近年のインターネットの発展に伴い、オンラインバンキング、オンライントレード、ネットショッピング、電子掲示板などの種々のサービスがウェブ・アプリケーションとして提供されている。特に近年のウェブ技術の進展により、ウェブ・アプリケーションは、初期の静的なコンテンツの集合から、動的かつ対話的にコンテンツを提供するように変化している。また、ＪａｖａＳｃｒｉｐｔ（登録商標）や、Ａｊａｘ（Asynchronous JavaScript（登録商標） and XML）、Ａｄｏｂｅ（登録商標）Ｆｌａｓｈ（登録商標）などクライアントテクノロジの発達に伴い、ますますリッチで動的なコンテンツが提供されるようになっている。
【０００３】
このようなウェブ・アプリケーションの複雑化に伴い、その動的な性質に起因して、従来のソフトウェアに対して有効であったテスト手法が効果的ではなくなり、ウェブ・アプリケーションを充分に検証することが困難となっていた。このため、ウェブ・アプリケーションの充分なソフトウェアテストを行うためには、多くの部分を手動で行う必要があり、アプリケーション開発の人件費を増大させる要因となっている。また、開発工程が進むにつれバグ修正のために必要なコストが増大する。このような背景から、動的なウェブ・アプリケーションに対する充分なソフトウェアテストを効率的に行うことを可能とするテストツールの開発が望まれていた。
【０００４】
従来より、ウェブ・アプリケーションのソフトウェアテストを自動化する技術の開発が試みられており、主として静的解析や動的解析による技術が広く適用されている（非特許文献１）。動的解析は、ウェブ・アプリケーションをトラバースして、ウェブ・アプリケーションの構造や振る舞いを学習し、予期しないようなインプットを送信したりすることでセキュリティ・ホールを発見する技術である。動的解析は、いわゆるブラックボックス・テストであり、サーバ側ソース・コードや動作に関する情報を必要としない。
【０００５】
これに対して、静的解析は、アプリケーション・コードを解析して、アプリケーションを記述する数学的なモデルを構築し、このモデルを解析することによってセキュリティ上の弱点を識別する技術である。静的解析は、いわゆるホワイトボックス・テストであり、アプリケーション・コードが必要となるが、コード自体が静的にスキャンされるため、コード網羅率の定義が明確となる。また、サーバ側のコードを静的解析することにより、コード中の文字列から、ＵＲＬ（Uniform Resource Locator）や入力パラメータを抽出する試みもなされている（非特許文献２）。また、クライアント・コードの静的コード解析に関連して、ＤＨＭＬなどのクライアント・コードにおけるＪａｖａＳｃｒｉｐｔ（登録商標）を検証する技術が知られている（非特許文献３）。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】”Developing secure Web applications: An introduction to IBM Rational AppScan Developer Edition”、［online］、”DeveloperWorks”、”Rational”、”Technical library”、［２０１０年４月２７日検索］、インターネット＜ＵＲＬ；http://www.ibm.com/developerworks/rational/library/08/0916_podjarny/＞
【非特許文献２】Minghui Wang, et. al，”A Static Analysis Approach for Automatic Generating Test Cases for Web Applications”，2008 International Conference on Computer Science and Software Engineering，p751-754, December 2008．
【非特許文献３】Takaaki Tateishi, et. al，”DHTML Accessibility Checking Based on Static JavaScript Analysis”，LNCS Universal Access in Human-Computer Interaction. Applications and Services, Volume 4556 p167-176, 2007.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記静的解析では、どのようなクライアント・コードが生成されるかをサーバ・コードから正確に予測することが困難である。また、クライアント側の動的なコードに起因して、静的解析ですべてのコード・パスを見つけ出すことは困難となる。また、一部のコードは、サーバ側を眺めているだけでは見えてこない。
【０００８】
一方、ウェブ・アプリケーションとの可能なあらゆるインタラクションを表すイベントツリーは、動的でかつ指数関数的に成長してゆく。このため、動的解析では、ウェブ・アプリケーションを完全に漏れなく探索しようとしても、非現実的な時間が必要となり、また無限ループに陥る可能性もある。さらに、クライアント側のＪａｖａＳｃｒｉｐｔ（登録商標）コードの実行結果をシミュレートすることにより、所定の範囲に制約して探索することも行われているが、潜在的に不完全なコード網羅率となってしまう。
【０００９】
したがって、従来のウェブ・アプリケーションの自動テスト技術は、特に動的なウェブ・アプリケーションに対して充分に機能するものではなく、このような動的なウェブ・アプリケーションを高い信頼性によりテストすることができる技術の開発が望まれていた。
【００１０】
すなわち、本発明は、上記問題点に鑑みてなされたものであり、コード網羅率の正確な検証を行うことができる形式で、ウェブ・アプリケーションのテストケースを効率的に生成可能な情報処理装置、テストケース生成方法、プログラムおよび記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、上記従来技術の不都合に鑑みてなされたものであり、本発明は、以下の特徴を有する、ウェブ・アプリケーションのテストケースを生成するための情報処理装置、テストケース生成方法、該情報処理装置をコンピュータ上に実現するプログラム、および該プログラムを記録媒体を提供する。
【００１２】
本発明では、まずウェブ・アプリケーションのサーバ・コードから解析により１以上のリソース識別子パターンを抽出しておく。このリソース識別子パターンは、それぞれパラメータに対する制約条件を含むものである。そして、情報処理装置は、上記サーバ・コードから生成されるクライアント・コードを解析することにより、上記１以上のリソース識別子パターンのうちの少なくとも１つに適合する１以上のイベント・シーケンスの発見を試みる。適合する１以上のイベント・シーケンスが見つかると、情報処理装置は、クライアント・コードから構築されるクライアント状態を取り込み、イベント・シーケンスそれぞれをクライアント状態上で実行し、実行結果として生成されるリソース識別子を含むテストケースを生成する。この実行結果として生成されるリソース識別子は、上記制約条件を満たすものとなる。
【００１３】
また本発明では、情報処理装置は、生成されたテストケースを基礎として、ウェブ・アプリケーションとの相互作用を通じて、クライアント状態を新たなクライアント状態に発展させることができる。この場合、新たなクライアント状態に対し、クライアント・コードの解析、イベント・シーケンスの発見、およびテストケースの生成が行われることによって、抽出された１以上のリソース識別子パターンの他のパターンに対応するテストケースを生成することができる。
【発明の効果】
【００１４】
上記構成によれば、情報処理装置では、ウェブ・アプリケーションのサーバ・コードから生成されるクライアント・コードを解析し、予め解析によりサーバ・コードからテストすべき対象として抽出された上記リソース識別子パターンに適合するクライアント状態およびイベント・シーケンスが探索され、サーバ・コードと、動的に生成されるクライアント・コードとの間の整合性を検証するためのテストケースが生成される。上記リソース識別子パターンがサーバ・コードの解析によって与えられるため、テスト達成度の基準となるコード網羅率の基準が明確であり、ソフトウェアテストにおいてコード網羅率を正確に検証することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態によるコンピュータ装置を含んで構成されるウェブ・アプリケーションのテスト環境の概略図。
【図２】本発明の実施形態によるテスト環境において実現される機能ブロック図。
【図３】本実施形態においてクライアント−サーバ間の相互作用を通じてテストケースを動的に生成する処理を説明する模式図。
【図４】本発明の実施形態のテストツールを実装するコンピュータ装置が実行するテストケース生成処理を示すフローチャート。
【図５】テスト対象のウェブ・アプリケーションのサーバ・コード（Ａ）および生成されるクライアント・コード（Ｂ，Ｃ）を例示する図。
【図６】本実施形態のテストケース生成処理の結果を示す画面を例示する図。
【図７】本実施形態のテストケース生成処理の結果を示す他の画面を例示する図。
【図８】テスト対象のウェブ・アプリケーションのサーバ・コード（Ａ）および生成されるクライアント・コード（Ｂ）の擬似コードを例示する図。
【図９】対象アプリケーションについてテストケースを生成する処理の実行例を示すフローチャート。
【発明を実施するための形態】
【００１６】
以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下の実施形態では、ウェブ・アプリケーションのテストケースを生成する情報処理装置として、ウェブ・アプリケーションのソフトウェア・テスト・ツールを実装するコンピュータ装置を一例として説明する。
【００１７】
図１は、本発明の実施形態によるコンピュータ装置１８を含んで構成されるウェブ・アプリケーションのテスト環境１０の概略図を示す。図１に示すテスト環境１０では、コンピュータ装置１８は、ネットワーク１２を介して、ウェブ・アプリケーション・サーバ１４やインターネット１６と接続されている。ネットワーク１２は、例えば、ＴＣＰ／ＩＰおよびイーサネット（登録商標）によるＬＡＮ（Local Area Network）、ＶＰＮ（Virtual Private Network）や専用線を使用するＷＡＮ（Wide Area Network）などとして構成される。
【００１８】
コンピュータ装置１８は、概ねパーソナル・コンピュータ、ワークステーションなどの汎用コンピュータとして構成される。コンピュータ装置１８は、より具体的には、シングルコア・プロセッサまたはマルチコア・プロセッサなどの中央処理装置（ＣＰＵ）、キャッシュ・メモリ、ＲＡＭ、ネットワーク・インタフェース・カード（ＮＩＣ）、ストレージ装置などを備え、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などの適切なオペレーティング・システム（以下、ＯＳとして参照する。）の制御のもと動作する。ウェブ・アプリケーション・サーバ１４も同様に、概ねパーソナル・コンピュータ、ワークステーション、ラックマウント型またはブレード型サーバなどのコンピュータ装置として構成される。
【００１９】
本実施形態のソフトウェアテストの対象となるウェブ・アプリケーションまたはそのモジュール（以下、対象アプリケーションという。）は、特に限定されるものではないが、ソフトウェア・テスト・ツールを実装するコンピュータ装置１８ローカル、またはウェブ・アプリケーション・サーバ１４上に配置される。
【００２０】
対象アプリケーションは、ＪＳＰ（Java（登録商標） Server Pages）、ＡＳＰ（Active Server Pages）、ＰＨＰ（Hypertext Preprocessor）などのサーバ・プログラムを実装し、ＨＴＴＰプロトコルを使用して、ウェブ・クライアントからのＨＴＴＰリクエストを処理するよう構成されている。より具体的には、対象アプリケーションは、クライアンからのＨＴＴＰリクエストに応答して、ソース・コードに従いＨＴＭＬデータ、ＸＭＬデータ等（以下、クライアント・コードという。）を生成し、ＨＴＴＰレスポンスを返す。なお、クライアント・コードは、サーバ・プログラムと、対象アプリケーションに接続されるデータベース（図示せず）やインターネット１６上の他のウェブ・アプリケーションまたはウェブ・サービスなどとが連携し、これらにより提供される情報を利用して生成されることもある。
【００２１】
クライアント・コードがサーバ・コードから動的に生成される場合、ウェブ・アプリケーションが複雑化してくると、サーバ・プログラムのソース・コード（以下、サーバ・コードという。）からクライアント・コードを正確に予測することが困難になってくる。また、無限のクライアント・コードが生成可能であるため、テスト達成度の基準となるコード網羅率の定義が不明確であり、コード網羅率を正確に追跡することが困難となる。
【００２２】
そこで、本実施形態では、サーバ・コードの静的コード解析により、静的なサーバ・コードについてのコード網羅率を適切に保証するとともに、クライアント・コードを動的に生成するコード、およびクライアント側にわたってアプリケーション・コードを展開させているコードに関しては、テストすべき対象として、さらに、クライアント・コードの解析を通じてこれらのコードをカバーするテストケースを生成する。このように、対象アプリケーション全体についてコード網羅率の基準を明確化し、またこれらのコードをカバーするテストケースを動的に生成し、コード網羅率の正確かつ効率的な検証の実現を図る。なお、本明細書において、「動的に生成する」とは、動作中の対象アプリケーションと相互作用しながら生成することを意味する。以下、本発明の実施形態によるテストケースの生成処理について、より詳細に説明する。
【００２３】
図２は、本発明の実施形態によるテスト環境１０において実現される機能ブロックを示す。図２に示すテスト環境１０は、対象アプリケーションを実装するサーバ側の機能ブロック２０と、対象アプリケーションをテストするクライアント側の機能ブロック３０とから構成される。サーバ側の機能ブロック２０に含まれる各機能部は、図１に示したウェブ・アプリケーション・サーバ１４またはコンピュータ装置１８が、ＨＤＤなどのコンピュータ可読な記録媒体からプログラムを読み出し、メモリ上にプログラムを展開し、プログラムを実行し、各ハードウェア資源を動作制御することによって実現される。クライアント側の機能ブロック３０は、コンピュータ装置１８がコンピュータ可読な記録媒体からプログラムを読み出し、メモリ上に展開し、プログラムを実行し、各ハードウェア資源を動作制御することによって実現される。
【００２４】
サーバ側の機能ブロック２０は、対象アプリケーションを記述するサーバ・コード２２と、サーバ・コード２２を解析するサーバ・コード解析部２４と、サーバ・コード２２に従いクライアントからのＨＴＴＰ要求を処理する応答部２６とを含む。
【００２５】
サーバ・コード２２は、例えばＪＳＰ、ＡＳＰ、ＰＨＰなどの技術を利用して記述され、例えばＪＳＰではＨＴＭＬ内にＪａｖａ（登録商標）コードが埋め込まれたファイルを含む一群のリソースの集合として構成される。サーバ・コード解析部２４は、いわゆる静的コード解析を実行する機能部であり、対象アプリケーションのサーバ・コード２２を解析し、対象アプリケーションを記述する数学的なモデルを構築し、当該モデルを解析する。
【００２６】
本実施形態では、サーバ・コード解析部２４は、サーバ・コード２２を静的コード解析することにより、サーバ・コード２２中に含まれるＵＲＬパターンおよびパラメータ制約条件（以下、ＵＲＬパターンおよびパラメータ制約条件のセットをパラメータ制約付きＵＲＬパターンと参照する。）を抽出する。ここで、ＵＲＬパターンとは、クエリ文字列中に埋め込まれるパラメータを含むＵＲＬの書式を、後述するパラメータ制約条件と関連付けて表現したものである。ＵＲＬパターンは、一般的に、スキーム（例：http）、オーソリティ（例：www.xxxx.yy.xx）およびパス（例：abc.jsp）の部分と、クエリ文字列の部分（例：parameter=value1）とから構成される。なお、説明する実施形態では、ネットワーク上のリソースを指し示すリソース識別子およびリソース識別子パターンとして、ＵＲＬを用いた場合を例示するが、ＵＲＬに限定されるものではなく、ＵＲＮ（Uniform Resource Name）など他のリソース識別子に対して適用することもできる。
【００２７】
また、パラメータ制約条件とは、対象アプリケーションにおける分岐構造等を反映したものであり、当該クエリ文字列中に設定されるパラメータに与えられる条件（例：value1>0）を規定する。パラメータ制約条件には、パラメータの値の範囲、他のパラメータとの関係、パラメータのデータ型など、パラメータに関連する種々の条件を含むことができる。なお、パラメータ制約条件がない場合もある。サーバ・コード解析部２４は、ソース・コードを解析し、要求される網羅の程度に応じて、パラメータに関する分岐、条件を網羅するようにパラメータ制約付きＵＲＬパターンを抽出する。なお、このようなＵＲＬパターンは、非特許文献２に開示されるように、静的コード解析により好適に抽出することができる。
【００２８】
パラメータ制約付きＵＲＬにつき例示すると、サーバ・コード中に、request.getParameterメソッドにより、２つのパラメータの取得が記述され、一定の大小関係を満たす場合の処理が記述されている場合、抽出されるＵＲＬパターンは、”http://localhost/page.jsp?a=z+b=y”のように表され、パラメータ制約条件は、例えば”z>y”のように表される。
【００２９】
このように、本実施形態では、サーバ・コードの静的解析により、クライアントから受け取ったパラメータに応じて処理を行うようなコードが識別され、各コードにアクセスするＵＲＬパターンおよびパラメータ制約条件が抽出される。サーバ・コード解析部２４は、サーバ・コード２２の静的解析が完了すると、解析結果中に含まれる１以上のパラメータ制約付きＵＲＬパターンを、例えばリストデータ形式でクライアント側の機能部３０へ渡す。
【００３０】
なお、サーバ・コード解析部２４は、テストツールを実装するコンピュータ装置１８に対し、静的解析の結果、つまりパラメータ制約付きＵＲＬパターンのリストを提供する、外部のモジュールとして構成することができる。また、他の実施形態では、本実施形態のテストツールに組み込まれ、本テストツールを実装するコンピュータ装置１８上で、サーバ・コードの静的解析を実行し、パラメータ制約付きＵＲＬパターンを抽出する構成とすることもできる。
【００３１】
応答部２６は、ウェブサーバ機能と、ＪＳＰ、ＡＳＰ、ＰＨＰなどのサーバ・プログラムを処理するアプリケーション・サーバ機能とを実装し、対象アプリケーションとして動作する。応答部２６は、クライアントからのＨＴＴＰリクエストに応答して、サーバ・コード２２に対応してクライアント・コードを生成し、ＨＴＴＰレスポンスを送信する。
【００３２】
クライアント側の機能ブロック３０は、ＵＲＬパターン・キュー３２と、クライアント・コード解析部３４と、ＤＯＭツリー記憶部４２とを含む。ＵＲＬパターン・キュー３２は、後述するテストケースのエントリを生成するために、サーバ・コード解析部２４から渡されたパラメータ制約付きＵＲＬパターンを一時的に保持する待ちキューである。ＵＲＬパターン・キュー３２には、処理待ちのパラメータ制約付きＵＲＬパターンのエントリが保持され、処理済みのエントリについては、当該ＵＲＬパターン・キュー３２から削除されるか、または処理済みであることを示すチェックが付される。
【００３３】
クライアント・コード解析部３４は、いわゆる静的コード解析を実行する機能部であり、サーバ側の応答部２６から取得したクライアント・コードを解析する。まず、サーバ側の応答部２６からクライアント・コードが受信されると、クライアント側の機能ブロック３０では、当該ウェブ・クライアントの状態（以下、クライアント状態という。）を記述するＤＯＭ（Document Object Modeling）ツリーが構築される。このＤＯＭツリーは、ＲＡＭなどにより提供されるＤＯＭツリー記憶部４２に格納される。ＤＯＭツリーは、クライアント・コード中に記述される要素を木構造のとして保持し、ウェブ・ページを構成する各要素の操作、参照、イベント処理を可能とする。
【００３４】
本実施形態のクライアント・コード解析部３４は、取得されたクライアント・コード（クライアント状態）を静的コード解析することにより、ＵＲＬパターン・キュー３２が保持する少なくとも１つのエントリに適合するイベント・シーケンスを検出する。ここで、イベント・シーケンスとは、上記クライアント状態上で実行される一連のイベントを意味する。
【００３５】
このクライアント・コード解析部３４の解析により、パラメータ制約付きＵＲＬパターンに適合するリクエストＵＲＬ（具体的な入力パラメータの値を含む。）を結果として生成するイベント・シーケンスが発見される。例えば、上述したパラメータ制約付きＵＲＬパターンの例（”http://localhost/page.jsp?a=z+b=y”，x>y）では、「２つのパラメータａ，ｂの入力ボックスそれぞれに、パラメータ制約条件を満たす具体的な値を入力し、送信ボタンをクリックする」というような、クライアント側で実行される一連のイベントが発見される。
【００３６】
またクライアント・コード解析部３４は、クライアント・コードに含まれるＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト・コードを静的解析する機能を備えることもできる。クライアント・コード解析部３４は、このスクリプト・コードを静的解析またはシミュレートすることによって、スクリプト・コード中の関数の呼び出し等を含めてイベント・シーケンスを発見することができる。
【００３７】
図２に示すクライアント側の機能ブロック３０は、さらに、テストケース生成部３６と、要求部３８と、テスト・キュー４０とを含む。上記クライアント・コード解析部３４は、所与のクライアント状態から、ＵＲＬパターン・キュー３２中の少なくとも１つエントリに適合する１以上のイベント・シーケンスを見つけ出すと、このイベント・シーケンスをテストケース生成部３６に渡す。
【００３８】
テストケース生成部３６は、クライアント・コード解析部３４からイベント・シーケンスを受け取り、このイベント・シーケンスを用いてテストケースのエントリ（以下、テスト・エントリという。）を動的に生成する。より具体的には、テストケース生成部３６は、ＤＯＭツリー記憶部４２からクライアント状態を取り込み、このクライアント状態上で当該イベント・シーケンスを実行し、実行結果としてリクエストＵＲＬを生成する。なお、テストケース生成部３６も、クライアント・コードに含まれるスクリプト・コードに対応して、スクリプト・コードの実行をエミュレートする機能を備えることができる。
【００３９】
この生成されたリクエストＵＲＬは、渡されたイベント・シーケンスに対応するパラメータ制約付きＵＲＬパターンに適合する具体的な値を含むものとなる。例えば、上述した「２つのパラメータａ，ｂの入力ボックスそれぞれに、パラメータ制約条件を満たす具体的な値を入力し、送信ボタンをクリックする」というイベント・シーケンスの例では、例えばリクエストＵＲＬ「http://localhost/page.jsp?a=2+b=1」が生成される。このリクエストＵＲＬは、対応するパラメータ制約付きＵＲＬパターン（”http://localhost/page.jsp?a=z+b=y”，x>y）に適合する。
【００４０】
テストケース生成部３６は、リクエストＵＲＬを生成すると、取り込んだクライアント状態と、このクライアント状態上で実行したイベント・シーケンスと、該イベント・シーケンスの実行により生成されたリクエストＵＲＬとのセットをテスト・エントリとして、テスト・キュー４０に保存する。そして、テストケース生成部３６は、対応するＵＲＬパターンのエントリをＵＲＬパターン・キュー３２から削除または処理済みを示すチェックを付す。このように、ＵＲＬパターン・キュー３２中のエントリに対応するテスト・エントリが生成されることによって、パラメータ制約付きＵＲＬパターンに関連するサーバ・コードがカバーされることになる。
【００４１】
上記クライアント・コード解析部３４は、また、イベント・シーケンスを検出した後、ＵＲＬパターン・キュー３２を参照し、現在のクライアント状態を解析した結果、すべてのＵＲＬパターンのエントリが網羅されるか否かを判定する。未だ網羅されないと判断される場合には、クライアント・コード解析部３４は、引き続きパラメータ制約付きＵＲＬパターンに対するテスト・エントリを生成するため、処理未完了（incomplete=true）を要求部３８に通知する。
【００４２】
要求部３８は、クライアント・コード解析部３４から処理未完了（incomplete=true）の通知を受けた場合、テスト・キュー４０中のテスト・エントリを使用して、新たなクライアント状態の取得を試みる。より具体的には、要求部３８は、テスト・エントリのリクエストＵＲＬに対してＨＴＴＰリクエストを発行し、例えばサーバ側の応答部２６から新たなウェブ・ページを受信して、新たなクライアント状態を取得する。あるいは、要求部３８は、例えばサーバ側の応答部２６からＸＭＬデータを受信して、テスト・エントリのクライアント状態に反映させて、新たなクライアント状態を取得する。
【００４３】
新たなクライアント状態が取得されると、クライアント・コード解析部３４は、この新たなクライアント状態に対する静的コード解析を実行してイベント・シーケンスを発見し、テストケース生成部３６は、新たに発見されたイベント・シーケンスから新たなテスト・エントリを生成することになる。このような処理は、ＵＲＬパターン・キュー３２のエントリすべてが網羅されるまで、または新たなクライアント状態が取得できなくなるまで繰り返される。
【００４４】
図３は、本実施形態においてクライアント−サーバ間の相互作用を通じてテストケースを動的に生成する処理を説明する模式図である。まず、対象アプリケーションのサーバ・コードを静的コード解析することにより、サーバ・コード中のクライアント・コードを動的に生成するコードを識別し、そのコードにアクセスするパラメータ制約付きＵＲＬパターンを抽出する。この抽出されたパラメータ制約付きＵＲＬパターンは、クライアント側での解析を通じてテストすべき対象であり、本実施形態のテストツールは、抽出されたすべてのＵＲＬパターンを網羅することを目標としてテストケースを生成する。
【００４５】
まず、１回目のサイクル５０−１では、クライアント・コード解析部３４は、最初に与えられたクライアント状態（状態１）を解析し、例えば、ＵＲＬパターン・キュー３２の２つのエントリ（パターン１，パターン３）にそれぞれ適合する２つのイベント・シーケンス（シーケンス１，シーケンス２）を発見する。テストケース生成部３６は、クライアント状態（状態１）を取り込み、このクライアント状態上で２つのイベント・シーケンス（シーケンス１，シーケンス２）をそれぞれ実行し、対応する２つのテスト・エントリ（テスト１，テスト２）を生成する。また、テストケース生成部３６は、生成したテスト・エントリに対応するＵＲＬパターン・キュー３２のエントリ（パターン１，パターン３）に処理済みであることを示すチェックを付す。
【００４６】
最初に与えられたクライアント状態（状態１）からは、ＵＲＬパターン・キュー３２の他のエントリ（例えばパターン２）に適合するイベント・シーケンスが発見できなかったため、要求部３８にその旨（incomplete=true）が通知され、要求部３８は、生成されたテスト・エントリを用いて新たなクライアント状態の取得を試みる。ここでは、２つのテスト・エントリ（テスト１，テスト２）から、２通りの新たなクライアント状態（状態１．１，状態１．２）が取得可能であり、要求部３８は、例えば一方のテスト・エントリ（例えばテスト１）を用いて、サーバにリクエストし、クライアント状態（状態１．１）を取得する。なお、もう一方のテスト・エントリ（テスト２）については、特に限定されないが、クライアント状態（状態１．１）から必要な新たなクライアント状態が取得できなくなった際に使用することができる。
【００４７】
２回目のサイクル５０−２では、クライアント・コード解析部３４は、新たなクライアント状態（状態１．１）を解析するが、クライアント状態（状態１．１）からは、ＵＲＬパターン・キューの他のエントリに適合するイベント・シーケンスが発見できず、要求部３８は、他のテスト・エントリ（この例ではテスト２）を用いて新たなクライアント状態（状態１．２）を取得する。
【００４８】
３回目のサイクル５０−２では、クライアント・コード解析部３４は、新たに取得されたクライアント状態（状態１．２）を解析し、例えば、ＵＲＬパターン・キューのエントリ（パターン２）に適合するイベント・シーケンス（シーケンス３）を発見する。テストケース生成部３６は、クライアント状態（状態１．２）を取り込み、この上でイベント・シーケンス（シーケンス３）を実行し、対応するテスト・エントリ（テスト３）を生成する。また、テストケース生成部３６は、生成したテスト・エントリに対応するＵＲＬパターン・キュー３２のエントリ（パターン２）に処理済みであることを示すチェックを付す。
【００４９】
このように、クライアント−サーバ間の相互作用を通じて、クライアント状態の取得と、クライアント状態からのＵＲＬパターンのエントリに適合するイベント・シーケンスの発見とが繰り返され、ＵＲＬパターン・キュー３２内のエントリすべてが網羅されると、当該対象アプリケーションに対するテストケースの生成処理が成功裡に完了することになる。
【００５０】
以下、図４および図５を参照しながら、本発明の実施形態によるテストケース生成処理の流れを説明する。図４は、本発明の実施形態のテストツールを実装するコンピュータ装置１８が実行するテストケース生成処理を示すフローチャートである。また、図５は、テスト対象のウェブ・アプリケーションのサーバ・コード（Ａ）および生成されるクライアント・コード（Ｂ，Ｃ）を例示する図である。図４に示す処理は、コンピュータ装置１８の操作者から、ウェブ・アプリケーションを指定したテストケースの生成処理の実行の指示が与えられたことに応答して、ステップＳ１００から開始される。
【００５１】
ステップＳ１０１では、コンピュータ装置１８は、対象アプリケーションのサーバ・コードから抽出された１以上のパラメータ制約付きＵＲＬパターンの提供を受ける。ここでは、サーバ・コード解析部２４がコンピュータ装置１８上の機能部として実装される場合には、コンピュータ装置１８は、サーバ・コード解析部２４により、サーバ・コード２２を解析し、１以上のパラメータ制約付きＵＲＬパターンを抽出する。サーバ・コード解析部２４がコンピュータ装置１８の外部の機能部として実装される場合には、コンピュータ装置１８は、１以上のパラメータ制約付きＵＲＬパターンを含むサーバ・コード２２の解析結果をインポートする。
【００５２】
例えば図５（Ａ）に示すサーバ・コードが与えられた場合、サーバ・コードの静的解析により、パターン１「”http://localhost/page_1.jsp?a=z+b=y”，z>y」およびパターン２「”http://localhost/page_1.jsp?c=z+d=y”，z>y」が抽出される。
【００５３】
ステップＳ１０２では、コンピュータ装置１８は、上記１以上のパラメータ制約付きＵＲＬパターンをＵＲＬパターン・キュー３２に格納する。図５に示す例では、パターン１およびパターン２がＵＲＬパターン・キュー３２にエントリされる。ステップＳ１０３では、コンピュータ装置１８は、例えば初期ページとして指定されるＵＲＬにアクセスし、クライアント・コードを受信して、初期のクライアント状態を取得する。例えば、コンピュータ装置１８は、ＵＲＬ「http://localhost/page_1.jsp」にアクセスし、図５（Ｂ）に示すクライアント・コードを取得する。
【００５４】
ステップＳ１０４では、コンピュータ装置１８は、クライアント・コード解析部３４により、所与のクライアント状態に対し、静的コード解析を施し、ＵＲＬパターン・キュー３２中のいずれか少なくとも１つのＵＲＬパターンに適合するリクエストＵＲＬを結果として生成するイベント・シーケンスの発見を試みる。図５に示す例では、図５（Ｂ）に示すクライアント・コードの解析により、パターン１に対応するシーケンス１「”a.value=2”→”b.value=1”→”submit.click”」が発見される。一方、現在のクライアント状態からは、パターン２をカバーするイベント・シーケンスを見つけ出すことができない。
【００５５】
現在のクライアント状態に対する解析によってはＵＲＬパターン・キュー３２中のエントリすべてをカバーできない場合には、クライアント・コード解析部３４は、処理未完了（incomplete=true）を要求部３８に通知する。一方、現在のクライアント状態に対する解析によって、ＵＲＬパターンのエントリすべてがカバーされた場合には、クライアント・コード解析部３４は、処理完了（incomplete=false）を要求部３８に通知する。
【００５６】
ステップＳ１０５では、コンピュータ装置１８は、クライアント・コードの解析の結果、上記イベント・シーケンスを発見できたか否かを判定する。発見できたと判定された場合（ＹＥＳ）には、ステップＳ１０６へ処理が進められる。一方、発見できなかったと判定された場合（ＮＯ）には、ステップＳ１１１へ処理が進められる。ステップＳ１０６からステップＳ１１０までの処理では、発見されたイベント・シーケンス毎に処理が実行される。
【００５７】
ステップＳ１０７では、コンピュータ装置１８は、発見されたイベント・シーケンス毎に、テストケース生成部３６に現在のクライアント状態を取り込み、当該クライアント状態上でイベント・シーケンスを実行し、リクエストＵＲＬを生成する。図５の例では、シーケンス１「”a.value=2”→”b.value=1”→”submit.click”」が、初期のクライアント状態上で実行され、結果として、リクエストＵＲＬ「http://localhost/page_1.jsp?a=2+b=1」が生成される。
【００５８】
ステップＳ１０８では、コンピュータ装置１８は、取り込んだクライアント状態と、実行したイベント・シーケンスと、生成したリクエストＵＲＬとをテスト・エントリとして、テスト・キュー４０に格納する。図５に示す例では、取り込んだクライアント状態と、シーケンス１「”a.value=2”→”b.value=1”→”submit.click”」と、リクエストＵＲＬ「http://localhost/page_1.jsp?a=2+b=1」とがテスト・エントリとしてテスト・キュー４０に格納される。
【００５９】
ステップＳ１０９では、コンピュータ装置１８は、ＵＲＬパターン・キュー３２中の当該イベント・シーケンスに対応するＵＲＬパターンのエントリを削除またはチェックする。図５に示す例では、シーケンス１「”a.value=2”→”b.value=1”→”submit.click”」は、パターン１「”http://localhost/page_1.jsp?a=z+b=y”，z>y」に対応するため、ＵＲＬパターン・キュー３２からパターン１が削除される。
【００６０】
ステップＳ１０６からステップＳ１１０までの処理において、発見されたイベント・シーケンスすべてについての処理が完了すると、ステップＳ１１１へ処理が進められる。ステップＳ１１１では、コンピュータ装置１８は、処理が未完了（incomplete=true）であるか否かを判定する。クライアント・コード解析部３４から要求部３８へ処理未完了である旨（incomplete=true）の通知がなされており、ステップＳ１１１で処理が未完了（incomplete=true）である判定された場合（ＹＥＳ）には、ステップＳ１１２へ処理が進められる。
【００６１】
ステップＳ１１２では、コンピュータ装置１８は、要求部３８により、テスト・キュー４０のテスト・エントリを使用して、新たなクライアント状態の取得を試みる。図５に示す例では、新たに生成したテスト・エントリに含まれるリクエストＵＲＬ「http://localhost/page_1.jsp?a=2+b=1」を使用して新たなクライアント状態を要求し、この場合、ＪＳＰにおけるforwardアクションにより、「http://localhost/page_2.jsp」のクライアント・コードが取得される。
【００６２】
ステップＳ１１３では、コンピュータ装置１８は、新しいクライアント状態を取得できたか否かを判定する。ステップＳ１１３で、新たなクライアント状態が取得できたと判定された場合（ＹＥＳ）には、ステップＳ１０４へ処理がループさせられる。一方、新たなクライアント状態を取得できるエントリが存在しないなど、ステップＳ１１３で、新しいクライアント状態が取得できなかった場合（ＮＯ）には、ステップＳ１１４へ処理を分岐し、この場合、ＵＲＬパターン・キュー３２に未処理のエントリが残されたまま、テストケースの生成処理が終了する。
【００６３】
また、ステップＳ１０５で、クライアント・コードの解析の結果、上記イベント・シーケンスを発見できなかったと判定された場合（ＮＯ）には、ステップＳ１１１へ処理が進められる。この場合、クライアント・コード解析部３４は、処理未完了（incomplete=true）を要求部３８に通知し、ステップＳ１１１からステップＳ１１２へ処理が進められ、テスト・キュー４０中の他のテスト・エントリを用いてクライアント状態の取得を試みることになる。
【００６４】
図５に示す例を参照して説明を続けると、２回目のサイクルのステップＳ１０４では、新たに取得された図５（Ｃ）に示すクライアント・コードの解析により、パターン２をカバーするシーケンス２「”c.value=2”→”d.value=1”→”submit.click”」が発見される。この場合、新たに取得したクライアント状態に対する解析によって、ＵＲＬパターン・キュー３２中のエントリすべてがカバーされるので、クライアント・コード解析部３４は、処理完了（incomplete=false）を要求部３８に通知する。
【００６５】
ステップＳ１０７では、シーケンス２「”c.value=2”→”d.value=1”→”submit.click”」が、クライアント状態「http://localhost/page_2.jsp」上で実行され、結果として、リクエストＵＲＬ「http://localhost/page_1.jsp?c=2+d=1」が生成される。ステップＳ１０８では、取り込んだクライアント状態と、シーケンス２「”c.value=2”→”d.value=1”→”submit.click”」と、リクエストＵＲＬ「http://localhost/page_1.jsp?c=2+d=1」とがテスト・エントリとして蓄積される。ステップＳ１０９では、シーケンス２「”a.value=2”→”b.value=1”→”submit.click”」は、パターン２「”http://localhost/page_1.jsp?c=z+d=y”，z>y」に対応するため、ＵＲＬパターン・キュー３２からパターン２が削除される。この場合、要求部３８がクライアント・コード解析部３４から処理が完了した旨（incomplete=false）の通知を受けているため（Ｓ１１１：ＮＯ）、ステップＳ１１１からステップＳ１１４へ処理が進められ、本処理が終了する。この場合、ＵＲＬパターン・キュー３２のエントリすべてを網羅するテストケースの生成処理が成功裡に完了する。
【００６６】
図６および図７は、本実施形態のテストケース生成処理の結果を示す画面を例示する。図６に示す画面１００は、サーバ・コードの静的コード解析の結果抽出されたＵＲＬパターンおよびパラメータ制約条件を表示する画面領域１０２を含む。ＵＲＬパターンおよびパラメータ制約条件は、対応するサーバ・コードに関連付けて（コード行など）管理されており、例えば、画面領域１０４には、選択中のパラメータ制約付きＵＲＬパターンに対応するサーバ・コードがハイライトされている。
【００６７】
また、ＵＲＬパターンおよびパラメータ制約条件は、生成されたテスト・エントリに関連付けて管理されており、図６に示す画面においてタブ１０６がクリックされると、図７に示すように画面１００が遷移する。図７に示す画面１００では、選択中のパラメータ制約付きＵＲＬパターンに対応するテストケースのエントリを表示する画面領域１０８を含む。このように、生成されたテストケースのエントリとサーバ・コードとを関連付けることによって、カバーされたサーバ・コードが把握でき、さらに、テストケースが生成されなかったＵＲＬパターンに関連するサーバ・コードを容易に操作者に識別させることができるようになる。
【００６８】
上述したように、本実施形態では、まず、サーバ・コードを静的コード解析することより、対象アプリケーションにおけるパラメータに関連する制御構造が反映されたパラメータ制約付きＵＲＬパターンが抽出される。そして、クライアントとして動作するコンピュータ装置は、サーバから取得されるクライアント・コードを静的コード解析し、テストすべき対象として抽出されたＵＲＬパターンに適合するリクエストＵＲＬを結果として生成するクライアント状態およびイベント・シーケンスを探索することにより、サーバ・コードと、動的に生成されるクライアント・コードとの間の整合性を検証するためのテストケースを生成する。
【００６９】
テストすべき対象がサーバ・コードの静的コード解析によって与えられるため、テスト達成度の基準となるコード網羅率の基準が明確であり、ソフトウェアテストにおいてコード網羅率を正確に検証することが可能となる。さらに、コンピュータ装置１８は、あるクライアント状態から生成したテスト・エントリを基礎として、クライアント状態にサーバとの相互作用の結果をフィードバックさせながら新たなクライアント状態に発展させ、対象アプリケーションを探索することにより、抽出されたＵＲＬパターン、すなわちクライアント・コードを動的に生成するサーバ・コードを網羅するテストケースを効率的に生成することができる。本技術によれば、例えばウェブ・アプリケーションにおいて、特定のパラメータが入力されて初めて実行されるようなコード・パスもカバーすることができる。
【００７０】
また、本発明のテストケース生成処理では、従来のウェブ・アプリケーションの動的解析の際に問題となっていた無限ループに対して有効に対処することができる。図８および図９を参照して、本実施形態のテストケース生成処理が、どのように無限ループを回避することができるかを説明する。
【００７１】
図８は、テスト対象のウェブ・アプリケーションのサーバ・コード（Ａ）および生成されるクライアント・コード（Ｂ）の擬似コードを例示する。図８に示すコードが与えられると、コードの実行を伴う従来の動的解析では、図８（Ｂ）のクライアント・コードにおいて、ひとたび関数async_check_mail（）が呼び出されてしまうと、無限ループに陥ってしまう。したがって、従来の動的解析では、関数async_check_mail（）以降にある関数（button_click）が実行されず、ＵＲＬ「http://localhost/page_ｚ.jsp」が発見されない可能性がある。
【００７２】
図９は、図８に示す対象アプリケーションについてテストケースを生成する処理の実行例を示すフローチャートである。図９に示す処理は、操作者から、対象アプリケーションを指定したテストケースの生成処理の実行の指示が与えられたことに応答して、ステップＳ２００から開始される。
【００７３】
ステップＳ２０１では、図８（Ａ）に示すサーバ・コードが静的コード解析されて、３つのパラメータ制約付きＵＲＬパターン「”http://localhost/page_x.jsp”，””」、「”http://localhost/page_y.jsp”，””」、「”http://localhost/page_ｚ.jsp”，””」が抽出される。ステップＳ２０２では、コンピュータ装置１８は、上記パラメータ制約付きＵＲＬパターンをそれぞれＵＲＬパターン・キュー３２に追加する。ステップＳ２０３では、コンピュータ装置１８は、例えばＵＲＬ「http://localhost/」にアクセスし、図８（Ｂ）に示すクライアント・コードを受信して、初期のクライアント状態を取得する。
【００７４】
ステップＳ２０４では、コンピュータ装置１８は、クライアント・コードに対し静的コード解析を施し、イベント・シーケンス「””」、「”async_check_mail”」、「”button_click”」を発見する。ここでは、現在のクライアント状態に対する解析によってＵＲＬパターン・キュー３２中のエントリすべてがカバーされるため、要求部３８に処理完了（incomplete=false）が通知される。
【００７５】
ステップＳ２０５では、コンピュータ装置１８は、イベント・シーケンス毎に、クライアント状態を取り込み、当該クライアント状態上でイベント・シーケンス「””」、「”async_check_mail”」および「”button_click”」をそれぞれ実行して、リクエストＵＲＬ「”http://localhost/page_x.jsp”」、「”http://localhost/page_y.jsp”」、「”http://localhost/page_ｚ.jsp”」をそれぞれ生成する。
【００７６】
ステップＳ２０６では、コンピュータ装置１８は、テスト・エントリ「client state， “”， “http://localhost/page_x.jsp”」，「client state， “async_check_mail”， “http://localhost/page_y.jsp”」，「client state， “button_click”， “http://localhost/page_z.jsp”」をテスト・キューに追加する。
【００７７】
ステップＳ２０７では、コンピュータ装置１８は、ＵＲＬパターン・キュー３２中の対応するＵＲＬパターンのエントリ「”http://localhost/page_x.jsp”，””」，「”http://localhost/page_y.jsp”，””」，「”http://localhost/page_ｚ.jsp”，””）を削除する。ステップＳ２０８では、コンピュータ装置１８は、処理未完了（incomplete=true）であるため、本テストケース生成処理を成功裡に完了し、ステップＳ２０９で、本処理を終了する。
【００７８】
このように、本実施形態のテストケース生成処理においては、サーバ・コードの静的解析によりテストすべき対象として抽出されたＵＲＬパターンに適合するクライアント状態およびイベント・シーケンスが、サーバとの相互作用を通じて探索されることになる。このとき、クライアント状態上でイベント・シーケンスが実行されるが、一旦、抽出されたＵＲＬパターンに適合するテスト・エントリが生成されれば、最早、同一のクライアント状態上で同一のイベント・シーケンスは実行されることはなく、このことは無限ループに陥ることが無いことを意味する。
【００７９】
また、本実施形態のテストケース生成処理においては、クライアント・コードの静的な解析により、ひとつのクライアント状態（上記例では、page_x.jsp）から未処理のパラメータ制約付きＵＲＬパターンに適合するすべての可能なイベント・シーケンス（上記例では、””、”async_check_mail()”および”button_click()”）が検出されるため、従来の動的解析では問題となっていた無限ループに起因した探索の漏れを発生させない。
【００８０】
以上説明したように、本発明の実施形態によれば、コード網羅率の正確な検証を行うことができる形式で、ウェブ・アプリケーションのテストケースを効率的に生成可能な情報処理装置、テストケース生成方法、プログラムおよび記録媒体を提供することができる。
【００８１】
本発明の実施形態によれば、無限ループを回避し、効率的に対象アプリケーションが探索されるため、テストすべき対象であるパラメータ制約付きＵＲＬパターンを完全に網羅するテストケースを自動的に生成することが可能である。これにより多くのコストを発生させる手動による作業を大幅に削減することができる。
【００８２】
また、本発明の実施形態によれば、テスト対象のウェブ・アプリケーションの全体像を対象とすることにより、システムの完全なトラッキングも可能である。さらに、Ａｊａｘなどの動的なクライアント・コードを処理することもできる。
【００８３】
本発明の実施形態によるテストケース生成処理は、ウェブ・アプリケーションのセキュリティ診断ツールにおけるクローラとして応用することができ、コード網羅率を向上させることができる。コード網羅率を向上させることができれば、ウェブ・アプリケーションの欠陥を見つけ出せる可能性も高くなるため、ひいては、アプリケーション開発におけるコストを削減することができる。
【００８４】
本発明の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのオブジェクト指向プログラミング言語、ＳＱＬなどのデータベース言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布または伝送して頒布することができる。
【００８５】
これまで本発明を、特定の実施形態および実施例をもって説明してきたが、本発明は、特定の実施形態または実施例に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【符号の説明】
【００８６】
１０…テスト環境、１２…ネットワーク、１４…ウェブ・アプリケーション・サーバ、１６…インターネット、１８…コンピュータ装置、２０…機能ブロック、２２…サーバ・コード、２４…サーバ・コード解析部、２６…応答部、３０…機能ブロック、３２…ＵＲＬパターン・キュー、３４…クライアント・コード解析部、３６…テストケース生成部、３８…要求部、４０…テスト・キュー、４２…ＤＯＭツリー記憶部、５０…サイクル
【図１】
0005425699.tif 000002
【図２】
0005425699.tif 000003
【図３】
0005425699.tif 000004
【図４】
0005425699.tif 000005
【図５】
0005425699.tif 000006
【図６】
0005425699.tif 000007
【図７】
0005425699.tif 000008
【図８】
0005425699.tif 000009
【図９】
0005425699.tif 000010