JP2021174066A - テスト管理システム、テスト管理装置およびテスト管理方法 - Google Patents

Abstract

【課題】複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間を短縮可能とする。【解決手段】テスト管理システム１０において、Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部１２０と、前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成するグループ算出部１０２と、前記テストグループに関して多変量テストを実行するテスト実行部１０１を備えたテスト管理装置１００を含む構成とする。【選択図】図２

Description

本発明は、テスト管理システム、テスト管理装置およびテスト管理方法に関するものである。

各種システムやウェブサイト、或いは広告等の施策に関して、その良否を評価するためにＡ／Ｂテストが行われている。
Ａ／Ｂテストでは、施策対象のウェブサイトやシステムを複数パターン用意し、それを一定の割合ずつユーザに公開してその反応を観測する。そして、その観測結果（例：クリック率、応答速度等）を集計、評価することで、目標となる評価項目に対し、上記複数パターンのうちどのパターンが優れているかを評価する。

一方で、近年はマイクロサービスアーキテクチャのように、一つのシステムを複数のマイクロサービスの組として開発することが行われる。こうした構築体制では、マイクロサービスごとに開発チームが存在し、各チームが自律的に開発を行う。当該体制で業務を進めることにより、迅速な開発が実現される。

ここで、複数チームが自律的に開発を行うシステム開発においては、複数チームが同時にＡ／Ｂテストを行うケースがある。

これら同時実行される複数のＡ／Ｂテストのパターンが、互いに影響を及ぼす場合、そのテストの結果は不正確な可能性がある。

例えば、ユーザに商品を推薦する機能を持ったウェブサイトに関して、あるチームが商品推薦アルゴリズムの違いによる商品購入数についてＡ／Ｂテストを実行したとする。一方、同時期に別のチームが、当該ウェブサイトのデザインの違いによる商品購入数について、Ａ／Ｂテストを実行したとする。すると、当該ウェブサイトでの商品購入数が向上したとしても、それがどちらのチームの施策による効果か判然としない。

他方、一度に実行するＡ／Ｂテストを１つだけに絞るとすれば、上述の各チームの各施策に関する全てのＡ／Ｂテストの完了までに、膨大な時間が必要となる。その結果、当該ウェブサイトに関する迅速な開発を阻害する。

そこで、上述のような問題を解決するために、例えば以下の技術を活用できる。非特許文献１においては、それぞれ異なるユーザハッシュを用いることで、対象ユーザを選定することにより、複数のＡ／Ｂテストを互いの影響なく実施する技術が開示されている。

また、特許文献１においては、多変量テスト（Ｍｕｌｔｉｖａｒｉａｔｅ ｔｅｓｔｉｎｇ）の概念を用いることで、テスト間の影響を除外して評価を実行する技術が開示されている。

Ｄｉａｎｅ Ｔａｎｇ， Ａｓｈｉｓｈ Ａｇａｒｗａｌ， Ｄｅｉｒｄｒｅ Ｏ’Ｂｒｉｅｎ， Ｍｉｋｅ Ｍｅｙｅｒ， "Ｏｖｅｒｌａｐｐｉｎｇ Ｅｘｐｅｒｉｍｅｎｔ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ： Ｍｏｒｅ， Ｂｅｔｔｅｒ， Ｆａｓｔｅｒ Ｅｘｐｅｒｉｍｅｎｔａｔｉｏｎ"， ＫＤＤ’１０， ｐ．１７−２６ （２０１０）

ＵＳ２０１４０２８０８６２Ａ１

しかしながら、非特許文献１で開示された手法では、複数のＡ／Ｂテスト間に存在する交互作用を評価できない。
一方、交互作用の考慮が可能な特許文献１の手法を採用しても、適宜な精度の結果を得るために、相応のサンプル数が必要となる課題は残る。すなわち、多変量テストを実施する場合、組み合わせる要素の数に比例して、評価に必要なサンプル数が増加するためである。このため、エンタープライズ向けサービスなど、想定されるユーザが少ないサービスの場合、評価に必要な数のサンプルを集めるまでに長時間を要する可能性がある。

また他方、同時に実行されるＡ／Ｂテストの数が増えると、評価結果の算出までに時間がかかってしまう問題もある。

そこで本発明の目的は、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間を短縮可能とする技術を提供することにある。

上記課題を解決する本発明のテスト管理システムは、Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部と、前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成するグループ算出部と、前記テストグループに関して多変量テストを実行するテスト実行部と、を備えたテスト管理装置を含むことを特徴とする。
また、本発明のテスト管理装置は、Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部と、前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成するグループ算出部と、前記テストグループに関して多変量テストを実行するテスト実行部と、を備えることを特徴とする。

また、本発明のテスト管理方法は、テスト管理装置が、Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部を備えて、前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成し、前記テストグループに関して多変量テストを実行することを特徴とする。

本発明によれば、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間を短縮可能となる。

本実施形態における処理の概要の一例を示した図である。 本実施形態におけるシステム構成の一例を示した図である。 本実施形態における操作画面の一例を示した図である。 本実施形態におけるハードウェア構成の一例を示した図である。 本実施形態における依存関係情報の一例を示した図である。 本実施形態におけるテスト概要情報の一例を示した図である。 本実施形態におけるテスト対象情報の一例を示した図である。 本実施形態における目標情報の一例を示した図である。 本実施形態におけるメトリクス情報の一例を示した図である。 本実施形態における全体の処理の一例を示した図である。 本実施形態におけるテストグループ作成処理の一例を示した図である。 本実施形態におけるテストの実行処理の一例を示した図である。 本実施形態におけるシステム構成の一例を示した図である。 本実施形態におけるソフトウェア構成管理情報の一例を示した図である。 本実施形態におけるテスト履歴情報の一例を示した図である。

以下図面について、本発明の一実施の形態を詳述する。ただし、本発明は後述する実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例および同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。
なお、本実施例では各情報を「テーブル」または「ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）フォーマットのテキストデータ」形式にて説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造や、Ｙａｍｌ、ＸＭＬ等フォーマットのテキストデータや、またそれ以外で表現されていても良い。

そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。また、各情報の内容を説明する際に、「識別情報」、「識別子」、「ＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

また、本実施例において、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）上のボタンの押下を起点に実行される処理は、対応するＡＰＩの呼び出しを起点に実行されても良い。

また、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、前述した各構成、機能、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

また、以後の説明では「○○部」などのプログラムを主語とした説明を行う場合があるが、プログラムはプロセッサ２０１によって実行されることで定められた処理を主記憶デバイス２０４および通信制御デバイス２０２を用いながら行うため、プロセッサ２０１を
主語とした説明としてもよい。また、プログラムを主語として開示された処理はプログラミング装置が行う処理としてもよい。

また、異なる電子計算機間にてデータを取得する、あるいはプログラムの機能を呼び出しする際、実際にはＷｅｂＡＰＩ等の通信プロトコルを用いたリモートプロシージャコールを行っている場合がある。
＜テスト管理方法の基本概念＞
まず、図１を用いてテスト管理方法の概要を説明する。図１は、複数のサービス１５４０で構成されるシステムにおいて、サービスＢ、Ｃ、Ｄを含む複数のサービスが同時にＡ／Ｂテストを実行する場合、サービスＢのＡ／Ｂテストのテストケースを算出する手順を表している。ここで、テストケースとは個別にサンプルを集計する必要があるパターンの組である。

パターンとは、クリック率や反応速度といった適宜な目標値の向上を意図して行われた、サービスごとのシステム等の改変のパターンを想定しうる。

本実施形態のテスト管理方法においては、まず、テスト対象となるシステム１５１１でＡ／Ｂテストを実施するサービス１５４０（サービスＢ、Ｃ、Ｄ）を列挙し、それらサービスが含むパターン（図中のｖ１、ｖ２）の全組み合わせからなるテストケース１５１２を作成する。ここで作成したテストケース１５１２は、多変量テストのテストケースを網羅的に作成したマトリクスとなる。

次に、上述のシステムの依存関係、Ａ／Ｂテストの目標、影響度、などの情報を基に、テストグループ１５４１を作成する。

このテストグループ１５４１に含まれるサービスが関係するテストケースの列は、テストケース１５２２の点線のようになる。

なお注意点として、当該テストグループ１５４１は、サービスごとに異なる。図の例では、サービスＢのテストグループ１５４１には、サービスＡ、Ｂ、Ｃが含まれるが、サービスＣのテストグループは、サービスＢのテストグループ１５４１とは異なる可能性がある（例えばサービスＣのテストグループは、サービスＣ単体となる場合がある）。これはテストグループの作成にテストの目標や影響度などの情報が関わっているためである。

最後に、上述のテストグループ１５４１に対応するようにテストケース１５２２を集約してテストケース１５３２を得て、後述の多変量テストを実行する。

なお注意点として、本発明の手法ではテストケース１５３２のように、テストグループごとにテストケースを集約するが、これは評価のタイミングで集約しているのであって、テスト自体は全てのテストケースでメトリクスを計測する。

このため、テストグループ外のサービスのＡ／Ｂテストの影響を受けると思われるが、この影響は個々のサービスへのユーザの振り方をランダムに行い、Ａ／Ｂテスト間の相関係数をほぼ０とすることで回避する。

なお、多変量テストとは、例えば、ウェブサイトのタイトル文字とトップ画像のように複数の要素が同時に変更されたとき、最適な組み合わせを評価する手法である。

こうした多変量テストをする際は、変更された個々の要素の組み合わせをそれぞれテストケースとしてＡ／Ｂテストのように比較する。

例えば、上記のウェブサイトのタイトル文字が３パターン、トップ画像が２パターンあるときに多変量テストを行う場合、３と２の組み合わせである６パターンのテストケースを作成する。

その後、それぞれのパターンを特定の割合ずつユーザに公開し、目標に設定したメトリクス（例えばクリック率やエラー率）の値をテストケースごとに計測する。

その後、各テストケースをベースライン（変更前と同じパターンの組み合わせなど、基準となるテストケース）と比較し、目標のメトリクスがより良い値かどうか評価する。

多変量テストでは、複数のテストケースを組み合わせた場合の交互効果も評価できる。多変量テストは、例えば重回帰分析やロジスティック回帰、ベイジアンフィルタなどを用いて実現することができる。
＜＜実施例１＞＞
続いて、図２を用いてテスト管理システム１０の構成の一例を説明する。本実施例１のテスト管理システム１０は、テスト対象１、メトリクス収集システム３、及びテスト管理装置１００から構成されている。また、これらテスト管理システム１０の各構成要素は、ネットワーク５で通信可能に接続されている。

上述の各構成要素は、それぞれがＣＰＵ、メモリ、ハードディスクなどからなる計算機で実装された装置である（図４にて詳述）。その動作形態は、それぞれ物理的に異なる計算機上で動作していてもよいし、仮想サーバと呼ばれる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク（プロセスやコンテナとも呼ばれる）単位であってもよい。

またネットワーク５は、インターネットやローカルエリアネットワーク（ＬＡＮ）、専用の通信網、またはＶＬＡＮなどに代表される仮想的なネットワークであってもよい。

テスト対象１は、Ａ／Ｂテストを行う対象となるサービスであり、例えば図１におけるサービスＢを表す。テスト対象１は、図１におけるサービスＣやサービスＤのように複数存在して良い。各サービスは、「Ｗｅｂページをユーザに送付する」、「推薦商品のリストを呼び出し元サービスに送付する」などの機能を提供するシステムといえる。

また、テスト対象１は、プロキシ２と２個以上のサービス３のパターン３−１、３−２から構成される。なお、サービス３のパターンを総称し、以降はサービス３と記載する場合がある。こうしたサービス３のパターンは、図１における各サービス中にあるｖ１、ｖ２が該当する。

また、プロキシ２は、トラヒック分割部２１とメトリクス送信部２２を有し、トラヒックをサービス３の各パターン３−１、３−２に振り分ける役割を有する。

このうちトラヒック分割部２１は、プロキシ２が受信したトラヒックを、テスト管理装置１００から指定された割合でサービス３の各パターン３−１、３−２に送付する機能である。

このときの割合は、サービス３のパターン３−１（サービスＡ１）、３−２（サービスＡ２）ごとに異なっても良い。例えば、サービス３のパターン３−１（サービスＡ１）には９０％、サービス３のパターン３−２（サービスＡ２）には１０％、といった割合を想定して良い。

また、どのアクセスがどのサービスのパターン３−１、３−２に送付されるかは、テスト対象１ごとに異なる。

また、メトリクス送信部２２は、指定された値を付加情報と共にメトリクス収集システム３０に送付する機能である。送付するデータの構成は図９にて後述する。

上述のサービス３のパターン３−１（サービスＡ１）は、メトリクス送信部２３−１を、同様にパターン３−２（サービスＡ２）は、メトリクス送信部２３−２を有し、サービスの機能を実現するための処理を行う。

メトリクス送信部２３−１、２３−２は、プロキシ２のメトリクス送信部２２と同一の機能を有する。メトリクス送信部２３−１、２３−２は、例えばサービスのパターン３内でのみ計測できるメトリクスをメトリクス収集システム３０に送付する。

なお、サービス３のパターン３−１、３−２自体を、複数のコンポーネントで実装しても良い。また、プロキシ２はサービス３のパターン３−１、３−２における一機能として実装しても良い。

一方、メトリクス収集システム３０は、メトリクス収集部３１とメトリクス情報３２を有している。メトリクス収集システム３０は、テスト対象１からメトリクスを収集してメトリクス情報３２として保持する。

上述のメトリクス収集部３１は、上述のプロキシ２および各サービス３のパターン３−１、３−２のメトリクス送信部２３−１、２３−２からメトリクスを収集する機能を持つ。

また、メトリクス情報３２は、メトリクス収集部３１により収集されたメトリクスの情報を保持する。メトリクス情報３２の詳細については図９に基づき後述する。

なお、テスト対象１が含む各構成要素は、それぞれが直接接続している必要はなく、例えばネットワーク５やそれ以外のネットワークを介して互いに接続されていても良い。

また、テスト管理装置１００は、複数のテスト対象１が同時にＡ／Ｂテストをする際に、Ａ／Ｂテストを管理する役割を有し、テスト実行部１０１、グループ算出部１０２、トラヒック制御部１０３、結果集計部１０４、ＧＵＩ部１０５、依存関係情報１０６、テスト概要情報１０７、テスト対象情報１０８、及び目標情報１０９、で構成される。

このうちテスト実行部１０１は、多変量テストを実行する（図１２にて詳述）。

また、グループ算出部１０２は、テストグループを作成する（図１１にて詳述）。

また、トラヒック制御部１０３は、テスト実行部１０１により指定された割合でトラヒックを割り振るようテスト対象１のプロキシ２に指示を送る。

また、結果集計部１０４は、メトリクス収集システム３０のメトリクス情報３１を集計し、多変量テストの評価や画面への表示項目を算出する。

また、ＧＵＩ部１０５は、テストのリクエストを入力するための画面をユーザに提示する（図３にて詳述）。

また、依存関係情報１０６は、テスト対象１を含むシステムにおけるサービス間の接続関係を示す情報である（図５にて詳述）。この依存関係情報１０６は、例えばテスト対象１の開発者など（以下、ユーザと表記する）による入力やネットワーク設定情報や分散トレーシングの出力結果などを利用して作成できる。

また、テスト概要情報１０７は、ＧＵＩ部１０５を通してユーザから入力されたテスト要求の概要を示す情報である（図６にて詳述）。

また、テスト対象情報１０８は、テストの対象となるサービス３のパターンの情報である（図７にて詳述）。

また、目標情報１０９は、「クリック数」などの目標の情報をまとめたもので、予め登録されている情報である（図８にて詳述）。
＜ＧＵＩ例＞
図３はＧＵＩ画面２００の一例を示している。ここで例示するＧＵＩ画面２００は、テスト管理装置１００のＧＵＩ部１０５が生成したＧＵＩの一例である。

このＧＵＩ画面２００を用いることで、ユーザは多変量テストの実行および結果確認ができる。ＧＵＩ画面２００には、入力画面２１０、テスト範囲画面２２０、テスト結果概要画面２３０、及びテストケース画面２４０が含まれる。

このうち入力画面２１０には、複数の入力項目と実行ボタン２１１が含まれる。当該入力項目は、テキストボックスやリストボックスとして実装され、テスト概要情報１０７（変更箇所からバージョンまで）やテスト対象情報１０８（レート）のカラム名に対応した入力ができる。レートは各行においてテスト対象１が含むパターン３のパラメータである。当該レートの行は２行以上存在しても良い。

ユーザは本入力項目を用いて、テスト概要情報１０７やテスト対象情報１０８をテスト管理装置１００に入力する。その後、ユーザが実行ボタン２１１を押下することにより、各入力項目がテスト概要情報１０７およびテスト対象情報１０８に登録されるとともにテスト実行部１０１にテストのリクエストが発行され、テストが実施される（図１０にて詳述）。

また、入力項目のうち終了条件、期限、交互条件、レートは、テスト実行後であっても値を変更して実行ボタン２１１を押下することにより、ユーザはテストのパラメータを更新できる。この更新処理は図１２のＰ１１０６にて詳述する。

これにより、例えばテスト完了までの期限を短くする必要が出た際に、ユーザはテストのパラメータを変更できる。

また、テスト範囲画面２２０は、テスト対象１を含むシステムの依存関係情報１０６が図示された画面である。テスト範囲画面２２０を用いてユーザは、リクエストした多変量テストのテストグループ１５４１が含むサービス１５４０を確認および変更できる。

テスト範囲画面２２０は、テスト対象１を含むシステムの依存関係情報１０６の図（以降、テスト範囲図２２１と呼称）と対象変更ボタン２２２を含む。

テスト範囲図２２１では、例えば各サービスは四角アイコン２２Ａで表され、その依存関係がサービス間の線２２Ｂで表現される。

テストのリクエストが発行されているサービスは、サービスの枠内にテストに使用されるパターン３の情報が四角アイコン２２Ｃで図示される（例えばサービスＤ内のＤ０やＤ１）。

同様に入力画面２１０の測定箇所に設定されているサービスにも、入力画面のレートとして記載されたパターンの情報が四角アイコンに記載される。入力画面２１０の測定箇所に設定されているサービスは、例えばサービスＢのように外枠が二重線で表現されるなどして、ユーザが識別可能である。また、測定対象のテストグループ１５４１に含まれるサービスは背景色が黒色であるなどして、ユーザから識別可能である。

ユーザは、テスト範囲図２２１上でサービス３のアイコンを押下することにより、当該サービス３をテストグループ１５４１に含めるか否かを切り替えられる。この更新処理は図１２のＰ１１０６にて詳述する。これにより、例えばテスト完了までの期限を短くする必要が出た際に、ユーザは指定したサービスの交互作用の確認を諦めることと引き換えにテストの終了時刻を前倒すことが可能となりうる。

テスト結果概要画面２３０には、テストの概要として、例えば改善割合や改善確率、終了予想時刻が表示される。

改善割合は、目標となる計測値が基準となるパターンから改善された割合のうち、テストパターン内で最大の値である。なお、基準となるパターンとは、例えば入力画面２１０のレートにて、基準の項目にｂａｓｅと入力されたパターンの組み合わせで構成されたテストケースである。

改善確率は、上述の改善割合が本当に改善されている確率である。Ａ／Ｂテストではサンプルをもとに改善の有無を判断するため、サンプルにより算出した結果が正しいか否かは確率として出力される。終了予想時刻はサンプル数の増加速度から予測されるテストの終了時刻である。

テストケース画面２４０は、テストの実施状況がテストケースごとに表示される。各テストケースの情報には、組合せ名やサンプル数、計測値、改善割合、改善確率が含まれる。

組合せ名は、テストケースで評価されるパターンの組合せの情報である。サンプル数とは現在収集したＡ／Ｂテストの評価に必要なデータの数であり、例えばテストケースの組合せパターンへのユーザアクセス数などである。

計測値とは、目標となるメトリクスの現在値である。例えば目標値がクリック率の場合は、ユーザアクセスのうちユーザがクリックした割合が該当する。

改善割合は、目標となる計測値が基準となるパターンから改善された割合である。また、改善確率は、上述の改善割合が本当に改善されている確率である。この項目以外にも、例えば目標値に対するサービスごとの影響度を記載しても良い。当該影響度は例えばベイジアンフィルタやロジスティック回帰等で計算できる。
＜ハードウェア構成＞
図４はプロキシ２、サービス（を実装するシステム）、メトリクス収集システム３０、テスト管理装置１００のハードウェア構成の一例を示すブロック図である。

ただし、このハードウェア構成は物理的な計算機であっても良いし、仮想サーバと呼ば
れる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク（プロセスやコンテナとも呼ばれる）であってもよい。

電子計算機３００には、プロセッサ３０１、通信制御装置３０２、通信インターフェース３０３、主記憶装置３０４、および補助記憶装置３０５が設けられている。なお、プロセッサ３０１、通信制御装置３０２、通信インターフェース３０３、主記憶装置３０４、および補助記憶装置３０５は、内部バス３０６を介して相互に接続されている。

上述のうちプロセッサ３０１は、動作制御を司るハードウェアである。

また、主記憶装置３０４は、例えば、不揮発性の半導体メモリから構成され、各種プログラムやデータを保持する。

また、補助記憶装置３０５は、大容量の記憶容量を有する記憶装置であり、例えば、ハードディスク装置やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。この補助記憶装置３０５は、各種プログラムの実行ファイルを保持する。

補助記憶装置３０５および補助記憶装置３０５は、プロセッサ３０１からアクセス可能である。

また、通信制御装置３０２は、通信を制御する機能を有するハードウェアであり、図２に示すシステムのコンポーネントが互いに通信するために使用される。通信制御装置３０２は、通信インターフェース３０３を介してネットワーク５に接続される。
＜データ構造の例＞
図５は依存関係情報１０６のデータ構造の一例を示す図である。この依存関係情報１０６は、テスト管理装置１００がＡ／Ｂテストを行う対象システムの構造の情報である。

こうした依存関係情報１０６は、サービスＩＤ４０１と依存先４０２を含む。このうちサービスＩＤ４０１は、サービス１５４０の識別子であり、テスト管理装置１００内で一意の値を持つ。依存先４０２はサービスＩＤ４０１で示された当該サービスが呼び出している他のサービスのサービスＩＤ４０１である。

続いて図６に、テスト概要情報１０７のデータ構造の一例を示す。このテスト概要情報１０７は、ＧＵＩ部１０５を通してユーザから送付されたテストの要求の概要を示す情報であり、各行がそれぞれ個別のテストを表す。

テスト概要情報１０７は、テストＩＤ５０１、変更箇所５０２、測定箇所５０３、目標５０４、影響タイプ５０５、影響度５０６、テストグループ５０７、期限５０８、交互条件５０９、及び終了条件５１０を含む。

このうち、テストＩＤ５０１はテストごとに発行される識別子であり、テスト管理装置１００内で一意の値を持つ。また、変更箇所５０２はテスト対象１であるサービスのサービスＩＤ４０１である。

また、測定箇所５０３は、テストにおけるメトリクスの測定先となるサービスのサービスＩＤ４０１である。

なお、変更箇所５０２と測定箇所５０３は異なるサービスになりうる。例えば推薦商品を算出するアルゴリズムを変えたときのユーザのクリック率をテストする場合、推薦商品
を算出するサービスが変更箇所５０２で、ユーザが操作するＷｅｂページ生成するサービスが測定箇所５０３などとなる場合がある。

目標５０４は、テストにおいて評価するメトリクスの目標ＩＤ７０１（図８にて詳述）を指す。また、影響タイプ５０５は、テスト対象１の変更内容が与える影響のタイプであり、例えば、ユーザに影響を与える変更、速度に影響を与える変更、エラー率に影響を与える変更、リソース消費量に影響を与える変更、などの項目やその組合せが含まれる。

また、影響度５０６は、テスト対象１の変更が影響タイプ５０５に与える影響の大きさを表しており、例えば大、中、小などの項目が含まれる。

テストグループ５０７はテストグループに含まれるサービスのサービスＩＤ４０１のリストであり、ＧＵＩ画面２００のテスト範囲２２０でのユーザ入力をもとにグループ算出部１０９が算出する。

期限５０８は、テストの終了期限となる時刻であり、例えばＩＳＯ８６０１の形式で表される。この期限５０８はタイムゾーンの情報を含んでも良い。

また、交互条件５０９は、当該テストが多変量テストとして参照する他のテストの条件であり、対象テストと影響度の情報の組で構成される。

対象テストとしては、例えば、全種、関連のみ、なし、があって良く、影響度は影響度５０６と同じ項目があって良い。

また、交互条件５０９および目標５０４、他のテストの影響タイプ５０５、影響度５０６、依存関係情報１０６は、グループ算出部１０２がテストグループ１５４２を算出するための情報である（図１１にて詳述）。

終了条件５１０は、テストを終了させる条件であり、例えばテストケースの改善確率が９５％以上になるなどの条件である。

図７はテスト対象情報１０８のデータ構造の一例である。このテスト対象情報１０８は、テストの対象となるサービス３のパターンの情報であり、各行が特定のテストにおける一つのパターンの情報を表す。

こうしたテスト対象情報１０８は、例えばＧＵＩ部１０５からのユーザ入力をもとに作成される。

テスト対象情報１０８は、テストＩＤ６０１、対象名６０２、アクセス先６０３、レート基準６０４、レート上限６０５、及びレート下限６０６の各値を含む。

このうちテストＩＤ６０１は、テストＩＤ５０１と同じくテストごとに発行される識別子であり、テスト管理装置１００内で一意の値を持つ。

また、対象名６０２は、レコードが表すパターンの名称である。アクセス先６０３は当該パターンにアクセスするための情報であり、例えばＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）やＩＰアドレス（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）で表される。

レート基準６０４は、当該パターンに流すトラヒックの割合の基準となる値である。同
じく、レート上限６０５は当該パターン３に流すトラヒックの上限であり、レート下限６０６は下限である。なお、こうしたレート６０４〜６０６の各値は、例えばパーセントで表現される。

ベースとなるパターンは、レート６０４〜６０６が存在せず、同一テスト対象１が有する他のパターンのレートの残量がレートに割り当てられる。

多変量テストの際は、テスト実行部１０１がテストの期限５０８を加味してレート上限６０５とレート下限６０６の中で、レート基準６０４に近くなるようにトラヒックのレートを算出する。

図８は目標情報１０９のデータ構造の一例である。この目標情報１０９は、「クリック数」などの目標の情報をまとめたもので、予め登録されている情報である。
目標情報１０９は、目標ＩＤ７０１、影響タイプ７０２、及び依存先７０３の各値を含む。このうち目標ＩＤ７０１は、目標の識別子であり、テスト管理装置１００内で一意の値を持つ。

また、影響タイプ７０２は、当該目標が何の影響を受けるかを表した情報である。この影響タイプ７０２の項目は、影響タイプ５０５と同一である。

また、依存先７０３は、目標がどのような依存先のサービスに影響を受けるかを示した情報である。依存先のサービスとは、図５の依存関係情報１０１にて示したようにサービスが呼び出しているサービスである。

依存先７０３には、測定箇所の依存先サービス、変更箇所の依存先サービス、測定箇所から変更箇所までのサービス、測定箇所のみ、変更箇所のみ、などの項目が含まれる。

図９はメトリクス情報３２のデータ構造の一例である。このメトリクス情報３２は、メトリクス収集システム３０が収集した、クリック数や応答時間、ユーザアクセス数などのメトリクス情報が保持される。

このメトリクス情報３２にはタイムスタンプ８０１、対象名８０２、メトリクス名８０３、測定値８０４が含まれる。

このうちタイムスタンプ８０１は、メトリクスを収集したときの時刻の情報であり、例えばＩＳＯ８６０１の形式で表される。

また、期限５０８は、タイムゾーンの情報を含んでも良い。対象名８０２は、メトリクス収集元のパターンの識別子である。

メトリクス名８０３は、収集したメトリクスの名称８０３である。また、測定値８０４は収集したメトリクスの値である。
＜テスト管理方法のフロー＞
続いて、テスト管理方法のフローについて、図１０に基づき説明する。図１０はテスト管理装置１００がユーザからテストの要求を受信してから実際にテストが実行されるまでの全体の処理の一例を示した図である。

この場合、テスト管理装置１００のＧＵＩ部１０５は、ユーザ向けにＧＵＩ画面２００を当該ユーザの端末（ネットワーク５に接続した情報処理端末。図示なし）に出力する。

また、ＧＵＩ部１０５は、当該ユーザが入力項目２１０を入力して実行ボタン２１１を押下したことを受けて、入力項目２１０の項目をテストの要求として取得する。また、ＧＵＩ部１０５は、入力項目２１０のうち変更箇所から交互条件までのパラメータをテスト概要情報１０７に保存し、レートをテスト対象情報１０８に保存する（Ｐ９０１）。

その後、テスト管理装置１００のテスト実行部１０１は、未実行のテストの要求が予め定められた一定数蓄積される、前回のテスト実行から予め定められた一定時間経過する、などの特定のテスト開始条件を満たすか判定する（Ｐ９０２）。

上述の判定の結果、テスト開始条件を満たす場合（Ｐ９０２：Ｙｅｓ）、テスト実行部１０１は未実行のテストの要求を読み込み、後続の処理を実行する（Ｐ９０３）。一方、テスト開始条件を満たさない場合（Ｐ９０２：Ｎｏ）、テスト実行部１０１は、当該ユーザの入力を待機する。

テストを実行すると、テスト実行部１０１は、グループ算出部１０２に対し、一つ以上の未実施のテストのテストＩＤ５０１を送付する。

一方、グループ算出部は、テスト実行部１０１から取得したテストＩＤ５０１をもとに、各テストのテストグループを算出する（Ｐ９０４）。本処理は図１１にて詳述する。

その後、テスト実行部１０１は、テストの要求に対応した多変量テストを実行し、その結果をＧＵＩ画面２００を通じてユーザ（の端末）に通知する（Ｐ９０５）。本処理は図１２にて詳述する。

以上のように、入力された条件に基づいて作成したテストグループごとに多変量テストを行うことで、テストに必要なテストケースの数を削減できる。そのため、テスト管理装置１００はサンプル数が少ない環境においても、複数のテスト対象１がＡ／Ｂテストを同時に実行する場合において、互いのテストの影響を除外し、交互作用を考慮しつつ、評価結果算出までの時間を短縮したテストの実行を可能にする。

図１１はグループ算出部１０２がテストグループを算出する処理の一例を示した図である。本処理は、図１０のＰ９０４を詳述したものである。

本処理では、グループ算出部１０２が、テスト実行部１０１から一つ以上のテストの要求として一つ以上のテストＩＤ５０１を受け取り、テストごとのテストグループ１５４１をテスト実行部１０１に返す。

なお、以降の説明は断りが無い限り、テストＩＤ５０１ごとの処理を示しており、その対象となるテストＩＤ５０１で示されたテストを対象テストと呼称し、レコードはテストＩＤ５０１に対応したテスト概要情報１０６のレコードを指す。

まず、グループ算出部１０２は、対象テストが依存するサービスのリストを算出する（Ｐ１００１）。

具体的には、グループ算出部１０２が、対象テストのレコードの目標５０４と目標ＩＤ７０１に関して値が一致するレコードを、目標情報１０９から読み込み、その依存先７０３の値を取得する。

次にグループ算出部１０２は、依存関係情報１０６から後述の方法で当該依存先７０３の値に応じたサービスＩＤ４０２のリスト（以降、依存先サービスリストと呼称）を取得
する。当該依存先サービスリストの取得は、例えば、依存先７０３の値が「測定箇所の依存先サービス」の場合、対象テストの測定箇所５０３と同じ値のサービスＩＤ４０１および当該サービスＩＤ４０１が依存する全てのサービスＩＤ４０１を再帰的に全て取得し、取得した当該サービスＩＤ４０１群をリスト化することで実現される。なお、サービスＩＤ４０１の依存先４０２に示されたＩＤの値が、当該サービスＩＤ４０１の依存するサービス１５４０である。

次に、グループ算出部１０２は、テスト概要情報１０７にアクセスし、テストＩＤ５０１が対象テストのテストＩＤ５０１の値と異なり、かつ変更箇所５０２もしくは測定箇所５０３が依存先サービスリスト内のサービスＩＤ４０１の値と同じレコード（以降、依存テスト候補群）を全て取得する（Ｐ１００２）。

最後に、グループ算出部１０２は、対象テストのレコードの交互条件５０９を満たすテストのレコードを依存テスト候補群の中から抽出し、その変更箇所５０２のサービスＩＤのリストをテストグループとして対象テストのレコードのテストグループ５０７に登録する（Ｐ１００３）。

例えば、対象テストのレコードの交互条件５０９が「全種／影響度大」のとき、グループ算出部１０２は、依存テスト候補群のレコードから影響タイプ５０５の値が大のレコードを抽出し、その変更箇所をテストグループとする。

また、対象テストのレコードの交互条件５０９が「関連のみ／影響度中」のとき、グループ算出部１０２は、目標情報１０９から対象テストのレコードの目標５０４と目標ＩＤ７０１の値が同じレコードの影響タイプ７０２を取得し、その後、依存テスト候補群のうち、レコードの影響タイプ５０５が先ほど取得した当該影響タイプ７０２と一致し、かつ影響度が中以上のレコードを抽出し、その変更箇所をテストグループとする。

以上の処理により、グループ算出部１０２は、対象テストが依存するテストをテストグループとして算出できる。

図１２はテスト実行部１０１が多変量テストを実施する処理の一例を示した図である。本処理は、図１０のＰ９０５を詳述したものである。

このフローにおけるテスト実行部１０１は、テストの要求に対応した多変量テストを実行し、その結果をＧＵＩ画面２００を通じてユーザに通知する。なお、以降の説明は断りが無い限り、テストＩＤ５０１ごとの処理を示しており、その対象となるテストＩＤ５０１で示されたテストを対象テストと呼称し、レコードはテストＩＤ５０１に対応したテスト概要情報１０６のレコードを指す。

まず、テスト実行部１０１は、各パターンに流せるトラヒックのレート上限６０５とレート下限６０６の中で、各テストの期限５０８の間に可能な限り当該テストの終了条件５１０を満たせるような、サービスのパターンに流すトラヒックのレートを算出する（Ｐ１１０１）。このとき、影響度５０６が大きいテストから優先して終わらせるようにトラヒックのレートを調整してもよい。

ここで、テストの終了条件５１０は、図３で示した基準となるテストケースからの改善確率の値が一定以上になることである。この改善確率は例えば、ｔ検定や多因子分散分析（Ｎ−Ｗａｙ ＡＮＯＶＡ）、多重比較など、多変量テストにて用いられる統計手法により、基準となるテストケースと対象のテストケースとのメトリクス集計値の間に有意差があるか検定したときの信頼水準を用いることができる。このため、この検定に必要なサン
プルサイズが必要なサンプル（例えばユーザアクセス）の数となる。

そこで、メトリクス情報３２にある過去のメトリクスの計測値８０４から、サービスごとに単位時間（例えば毎分）あたりのサンプルの増加速度を算出することにより、測定箇所５０３のレートに応じた終了予測時間を算出できる。

そこで、テスト対象情報１０８のレート上限６０５とレート下限６０６およびサービス間の依存関係によるトラヒック流量の変化を制約条件として、実施する全てのテストについて終了予測時間が期限５０８より前になるような制約付き最適化問題を計算することにより、各パターンに流すトラヒックのレートを算出できる。

この計算は遺伝的アルゴリズムや焼きなまし法といったヒューリスティックな手法を用いても良い。このとき、影響度に応じた重み付けを行うことにより、影響度が大きいほどより終了予測時間を短くするようにトラヒックのレートを割り当てても良い。

次にトラヒック制御部１０３は、それぞれのテストに対応したテスト対象１のプロキシ２のトラヒック分割部２１を制御し、パターンのアクセス先６０３に流れるトラヒックの量をＰ１１０１で算出したレートの割合に設定する（Ｐ１１０２）。

次に、結果集計部１０４は、メトリクス収集システム３０からメトリクス情報３２を取得し、その計測値８０４を対象名８０２ごとに集計し、テストの目標５０４に応じた値に変換する（Ｐ１１０３）。

この変換は、例えば、対象のテストの目標５０４がクリック数である場合、メトリクス情報３２からタイムスタンプ８０１が一定時間内（例えば過去１分以内）で、対象名８０２が測定箇所５０３と同じ値であるレコードを取得し、メトリクス名８０３がクリック数のレコードの測定値８０４の合計を、メトリクス名８０３がユーザアクセスであるレコードの測定値８０４の合計で除算した値を算出する。

これらの計算手順は予め結果集計部１０４内に登録してあっても良いし、新しい計算手順をユーザが追加できるようにしても良い。

次に、結果集計部１０４は、テストごとに集計結果を算出し、その結果をＧＵＩ部１０５を経由してＧＵＩ画面２００に出力する（Ｐ１１０４）。ここで出力する値は、テストケース画面２４０の計測値、改善割合、改善確率、またテスト結果概要画面２３０の改善割合、改善確率、終了予想時刻、が含まれる。

計測値はＰ１１０３で算出したテストの目標５０４に応じた値である。また終了予測時刻はＰ１１０１にて算出した時刻である。改善割合は基準となるテストケースとそれ以外のテストケースのメトリクスの差分値を算出することによりＧＵＩ画面２００の改善割合を算出できる。

また、Ｐ１１０１で示した統計検定を用いて信頼水準を算出することによりＧＵＩ画面２００の改善確率を算出できる。

ここで、テスト実行部１０１は、Ｐ１１０４にて算出した改善確率が当該テストの終了条件５１０を満たすか、もしくは当該テストの期限５０８を超過しているか判定し、どちらか一方でも真である場合は当該テストが終了したとしてＰ１１０６に移動する。

一方、両方とも偽である場合は、Ｐ１１０１から処理を繰り返す。Ｐ１１０１から繰り
返す際、ＧＵＩ画面２００の値がユーザにより更新されていた場合は更新後の値を用いる。またテストＰ１１０３にて取得したメトリクスの値をもとに、Ｐ１１０１にて統計値を算出し直すことにより、より正確な終了予測時刻を算出できうる。

テストが終了した場合（Ｐ１１０５：Ｙｅｓ）、テスト実行部１０１は、当該テストのテストグループ１５４２に含まれるテスト対象１が他のテストのテストグループに含まれていないか確認し、含まれていないテスト対象１についてはトラヒック制御を解除する（Ｐ１１０７）。

以上の処理により、テスト実行部１０１はテストグループごとの多変量テストを実施できる。
＜＜実施例２＞＞
実施例２においては、実施例１に加え、テスト管理装置１００がメトリクス情報３２、ソフトウェア構成管理情報２１０およびテスト履歴情報１１１を用いて、パラメータ推定部１１０により、テストのパラメータを推定する方法を説明する。

ただし、このパラメータの推定には、メトリクス情報３２、ソフトウェア構成管理情報２１０およびテスト履歴情報１１１の全てが必要というわけではない。例えば、影響度など複数の項目から計算されるパラメータは、特定の情報が無くとも、残りの情報からパラメータを推定できる。

こうした実施例２の手法を用いることにより、ユーザはテストのパラメータの一部をＧＵＩ画面２００に入力せずとも良いという効果がある。

図１３は実施例２のシステム構成の一例である。本実施例において、テスト対象１とメトリクス収集システム３０は、実施例１について示した図２のテスト管理装置１００と同様のため、説明を省略する。

ソフトウェア構成管理システム２００は、テスト対象１を含む対象システムのソースコードなどの成果物の変更履歴を管理するシステムであり、例えばＧｉｔ（登録商標）やＳｕｂｖｅｒｓｉｏｎ（登録商標）、Ｇｉｔｌａｂ（登録商標）、ＧｉｔＨｕｂ（登録商標）である。

このソフトウェア構成管理システム２００は、上述の変更履歴をソフトウェア構成管理情報２１０に保持する。ソフトウェア構成管理情報２１０の構成は、図１４にて詳述する。

一方、テスト管理システム１２２１は、複数のテスト対象１が同時にＡ／Ｂテストをする際に、Ａ／Ｂテストを管理する役割を有する。テスト管理装置１００において、パラメータ推定部１１０とテスト履歴情報１１１以外の機能および情報は、図２で例示した構成と同様のため、説明を省略する。

実施例２において、テスト管理装置１００のテスト履歴情報１１１は、過去に実行されたテストの情報である（図１５にて詳述）。

また、パラメータ推定部１１０は、テストのパラメータを推定する機能を有する。具体的には、テスト履歴情報１１１を用いてテストの終了条件、期限、影響タイプ、交互条件を算出し、メトリクス情報３２、ソフトウェア構成管理情報２１０およびテスト履歴情報１１１を用いてテストの重要度を算出する。

こうしたパラメータ推定部１１０は、ＧＵＩ部１０５の更新状況を監視しており、ＧＵＩ画面２００の入力画面２１０にユーザが変更箇所、測定箇所、目標を入力したタイミングでパラメータの推定処理を実行する。その後、パラメータ推定部１１０は、推定したパラメータをＧＵＩ部１０５を介してＧＵＩ画面２００に出力する。これによりパラメータ推定部１１０はユーザの入力動作を補助する。

以下、パラメータ推定部１１０による各パラメータの算出方法を示す。なお、一部のパラメータの算出式に後述の図１４、図１５にて詳述される項目を含む。

まず、前準備として、パラメータ推定部１１０は、テスト履歴情報１１１から、ユーザが入力した変更箇所、測定箇所、目標が一致し、かつ定められた条件（例えば直近１０個など）のレコード（以降、履歴レコード群と呼称）を取得する。この履歴レコード群が取得できない場合は、推定不可能として影響度以外の推定処理を終了する。

上述の処理の結果、履歴レコード群が取得できた場合、パラメータ推定部１１０は、履歴レコード群に含まれる改善確率１４０７の平均値を終了条件として出力する。

同様に、パラメータ推定部１１０は、履歴レコード群に含まれるテスト終了時刻１４１２とテスト開始時刻１４１１の差の秒数をレコードごとに算出し、その平均の秒数を現在の時刻に加算した時刻を期限として出力する。

また、パラメータ推定部１１０は、履歴レコード群に最も多く出現する影響タイプ１４０８の値を影響タイプとして出力し、同様に最も多く出現する交差条件１４１０の値を交差条件として出力する。

なお、影響度の算出処理として、パラメータ推定部１１０は４種類の値の重み付け平均の値を用いる。１つ目は履歴レコード群に含まれる影響度１４０５の平均値である。平均を取る際は、例えば大を２、中を１、賞を０のように影響度の値を数値化し、その平均をとる。

２つ目はテストの対象システムにおけるテスト対象の影響の大きさである。これはメトリクス情報３２のレコードをサービスごとにユーザの入力した当該目標の計測値を算出し、計測箇所となるサービスの計測値の大きさが、計測値を算出できた全てのサービスのうち、例えば上位５％なら２、上位５０％なら１、それ以外は０となるように数値を割り振る。数値を割り振る基準は予めテスト管理装置１００が定めていても良いし、ユーザが設定できても良い。

３つ目および４つ目はテスト対象の不安定さである。これは対象名１３０２がユーザの入力した変更箇所に等しいレコードをソフトウェア構成管理情報２１０から抽出し、そのうちタイムスタンプが最新のレコードとその一つ前のレコードを取得する。

その後３つ目の値として、最新の当該レコードとその一つ前の当該レコードのソースコードの差分を取り、コメント行を除き変更されている行数が、全体の３割以上なら２、１割以上なら１、それ以下なら０と数値を割り振る。

数値を割り振る基準は、予めテスト管理装置１００に定めていても良いし、ユーザが設定できても良い。

４つ目の値は最新の当該レコードとその一つ前の当該レコードから、バージョン１３０４を取得し、メジャーバージョン（最初の数字）が変化していた場合２を、マイナーバー
ジョンが変化していた場合１を、それ以外の場合は０を付与する。

これは、ソースコードの変更量が多い場合や、メジャーバージョンアップが起きると動作が不安定になることやユーザへの影響が多いことを利用して影響度を算出している。予めテスト管理装置１００が定めていても良いし、ユーザが設定できても良い。

以上により、パラメータ推定部１１０はテストのパラメータを推定し、推定したパラメータをＧＵＩ部１０５を介してＧＵＩ画面２００に出力することで、ユーザの入力を補助する。

図１４は実施例２のソフトウェア構成管理情報２１０のデータ構造の一例である。ソフトウェア構成管理情報２１０は、テスト対象１を含む対象システムのソースコードなどの成果物の変更履歴の情報であり、タイムスタンプ１３０１、対象名１３０２、ソースコード１３０３、バージョン１３０４を含む。

このうちタイムスタンプ１３０１は、成果物が変更された時刻を表し、例えばＩＳＯ８６０１の形式で表される。このタイムスタンプ１３０１はタイムゾーンの情報を含んでも良い。

また、対象名１３０２は、ソフトウェア構成管理の対象となっているサービスの識別子であり、例えばソフトウェア構成管理を行う単位であるリポジトリの名前などを用いて保持する。

また、ソースコードは、対象名１３０２で表されるサービスのプログラムのソースコードの情報である。バージョン１３０４は、ソースコードに紐付けられたバージョンの情報であり、例えば＜メジャー．マイナー．パッチ＞の３個の値でバージョンを表記するセマンティックバージョニングの形式で表現される。

バージョン１３０４は、例えばＧｉｔ（登録商標）やＳｕｂｖｅｒｓｉｏｎ（登録商標）等のブランチ名やタグ名などとして保持する。

ソフトウェア構成管理情報２１０を用いてパラメータ算出部１２２０がテストの影響度を算出する方法は図１３のパラメータ推定部１１０の通りである。

図１５は実施例２のテスト履歴情報１１１のデータ構造の一例である。テスト履歴情報１１１は、過去実施されたテストの情報であり、テストＩＤ１４０１、変更箇所１４０２、測定箇所１４０３、目標１４０４、影響度１４０５、測定値１４０６、改善割合１４０７、改善確率１４０８、影響タイプ１４０９、交差条件１４１０、テスト開始時刻１４１１、テスト終了時刻１４１２が含まれる。

このうちテストＩＤ１４０１は、過去に実施されたテストの識別子であり、テスト管理装置１００内で一意の値を持つ。以降、テストＩＤ１４０１で示されたテストを当該テストと呼称する。

また、変更箇所１４０２は、当該テストのテスト対象１となったサービスのサービスＩＤである。測定箇所１４０５は、当該テストのメトリクスの測定先となったサービスのサービスＩＤである。

また、目標１４０４は、当該テストの目標となるメトリクスの値であり、目標情報１０９の目標ＩＤ７０１で表される。

また、影響度１４０５は、当該テストの影響度を表す。測定値１４０６は当該テストの終了時に最も改善確率の高かったテストケースの測定値である。

また、改善割合１４０７は、測定値１４０６のテストケースの改善割合である。改善確率１４０８は測定値１４０６のテストケースの改善確率である。

また、交差条件１４１０は、当該テストの交差条件５０９である。テスト開始時刻１４１１は当該テストが開始された時刻であり、テスト終了時刻１４１２は当該テストが終了した時刻である。

テスト開始時刻１４１１とテスト終了時刻１４１２は例えばＩＳＯ８６０１の形式で表される。これらの値はタイムゾーンの情報を含んでも良い。

テスト履歴情報１１０は、当該テストの開始時にテストＩＤ１４０１および変更箇所１４０２、測定箇所１４０３、目標１４０４、影響度１４０５、テスト開始時刻１４１１がテスト実行部１０１により登録される。

また、テスト終了時に、当該テストのレコードに測定値１４０６、改善割合１４０７、改善確率１４０８、交差条件１４１０、テスト終了時刻１４１２がテスト実行部１０１により登録される。

テスト履歴情報１１１を用いてパラメータ算出部１２２０がテストの影響度を算出する方法は図１３のパラメータ推定部１１０の通りである。

以上の処理および情報を用いてテスト管理装置１００はテストのパラメータの推定を行う。これにより、ユーザはテストのパラメータの一部をＧＵＩ画面２００に入力せずとも良いという効果を得られる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間を短縮可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のテスト管理システムにおいて、前記Ａ／Ｂテストに関して予め規定された、トラヒックのレート上限及び下限と、前記Ａ／Ｂテストの期限とに基づき、前記テスト対象ごとに存在するパターンに割り当てるトラヒックが、前記レート上限と前記レート下限の条件を満たしつつ、前記Ａ／Ｂテストが前記期限までに完了するようトラヒックのレートを制御する処理を繰り返し、前記トラヒックのレートの割り当てを最適化するトラヒック制御部をさらに備える、としてもよい。

これによれば、ユーザ数の規模が小さいケースに適宜に対応し、そのトラヒックを効率的に制御可能となる。ひいては、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間をより短縮可能となる
また、本実施形態のテスト管理システムにおいて、前記トラヒック制御部は、前記トラヒックのレート割り当ての際、前記影響度がテスト対象間で相対的に大きいテスト対象に対し、優先的にトラヒックを割り当てるものである、としてもよい。

これによれば、結果に大きな影響を与えるテスト対象にトラヒックを多く割り当てることが可能となり、ひいては、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間をより短縮可能となる
また、本実施形態のテスト管理システムにおいて、前記テスト管理装置は、前記記憶部において、前記情報として、前記テスト対象のソフトウェアに関するソフトウェア構成管理情報と、前記多変量テストのテスト履歴情報と、前記多変量テストにおけるテスト結果を集計したメトリクス情報と、を格納し、前記記憶部における、前記メトリクス情報、前記ソフトウェア構成管理情報、及び前記テスト履歴情報の各情報のうち、ユーザが指定した、テスト対象における変更箇所、テスト目標及び当該テスト目標の測定箇所が一致するものを抽出し、当該情報における予め定めた項目の値を所定アルゴリズムに適用して、今回のテスト対象における前記影響度を推定するパラメータ推定部をさらに備える、としてもよい。

これによれば、ユーザが影響度を規定できない等の状況に適宜に対処し、影響度を推定することが可能となる。ひいては、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間をより短縮可能となる
また、本実施形態のテスト管理システムにおいて、前記パラメータ推定部は、前記記憶部における前記テスト履歴情報を参照し、前記記憶部における、前記メトリクス情報、前記ソフトウェア構成管理情報、及び前記テスト履歴情報の各情報のうち、ユーザが指定した、テスト対象における変更箇所、テスト目標及び当該テスト目標の測定箇所が一致するものを抽出し、当該情報における各項目を、今回のテスト対象に関するパラメータとして推定するものである、としてもよい。

これによれば、テスト対象に関するパラメータをユーザが指定できない場合に適宜に対応し、デフォルトの値を推定、提示することが可能となる。ひいては、複数のＡ／Ｂテストを同時実行するケースにおいて、テスト間の影響と交互作用を踏まえつつ、評価結果の算出時間をより短縮可能となる。

１ テスト対象
２ プロキシ
２１ トラヒック分割部
２２ メトリクス送信部
２３ メトリクス送信部
３ サービス
５ ネットワーク
１０ テスト管理システム
３０ メトリクス収集システム
３１ メトリクス収集部
３２ メトリクス情報
１００ テスト管理装置
１０１ テスト実行部
１０２ グループ算出部
１０３ トラヒック制御部
１０４ 結果集計部
１０５ ＧＵＩ部
１０６ 依存関係情報
１０７ テスト概要情報
１０８ テスト対象情報
１０９ 目標情報
１１０ パラメータ推定部
１１１ テスト履歴情報
１２０ 記憶部
２００ ソフトウェア構成管理システム
２１０ ソフトウェア構成管理情報
１５４０ サービス
１５４１ テストグループ

Claims (7)

1. Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部と、
   前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成するグループ算出部と、
   前記テストグループに関して多変量テストを実行するテスト実行部と、
   を備えたテスト管理装置を含むことを特徴とするテスト管理システム。
2. 前記テスト管理装置において、
   前記Ａ／Ｂテストに関して予め規定された、トラヒックのレート上限及び下限と、前記Ａ／Ｂテストの期限とに基づき、
   前記テスト対象ごとに存在するパターンに割り当てるトラヒックが、前記レート上限と前記レート下限の条件を満たしつつ、前記Ａ／Ｂテストが前記期限までに完了するようトラヒックのレートを制御する処理を繰り返し、前記トラヒックのレートの割り当てを最適化するトラヒック制御部をさらに備える、
   ことを特徴とする請求項１に記載のテスト管理システム。
3. 前記トラヒック制御部は、
   前記トラヒックのレート割り当ての際、前記影響度がテスト対象間で相対的に大きいテスト対象に対し、優先的にトラヒックを割り当てるものである、
   ことを特徴とする請求項２に記載のテスト管理システム。
4. 前記テスト管理装置は、
   前記記憶部において、前記情報として、前記テスト対象のソフトウェアに関するソフトウェア構成管理情報と、前記多変量テストのテスト履歴情報と、前記多変量テストにおけるテスト結果を集計したメトリクス情報と、を格納し、
   前記記憶部における、前記メトリクス情報、前記ソフトウェア構成管理情報、及び前記テスト履歴情報の各情報のうち、ユーザが指定した、テスト対象における変更箇所、テスト目標及び当該テスト目標の測定箇所が一致するものを抽出し、当該情報における予め定めた項目の値を所定アルゴリズムに適用して、今回のテスト対象における前記影響度を推定するパラメータ推定部をさらに備える、
   ことを特徴とする請求項１に記載のテスト管理システム。
5. 前記パラメータ推定部は、
   前記記憶部における前記テスト履歴情報を参照し、前記記憶部における、前記メトリクス情報、前記ソフトウェア構成管理情報、及び前記テスト履歴情報の各情報のうち、ユーザが指定した、テスト対象における変更箇所、テスト目標及び当該テスト目標の測定箇所が一致するものを抽出し、当該情報における各項目を、今回のテスト対象に関するパラメータとして推定するものである、
   ことを特徴とする請求項４に記載のテスト管理システム。
6. Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部と、
   前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成するグループ算出部と、
   前記テストグループに関して多変量テストを実行するテスト実行部と、
   を備えることを特徴とするテスト管理装置。
7. テスト管理装置が、
   Ａ／Ｂテストのテスト対象に関する情報を保持する記憶部を備えて、
   前記テスト対象のうち同時にＡ／Ｂテストが実行される、複数のテスト対象に関して、前記記憶部の前記情報が示す、テスト目標、当該テスト目標への影響度、及びテスト対象間の依存関係を参照し、テスト目標が一致し、当該テスト目標への影響度が所定基準のものであって、テスト対象間で依存関係があるものを、前記複数のテスト対象から抽出してテストグループを生成し、
   前記テストグループに関して多変量テストを実行する、
   ことを特徴とするテスト管理方法。

Images