(57)【特許請求の範囲】
【請求項１】
プロセッサとメモリとを有し、ソフトウェアのテストを管理するＣＩサーバと、
プロセッサとメモリとを有する一つ以上の計算機を含み、前記ＣＩサーバからの要求に応じて前記ソフトウェアのテストを実行する計算クラスタと、を含む継続的インテグレーションシステムであって、
前記ＣＩサーバは、
前記テストを実行するソフトウェアを受け付けて、前記テストに割り当てるリソースを決定し、当該リソースを前記計算クラスタに通知して前記テストを実行させて、前記計算クラスタから実行結果を取得するＣＩサービス部と、
前記ＣＩサービス部からの要求に応じて、前記テストに割り当てるリソースを推定するリソース推定部と、を有し、
前記リソース推定部は、
前記テストごとに一意となるテストＩＤを割り当てるテストＩＤ算出部と、
前記テストＩＤごとに前記テストの実行中に消費したリソースの情報を取得する結果取得部と、
過去に実行した前記テストＩＤと前記取得したリソースの情報とを対応付けて格納する履歴情報と、
前記ＣＩサービス部からリソースの推定を要求されたときには、前記履歴情報に基づいて、前記テストＩＤごとにテストの実行に必要なリソースを推定し、推定結果をリソース割当情報として前記ＣＩサービス部に通知する推定部と、を含み、
前記ＣＩサービス部は、
前記テストに割り当てるリソースの推定要求をリソース推定部に送信し、前記リソース推定部から受け付けたリソースの推定結果を、前記テストに割り当てるリソースとして決定することを特徴とする継続的インテグレーションシステム。
【請求項２】
請求項１に記載の継続的インテグレーションシステムであって、
前記ＣＩサービス部は、
前記テストを実行するソフトウェアとして、テストコードとソースコードを特定する識別子を含むコードメタ情報を受け付けて、前記テストに対応するジョブＩＤを生成し、前記リソースの推定要求に前記コードメタ情報と前記ジョブＩＤを含めて前記リソース推定部へ送信し、
前記リソース推定部のテストＩＤ算出部は、
前記リソースの推定要求を受け付けて、前記コードメタ情報と前記ジョブＩＤから前記テストＩＤを算出することを特徴とする継続的インテグレーションシステム。
【請求項３】
請求項２に記載の継続的インテグレーションシステムであって、
前記コードメタ情報は、前記テストコードとソースコードを格納するリポジトリＩＤとブランチＩＤを含み、
前記テストＩＤ算出部は、
前記リポジトリＩＤとブランチＩＤとジョブＩＤのうち少なくとも一つを用いて前記テストＩＤを算出することを特徴とする継続的インテグレーションシステム。
【請求項４】
請求項３に記載の継続的インテグレーションシステムであって、
前記履歴情報は、
前記リポジトリＩＤとブランチＩＤとジョブＩＤとテストＩＤを含み、
前記推定部は、
前記履歴情報に前記テストＩＤと一致するリソースの情報が存在しない場合には、前記リポジトリＩＤとブランチＩＤが一致するテストＩＤのリソースの情報を代用することを特徴とする継続的インテグレーションシステム。
【請求項５】
請求項１に記載の継続的インテグレーションシステムであって、
前記リソース推定部は、
前記リソースを推定するためのアルゴリズムを複数格納したアルゴリズム情報を有し、
前記ＣＩサービス部は、
前記テストを実行するソフトウェアと、推定するアルゴリズムを受け付けて、前記テストに割り当てるリソースの推定要求に前記アルゴリズムを含めて前記リソース推定部に送信し、
前記リソース推定部は、
前記アルゴリズムを受け付けて、前記推定部が、当該アルゴリズムを用いて前記リソースを推定することを特徴とする継続的インテグレーションシステム。
【請求項６】
請求項１に記載の継続的インテグレーションシステムであって、
前記ＣＩサービス部は、
前記テストを実行するソフトウェアと推定するリソースのマージンを受け付けて、前記テストに割り当てるリソースの推定要求に前記マージンを含めて前記リソース推定部に送信し、
前記リソース推定部は、
前記マージンを受け付けて、前記推定部が、当該マージンを加えて前記リソースを推定することを特徴とする継続的インテグレーションシステム。
【請求項７】
請求項１に記載の継続的インテグレーションシステムであって、
前記結果取得部は、
前記取得したリソースの情報から消費したリソース量を選択し、当該リソース量が所定の閾値を超えていれば、前記テストの負荷が過大となったことを示す通知を出力することを特徴とする継続的インテグレーションシステム。
【請求項８】
請求項１に記載の継続的インテグレーションシステムであって、
前記履歴情報は、
前記テストを実行するインスタンス名を含み、前記テストＩＤと１以上のインスタンス名とリソースの情報とを対応付けて格納し、
前記推定部は、
前記テストＩＤ内のインスタンス名ごとに前記テストの実行に必要なリソースを推定することを特徴とする継続的インテグレーションシステム。
【請求項９】
請求項１に記載の継続的インテグレーションシステムであって、
前記履歴情報は、
前記テストを実行する際に割り当てたリソースの情報を含み、
前記リソース推定部は、
前記テストＩＤ毎に、前記テストの実行中に消費したリソースの情報と割り当てたリソースの情報を時系列的に表示する画面を生成することを特徴とする継続的インテグレーションシステム。
【請求項１０】
プロセッサとメモリとを有し、ソフトウェアのテストを管理するＣＩサーバが、プロセッサとメモリとを有する一つ以上の計算機を含む計算クラスタに前記ソフトウェアのテストを実行させる際に前記計算機のリソースを制御するリソース制御方法であって。する計算クラスタと、を含むリソース制御方法であって、
前記ＣＩサーバのＣＩサービス部が、前記テストを実行するソフトウェアを受け付ける第１のステップと、
ＣＩサービス部が、前記テストに割り当てるリソースの推定要求を前記ＣＩサーバのリソース推定部に送信する第２のステップと、
前記リソース推定部が、前記テストに割り当てるリソースの推定要求を受け付けて、前記テストごとに一意となるテストＩＤを割り当てる第３のステップと、
前記リソース推定部が、過去に実行した前記テストＩＤと、テストの実行中に消費したリソースの情報とを対応付けて格納する履歴情報に基づいて、前記テストＩＤごとにテストの実行に必要なリソースを推定し、当該推定結果をリソース割当情報として前記ＣＩサービス部に通知する第４のステップと、
前記ＣＩサービス部が、前記リソース割当情報を受け付けて当該リソース割当情報を前記計算クラスタに通知して前記テストを実行させる第５のステップと、
前記ＣＩサービス部が、前記計算クラスタから前記テストの実行結果を取得する第６のステップと、
前記リソース推定部が、前記テストの実行中に消費したリソースの情報を取得して、前記履歴情報に格納する第７のステップと、
を含むことを特報とするリソース制御方法。
【請求項１１】
請求項１０に記載のリソース制御方法であって、
前記第１のステップは、
前記テストを実行するソフトウェアとして、テストコードとソースコードを特定する識別子を含むコードメタ情報を受け付けて、前記テストに対応するジョブＩＤを生成し、
前記第２のステップは、
前記リソースの推定要求に前記コードメタ情報と前記ジョブＩＤを含めて前記リソース推定部へ送信し、
前記第３のステップは、
前記コードメタ情報と前記ジョブＩＤから前記テストＩＤを算出することを特徴とするリソース制御方法。
【請求項１２】
請求項１１に記載のリソース制御方法であって、
前記コードメタ情報は、前記テストコードとソースコードを格納するリポジトリＩＤとブランチＩＤを含み、
前記第３のステップは、
前記リポジトリＩＤとブランチＩＤとジョブＩＤのうち少なくとも一つを用いて前記テストＩＤを算出することを特徴とするリソース制御方法。
【請求項１３】
請求項１２に記載のリソース制御方法であって、
前記履歴情報は、
前記リポジトリＩＤとブランチＩＤとジョブＩＤとテストＩＤを含み、
前記第４のステップは、
前記履歴情報に前記テストＩＤと一致するリソースの情報が存在しない場合には、前記リポジトリＩＤとブランチＩＤが一致するテストＩＤのリソースの情報を代用することを特徴とするリソース制御方法。
【請求項１４】
請求項１０に記載のリソース制御方法であって、
前記第１のステップは、
前記テストを実行するソフトウェアと、推定するアルゴリズムを受け付け、
前記第２のステップは、
前記テストに割り当てるリソースの推定要求に前記アルゴリズムを含めて前記リソース推定部に送信し、
前記第４のステップは、
前記アルゴリズムを受け付けて、前記リソースを推定するために予め設定された複数のアルゴリズムを格納したアルゴリズム情報から前記受け付けたアルゴリズムを選択し、当該アルゴリズムを用いて前記リソースを推定することを特徴とするリソース制御方法。
【請求項１５】
請求項１０に記載のリソース制御方法であって、
前記第１のステップは、
前記テストを実行するソフトウェアと、推定するリソースのマージンを受け付けて、
前記第２のステップは、
前記テストに割り当てるリソースの推定要求に前記マージンを含めて前記リソース推定部に送信し、
前記第４のステップは、
前記マージンを受け付けて、当該マージンを加えて前記リソースを推定することを特徴とするリソース制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムの不具合解消のためのテストの際に消費する計算機リソースを削減する計算機システム及びその方法に関する。
【背景技術】
【０００２】
ソフトウェア開発において、コーディングとソフトウェアテスト（以下テストと呼称）を継続的に繰り返す継続的インテグレーション（ＣＩ：Continuous Integration）が行われている。ＣＩを行うときは、ソフトウェア構成管理（ＳＣＭ：Software Configuration Management）サーバにてユーザが生成したソースコードやテストコード（以下まとめてコード群と呼称）を管理する。【０００３】
ソフトウェア構成管理サーバ（以下、ＳＣＭサーバ）は、ユーザからのリクエストやコード群の更新に応じて、継続的インテグレーションサーバ（以下ＣＩサーバ）上でテストコードを実行する。なお、ソースコードにはテストの対象となるソフトウェアの処理が記述されており、テストコードにはソースコードを評価する処理（テスト処理）、およびビルドやテスト処理の起動等、テストに必要な一連の処理が記述されている。【０００４】
また、近年ではＣＩサーバの機能をサービスとして提供するＣＩサービスが登場し始めている。ＣＩサービスとは、ユーザがＳＣＭサーバのコード群を更新すると、ＣＩサービスのサービス提供者が保有するＣＩサーバ上でユーザのテストコードを自動的に実行し、実行結果を電子メールやチャットによりユーザへ通知するサービスである。【０００５】
上記従来の技術では、ＣＩサービスにおいて、ユーザのテストコードを実行するときは、テストの実行基盤上に、テストごとに仮想マシンやコンテナ（ＬＸＣ（Linux Containers）等のコンテナ型仮想化技術によって生成されたコンテナ）等のインスタンスを構築して、当該インスタンス上でテストを実行する。【０００６】
現在のＣＩサービスにおいては、テストを実行するためのインスタンスに、十分な量のコンピューティングリソース（プロセッサやメモリ、ディスクサイズ、ネットワーク帯域等、以下リソースと呼称）を一律に割り当てる。これにより、ＣＩサーバの実行環境のリソース不足に起因したユーザのテストの失敗を抑制できるが、一方で負荷の少ないテストにも一律にリソースが割り当てられることからリソースの無駄が多い、という問題があった。【０００７】
ＣＩサービスの実行基盤としてパブリッククラウド環境を用いることにより、負荷に応じて基盤リソースを増強できるため、リソースが枯渇する心配は無いものの、リソースを増強すると、その分コストが増大するためＣＩサービスの提供者は採算が取りづらくなる。リソースのコストを低減するために、ＣＩサービスにおいては、テストを実行する実行基盤のリソースを効率的に使用することが要求されている。【０００８】
ＣＩの実行基盤のリソースを効率的に使用する技術として特許文献１、２が知られている。【０００９】
特許文献１には、テストの網羅性を担保しながらも、ソースコードの更新箇所に関係するテストのみを実行するように、テストの実行範囲を変更することで、回帰テストの量を削減するテストシステムが開示されている。【００１０】
特許文献２には、使用可能なリソースが制限された中で、テストがソフトウェアに与える品質属性（ＳＱＡ：Software Quality Attribute）や過去のテスト結果の成否の情報に基づき、テストの集合から実行するテストの部分集合を抽出する手法が開示されている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２０１５−０６９４００号公報
【特許文献２】米国特許第９４０５６６１号
【発明の概要】
【発明が解決しようとする課題】
【００１２】
サービス提供者が上述のＣＩをサービスとして提供するとき、前記先行技術文献ではテストの実行基盤となるリソースを効率化に用いることは困難である。以下に、その理由を示す。【００１３】
特許文献１および２は、テストの大部分が前回のテストと同一の処理という点に着目し、過去のテスト情報やテスト結果をもとにテストの中から一部の処理を抽出し、抽出した処理のみ実行することで、テストに必要なリソース量を削減している。【００１４】
しかし、ソフトウェアの品質保証という観点を考えると、全てのテストを実行しなければ、テスト工程で問題が無いことを保証できない。このため、前記従来例のように実行するテストを部分的に抽出して実行することは望ましくない。特に、ＣＩサービスにおいては、サービス提供者がリソースを削減する目的で、ユーザの生成したテストから実行するテストを部分的に抽出して実行することはサービス品質の観点において困難である。【００１５】
本発明は以上の点を考慮してなされたもので、過去のテストの履歴情報に基づいて各テストに必要なリソースを推定することにより、各テストのインスタンスに割り当てるリソースを変更し、テスト実行時に割り当てるリソース量を低減することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、プロセッサとメモリとを有し、ソフトウェアのテストを管理するＣＩサーバと、プロセッサとメモリとを有する一つ以上の計算機を含み、前記ＣＩサーバからの要求に応じて前記ソフトウェアのテストを実行する計算クラスタと、を含む継続的インテグレーションシステムであって、前記ＣＩサーバは、前記テストを実行するソフトウェアを受け付けて、前記テストに割り当てるリソースを決定し、当該リソースを前記計算クラスタに通知して前記テストを実行させて、前記計算クラスタから実行結果を取得するＣＩサービス部と、前記ＣＩサービス部からの要求に応じて、前記テストに割り当てるリソースを推定するリソース推定部と、を有し、前記リソース推定部は、前記テストごとに一意となるテストＩＤを割り当てるテストＩＤ算出部と、前記テストＩＤごとに前記テストの実行中に消費したリソースの情報を取得する結果取得部と、過去に実行した前記テストＩＤと前記取得したリソースの情報とを対応付けて格納する履歴情報と、前記ＣＩサービス部からリソースの推定を要求されたときには、前記履歴情報に基づいて、前記テストＩＤごとにテストの実行に必要なリソースを推定し、推定結果をリソース割当情報として前記ＣＩサービス部に通知する推定部と、を含み、前記ＣＩサービス部は、前記テストに割り当てるリソースの推定要求をリソース推定部に送信し、前記リソース推定部から受け付けたリソースの推定結果を、前記テストに割り当てるリソースとして決定する。
【発明の効果】
【００１７】
本発明によれば、各テストに必要なリソースを推定することにより、テストに割り当てる計算機リソースの量を変更することが可能となって、テストの実行時のリソース消費量を削減できる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例１を示し、リソース推定の単位であるテストを示すブロック図である。
【図２】本発明の実施例１を示し、リソース推定装置を含むＣＩシステムの一例を示すブロック図である。
【図３】本発明の実施例１を示し、リソース推定装置の機能要素の一例を示すブロック図である。
【図４】本発明の実施例１を示し、リソース推定装置のハードウェアの構成の一例を示すブロック図である。
【図５Ａ】本発明の実施例１を示し、履歴情報に含まれるテストＩＤ管理テーブルの一例を示す図である。
【図５Ｂ】本発明の実施例１を示し、履歴情報に含まれる履歴管理テーブルの一例を示す図である。
【図６】本発明の実施例１を示し、ＣＩシステムで行われる処理の一例を示すシーケンス図である。
【図７】本発明の実施例１を示し、リソース推定装置が出力する表示画面の一例を示す図である。
【図８】本発明の実施例２を示し、履歴情報に格納される履歴管理テーブルの一例を示す図である。
【図９】本発明の実施例２を示し、ＣＩシステムで行われる処理の一例を示すシーケンス図である。
【図１０】本発明の実施例３を示し、ＣＩサーバの構成の一例を示すブロック図である。
【発明を実施するための形態】
【００１９】
以下、本発明の一実施形態について添付図面を用いて説明する。
【実施例１】
【００２０】
図１は、本実施例１におけるリソースの使用量を推定する単位であるテスト１５０を示すブロック図である。本実施例１におけるテスト１５０は、継続的に開発するソフトウェア（ソースコード）をテストするために、同一の目的で更新されてきた一連のテストコード１５１−１〜１５１−３を表す。ただし、「テスト１５０」ではなく符号の無い「テスト」もしくは「ソフトウェアテスト」と表記される場合は情報の単位ではなく、ソフトウェアの評価手法としてのテストを指す。【００２１】
テストコード１５１−１〜１５１−３はソフトウェアを評価するための処理、およびビルドやテスト起動等のテストに必要な一連の処理を表す文字列の羅列で、１つ以上のファイルに記述される。以下の説明では、テストコードの全般を示す場合には「−」以降を省略した符号「１５１」を使用する。他の構成要素の符号についても同様である。【００２２】
ソフトウェアの開発に応じてテストコード１５１−１がテストコード１５１−２〜１５１−３へ順次変化したとしても、それらは同一のテスト１５０とみなす。図５にて後述するテストＩＤ（識別子）７４は、テスト１５０を一意に定める識別子を表す。【００２３】
本実施例１ではテスト１５０を計算クラスタ３０で自動的に実行するための設定ファイル（Jenkinsfileなど）や、インスタンス構成を定義したファイル（docker-compose.yml等）もテストコード１５１として扱う。【００２４】
＜システムの全体構成＞
図２は、リソース推定装置２を含むＣＩ（Continuous Integration：継続的インテグレーション）システム１の機能要素の一例を示すブロック図である。本図を用いて、ＣＩシステム１の各機能要素の役割および、リソース推定装置２との関係を示す。【００２５】
ＣＩシステム１はＳＣＭサーバ１０とＣＩサーバ２０とリソース推定装置２と計算クラスタ３０とが通信ネットワークで接続された計算機システムである。ＳＣＭサーバ１０と、ＣＩサーバ２０と、リソース推定装置２と、計算クラスタ３０は、１台以上のコンピュータ等のハードウェアもしくは、１個以上の仮想マシンやコンテナ等のソフトウェアで構成され、通信ネットワークを介して相互に通信を行う。【００２６】
ＳＣＭサーバ１０は、リポジトリ１１やブランチ１２の単位でユーザ端末５０で生成したコード群４０を管理する。ユーザ端末５０がＳＣＭサーバ１０のコード群４０を更新すると、ＳＣＭサーバ１０は、ＣＩサーバ２０に対して更新されたコード群４０およびコードメタ情報４１を送信する。【００２７】
コード群４０は、ユーザ端末５０が生成したテストコード１５１やソースコードを含む。コードメタ情報４１は、コード群４０に付随する情報であり、コード群４０に含まれるテストコード１５１やソースコードを特定するためのリポジトリ１１やブランチ１２のＩＤ等を含む。【００２８】
ＣＩサーバ２０は、ユーザ端末５０からのリクエストやＳＣＭサーバ１０のリポジトリ１１の更新に応じて、ソフトウェアテストを計算クラスタ３０に実行させる。ＣＩサーバ２０は、ＳＣＭ連携機能２１と、リソース推定連携機能２２と、計算クラスタ連携機能２３と、ジョブ情報２４を有する。【００２９】
ＳＣＭ連携機能２１は、ＳＣＭサーバ１０からコード群４０およびコードメタ情報４１を受信し、ジョブ情報２４を参照してコードメタ情報４１に対応するジョブメタ情報４２を生成する機能を有する。【００３０】
リソース推定連携機能２２は、リソース推定装置２にコードメタ情報４１と、ジョブメタ情報４２を通知して、テスト１５０に割り当てるリソース量の推定を要求する。なお、テスト１５０は、ジョブメタ情報４２に含まれるジョブの識別子と、コードメタ情報４１に含まれるテストコード１５１の識別子やソースコードの識別子を基にリソース推定装置２によって特定される。【００３１】
リソース推定連携機能２２は、リソース推定装置２からリソース量の推定要求に対するリソース割当情報４３を受信すると、テスト１５０を実行するためのインスタンス３４に割り当てるリソースを決定する他、テスト１５０の実行後にログ情報４４をリソース推定装置２に通知する機能を有する。なお、リソースとは、計算クラスタ３０内のホスト３３のプロセッサの割当量やメモリの容量、ディスクサイズ、ネットワーク帯域等のコンピュータリソースを指す。【００３２】
計算クラスタ連携機能２３は、計算クラスタ３０に対し、インスタンス３４の生成（リソース要求）や、インスタンス３４上でのテスト１５０の実行（テスト１５０の実行要求）や、インスタンス３４の削除を要求する。ジョブ情報２４は、ＳＣＭサーバ１０から受信したコードメタ情報４１に対応するジョブメタ情報４２を管理する。【００３３】
ジョブメタ情報４２は、コード群４０に対応するジョブＩＤを有する。また、ＣＩサーバ２０の機能によっては、ジョブメタ情報４２内にＳＣＭサーバ１０内におけるコード群４０のリポジトリ１１やブランチ１２のＩＤを含む場合がある。この場合はジョブメタ情報４２をコードメタ情報４１の代替として用いることができる。なお、ジョブＩＤは、例えばＪｅｎｋｉｎｓ（登録商標）におけるジョブ名やＣｏｎｃｏｕｒｓｅＣＩ（登録商標）におけるパイプライン名やグループ名であり、ＣＩサーバ２０で生成することができる。【００３４】
ログ情報４４は、テスト１５０の成否（実行結果）やテスト１５０の開始時刻（実行時刻８５）や、計算クラスタ３０のホスト３３に生成したインスタンス３４のＩＤや、インスタンス３４に割り当てたリソース量の値等を有する。なお、インスタンス３４のＩＤは、計算クラスタ管理装置３１等で生成されたＩＤを用いることができる。リソース推定装置２は、ジョブメタ情報４２とログ情報４４から、テスト１５０を実行したインスタンス３４のＩＤと、コード群４０に対応するジョブＩＤとの対応関係を特定することができる。【００３５】
また、ログ情報４４には、ＣＩサーバ２０によってはインスタンス３４が消費したリソース量の情報を有する場合もある。リソース割当情報４３は、テスト１５０を実行するために計算クラスタ３０でインスタンス３４に割り当てるホスト３３のリソース量を指定する情報を有する。【００３６】
計算クラスタ３０は、テスト１５０を実行する環境であり、例えばＫｕｂｅｒｎｅｔｅｓ（登録商標）やＯｐｅｎＳｔａｃｋ（登録商標）等によって構成される。計算クラスタ３０は計算クラスタ管理装置３１とリソース監視装置３２、および１つ以上のホスト３３−１〜３３−ｎからなる。【００３７】
計算クラスタ管理装置３１は、ＣＩサーバ２０からのリクエストに応じて、ホスト３３上にテスト１５０を実行するためのインスタンス３４を生成する。リソース監視装置３２はインスタンス３４のリソース消費量を収集および保持する。なお、リソース監視装置３２が保持するリソース消費量の情報は、リソース消費結果４５としてリソース推定装置２が取得することができる。ホスト３３はインスタンス３４を稼働させる。ホスト３３は物理マシンや仮想マシンにより構築される。インスタンス３４はテスト１５０を実行するため、ホスト３３上に構築された仮想マシンやコンテナである。【００３８】
＜論理構成及び物理構成＞
図３はリソース推定装置２の機能要素の一例を示すブロック図である。リソース推定装置２はテストＩＤ算出部３と結果取得部４とリソース推定部５と履歴情報６とアルゴリズム情報７からなる。【００３９】
テストＩＤ算出部３は、コードメタ情報４１およびジョブメタ情報４２および、図５Ａに示すテストＩＤ管理テーブル７０を参照してテスト１５０ごとに一意となるテストＩＤ７４を算出し、結果取得部４およびリソース推定部５に通知する。本処理は図６のステップＰ３にて詳述する。【００４０】
結果取得部４は、リソース監視装置３２から取得したリソース消費結果４５と、ＣＩサーバ２０から取得したログ情報４４と、テストＩＤ算出部３から取得したテストＩＤ７４に基づき、テストＩＤ７４ごとのインスタンス３４の消費リソース量を算出し、算出結果の値を履歴情報６に格納する。本処理は図６のステップＰ１０にて詳述する。【００４１】
履歴情報６はテストＩＤ７４ごとにインスタンス３４に割り当てたリソース量の情報を保持する。履歴情報６は図５Ａ、図５Ｂにて詳述する。【００４２】
リソース推定部５は、テストＩＤ算出部３から取得したテストＩＤ７４に基づいて履歴情報６からテストＩＤに関連するリソース情報８２（図５にて詳述）を取得する。そして、リソース推定部５は、アルゴリズム情報７からユーザ端末５０が選択したアルゴリズムを取得して、当該アルゴリズムを用いて、テストＩＤ７４で指定されたテスト１５０を実行するために必要なインスタンス３４のリソース量を算出する。本処理は図６のステップＰ５にて詳述する。【００４３】
アルゴリズム情報７は、リソース量を推定するための計算処理を実行するためのプログラムを１つ以上保持する。このプログラムを本実施例１ではアルゴリズムと呼称する。アルゴリズムは、リソース情報８２に基づいてインスタンス３４へ割り当てるリソース量を算出する所定の処理であり、例えば回帰分析や、標準偏差を考慮した算術平均である。【００４４】
また、各アルゴリズムは、算出した割当リソース量に対し、ユーザ端末５０のユーザが設定した任意の余裕（例えばアルゴリズムの算出値より１０％多いリソース量を割当リソース量とする等）を設けることができる。なお、リソース量を推定するアルゴリズム情報７については、上記の他に公知または周知の技術を適用することができる。【００４５】
図４は、リソース推定装置２のハードウェア構成の一例を示すブロック図である。リソース推定装置２は、入出力デバイス６２と、プロセッサ６３と、外部記憶デバイス６４と、主記憶デバイス６５と、通信制御デバイス６１を含んで構成される。これらは、内部バス６６を介して相互に接続される。【００４６】
入出力デバイス６２は、ユーザ（または管理者）が各種操作入力を行うためのキーボードやマウス等の入力デバイスと、各種情報を表示するための液晶ディスプレイやタッチパネルのような出力デバイスである。【００４７】
プロセッサ６３は、リソース推定装置２の演算処理を行うハードウェアである。また、外部記憶デバイス６４は、大容量の記憶容量を有する記憶デバイスであり、たとえばハードディスク装置やＳＳＤ（Solid State Drive）である。外部記憶デバイス６４は、図２で示した履歴情報６およびアルゴリズム情報７を保持するほか、主記憶デバイス６５に呼び出される各種プログラムの実行ファイルを保持する。【００４８】
主記憶デバイス６５は、例えば半導体メモリから構成され、各種プログラムやテーブルから呼び出されたデータを一時的に保持する。主記憶デバイス６５は、図２で示したテストＩＤ算出部３と、結果取得部４と、リソース推定部５のプログラム群を含む。また、各種テーブルへのアクセスを高速にするため、外部記憶デバイス６４の代わりに、主記憶デバイス６５に履歴情報６やアルゴリズム情報７を保持しても良い。外部記憶デバイス６４および主記憶デバイス６５は、プロセッサ６３からアクセスできる。【００４９】
なお、本実施例ではテストＩＤ算出部３と、結果取得部４と、リソース推定部５をプログラムとして説明するが、これらはハードウェアによって同等の機能が構成されるとしてもよいし、ソフトウェアとハードウェアによって構成されていてもよい。【００５０】
通信制御デバイス６１は、外部との通信を制御する機能を有するハードウェアであり、通信ネットワーク６７を介してリソース推定装置２をＣＩシステム１に接続する。【００５１】
プロセッサ６３は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ６３は、テストＩＤ算出プログラムに従って処理することでテストＩＤ算出部３として機能する。他のプログラムについても同様である。さらに、プロセッサ６３は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。【００５２】
リソース推定装置２の各機能を実現するプログラム、テーブル等の情報は、外部記憶デバイス６４や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。【００５３】
＜テーブル＞
図５Ａは履歴情報６に格納されるテストＩＤ管理テーブル７０の一例を示す図である。図５Ｂは履歴情報６に格納される履歴管理テーブル８０の一例を示す図である。テストＩＤ管理テーブル７０は、コードメタ情報４１とジョブメタ情報４２からテストＩＤ７４を算出するための情報を保持するテーブルである。【００５４】
テストＩＤ管理テーブル７０は、リポジトリＩＤフィールド７１と、ブランチＩＤフィールド７２と、ジョブＩＤフィールド７３と、テストＩＤフィールド７４を一つのレコードに含む。各レコードはテスト１５０ごとに一意となるテストＩＤ７４に対応している。【００５５】
リポジトリＩＤ７１は、対象となるリポジトリ１１の識別子を格納する記憶領域である。リポジトリＩＤ７１は、ＳＣＭサーバ１０においてコード群４０が管理されているリポジトリ１１を一意に特定する識別情報であり、ＳＣＭサーバ１０ごとに一意となる値である。【００５６】
ブランチＩＤ７２は、対象となるブランチ１２の識別子を格納する記憶領域である。ブランチＩＤ７２は、ＳＣＭサーバ１０においてコード群４０が管理されているリポジトリ１１内のブランチ１２を一意に特定する識別情報であり、リポジトリ１１ごとに一意となる値である。【００５７】
ジョブＩＤ７３は、対象となるジョブの識別子を格納する記憶領域である。ジョブＩＤ７３は、ＣＩサーバ２０においてテストを実行するジョブを一意に特定する識別情報である。なお、リポジトリ１１とジョブとの対応関係は、１つのリポジトリ１１に対し、複数のジョブが存在する場合もあれば、複数のリポジトリが１つのジョブに対応する場合もある。ジョブＩＤ７３はＣＩサーバ２０ごとに一意となる値である。【００５８】
テストＩＤ７４は、対象となるテスト１５０の識別子を格納する記憶領域である。テストＩＤ７４は、テスト１５０ごとに一意となる値であり、リポジトリＩＤ７１と、ブランチＩＤ７２と、ジョブＩＤ７３を基にユーザ端末５０が定めた算出方法を用いて算出される。算出方法は図６のステップＰ４にて詳述する。テストＩＤ７４はリソース推定装置２ごとに一意となる値である。  【００５９】
図５Ｂの履歴管理テーブル８０は、各テスト１５０と、テスト１５０の実行時に割り当てたリソース情報８２とを対応付けるテーブルである。【００６０】
履歴管理テーブル８０は、テストＩＤ８１と、リソース情報８２を有する。更にリソース情報８２は、割当リソース８３と、消費リソース８４と、実行時刻８５を一つのレコードに含む。各レコードはテストＩＤ８１で指定されたテスト１５０が実行されたときのリソース情報８２を表す。ＣＩシステム１では、同一のテスト１５０が複数回実行されうるため、同一のテストＩＤ８１のレコードが複数回出現しうる。【００６１】
テストＩＤ８１は、対象となるテスト１５０の識別子を格納する記憶領域である。テストＩＤ８１は、テスト１５０ごとに一意に割り振られたＩＤであり、図５ＡのテストＩＤ管理テーブル７０に登録されたテストＩＤ７４と同一である。【００６２】
割当リソース８３は、対象となる割当リソース８３を格納する記憶領域である。割当リソース８３は、ＣＩサーバ２０がテスト実行時に計算クラスタ３０のインスタンス３４へ割り当てたリソース量である。【００６３】
消費リソース８４は、テスト１５０で実際に消費したリソース量を格納する記憶領域である。消費リソース８４は、テスト実行時に当該テスト１５０のインスタンス３４が実際に消費したリソース量である。なお、割当リソース８３および消費リソース８４は、リソース量として仮想ＣＰＵのコア数やメモリ量、ディスク量、ネットワーク帯域等、リソースの種類ごとにそれぞれ値を保持することができる。【００６４】
実行時刻８５は、対象となる実行時刻８５を保持する記憶領域である。実行時刻８５は、テスト実行開始時の時刻情報である。【００６５】
なお、本実施例１では各種情報をテーブルとして説明をしているが、テーブル以外（例えばリストや連想配列）によって構成されていてもよい。【００６６】
＜シーケンス図＞
図６はリソース推定装置２を含むＣＩシステム１の処理の例を示すシーケンス図である。本シーケンス図を用いて、ユーザ端末５０がＳＣＭサーバ１０のリポジトリ１１のコード群４０を更新してから、ＣＩサーバ２０が計算クラスタ３０にテスト１５０を実行させて、テスト１５０の実行結果をユーザ端末５０に通知するまでの処理を示す。【００６７】
以下、具体的な処理の手順を示す。まずユーザ端末５０が、ＳＣＭサーバ１０のリポジトリ１１もしくはリポジトリ１１内の特定ブランチ１２にて管理されているコード群４０を更新する（Ｐ１）。ＳＣＭサーバ１０は、コード群４０が更新されると、ＣＩサーバ２０にコード群４０および、コードメタ情報４１を送信する（Ｐ２）。【００６８】
次に、ＣＩサーバ２０は、コードメタ情報４１およびジョブメタ情報４２からなるメタ情報群をリソース推定装置２へ送信する（Ｐ３）。なお、ジョブメタ情報４２に含まれるジョブＩＤは、コードメタ情報４１に含まれるリポジトリＩＤ７１やブランチＩＤ７２をもとにＣＩサーバ２０内のジョブ情報２４を参照することにより取得される。【００６９】
その後、リソース推定装置２は、テストＩＤ算出部３にて、テスト１５０に対応するテストＩＤを算出する（Ｐ４）。これは例えば、リソース推定装置２は図５Aの履歴管理テーブル８０を参照し、送信されたコードメタ情報４１に含まれるリポジトリＩＤ７１と、ブランチＩＤ７２およびジョブメタ情報４２に含まれるジョブＩＤ７３の値が全て一致するレコードのテストＩＤ７４を取得する。一方、該当するレコードが無い場合、リソース推定装置２が、類似したテスト１５０を参考にテストＩＤ７４を生成して、新規にレコードを登録してもよい。【００７０】
類似するテスト１５０を参考にするとは、例えば、リソース推定装置２が予め決められたＩＤもしくはＩＤの組（例えばリポジトリＩＤ７１とブランチＩＤ７２）が同一のレコードを検索する。そして、リソース推定装置２は、当該テストＩＤ７４の算出規則を参考にして、自身のテストＩＤ７４を算出することなどで行われる（例えば、検索したレコードのテストＩＤ７４がリポジトリＩＤ７１とブランチＩＤ７２の組み合わせの場合、自身のテストＩＤ７４もリポジトリＩＤ７１とブランチＩＤ７２の組とするなど）。【００７１】
これにより、ＳＣＭサーバ１０において、リポジトリ１１の配下で新規にブランチ１２を生成した場合などでは、履歴情報６に対象となるテストＩＤ７４のリソース情報が無い場合でも、リポジトリＩＤ７１とブランチＩＤ７２が同一のレコードのテストＩＤ７４から履歴管理テーブル８０のリソース情報８２を代用することで、リソースを推定することが可能となる。【００７２】
更に、類似するテスト１５０の検索結果が無い場合、リソース推定装置２は、予め決められたＩＤもしくはＩＤの組み合わせ（例えばリポジトリＩＤ７１とブランチＩＤ７２の組み合わせ）をテストＩＤ７４とし、リポジトリＩＤ７１と、ブランチＩＤ７２と、ジョブＩＤ７３と、テストＩＤ７４とを生成して新規のレコードとして履歴情報６のテストＩＤ管理テーブル７０に登録する。【００７３】
その後、リソース推定装置２はリソース推定部５にて、履歴管理テーブル８０から当該テストＩＤ７４を含む全てのレコードからリソース情報８２を取得し、アルゴリズム情報７に含まれる１つ以上のアルゴリズムから、ユーザ端末５０が指定したアルゴリズムを選択してテスト１５０のインスタンス３４に割り当てるリソース量を推定する（Ｐ５）。【００７４】
例えば、ユーザ端末５０がアルゴリズムとして算術平均を指定した場合、リソース推定装置２は、取得したリソース情報のうち、履歴管理テーブル８０の消費リソース８４に含まれるリソース量の値の算術平均を、インスタンス３４に割り当てるリソース量として推定する。【００７５】
履歴管理テーブル８０のテストＩＤ８１に、当該テストＩＤが含まれない場合は、リソース推定装置２は、予め決められた処理で類似するテストＩＤを算出し、当該テストＩＤ８１に対応するリソース情報８２を用いてリソース量を推定する。【００７６】
予め決められた処理とは、例えば、テストＩＤ７４がリポジトリＩＤ７１とブランチＩＤ７２の組で表されている場合、リポジトリＩＤ７１が同一でブランチＩＤ７２が「ｍａｓｔｅｒ」のテストＩＤ７４を当該テストＩＤの代替として利用する等の処理である。これは、ソフトウェア開発において、新規にブランチ１２を生成する場合、「ｍａｓｔｅｒ」ブランチから派生させることを利用している。なお、類似するテストＩＤ７４が無い場合、リソース推定装置２は、予め定められたリソース量を推定値として算出する。【００７７】
その後、リソース推定装置２は推定したリソース量をリソース割当情報４３としてＣＩサーバ２０に通知する（Ｐ６）。【００７８】
その後、ＣＩサーバ２０はリソース割当情報４３で指定されたリソース量が割り当てられたインスタンス３４を用いてテスト１５０のソフトウェアテストを計算クラスタ３０に実行させる（Ｐ７）。具体的には、ＣＩサーバ２０が計算クラスタ管理装置３１に対し、リソース割当情報４３で指定されたリソース量が割り当てられたインスタンス３４の生成を要求する（Ｐ７１）。【００７９】
計算クラスタ管理装置３１は、ホスト３３を１つ選択し、当該ホスト３３にリソース割当情報４３で指定されたリソース量のインスタンス３４を生成させる（Ｐ７２）。その後、ＣＩサーバ２０は生成されたインスタンス３４に、ＳＣＭサーバ１０から受け付けたコード群４０を送信して、インスタンス３４上でソフトウェアテストを実行させ（Ｐ７３）、ソフトウェアテストの実行結果を取得する（Ｐ７４）。ソフトウェアテストが終了すると、ＣＩサーバ２０は、計算クラスタ管理装置３１に対して当該ソフトウェアテストに対応するインスタンス３４の削除を要求する（Ｐ７５）。【００８０】
計算クラスタ管理装置３１は、ホスト３３に指定したインスタンス３４を削除させる（Ｐ７６）。なお、リソース監視装置３２は、常時、計算クラスタ３０上のインスタンス３４が消費したリソースの情報を収集している（Ｐ７７）。【００８１】
ソフトウェアテストの終了後、ＣＩサーバ２０は、実行したテスト１５０のコードメタ情報４１と、ジョブメタ情報４２と、ログ情報４４を、リソース推定装置２に送信する（Ｐ８）。なお、ログ情報４４には、ソフトウェアテストの成否や、ソフトウェアテストの開始時刻、生成したインスタンス３４のＩＤ、インスタンス３４に割り当てたリソース量の値等が含まれる。また、ＣＩサーバ２０の機能によっては、インスタンス３４が消費したリソース量の値が含まれる場合もある。【００８２】
その後、リソース推定装置２は、リソース監視装置３２からインスタンスＩＤとリソース消費結果４５（テスト１５０のソフトウェアテストで実際に消費したリソース量）を取得する（Ｐ９）。なお、リソース消費結果４５は、ソフトウェアテストを実行した際にインスタンス３４が使用したリソース量の最大値もしくは平均値等の予め設定された値をリソースの種類ごと（例えばプロセッサ、メモリ等）に記録した情報を有する。ただし、リソース量の値の算出方法（最大値や平均値）はリソース推定装置２内で統一されているものとする。なお、この処理はログ情報４４内にインスタンス３４が消費したリソース量の値が含まれている場合は省略して良い。【００８３】
その後、リソース推定装置２は、ソフトウェアテストの結果を履歴情報６に格納する（Ｐ１０）。具体的には、まず、リソース推定装置２はテストＩＤ算出部３において、ステップＰ４と同様の処理によりコードメタ情報４１およびジョブメタ情報４２からテストＩＤを算出する。次に、リソース推定装置２は、結果取得部４において、ログ情報４４から割当リソース８３と実行時刻８５を取得し、リソース消費結果４５から消費リソース８４を取得する。そして、リソース推定装置２の結果取得部４は、算出したテストＩＤのエントリを履歴管理テーブル８０に追加して、上記取得した割当リソース８３と実行時刻８５及び消費リソース８４を格納する。【００８４】
ただし、ログ情報４４に消費リソースの情報が含まれる場合、消費リソース８４の値をログ情報４４から取得しても良い。なお、消費リソース８４の値がパーセント等の割合表記の場合は、割り当てたリソース量とパーセントの値の積を消費リソースの値にする等の処理により、リソースの値となるよう変換する。例えば、仮想ＣＰＵを１コア割り当てたとき、リソース消費結果のＣＰＵの値が３０％のときは、仮想ＣＰＵの消費リソースは０．３コアのように変換する。【００８５】
その後、リソース推定装置２は、消費リソース８４の値と所定の閾値とを比較して、消費リソース８４がインスタンス３４に予め定められたリソース量の最大値に近いか否かを判定し、最大値に近い場合はユーザ端末５０に負荷が過大となったという通知を出力する（Ｐ１１）。これにより、テスト１５０の負荷が大きく、テスト１５０の実行速度が落ちている可能性があることをユーザ端末５０へ通知することができる。なお、リソース推定装置２は、消費リソース８４の値が所定の閾値を超えていれば、ホスト３３で消費したリソース量が所定の最大値に近い負荷が過大な状態と判定することができる。【００８６】
最後に、ＣＩサーバ２０は、テスト１５０の成否をユーザ端末５０およびＳＣＭサーバ１０に通知する（Ｐ１２）。【００８７】
以上の処理により、ＣＩサーバ２０が計算クラスタ３０にテスト１５０を実行させる際には、リソース推定装置２を用いてテスト１５０を実行するインスタンス３４に割り当てるホスト３３のリソース量を、過去のテストの履歴情報に基づいて推定する。テストの大部分が前回のテストと同一の処理という点に着目し、過去に割り当てたリソースの履歴情報に基づいて、今回のテスト１５０に必要なリソース量を推定することにより、割り当てるリソースが過剰になるのを抑制し、割り当てるリソース量を低減することができる。【００８８】
＜画面表示例＞
図７はリソース推定装置２がユーザ端末５０もしくはＣＩサービスの管理者に提示する表示画面の一例を示す図である。この表示画面１００では、テストＩＤごとに使用するアルゴリズム等のパラメータ設定ができる他、リソース削減効果を表示できる。表示画面１００はテストＩＤ選択領域１０１と、設定表示領域１０２と、リソース削減効果表示領域１０３と、履歴情報表示領域１０４を有する。なお、テストＩＤ選択領域１０１以外の表示領域は、必ずしも同一画面上に表示する必要はなく、それぞれ独立した画面として表示しても良い。【００８９】
テストＩＤ選択領域１０１において、ユーザ端末５０もしくはＣＩサービスの管理者はテストＩＤを選択する。設定表示領域１０２と、リソース削減効果表示領域１０３と、履歴情報表示領域１０４は、本領域にて選択したテストＩＤに関する情報が表示される。【００９０】
設定表示領域１０２は、選択されたテストＩＤに設定されたパラメータが表示され、ユーザ端末５０もしくはＣＩサービスの管理者は本領域のプルダウンメニュー等からパラメータを確認、もしくは変更できる。選択可能なパラメータとしては、テストＩＤの設定方法や、リソースを推定するアルゴリズムや、参照する履歴数（履歴管理テーブル８０のレコード数）や、リソースの推定結果を補正するマージン等を有する。【００９１】
マージンは、テスト１５０に割り当てるリソース消費として推定した値に対し、ＧＵＩやＡＰＩ、設定ファイルにより設定された所定の余裕を付加すけることで、推定した値と実際に消費される値とのズレによるリソース不足を抑制することができる。【００９２】
テストＩＤの設定方法は、リポジトリＩＤ７１、ブランチＩＤ７２、ジョブＩＤ７３の中からどのような組み合わせをテストＩＤ７４として設定するかを決めるためのパラメータである。テストＩＤ設定方法が変更された場合、リソース推定装置２は履歴情報６内のテストＩＤ管理テーブル７０および履歴管理テーブル８０のテストＩＤ７４の値を更新する。また、参照履歴数とは、リソース推定の際に、過去何個の履歴情報を参照するかを設定する値である。【００９３】
なお、テストＩＤ設定方法の更新において、複数のテストＩＤ７４が１つに統合される場合は、予め定められた手順でテストＩＤ７４およびその履歴情報を更新する。例えば、元々テストＩＤ７４として、リポジトリＩＤ７１とブランチＩＤ７２を組み合わせた値を使用しており、本設定画面により、リポジトリＩＤ７１のみをテストＩＤ７４に使用するよう変更した場合、リソース推定装置２は、テストＩＤ管理テーブル７０内のうち、当該リポジトリＩＤを有する全てのレコードのテストＩＤ７４をリポジトリＩＤ７１の値に変更し、履歴管理テーブル８０から、当該リポジトリＩＤ７１を含んだテストＩＤ７４を有する全てのレコードを、リポジトリＩＤ７１をテストＩＤとする新規のレコードとして統合する等の処理を行う。【００９４】
リソース削減効果表示領域１０３は、リソース推定装置２により、削減されたリソースの量および割合を表示する領域である。ここに表示する値は、例えばデフォルトで割り当てられるリソース量から実際に割り当てたリソース量の値を差し引いた値の平均値等である。【００９５】
履歴情報表示領域１０４は、各リソースの割当量および実際の消費量の時系列的な推移を表示する領域である。本領域は例えば、縦軸をリソース量、横軸を時刻とする面グラフで表される。グラフは各リソースの値ごとに生成される。グラフには、例えば、デフォルトで割り当てられるリソース量を示すデフォルト割当量１０５や各テストに割り当てたリソース量の推移を示すリソース割当グラフ１０６や、各テストで実際に消費されたリソース量の推移を示すリソース消費グラフ１０７を有する。【００９６】
なお、パラメータ設定の方法は、表示画面からの設定に限定されるものではなく、例えばＡＰＩ（Application Programming Interface）や設定ファイルを用いても良い。【００９７】
以上の処理により、実施例１において、リソース推定装置２は各テストに必要なリソース量を推定することにより、テストに合わせて割当リソースを変更し、テストの実行時のリソース消費量を削減できるようになる。【００９８】
以上説明したように、リソース推定装置２は、ＣＩサーバ２０から受信したテスト１５０を特定する情報（コードメタ情報４１とジョブメタ情報４２）からテストＩＤ７４を生成し、テストＩＤ７４に一致する履歴管理テーブル８０のレコードから、当該テスト１５０の過去の実行時に消費したリソース量（消費リソース８４）を取得する。【００９９】
そして、リソース推定装置２は、過去のリソース消費量（消費リソース８４）に基づいて、今回のテスト１５０に割り当てるリソース量を推定し、推定したリソース量をリソース割当情報４３としてＣＩサーバ２０へ通知する。【０１００】
ＣＩサーバ２０は、リソース割当情報４３で計算クラスタ３０にリソースを要求して、ホスト３３にインスタンス３４を生成させる。これにより、ホスト３３には、リソース推定装置２が過去のリソース消費量の実績に基づいて推定したリソース量を割り当てたインスタンス３４が生成される。【０１０１】
そして、ＣＩサーバ２０は、計算クラスタ３０にテストコード１５１とソースコード等を送信して、当該インスタンス３４でテスト１５０を実行させる。テスト１５０が終了すると、ＣＩサーバ２０はテスト１５０の結果をホスト３３から受信し、リソース推定装置２に、コードメタ情報４１と、ジョブメタ情報４２と、ログ情報４４（割当リソース８３と実行時刻８５を含む）を送信する。リソース推定装置２は、リソース監視装置３２からインスタンスＩＤとリソース消費結果４５（実際の消費リソース８４）を受信する。【０１０２】
そして、リソース推定装置２は、コードメタ情報４１とジョブメタ情報４２に対応するテストＩＤのエントリを履歴管理テーブル８０に追加して、上記取得した割当リソース８３と実行時刻８５及び消費リソース８４を格納する。これにより、テストＩＤ毎に、過去のテスト１５０で実際に消費したリソース量が消費リソース８４として蓄積され、次回のリソース量の推定に用いられる。これにより、リソース推定装置２が、各テスト１５０に必要なリソース量を過去の実績から推定することにより、テスト１５０に割り当てる計算機リソースの量を変更することが可能となって、テストの実行時のリソース消費量を削減できる。【０１０３】
なお、上記実施例１では、リソース推定装置２がリソース監視装置３２からリソース消費結果４５を受信する例を示したが、リソース推定装置２がＣＩサーバ２０を介してリソース監視装置３２からリソース消費結果４５を受信するようにしても良い。
【実施例２】
【０１０４】
実施例２として、複数のインスタンス３４を生成するテスト１５０に対し、各インスタンス３４の消費リソース量を推定する際のリソース推定装置２の処理を示す。ただし、実施例１と同一の処理または構成についての説明は省略する。【０１０５】
１回のテスト１５０で複数のインスタンス３４が生成される場合、テスト１５０内のインスタンス３４毎に消費するリソース量を推定し、テスト１５０実行時にインスタンス３４毎に消費したリソース量の履歴の取得を行う必要がある。本実施例２では、テストコード１５１やテストコード１５１が含む設定情報、およびＣＩサーバ２０のログ情報４４に基づき、インスタンス３４とリソース量を対応付ける。【０１０６】
このため、リソース推定装置２はリソースの推定時や、リソース消費結果４５の取得時において、実施例１で取得したコードメタ情報４１やジョブメタ情報４２、ログ情報４４、リソース消費結果４５に加え、コード群４０もＣＩサーバ２０から取得する。【０１０７】
＜テーブル＞
図８は実施例２における履歴情報６に格納される履歴管理テーブル８０Ａのテーブル構成例を示す図である。なお、テストＩＤ管理テーブル７０の構成例は実施例１と同一のため省略する。本実施例２の履歴管理テーブル８０Ａは、前記実施例１の履歴管理テーブル８０にインスタンス名２１１のフィールドを追加した点が相違する。【０１０８】
履歴管理テーブル８０Ａは各テスト１５０で生成するインスタンス３４とそのリソース情報８２とを対応付けるテーブルであり、テストＩＤ８１とインスタンス名２１１とリソース情報８２を一つのレコードに含む。リソース情報８２は割当リソース８３と、消費リソース８４と、実行時刻８５を有する。各レコードは、テストＩＤ８１で指定されたテスト１５０が生成する個々のインスタンス３４が実行されたときのリソース情報８２を保持する。このため、同一のテストＩＤ８１およびインスタンス名２１１が複数のレコードに出現しうる。テストＩＤ８１およびリソース情報８２は実施例１と同様なため省略する。【０１０９】
インスタンス名２１１は、対象となるインスタンス３４の名称を格納する記憶領域である。インスタンス名２１１は、テスト１５０で生成する個々のインスタンス３４のテストコード１５１内における名称であり、テストコード１５１やテストコード１５１が含む設定情報を基に算出される。算出方法は図９のステップＰ１４にて詳述する。インスタンス名２１１はテストＩＤ８１ごとに一意である。【０１１０】
＜シーケンス図＞
図９は、実施例２においてリソース推定装置２を含むＣＩシステム１で行われる処理の一例を示すシーケンス図である。本シーケンス図において、ユーザ端末５０がＳＣＭサーバ１０のリポジトリ１１のコード群４０を更新してから、計算クラスタ３０にテスト１５０を実行させて、テスト１５０の実行結果をユーザ端末５０に通知するまでの処理を示す。図９において、点線で表されたシーケンスは実施例１の図６と同一の処理であるため、これらの説明は省略するか、関連箇所のみ簡素に説明する。【０１１１】
ＳＣＭサーバ１０がＣＩサーバ２０に対して、コード群４０およびコードメタ情報４１送信した後（Ｐ２）、ＣＩサーバ２０は、コードメタ情報４１と、ジョブメタ情報４２と、コード群４０をリソース推定装置２へ送信する（Ｐ２００）。【０１１２】
その後、リソース推定装置２はテストＩＤ算出部３にて、テスト１５０に対応するテストＩＤを算出する（Ｐ４）。【０１１３】
その後、リソース推定装置２はリソース推定部５にて、当該テストＩＤで生成する個々のインスタンス３４に割り当てるリソース量を推定する（Ｐ２０１）。具体的には、リソース推定装置２は、コード群４０に含まれるテストコード１５１やテストコード１５１に付随する設定情報からインスタンス名２１１を選択する。次に、リソース推定装置２は、履歴管理テーブル８０Ａから当該テストＩＤに関係するレコードのうち、選択されたインスタンス名２１１のリソース情報８２をインスタンス名２１１ごとに取得する。【０１１４】
そして、リソース推定装置２は、アルゴリズム情報７が含む１つ以上のアルゴリズムの中から、ユーザ端末５０が選択したアルゴリズムを用いて、インスタンス３４ごとに割り当てるリソース量を推定する。なお、履歴管理テーブル８０Ａに当該テストＩＤが無い場合は実施例１と同様に予め定められた手法で、類似するテストＩＤを参照するか、もしくは予め定められたリソース量を推定値として算出する。【０１１５】
コード群４０に記載されたインスタンス名２１１が履歴管理テーブル８０Ａに無い場合も、前述のテストＩＤがない場合と同様であり、リソース推定装置２は、予め定められた手法で類似するテストＩＤ７４を検出し、検出されたテストＩＤ７４に同一のインスタンス名２１１があるか否かを判定し、同一のインスタンス名２１１が存在する場合はその値を参照する。同一のインスタンス名２１１が無い場合、リソース推定装置２は、予め定められたリソース量を当該インスタンス名２１１の割当リソース量として算出する。【０１１６】
その後、リソース推定装置２は、インスタンス名２１１ごとのリソース割当量をリソース割当情報４３としてＣＩサーバ２０に送信する（Ｐ２０２）。その後、ＣＩサーバ２０は、リソース割当情報４３で指定されたリソース量を各インスタンス３４に割り当て、テスト１５０のソフトウェアテストを実行させる（Ｐ７）。ソフトウェアテストの実行処理は前記実施例１の図６と同様である。【０１１７】
ソフトウェアテストの終了後、ＣＩサーバ２０は実行したテスト１５０のコードメタ情報４１と、ジョブメタ情報４２とログ情報４４をリソース推定装置２に送信する（Ｐ８）。ログ情報４４には、図２で示したように、テスト１５０の成否やテスト１５０の開始時刻、生成したインスタンス３４のＩＤ、各インスタンス３４に割り当てたリソース量の値、インスタンス名２１１とインスタンスＩＤとの対応関係等が含まれる。【０１１８】
なお、ＣＩサーバ２０の機能によっては、インスタンス３４が消費したリソース量の値が含まれる場合もある。【０１１９】
その後、リソース推定装置２は、ログ情報４４に含まれる複数のインスタンスＩＤのリソース消費結果４５をリソース監視装置３２からそれぞれ取得する（Ｐ２０３）。リソース消費結果４５は、インスタンス３４ごとに使用したリソース量の最大値もしくは平均値をリソースごと（例えばＣＰＵ、メモリ等）に記録したものである。ただし、リソース量の値が最大値か平均値かはリソース推定装置２内で統一するものとする。また、この処理はログ情報４４内にインスタンス３４が消費したリソース量の値が含まれている場合は省略して良い。【０１２０】
その後、リソース推定装置２は、テスト１５０の結果を履歴情報６に格納する（Ｐ２０４）。具体的には、まず、リソース推定装置２はテストＩＤ算出部３において、上記ステップＰ４と同様の処理によりコードメタ情報４１およびジョブメタ情報４２からテストＩＤを算出する。【０１２１】
次にリソース推定装置２の結果取得部４が、ログ情報４４からソフトウェアテストの実行時刻８５と、インスタンス名２１１とインスタンスＩＤとの対応関係と、インスタンスＩＤごとの割当リソース８３を取得し、リソース消費結果４５からインスタンスＩＤごとの消費リソース８４を取得する。そして、リソース推定装置２は、算出したテストＩＤと共に、個々のインスタンス３４の割当リソース８３と、消費リソース８４と、実行時刻８５をインスタンス名と対応付けながら履歴管理テーブル８０に格納する。ここで、ログ情報４４に消費リソースの情報が含まれる場合は、消費リソース８４の値をログ情報４４から取得しても良い。以降の処理は実施例１と同一のため説明を省略する。【０１２２】
以上の処理により、実施例２において、複数のインスタンス３４を生成するテスト１５０についても、リソース推定装置２は各インスタンス３４のリソース量を推定することが可能となる。
【実施例３】
【０１２３】
図１０は、本発明の実施例３を示し、ＣＩサーバ２０と計算クラスタ３０の構成の一例を示すブロック図である。前記実施例１では、ＣＩサーバ２０とリソース推定装置２を独立した計算機で構成した例を示したが、本実施例３は、ＣＩサーバの機能とリソース推定装置を統合したＣＩサーバ２００とした例を示す。【０１２４】
また、上記実施例１では、計算クラスタ３０内で、計算クラスタ管理装置３１とリソース監視装置３２を独立した計算機で構成した例を示したが、本実施例３では、ひとつの管理計算機３００に統合した例を示す。【０１２５】
ＣＩサーバ２００は、ＣＩサービス部２０Ａとリソース推定部２Ａを含む。リソース推定部２Ａは、前記実施例１のリソース推定装置２と同様に機能し、リソース割当情報４３をリソース推定連携機能２２に出力する。ＣＩサービス部２０Ａは、前記実施例１のＣＩサーバ２０と同様に機能し、計算クラスタ３０で実行するソフトウェアテストを管理する。本実施例３のように、ＣＩサーバ２０とリソース推定装置２をひとつの計算機に統合することができる。【０１２６】
また、計算クラスタ３０では、管理計算機３００が、計算クラスタ管理部３１Ａと、リソース監視部３２Ａを有する。計算クラスタ管理部３１Ａは前記実施例１の計算クラスタ管理装置３１と同様に機能する。また、リソース監視部３２Ａは、前記実施例１のリソース監視装置３２と同様に機能する。【０１２７】
本実施例３のように、計算クラスタ３０においても計算クラスタ管理部とリソース監視部をひとつの管理計算機３００に統合することができる。【０１２８】
＜まとめ＞
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。【０１２９】
また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。【０１３０】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【図１】
0006692454.tif 000002
【図２】
0006692454.tif 000003
【図３】
0006692454.tif 000004
【図４】
0006692454.tif 000005
【図５Ａ】
0006692454.tif 000006
【図５Ｂ】
0006692454.tif 000007
【図６】
0006692454.tif 000008
【図７】
0006692454.tif 000009
【図８】
0006692454.tif 000010
【図９】
0006692454.tif 000011
【図１０】
0006692454.tif 000012