JPWO2018066040A1 - 管理計算機及びテスト環境決定方法 - Google Patents

Abstract

一つ以上のテストケースを含むテストケースグループを実行する複数のテスト環境が構築された計算機システムと接続する管理計算機であって、管理計算機は、テストケースグループの識別情報、及びテストケースグループに含まれるテストケースの特性に基づいて決定された候補テスト環境の識別情報から構成されるエントリを含むグループ情報と、テスト環境の状態に関する条件である動的条件を含む条件情報と、を保持し、第１のテストケースグループの実行契機を検出した場合、グループ情報を参照して第１のテストケースグループの候補テスト環境を特定し、候補テスト環境の状態を示す状態情報を取得し、条件情報及び前記状態情報に基づいて、候補テスト環境の中から第１のテストケースグループを実行するテスト環境を決定する。

Description

本発明は、一つ以上のテストケースによって定義されたテストを行うテスト環境の管理技術に関する。

ＤｅｖＯｐｓ等のシステム開発では、ウォータフォール型開発と異なり、迅速かつ継続的なアプリケーションのリリースが要求されることから、複数のテスト環境を用いて膨大な量の回帰テストが実行される。

仮想化技術及びクラウドコンピューティングの普及に伴って、オンプレミス型システムだけではなく、クラウドサービス上の仮想マシン（ＶＭ）等のリソースから構成されるテスト環境も利用されている。

効率的なシステム開発の要求に対して、特許文献１に記載の技術が知られている。特許文献１には、「プログラムのテスト網羅性を判断するための再テスト方法において、モジュール修正時の再テスト範囲を、テストデータとテスト対象モジュールの関連情報を基に抽出し、該抽出したテストデータを再実行し、該テストデータについての実行済みテスト結果と今回のテスト結果とを比較し検証する」ことが記載されている。

特開平６−３５７５４号公報

システム開発では複数のテスト環境を用いてテストが行われるため、システム開発の実行コストを削減したいというユーザ要求が存在する。ここで、システム開発の実行コストは、使用料金等の運用コスト、ユーザ操作等の管理コスト、及びテストケースの実行時の計算機の負荷等の処理コスト等を含む。前述したユーザ要求を解決するためには、テストケースで定義されるテストの内容、テスト環境の状態、及びシステム開発の実行コスト等を考慮してテスト環境を決定する必要がある。

例えば、運用コストに着目した場合、以下のような問題がある。商用ソフトウェアを用いるテスト環境を用いてテストケースを実行する場合、本番環境と同等の料金を支払う必要があり、運用コストが増大する。前述の問題の解決方法として、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）を用いたテスト環境を利用する方法が考えられる。しかし、テストケースで定義されるテストの内容によっては、ＯＳＳを利用できない場合がある。また、テストケースの実行時にＯＳＳを用いたテスト環境のリソースが不足しているため、当該テスト環境を利用できない可能性がある。

テストの内容及びテスト環境の状態の組み合わせは膨大であり、ユーザ要求に合致したテスト環境を決定するためにはユーザの負担が大きい。そのため、管理コストも増大するという問題がある。また、ラウンドロビン方式でテストケースを実行するテスト環境を決定する場合、負荷の高いテストケースが一つのテスト環境に集中し、処理コストが増大するという問題もある。

本発明は、テストの内容及びテスト環境の状態を考慮して、ユーザ要求に合致したテスト環境を自動的に決定するシステム及び方法を実現する。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、一つ以上のテストケースを含むテストケースグループを実行する複数のテスト環境が構築された計算機システムと接続する管理計算機であって、前記計算機システムは、複数の計算機を含み、前記管理計算機は、プロセッサ、前記プロセッサに接続されるメモリ、前記プロセッサに接続されるネットワークインタフェースを有し、前記テストケースグループの識別情報、及び前記テストケースグループに含まれるテストケースの特性に基づいて決定された候補テスト環境の識別情報から構成されるエントリを含むグループ情報と、前記テスト環境の状態に関する条件である動的条件を含む条件情報と、を保持し、前記プロセッサは、第１のテストケースグループの実行契機を検出した場合、前記グループ情報を参照して前記第１のテストケースグループの候補テスト環境を特定し、前記候補テスト環境の状態を示す状態情報を取得し、前記条件情報及び前記状態情報に基づいて、前記候補テスト環境の中から前記第１のテストケースグループを実行する実行テスト環境を決定することを特徴とする。

本発明によれば、ユーザ要求に合致したテスト環境を自動的に決定することができる。これによって、システム開発の実行コストを削減することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

実施例１の計算機システムの一例を示すブロック図である。 実施例１のテストケース情報の一例を示す図である。 実施例１の条件情報の一例を示す図である。 実施例１のテスト環境情報の一例を示す図である。 実施例１のライセンス情報の一例を示す図である。 実施例１のグループ情報の一例を示す図である。 実施例１のテスト実行キュー情報の一例を示す図である。 実施例１の管理サーバが実行する処理の流れを説明するシーケンス図である。 実施例１の管理サーバが実行する処理の流れを説明するシーケンス図である。 実施例１の静的分類モジュールが実行する静的分類処理の一例を説明するフローチャートである。 実施例１のグループ生成モジュールが実行するグループ生成処理の一例を説明するフローチャートである。 実施例１のグループ評価モジュールが実行するグループ評価処理の一例を説明するフローチャートである。 実施例１の動的分類モジュールが実行する動的分類処理の一例を説明するフローチャートである。 実施例１の動的分類モジュールが実行する動的分類処理の一例を説明するフローチャートである。 実施例１の情報取得モジュールが実行する処理の一例を説明するフローチャートである。 実施例１のコスト算出モジュールが実行する処理の一例を説明するフローチャートである。

以下、本発明の実施例について添付図面を用いて説明する。実施例で用いるテーブルに使用する識別情報は、当該テーブルに一つ以上のカラムを用いてテーブルのエントリを特定できる場合、識別情報のカラムを省略することもできる。また、識別情報は昇順となる識別番号を自動的に割り当てられてもよい。各図において共通の構成については同一の参照符号が付されている。

実施例１では、ユーザ要求が運用コストの削減である場合の構成及び処理について説明する。クラウド型システム上のテスト環境を使用する場合、使用料金の低いテスト環境を使用し、又は、テスト環境の使用時間を短くすることによって、運用コストを削減できる。ここでは、使用料金の低いテスト環境を使用することによって運用コストの削減を実現する方法及びシステムについて説明する。なお、他のユーザ要求についても同様の構成で同様の機能及び効果を実現できる。

図１は、実施例１の計算機システムの一例を示すブロック図である。

実施例１の計算機システムは、管理サーバ１００、オンプレミス型システム１０１、及びクラウド型システム１０２から構成され、管理ネットワーク１０３を介して互いに接続される。なお、管理ネットワーク１０３は、オンプレミス型システム１０１に接続するネットワーク及びクラウド型システム１０２に接続するネットワークに分けてもよい。

本実施例では、テスト環境が一つ以上のテストケースを実行することによって、テストが行われる。ここで、テストケースとは、実行前条件、入力値、期待される結果、及び実行後条件等を含むテストの内容を定義した情報である。また、テスト環境とは、テストを行うための環境である。

オンプレミス型システム１０１及びクラウド型システム１０２は、テスト環境を実現するシステムである。本実施例では、ステージング環境及び代替環境の二つ種類のテスト環境が各システム上に構築される。ステージング環境は商用ソフトウェアを利用する環境であって、本番環境と同等の環境である。また、代替環境はＯＳＳを利用する環境である。なお、本番環境は、実際にシステムが稼働する環境である。

オンプレミス型システム１０１は、システム開発者が所属する会社が運用するシステムである。クラウド型システム１０２は、クラウドサービスの提供者が運用するシステムである。オンプレミス型システム１０１及びクラウド型システム１０２は、それぞれ、複数の計算機、複数のストレージ装置、及び複数のネットワーク装置等を含む。テスト環境は、物理的な装置そのものをリソースとして用いるテスト環境でもよいし、仮想的な装置をリソースとして用いるテスト環境でもよい。実施例１では、クラウド型システム１０２上に構築されたテスト環境を対象とした処理について説明する。二つのシステム上に構築されたテスト環境を対象とした処理については実施例２で説明する。

管理サーバ１００は、テストケースを実行するテスト環境を決定する。ここで、管理サーバ１００のハードウェア構成及びソフトウェア構成について説明する。

管理サーバ１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１１、メモリ１１２、ネットワークインタフェース１１３、及びＩＯインタフェース１１４を有する。前述した各ハードウェアは、内部バスを介して互いに接続される。

ＣＰＵ１１１は、メモリ１１２に格納されるプログラムを実行する。ＣＰＵ１１１は、メモリ１１２に格納されるプログラムにしたがって動作することによって、所定の機能を実現するモジュールとして動作する。例えば、ＣＰＵ１１１は、情報取得プログラムにしたがって動作することで情報取得モジュール１２６として機能する。他のプログラムについても同様である。

メモリ１１２は、ＣＰＵ１１１が実行するプログラム及び情報を格納する。また、メモリ１１２は、プログラムが一時的に使用するワークエリアを含む。メモリ１１２に含まれるプログラム及び情報は後述する。

ネットワークインタフェース１１３は、ＩＰネットワーク等を介して外部の装置と通信するためのインタフェースである。ＩＯインタフェース１１４は、入力装置１０４及び表示装置１０５と接続するインタフェースである。なお、ＩＯインタフェース１１４は、ＵＳＢメモリ及び外部ストレージ装置等、外部の記憶媒体に接続してもよい。

ここで、入力装置１０４は、管理サーバ１００にデータを入力するための装置である。キーボード、マウス、及びタッチパネル等を入力装置１０４として用いることができる。表示装置１０５は、管理サーバ１００の処理結果等を表示するための装置である。ディスプレイ及びタッチパネル等を表示装置１０５として用いることができる。

図１では、各ハードウェアの数はそれぞれ一つであるが二つ以上であってもよい。例えば、管理サーバ１００が複数のネットワークと接続する場合、管理サーバ１００は、各ネットワークと接続する複数のネットワークインタフェース１１３を有してもよい。

ここで、メモリ１１２に格納されるプログラム及び情報について説明する。メモリ１１２は、制御モジュール１２０を実現するプログラム及び管理情報群１３０を格納する。

制御モジュール１２０は、管理サーバ１００全体を制御するモジュールであり、複数のモジュールを含む。具体的には、制御モジュール１２０は、テスト実行モジュール１２１、静的分類モジュール１２２、動的分類モジュール１２３、グループ生成モジュール１２４、グループ評価モジュール１２５、情報取得モジュール１２６、及びコスト算出モジュール１２７を含む。

テスト実行モジュール１２１は、各モジュールと連携して、決定されたテスト環境にテストケースを実行させる。静的分類モジュール１２２は、テストケースによって定義されたテストの内容及び条件情報１３２に基づいて、各テストケースを実行するテスト環境の候補を選択する。動的分類モジュール１２３は、テスト環境の稼働状態等、テスト環境の状態及び条件情報１３２に基づいてテストケースを実行するテスト環境を決定する。以下の説明では、テストケースによって定義されたテストの内容をテストケース特性と記載する。

グループ生成モジュール１２４は、一つ以上のテストケースから構成されるテストケースグループを生成する。本実施例では、テストケースグループ単位でテストが行われる。グループ評価モジュール１２５は、静的分類モジュール１２２の処理結果に基づいて、テストケースグループを実行するテスト環境の候補を選択する。以下の説明では、テストケースグループを実行するテスト環境の候補を候補テスト環境と記載する。

情報取得モジュール１２６は、テスト環境の状態を示す状態情報を取得する。コスト算出モジュール１２７は、システム開発の実行コストを算出する。本実施例では、コスト算出モジュール１２７は、テスト環境の使用料金を算出する。

管理情報群１３０は、テストケース情報１３１、条件情報１３２、テスト環境情報１３３、ライセンス情報１３４、グループ情報１３５、及びテスト実行キュー情報１３６を含む。各情報の詳細は、図２から図７を用いて説明する。

なお、メモリ１１２に格納されるプログラム及び情報は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、不揮発性メモリ、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機が読み取り可能な非一時的記憶媒体、又は、外部ストレージ装置に格納されてもよい。この場合、ＣＰＵ１１１は、外部ストレージ装置等からプログラム及び情報を読み出し、メモリ１１２にプログラム及び情報をロードする。

図２は、実施例１のテストケース情報１３１の一例を示す図である。なお、図２では、図面のスペースを考慮してテストケース情報１３１を二つのテーブルに分けているが、実際は一つのテーブルとして管理される。

テストケース情報１３１は、テストケースを管理する情報であり、テストケースＩＤ２０１、自動化２０２、性能２０３、独自機能２０４、重要度２０５、前提条件２０６、代替環境２０７、実行環境２０８、エラー２０９、予測時間２１０、システムＩＤ２１１、ユースケース／機能２１２、及びグルーピング２１３から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

テストケースＩＤ２０１は、テストケースを識別するための識別情報を格納する。テストケースＩＤ２０１は、テストケース情報１３１のエントリを識別するための識別情報としても用いられる。

自動化２０２は、テストケースが自動化できるか否かを示す情報を格納する。自動化２０２には、「可能」及び「不可能」のいずれかが格納される。

性能２０３は、テストケースで定義されたテストが性能テストであるか否かを示す情報を格納する。性能２０３には、「ＹＥＳ」及び「ＮＯ」のいずれかが格納される。性能テストは、本番環境におけるシステムの性能等を計測することを目的として行われる。そのため、性能テストは、本番環境と同等のステージング環境で行われる必要がある。なお、ステージング環境を用いる必要があるテストとしては、セキュリティの確認を目的としてテスト等が考えられる。

独自機能２０４は、テストケースで定義されたテストが商用ソフトウェアの独自機能を確認するテストであるか否かを示す情報を格納する。独自機能２０４には、「ＹＥＳ」及び「ＮＯ」のいずれかが格納される。

重要度２０５は、テストケースの実行順番（テストの実行順番）等を示す重要度を格納する。重要度は、バグの発生率の高さ又はシステム全体の影響度等を表すものである。重要度２０５には、「１」以上の整数が格納される。本実施例では、値が１に近いほど重要度が高いことを示す。ユーザが設定した値を重要度２０５に設定してもよいし、テストケース間の依存関係に基づいて算出された値を重要度２０５に設定してもよい。例えば、前提条件２０６に登録される数に基づいて値を設定する方法が考えられる。

前提条件２０６は、エントリに対応するテストケースを実行する前に実行する必要があるテストケースの識別情報を格納する。なお、事前に実行する必要があるテストケースが存在しない場合、前提条件２０６は空欄となる。例えば、データベースのレコードを追加するテストを定義する第１のテストケース、及び第１のテストケースにおいて追加されたレコードを削除するテストを定義する第２のテストケースがあった場合、第２のテストケースは、第１のテストケースが前提条件となる。したがって、第２のテストケースに対応するエントリの前提条件２０６には第１のテストケースの識別情報が格納される。

代替環境２０７は、テストケースを代替環境２０７で実行できるか否かを示す情報を格納する。代替環境２０７には、「可能」及び「不可能」のいずれかが格納される。

実行環境２０８は、前回、テストケースを実行したテスト環境の識別情報を格納する。実行環境２０８には、後述するテスト環境ＩＤ４０１（図４参照）に設定された識別情報が格納される。

エラー２０９は、テスト結果がテストケースにおいて期待された結果であるか否かを示す情報を格納する。テスト結果がテストケースにおいて期待された結果でない場合、エラー２０９には「エラー」が格納され、テスト結果がテストケースにおいて期待された結果である場合、エラー２０９は空欄である。

予測時間２１０は、テストケースによって定義されたテストの実行時間の予測値を格納する。前回、実行されたテストの実行時間が予測時間２１０に格納されてもよいし、また、これまで実行したテストの実行時間の統計値が予測時間２１０に格納されてもよい。ここで、統計値は、平均値、最高値、及び中央値等を示す。

システムＩＤ２１１は、テストケースで定義されたテストの対象となるシステム又はソフトウェアの識別情報を格納する。

ユースケース／機能２１２は、テストケースで定義されたテストの対象となる具体的な機能等の識別情報を格納する。

グルーピング２１３は、グループ生成モジュール１２４によって処理されたエントリであるか否かを示す情報を格納する。グルーピング２１３には、「実行済」及び「未実行」のいずれかが格納される。

本実施例では、自動化２０２、性能２０３、独自機能２０４、重要度２０５、及び前提条件２０６が、テストケース特性として用いられる。

図３は、実施例１の条件情報１３２の一例を示す図である。

条件情報１３２は、テストケースグループを実行するテスト環境を決定するための条件を管理する情報であり、条件ＩＤ３０１、条件種別３０２、項目３０３、及び条件３０４から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

条件ＩＤ３０１は、条件を一意に識別するための識別情報を格納する。

条件種別３０２は、条件の種別を示す情報を格納する。条件種別３０２には「静的」及び「動的」のいずれかが格納される。「静的」は静的分類モジュール１２２によって使用される条件であり、「動的」は動的分類モジュール１２３によって使用される条件である。以下の説明では、条件種別３０２に「静的」が設定されたエントリに対応する条件を静的条件と記載し、また、条件種別３０２に「動的」が設定されたエントリに対応する条件を静的条件と記載する。静的条件は、時間に依存しないパラメータ等の条件である。テストケース特性に関する条件が、主に、静的条件として設定される。また、動的条件は、時間に依存するパラメータ等の条件である。テスト環境の状態に関する条件が、主に、動的条件として設定される。

項目３０３は、条件の名称及び種別等を示す情報を格納する。項目３０３は、ユーザがユーザ要求を入力するためのＧＵＩ等に表示される。

条件３０４は、具体的な条件の内容を格納する。なお、本実施例では、説明のため文字列として条件を記載しているが、条件式等、文字列以外のデータが格納されてもよい。なお、条件３０４に設定する数値は、ユーザが決定してもよい。

図４は、実施例１のテスト環境情報１３３の一例を示す図である。

テスト環境情報１３３は、テスト環境の構成及びテスト環境の状態等を管理する情報であり、テスト環境ＩＤ４０１、テスト環境種別４０２、構成４０３、代替対象ソフトウェア４０４、ＣＰＵ使用率４０５、及びメモリ使用率４０６から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

テスト環境ＩＤ４０１は、テスト環境を一意に識別する識別情報を格納する。

テスト環境種別４０２は、テスト環境の種別を示す情報を格納する。本実施例のテスト環境種別４０２には、「ステージング」及び「代替」のいずれかが格納される。

構成４０３は、テスト環境の構成情報を格納する。本実施例では、テスト環境において稼働するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の種別が構成４０３に格納される。なお、構成４０３には、テスト環境のハードウェア構成及びソフトウェア構成等が格納されてもよい。

代替対象ソフトウェア４０４は、ＯＳＳと置き換える商用ソフトウェア又はＯＳＳの識別情報を格納する。エントリのテスト環境種別４０２が「ステージング」の場合、代替対象ソフトウェア４０４には、ＯＳＳと置き換える商用ソフトウェアの識別情報が格納される。エントリのテスト環境種別４０２が「代替」の場合、代替対象ソフトウェア４０４には、ＯＳＳの識別情報が格納される。

ＣＰＵ使用率４０５は、テスト環境を構成するサーバ等が有するＣＰＵの使用率を格納する。例えば、サーバが物理サーバの場合、物理ＣＰＵの使用率がＣＰＵ使用率４０５に格納され、サーバがＶＭの場合、仮想ＣＰＵの使用率がＣＰＵ使用率４０５に格納される。

メモリ使用率４０６は、テスト環境を構成するサーバ等が有するメモリの使用率を格納する。例えば、サーバが物理サーバの場合、物理メモリの使用率がメモリ使用率４０６に格納され、サーバがＶＭの場合、仮想メモリの使用率がメモリ使用率４０６に格納される。

図５は、実施例１のライセンス情報１３４の一例を示す図である。

ライセンス情報１３４は、テスト環境において使用するソフトウェアのライセンス料を管理する情報であり、ライセンスＩＤ５０１、ソフトウェア５０２、使用状態５０３、テスト環境ＩＤ５０４、及び料金５０５から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

ライセンスＩＤ５０１は、ライセンスを一意に識別するための識別情報を格納する。

ソフトウェア５０２は、ライセンス対象のテスト環境に含まれるソフトウェアの識別情報を格納する。なお、クラウド型システム１０２のオプションサービスとしてソフトウェアが提供される場合、ソフトウェア５０２にはサービスの識別情報が格納される。

使用状態５０３は、ライセンスを使用しているか否かを示す情報を格納する。使用状態５０３には、「使用中」及び「未使用」のいずれかが格納される。

テスト環境ＩＤ５０４は、ライセンスを対象のテスト環境の識別情報を格納する。テスト環境ＩＤ５０４には、テスト環境ＩＤ４０１に設定された識別情報が格納される。

料金５０５は、ライセンス対象のテスト環境の使用料金を格納する。

図６は、実施例１のグループ情報１３５の一例を示す図である。

グループ情報１３５は、グループ生成モジュール１２４によって生成されるテストケースグループを管理する情報であり、グループＩＤ６０１、グループ重要度６０２、代替環境６０３、及びテストケース６０４から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

グループＩＤ６０１は、テストケースグループを一意に識別するための識別情報を格納する。

グループ重要度６０２は、テストケースグループの重要度を格納する。グループ重要度６０２は、テストケースグループ間の実行順番を決定するために用いられる。

代替環境６０３は、テストケースグループとして代替環境を使用できるか否を示す情報を格納する。代替環境６０３には「可能」及び「不可能」のいずれかが格納される。なお、代替環境６０３に設定する値は、テストケースグループに含まれるテストケースの代替環境２０７に基づいて決定される。本実施例では、候補テスト環境を特定する情報としてテスト環境の種別を用いているため、エントリは代替環境６０３を含む。

テストケース６０４は、テストケースグループを構成するテストケースの識別情報を格納する。テストケース６０４には、テストケースグループに含まれるテストケースの数だけ列が存在する。テストケース６０４の各列には、テストケースＩＤ２０１に設定された識別情報が格納される。本実施例では、テストケース６０４の左から順にテストケースが実行される。

図７は、実施例１のテスト実行キュー情報１３６の一例を示す図である。

テスト実行キュー情報１３６は、テストケースを登録するテスト実行キューを管理する情報であり、キューＩＤ７０１、テストケースＩＤ７０２、グループＩＤ７０３、及び実行環境ＩＤ７０４から構成されるエントリを含む。なお、エントリには、前述した以外のカラムが含まれてもよい。

キューＩＤ７０１は、キューを一意に識別するための識別情報を格納する。

テストケースＩＤ７０２は、キューに投入されたテストケースの識別情報を格納する。テストケースＩＤ７０２には、テストケースＩＤ２０１に設定された識別情報が格納される。

グループＩＤ７０３は、キューに投入されたテストケースが属するテストケースグループの識別情報を格納する。グループＩＤ７０３には、グループＩＤ６０１に設定された識別情報が格納される。

実行環境ＩＤ７０４は、テストケースに対応するテストを実行するテスト環境の識別情報を格納する。実行環境ＩＤ７０４には、テスト環境ＩＤ４０１に設定された識別情報が格納される。

図８Ａ及び図８Ｂは、実施例１の管理サーバ１００が実行する処理の流れを説明するシーケンス図である。

テスト実行モジュール１２１は、テスト（テストケースグループ）の開始契機を検出した場合（ステップＳ８０１）、静的分類モジュール１２２に開始命令を送信する（ステップＳ８０２）。また、テスト実行モジュール１２１は、ユーザに予算の入力するための画面を表示し、予算の入力を受け付ける。

テスト実行モジュール１２１は、ユーザが入力したテスト開始指示をテストの開始契機として検出してもよい。また、テスト実行モジュール１２１は、実行スケジュールに設定された時間を経過した場合、又は、テスト対象となるシステムがバージョン管理ソフトに対してソースをコミットした場合、テストが開始されたと判定してもよい。

なお、管理サーバ１００が予算を管理する情報を保持している場合、予算を入力する画面が表示されなくてもよい。

静的分類モジュール１２２は、テスト実行モジュール１２１から開始命令を受信した場合、静的分類処理を実行する（ステップＳ８０３）。静的分類処理では、静的分類モジュール１２２は、テストケース特性に基づいて、各テストケースについて実行可能なテスト環境を選択する。静的分類処理の詳細は、図９を用いて説明する。

静的分類モジュール１２２は、静的分類処理が終了した後、テスト実行モジュール１２１に完了通知を送信する（ステップＳ８０４）。

テスト実行モジュール１２１は、静的分類モジュール１２２から完了通知を受信した場合、グループ生成モジュール１２４に開始命令を送信する（ステップＳ８０５）。

グループ生成モジュール１２４は、テスト実行モジュール１２１から開始命令を受信した場合、グループ生成処理を実行する（ステップＳ８０６）。グループ生成処理では、グループ生成モジュール１２４は、テストケースグループを生成する。グループ生成処理の詳細は、図１０を用いて説明する。

グループ生成モジュール１２４は、グループ生成処理が終了した後、テスト実行モジュール１２１に完了通知を送信する（ステップＳ８０７）。

テスト実行モジュール１２１は、グループ生成モジュール１２４から完了通知を受信した場合、グループ評価モジュール１２５に開始命令を送信する（ステップＳ８０８）。

グループ評価モジュール１２５は、テスト実行モジュール１２１から開始命令を受信した場合、グループ評価処理を実行する（ステップＳ８０９）。グループ評価処理では、グループ評価モジュール１２５は、候補テスト環境を選択する。グループ評価処理の詳細は、図１１を用いて説明する。

グループ評価モジュール１２５は、グループ評価処理が終了した後、テスト実行モジュール１２１に完了通知を送信する（ステップＳ８１０）。

テスト実行モジュール１２１は、グループ評価モジュール１２５から完了通知を受信した場合、動的分類モジュール１２３に開始命令を送信する（ステップＳ８１１）。

動的分類モジュール１２３は、テスト実行モジュール１２１から開始命令を受信した場合、動的分類処理を実行する（ステップＳ８１２）。動的分類処理では、動的分類モジュール１２３は、候補テスト環境の状態に基づいて、テストケースグループを実行するテスト環境を決定する。また、動的分類モジュール１２３は、テストケースグループに含まれるテストケースをテスト実行キューに登録する。動的分類処理の詳細は、図１２Ａ及び図１２Ｂを用いて説明する。

動的分類モジュール１２３は、動的分類処理が終了した後、テスト実行モジュール１２１に完了通知を送信する（ステップＳ８１３）。

テスト実行モジュール１２１は、テスト実行キュー情報１３６を参照し、テスト実行キューに投入されたテストケースを実行する（ステップＳ８１４）。

以上の処理によって、テストケースグループを適切なテスト環境で実行させることができる。

図９は、実施例１の静的分類モジュール１２２が実行する静的分類処理の一例を説明するフローチャートである。

静的分類モジュール１２２は、テストケースのループ処理を開始する（ステップＳ９０１）。

具体的には、静的分類モジュール１２２は、テストケース情報１３１を参照し、ターゲットテストケースを一つ選択する。また、静的分類モジュール１２２は、条件情報１３２から条件種別３０２に「静的」が設定されたエントリを取得する。

なお、ループ処理では、テストケース情報１３１に登録された全てのテストケースの中からターゲットテストケースを選択してもよいし、変更したソフトウェアに関連するテストケースの中からターゲットテストケースを選択してもよい。変更したソフトウェアに関連するテストケースだけに絞り込むことによって処理負荷を低減できる。

ステップＳ９０３からステップＳ９０９までの処理では、静的分類モジュール１２２は、静的条件に基づいて、ターゲットテストケースを実行可能なテスト環境を選択する。

まず、静的分類モジュール１２２は、テストケース情報１３１を参照し、ターゲットテストケースに対応するエントリの自動化２０２が「可能」であるか否かを判定する（ステップＳ９０２）。

ターゲットテストケースに対応するエントリの自動化２０２が「不可能」であると判定された場合、静的分類モジュール１２２は、ステップＳ９１０に進む。この場合、当該エントリの代替環境２０７は「不可能」が設定される。

ターゲットテストケースに対応するエントリの自動化２０２が「可能」であると判定された場合、静的分類モジュール１２２は、代替環境でターゲットテストケースを実行できるか否かを判定する（ステップＳ９０３）。具体的には、以下のような処理が実行される。

静的分類モジュール１２２は、ターゲットテストケースに対応するエントリの性能２０３が「ＹＥＳ」であるか否かを判定する。

エントリの性能２０３が「ＹＥＳ」であると判定された場合、静的分類モジュール１２２は、代替環境でターゲットテストケースを実行できないと判定する。エントリの性能２０３が「ＮＯ」であると判定された場合、静的分類モジュール１２２は、エントリの独自機能２０４が「ＹＥＳ」であるか否かを判定する。

エントリの独自機能２０４が「ＹＥＳ」であると判定された場合、静的分類モジュール１２２は、代替環境でターゲットテストケースを実行できないと判定する。エントリの独自機能２０４が「ＮＯ」であると判定された場合、静的分類モジュール１２２は、代替環境でターゲットテストケースを実行できると判定する。以上がステップＳ９０３の処理の説明である。

代替環境でターゲットテストケースを実行できないと判定された場合、静的分類モジュール１２２は、ターゲットテストケースに対応するエントリの代替環境２０７に「不可能」を設定する（ステップＳ９０９）。その後、静的分類モジュール１２２は、ステップＳ９１０に進む。

代替環境でターゲットテストケースを実行できると判定された場合、静的分類モジュール１２２は、ステージング環境及び代替環境のそれぞれでテストケースを実行する（ステップＳ９０４）。静的分類モジュール１２２は、ステージング環境及び代替環境からテスト結果が出力されるまで待ち状態に移行する。

静的分類モジュール１２２は、ステージング環境及び代替環境からテスト結果が出力された場合、当該テスト結果に基づいて、テストケースを見直す必要があるか否かを判定する（ステップＳ９０５）。

具体的には、静的分類モジュール１２２は、テストケースにおいて期待された結果が出力されたか否かを判定する。

テストケースを見直す必要があると判定された場合、静的分類モジュール１２２は、ステップＳ９１０に進む。この場合、当該エントリの代替環境２０７には特に値が設定されなくてもよい。

テストケースを見直す必要がないと判定された場合、静的分類モジュール１２２は、ステージング環境及び代替環境のテスト結果が一致するか否かを判定する（ステップＳ９０６）。なお、テスト結果の一致は、完全一致でなくてもよく、類似する結果であればよい。

ステージング環境及び代替環境のテスト結果が一致しないと判定された場合、静的分類モジュール１２２は、エントリの代替環境２０７に「不可能」を設定する（ステップＳ９０９）。その後、静的分類モジュール１２２は、ステップＳ９１０に進む。

ステージング環境及び代替環境のテスト結果が一致すると判定された場合、静的分類モジュール１２２は、エントリの代替環境２０７に「可能」を設定する（ステップＳ９０７）。その後、静的分類モジュール１２２は、ステップＳ９１０に進む。

ステップＳ９１０では、静的分類モジュール１２２は、選択可能な全てのテストケースについて処理が完了したか否かを判定する（ステップＳ９１０）。

選択可能な全てのテストケースについて処理が完了していないと判定された場合、静的分類モジュール１２２は、ステップＳ９０１に戻り、新たなターゲットテストケースを選択し、同様の処理を実行する。

選択可能な全てのテストケースについて処理が完了したと判定された場合、静的分類モジュール１２２は、テストケースのループ処理を終了し、テスト実行モジュール１２１に完了通知を送信する（ステップＳ９１１）。その後、静的分類モジュール１２２は、静的分類処理を終了する。

以上の通り、静的分類モジュール１２２では、テストケース特性に基づいて、テストケースを実行可能なテスト環境を選択する。本実施例では、静的分類モジュール１２２は、代替環境が優先的に選択されるように制御する。これによって、テストケースの運用コストを低くできる。

なお、図９では、静的分類モジュール１２２は、ステージング環境及び代替環境のいずれかを選択しているが、これに限定されない。条件情報１３２に設定する条件を変更することによって、静的分類モジュール１２２は、様々な観点に基づいて、テスト環境を選択できる。

図１０は、実施例１のグループ生成モジュール１２４が実行するグループ生成処理の一例を説明するフローチャートである。

グループ生成モジュール１２４は、テストケース情報１３１の全てのエントリのグルーピング２１３に「未実行」を設定する（ステップＳ１００１）。

次に、グループ生成モジュール１２４は、前提条件２０６に登録されていないテストケースを特定する（ステップＳ１００２）。

具体的には、グループ生成モジュール１２４は、各エントリの前提条件２０６を参照し、いずれのエントリの前提条件２０６にも登録されていないテストケースを特定する。前提条件２０６に登録されていないテストケースは、テストケースグループにおいて最後に実行されるテストケースに対応する。

次に、グループ生成モジュール１２４は、特定されたテストケースのループ処理を開始する（ステップＳ１００３）。

具体的には、グループ生成モジュール１２４は、特定されたテストケースの中から一つのテストケースを選択し、ステップＳ１００４からステップＳ１０１１までの処理を実行する。

グループ生成モジュール１２４は、選択されたテストケースをターゲットテストケースに設定し（ステップＳ１００４）、また、ターゲットテストケースを含むテストケースグループを生成する（ステップＳ１００５）。

具体的には、グループ生成モジュール１２４は、グループ情報１３５にエントリを追加し、追加されたエントリのグループＩＤ６０１に識別情報を設定する。グループ生成モジュール１２４は、テストケース６０４に列を追加し、ターゲットテストケースの識別情報を設定する。また、グループ生成モジュール１２４は、テストケース情報１３１を参照して、ターゲットテストケースのエントリのグルーピング２１３に「実行済」を設定する。

次に、グループ生成モジュール１２４は、ターゲットテストケースと依存関係があるテストケースが存在するか否かを判定する（ステップＳ１００６）。

具体的には、グループ生成モジュール１２４は、前提条件２０６にターゲットテストケースの識別情報が格納されるエントリを検索する。当該エントリが存在しない場合、グループ生成モジュール１２４は、ターゲットテストケースと依存関係があるテストケースが存在しないと判定する。

ターゲットテストケースと依存関係があるテストケースが存在すると判定された場合、グループ生成モジュール１２４は、検索されたテストケースをテストケースグループに追加する（ステップＳ１００７）。

具体的には、グループ生成モジュール１２４は、テストケース情報１３１からステップＳ１００６において検索されたテストケースの識別情報を取得する。グループ生成モジュール１２４は、ステップＳ１００５においてグループ情報１３５に追加されたエントリのテストケース６０４に取得されたテストケースの識別情報を追加する。なお、テストケースの識別情報は、右から順に設定される。すなわち、新たに設定されるテストケースの識別情報が最も右側になるように設定される。

次に、グループ生成モジュール１２４は、テストケース情報１３１を参照して、ターゲットテストケースのエントリのグルーピング２１３に「実行済」を設定する（ステップＳ１００８）。なお、既にグルーピング２１３が「実行済」である場合、当該ステップを省略できる。

次に、グループ生成モジュール１２４は、ステップＳ１００７において検索されたテストケースを新たなターゲットテストケースに設定する（ステップＳ１００９）。その後、グループ生成モジュール１２４は、ステップＳ１００６に戻り、同様の処理を実行する。

ステップＳ１００６において、ターゲットテストケースと依存関係があるテストケースが存在しないと判定された場合、グループ生成モジュール１２４は、テストケース情報１３１を参照して、ターゲットテストケースのエントリのグルーピング２１３に「実行済」を設定する（ステップＳ１０１０）。なお、既にグルーピング２１３が「実行済」である場合、当該ステップを省略できる。

次に、グループ生成モジュール１２４は、ステップＳ１００５において生成されたテストケースグループの重要度を算出する（ステップＳ１０１１）。具体的には、以下のような処理が実行される。

グループ生成モジュール１２４は、グループ情報１３５に追加されたエントリのテストケース６０４からテストケースグループに含まれるテストケースの識別情報を取得する。

グループ生成モジュール１２４は、テストケース情報１３１を参照して、テストケースＩＤ２０１が取得されたテストケースの識別情報に一致するエントリを検索し、検索されたエントリの重要度２０５から値を取得する。グループ生成モジュール１２４は、取得された値を用いてテストケースグループの重要度を算出する。例えば、テストケースの重要度の合計値、平均値、最大値、及び最小値等がテストケースグループの重要度として算出される。

グループ生成モジュール１２４は、グループ情報１３５に追加されたエントリのグループ重要度６０２に算出された重要度を設定する。以上がステップＳ１０１１の処理の説明である。

次に、グループ生成モジュール１２４は、ステップＳ１００２において特定された全てのテストケースについて処理が完了したか否かを判定する（ステップＳ１０１２）。

ステップＳ１００２において特定された全てのテストケースについて処理が完了していないと判定された場合、グループ生成モジュール１２４は、ステップＳ１００３に戻り、特定されたテストケースの中から新たなテストケースを選択し、同様の処理を実行する。

ステップＳ１００２において特定された全てのテストケースについて処理が完了したと判定された場合、グループ生成モジュール１２４は、テストケースのループ処理を終了し、テスト実行モジュール１２１に完了通知を送信する（ステップＳ１０１３）。その後、グループ生成モジュール１２４は、グループ生成処理を終了する。

図２に示すテストケース情報１３１の場合、ステップＳ１００２において、「ＴＣ２」、「ＴＣ３」、及び「ＴＣ５」が特定される。「ＴＣ２」のテストケースグループは「ＴＣ２」及び「ＴＣ１」を含み、「ＴＣ３」のテストケースグループは「ＴＣ３」のみを含み、「ＴＣ５」のテストケースグループは「ＴＣ１」、「ＴＣ４」、及び「ＴＣ５」を含む。「ＴＣ１」は二つのテストケースグループに含まれる。

なお、グループ生成モジュール１２４は、変更したソフトウェアに関するテストケースのエントリのみについて、グルーピング２１３を「未実行」に設定してもよい。

以上の通り、グループ生成モジュール１２４は、テストケース間の依存関係に基づいて、一つ以上のテストケースを含むテストケースグループを生成できる。

図１１は、実施例１のグループ評価モジュール１２５が実行するグループ評価処理の一例を説明するフローチャートである。

グループ評価モジュール１２５は、テストケースグループのループ処理を開始する（ステップＳ１１０１）。

具体的には、グループ評価モジュール１２５は、グループ情報１３５を参照し、ターゲットテストケースグループを一つ選択する。

次に、グループ評価モジュール１２５は、ステージング環境でのみ実行可能なテストケースがターゲットテストケースグループに含まれるか否かを判定する（ステップＳ１１０２）。具体的には、以下のような処理が実行される。

グループ評価モジュール１２５は、グループ情報１３５を参照し、ターゲットテストケースグループのエントリのテストケース６０４からテストケースの識別情報を取得する。グループ評価モジュール１２５は、テストケース情報１３１を参照し、テストケースＩＤ２０１が取得されたテストケースの識別情報と一致するエントリを検索する。

グループ評価モジュール１２５は、検索されたエントリの代替環境２０７を参照し、代替環境２０７が「不可能」であるエントリが存在するか否かを判定する。代替環境２０７が「不可能」であるエントリが存在する場合、グループ評価モジュール１２５は、ステージング環境でのみ実行可能なテストケースがターゲットテストケースグループに含まれると判定する。以上がステップＳ１１０２の処理の説明である。

ステージング環境でのみ実行可能なテストケースがターゲットテストケースグループに含まれないと判定された場合、グループ評価モジュール１２５は、グループ情報１３５を参照し、ターゲットテストケースグループのエントリの代替環境６０３に「可能」を設定する（ステップＳ１１０３）。すなわち、代替環境がターゲットテストケースグループの候補テスト環境として選択される。その後、グループ評価モジュール１２５は、ステップＳ１１０５に進む。

ステージング環境でのみ実行可能なテストケースがターゲットテストケースグループに含まれると判定された場合、グループ評価モジュール１２５は、グループ情報１３５を参照し、ターゲットテストケースグループのエントリの代替環境６０３に「不可能」を設定する（ステップＳ１１０４）。すなわち、ステージング環境がターゲットテストケースグループの候補テスト環境として選択される。その後、グループ評価モジュール１２５は、ステップＳ１１０５に進む。

ステップＳ１１０５では、グループ評価モジュール１２５は、全てのテストケースグループについて処理が完了したか否かを判定する（ステップＳ１１０５）。

全てのテストケースグループについて処理が完了していないと判定された場合、グループ評価モジュール１２５は、ステップＳ１１０１に戻り、新たなターゲットテストケースグループを選択し、同様の処理を実行する。

全てのテストケースグループについて処理が完了したと判定された場合、グループ評価モジュール１２５は、テストケースグループのループ処理を終了し、テスト実行モジュール１２１に完了通知を送信する（ステップＳ１１０６）。その後、グループ評価モジュール１２５は、グループ評価処理を終了する。

図１２Ａ及び図１２Ｂは、実施例１の動的分類モジュール１２３が実行する動的分類処理の一例を説明するフローチャートである。

動的分類モジュール１２３は、グループ情報１３５のエントリをグループ重要度の高い順に並び替える（ステップＳ１２０１）。本実施例では、値が小さいほど重要度が高いことから、グループ重要度６０２の値が小さい順にエントリが並び替えられる。ステップＳ１２０１の処理は、重要度の高いテストケースを優先的に実行するための処理である。

次に、動的分類モジュール１２３は、テストケースグループのループ処理を開始する（ステップＳ１２０２）。

具体的には、動的分類モジュール１２３は、グループ情報１３５を参照し、ターゲットテストケースを一つ選択する。また、動的分類モジュール１２３は、条件情報１３２から条件種別３０２に「動的」が設定されたエントリを取得する。

ステップＳ１２０３からステップＳ１２１２では、動的分類モジュール１２３は、動的条件に基づいて、選択されたテストケースグループを実行するテスト環境を決定する。

次に、動的分類モジュール１２３は、グループ情報１３５を参照し、ターゲットテストケースグループに対応するエントリの代替環境６０３が「可能」であるか否かを判定する（ステップＳ１２０３）。すなわち、代替環境が候補テスト環境であるか否かが判定される。当該処理は、候補テスト環境を特定するための処理である。

ターゲットテストケースグループに対応するエントリの代替環境６０３が「不可能」であると判定された場合、動的分類モジュール１２３は、テスト環境情報１３３を参照し、ターゲットテストケースグループを実行するステージング環境を決定する（ステップＳ１２０５）。その後、動的分類モジュール１２３は、ステップＳ１２１１に進む。具体的には、以下のような処理が実行される。

動的分類モジュール１２３は、テスト環境情報１３３を参照し、テスト環境種別４０２が「ステージング」であるエントリを検索する。動的分類モジュール１２３は、検索されたエントリのＣＰＵ使用率４０５及びメモリ使用率４０６を取得する。動的分類モジュール１２３は、取得されたＣＰＵ使用率及びメモリ使用率に基づいて、項目３０３が「稼働状態」である動的条件を満たすステージング環境を特定する。

動的分類モジュール１２３は、特定されたステージング環境の中からＣＰＵ使用率が最も小さいステージング環境を選択する。動的分類モジュール１２３は、選択されたステージング環境を、選択されたテストケースグループを実行するステージング環境に決定する。なお、前述した処理は一例であってこれに限定されない。以上がステップＳ１２０５の処理の説明である。

ターゲットテストケースグループに対応するエントリの代替環境６０３が「可能」であると判定された場合、動的分類モジュール１２３は、代替環境を使用できるか否かを判定する（ステップＳ１２０４）。

具体的には、動的分類モジュール１２３は、条件情報１３２を参照し、条件種別３０２が「動的」かつ項目３０３が「スケジュール」であるエントリの条件３０４に設定されたスケジュールに基づいて、代替環境を使用できるか否かを判定する。例えば、動的分類モジュール１２３は、現在時刻又はテストケースグループの開始予定時刻と、スケジュールとを比較することによって、代替環境を使用できるか否かを判定できる。

代替環境を使用できないと判定された場合、動的分類モジュール１２３は、ステップＳ１２０５に進む。

代替環境を使用できると判定された場合、動的分類モジュール１２３は、ターゲットテストケースグループを実行する代替環境を決定する（ステップＳ１２０６）。

具体的には、動的分類モジュール１２３は、テスト環境情報１３３を参照し、テスト環境種別４０２が「代替」であるエントリを検索する。動的分類モジュール１２３は、検索されたエントリのＣＰＵ使用率４０５又はメモリ使用率４０６の値が最も小さい代替環境を選択する。動的分類モジュール１２３は、選択された代替環境を、ターゲットテストケースグループを実行する代替環境に決定する。以上がステップＳ１２０６の処理の説明である。

次に、動的分類モジュール１２３は、決定された代替環境にテストに必要なリソースが存在するか否かを判定する（ステップＳ１２０７）。

具体的には、動的分類モジュール１２３は、テスト環境情報１３３を参照し、決定された代替環境に対応するエントリのＣＰＵ使用率４０５及びメモリ使用率４０６の値を取得する。動的分類モジュール１２３は、取得されたＣＰＵ使用率及びメモリ使用率に基づいて、項目３０３が「稼働状態」である動的条件を満たすか否かを判定する。項目３０３が「稼働状態」である動的条件を満たさない場合、動的分類モジュール１２３は、決定された代替環境にテストに必要なリソースが存在しないと判定する。

決定された代替環境にテストに必要なリソースが存在すると判定された場合、動的分類モジュール１２３は、ステップＳ１２１１に進む。

決定された代替環境にテストに必要なリソースが存在しないと判定された場合、動的分類モジュール１２３は、コスト算出モジュール１２７を呼び出す（ステップＳ１２０８）。このとき、動的分類モジュール１２３は、ターゲットテストケースグループの識別情報をコスト算出モジュール１２７に入力する。動的分類モジュール１２３は、コスト算出モジュール１２７から使用料金を含む応答を受信するまで待ち状態に移行する。コスト算出モジュール１２７が実行する処理は、図１４を用いて説明する。

動的分類モジュール１２３は、コスト算出モジュール１２７から使用料金を含む応答を受信した場合、予算内で代替環境の構成を追加できるか否かを判定する（ステップＳ１２０９）。

具体的には、動的分類モジュール１２３は、使用料金が予算以下であるか否かを判定する。使用料金が予算以下である場合、動的分類モジュール１２３は、予算内で代替環境を追加できると判定する。

予算内で代替環境を追加できないと判定された場合、動的分類モジュール１２３は、ステップＳ１２１１に進む。

予算内で代替環境を追加できると判定された場合、動的分類モジュール１２３は、テスト環境を追加し（ステップＳ１２１０）、追加されたテスト環境を、選択されたテストケースグループを実行するテスト環境に決定する。その後、動的分類モジュール１２３は、ステップＳ１２１１に進む。テスト環境の追加方法は公知の技術を用いればよいため説明を省略する。

なお、本実施例では、代替環境の使用料金はステージング環境より使用料金が低いため、通常、ステップＳ１２１０では代替環境が生成される。

ステップＳ１２０３からステップＳ１２１０に示すように、動的分類モジュール１２３は、動的条件に基づいてテストケースグループを実行するテスト環境を決定する。

ステップＳ１２１１では、動的分類モジュール１２３は、ターゲットテストケースグループに含まれるテストケースのループ処理を開始する（ステップＳ１２１１）。

具体的には、動的分類モジュール１２３は、グループ情報１３５を参照し、ターゲットテストケースグループのエントリのテストケース６０４に設定されたテストケースの識別情報（ターゲットテストケース）を一つ選択する。このとき、動的分類モジュール１２３は、テストケースの実行順にテストケースの識別情報を選択する。すなわち、左から順にテストケースの識別情報が選択される。テストケース６０４には、テストケースの実行順とは逆の順番でテストケースが設定されているためである。

次に、動的分類モジュール１２３は、ターゲットテストケースをテスト実行キュー情報１３６に登録する（ステップＳ１２１２）。

具体的には、動的分類モジュール１２３は、テスト実行キュー情報１３６にエントリを追加し、追加されたエントリのキューＩＤ７０１に識別情報を設定する。また、動的分類モジュール１２３は、テストケースＩＤ７０２にターゲットテストケースの識別情報を設定し、グループＩＤ７０３にターゲットテストケースグループの識別情報を設定する。さらに、動的分類モジュール１２３は、追加されたエントリの実行環境ＩＤ７０４に決定されたテスト環境の識別情報を設定する。

次に、動的分類モジュール１２３は、ターゲットテストケースグループに含まれる全てのテストケースについて処理が完了したか否かを判定する（ステップＳ１２１３）。

ターゲットテストケースグループに含まれる全てのテストケースについて処理が完了していないと判定された場合、動的分類モジュール１２３は、ステップＳ１２１１に戻り、新たなターゲットテストケースを選択し、同様の処理を実行する。

ターゲットテストケースグループに含まれる全てのテストケースについて処理が完了したと判定された場合、動的分類モジュール１２３は、全てのテストケースグループについて処理が完了したか否かを判定する（ステップＳ１２１４）。

全てのテストケースグループについて処理が完了していないと判定された場合、動的分類モジュール１２３は、ステップＳ１２０２に戻り、新たにターゲットテストケースグループを選択し、同様の処理を実行する。

全てのテストケースグループについて処理が完了したと判定された場合、動的分類モジュール１２３は、テスト実行モジュール１２１に完了通知を送信する（ステップＳ１２１６）。その後、動的分類モジュール１２３は、動的分類処理を終了する。

以上の通り、動的分類モジュール１２３は、動的条件に基づいて、実際にテストケースグループを実行するテスト環境を決定できる。

図１３は、実施例１の情報取得モジュール１２６が実行する処理の一例を説明するフローチャートである。

情報取得モジュール１２６は、周期的に、又は、テスト実行モジュール１２１から開始命令を受け付けた場合に、以下で説明する処理を開始する。

情報取得モジュール１２６は、テスト環境のループ処理を開始する（ステップＳ１３０１）。

具体的には、情報取得モジュール１２６は、テスト環境情報１３３を参照し、ターゲットテスト環境を一つ選択する。

情報取得モジュール１２６は、ターゲットテスト環境から、当該テスト環境の稼働状態を示す状態情報を取得する（ステップＳ１３０２）。

テスト環境の状態とは、ＣＰＵ使用率、メモリ使用率、ネットワーク帯域、ＩＯ性能等を示す。なお、状態情報を取得する方法は公知であるため詳細な説明を省略する。

次に、情報取得モジュール１２６は、取得された状態情報をテスト環境情報１３３に登録する（ステップＳ１３０３）。本実施例では、ターゲットテスト環境のエントリのＣＰＵ使用率４０５及びメモリ使用率４０６に値が設定される。

次に、情報取得モジュール１２６は、全てのテスト環境について処理が完了したか否かを判定する（ステップＳ１３０４）。

全てのテスト環境について処理が完了していないと判定された場合、情報取得モジュール１２６は、ステップＳ１３０１に戻り、新たなターゲットテスト環境を選択し、同様の処理を実行する。

全てのテスト環境について処理が完了したと判定された場合、情報取得モジュール１２６は、処理を終了する。

以上の通り、情報取得モジュール１２６は、テスト環境の状態情報を取得できる。

図１４は、実施例１のコスト算出モジュール１２７が実行する処理の一例を説明するフローチャートである。

コスト算出モジュール１２７は、ステップＳ１２０２において選択されたターゲットテストケースグループを実行する代替環境の利用料金（運用コスト）を算出する（ステップＳ１４０１）。具体的には、以下のような処理が実行される。

コスト算出モジュール１２７は、グループ情報１３５を参照し、ステップＳ１２０２において選択されたテストケースグループのエントリのテストケース６０４からテストケースの識別情報を取得する。

コスト算出モジュール１２７は、テストケース情報１３１を参照し、テストケースＩＤ２０１が取得されたテストケースの識別情報と一致するエントリの予測時間２１０の値を取得する。コスト算出モジュール１２７は、取得された値を合計することによってテストケースグループの予測時間を算出する。

コスト算出モジュール１２７は、ライセンス情報１３４を参照し、各エントリの料金５０５の値を取得する。コスト算出モジュール１２７は、単位時間当たりの料金に予測時間を乗算することによって、各テスト環境の使用料金を算出する。以上がステップＳ１４０１の処理の説明である。

コスト算出モジュール１２７は、使用料金が最も低いテスト環境を選択し、動的分類モジュール１２３に選択されたテスト環境の識別情報及び使用料金を出力する（ステップＳ１４０２）。その後、コスト算出モジュール１２７は、処理を終了する。

動的分類モジュール１２３は、テスト環境の識別情報に基づいて、決定されたテスト環境と同等の構成のテスト環境を追加することができる。

実施例１では、ユーザが運用コストの削減を要求した場合のテスト環境の決定方法について説明した。なお、管理サーバ１００は、ユーザ要求に応じて決定するテスト環境を変更できる。一般化した場合の情報及び処理の内容について説明する。

テストケース情報１３１の代替環境２０７は、選択テスト環境ＩＤに置き換えられる。選択テスト環境ＩＤには、テストケースを実行できるテスト環境の識別情報が格納さる。グループ情報１３５の代替環境６０３は、候補テスト環境ＩＤに置き換えられる。候補テスト環境ＩＤには、具体的なテスト環境の識別情報又はテスト環境の種別が格納される。

グループ評価モジュール１２５は、ステップＳ１１０２からステップＳ１１０４の代わりに、選択テスト環境ＩＤに設定されたテスト環境の中から候補テスト環境を選択する。また、グループ評価モジュール１２５は、グループ情報１３５の候補テスト環境ＩＤに選択された候補テスト環境の識別情報を設定する。例えば、処理コストの削減を目的としたユーザ要求の場合、全てのテストケースを実行可能なテスト環境であり、かつ、ＣＰＵ使用率が最も小さいテスト環境が選択される。

動的分類モジュール１２３は、ステップＳ１２０３において、グループ情報１３５を参照し、候補テスト環境を特定する。動的分類モジュール１２３は、ステップＳ１２０６において、候補テスト環境以外のテスト環境の中から動的条件に基づいて、テスト環境を検索し、検索されたテスト環境の中から実行テスト環境を決定する。

ここで、実施例１で説明した以外のユーザ要求の処理例について説明する。例えば、テスト時間の削減（処理コストの削減）を目的とする場合、静的条件は変更せず、動的条件を「ＣＰＵ使用率＜３０％かつメモリ使用率３０％」、「テスト環境＝２」と設定する方法が考えられる。前述した条件の場合、管理サーバ１００は、代替環境を候補テスト環境に設定し、当該候補テスト環境の中から使用するリソース量が低い代替環境を二つ選択する。

また、静的条件としてソフトウェアの名称又は機能の種別等を設定してもよい。これによって、指定されたソフトウェア又は機能を有するテスト環境を候補テスト環境に設定できる。

実施例１によれば、管理サーバ１００は、テストの内容に基づいてテストケースグループを実行する候補テスト環境を選択し、さらに、テスト環境の状態及びユーザ要求に基づいてテストケースグループを実行するテスト環境を決定できる。

予め候補テスト環境が決定されているため、管理サーバ１００は、テスト環境を迅速に決定できる。また、管理サーバ１００は、テスト環境の状態に応じて、ユーザ要求に合致したテスト環境を決定できる。

例えば、ユーザが運用コストの削減を要求している場合、管理サーバ１００は、代替環境を選択する。ユーザがテスト時間の削減を要求している場合、管理サーバ１００は、使用リソース量が少ないテスト環境、又は、負荷が低いテスト環境を選択する。

実施例２では、オンプレミス型システム１０１及びクラウド型システム１０２のそれぞれにテスト環境が生成される点が異なる。

実施例２の計算機システムの構成及び管理サーバ１００の構成は実施例１と同一である。テストケース情報１３１、ライセンス情報１３４、グループ情報１３５、及びテスト実行キュー情報１３６は実施例１と同一である。実施例２では、条件情報１３２及びテスト環境情報１３３が異なる。

実施例２では、テスト環境情報１３３にシステム種別のカラムが新たに追加される。当該カラムには、例えば、「オンプレミス」及び「クラウド」のいずれかが格納される。これによって、どのシステム上に生成されたテスト環境であるかを識別できる。

実施例２では、テストに要する使用料金の削減を目的とする場合、条件情報１３２には静的条件として「オンプレミス」が設定される。オンプレミス型システム１０１を使用した方が料金を削減できるためである。

実施例２の各モジュールが実行する処理の流れは実施例１と同一である。ただし、静的分類モジュール１２２及び動的分類モジュール１２３が実行する処理が一部異なる。

具体的には、静的分類モジュール１２２は、オンプレミス型システム１０１上のテスト環境を候補テスト環境に選択する。また、動的分類モジュール１２３は、オンプレミス型システム１０１上のテスト環境の中からテストケースグループを実行するテスト環境を決定する。オンプレミス型システム１０１上のテスト環境が不足している場合、動的分類モジュール１２３は、クラウド型システム１０２上のテスト環境の中からテストケースグループを実行するテスト環境を決定する。

前述した制御を実現するためには、例えば、ステップＳ１２０８において、動的分類モジュール１２３は、オンプレミス型システム１０１に項目３０３が「稼働状態」である動的条件を満たすテスト環境を生成できるか否かを判定する。

当該判定結果がＹＥＳの場合、動的分類モジュール１２３は、ステップＳ１２１１に進む。当該判定結果がＮＯの場合、動的分類モジュール１２３は、ステップＳ１２０９に進む。このとき、動的分類モジュール１２３は、システム種別「クラウド」をコスト算出モジュール１２７に入力する。

実施例２も実施例１と同様の効果を有する。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるＣＰＵが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるＣＰＵが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

Claims (14)

1. 一つ以上のテストケースを含むテストケースグループを実行する複数のテスト環境が構築された計算機システムと接続する管理計算機であって、
   前記計算機システムは、複数の計算機を含み、
   前記管理計算機は、
   プロセッサ、前記プロセッサに接続されるメモリ、前記プロセッサに接続されるネットワークインタフェースを有し、
   前記テストケースグループの識別情報、及び前記テストケースグループに含まれるテストケースの特性に基づいて決定された候補テスト環境の識別情報から構成されるエントリを含むグループ情報と、前記テスト環境の状態に関する条件である動的条件を含む条件情報と、を保持し、
   前記プロセッサは、
   第１のテストケースグループの実行契機を検出した場合、前記グループ情報を参照して前記第１のテストケースグループの候補テスト環境を特定し、
   前記候補テスト環境の状態を示す状態情報を取得し、
   前記条件情報及び前記状態情報に基づいて、前記候補テスト環境の中から前記第１のテストケースグループを実行する実行テスト環境を決定することを特徴とする管理計算機。
2. 請求項１に記載の管理計算機であって、
   前記管理計算機は、前記テスト環境の構成及び状態を管理するテスト環境情報を保持し、
   前記プロセッサは、
   前記テスト環境情報を参照して、前記動的条件を満たす前記候補テスト環境が存在するか否かを判定し、
   前記動的条件を満たす前記候補テスト環境が存在すると判定された場合、前記動的条件を満たす前記候補テスト環境の中から前記実行テスト環境を決定することを特徴とする管理計算機。
3. 請求項２に記載の管理計算機であって、
   前記プロセッサは、
   前記動的条件を満たす前記候補テスト環境が存在しないと判定された場合、前記候補テスト環境の構成及び前記動的条件に基づいて、前記動的条件を満たすテスト環境を生成し、
   前記生成されたテスト環境を前記実行テスト環境に決定することを特徴とすることを特徴とする管理計算機。
4. 請求項３に記載の管理計算機であって、
   前記第１のテストケースグループは、複数のテストケースを含み、
   前記条件情報は、前記テストケースの特性に関する条件である静的条件を含み、
   前記プロセッサは、
   前記第１のテストケースグループに含まれる各テストケースの特性を解析し、
   前記解析の結果及び前記静的条件に基づいて前記候補テスト環境を選択し、
   前記第１のテストケースグループの識別情報、及び前記選択された候補テスト環境の識別情報から構成されるエントリを前記グループ情報に登録することを特徴とする管理計算機。
5. 請求項４に記載の管理計算機であって、
   前記管理計算機は、前記テストケースの識別情報、前記テストケース間の依存関係、及び前記テストケースを実行可能なテスト環境の識別情報から構成されるエントリを含むテストケース情報を保持し、
   前記プロセッサは、
   前記テストケース情報によって管理される複数のテストケースの各々について、前記静的条件を満たすテスト環境を特定し、
   前記テストケース間の依存関係に基づいて前記第１のテストケースグループを生成し、
   前記第１のテストケースグループに含まれる各テストケースの前記静的条件を満たすテスト環境の中から前記候補テスト環境を選択し、
   前記テストケースグループの識別情報、及び前記候補テスト環境の識別情報から構成されるエントリを前記グループ情報に登録することを特徴とする管理計算機。
6. 請求項３に記載の管理計算機であって、
   前記管理計算機は、前記テスト環境の利用料金を算出するためのコスト情報を保持し、
   前記動的条件は、前記テスト環境のリソースの使用率を指定する条件を含み、
   前記複数のテスト環境は、第１のテスト環境、及び前記第１のテスト環境より前記テストケースの実行に要するコストが低い第２のテスト環境を含み、
   前記プロセッサは、
   前記第１のテストケースグループの前記候補テスト環境が前記第２のテスト環境である場合、前記第２のテスト環境の状態を示す状態情報を取得し、
   前記状態情報及び前記動的条件に基づいて、前記第２のテスト環境を用いて前記第１のテストケースグループを実行できるか否かを判定し、
   前記第２のテスト環境を用いて前記第１のテストケースグループを実行できないと判定された場合、前記コスト情報に基づいて前記候補テスト環境と同一のテスト環境を追加するためのコストを算出し、
   前記コストが閾値以下であると判定された場合、新たに第２のテスト環境を追加し、当該第２のテスト環境を前記実行テスト環境に決定することを特徴とする管理計算機。
7. 請求項６に記載の管理計算機であって、
   前記動的条件は、前記第２のテスト環境が使用可能な時間を示す条件を含み、
   前記プロセッサは、
   前記第１のテストケースグループの前記候補テスト環境が前記第２のテスト環境である場合、前記第２のテスト環境を使用できる時間帯であるか否かを判定し、
   前記第２のテスト環境を使用できる時間帯であると判定された場合、前記第２のテスト環境を前記実行テスト環境に決定し、
   前記第２のテスト環境を使用できる時間帯でないと判定された場合、前記第１のテスト環境を前記実行テスト環境に決定することを特徴とする管理計算機。
8. 一つ以上のテストケースを含むテストケースグループを実行する複数のテスト環境が構築された計算機システムと接続する管理計算機におけるテスト環境決定方法であって、
   前記計算機システムは、複数の計算機を含み、
   前記管理計算機は、
   プロセッサ、前記プロセッサに接続されるメモリ、前記プロセッサに接続されるネットワークインタフェースを有し、
   前記テストケースグループの識別情報、及び前記テストケースグループに含まれるテストケースの特性に基づいて決定された候補テスト環境の識別情報から構成されるエントリを含むグループ情報と、前記テスト環境の状態に関する条件である動的条件を含む条件情報と、を保持し、
   前記テスト環境決定方法は、
   前記プロセッサが、第１のテストケースグループの実行契機を検出した場合、前記グループ情報を参照して前記第１のテストケースグループの候補テスト環境を特定する第１のステップと、
   前記プロセッサが、前記候補テスト環境の状態を示す状態情報を取得する第２のステップと、
   前記プロセッサが、前記条件情報及び前記状態情報に基づいて、前記候補テスト環境の中から前記第１のテストケースグループを実行する実行テスト環境を決定する第３のステップと、を含むことを特徴とするテスト環境決定方法。
9. 請求項８に記載のテスト環境決定方法であって、
   前記管理計算機は、前記テスト環境の構成及び状態を管理するテスト環境情報を保持し、
   前記第３のステップは、
   前記プロセッサが、前記テスト環境情報を参照して、前記動的条件を満たす前記候補テスト環境が存在するか否かを判定するステップと、
   前記動的条件を満たす前記候補テスト環境が存在すると判定された場合、前記プロセッサが、前記動的条件を満たす前記候補テスト環境の中から前記実行テスト環境を決定するステップと、を含むことを特徴とするテスト環境決定方法。
10. 請求項９に記載のテスト環境決定方法であって、
    前記第３のステップは、
    前記動的条件を満たす前記候補テスト環境が存在しないと判定された場合、前記プロセッサが、前記候補テスト環境の構成及び前記動的条件に基づいて、前記動的条件を満たすテスト環境を生成するステップと、
    前記プロセッサが、前記生成されたテスト環境を前記実行テスト環境に決定するステップと、を含むことを特徴とすることを特徴とするテスト環境決定方法。
11. 請求項１０に記載のテスト環境決定方法であって、
    前記第１のテストケースグループは、複数のテストケースを含み、
    前記条件情報は、前記テストケースの特性に関する条件である静的条件を含み、
    前記テスト環境決定方法は、
    前記プロセッサが、前記第１のテストケースグループに含まれる各テストケースの特性を解析するステップと、
    前記プロセッサが、前記解析の結果及び前記静的条件に基づいて前記候補テスト環境を選択するステップと、
    前記プロセッサが、前記第１のテストケースグループの識別情報、及び前記選択された候補テスト環境の識別情報から構成されるエントリを前記グループ情報に登録するステップと、を含むことを特徴とするテスト環境決定方法。
12. 請求項１１に記載のテスト環境決定方法であって、
    前記管理計算機は、前記テストケースの識別情報、前記テストケース間の依存関係、及び前記テストケースを実行可能なテスト環境の識別情報から構成されるエントリを含むテストケース情報を保持し、
    前記テスト環境決定方法は、
    前記プロセッサが、前記テストケース情報によって管理される複数のテストケースの各々について、前記静的条件を満たすテスト環境を特定するステップと、
    前記プロセッサが、前記テストケース間の依存関係に基づいて前記第１のテストケースグループを生成するステップと、
    前記プロセッサが、前記第１のテストケースグループに含まれる各テストケースの前記静的条件を満たすテスト環境の中から前記候補テスト環境を選択するステップと、
    前記プロセッサが、前記テストケースグループの識別情報、及び前記候補テスト環境の識別情報から構成されるエントリを前記グループ情報に登録するステップと、を含むことを特徴とするテスト環境決定方法。
13. 請求項１０に記載のテスト環境決定方法であって、
    前記管理計算機は、前記テスト環境の利用料金を算出するためのコスト情報を保持し、
    前記動的条件は、前記テスト環境のリソースの使用率を指定する条件を含み、
    前記複数のテスト環境は、第１のテスト環境、及び前記第１のテスト環境より前記テストケースの実行に要するコストが低い第２のテスト環境を含み、
    前記第２のステップは、前記プロセッサが、前記第１のテストケースグループの前記候補テスト環境が前記第２のテスト環境である場合、前記第２のテスト環境の状態を示す状態情報を取得するステップを含み、
    前記第３のステップは、
    前記プロセッサが、前記状態情報及び前記動的条件に基づいて、前記第２のテスト環境を用いて前記第１のテストケースグループを実行できるか否かを判定するステップと、
    前記第２のテスト環境を用いて前記第１のテストケースグループを実行できないと判定された場合、前記プロセッサが、前記コスト情報に基づいて前記候補テスト環境と同一のテスト環境を追加するためのコストを算出するステップと、
    前記コストが閾値以下であると判定された場合、前記プロセッサが、新たに第２のテスト環境を追加し、当該第２のテスト環境を前記実行テスト環境に決定するステップと、を含むことを特徴とするテスト環境決定方法。
14. 請求項１３に記載のテスト環境決定方法であって、
    前記動的条件は、前記第２のテスト環境が使用可能な時間を示す条件を含み、
    前記第３のステップは、
    前記プロセッサが、前記第１のテストケースグループの前記候補テスト環境が前記第２のテスト環境である場合、前記第２のテスト環境を使用できる時間帯であるか否かを判定するステップと、
    前記第２のテスト環境を使用できる時間帯であると判定された場合、前記プロセッサが、前記第２のテスト環境を前記実行テスト環境に決定するステップと、
    前記第２のテスト環境を使用できる時間帯でないと判定された場合、前記プロセッサが、前記第１のテスト環境を前記実行テスト環境に決定するステップと、を含むことを特徴とするテスト環境決定方法。

Images