JP2017167763A - 情報処理装置、試験実行方法および試験実行プログラム - Google Patents

Abstract

【課題】使用するリソースを削減した利便性の高いテスト環境を提供することを課題とする。【解決手段】試験制御装置は、複数のコンポーネントを有するシステムの改版を行うユーザごとに、改版で利用されるコンポーネントの種別と改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶する。試験制御装置は、端末装置からリクエストを受信した場合、当該端末装置のユーザに対応付けられる利用構成表に基づいて、リクエストの転送先となるコンポーネントの種別を特定する。試験制御装置は、特定された種別に対応するサーバ装置が起動中の場合、リクエストをサーバ装置に転送し、サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置にリクエストを転送する。【選択図】図２

Description

本発明は、情報処理装置、試験実行方法および試験実行プログラムに関する。

近年、Ｗｅｂ、ＡＰ（アプリケーション）、ＤＢ（データベース）などの複数のコンポーネントからなるＩＣＴ（Information and Communication Technology）システムを用いたサービスが増えている。これらのコンポーネントは、従来の物理サーバや仮想マシン（ＶＭ：Virtual Machine）に比べて、ディスク量やメモリ量が少なく起動時間が短いコンテナ技術を用いて動作させることが増えている。

このようなコンポーネントを用いたサービスは、複数人のチームで開発され、機能追加や改善などによる頻繁な改版を繰り返すことが多い。また、頻繁な改版であっても、サービスを停止しないように、テスト環境を用意しておき、予め作成したテストコードを用いてテストを実行することが一般的である。例えば、共用のテストシステムを１つまたは複数用意する手法や開発者ごとにテストシステムを用意する手法が知られている。

特開２０１０−１１３３８１号公報 特開平４−１９５４３６号公報

しかしながら、上記技術では、使用するリソースが多く、利便性も悪い。例えば、共用のテストシステムを用いる場合では、使用するリソースが少なくて済むが、複数のメンバーが同時に使用することができないので、利便性が悪く、頻繁な改版ができない。また、開発者ごとにテストシステムを用意する手法では、使用するリソースが多くなり、コストが増大する。

１つの側面では、使用するリソースを削減した利便性の高いテスト環境を提供することができる情報処理装置、試験実行方法および試験実行プログラムを提供することを目的とする。

第１の案では、情報処理装置は、複数のコンポーネントを有するシステムの改版を行うユーザごとに、前記改版で利用されるコンポーネントの種別と前記改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶する記憶部を有する。情報処理装置は、端末装置からリクエストを受信した場合、当該端末装置のユーザに対応付けられる前記利用構成表に基づいて、前記リクエストの転送先となるコンポーネントの種別を特定する特定部を有する。情報処理装置は、特定された種別に対応するサーバ装置が起動中の場合、前記リクエストを前記サーバ装置に転送し、前記サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置に前記リクエストを転送する転送制御部を有する。

一実施形態によれば、使用するリソースを削減した利便性の高いテスト環境を提供することができる。

図１は、実施例１にかかるシステムを説明する図である。 図２は、実施例１にかかる試験制御装置の機能構成を示す機能ブロック図である。 図３は、利用構成表に記憶される情報の例を示す図である。 図４は、コンテナ情報表に記憶される情報の例を示す図である。 図５は、フロー制御表に記憶される情報の例を示す図である。 図６は、コンテナ削除を説明する図である。 図７は、実施例１にかかるコンテナ起動およびリクエスト転送の処理の流れを示すフローチャートである。 図８は、実施例１にかかるコンポーネントの改版を説明する図である。 図９は、実施例２にかかる試験制御装置の機能構成を示す機能ブロック図である。 図１０は、実施例２にかかる専有コンテナ種表に記憶される情報の例を示す図である。 図１１は、実施例２にかかるフロー制御表に記憶される情報の例を示す図である。 図１２は、実施例２にかかるコンテナ起動およびリクエスト転送の処理の流れを示すフローチャートである。 図１３は、実施例２にかかる専有コンテナを用いたテスト環境を説明する図である。 図１４は、実施例３にかかる利用コンテナの推定を説明する図である。 図１５は、実施例３にかかる専有コンテナの推定を説明する図である。 図１６は、実施例３にかかる専有コンテナの推定を説明する図である。 図１７は、実施例３にかかるテストケースの確認処理の流れを示すフローチャートである。 図１８は、実施例３にかかる専有コンテナの推定処理の流れを示すフローチャートである。 図１９は、ハードウェア構成例を説明する図である。

以下に、本願の開示する情報処理装置、試験実行方法および試験実行プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１にかかるシステムを説明する図である。図１に示すように、このシステムは、複数のユーザ端末１から３と試験制御装置１０とを有し、各ユーザ端末に、テスト環境を提供するシステムである。このシステムは、Ｗｅｂ、ＡＰ、ＤＢなどの複数のコンポーネントからなるＩＣＴシステムを用いたサービスを提供する稼働システムのテスト環境を、各ユーザ端末に提供する。本実施例では、Ｗｅｂ、ＡＰ、ＤＢの順で構成される３層システムを例にして説明する。

各ユーザ端末は、ＩＣＴシステムの改版を行うユーザの端末であり、例えばサーバ、ノートパソコン、移動体端末などの端末である。ユーザは、各ユーザ端末を用いて、自身が担当するコンポーネントの改版を行い、テストケースを用いて改版後の異常を検出する。

ここでテストケースとは、コンテンツ、アプリ、データベーススキーマなどが正常に動作することを確認するために、何らかの操作とそれに対する期待値を記述し、実際の操作の結果と期待値を比較して、同じであれば、テスト成功となる。テストケースには、例えば画像などのＷｅｂの静的コンテンツのように、通常のアクセスで変化しないものもあれば、アクセス数などのＤＢのデータのように、テストのアクセスであっても変化するものもある。あるいは、システムのログインのテストのために、テストユーザの情報を予めＤＢに登録するようなテストのための準備が必要なこともある。

試験制御装置１０は、複数のコンポーネントを有するシステムの改版を行うユーザに、テスト環境を提供するサーバ装置である。具体的には、試験制御装置１０は、各ユーザ端末に対して、物理サーバ、仮想マシン、コンテナなどを用いたテスト環境を提供する。ここで、テスト環境は、試験制御装置１０内に構成されてもよく、別の物理サーバ内に構成されてもよい。

このような構成において、試験制御装置１０は、複数のコンポーネントを有するシステムの改版を行うユーザごとに、改版で利用されるコンポーネントの種別と改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶する。そして、試験制御装置１０は、ユーザ端末からリクエストを受信した場合、当該ユーザ端末のユーザに対応付けられる利用構成表に基づいて、リクエストの転送先となるコンポーネントの種別を特定する。その後、試験制御装置１０は、特定された種別に対応するサーバ装置が起動中の場合、リクエストをサーバ装置に転送し、サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置にリクエストを転送する。

例えば、試験制御装置１０は、プロキシ（proxy）を起動する。ここで起動するプロキシは、コンテナであってもよい。そして、試験制御装置１０は、ユーザから送信されたリクエストをプロキシで受信する。すると、試験制御装置１０は、転送先のコンテナが存在しなければ、新規にコンテナを起動して、起動させたコンテナにリクエストを転送し、対象コンテナがすでに存在すれば、そのコンテナにリクエストを転送する。

つまり、図１に示すように、試験制御装置１０は、はじめにリクエストを送信したユーザ端末１に対して、ユーザ端末１が使用するＷｅｂサーバ、ＡＰサーバ、ＤＢサーバの各コンテナを生成する。次に、試験制御装置１０は、２番目にリクエストを送信したユーザ端末２に対して、ユーザ端末２が使用するＷｅｂサーバ、ＡＰサーバ、ＤＢサーバの各コンテナがすでに起動済みであることから、ユーザ端末１のリクエスト時に生成した各コンテナにリクエストを転送する。最後に、試験制御装置１０は、３番目にリクエストを送信したユーザ端末３に対して、ユーザ端末３が使用するＡＰサーバとＤＢサーバのコンテナがすでに起動済みであることから、ユーザ端末１のリクエスト時に生成したＡＰサーバのコンテナにリクエストを転送する。

このように、試験制御装置１０は、あるユーザ端末に対して起動させたコンテナを共用して、他のユーザ端末にも使用させることができる。この結果、試験制御装置１０は、使用するリソースを削減した利便性の高いテスト環境を提供することができる。なお、図１では、各コンテナに対してプロキシを起動させた例を説明したが、これに限定されるものではなく、１つのプロキシでリクエストを振り分けることもできる。

［機能構成］
図２は、実施例１にかかる試験制御装置１０の機能構成を示す機能ブロック図である。本実施例では、試験制御装置１０とは別の筐体等に、テスト環境を生成する例で説明する。図２に示すように、試験制御装置１０は、通信制御部１１、記憶部１２、制御部２０を有する。

通信制御部１１は、他の装置の通信を制御する処理部であり、例えばネットワークインタフェースカードである。例えば、通信制御部１１は、テストケースを実行するリクエストを各ユーザ端末から受信し、テスト結果を各ユーザ端末に送信する。

記憶部１２は、制御部２０が実行するプログラムや各種データを記憶する記憶装置であり、例えばメモリやハードディスクなどである。この記憶部１２は、利用構成表１３、コンテナ情報表１４、フロー制御表１５を記憶する。なお、ここでは、表を例にして説明するが、データ形式を限定するものではなく、テキスト形式やＤＢなどの形式を採用することもできる。

利用構成表１３は、複数のコンポーネントを有するシステムの改版を行うユーザごとに、改版で利用されるコンポーネントの種別と改版で利用されるコンポーネント間の接続関係とを対応付けて記憶する。

図３は、利用構成表１３に記憶される情報の例を示す図である。図３に示すように、利用構成表１３は、「ユーザ、接続情報、破棄不可」を対応付けて記憶する。ここで記憶される「ユーザ」は、ユーザ端末すなわちシステムの改版を行うユーザを識別する識別子である。「接続情報」は、ユーザ端末が使用するコンテナの種別と使用するコンテナの接続関係を示す情報である。「破棄不可」は、特定の条件を満たす場合に自動的にコンテナを破棄する自動破棄が無効か否かを設定する情報である。

図３の例では、「ユーザ１」は、「Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバ」のコンテナを使用し、各コンテナの接続関係が「クライアント（client）からＷｅｂサーバ」、「ＷｅｂサーバからＡＰサーバ」、「ＡＰサーバからＤＢサーバ」であることを示す。また、いずれのコンテナについても自動破棄が有効である。なお、「ユーザ２」については、利用するコンテナの種別（コンテナ種）と接続関係は、ユーザ１と同様であるが、「ＤＢサーバ」について自動破棄が無効に設定されている。

コンテナ情報表１４は、起動済みのコンテナに関する情報を記憶する。図４は、コンテナ情報表１４に記憶される情報の例を示す図である。図４に示すように、コンテナ情報表１４は、「コンテナ、コンテナ種、破棄不可」を対応付けて記憶する。

ここで記憶される「コンテナ」は、起動済みのコンテナを識別する識別子であり、「コンテナ種」は、起動済みのコンテナの種別であり、「破棄不可」は、自動破棄の設定を示す。図４の例では、「Ｗｅｂサーバ」に該当するコンテナ「Ｗｅｂ１」が自動破棄を許可した状態で起動されていることを示す。

フロー制御表１５は、テスト環境内で起動するコンテナごとに、テスト環境で発生した通信に関する情報を記憶する。図５は、フロー制御表１５に記憶される情報の例を示す図である。図５に示すように、フロー制御表１５は、「コンテナ、ユーザ、最新アクセス時刻」を対応付けて記憶する。

ここで記憶される「コンテナ」は、アクセス対象のコンテナ種を示す情報であり、「ユーザ」は、アクセスしたユーザを示す情報であり、「最新アクセス時刻」は、ユーザがコンテナにアクセスした最新の日時である。図５の例では、コンテナ「Ｗｅｂ１」に対して、「ユーザ１」から「2015/12/4 12：00：01」にアクセスがあったことを示している。

制御部２０は、試験制御装置１０全体の処理を司る処理部であり、例えばプロセッサなどである。この制御部２０は、プロキシ実行部２１、設定部２２、代理処理部２３、コンテナ起動部２４、コンテナ破棄部２５を有する。なお、プロキシ実行部２１、設定部２２、代理処理部２３、コンテナ起動部２４、コンテナ破棄部２５は、プロセッサなどの電子回路の一例やプロセッサが実行するプロセスの一例である。

プロキシ実行部２１は、リクエストの受信および処理結果の応答などを実行する処理部である。具体的には、プロキシ実行部２１は、処理が開始されると、利用構成表１３を参照して、コンテナ種を取得し、取得したコンテナ種ごとにプロキシのコンテナを起動する。このようにして、プロキシ実行部２１は、各ユーザ端末に対して、テスト環境として代理応答する。

例えば、プロキシ実行部２１は、ユーザ端末からリクエストを受信すると、代理処理部２３に出力する。また、プロキシ実行部２１は、代理処理部２３等からリクエストに対する応答を受信すると、リクエスト元のユーザ端末に応答を送信する。

また、プロキシ実行部２１は、各コンテナからリクエストを受信すると、当該リクエストを代理処理部２３に出力する。図３のユーザ１を例にして説明すると、プロキシ実行部２１は、ユーザ端末１からリクエストを受信して代理処理部２３に出力し、その後に、Ｗｅｂサーバのコンテナからリクエストを受信して代理処理部２３に出力する。また、プロキシ実行部２１は、ＡＰサーバのコンテナからリクエストを受信して代理処理部２３に出力し、その後に、ＤＢサーバのコンテナからリクエストを受信して代理処理部２３に出力する。その後、プロキシ実行部２１は、ＤＢサーバのコンテナから受信した結果をユーザ端末１に応答する。

ここで、Ｗｅｂ−ＡＰ−ＤＢなどの多層システムである本システムでは、２層目以降のユーザのアクセスの識別について、公知の様々な手法を採用することができる。例えば、各コンポーネントに、送信元アドレスなどのユーザの識別情報を、コメントやオプションヘッダなどのメッセージの論理的な意味を変更した領域に挿入して、伝達させるように実装しておくことができる。また、ユーザからのアクセスと２層目以降のアクセスとを紐付ける情報を予め特定しておき、その情報を用いて通信を紐付けることもできる。

設定部２２は、複数のコンポーネントを有するシステムの改版を行うユーザごとに、改版で利用されるコンポーネントの種別と改版で利用されるコンポーネント間の接続関係との対応付けの設定を受付ける処理部である。具体的には、設定部２２は、各ユーザ端末から、利用構成表１３の登録を受け付ける。

代理処理部２３は、ユーザ端末から送信されたリクエストを、該当するコンテナに振り分ける処理部である。具体的には、代理処理部２３は、ユーザ端末または各コンテナからリクエストを受信した場合に、利用構成表１３を参照して、次の転送先となるコンポーネントを特定する。そして、代理処理部２３は、次の転送先となるコンポーネントを特定すると、コンテナ情報表１４を参照して、該当するコンポーネントに対応するコンテナが起動中か否かを判定する。

その後、代理処理部２３は、該当コンテナが起動中である場合は、該当コンテナにリクエストを転送し、フロー制御表１５を更新する。一方。代理処理部２３は、該当コンテナが未起動である場合は、コンテナ起動部２４にコンテナの起動指示を送信する。その後、代理処理部２３は、該当コンテナが起動されると、該当コンテナにリクエストを転送し、フロー制御表１５を更新する。

例えば、代理処理部２３は、ユーザ端末１のユーザ１のＩＤやアドレス情報等が付加されたリクエストを、ユーザ端末１から受信すると、利用構成表１３を参照してリクエストの転送先がＷｅｂであることを特定する。続いて、代理処理部２３は、フロー制御表１５を参照して、ユーザ１に該当するエントリを特定する。ここで、代理処理部２３は、エントリがフロー制御表１５にあれば、コンテナ「Ｗｅｂ１」を取得して、コンテナ「Ｗｅｂ１」にリクエストを転送する。このとき、代理処理部２３は、現在時刻を取得して、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

一方、代理処理部２３は、フロー制御表１５に「ユーザ１」のエントリがない場合、コンテナ情報表１４を参照し、コンテナ種「Ｗｅｂ」のエントリがあるか否かを判定する。そして、代理処理部２３は、コンテナ種「Ｗｅｂ」のエントリがコンテナ情報表１４にある場合、コンテナ種「Ｗｅｂ」に対応付けられるコンテナ「Ｗｅｂ１」を取得する。続いて、代理処理部２３は、コンテナ「Ｗｅｂ１」に対応するエントリをフロー制御表１５から検索し、エントリがあれば「ユーザ」に「ユーザ１」を追記し、エントリがなければ、「コンテナ＝Ｗｅｂ１、ユーザ＝ユーザ１、破棄不可＝−」のエントリの新規作成をコンテナ起動部２４に要求する。その後、代理処理部２３は、Ｗｅｂコンテナ「Ｗｅｂ１」にリクエストを転送するとともに、現在時刻を取得して、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

また、代理処理部２３は、コンテナ情報表１４にもＷｅｂのエントリがない場合、コンテナ起動部２４に対して、Ｗｅｂのコンテナの生成指示を送信する。そして、代理処理部２３は、Ｗｅｂのコンテナ「Ｗｅｂ１」が起動されると、上記処理と同様の処理を実行して、Ｗｅｂコンテナ「Ｗｅｂ１」にリクエストを転送するとともに、現在時刻を取得して、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

なお、ここでは、Ｗｅｂコンテナへのリクエストについて説明したが、ＡＰやＤＢであっても同様の手法で処理することができる。

コンテナ起動部２４は、該当コンポーネントのコンテナを起動する処理部である。具体的には、コンテナ起動部２４は、代理処理部２３から指示されたコンテナを起動し、コンテナ情報表１４に、起動したコンテナに該当するエントリを生成する。

例えば、コンテナ起動部２４は、代理処理部２３からＷｅｂのコンテナの生成指示を受信すると、コンテナ情報表１４を参照して、Ｗｅｂコンテナの起動数を取得する。ここで、Ｗｅｂコンテナが未起動の場合、コンテナ起動部２４は、起動対象が１番目のＷｅｂコンテナであることから、起動対象のＷｅｂコンテナを「Ｗｅｂ１」とする。そして、コンテナ起動部２４は、テスト環境に「Ｗｅｂ１」のコンテナを起動するとともに、コンテナ情報表１４に、「コンテナ＝Ｗｅｂ１、コンテナ種＝Ｗｅｂ」のエントリを生成する。さらに、コンテナ起動部２４は、リクエスト送信元の「ユーザ１」に対応付けられるエントリを利用構成表１３から特定し、「破棄不可＝−」を取得する。そして、コンテナ起動部２４は、コンテナ情報表１４の「コンテナ＝Ｗｅｂ１、コンテナ種＝Ｗｅｂ」のエントリに、「破棄不可＝−」を追記する。その後、コンテナ起動部２４は、コンテナの起動開始を代理処理部２３に応答する。なお、各表の作成は、代理処理部２３が実行することもできる。

コンテナ破棄部２５は、所定の条件を満たすコンテナを破棄する処理部である。具体的には、コンテナ破棄部２５は、コンテナ情報表１４のエントリごとに、フロー制御表１５に該当するコンテナのエントリがあるか検索し、エントリがなければ、該当コンテナは不要と判定して削除する。削除後、コンテナ破棄部２５は、コンテナ情報表１４の該当エントリも削除する。

図６は、コンテナ削除を説明する図である。図６に示すように、コンテナ情報表１４には、「Ｗｅｂ１」のエントリと「ＡＰ１」のエントリが登録されている。この状態で、コンテナ破棄部２５は、フロー制御表１５を参照すると、フロー制御表１５には、「Ｗｅｂ１」のエントリは存在するが、「ＡＰ１」のエントリがないことを特定する。すると、コンテナ破棄部２５は、テスト環境にある「ＡＰ１」に該当する「ＡＰサーバ」のコンテナを、テスト環境から削除する。続いて、コンテナ破棄部２５は、フロー制御表１５から「ＡＰ１」のエントリを削除する。このようにして、コンテナ破棄部２５は、「ＡＰサーバ」のコンテナに使用されていたプロセッサやメモリなどのリソースを解放する。

上記削除処理は、定期的に実行することができるが、削除する契機はこれに限定されるものではない。例えば、コンテナ破棄部２５は、フロー制御表１５のエントリごとに、最新アクセス時刻が現時刻より時間Ｔ（例えば１時間）以前かを判定する。そして、コンテナ破棄部２５は、最新アクセス時刻が現時刻より時間Ｔ以前のエントリをフロー制御表１５から削除し、テスト環境からも該当コンテナを削除する。また、コンテナ破棄部２５は、ユーザがユーザインタフェースを介して明示的にシステムの利用終了を通知したら削除することもできる。

［処理の流れ］
図７は、実施例１にかかるコンテナ起動およびリクエスト転送の処理の流れを示すフローチャートである。図７に示すように、プロキシ実行部２１によってリクエストが受信されると（Ｓ１０１：Ｙｅｓ）、代理処理部２３は、リクエストからユーザを特定する（Ｓ１０２）。

続いて、代理処理部２３は、特定したユーザに対応するエントリを利用構成表１３から特定して、転送先を特定する（Ｓ１０３）。そして、代理処理部２３は、フロー制御表１５を参照して、特定したユーザに対応するエントリを検索し（Ｓ１０４）、エントリがある場合（Ｓ１０４：Ｙｅｓ）、該当コンテナにエントリを転送する（Ｓ１１０）。

一方、代理処理部２３は、フロー制御表１５に該当ユーザのエントリがない場合（Ｓ１０４：Ｎｏ）、フロー制御表１５から、特定した転送先のコンテナに対応するエントリを検索する（Ｓ１０５）。

そして、代理処理部２３は、フロー制御表１５に該当コンテナのエントリがある場合（Ｓ１０５：Ｙｅｓ）、該当コンテナのエントリにユーザ（ユーザＩＤ）を追加して（Ｓ１０６）、該当コンテナにリクエストを転送する（Ｓ１１０）。

一方、代理処理部２３が、フロー制御表１５に該当コンテナのエントリがないと判定した場合（Ｓ１０５：Ｎｏ）、コンテナ起動部２４が、該当コンテナを起動する（Ｓ１０７）。続いて、コンテナ起動部２４は、該当コンテナのエントリを追加して、コンテナ情報表１４を更新するとともに（Ｓ１０８）、該当コンテナおよびユーザのエントリを追加して、フロー制御表１５を更新する（Ｓ１０９）。なお、各表の更新は、代理処理部２３が実行することもできる。その後、代理処理部２３は、起動されたコンテナに、受信されたリクエストを転送する（Ｓ１１０）。

［改版の具体例］
図８は、実施例１にかかるコンポーネントの改版を説明する図である。図８に示す図では、ユーザ１から３が同じシステムの開発者であるが、担当するコンポーネントが異なっている例を示す。なお、図８に示すｖはバージョンであり、ｂはブランチを示す。また、各ユーザは、改版前においては共通のテストケースＡを用いてコンポーネントをテストする。

図８では、ユーザ１が、バージョン１のＡＰサーバ（ＡＰｖ１）を改版し、ユーザ２が、バージョン１のＤＢサーバ（ＤＢｖ１）を改版し、ユーザ３が、バージョン１のＷｅｂサーバ（Ｗｅｂｖ１）を改版する。

このため、ユーザ１は、コンポーネント（ＡＰｖ１）をコンポーネント（ＡＰｖ１ｂ１）に改版することから、テストケースＡをテストケースＡＰｖ１ｂ１に修正して、改版後のコンポーネント（ＡＰｖ１ｂ１）をテストする。

同様に、ユーザ２は、コンポーネント（ＤＢｖ１）をコンポーネント（ＤＢｖ１ｂ２）に改版することから、テストケースＡをテストケースＤＢｖ１ｂ２に修正して、改版後のコンポーネント（ＤＢｖ１ｂ２）をテストする。

同様に、ユーザ３は、コンポーネント（Ｗｅｂｖ１）をコンポーネント（Ｗｅｂｖ１ｂ３）に改版することから、テストケースＡをテストケースＷｅｂｖ１ｂ３に修正して、改版後のコンポーネント（Ｗｅｂｖ１ｂ３）をテストする。

このように、Ｗｅｂ上のサービスを頻繁に改版する時、ある改版時の変更は、システムのごく一部であり、大部分のシステムのコンポーネントは変更されず、テストケースの変更もごく一部である。この結果、改版されるコンポーネント以外のコンポーネントは共用することができる。

［効果］
近年のＷｅｂサービスは、コンポーネント間の関係性を小さくして影響度を小さくするために、疎結合化が行われており、１コンポーネント１コンテナにすることが多い。また、システムは多くのコンポーネントから構成されるので、多くのコンテナから構成される。従って、ある改版のときは、殆どのコンテナは改版されない。また、開発を行っているチームのメンバーは、各々違うところを担当しているが、大部分のコンポーネント（コンテナ）やテストケースは改版されないため同じである。

したがって、実施例で説明したように、コンテナを用いて、改版対象以外のコンポーネントを共用することで、リソースの削減を図ることができる。例えば、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバから構成されるシステムを３ユーザで改版する場合、従来であれば９コンテナを用いてテスト環境を生成していたが、上記実施例を適用することで、３コンテナでテスト環境を生成することができる。したがって、リソースの削減が実現できる。さらに、各ユーザが並列に改版およびテストを実行することもできるので、利便性の低下も抑制できる。すなわち、使用するリソースを削減した利便性の高いテスト環境を提供することができる。

ところで、実施例１では、各コンテナを各ユーザで共用する例を説明したが、改版内容等によっては、コンテナを専有してテストを行う事象も発生する。そこで、実施例２では、一部のコンテナを専有させたテスト環境の作成例を説明する。なお、システム構成やコンポーネント構成等は、実施例１と同一とする。

［機能構成］
図９は、実施例２にかかる試験制御装置１０の機能構成を示す機能ブロック図である。図９に示す試験制御装置１０は、実施例１の図２と同様、通信制御部１１と記憶部１２と制御部２０とを有するが、実施例１とは異なり、専有コンテナ種表１６を有している。なお、実施例２では、実施例１と異なる点について説明する。

専有コンテナ種表１６は、各ユーザが専有するコンテナの種別を記憶する。ここで記憶される情報は、ユーザにより設定することができる。図１０は、実施例２にかかる専有コンテナ種表１６に記憶される情報の例を示す図である。

図１０に示すように、専有コンテナ種表１６は、「ユーザ、専有コンテナ種」を対応付けて記憶する。「ユーザ」は、ユーザを識別する識別子等であり、「専有コンテナ種」は、ユーザが専有するコンテナの種別である。図１０の例では、ユーザ１がＡＰサーバのコンテナを専有することを示す。

また、専有コンテナを生成することから、フロー制御表１５にも実施例１と異なる情報が追記される。図１１は、実施例２にかかるフロー制御表１５に記憶される情報の例を示す図である。図１１に示すように、実施例２にかかるフロー制御表１５は、実施例１で説明した「コンテナ、ユーザ、最新アクセス時刻」に加えて、専有するか否かを示す「専有」の列が追加されている。図１１の例では、ユーザ１に専有されるＷｅｂ１のコンテナに、ユーザ１が「2015/12/04 12：00：00」にアクセスしたことを示す。

また、代理処理部２３は、実施例１では該当コンテナが起動中であればリクエストを転送し、該当コンテナが未起動であればコンテナの起動をコンテナ起動部２４に指示していたが、これらに加えて、専有コンテナか否かの判定を行う。

具体例を挙げて説明すると、代理処理部２３は、ユーザ端末１からリクエストを受信した場合に、利用構成表１３を参照して、次の転送先となるコンテナが「Ｗｅｂ」であることを特定する。続いて、代理処理部２３は、フロー制御表１５を参照して、ユーザ１に該当するエントリを特定する。ここで、代理処理部２３は、該当のエントリがフロー制御表１５にあれば、コンテナ情報の「Ｗｅｂ」を取得して、該当コンテナ「Ｗｅｂ」にリクエストを転送する。このとき、代理処理部２３は、現在時刻を取得して、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

一方、代理処理部２３は、フロー制御表１５に「ユーザ１」のエントリがない場合、コンテナ情報表１４を参照し、コンテナ種「Ｗｅｂ」のエントリがあるか否かを判定する。そして、代理処理部２３は、コンテナ種「Ｗｅｂ」のエントリがコンテナ情報表１４にある場合、コンテナ種「Ｗｅｂ」に対応付けられるコンテナ「Ｗｅｂ１」を取得する。続いて、代理処理部２３は、コンテナ「Ｗｅｂ１」に対応するエントリをフロー制御表１５から検索し、「専有＝ｎｏ」のエントリが存在する場合、「ユーザ１」を追記してエントリの転送等を実行する。

ここで、代理処理部２３は、フロー制御表１５に、「専有＝ｙｅｓ」が対応付けられるコンテナ「Ｗｅｂ１」のエントリが存在する場合、新たなコンテナである「Ｗｅｂ２」のコンテナの生成を、コンテナ起動部２４に指示する。このとき、コンテナ起動部２４は、ユーザ１に対応する専有コンテナ種表１６を参照し、専有コンテナ種が「ＡＰ」であることから、「専有＝ｎｏ」を設定した「Ｗｅｂ２」のコンテナを生成する。その後、代理処理部２３は、新たに生成された「Ｗｅｂ２」のコンテナにリクエストを転送するとともに、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

また、代理処理部２３は、フロー制御表１５に該当エントリがなければ、「コンテナ＝Ｗｅｂ１、ユーザ＝ユーザ１、破棄不可＝−」のエントリの新規作成をコンテナ起動部２４に要求する。このとき、コンテナ起動部２４は、ユーザ１に対応する専有コンテナ種表１６を参照し、専有コンテナ種が「ＡＰ」であることから、「専有＝ｎｏ」を設定した「Ｗｅｂ２」のコンテナを生成するとともに、要求されたエントリを作成する。その後、代理処理部２３は、Ｗｅｂコンテナ「Ｗｅｂ１」にリクエストを転送するとともに、フロー制御表１５の該当エントリの最新アクセス時刻を更新する。

［処理の流れ］
図１２は、実施例２にかかるコンテナ起動およびリクエスト転送の処理の流れを示すフローチャートである。図１２に示すように、プロキシ実行部２１によってリクエストが受信されると（Ｓ２０１：Ｙｅｓ）、代理処理部２３は、リクエストからユーザを特定する（Ｓ２０２）。

続いて、代理処理部２３は、特定したユーザに対応するエントリを利用構成表１３から特定して、転送先を特定する（Ｓ２０３）。そして、代理処理部２３は、フロー制御表１５を参照して、特定したユーザに対応するエントリを検索し（Ｓ２０４）、エントリがある場合（Ｓ２０４：Ｙｅｓ）、該当コンテナにリクエストを転送する（Ｓ２１２）。

一方、代理処理部２３は、フロー制御表１５に該当ユーザのエントリがない場合（Ｓ２０４：Ｎｏ）、フロー制御表１５から、特定した転送先のコンテナに対応するエントリを検索する（Ｓ２０５）。

そして、代理処理部２３は、フロー制御表１５に該当コンテナのエントリがあり（Ｓ２０５：Ｙｅｓ）、該当コンテナのエントリが該当ユーザの専有コンテナ種ではなく他ユーザのコンテナではなく（Ｓ２０６：Ｙｅｓ）、該当コンテナが他ユーザの専有コンテナ種ではない場合（Ｓ２０７：Ｙｅｓ）、該当エントリに「専有＝ｎｏ、ユーザ＝ユーザ１」を追加する（Ｓ２０８）。その後、代理処理部２３は、該当コンテナにリクエストを転送する（Ｓ２１２）。

一方、フロー制御表１５に該当コンテナのエントリがない場合（Ｓ２０５：Ｎｏ）、または、該当コンテナのエントリが該当ユーザの専有コンテナ種もしくは他ユーザのコンテナである場合（Ｓ２０６：Ｎｏ）、または、他ユーザの専有コンテナ種である場合（Ｓ２０７：Ｎｏ）、Ｓ２０９以降が実行される。

すなわち、コンテナ起動部２４が、該当コンテナを起動する（Ｓ２０９）。続いて、コンテナ起動部２４は、該当コンテナのエントリを追加して、コンテナ情報表１４を更新するとともに（Ｓ２１０）、該当コンテナおよびユーザのエントリを追加して、フロー制御表１５を更新する（Ｓ２１１）。なお、各表の更新は、代理処理部２３が実行することもできる。その後、代理処理部２３は、起動されたコンテナに、受信されたリクエストを転送する（Ｓ２１２）。

［具体例］
次に、ユーザ１から３のそれぞれがＷｅｂ、ＡＰ、ＤＢのコンポーネントを使用する例で説明する。ここでは、ユーザ１から順にリクエストが発行され、ユーザ１がＡＰを専有し、ユーザ２がＤＢを専有し、ユーザ３がＷｅｂを専有する例で説明する。図１３は、実施例２にかかる専有コンテナを用いたテスト環境を説明する図である。

まず、試験制御装置１０は、ユーザ１からリクエストを受信すると、利用構成表１３にしたがって、「専有＝ｎｏ」のコンテナ「Ｗｅｂ１」を生成してリクエストを転送する。続いて、試験制御装置１０は、コンテナ「Ｗｅｂ１」からのリクエストの転送先として、「専有＝ｙｅｓ」のコンテナ「ＡＰ１」を生成して、リクエストを転送する。その後、試験制御装置１０は、専有コンテナ「ＡＰ１」からのリクエストの転送先として、「専有＝ｎｏ」のコンテナ「ＤＢ１」を生成して、リクエストを転送する。

この時点では、フロー制御表１５には、「コンテナ＝Ｗｅｂ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｎｏ」が記憶され、「コンテナ＝ＡＰ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｙｅｓ」が記憶され、「コンテナ＝ＤＢ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｎｏ」が記憶される。なお、最新アクセス時刻に関しては省略する。

次に、試験制御装置１０は、ユーザ２からリクエストを受信すると、転送先である「Ｗｅｂ」として「専有＝ｎｏ」のコンテナ「Ｗｅｂ１」が起動済みであることから、このコンテナ「Ｗｅｂ１」にリクエストを転送する。続いて、試験制御装置１０は、コンテナ「Ｗｅｂ１」からのリクエストを受信すると、転送先である「ＡＰ」としてコンテナ「ＡＰ１」が起動済みであるが、コンテナ「ＡＰ１」が専有状態であることから、「専有＝ｎｏ」のコンテナ「ＡＰ２」を新たに生成して、このコンテナ「ＡＰ２」にリクエストを転送する。その後、試験制御装置１０は、コンテナ「ＡＰ２」からリクエストを受信すると、転送先として「専有＝ｎｏ」のコンテナ「ＤＢ１」が起動済みではあるが、ＤＢがユーザ２の専有コンテナ種に設定されていることを検出する。すると、試験制御装置１０は、「専有＝ｙｅｓ」を設定した新たなＤＢサーバのコンテナ「ＤＢ２」を生成し、このコンテナ「ＤＢ２」にリクエストを転送する。

この時点では、フロー制御表１５には、「コンテナ＝Ｗｅｂ１」に対応付けて「ユーザ＝ユーザ１，ユーザ２、専有＝ｎｏ」が記憶される。また、フロー制御表１５には、「コンテナ＝ＡＰ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｙｅｓ」が記憶され、「コンテナ＝ＡＰ２」に対応付けて「ユーザ＝ユーザ２、専有＝ｎｏ」が記憶される。また、フロー制御表１５には、「コンテナ＝ＤＢ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｎｏ」が記憶され、「コンテナ＝ＤＢ２」に対応付けて「ユーザ＝ユーザ２、専有＝ｙｅｓ」が記憶される。

次に、試験制御装置１０は、ユーザ３からリクエストを受信すると、転送先である「Ｗｅｂ」としてコンテナ「Ｗｅｂ１」が起動済みであるが、Ｗｅｂがユーザ３の専有コンテナ種に設定されていることを検出する。すると、試験制御装置１０は、「専有＝ｙｅｓ」を設定した新たなＷｅｂサーバのコンテナ「Ｗｅｂ２」を生成し、このコンテナ「Ｗｅｂ２」にリクエストを転送する。続いて、試験制御装置１０は、コンテナ「Ｗｅｂ２」からリクエストを受信すると、転送先である「ＡＰ」として「専有＝ｎｏ」のコンテナ「ＡＰ２」が起動済みであることから、このコンテナ「ＡＰ２」にリクエストを転送する。その後、試験制御装置１０は、コンテナ「ＡＰ２」からリクエストを受信すると、転送先として「専有＝ｎｏ」のコンテナ「ＤＢ１」が起動済みであることから、このコンテナ「ＤＢ１」にリクエストを転送する。

この時点では、フロー制御表１５には、「コンテナ＝Ｗｅｂ１」に対応付けて「ユーザ＝ユーザ１，ユーザ２、専有＝ｎｏ」が記憶され、「コンテナ＝Ｗｅｂ２」に対応付けて「ユーザ＝ユーザ３、専有＝ｙｅｓ」が記憶される。また、フロー制御表１５には、「コンテナ＝ＡＰ１」に対応付けて「ユーザ＝ユーザ１、専有＝ｙｅｓ」が記憶され、「コンテナ＝ＡＰ２」に対応付けて「ユーザ＝ユーザ２，ユーザ３、専有＝ｎｏ」が記憶される。また、フロー制御表１５には、「コンテナ＝ＤＢ１」に対応付けて「ユーザ＝ユーザ１，ユーザ３、専有＝ｎｏ」が記憶され、「コンテナ＝ＤＢ２」に対応付けて「ユーザ＝ユーザ２、専有＝ｙｅｓ」が記憶される。

［効果］
このように、試験制御装置１０は、専有のコンテナと共用のコンテナを混在させたシステム環境を生成して、各ユーザに適したテスト環境を提供することができるので、リソースの削減を図りつつ、ユーザの利便性を向上させることができる。

ところで、実施例１−２では専有したいコンテナ種が予め判っていることを前提としたが、場合によっては、どのシーンで専有すべきか特定が難しいこともある。例えば、テストセット実行時に、あるテストケースはＷｅｂ層のみ専有が必要で、あるテストケースはＤＢ層のみ専有が必要とするケースがありうる。このような場合、専有指定を事前にユーザが漏れ無く行うことは難しい。

そこで、実施例３では、テストケース実行時において、専有情報を動的に判断する例を説明する。これは、あるテストケースの実行結果と、実行中の経路情報から、テストケース実行のためにあるコンテナ種類は専有すべきかどうかを推測する。

テストケースとは、上述したように、コンテンツ、アプリ、データベーススキーマなどが正常に動作することを確認するために、何らかの操作とそれに対する期待値を記述し、実際の操作の結果と期待値を比較するものである。ここでは、各々のテストケースは、前処理（テストに必要な準備）・テスト操作・後処理（系を元の状態に戻す）を行うものとする。そのため、同時に実行しないかぎりは、いずれのテストをどんな順序で実行しても問題は起きない。なお、テストセットはテストケースの集合である。また、テストケースごとに、一意なＩＤを振る。ここではＴ１、Ｔ２、・・・、Ｔｎとする。なお、同じ名前のテストケースであっても、変更があるごとに新たなＩＤを振る。

［利用コンテナの推定］
まず、試験制御装置１０は、ユーザによるテストケース実行時に、実行状況を取得する。具体的には、試験制御装置１０は、すべてのテストケースについて、実施例２の専有コンテナ種表１６にすべてのコンテナを専有として登録する。試験制御装置１０は、テストケースＴ１、Ｔ２、Ｔ３、・・・、Ｔｎを実行する。

ここで、試験制御装置１０は、テストケースが１つでも失敗した場合は、テストケースや対象コードなどの修正が必要なため、ユーザインタフェースを通じユーザに通知して、処理を終了する。また、試験制御装置１０は、すべてのテストケースが成功した場合は、テストケース毎の経路をプロキシ実行部２１のログから取得する。なお、プロキシ実行部２１は、時刻、ユーザ、コンテナ種、テストケースを利用ログに記録する。

図１４は、実施例３にかかる利用コンテナの推定を説明する図である。図１４に示すように、試験制御装置１０は、テストケースを実行すると、「時刻、ユーザ、コンテナ種、テストケース」を有する利用ログを取得する。さらに、試験制御装置１０は、テストケースを実行するたびに、「ユーザ、テストケース、状態（開始ｏｒ終了）、時刻」を有する実行ログをプロキシ実行部２１から取得する。

そして、試験制御装置１０は、利用ログと実行ログとを照らし合わせて、あるテストケース実行時に利用した利用コンテナ種（テストケース−利用コンテナ種表）を取得する。すなわち、試験制御装置１０は、実行ログのあるユーザのあるテストケースの開始から終了時刻の範囲にある利用ログで、合致するユーザのテストケースのコンテナ種を取得する。例えば、実行ログのユーザ１かつテストケースＴ１について、利用ログで合致するコンテナ種はＷｅｂである。別の例では、実行ログのユーザ１かつテストケースＴ２について、利用ログで合致するコンテナ種はＷｅｂ、ＡＰ、ＤＢである。

このようにして、試験制御装置１０は、テストケースごとに、利用していたコンテナ種は「１」、利用していないコンテナ種は「０」などとして、テストケース−利用コンテナ種表のエントリを生成する。なお、これらのテストケースは、ここでの説明内では以後変更されないとする。変更された場合は、前述のとおり、新しいＩＤのテストケースとして扱う。

［専有コンテナの推定］
次に、上記テストケース−利用コンテナ種表を用いて、専有コンテナを推定する例を説明する。ここでは、コンテナを共用にして、失敗の度に専有を変更して試行を繰り返すことで、テストケースごとに専有コンテナを推定する。

具体的には、試験制御装置１０は、すべてのコンテナを共用としてテストケースを実行する。ここではユーザによる２回目のテストケース実行を待つが、能動的に、試験制御装置１０がユーザに代わって実行してもよい。これにより、同じユーザまたは異なるユーザによる他のテストケースの同時実行時に、コンテナが共有される状況が生まれる。テストケース実行を繰り返すうちに、あるテストケースが失敗したら、元々は成功する筈なので、その失敗は共用したことが原因であると判断できる。

共用による失敗を素早く発見するために、あるユーザのテストセット実行時に、テストケース−利用コンテナ種表で同じコンテナ種を使うテストを、積極的に同時に実行してもよい。そして、試験制御装置１０は、これらテストで失敗したときに、テストケースごとに成功や失敗を表す成否表（テストケース成否表）を作成する。

図１５は、実施例３にかかる専有コンテナの推定を説明する図である。図１５に示すように、試験制御装置１０は、テストケース成否表で「false」であるテストケースごとに、テストケース−利用コンテナ種表で利用するコンテナ種を取得し、１つの組み合わせを選択して専有とする。例えば、Ｔ１は、利用コンテナ種がＷｅｂしかないので、Ｗｅｂを専有コンテナに選択する。Ｔ２の場合、利用コンテナ種がＷｅｂ、ＡＰ、ＤＢのすべてなので、２×３−１＝７通り存在する。Ｔ３の場合、利用コンテナ種がＷｅｂ、ＡＰを利用するので、２×２−１＝３通りとなる。ここで、試験制御装置１０は、すでに選んだ組み合わせを再選択しないように、組み合わせの選択順序が一定な選択ロジックにするか、すでに選んだ組み合わせを記憶しておき、それらにない組み合わせを選択するなどすればよい。

この例では、試験制御装置１０は、いずれのテストケースについてもＷｅｂを選択し、テストケース−専有コンテナ種表のＷｅｂ列に「１」を記入する。そして、試験制御装置１０は、ユーザによるテスト実行時に、テストケース実行ごとに、テストケース−専有コンテナ種表に専有コンテナ情報を記入または削除する。

図１５の例では、試験制御装置１０は、テストケース−利用コンテナ種表とテストケース成否表を比べると、テストケースＴ１のように、Ｗｅｂしか使っていないのに失敗しているのは、Ｗｅｂが共有できないことが原因と特定する。一方で、試験制御装置１０は、テストケースＴ２やＴ３のように、失敗時に複数のコンテナ種が「１」になるものは、これだけでは原因を特定できない。そこで、試験制御装置１０は、失敗したテストケースについて、テストケースが失敗しなくなるまで、すべての専有の組み合わせを試行する。

図１６は、実施例３にかかる専有コンテナの推定を説明する図であり、図１５の推定の続きである。図１６の上図に示すように、試験制御装置１０は、テストケースＴ１については、Ｗｅｂを共有できないことが特定できたので、テストケース−専用コンテナ種表のテストケース「Ｔ１」の「Ｗｅｂ＝１（専有）」を確定する。一方で、試験制御装置１０は、テストケースＴ２とＴ３については、ＡＰを「１（専有）」にした状態で、再度テストを実行する。

このようにして、試験制御装置１０は、失敗したテストケースについて専有を変更してテストを繰り返す。この結果、図１６の下図に示すように、テストケースＴ２はＡＰの専有で成功し、テストケースＴ３はＡＰとＤＢの専有でテストケースが失敗しなくなったとすると、その状態でのテストケース−専有コンテナ種表にしたがって、各テストケースの専有コンテナ種を特定することができる。

［確認処理の流れ］
図１７は、実施例３にかかるテストケースの確認処理の流れを示すフローチャートである。つまり、図１７では、テストケース自体に問題がないかを確認する処理を説明する。

図１７に示すように、試験制御装置１０は、処理を開始すると、テストケースを選択し（Ｓ３０１）、成否表に登録されているか否かを判定する（Ｓ３０２）。続いて、試験制御装置１０は、成否表に登録されていない場合（Ｓ３０２：Ｎｏ）、すべてのコンテナを専有に設定して（Ｓ３０３）、テストを実行する（Ｓ３０４）。

テストが終了すると、試験制御装置１０は、専有設定を解除し（Ｓ３０５）、フロー情報を削除する（Ｓ３０６）。そして、試験制御装置１０は、テストが失敗した場合（Ｓ３０７：Ｎｏ）、ユーザに通知する（Ｓ３０８）。

一方、試験制御装置１０は、テストが成功した場合（Ｓ３０７：Ｙｅｓ）、未処理のテストケースが有るか否かを判定する（Ｓ３０９）。そして、試験制御装置１０は、未処理のテストケースが有る場合（Ｓ３０９：Ｙｅｓ）、Ｓ３０１以降を繰り返す。なお、Ｓ３０２において、選択されたテストケースが成否表に登録されている場合（Ｓ３０２：Ｙｅｓ）、Ｓ３０９を実行する。

そして、試験制御装置１０は、未処理のテストケースがない場合（Ｓ３０９：Ｎｏ）、テストケースを１つ選択し（Ｓ３１０）、利用ログや実行ログに基づいて、利用コンテナ種を特定する（Ｓ３１１）。続いて、試験制御装置１０は、未処理のテストケースが有る場合（Ｓ３１２：Ｙｅｓ）、Ｓ３１０以降を繰り返し、未処理のテストケースがなくなると（Ｓ３１２：Ｎｏ）、処理を終了する。

［推定処理の流れ］
図１８は、実施例３にかかる専有コンテナの推定処理の流れを示すフローチャートである。図１８に示すように、試験制御装置１０は、テストケースを１つ選択し（Ｓ４０１）、利用するコンテナに専有を設定し（Ｓ４０２）、テストを実行する（Ｓ４０３）。

続いて、試験制御装置１０は、実行されたテストが終了すると、専有設定を解除し（Ｓ４０４）、フロー情報を削除し（Ｓ４０５）、テストの成否を記録する（Ｓ４０６）。ここで、未処理のテストケースがある場合（Ｓ４０７：Ｙｅｓ）、Ｓ４０１以降が繰り返される。

一方、未処理のテストケースがない場合（Ｓ４０７：Ｎｏ）、試験制御装置１０は、失敗したテストケースを選択し（Ｓ４０８）、当該テストケースが利用する利用コンテナを特定する（Ｓ４０９）。続いて、試験制御装置１０は、専有コンテナ種の組み合わせを選択する（Ｓ４１０）。その後、試験制御装置１０は、未処理のテストケースがある場合（Ｓ４１１：Ｙｅｓ）、Ｓ４０８以降を繰り返し、未処理のテストケースがない場合（Ｓ４１１：Ｎｏ）、処理を終了する。

［効果］
上述したように、試験制御装置１０は、テストケースごとに、テストケース−専有コンテナ種表を自動で作成するので、利用者はテストケース毎の専有設定を行うこと無く、適切な専有設定で動作させることが可能となる。また、これによって共有コンテナが増えるので、リソースの削減率が増える。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［コンテナ］
上記実施例では、コンテナを用いてテスト環境を生成する例を説明したが、これに限定されるものではなく、物理サーバや仮想マシン（ＶＭ）などを採用することもできる。

［専有情報］
上記実施例では、専有するコンテナを予め設定したり、テストケースから推定したりする例を説明したが、これに限定されるものではない。例えば、専有情報を、ユーザがリクエストに埋め込んだり、プロキシに設定しても良い。例を挙げると、ユーザ１はＤＢを専有し、ユーザ２はＷｅｂとＡＰを専有することを、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダに埋め込んだり、プロキシに直接送信元アドレスなどで埋め込み、その情報に従い、プロキシで送信先を制御することもできる。

また、試験制御装置１０は、その設定を、以下のようにして自動的に判別してもよい。例えば、試験制御装置１０は、あるコンテナＣに接続中のユーザ１がいる状態で、別ユーザ２やユーザ３からの新規リクエストがエラーまたはタイムアウトしたときに、コンテナＣはユーザ１に専有されていると推測する。このような現象は、コンテナＣがシングルスレッド実行で、ユーザ１によりリモートデバッグでステップ実行されているときなどに起こりうる。そして、試験制御装置１０は、ユーザ１の接続終了で、専有状態を解除する。

［システム］
また、図２や図９に示した各装置の各構成は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の単位で分散または統合して構成することができる。例えば、プロキシ実行部２１と代理処理部２３を統合することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）および当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［ハードウェア］
上記試験制御装置１０は、例えば、次のようなハードウェア構成を有するコンピュータにより実現することができる。図１９は、ハードウェア構成例を説明する図である。図１９に示すように、試験制御装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。

通信インタフェース１０ａの一例としては、ネットワークインタフェースカードなどである。ＨＤＤ１０ｂは、図３等に示した各種表を記憶する記憶装置である。

メモリ１０ｃの一例としては、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。プロセッサ１０ｄの一例としては、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）等が挙げられる。

また、試験制御装置１０は、プログラムを読み出して実行することで試験実行方法を実行する情報処理装置として動作する。つまり、試験制御装置１０は、プロキシ実行部２１、設定部２２、代理処理部２３、コンテナ起動部２４、コンテナ破棄部２５と同様の機能を実行するプログラムを実行する。この結果、試験制御装置１０は、プロキシ実行部２１、設定部２２、代理処理部２３、コンテナ起動部２４、コンテナ破棄部２５と同様の機能を実行するプロセスを実行することができる。なお、この他の実施例でいうプログラムは、試験制御装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ（Magneto−Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

１０ 試験制御装置
１１ 通信制御部
１２ 記憶部
１３ 利用構成表
１４ コンテナ情報表
１５ フロー制御表
１６ 専有コンテナ種表
２０ 制御部
２１ プロキシ実行部
２２ 設定部
２３ 代理処理部
２４ コンテナ起動部
２５ コンテナ破棄部

Claims (7)

1. 複数のコンポーネントを有するシステムの改版を行うユーザごとに、前記改版で利用されるコンポーネントの種別と前記改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶する記憶部と、
   端末装置からリクエストを受信した場合、当該端末装置のユーザに対応付けられる前記利用構成表に基づいて、前記リクエストの転送先となるコンポーネントの種別を特定する特定部と、
   特定された種別に対応するサーバ装置が起動中の場合、前記リクエストを前記サーバ装置に転送し、前記サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置に前記リクエストを転送する転送制御部と
   を有することを特徴とする情報処理装置。
2. 前記転送制御部は、予め指定されたテスト環境上で、特定された種別に対応するコンテナがいずれかのユーザに対して起動されている場合、前記リクエストを前記コンテナに転送し、前記コンテナがいずれのユーザに対しても起動されていない場合、該当するコンテナを前記テスト環境上に起動して、起動させたコンテナに前記リクエストを転送することを特徴とする請求項１に記載の情報処理装置。
3. 前記テスト環境上で一定時間リクエストが転送されなかったコンテナ、または、前記ユーザによって利用の終了が通知されたコンテナを、前記テスト環境が削除して、当該コンテナに使用されていたリソースを解放する削除部をさらに有することを特徴とする請求項２に記載の情報処理装置。
4. 前記ユーザごとに、専有するコンポーネントの種別を記憶する専有記憶部と、
   前記専有記憶部に記憶される情報に基づいて、前記リクエストの転送先となるコンポーネントの種別が専有対象か否かを判定する判定部とをさらに有し、
   前記転送制御部は、予め指定されたテスト環境上で、前記サーバ装置が起動中かつ前記サーバ装置がいずれのユーザにも専有されていない場合、前記リクエストを前記サーバ装置に転送し、前記サーバ装置が未起動かつ前記専有対象である場合、該当するサーバ装置を前記テスト環境上で起動して、起動させたサーバ装置に前記リクエストを転送するとともに他のユーザから前記サーバ装置へのリクエストの転送を抑制し、前記サーバ装置が未起動かつ前記専有対象ではない場合、該当するサーバ装置を前記テスト環境上で起動して、起動させたサーバ装置に前記リクエストを転送することを特徴とする請求項１に記載の情報処理装置。
5. 前記ユーザごとの各テストケースを実行して、各テストケースで利用するコンポーネントを特定して、各テストケースの利用コンポーネントの一覧を生成する生成部と、
   前記各テストケースから複数のテストケースを選択し、前記複数のテストケースそれぞれが利用するコンポーネントを専有させた状態で、前記複数のテストケースを実行して実行結果を生成する生成部と、
   前記複数のテストケースをそれぞれに対応する前記利用コンポーネントの一覧と、前記実行結果とを比較して、前記複数のテストケースをそれぞれについて、専有するコンポーネントを特定して、前記専有記憶部に格納する特定部とをさらに有することを特徴とする請求項４に記載の情報処理装置。
6. コンピュータが、
   複数のコンポーネントを有するシステムの改版を行うユーザごとに、前記改版で利用されるコンポーネントの種別と前記改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶部に記憶し、
   端末装置からリクエストを受信した場合、当該端末装置のユーザに対応付けられる前記利用構成表に基づいて、前記リクエストの転送先となるコンポーネントの種別を特定し、
   特定された種別に対応するサーバ装置が起動中の場合、前記リクエストを前記サーバ装置に転送し、前記サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置に前記リクエストを転送する
   処理を実行することを特徴とする試験実行方法。
7. コンピュータに、
   複数のコンポーネントを有するシステムの改版を行うユーザごとに、前記改版で利用されるコンポーネントの種別と前記改版で利用されるコンポーネント間の接続関係とを対応付けた利用構成表を記憶部に記憶し、
   端末装置からリクエストを受信した場合、当該端末装置のユーザに対応付けられる前記利用構成表に基づいて、前記リクエストの転送先となるコンポーネントの種別を特定し、
   特定された種別に対応するサーバ装置が起動中の場合、前記リクエストを前記サーバ装置に転送し、前記サーバ装置が未起動の場合、該当するサーバ装置を起動して、起動させたサーバ装置に前記リクエストを転送する
   処理を実行させることを特徴とする試験実行プログラム。

Images