(57)【要約】【課題】依存性注入される複数の実行環境各々に対してアプリケーションの統合テストを実行することが可能な方法、装置を提供することを目的とする。【解決手段】アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストするテスト装置１において、アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる一のリソース群（ＥＵＴ）をアプリケーションに注入するＤＩコンテナ１１０と、一のリソース群を注入されたアプリケーションに対して、テストを実行するテスト実行部１２０と、を備え、一のリソース群と異なる他のリソース群が存在する場合に、他のリソース群に対して、ＤＩコンテナ１１０による注入と、テスト実行部１２０によるテストを実行する、テスト装置。【選択図】図３
2007172269.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストする方法であって、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となるアプリケーションによって利用される実行環境依存の少なくとも一のリソース群を前記アプリケーションに注入するステップと、
前記アプリケーションによって利用される実行環境依存のリソース群を注入されたアプリケーションに対して、テストを実行するステップと、
を備える方法。
【請求項２】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストする方法であって、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる一のリソース群を前記アプリケーションに注入するステップと、
前記一のリソース群を注入されたアプリケーションに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を備える方法。
【請求項３】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストする方法であって、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる、一以上のリソース群を生成するステップと、
前記生成するステップにて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションに注入するステップと、
前記リソース群を注入されたアプリケーションに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を備える方法。
【請求項４】
前記生成するステップにて生成された一以上の全てのリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行する請求項３に記載の方法。
【請求項５】
前記リソース群は、一以上の実行環境モジュールを含み、
前記注入するステップにて、前記アプリケーションに、前記一以上の実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションに注入する、請求項３に記載の方法。
【請求項６】
前記実行環境モジュールは、さらに、一以上の他の実行環境モジュールを含み、
前記注入するステップにて、前記実行環境モジュールに対して、前記一以上の他の実行環境モジュールを注入し、前記アプリケーションに、前記一以上の他の実行環境モジュールが注入された実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションに注入する、請求項５に記載の方法。
【請求項７】
前記リソース群は、二以上の実行環境モジュールを含み、
前記生成するステップでは、前記リソース群を前記一以上の実行環境モジュールの組合せにより生成する、請求項５に記載の方法。
【請求項８】
前記テストを実行するステップでは、前記リソース群を注入されたアプリケーションに対して、アプリケーション・インターフェースを介して実行されたテストケースによりテストを実行する、請求項５に記載の方法。
【請求項９】
前記テストを実行するステップでは、前記実行環境モジュールに対して、さらに注入された実行環境モジュールを、前記テストケースに提供するステップを含む、請求項８に記載の方法。
【請求項１０】
前記実行環境モジュールのためのテストを実行するステップを含む、請求項５に記載の方法。
【請求項１１】
前記実行環境モジュールのためのテストを実行するステップでは、前記アプリケーションに対して注入された実行環境モジュールに応じて、当該実行環境モジュールのためのテストを選択して実行する、請求項１０に記載の方法。
【請求項１２】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストするテスト装置であって、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となるアプリケーションによって利用される実行環境依存の一のリソース群を前記アプリケーションに注入するＤＩコンテナと、
前記一のリソース群を注入されたアプリケーションに対して、テストを実行するテスト実行部と、を備え、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記ＤＩコンテナによる注入と、前記テスト実行部によるテストを実行する、テスト装置。
【請求項１３】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストするテスト装置であって、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる、一以上のリソース群を生成する実行環境生成部と、
前記実行環境生成部にて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションに注入するＤＩコンテナと、
前記リソース群を注入されたアプリケーションに対して、テストを実行するテスト実行部と、を備え、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記ＤＩコンテナによる注入と、前記テスト実行部によるテストを実行する、テスト装置。
【請求項１４】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストするためのプログラムであって、コンピュータに、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる一のリソース群を前記アプリケーションに注入するステップと、
前記一のリソース群を注入されたアプリケーションに対して、テストを実行するステップと、を実行させ、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行させる、コンピュータ・プログラム。
【請求項１５】
アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストするためのプログラムであって、コンピュータに、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる、一以上のリソース群を生成するステップと、
前記生成するステップにて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションに注入するステップと、
前記リソース群を注入されたアプリケーションに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を実行させる、コンピュータ・プログラム。
【請求項１６】
前記生成するステップにて生成された一以上の全てのリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行する請求項１５に記載のコンピュータ・プログラム。
【請求項１７】
前記リソース群は、一以上の実行環境モジュールを含み、
前記注入するステップにて、前記アプリケーションに、前記一以上の実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションに注入する、請求項１５に記載のコンピュータ・プログラム。
【請求項１８】
前記実行環境モジュールは、さらに、一以上の他の実行環境モジュールを含み、
前記注入するステップにて、前記実行環境モジュールに対して、前記一以上の他の実行環境モジュールを注入し、前記アプリケーションに、前記一以上の他の実行環境モジュールが注入された実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションに注入する、請求項１７に記載のコンピュータ・プログラム。
【請求項１９】
前記リソース群は、二以上の実行環境モジュールを含み、
前記生成するステップでは、前記リソース群を前記一以上の実行環境モジュールの組合せにより生成する、請求項１７に記載のコンピュータ・プログラム。
【請求項２０】
前記テストを実行するステップでは、前記リソース群を注入されたアプリケーションに対して、アプリケーション・インターフェースを介して実行されたテストケースによりテストを実行する、請求項１４に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムのテスト方法、テスト装置に関する。さらに詳しくは、複数のプログラムに対して、テストを実行する方法、この方法を実行するプログラム、テスト装置に関する。
【背景技術】
【０００２】
従来より、テストの対象となるシステムと、その他のシステムを含めて、その挙動が仕様に適合しているか調べるためのテストが行われている。このようなテストは、テスト対象となるシステムのバグ抽出や、システム間での適合性を検証するために、必要不可欠である。現在の多くのアプリケーション・プログラム（以下、「アプリケーション」）は、様々なシステムと結合して実行できることが求められているため、このような結合する可能性がある全てのシステムに対してテスト（以下「統合テスト」）を行う必要がある。
【０００３】
ここで、テスト対象のシステムと、様々な結合可能なシステムとの結合テストを行うには、テスト対象のシステム、結合対象のシステムごとに固有な結合の設定や、構築したシステムごとのテストケースを記述する必要がある。これらの作業は、多大な労力を必要とするものであり、テストの実行における効率化が求められている。
【０００４】
このような結合テストに関連して、アプリケーションをあるシステムで実行する際に、このアプリケーションは、システム側が提供するリソースを利用しながら、アプリケーションのロジックを実行することがある。例えば、システム側が提供するデータベースへの接続クラス、認証機構等を利用して、アプリケーションがデータベースの接続や、個人認証等を行う場合である。このようにデータベース等のシステムを利用する場合、アプリケーションとそのアプリケーションを実行するシステムとの結合テストは、必要不可欠である。このように、システム側のリソースを利用する多くのアプリケーションは、システム側が提供するリソースの種類を意識しながら、アプリケーションを記述する必要がある。
【０００５】
例えば、特定の種類のデータベースへ接続するためのクラスなどは、ソースコード内で直接、もしくは、アプリケーション特有の設定ファイル等で指定する。このようなアプリケーションを、様々なシステムで実行できることを保証するには、アプリケーションのソースコードの書き換えや、アプリケーション特有の設定を、システムごとに行う必要がある。
【０００６】
こういったアプリケーションとアプリケーションが使用するシステムとの結合に関する関心が高まることで、ＤＩ（Dependency  Injection、依存性注入）という考えが近年提案されている。ＤＩを利用したシステム（ＤＩシステム）では、依存性（Dependency）という形式の設定を外部から与えることで、アプリケーション側が利用するリソースの結合を行う（アプリケーションに関しても依存性を利用して結合する）。ここで、依存性とは、あるリソース（依存元）が必要としているリソース（依存先）の記述のことである。例えば、あるリソースＡが、リソースＢを必要としている場合、「ＡがＢに依存している」という依存性が記述される（Ａ→Ｂ）。ＤＩシステムはこのような依存性を解釈すると、Ｂというリソースを構築し、コードを挿入したり、setterメソッドを利用したり、コンストラクタからの指定を行う等で、リソースＢをリソースＡに提供する。
【０００７】
非特許文献１では、ＤＩをテストシステムに利用するという具体的な事例が開示されている。ここでは、ＤＩに基づいたコンポーネントとして、外部に対する依存が極力取り除かれていることを利用して単体テストを容易にするテスト方法が開示されている。
【非特許文献１】MemoryDump、DependencyInjection for Unit Tests、［online］、［平成１７年１１月２８日検索］  ［http://jroller.com/page/ara_e/20040717#dependency_injection_for_unit_tests］
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、非特許文献１では、単に、単体テストシステムを構築するための依存性注入の方法が開示されているに過ぎず、複数のリソース（実行環境）が依存性注入されるシステムの統合テストを対象にしたテスト方法、テストシステムを開示する文献ではない。
【０００９】
上述のように、アプリケーションのアセット化の普及などにより、近年のアプリケーションは、多様なシステム構成上で実行可能となるように、設計、実装されなければならないという要求が高まっている。例えば、複数のベンダーのデータベースへの接続クラスや、様々な形式の認証機構が利用できるように、アプリケーションの実装が行われている。このようなリソースを提供する様々なシステム構成上でアプリケーションが実行できることをテストで保証するためには、アプリケーションの結合テストを、サポートする全てのシステム構成上で実行する統合テストを実行する必要が生じる。しかし、非特許文献１は、依存性注入される複数のリソース各々に対して網羅的にアプリケーションの統合テストを実行することが可能な方法を開示した文献ではない。
【００１０】
本発明は、上記課題を解決するために、依存性注入される複数の実行環境各々に対してアプリケーションの統合テストを実行することが可能な方法、装置、およびそれを制御するプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の第１の形態によると、アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストする方法であって、アプリケーション・インターフェースを介してテストが実行されるアプリケーション（ＡＵＴ）に依存性注入される候補となるアプリケーションによって利用される実行環境依存の少なくとも一のリソース群（ＥＵＴ）をアプリケーションに注入するステップと、アプリケーションによって利用される実行環境依存のリソース群を注入されたアプリケーションに対して、テストを実行するステップと、を備える方法を提供する。
【００１２】
本発明の第２の形態によると、アプリケーションと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるシステムをテストする方法であって、アプリケーション・インターフェースを介してテストが実行されるアプリケーション（ＡＵＴ）に依存性注入される候補となる、一以上のリソース群（ＥＵＴ）を生成するステップと、生成するステップにて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションに注入するステップと、リソース群を注入されたアプリケーションに対して、テストを実行するステップと、一のリソース群と異なる他のリソース群が存在する場合に、他のリソース群に対して、注入するステップと、テストを実行するステップとを繰り返すステップと、を備える方法を提供する。
【００１３】
上記発明によれば、複数の実行環境にてテストが必要なアプリケーションに対して、依存性注入によるリソース群の注入方法を用いて、アプリケーションに依存性注入される候補となる一のリソース群をアプリケーションに注入し、一のリソース群を注入されたアプリケーションに対して、テストを実行する。そして、一のリソース群と異なる他のリソース群が存在する場合に、他のリソース群に対して、注入するステップと、テストを実行するステップとを繰り返すステップとを実行することで、複数のリソース群に対する統合テストを実行する。
【発明の効果】
【００１４】
本発明の手法によって、複数の実行環境にてテストが必要なアプリケーションに対して、依存性注入による実行環境の注入方法を用いて、依存性注入される複数の実行環境各々に対してアプリケーションの統合テストを実行することが可能な方法、システム、およびそれを制御するプログラムを提供することが可能である。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施形態について図を参照しながら説明する。
【００１６】
図１は、本発明の実施形態として、テストの対象となるコンピュータ・プログラムから構成されるシステム５０を示す。システム５０は、テストされる対象となるアプリケーション（以下、「ＡＵＴ」）５１と、このＡＵＴ５１に依存性注入する実行環境（以下、「ＥＵＴ」）５５とから構成される。
【００１７】
ＡＵＴ（Application  Under  Test）５１は、統合テストの対象となるアプリケーション・プログラム（以下、「アプリケーション」）又は、アプリケーション・プログラムが動作するシステムである。ここで、アプリケーションは、コンピュータ・プログラムから構成されるシステムのうち、アプリケーション・インターフェースを介して実行される。本明細書では、テストを実行する際の対象となるアプリケーションをＡＵＴと記載する。
【００１８】
アプリケーションは、ＥＵＴ５５のうち一以上の実行環境モジュール（以下、「ＥＥＲ」）が、アプリケーションに依存性注入されることで、実行が行われる。したがって、ＡＵＴ５１も同様に、ＥＵＴ５５のうち一以上の実行環境モジュールが、アプリケーションに依存性注入されることで、実行が行われる。すなわち、ＡＵＴ５１は、後述するＤＩコンテナによりＥＵＴが提供するＥＥＲと組み合わせられることで、実行可能になる。
【００１９】
ＥＵＴ（Execution  Environment  Under  Test）５５は、コンピュータ・プログラムから構成されるシステムのうち、アプリケーションに注入される実行環境であって、アプリケーションの実行のための環境プログラム、又はシステムである。ＥＵＴ５５は、ＥＥＲ５３のように複数のＥＥＲを含み、アプリケーションが実行される際に、各ＥＥＲ５３から構成される実行環境がアプリケーションに注入される。ここで、アプリケーションに注入される実行環境とは、具体的には、アプリケーションによって利用される実行環境依存のリソースであり、注入されるリソースが複数の場合には、リソース群のことである。したがって、ＡＵＴ５１のテストを実行する際には、ＥＵＴ５５を構成する各ＥＥＲ５３が、ＤＩコンテナによりＡＵＴに依存性注入され、テストが実行される。ここで、ＤＩコンテナとは、後述する依存性記述ファイル等の結合情報に基づいて、依存性の解決を行う装置又は機能である。
【００２０】
ＥＥＲ（Execution  Environment  Resource）５３は、ＥＥＲ５３に含まれる実行環境モジュール（上述のリソースに対応）である。例えば、アプリケーションが、DriverManagerを依存性注入されることで、実行する場合であれば、依存性注入される実行環境モジュールが、ベンダーＡ社DriverManagerとなる。したがって、ＡＵＴ５１の実行では、実行環境モジュールとして、例えば、ＥＥＲ５３のＡが、ベンダーＡ社DriverManagerとなる。ここで、一例として挙げた「DriverManager」は、データベース接続用インスタンスであり、Java（登録商標）のJDBCのデータベースアクセス用ライブラリにおける、一つのクラス名である。
【００２１】
ＥＥＲは、他のＥＥＲがさらに依存性注入される場合があってよい。すなわち、図１のＢ、Ｃに示したように、ＥＥＲ５３のＣが、ＥＥＲ５３のＢに依存性注入され、このＥＥＲが、ＡＵＴ５１に注入される。この場合では、アプリケーションを実行する際に、実行環境モジュール自身が、さらに、実行環境モジュールに依存性注入され、ここで依存性注入された実行環境モジュールが、さらに、アプリケーションに依存性注入される。
【００２２】
依存性注入とは、アプリケーション側が利用するリソースの結合を結合情報として記憶し、この結合情報を用いて、依存先の解決を行うことである。依存性注入についての詳細は、例えば、Martin  Fowlerのホームページ「Inversion  of  Control  Containers  and  the  Dependency  Injection  pattern」
http://www.martinfowler.com/articles/injection.htmlに公開されている。アプリケーションが依存性注入されている場合には、その依存先の解決は、ＤＩコンテナが実行する。依存性注入を利用するメリットとしては、アプリケーションや、システム側が提供する実行環境の結合方法が、全て依存性記述という形式で、一般的に記述できる点である。また、ＤＩコンテナが、依存性記述や独自のリソース解析結果より依存性を決定し、アプリケーションに依存性注入するリソースを選択、管理することができるため、ＤＩコンテナがアプリケーションの構成を管理することが可能になる。
【００２３】
図２は、テストの対象となるコンピュータ・プログラムから構成されるシステム１０、２０を示す。図２に示すように、例えば、アプリケーションがデータベースに接続するために、DriveManager１２ａを実行環境に要求し、ある実行環境ではベンダーＡ社DriveManager１２ｂが利用される。一方、ある実行環境ではベンダーＢ社DriveManager２１ｂが、アプリケーションに注入されて、DriveManagerとして利用される。この場合に、図２のシステム１０、システム２０に示すように、依存性を変更するだけで、統合テストのためのシステム構成を容易に変更することが可能である。すなわち、ＥＵＴ１５では、「アプリケーション  →  ベンダーＡ社DriveManager」、ＥＵＴ２５では、「アプリケーション  →  ベンダーＢ社DriveManager」と結合情報を記述するだけで、システム１０からシステム２０へ切り替え処理をＤＩコンテナが実行することができる。
【００２４】
統合テストとは、ＡＵＴに採用される全ての実行環境に対して行うテストである。すなわち、ＡＵＴに対してテストを行う際に、テスト対象となるアプリケーションに使用される一の実行環境（ＥＵＴ）を採用してテストを行うが、この一の実行環境（ＥＵＴ）として採用される全ての実行環境（ＥＵＴ）に対して、網羅的に行うテストが統合テストである。図２を例とすると、統合テストは、DriveManager１２ａとして、ベンダーＡ社DriveManager１２ｂをアプリケーションに依存性注入した場合のテストと、ベンダーＢ社DriveManager２１ｂを依存性注入した場合のテストの両方のテストである。
【００２５】
図３は、上述の統合テストを実行するための、テスト装置１の機能ブロック図を示す。テスト装置１は、情報、データの演算、制御を行う制御部１００と、情報、データが入力される入力部１５０と、情報、データが出力される出力部１６０と、情報、データが記憶される記憶部２００とを備え、コンピュータであってよい。テスト装置１は、通信回線ネットワークに接続し、この通信回線ネットワークと接続された外部端末と通信可能とする通信部（図示省略）を備えていてもよい。テスト装置１が通信部を備える場合に、テスト装置１が入力部１５０、出力部１６０を備えずに、外部端末からの遠隔操作により、情報、データの入力を受け、制御部１００が演算、制御した結果が外部端末に送信されて、外部端末の出力部に表示されてもよい。
【００２６】
図３では、ＤＩコンテナ１１０が、制御部１００に含まれる実施形態で説明したが、テスト装置１の制御部１００としては、テスト実行部１２０とテストカバレッジ管理部１３０とが備えられ、ＤＩコンテナ１１０が他のコンピュータにて動作する実施形態であってよい。すなわち、ＤＩコンテナ１１０が、テスト装置１と情報、データが通信可能な他のサーバにて動作してもよい。
【００２７】
制御部１００は、依存性注入の結合の解決を行うＤＩコンテナ１１０と、テストを実行するテスト実行部１２０と、統合テストのテスト範囲を管理するテストカバレッジ管理部１３０とを備え、例えば、中央演算処理ユニット（ＣＰＵ）であってよい。制御部１００は、後述するメインフロー処理、ＥＥＲリストの生成処理、ＥＵＴの生成処理、ＥＵＴ変換処理、シングルテスト実行処理、統合テスト実行処理、動的シングルテスト実行処理、動的統合テスト実行処理を実行する。
【００２８】
ＤＩコンテナ１１０は、依存性注入されるアプリケーションと、アプリケーションに依存性注入するＥＥＲに対して、さらに依存性注入するＥＥＲに対して処理を行う。ＤＩコンテナ１１０は、後述する依存性記述ファイル等の結合情報に基づいて、依存性の解決を行う。ＤＩコンテナ１１０は、ＥＥＲリストを生成するＥＥＲリスト生成部１１２と、テスト対象となるＥＵＴを生成するＥＵＴ生成部１１４を備える。
【００２９】
テスト実行部１２０は、テストケース及びＥＥＲ特有テストを読み込んでテストを実行する。ここで、テスト実行部１２０が実行するテストは、アプリケーション・インターフェースを介して読み込まれて実行されるテストケースと、ＥＥＲ特有のテストケースであるＥＥＲ特有テストとの両方を含む。ここで、ＥＥＲ特有テストとは、後述するように、一のＥＥＲの専用のテストであり、テストの対象となるＥＥＲの状態を把握するためのテストである。なお、テスト実行部１２０が、ＤＩコンテナ１１０に含まれていてもよい。なお、本明細書におけるテストケースとは、統合テストのためのテストケースであってもよいし、一のＥＵＴのためのテスト（以下「シングルテスト」）のためのテストケースであってよい。
【００３０】
テストカバレッジ管理部１３０は、シングルテストとしてテスト済みのＥＵＴと、テスト未実行のＥＵＴとを管理し、全てのＥＵＴに対してテスト実行部１２０にテストを実行させることで、統合テストを行う。
【００３１】
記憶部２００は、アプリケーションを記憶したアプリケーション記憶部２０２、ＥＥＲを記憶したＥＥＲ記憶部２０４と、ＥＵＴを記憶したＥＵＴ記憶部２０６と、依存性記述ファイルを記憶した依存性記述記憶部２０８と、ＥＥＲリストを記憶したＥＥＲリスト記憶部２１０と、テストケースを記憶したテストケース記憶部２１２と、ＥＥＲ特有テストを記憶したＥＥＲ特有テスト記憶部２１４とを備える。記憶部２００は、例えば、メモリ、ハードディスク等であってよく、制御部１００により各情報、データが記憶される。
【００３２】
図４に基づいて、制御部１００が実行するメイン処理フローについて説明する。このメイン処理フローは、静的な依存性決定方法によるテスト実行方法についてのメイン処理フローである。ここで、「静的なテスト」とは、テスト実行の前に、依存性注入されるＥＵＴが既に列挙され、実行されるテストである。これに対して、「動的なテスト」とは、後述するように、テストケースを実行する際に、事前にＥＵＴを生成せずに、テストケースを実行する際、ＡＵＴがＤＩコンテナに対して、ＥＥＲを要求した時に、ＥＥＲを列挙し、列挙したＥＥＲを注入してテストを実行し、統合テストとして注入されるべき全てのＥＵＴに対して行うテストである。
【００３３】
静的な依存性決定方法によるテストを実行する前に、制御部１００のＥＥＲリスト生成部１１２は、ＥＥＲリストの生成処理を行う（ステップＳ０１）。ＥＥＲリストの生成処理については、図５に基づいて後述するが、ＡＵＴに依存性注入されるＥＥＲのうち、代替される２以上のＥＥＲを一つのＥＥＲリストとして、複数のＥＥＲリスト群を生成する。
【００３４】
次に、ＥＵＴ生成部１１４は、生成されたＥＥＲリストからＥＵＴの生成処理（ステップＳ０２）を行う。すなわち、ＥＥＲリストからＥＥＲを抽出して、ＥＵＴを生成する。そして、テスト実行部１２０は、ＥＵＴ生成部１１４により生成された全てのＥＵＴに対して、テスト実行処理を行う（ステップＳ０３）ことで、統合テストを行う。以下、静的な依存性決定方法による各処理について詳細に説明する。
【００３５】
ＥＥＲリストを説明するために、テスト対象となるＡＵＴに依存性注入されるＥＵＴ、ＥＥＲについて説明する。図６は、ＡＵＴに依存性注入されるＥＵＴを示す概念図である。図６に示すように、ＡＵＴ６０は、ＥＥＲ６１ａ〜ｃのいずれか一つが依存性注入されてテストが実行される。すなわち、ＥＥＲ６１ａ、ＥＥＲ６１ｂ、ＥＥＲ６１ｃは代替的に注入される実行環境モジュールである。したがって、ＡＵＴ６０に対して、統合テストを行うためには、ＥＥＲ６１ａを含むＥＵＴ６５ａと、ＥＥＲ６１ｂを含むＥＵＴ６５ｂと、ＥＥＲ６１ｃを含むＥＵＴ６５ｃとに対して、それぞれテストを行う必要がある。
【００３６】
図７は、図６と同様に、ＡＵＴに依存性注入されるＥＵＴを示す概念図である。図７に示すように、ＡＵＴ７０は、ＥＥＲ７１ａ、７１ｂのいずれかが依存性注入されてテストが実行される。ここで、ＥＥＲ７１ａは、さらに、ＥＥＲ７２ａあるいはＥＥＲ７２ｂが依存性注入される。したがって、この場合に必要な統合テストは、ＡＵＴ７０のテストの実行において要求されるＥＥＲの組合せとなる。一つの組合せとして、ＥＥＲ７１ｂのみを依存性注入する場合がある。これが、ＥＵＴ７５ｃである。ＥＥＲ７２ａがＥＥＲ７１ａに依存性注入され、ＥＥＲ７２ａが依存性注入されたＥＥＲ７１ａがＡＵＴ７０に依存性注入される場合がある。これが、ＥＵＴ７５ｂである。さらに、ＥＥＲ７２ｂがＥＥＲ７１ａに依存性注入され、ＥＥＲ７２ｂが依存性注入されたＥＥＲ７１ａがＡＵＴ７０に依存性注入される場合がある。これが、ＥＵＴ７５ａである。
【００３７】
このように、ＥＥＲがさらに依存性注入される場合には、ＡＵＴに対してテストを実行するために必要な最低限のＥＥＲの組合せをＥＵＴとして列挙し、列挙されたＥＵＴ全てに対して統合テストを行う必要がある。
【００３８】
ＥＥＲリストは、上述のような統合テストを実行するためにＡＵＴに依存性注入されるＥＥＲのうち、ＥＥＲ７１ａとＥＥＲ７１ｂのように、代替される２以上のＥＥＲを一つのグループとしたリストである。
【００３９】
ＥＥＲリスト生成部１１２が実行するＥＥＲリスト生成処理について、図５に基づいて説明する。ＥＥＲリスト生成部１１２は、ＡＵＴに対応したアプリケーションの実行に必要な一のＥＥＲを抽出する（ステップＳ１０）。次に、ＥＥＲリスト生成部１１２は、抽出したＥＥＲの代替となる他のＥＥＲの抽出を行う（ステップＳ１１）。次に、ＥＥＲリスト生成部１１２は、抽出した一のＥＥＲと他のＥＥＲにより、一のＥＥＲリストを生成する（ステップＳ１２）。
【００４０】
図８は、ＥＥＲリストを示す概念図である。図８に示すように、アプリケーションの実行のためには、ＥＥＲとしてＥＥＲ８１、ＥＥＲ８２を必要とする。ここで、ＥＥＲ８１に依存性注入されるＥＥＲが、ＥＥＲ８１ａ〜ｃである。これらのＥＥＲ８１ａ〜ｃは、代替されるＥＥＲとして、ＥＥＲリスト７３ａを形成する。
【００４１】
次に、ＥＥＲリスト生成部１１２は、他のＥＥＲがさらに依存性注入されるかを判断する（ステップＳ１３）。図８の例では、ＥＥＲ８１は、他のＥＥＲが依存性注入されないので、さらにＥＥＲが依存性注入されることはないと判断して、ステップＳ１５に移行する。ステップＳ１５にて、ＥＥＲリスト生成部１１２は、アプリケーションの実行に必要な他のＥＥＲがあるかを判断する。この場合には、アプリケーションの実行には、ＥＥＲ８２にＥＥＲ８２ａ、あるいはＥＥＲ８２ｂが依存性注入されるべきであるため、処理がステップＳ１０へと戻り、ＥＥＲ８２ａに対して、ＥＥＲリストを作成する（ステップＳ１１、Ｓ１２）。
【００４２】
ここで、ＥＥＲ８２ａには、ＥＥＲ８３ａが依存性注入されることで、アプリケーションが実行される。したがって、ＥＥＲリスト生成部１１２は、ＥＥＲ８３ａがＥＥＲ８２ａに依存性注入されると判断し（ステップＳ１３）、ステップＳ１４にて、依存性注入されるＥＥＲ８３ａを抽出する。ＥＥＲリスト生成部１１２は、ＥＥＲ８３ａを抽出した後に、ＥＥＲ８３ａの代替となる他のＥＥＲを抽出し（ステップＳ１１）、ＥＥＲ８３ａの代替となる他のＥＥＲにより、ＥＥＲリスト７３ｃを生成する（ステップＳ１２）。さらに、ＥＥＲ８３ａが依存性注入される場合には、ＥＥＲリスト生成部１１２は、この依存性注入されるＥＥＲに対して、同様の処理（ステップＳ１１、Ｓ１２の処理）を実行する。
【００４３】
最後に、アプリケーションの実行においては、ＥＥＲリスト生成部１１２は、ＥＥＲ８１、ＥＥＲ８２以外に必要な他のＥＥＲが無いことを判断して（ステップＳ１５）、ＥＥＲリスト生成処理を終了する。
【００４４】
なお、ＥＥＲリスト生成部１１２により生成されたＥＥＲリストは、ＥＥＲリスト記憶部２１０に記憶される。
【００４５】
上述のＥＥＲリスト生成処理では、ステップＳ１０が、アプリケーションの実行に必要な一のＥＥＲを抽出するステップであるが、動的なテストを実行する場合には、ＡＵＴの実行に必要な一のＥＥＲが抽出される。すなわち、ステップＳ１０が、「ＡＵＴの実行に必要な一のＥＥＲの抽出」となり、テストの実行とともにＥＥＲリスト生成部１１２によりＥＥＲリストが生成される。
【００４６】
図９は、静的なテストを実行する際のＥＵＴの生成処理を示すフローチャートである。ＥＵＴ生成部１１４が実行するＥＵＴの生成処理について、図９、図１０に基づいて説明する。図１０は、ＥＥＲリストからＥＵＴを生成することを示す概念図である。図１０に示すように、ＥＥＲリスト生成部１１２が生成したＥＥＲリスト７３ａ〜ｃから、ＥＵＴ生成部１１４は、アプリケーションに依存性注入される候補となるＥＵＴ９０ａ〜ｉを生成する。
【００４７】
ＥＵＴ生成部１１４は、アプリケーションの実行に必要なＥＥＲの一の組合せを抽出する（ステップＳ２０）。すなわち、ＥＵＴ生成部１１４は、アプリケーションを実行するために、必要な一のＥＥＲを一のＥＥＲリストから抽出して、全てのＥＥＲリストからこの抽出を行うことで、一のＥＥＲの組合せを抽出する（ステップＳ２０）。
【００４８】
図１０の例によれば、図８のアプリケーション（図ではＡＵＴに対応）を実行するためには、ＥＥＲとしてＥＥＲ８１、ＥＥＲ８２が依存性注入される必要がある。したがって、ＥＵＴ生成部１１４は、例えば、ＥＥＲリスト７３ａから一のＥＥＲ８１ａを抽出し、ＥＥＲリスト７３ｂから、ＥＥＲ８２を抽出する。これにより、一のＥＥＲ組合せ（ＥＥＲ８１ａ、ＥＥＲ８２）が生成される。
【００４９】
ＥＵＴ生成部１１４は、この一のＥＥＲ組合せを含むＥＵＴをＥＵＴ記憶部２０６に記憶する（ステップＳ２１）。すなわち、ＥＵＴ生成部１１４は、一のＥＥＲ組合せ（ＥＥＲ８１ａ、ＥＥＲ８２）を含めて、ＥＵＴ９０ｂを生成する。次に、ＥＵＴ生成部１１４は、他のＥＥＲ組合せがあるかを判断する（ステップＳ２２）。図１０の例によれば、ＥＵＴ生成部１１４は、他のＥＥＲの組合せが存在するので、ステップＳ２０に戻り、他のＥＥＲの組合せに対して、ＥＵＴを生成する。
【００５０】
すなわち、ＥＵＴ生成部１１４は、ＥＥＲ組合せとして（例えば、ＥＥＲ８１ｂとＥＥＲ８２ａとＥＥＲ８３ａの組合せ、ＥＥＲ８１ｃとＥＥＲ８３ｂの組合せ等）に対して、同様の処理を行い、ＥＵＴ９０ａからＥＵＴ９０ｉまでのＥＵＴを生成する。
【００５１】
上述のＥＵＴ生成処理では、ステップＳ２０が、アプリケーションの実行に必要なＥＥＲの一の組合せを抽出するステップであるが、動的なテストを実行する場合には、ＥＵＴは生成されず、テストの実行時にＡＵＴの実行に必要なＥＥＲの一の組合せがＥＥＲリストから抽出される。
【００５２】
次に、図１１に基づいて、ＥＵＴ変換処理について説明する。ＥＵＴ生成部１１４は、一のＥＵＴを依存性記述ファイルに変換する。
【００５３】
依存性記述ファイルは、アプリケーション（ＡＵＴ）又は実行環境モジュール（ＥＥＲ）に記述されている情報のうち、依存性の結合に関する情報を抽出した記述ファイルである。ＤＩコンテナ１１０は、この依存性記述ファイルを読み込むことで、アプリケーションに対しての依存性注入あるいは、実行環境モジュールに対する注入の解決を行う。
【００５４】
ＥＵＴ生成部１１４は、生成された一のＥＵＴを選択して（ステップＳ３０）、この一のＥＵＴに対応した依存性記述ファイルを生成する（ステップＳ３１）。そして、ＥＵＴ生成部１１４は、他のＥＵＴが存在するかを判断して、他のＥＵＴがあると判断した場合には、ステップＳ３０に処理を移す（ステップＳ３２）。
【００５５】
次に、図１２から図１４に基づいて、テスト実行部１２０が静的なテストを実行するテスト実行処理について説明する。テスト実行部１２０が実行する動的なテストについては、図１５、図１６に基づいて後述する。
【００５６】
ＥＵＴ生成部１１４により生成された複数のＥＵＴに対して、テスト実行部１２０が個々にテストを実行する。
【００５７】
ここで、テスト実行部１２０が実行するテストは、図１４に示すように、テストケース１３２を、アプリケーション・インターフェースを介して実行するテストと、一のＥＥＲのためのＥＥＲ特有テスト１３３との２つのテストが実行される。テストケースは、ＡＵＴ１３０をテストするために記述されるプログラムであり、アプリケーション・インターフェースを介してデータの入出力が行われるテストである。
【００５８】
ＥＥＲ特有テストは、一のＥＥＲのために必要なテストである。例えば、上述のテストケースのみでは、ＥＥＲの内部状態をテスト実施者が知らなくても、テストケースの最終的な結果として問題がないと出力する場合がある。ＥＥＲ特有テストは、このような場合に、テストケースで動作したＥＥＲの内部状態をテスト実施者に提供する。ＥＥＲ特有テストは、テストケースが実行されている所定の時点で、テストケースから読み出されて（メソッドの読み出し）、実行され、当該ＥＥＲのためのテスト結果を出力する。
【００５９】
テストケース、ＥＥＲ特有テストは、テスト実行前に、それぞれ、テストケース記憶部２１２とＥＥＲ特有テスト記憶部２１４に記憶される。
【００６０】
図１２は、テスト実行部１２０が実行する統合テスト実行処理のフローチャート図である。テスト実行部１２０は、一の依存性記述ファイルを選択する（ステップＳ４０）。一の依存性記述ファイルは、上述のように一のＥＵＴに対応している。したがって、例えば、図１０のＥＵＴ９０ｂに対応した依存性記述ファイルは、結合情報として、アプリケーション、ＥＥＲ８１ａ間の結合情報と、アプリケーション、ＥＥＲ８２ｂ間の結合情報とを含む。
【００６１】
次に、テスト実行部１２０は、選択された依存性記述ファイルに基づいて、この依存性記述ファイルに対応したＥＵＴのシングルテストを実行する（ステップＳ４１）。シングルテスト実行処理については、図１３に基づいて後述する。シングルテスト実行処理が終了した後に、テスト実行部１２０は、他の依存性記述ファイルが存在するかを判断（ステップＳ４２）して、他の依存性記述ファイルが存在する場合には、テスト実行部１２０は、他の依存性記述ファイルに対して、シングルテストを実行する（ステップＳ４１）。他の依存性記述ファイルが存在しないと判断（ステップＳ４２）した場合には、統合テストを終了する。
【００６２】
図１３は、シングルテスト実行処理を示すフローチャートを示す。図１３と図１４に基づいて、テスト実行部１２０が実行するシングルテスト実行処理について説明する。図１４は、ＡＵＴに対してテストを実行する際の概念図を示す。ＡＵＴ１３０に対して、ＡＰＩ（アプリケーション・インターフェース）１３５を介して、テスト実行部１２０は、テストケース１３２の実行を開始する（ステップＳ５０）。そして、テスト実行部１２０またはＤＩコンテナ１１０は、このシングルテストの依存性記述ファイルから一のＥＥＲを依存性注入して、テストケースを実行する。
【００６３】
そして、テスト実行部１２０は、テストケースを実行するうちに、ＥＥＲ特有テストケースが実行されるかを判断する（ステップＳ５１）。テスト実行部１２０は、ＥＥＲ特有テストケースではなく、通常のテストケースであれば、継続してテストケースを実行する（ステップＳ５４）。ここで、テスト実行部１２０は、ＥＥＲ特有テスト記憶部２１４に記憶されたＥＥＲ特有テストに対応するＥＥＲが依存性注入された場合に、このＥＥＲに対応するＥＥＲ特有テストケースを実行する。
【００６４】
テスト実行部１２０は、テストケースを実行するうちに、ＥＥＲ特有テストケースが実行されると判断した場合には、ＥＥＲ特有テスト記憶部２１４から対応したＥＥＲ特有テスト１３３ａを読み出して（依存性注入して）（ステップＳ５２）、ＥＥＲ１３１ａに対する特有テストを実行する（ステップＳ５３）。次に、テスト実行部１２０は、テストケースが終了であるかを判断する（ステップＳ５４）。ここで、テストケースが終了でないと判断した場合には、ステップＳ５１に処理を移す。
【００６５】
ここで、ＡＵＴに依存性注入されるＥＥＲがさらにＥＥＲを依存性注入される場合にも、ステップＳ５１に処理を移して、ＥＥＲに依存性注入されるＥＥＲに対して、ＥＥＲ特有テストが実行されてよい。このように、各実行環境モジュールに応じた特有テストが依存性注入され、テストが行われるため、ＡＵＴのみならず、実行環境モジュールを含めたテストを実行することが可能である。
【００６６】
次に、図１５、図１６に基づいて、動的なテストの実行処理について説明する。図１５は、テスト実行部１２０が実行する動的な統合テストの実行処理である。テスト実行部１２０は、テストの実行を開始して（ステップＳ６０）、動的テストケース実行処理（ステップＳ６１）を実行する。そして、テスト実行部１２０は、依存性注入される他のＥＥＲで、未だテストケースが実行されていないＥＥＲの組み合わせがあるかを判断して（ステップＳ６２）、全てのＥＥＲに対してテストを実行する。ここで、テスト実行部１２０が、テストカバレッジ管理部１３０に対して、全てのＥＥＲに対してテストを実行したかを確認し、テストカバレッジ管理部１３０の判断で、未だテストケースが実行されていないＥＥＲの組合せを判断してもよい。例えば、テストカバレッジ管理部１３０は、テストを実行していないＥＥＲの組合せを判断する際に、テスト実施者からＥＥＲの組合せとして必要なテストの実行回数や、テストとして必要なＥＥＲの組合せなどに関するデータの入力を受け付けて、このデータに基づいて判断してもよい。
【００６７】
図１６に基づいて、動的テストケース実行処理について説明する。テスト実行部１２０が、ＥＥＲリストからＥＥＲをＤＩコンテナ１１０に対して要求する（ステップＳ７０）。この要求に対して、テスト実行部１２０は、ＤＩコンテナ１１０が提供したＥＥＲに対してテストを実行する（ステップＳ７１）。ＤＩコンテナ１１０は、ＥＥＲリストからＥＥＲを抽出して、テスト実行部１２０にＥＥＲを提供してもよい。次に、テスト実行部１２０が、テストを実行していないＥＥＲの組合せを判断する（ステップＳ７２）。例えば、ＥＥＲリストから、未だテストが実行されていないＥＥＲの組合せを判断する。ここで、テスト実行部１２０が、テストカバレッジ管理部１３０に対して、全てのＥＥＲに対してテストを実行したかを確認し、テストカバレッジ管理部１３０の判断で、未だテストケースが実行されていないＥＥＲの組合せを判断してもよい。
【００６８】
次に、一例として、ＤＩコンテナが使用する依存性記述ファイルを示す。
（リスト１）
<beans>
<bean id="child"  class="Child">
<property name="name">
<value>child1</value>
</property>
<property name="no">
<value>1</value>
</property>
</bean> 
<bean id="parent"  class="Parent">
<property name="child">
<ref bean="child"/>
</property>
<property name="name">
<value>parent</value>
</property>
</bean>
</beans>
【００６９】
リスト１では、parentというリソースが、childというリソースに依存していることを示している。すなわち、parentは、childを依存性注入することで、実行可能となる。このように、<bean  id="parent"  class="Parent">、<property  name="child">の記述が、依存性注入の解決のための、結合情報に対応する。
【００７０】
（リスト２）
<beans>
<bean id=”child”>
</bean>
<bean id="parent"  class="Parent">
<property name="child">
<ref bean="child"/>
</property>
<property name="name">
<value>parent</value>
</property>
</bean>
</beans>
【００７１】
リスト２では、リスト１と同様にparentというリソースが定義されているが、childというリソースは宣言されているだけで、定義は含まない。childの定義は、別ファイルとしてリスト３のように記述される。リスト３には、childの選択肢として“Child1”,
“Child2”, “Child3”と名づけられたＥＥＲが定義されている。各ＥＥＲには、ＥＥＲの実装に依存したテストケース（”Child1SpecificTestCase”,“Child2SpecificTestCase”,“Child3SpecificTestCase”）が定義されている。
【００７２】
（リスト３）
<eer-list id=”child">
<bean class=”Child1”>
<property name="name">
<value>child1</value>
</property>
<property name="no">
<value>1</value>
</property>
<testcase class=”Child1SpecificTestCase”/>
</bean> 
<bean class=”Child2”>
<property name="name">
<value>child2</value>
</property>
<property name="no">
<value>1</value>
</property>
<testcase class=”Child2SpecificTestCase”/>
</bean> 
<bean class=”Child3”>
<property name="name">
<value>child3</value>
</property>
<property name="no">
<value>1</value>
</property>
<testcase class=”Child3SpecificTestCase”/>
</bean> 
</eer-list>
【００７３】
最後に、実施例として、上記実施形態のテスト方法を、銀行システムに適用した例について説明する。図１７に示すように、ＡＵＴに対応するアプリケーションが、銀行システム３００であり、この銀行システム３００に依存性注入される実行環境モジュールが、データベース３０１と、通知機能３０２である。ここで、銀行システム３００に対して、データベース３０１には、ベンダーＡ社データベース３０１ａ、ベンダーＢ社データベース３０１ｂ、ベンダーＣ社データベース３０１ｃの実行環境の統合テストを要求される。また、銀行システム３００に対して、通知機能３０２では、携帯電話機能３０２ａ、Ｅ−ｍａｉｌ３０２ｂの実行環境の統合テストを要求される。ここで、携帯電話機能３０２ａとは、携帯電話を利用して通知を行う機能を備えたモジュールのことである。Ｅ−ｍａｉｌ３０２ｂとは、Ｅ−ｍａｉｌを利用して通知を行う機能を備えたモジュールのことである。さらに、携帯電話機能３０２ａにおいては、Ｙ社ネットワーク３０３ａ、Ｚ社ネットワーク３０３ｂ用のモジュールに対して、統合テストを行う必要がある。
【００７４】
テストケース１から３が、アプリケーション・インターフェース３０５を介して実行される。例えば、テストケース１とは、銀行システムの「口座を開く」テストであり、テストケース２とは、銀行システムの「お金を預ける」テストであり、テストケース３とは、銀行システムの「お金を引き出す」テストである。
【００７５】
この銀行システム３００は、外部のプログラムから、「口座を開く（口座番号を指定）」「お金を預ける（口座番号と金額を指定）」「お金を引き出す（口座番号と金額を指定）」という実行を受け付ける。これらの処理を実行した場合、銀行システム３００に接続しているデータベース３０１にその処理が実行される。また、処理が終了すると、ユーザーに対して処理終了の通知が届く。銀行システムの機能用件として、以下のＥＥＲを依存性注入しても実行できる必要がある。
（１）データベースとして、各ベンダーＡ社、Ｂ社、Ｃ社のデータベースが実行可能。
（２）通知機能として携帯電話用、E-mail用が実行可能。
（３）携帯電話用の通知機能には、Ｙ社ネットワーク用とＺ社ネットワーク用の通知機能が実行可能。
【００７６】
これらのシステム上で、以下のテストを実行するものとする。
（１）上記処理を行って、その処理がデータベースに反映されているかを調べる。
方法:データベースの特定のテーブルの特定のレコードにきちんと値が入力されているか調べる。
（２）それぞれの処理を行って、その通知機能がきちんと働いているかを調べる。
方法:通知コンポーネントごとに特有な確認方法（特有テスト）で確認する。
【００７７】
（テストケース：Johnの口座を開く）
実行するプログラム、システム、部：コマンド（変数）
銀行システム：口座を開く（“John”）
ＤＩコンテナ：コンポーネント取得（“銀行システム”，“データベース”）
データベースコンポーネント：口座登録確認（“John”）
ＤＩコンテナ：コンポーネント取得（“銀行システム”，“通知”）
ＤＩコンテナ：コンポーネントテストケース取得（通知コンポーネント，“登録通知確認”）
登録通知確認用コンポーネント：実行（“John”）
【００７８】
上記のように記述されたテストケースを実行する際に、例えば、依存性注入される携帯電話機能３０２ａの口座登録の通知のテストを確認するテストが必要になる。このように、依存性注入される特有のテストとして、図１７では、携帯電話口座登録通知確認３１０ａ、Ｙ社ネットワーク用口座登録通知確認３２０ａ、Ｚ社ネットワーク用口座登録通知確認３２０ｂを示した。以下、これらのＥＥＲ特有テストの一例を示す。
【００７９】
（テストケース：携帯電話用口座登録通知確認）
（１）ＤＩコンテナ：コンポーネント取得（“携帯電話用口座登録通知コンポーネント”，“種類”）
（２）種類コンポーネント：実行（口座名）
【００８０】
（テストケース：E-mail用口座登録通知確認）
E-mail送信済みリストに口座登録確認メールの有無を調べる（口座名）
【００８１】
（テストケース：Ｙ社ネットワーク用口座登録通知確認）
Ｙ社ネットワーク用送信済みリストに口座登録確認メールの有無を調べる（口座名）
【００８２】
（テストケース：Ｚ社ネットワーク用口座登録通知確認）
Ｚ社ネットワーク用送信済みリストに口座登録確認メールの有無を調べる（口座名）
【００８３】
上記実施例に係る方法、システムを使用することで、異なるシステム構成をサポートするアプリケーションの統合テストを、自動化することが可能となる。また、一度作成した依存性の設定、サポートする依存性リストを、アプリケーションと切り離して管理できるＤＩコンテナの特徴により、テストに必要な情報の再利用性が高まる。さらに、アプリケーションの統合テストの自動化が実現することにより、バグの早期発見、デバッグ効率の促進、テストレポートの整備、簡単なテスト実行、テスターの生産性の向上、テストの人為的ミスの軽減、テスト方法の保存など、様々な効果を得ることができる。これまで、アプリケーションのロジックのテストを中心に、テストの自動化手法が提案されてきたが、本発明により、テストを実行する環境の構築に関しても、自動化の効果を得ることができるようになる。上記実施例で使用する依存性の設定、サポートする依存性リストは、一のアプリケーションのみに適用可能なものではなく、その他の様々なアプリケーションに利用可能である。例えば、２つのアプリケーションが、同じコンテナを利用する場合、そのコンテナに対する依存性に関する依存性の設定、サポートする依存性リストは、共有することができる。アセット等、開発物の再利用性が求められる現在、同じコンテナを利用する機会は多くなることは予想され、それらに対するテストに必要な情報を再利用することは、非常に有用である。
【００８４】
以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【００８５】
本発明において一つの実施形態として説明したプログラムのテスト方法は、コンピュータ上のシステムまたはコンピュータにその機能を実行させるプログラムによって実現可能である。また、上記プログラムを格納する記録媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム（または、装置または機器）あるいは伝搬媒体であることができる。コンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。
【図面の簡単な説明】
【００８６】
【図１】本発明の好適な実施形態におけるテストの対象となるコンピュータ・プログラムから構成されるシステム５０を示す図である。
【図２】本発明の好適な実施形態におけるテストの対象となるコンピュータ・プログラムから構成されるシステム１０、２０を示す図である。
【図３】本発明の好適な実施形態におけるテスト装置１の機能ブロック図である。
【図４】メインフロー処理を示すフローチャートである。
【図５】ＥＥＲリストの生成処理を示すフローチャートである。
【図６】ＡＵＴに依存性注入されるＥＵＴを示す概念図である。
【図７】ＡＵＴに依存性注入されるＥＵＴを示す概念図である。
【図８】ＥＥＲリストを示す概念図である。
【図９】ＥＵＴの生成処理を示すフローチャートである。
【図１０】ＥＥＲリストからＥＵＴを生成することを示す概念図である。
【図１１】ＥＵＴ変換処理を示すフローチャートである。
【図１２】統合テスト実行処理を示すフローチャートである。
【図１３】シングルテスト実行処理を示すフローチャートである。
【図１４】ＡＵＴに対してテストを実行する際の概念図である。
【図１５】動的テスト実行処理を示すフローチャートである。
【図１６】動的テストケース実行処理を示すフローチャートである。
【図１７】銀行システムに対して、本実施例を適用したことを示す概念図である。
【符号の説明】
【００８７】
１  テスト装置
１００  制御部
１１０  ＤＩコンテナ
１１２  ＥＥＲリスト生成部
１１４  ＥＵＴ生成部
１２０  テスト実行部
１３０  テストカバレッジ管理部
１５０  入力部
１６０  出力部
２００  記憶部
【図１】
2007172269.tif 000003
【図２】
2007172269.tif 000004
【図３】
2007172269.tif 000005
【図４】
2007172269.tif 000006
【図５】
2007172269.tif 000007
【図６】
2007172269.tif 000008
【図７】
2007172269.tif 000009
【図８】
2007172269.tif 000010
【図９】
2007172269.tif 000011
【図１０】
2007172269.tif 000012
【図１１】
2007172269.tif 000013
【図１２】
2007172269.tif 000014
【図１３】
2007172269.tif 000015
【図１４】
2007172269.tif 000016
【図１５】
2007172269.tif 000017
【図１６】
2007172269.tif 000018
【図１７】
2007172269.tif 000019
【手続補正書】
【提出日】平成19年1月25日(2007.1.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをコンピュータがテストする方法であって、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソース群と、を記憶するステップと、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる少なくとも一のリソース群を読み出して、当該一のリソース群を前記記憶されたアプリケーションのプログラムに注入するステップと、
前記アプリケーションのプログラムによって利用される実行環境依存のリソース群を注入されたアプリケーションのプログラムに対して、テストを実行するステップと、
を備える方法。
【請求項２】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをコンピュータがテストする方法であって、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソース群と、を記憶するステップと、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる一のリソース群を読み出して、当該一のリソース群を前記記憶された前記アプリケーションのプログラムに注入するステップと、
前記一のリソース群を注入されたアプリケーションのプログラムに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を備える方法。
【請求項３】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをコンピュータがテストする方法であって、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソースと、を記憶するステップと、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる、一以上のリソース群を前記記憶されたリソースに基づいて生成するステップと、
前記生成するステップにて生成された一以上のリソース群のうち、一のリソース群を読み出して、当該一のリソース群を前記記憶されたアプリケーションのプログラムに注入するステップと、
前記リソース群を注入されたアプリケーションのプログラムに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を備える方法。
【請求項４】
前記生成するステップにて生成された一以上の全てのリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行する請求項３に記載の方法。
【請求項５】
前記リソース群は、一以上の実行環境モジュールを含み、
前記注入するステップにて、前記アプリケーションのプログラムに、前記一以上の実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションのプログラムに注入する、請求項３に記載の方法。
【請求項６】
前記実行環境モジュールは、さらに、一以上の他の実行環境モジュールを含み、
前記注入するステップにて、前記実行環境モジュールに対して、前記一以上の他の実行環境モジュールを注入し、前記アプリケーションのプログラムに、前記一以上の他の実行環境モジュールが注入された実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションのプログラムに注入する、請求項５に記載の方法。
【請求項７】
前記リソース群は、二以上の実行環境モジュールを含み、
前記生成するステップでは、前記リソース群を前記一以上の実行環境モジュールの組合せにより生成する、請求項５に記載の方法。
【請求項８】
前記テストを実行するステップでは、前記リソース群を注入されたアプリケーションのプログラムに対して、アプリケーション・インターフェースを介して実行されたテストケースによりテストを実行する、請求項５に記載の方法。
【請求項９】
前記テストを実行するステップでは、前記実行環境モジュールに対して、さらに注入された実行環境モジュールを、前記テストケースに提供するステップを含む、請求項８に記載の方法。
【請求項１０】
前記実行環境モジュールのためのテストを実行するステップを含む、請求項５に記載の方法。
【請求項１１】
前記実行環境モジュールのためのテストを実行するステップでは、前記アプリケーションのプログラムに対して注入された実行環境モジュールに応じて、当該実行環境モジュールのためのテストを選択して実行する、請求項１０に記載の方法。
【請求項１２】
アプリケーションのプログラムと、このアプリケーションによって利用される実行環境依存のリソース群とから構成されるプログラムをテストするテスト装置であって、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソース群と、を記憶する記憶部と、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる少なくとも一のリソース群を読み出して、当該一のリソース群を前記記憶されたアプリケーションのプログラムに注入するＤＩコンテナと、
前記一のリソース群を注入されたアプリケーションのプログラムに対して、テストを実行するテスト実行部と、を備え、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記ＤＩコンテナによる注入と、前記テスト実行部によるテストを実行する、コンピュータ・プログラムを読み取り可能なテスト装置。
【請求項１３】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをテストするテスト装置であって、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソースと、を記憶する記憶部と、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションのプログラムに依存性注入される候補となる、一以上のリソース群を前記記憶されたリソースに基づいて生成する実行環境生成部と、
前記実行環境生成部にて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションのプログラムに注入するＤＩコンテナと、
前記リソース群を注入されたアプリケーションのプログラムに対して、テストを実行するテスト実行部と、を備え、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記ＤＩコンテナによる注入と、前記テスト実行部によるテストを実行する、コンピュータ・プログラムを読み取り可能なテスト装置。
【請求項１４】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをテストするためのプログラムであって、コンピュータに、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソース群と、を記憶するステップと、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる一のリソース群を読み出して、当該一のリソース群を前記記憶されたアプリケーションのプログラムに注入するステップと、
前記一のリソース群を注入されたアプリケーションのプログラムに対して、テストを実行するステップと、を実行させ、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行させる、コンピュータ・プログラム。
【請求項１５】
アプリケーションのプログラムと、このアプリケーションのプログラムによって利用される実行環境依存のリソース群とから構成されるプログラムをテストするためのプログラムであって、コンピュータに、
アプリケーションのプログラムと、当該アプリケーションのプログラムによって利用され、実行環境依存する少なくとも一のリソースと、を記憶するステップと、
アプリケーション・インターフェースを介してテストが実行されるアプリケーションに依存性注入される候補となる、一以上のリソース群を前記記憶されたリソースに基づいて生成するステップと、
前記生成するステップにて生成された一以上のリソース群のうち、一のリソース群を前記アプリケーションのプログラムに注入するステップと、
前記リソース群を注入されたアプリケーションのプログラムに対して、テストを実行するステップと、
前記一のリソース群と異なる他のリソース群が存在する場合に、前記他のリソース群に対して、前記注入するステップと、前記テストを実行するステップとを繰り返すステップと、
を実行させる、コンピュータ・プログラム。
【請求項１６】
前記生成するステップにて生成された一以上の全てのリソース群に対して、前記注入するステップと、前記テストを実行するステップとを実行する請求項１５に記載のコンピュータ・プログラム。
【請求項１７】
前記リソース群は、一以上の実行環境モジュールを含み、
前記注入するステップにて、前記アプリケーションに、前記一以上の実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションのプログラムに注入する、請求項１５に記載のコンピュータ・プログラム。
【請求項１８】
前記実行環境モジュールは、さらに、一以上の他の実行環境モジュールを含み、
前記注入するステップにて、前記実行環境モジュールに対して、前記一以上の他の実行環境モジュールを注入し、前記アプリケーションのプログラムに、前記一以上の他の実行環境モジュールが注入された実行環境モジュールを注入することで、一以上のリソース群を前記アプリケーションのプログラムに注入する、請求項１７に記載のコンピュータ・プログラム。
【請求項１９】
前記リソース群は、二以上の実行環境モジュールを含み、
前記生成するステップでは、前記リソース群を前記一以上の実行環境モジュールの組合せにより生成する、請求項１７に記載のコンピュータ・プログラム。
【請求項２０】
前記テストを実行するステップでは、前記リソース群を注入されたアプリケーションのプログラムに対して、アプリケーション・インターフェースを介して実行されたテストケースによりテストを実行する、請求項１４に記載のコンピュータ・プログラム。