JP5629239B2 - ソフトウェアの動作をテストする装置及び方法 - Google Patents

Description

本発明は、ソフトウェアの動作をテストする装置及び方法に関する。特に、本発明は、ソフトウェアの複数のバージョンの動作をテストする装置及び方法に関する。

ソフトウェアのあるバージョンで正常に使用可能であったデータが、そのソフトウェアのバージョンが変わることによって正常に使用できなくなることがある。このようなソフトウェアの例としては、ＣＡＴＩＡ（登録商標）等のＣＡＤソフトがあり、バージョンが変わる要因の例としては、新リリースや緊急パッチ適用がある。
新リリースや緊急パッチ適用では、その対象となる不具合が修正されているかどうかが、ＣＡＤソフトの開発元（以下、単に「開発元」という）において確認される。このとき、開発元としては、その対象となる不具合が発生していない箇所、例えば、過去に修正した箇所についても確認し、不具合の修正が他の箇所に影響していないこと、つまり、不具合の修正によって却ってＣＡＤソフトの品質が悪化していないことを保証できるのが理想的である。

ところが、ＣＡＤソフトに関しては、データ、使い方（どの機能を利用するか）、品質基準（どの程度の精度を要求するか）等が、ＣＡＤソフトのユーザ企業（以下、単に「ユーザ」という）ごとに異なり、開発元でこれを把握することは難しいという事情がある。また、データ及び使い方はノウハウであるので、ユーザが社外に公表できないという事情もある。
こうした事情から、開発元においてユーザの使用方法を網羅したテストを頻繁な新リリースや緊急パッチ適用ごとに実施し、不具合の修正が他の箇所に影響していないことを保証することは困難である。
そこで、ユーザ側においてユーザデータを用いた新リリースや緊急パッチ適用ごとのテストを実施することが有効になる。

尚、公報記載の技術としては、テストケースの作成に着目した技術として、例えば特許文献１、２の技術がある。
特許文献１の技術では、モデル検査により出力された状態と、状態の遷移により表される状態空間を参照して、外部モジュールを呼び出す状態を特定する状態特定処理と、特定した外部モジュールを呼び出す状態から初期状態へのパスを、状態の遷移を参照して抽出するパス抽出処理と、抽出したパスに対して、プログラムの仕様に基づいて「Ａ（条件）ならばＢ（帰結）である」の形式で作成されたプロパティの条件を比較して、条件を満たす抽出したパスを検出するプロパティ適用処理と、条件ごとに抽出したパスを分類するシナリオ分類処理と、シナリオ分類処理により分類された抽出したパスと、抽出したパスに対応するプロパティの帰結を期待される結果を、テストケースとして生成するテストケース生成処理と、を実行する。
特許文献２の技術では、実運用されている本番機に含まれる第１サーバにおいて、ハードディスクに、本番ディレクトリと別に、仮想ディレクトリを設け、ユーザがジョブ登録部に登録したテスト対象のプログラムに係るデータは、仮想ディレクトリに格納する。ジョブ処理部は、本番処理を本番ジョブ処理部で行うとともに、テスト対象のプログラムを仮想ジョブ処理部で実行する。ファイル解析部は、元のプログラム及びそのプログラムの入出力データを解析することにより、処理内容及び処理特性を特定し、テストケースの作成、テスト結果の判定を行う。リリース処理部は、テスト後に仮想ディレクトリに格納されたテストに係るデータを削除し、リリースが可能となったプログラムなどを本番ディレクトリに移行する。
同様のテストケースの作成に着目した技術としては、特許文献３、４の技術もある。

また、テストケースの取捨選択に着目した技術として、例えば特許文献５の技術がある。
特許文献５の技術では、テスト対象のソースコードに処理の流れを追跡するための処理を埋め込むトレース機能埋込部と、トレース情報表と自動テスト実行システムが出力したテスト実行結果表を連結し、重複したテストケースを削除するテスト結果分析部を用いて、重複したテストケースを削除した後、テスト実行結果表を表示装置に表示する。
同様のテストケースの取捨選択に着目した技術としては、特許文献６、７の技術もある。

更に、その他のテストに関する技術として、例えば特許文献８〜１０の技術がある。

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

このように、ソフトウェアのバージョンが変わるごとにユーザ側でユーザデータを用いたテストを実施することは有効である。
しかしながら、ユーザデータを用いて普通にテストを実施したのでは、ＣＡＤソフトの製品仕様が通常公開されていないことから、重複したテストが行われ、無駄が発生する可能性がある。
例えば緊急パッチ適用前の検証は早く終えてパッチ適用が求められるため、限られた時間内に完了させる必要があるので、このような重複したテストはできるだけ排除する必要がある。即ち、普通にテストを実施したのではテスト工数が膨大になるので、テストを最適化することが望まれる。
また、このような重複したテストは排除し、その代わりに、新しいユーザデータを追加して、別の不具合や別の機能について対応した方がより効果的である。

尚、公報記載の技術は、何れも、ソフトウェアのバージョンが変わるごとのテストにおける無駄の削減に寄与するものではない。

本発明の目的は、複数のデータを用いてソフトウェアの複数のバージョンの動作をテストする際の無駄を削減することにある。

かかる目的のもと、本発明は、ソフトウェアの複数のバージョンの動作をテストする装置であって、複数のデータの各データと、各データを識別するデータ識別情報とを対応付けて記憶する記憶部と、複数のデータの各データを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列と、各データを識別するデータ識別情報とを対応付けたテスト結果情報を取得する取得部と、複数のデータをグループ化して得られる複数のグループであって各グループに属するデータを識別するデータ識別情報にテスト結果情報において対応付けられたテスト結果列が同一又は類似である複数のグループの各グループを、テスト結果列によって識別するグループ識別情報と、各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を、テスト結果列における連続して成功を示すテスト結果の多さによって示すテスト結果安定性情報と、各グループに属するデータを用いてテストされるソフトウェアのモジュールの安定性を、テスト結果列におけるテスト結果の変動の少なさによって示すモジュール安定性情報と、各グループに属するデータを識別するデータ識別情報とを対応付けたグループ情報を生成するグループ情報生成部と、複数のグループの各グループを識別するグループ識別情報にグループ情報において少なくとも２つのデータ識別情報が対応付けられており、グループ識別情報にグループ情報において対応付けられたテスト結果安定性情報が予め定めた第１の基準を超える安定性を示しており、グループ識別情報にグループ情報において対応付けられたモジュール安定性情報が予め定めた第２の基準を超える安定性を示しているがテスト結果列におけるテスト結果の変動が１回以上あることを示している場合に、各グループに属するデータを識別するデータ識別情報として少なくとも２つのデータ識別情報のうちの特定のデータ識別情報を含み特定のデータ識別情報以外は含まないリストを生成するリスト生成部と、複数のグループの各グループに属するデータとして、リスト生成部により生成されたリストに各グループに属するデータを識別するデータ識別情報として含まれる特定のデータ識別情報に対応付けて記憶部に記憶されたデータを用いて、ソフトウェアの新たなバージョンのテストを実行するテスト実行部とを含む、装置を提供する。

また、本発明は、ソフトウェアの複数のバージョンの動作をテストする装置であって、複数のデータの各データについて、各データを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得する取得部と、複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて取得部により取得されたテスト結果列が同一又は類似である複数のグループの各グループについて、各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成する生成部と、複数のグループの少なくとも２つのデータが属する各グループについて生成部により生成されたテスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、少なくとも２つのデータからソフトウェアの動作をテストする際に用いるデータを選択する選択部とを含む、装置も提供する。

ここで、生成部は、複数のグループの各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列における成功を示すテスト結果の出現状況に基づいて、テスト結果安定性情報を生成する、ものであってもよい。
また、生成部は、複数のグループの各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列において、複数のバージョンのうちの最新のバージョンから遡って連続するバージョンの動作をテストしたときのテスト結果が成功を示し続ける長さが長いほど、高い安定性を示すテスト結果安定性情報を生成する、ものであってよい。

更に、生成部は、複数のグループの各グループに属するデータを用いてテストされるソフトウェアのモジュールの安定性を示すモジュール安定性情報を更に生成し、選択部は、少なくとも２つのデータが属する各グループについて生成部により生成されたモジュール安定性情報が予め定めた基準を超える安定性を示している場合に、少なくとも２つのデータからソフトウェアの動作をテストする際に用いるデータを選択する、ものであってよい。

この場合、生成部は、複数のグループの各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列におけるテスト結果の変動状況に基づいて、モジュール安定性情報を生成する、ものであってよい。
また、生成部は、複数のグループの各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列において、複数のバージョンの各バージョンの動作をテストしたときのテスト結果の変動に各バージョンの新しさに応じた重みを付加して加算することで得られた変動の度合いが低いほど、高い安定性を示すモジュール安定性情報を生成する、ものであってよい。

加えて、選択部は、少なくとも２つのデータの各データを用いてソフトウェアの動作をテストするのに要する時間に基づいて、少なくとも２つのデータからソフトウェアの動作をテストする際に用いるデータを選択する、ものであってよい。

更に、本発明は、ソフトウェアの複数のバージョンの動作をテストする方法であって、複数のデータの各データについて、各データを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得するステップと、複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて取得されたテスト結果列が同一又は類似である複数のグループの各グループについて、各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成するステップと、複数のグループの少なくとも２つのデータが属する各グループについて生成されたテスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、少なくとも２つのデータからソフトウェアの動作をテストする際に用いるデータを選択するステップとを含む、方法も提供する。

更にまた、本発明は、ソフトウェアの複数のバージョンの動作をテストする装置としてコンピュータを機能させるプログラムであって、コンピュータを、複数のデータの各データについて、各データを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得する取得部と、複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて取得部により取得されたテスト結果列が同一又は類似である複数のグループの各グループについて、各グループに属するデータを用いてソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成する生成部と、複数のグループの少なくとも２つのデータが属する各グループについて生成部により生成されたテスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、少なくとも２つのデータからソフトウェアの動作をテストする際に用いるデータを選択する選択部として機能させる、プログラムも提供する。

本発明によれば、複数のデータを用いてソフトウェアの複数のバージョンの動作をテストする際の無駄を削減することができる。

本発明の実施の形態におけるテスト実行装置の構成例を示したブロック図である。 本発明の実施の形態におけるテスト結果記憶部の記憶内容の例を示した図である。 本発明の実施の形態におけるテストケースグループ決定処理について説明するための図である。 本発明の実施の形態におけるテスト結果安定性指数の算出方法について説明するための図である。 本発明の実施の形態におけるモジュール安定性指数の算出方法について説明するための図である。 本発明の実施の形態でモジュール安定性指数を算出する際に用いる重み付け関数の例を示した図である。 本発明の実施の形態におけるテスト結果分析部の動作例を示したフローチャートである。 本発明の実施の形態におけるテスト結果記憶部の記憶内容の例を示した図である。 本発明の実施の形態におけるテスト用リスト作成処理について説明するための図である。 本発明の実施の形態におけるリスト作成部の動作例を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
本実施の形態は、ユーザデータを用いなければ最終的な受け入れ可否の判定が困難なＣＡＤソフトについて、ブラックボックス的に、即ち、その内部構造を知ることなく、過去に障害を発生したデータを用いて、ユーザのＣＡＤソフトの利用状況及びＣＡＤソフトのモジュールの変更状況を考慮して、時間的な制約の下で、網羅性及び効率性の高いテストを実施するものである。

図１は、本発明の実施の形態におけるテスト実行装置１０の構成例を示したブロック図である。例えば、セットメーカは、ＣＡＤソフトによって部品の形状を表す形状データを作成し、この形状データを部品メーカに提供して部品の製造を依頼する。このとき、セットメーカがＣＡＤソフトによって直接的に作成するＣＡＤデータにはセットメーカ独自の設計情報も含まれているので、部品メーカには、ＣＡＤデータをそのまま提供するのではなく、ＣＡＤソフトの機能によって設計情報を削除する変換を行った後の形状データを提供する。一方、ＣＡＤソフトにはその不具合の修正等のために修正パッチが適用されることがある。ところが、修正パッチが他のセットメーカからの要望に応じて適用された場合等は、修正パッチが適用されたＣＡＤソフトを用いることにより、別の部分に影響が生じることがある。従って、修正パッチが適用されるごとに、ＣＡＤソフトの機能によるＣＡＤデータから形状データへの変換が、ＣＡＤデータから形状に関する部分を正確に抜き出すものとなっているかどうかのテストを行う必要がある。そこで、このテスト実行装置１０では、修正パッチ適用ごとの版（リリース）が異なるＣＡＤソフトについてこのようなテストを行う。

図示するように、テスト実行装置１０は、テストデータ記憶部１１と、テストデータ追加部１２と、テスト条件設定部１３と、テスト実行部１４と、テスト結果分析部１５と、テスト結果記憶部１６と、リスト作成条件設定部１７と、リスト作成部１８と、リスト記憶部１９とを含む。

テストデータ記憶部１１は、テストケース名と、テストデータとを対応付けて記憶するデータベースである。ここで、テストケース名は、テストデータを識別する名称であり、例えばテストデータのファイル名を用いるとよい。テストデータは、ＣＡＤソフトにより形状データに変換される前のＣＡＤデータのうち、テスト実行部１４によるテストで用いるデータである。本実施の形態では、データの一例として、テストデータを用いており、データ識別情報の一例として、テストケース名を用いている。また、データとデータ識別情報とを対応付けて記憶する記憶部の一例として、テストデータ記憶部１１を設けている。

テストデータ追加部１２は、１回目のリリースのＣＡＤソフトを用いたテストに先立ち、又は、そのテストを行った後のデータの追加が必要となった任意のタイミングで、テストデータ記憶部１１にテストデータを追加する。このとき、テストデータ追加部１２は、ユーザ側で過去に障害を発生させたＣＡＤデータを、テストデータとして追加する。

テスト条件設定部１３は、テスト実行部１４によりテストを行う際の条件であるテスト条件を設定する。ここで、テスト条件には、例えば、テストデータで表される形状とテストデータを変換して得られる形状データで表される形状との許容誤差がある。尚、このテスト条件設定部１３はオプションであり、テスト実行部１４によるテストでテスト条件が必要でない場合は、設けなくてもよい。

テスト実行部１４は、テストデータ記憶部１１に記憶されたテストデータで表される形状と、このテストデータをＣＡＤソフトにより変換して得られる形状データで表される形状との差分が、テスト条件設定部１３により設定された許容誤差内に収まっているかどうかのテストを行う。このとき、テスト対象となるテストデータのテストケース名を記述したリストのデータ（以下、「テスト用リスト」という）がリスト記憶部１９に記憶されていれば、テストデータ記憶部１１に記憶されたテストデータのうち、リスト記憶部１９に記憶されたテスト用リストに記述されたテストケース名に対応するテストデータを用いて、テストを行う。そして、テストケース名に対応付けて、テスト結果及びテスト時間を出力する。

テスト結果分析部１５は、１回目から（Ｎ−１）回目のリリースのＣＡＤソフトを用いたテストでは、テスト実行部１４によりテストケース名に対応付けて出力されたテスト結果及びテスト時間に基づいて、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト結果履歴及びテスト時間情報を更新する。また、Ｎ回目以降のリリースのＣＡＤソフトを用いたテストでは、テスト実行部１４によりテストケース名に対応付けて出力されたテスト結果と、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト結果履歴とを分析し、グループ識別子を生成すると共にテスト結果安定性指数及びモジュール安定性指数を算出する。そして、テスト結果記憶部１６にそのテストケース名に対応付けて、グループ識別子、テスト結果安定性指数、モジュール安定性指数を記憶すると共に、テスト実行部１４によりテストケース名に対応付けて出力されたテスト結果及びテスト時間に基づいて、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト結果履歴及びテスト時間情報を更新する。尚、Ｎは予め定めた自然数で、テストケースの集約を初めて実施するときのＣＡＤソフトのリリース回数を示す。Ｎは例えば１０〜２０程度が望ましい。本実施の形態では、テスト結果情報の一例として、テスト結果記憶部１６に記憶されたテストケース名とテスト結果履歴との対応情報を用いており、テスト結果情報を取得する取得部の一例として、テスト結果分析部１５を設けている。また、グループ情報の一例として、テスト結果記憶部１６に記憶されたテストケース名とグループ識別子とテスト結果安定性指数とモジュール安定性指数との対応情報を用いており、グループ情報を生成するグループ情報生成部の一例として、テスト結果分析部１５を設けている。

テスト結果記憶部１６は、テストケース名と、テスト結果履歴と、グループ識別子と、テスト結果安定性指数と、モジュール安定性指数と、テスト時間情報とを対応付けて記憶するデータベースである。ここで、テストケース名は、テスト実行部１４によるテストの対象となったテストデータを識別する名称である。テスト結果履歴は、テスト結果列の一例であり、ＣＡＤソフトのバージョンの一例であるリリースごとにリリース番号及びテスト結果を記述した履歴情報である。また、グループ識別子は、グループ識別情報の一例であり、対応するテストケースが属するグループを識別する情報である。テスト結果安定性指数は、テスト結果安定性情報の一例であり、対応するテストケースにおけるテスト結果の安定性（テスト結果が良好であるかどうか）を示す指数である。モジュール安定性指数は、モジュール安定性情報の一例であり、対応するテストケースでテストされるＣＡＤソフトのモジュールの安定性（モジュールが頻繁に変更されていないかどうか）を示す指数である。更に、テスト時間情報は、対応するテストケースのテストに要した時間の情報であり、複数回のテストが行われた場合には例えば個々のテストに要した時間の平均値や最新のテストに要した時間によって表すとよい。

リスト作成条件設定部１７は、テスト用リストを作成する際の条件（以下、「リスト作成条件」という）を設定する。ここで、リスト作成条件には、例えば、テスト用リストに含めるテストケースの数の制限、テスト用リストに含めるテストケースのテスト時間の制限、テスト用リストでテストケースを集約するときのテスト結果安定性指数の下限の閾値である第１閾値、テスト用リストでテストケースを集約するときのモジュール安定性指数の下限の閾値である第２閾値がある。

リスト作成部１８は、テスト結果記憶部１６に記憶されたテスト結果と、リスト作成条件設定部１７により設定されたリスト作成条件とに基づいて、テスト対象として選択したテストデータのテストケース名を記述したテスト用リストを作成する。本実施の形態では、リストを生成するリスト生成部の一例として、また、データを選択する選択部の一例として、リスト作成部１８を設けている。
リスト記憶部１９は、リスト作成部１８により作成されたテスト用リストを記憶する。

次に、本実施の形態におけるテスト実行装置１０の動作について詳細に説明する。
動作が開始すると、テスト実行装置１０は、まず、全てのＣＡＤデータを用いて一通りテストを行う。例えば、５００００件のＣＡＤデータがあり、このうち３０００件を用いてテストしたい場合であっても、準備段階として５００００件を用いてテストする。即ち、テストデータ追加部１２は、この５００００件のＣＡＤデータをテストデータとしてテストケース名と共にテストデータ記憶部１１に追加する。

これにより、１回目のリリースのＣＡＤソフトについての動作が行われる。
即ち、まず、テスト実行部１４が、テストデータ記憶部１１に記憶された５００００件のテストデータを用いて、１回目のリリースのＣＡＤソフトをテストし、テストケース名に対応付けてテスト結果を出力する。具体的には、テストデータにおける形状と、１回目のリリースのＣＡＤソフトによりテストデータを変換した後の形状データにおける形状との差分を求め、差分が許容誤差内に収まっていればテスト結果として「パス」を、差分が許容誤差内に収まっていなければテスト結果として「フェイル」を出力する。このとき、テスト実行部１４は、テストケース名に対応付けてテスト時間も出力する。

次に、テスト結果分析部１５は、テスト実行部１４によりテストケース名に対応付けて出力されたテスト結果を、テスト結果記憶部１６にそのテストケース名に対応するテスト結果履歴として記憶すると共に、テスト実行部１４によりテストケース名に対応付けて出力されたテスト時間を、テスト結果記憶部１６にそのテストケース名に対応するテスト時間情報として記憶する。具体的には、この時点では、テスト結果記憶部１６にそのテストケース名に対応するテスト結果履歴及びテスト時間情報は記憶されていないので、テスト実行部１４により出力されたテスト結果及びテスト時間をそのままテスト結果履歴及びテスト時間情報として記憶する。

次いで、リスト作成部１８は、テスト結果記憶部１６に記憶されたテストケースのうち、リスト作成条件設定部１７により設定された数の制限及びテスト時間の制限を超えない範囲でテストケースを選択し、この選択したテストケースのテストケース名を記述したテスト用リストを作成する。そして、作成したテスト用リストをリスト記憶部１９に記憶する。

その後、２回目のリリースのＣＡＤソフトについての動作が行われる。
即ち、まず、テスト実行部１４が、テストデータ記憶部１１に記憶された５００００件のテストデータのうち、リスト記憶部１９に記憶されたテスト用リストに記述されたテストケース名のテストデータを用いて、２回目のリリースのＣＡＤソフトをテストし、テストケース名に対応付けてテスト結果及びテスト時間を出力する。尚、テストデータ追加部１２によりテストデータ記憶部１１にテストデータが追加された場合は、その追加されたテストデータも用いて、このような処理を行う。

次に、テスト結果分析部１５は、テスト実行部１４によりテストケース名に対応付けて出力されたテスト結果を、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト結果履歴に含めて記憶すると共に、テスト実行部１４によりテストケース名に対応付けて出力されたテスト時間に基づいて、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト時間情報を更新する。

尚、リスト作成部１８は、３回目のリリースのＣＡＤソフトのテストでも今回のテストで用いたテストデータをそのまま用いることから、新たにテスト用リストを作成する処理を行わない。

その後、３回目から（Ｎ−１）回目までのリリースのＣＡＤソフトについても同様の動作が繰り返される。
ここで、このときのテスト結果記憶部１６の記憶内容について説明する。
図２は、テスト結果記憶部１６の記憶内容の一例を示した図である。尚、ここでは、Ｎ＝１０としている。
図示するように、テスト結果記憶部１６には、テストケース名に対応付けて、テスト結果履歴及びテスト時間情報が記憶されている。このうち、テスト結果履歴としては、１回目から９回目までの各リリースに対して、リリース番号及びテスト結果が記憶されている。括弧内で、左側の要素がリリース番号を示し、右側の要素がテスト結果を示す。「Ｐ」は「パス」で、「Ｆ」は「フェイル」を意味する。尚、この段階では、グループ識別子の生成、テスト結果安定性指数及びモジュール安定性指数の算出は行われていないので、これらの欄は空欄になっている。

その後、Ｎ回目のリリースのＣＡＤソフトについての動作が行われる。
即ち、まず、テスト実行部１４が、テストデータ記憶部１１に記憶された５００００件のテストデータのうち、リスト記憶部１９に記憶されたテスト用リストに記述されたテストケース名のテストデータを用いて、Ｎ回目のリリースのＣＡＤソフトをテストし、テストケース名に対応付けてテスト結果及びテスト時間を出力する。

次に、テスト結果分析部１５は、テスト実行部１４により出力されたテスト結果と、テスト結果記憶部１６に記憶されたテスト結果履歴とに基づいて、テスト結果分析処理を行う。

以下、このテスト結果分析処理について詳細に説明する。
第一に、テスト結果分析部１５は、テストケースグループ決定処理を行う。
このテストケースグループ決定処理は、各テストケースを文字列に変換することにより、各テストケースが属するグループを決定する処理である。

図３は、このテストケースグループ決定処理の概要について示した図である。
図には、テストケースＡ〜Ｅを用いてリリース１．１〜４．０のＣＡＤソフトをテストしたときのテスト結果と、テストケースＡ〜Ｅが属するグループのグループ識別子とを示している。また、リリースごとのリリース日時も示している。ここで、リリースごとのテスト結果としては、「パス」を「○」で、「フェイル」を「×」で、「未実施」を空白で表している。また、グループ識別子は、テスト結果における「パス」を「１」、「フェイル」を「０」、「未実施」を「２」とすることで表される文字列である。尚、上記では、１回目のリリースのＣＡＤソフトのテストで全てのテストデータを対象とするので、未実施のテストケースはあり得ないが、これはあくまで例であるので、未実施のテストケースも示している。

テスト結果分析部１５は、テストケースに対するグループ識別子が同じ場合に、そのテストケースが属するグループを同じグループとする。図では、テストケースＣ及びテストケースＤに対するグループ識別子が「０００００１１１１１」で同じであるので、これらのテストケースは同じグループに属することになる。このように各テストケースが属するグループが決定された後、各グループでテストケースの集約が検討されることになる。
尚、本実施の形態では、複数のテストケースに対するグループ識別子が同一の場合にそれらのテストケースが同じグループに属するものとして説明するが、複数のテストケースに対するグループ識別子が類似する場合、例えば、グループ識別子の各文字の差分の二乗和が閾値以内である場合に、それらのテストケースが同じグループに属するものとしてもよい。

第二に、テスト結果分析部１５は、テストケース優先度決定処理を行う。
このテストケース優先度決定処理は、テストケースを集約する際に、不安定な又は重点的なテストの実施が必要なテストケースに高い優先度を与える処理である。これにより、このようなテストケースが優先的に残されるので、網羅性の高いテストケース選択が実現される。尚、このテストケース優先度決定処理は、テストで用いるテストケースとＣＡＤソフト内のモジュールとの相関関係が不明である、又は、そのような相関関係を調査するのに多大な労力を必要とする、ということを条件に行われる。

具体的には、テスト結果分析部１５は、テストケースごとのテスト結果履歴からテストケースの安定性を把握する。その際、テストケースごとのテスト結果履歴において着目する情報としては、現時点でのテスト結果の安定性に加え、テストの対象となるモジュールの安定性がある。たとえ現在のテスト結果がある程度良好であっても、機能変更が頻繁なモジュールについては、より優先度を高くしてテストを実施する必要があるからである。
そこで、テスト結果分析部１５は、テストケースの安定性の判断において、テスト結果安定性指数、モジュール安定性指数という２つの指数を算出する。

（１）テスト結果安定性指数
図４は、テスト結果安定性指数を算出するときの手順を示した図である。
（ａ）には、テストケースＡ〜Ｃを用いてリリース１．１〜４．０のＣＡＤソフトをテストしたときのテスト結果と、現在まで継続してテスト結果が「パス」だったリリース日時を示すパス日時とを示している。尚、図中のテスト結果のうち、リリース１．１〜３．０に対するテスト結果が、テスト結果記憶部１６に記憶されていたものであり、リリース４．０に対するテスト結果が、テスト実行部１４により出力されたものである。

（ｂ）では、（ａ）のテスト結果「○」、「×」を、テスト結果が継続して「パス」である日数を示すパス継続数に置き換えている。つまり、リリース１．１に対しては、テスト結果が「○」であれば、パス継続数を「１」とし、テスト結果が「×」であれば、パス継続数を「０」とする。また、それ以降のリリースに対しては、テスト結果が「○」であれば、パス継続数を１つ前のリリースに対するパス継続数に１を加算した値とし、テスト結果が「×」であれば、パス継続数を「０」とする。これにより、リリース４．０に対するパス継続数が、現時点におけるテスト結果の安定性を表すことになり、その値は、テストケースＡについては「１０」、テストケースＢについては「５」、テストケースＣについては「５」となる。尚、本実施の形態では、パス継続数を、現在まで継続してテスト結果が「パス」であった日数として説明するが、現在まで継続してテスト結果が「パス」であった回数としてもよい。

但し、これでは、テストケースＡのリリース２．１のときのようにそれまでのテスト結果が全て「パス」であった場合も、テストケースＢのリリース４．０のときのようにそれまでのテスト結果に「フェイル」があった場合も、安定性を表す値は同じ「５」となってしまう。そこで、本実施の形態では、パス継続数を正規化して、テスト結果安定性指数を算出する。

（ｃ）に、パス継続数を正規化したときの結果を示す。
具体的には、（ｂ）のあるリリースに対するパス継続数を、そのリリースまでのリリース数で除することにより、０から１の間のテスト結果安定性指数を算出する。
例えば、現時点、つまり、１０回目のリリースでのテスト結果安定性指数は、テストケースＡについては１（＝１０／１０）、テストケースＢについては０．５（＝５／１０）、テストケースＣについては０．５（＝５／１０）となる。

尚、テスト結果安定性指数は、以降の説明においても、あるリリースから最新のリリースまでのパス継続数に基づいて算出するものとするが、その他の方法で算出するものとしてもよい。
例えば、あるリリースから最新のリリースではない任意のリリースまでのパス継続数に基づいて算出するものとしてもよい。
また、テスト結果が連続して「パス」であった数に基づくのでなく、単にテスト結果が「パス」であった数に基づいて、より一般化して言えば、成功を示すテスト結果の出現状況に基づいて、算出するものとしてもよい。

（２）モジュール安定性指数
図５は、モジュール安定性指数を算出するときの手順を示した図である。
（ａ）には、テストケースＡ〜Ｃを用いてリリース１．１〜４．０のＣＡＤソフトをテストしたときのテスト結果を示している。

（ｂ）では、（ａ）のテスト結果「○」、「×」を、テスト結果の変動の有無を示す変動データに置き換えている。テスト結果「パス」が続く長さが同じであっても、より安定したモジュールに関連したテストケースを優先して集約することが望ましい。そのため、テスト結果に基づいて「パス」及び「フェイル」が変動したパターンを求める。ここでは、テスト結果が１つ前のリリースに対するテスト結果と同じであれば、変動データを「１」とし、テスト結果が１つ前のリリースに対するテスト結果と異なっていれば、変動データを「０」としている。

ところで、このようなテスト結果の変動は、現時点に近い時点での変動の方が、現時点から遠い時点での変動よりも、テストケース選択における重要度が高いと言える。
従って、リリース日時が現在日時に近いほど重みを大きくする重み付け関数を設定し、重み付け関数で求められる各リリース日時に対する重みを各リリース日時における変動データに乗じて得られる値の和をモジュール安定性指数とする。

図６は、このような重み付け関数の一例を示したグラフである。
このグラフにおいて、横軸ｔは、現在日時とリリース日時との差分であり、縦軸Ｆ（ｔ）は、現在日時とリリース日時との差分がｔである場合の重みである。
モジュール安定性指数Ｍは、現在日時とリリース日時との差分がｔである場合の変動データをＶ（ｔ）とすると、「Ｍ＝ΣＦ（ｔ）×Ｖ（ｔ）」により算出される。

ここで、例えば、リリースの回数をＲとし、Ｆ（ｔ）＝（Ｒ−ｔ）／Σｔとする。図５の例では、Ｒ＝１０、Σｔ＝１＋２＋３＋４＋・・・＋１０＝５５であるので、Ｆ（ｔ）＝（１０−ｔ）／５５となる。
従って、モジュール安定性指数は、テストケースＡについては、１（＝（１／５５）×１＋（２／５５）×１＋（３／５５）×１＋（４／５５）×１＋（５／５５）×１＋（６／５５）×１＋（７／５５）×１＋（８／５５）×１＋（９／５５）×１＋（１０／５５）×１）となる。また、テストケースＢについては、０．８（＝（１／５５）×１＋（２／５５）×１＋（３／５５）×１＋（４／５５）×１＋（５／５５）×０＋（６／５５）×０＋（７／５５）×１＋（８／５５）×１＋（９／５５）×１＋（１０／５５）×１）となる。更に、テストケースＣについては、０．８９（＝（１／５５）×１＋（２／５５）×１＋（３／５５）×１＋（４／５５）×１＋（５／５５）×１＋（６／５５）×０＋（７／５５）×１＋（８／５５）×１＋（９／５５）×１＋（１０／５５）×１）となる。

尚、モジュール安定性指数は、以降の説明においても、各リリースに対する変動データに各リリースの新しさに応じた重みを付加した結果を加算することによって算出するものとするが、その他の方法で算出するものとしてもよい。
例えば、各リリースの新しさに応じた重みは付加することなく、単に変動データ「１」の数に基づいて、より一般化して言えば、テスト結果の変動状況に基づいて、算出するものとしてもよい。

次いで、このようなテスト結果分析処理を行うテスト結果分析部１５の動作について、フローチャートを参照して説明する。
図７は、Ｎ回目のリリースのＣＡＤソフトについてのテスト結果分析部１５の動作例を示したフローチャートである。尚、１回目から（Ｎ−１）回目までのリリースのＣＡＤソフトについての動作をこのフローチャートに含める場合は、フローチャートの先頭に、何回目のリリースのＣＡＤソフトについての動作であるかを判断するステップを設けるとよい。そして、そのステップで１回目から（Ｎ−１）回目までのリリースのＣＡＤソフトについての動作であると判断されれば、テスト実行部１４により出力されたテスト結果及びテスト時間をテスト結果記憶部１６に記憶する処理のみを行い、そのステップでＮ回目のリリースのＣＡＤソフトについての動作であると判断されれば、図示した処理を行うようにするとよい。

さて、動作を開始すると、テスト結果分析部１５は、まず、テスト実行部１４から出力されたデータの中に未処理のデータがあるかどうかを判定する（ステップ１０１）。未処理のデータがないと判定されれば、そのまま処理を終了するが、未処理のデータがあると判定されれば、そのデータの中から、テストケース名、テスト結果、テスト時間の１つの組を取り出す（ステップ１０２）。

次に、テスト結果分析部１５は、テスト結果記憶部１６にそのテストケース名に対応付けて記憶されたテスト結果履歴を読み出す（ステップ１０３）。
そして、テスト結果分析部１５は、ステップ１０２で取り出したテスト結果とステップ１０３で読み出したテスト結果履歴とに基づいて、グループ識別子を生成する（ステップ１０４）。具体的には、まず、ステップ１０３で読み出したテスト結果履歴を分析し、テスト結果「パス」を文字「１」に変換し、テスト結果「フェイル」を文字「０」に変換することで、文字列を生成する。そして、ステップ１０２で取り出したテスト結果を参照し、テスト結果が「パス」であればその文字列の後ろに文字「１」を付加し、テスト結果が「フェイル」であればその文字列の後ろに文字「０」を付加することで、グループ識別子を生成する。

また、テスト結果分析部１５は、ステップ１０２で取り出したテスト結果とステップ１０３で読み出したテスト結果履歴とに基づいて、テスト結果安定性指数を算出する（ステップ１０５）。具体的には、まず、ステップ１０２で取り出したテスト結果を参照し、テスト結果が「パス」であればパス継続数を「１」とし、テスト結果が「フェイル」であればパス継続数を「０」とする。また、パス継続数が「１」であれば、ステップ１０３で読み出したテスト結果履歴を分析し、前回のリリースに対するテスト結果からの連続する「パス」の数をパス継続数に加算する。そして、この時点におけるパス継続数を今回のリリースまでのリリース回数で除することで、テスト結果安定性指数を算出する。

更に、テスト結果分析部１５は、ステップ１０２で取り出したテスト結果とステップ１０３で読み出したテスト結果履歴とに基づいて、モジュール安定性指数を算出する（ステップ１０６）。具体的には、まず、ステップ１０３で読み出したテスト結果履歴を分析し、１回目のリリースに対する変動データを「１」とし、２回目から前回までのリリースに対する変動データを、テスト結果が１つ前のテスト結果と同じであれば「１」とし、テスト結果が１つ前のテスト結果と異なれば「０」とする。また、ステップ１０２で取り出したテスト結果を参照し、今回のリリースに対する変動データを、テスト結果が前回のテスト結果と同じであれば「１」とし、テスト結果が前回のテスト結果と異なれば「０」とする。そして、各リリースに対する変動データに、図６のような重み付け関数でｔを各リリースのリリース日時と今回のリリースのリリース日時との差分としたときのＦ（ｔ）を乗じ、その結果の値を足し合わせることで、モジュール安定性指数を算出する。ここで、各リリースのリリース日時は、図２に示したようにテスト結果履歴内に記憶されていないのであれば、ＣＡＤソフトのリリースを管理するデータベースからリリース番号をキーに取得するとよい。或いは、テスト結果履歴内に記憶しておき、そこから取得するようにしてもよい。

これにより、テスト結果分析部１５は、テスト結果記憶部１６に、ステップ１０２で取り出したテストケース名に対応付けて、グループ識別子、テスト結果安定性指数、モジュール安定性指数を記憶する（ステップ１０７）。このとき、グループ識別子、テスト結果安定性指数、モジュール安定性指数が既に記憶されていれば、これらを新たなグループ識別子、テスト結果安定性指数、モジュール安定性指数で上書きする。

次いで、テスト結果分析部１５は、ステップ１０２で取り出したテスト結果を、ステップ１０２で取り出したテストケース名に対応付けてテスト結果記憶部１６に記憶されたテスト結果履歴に含めて、記憶する（ステップ１０８）。
また、テスト結果分析部１５は、ステップ１０２で取り出したテスト時間に基づいて、ステップ１０２で取り出したテストケース名に対応付けてテスト結果記憶部１６に記憶されたテスト時間情報を更新する（ステップ１０９）。
その後、処理はステップ１０１に戻り、未処理のデータがないと判定されるまで、ステップ１０２〜１０９の処理を繰り返す。

ここで、このときのテスト結果記憶部１６の記憶内容について説明する。
図８は、テスト結果記憶部１６の記憶内容の一例を示した図である。尚、ここでも、Ｎ＝１０としている。
図示するように、テスト結果記憶部１６には、テストケース名に対応付けて、テスト結果履歴及びテスト時間情報が記憶されている。このうち、テスト結果履歴としては、１回目から１０回目までの各リリースに対して、リリース番号及びテスト結果が記憶されている。また、テストケース名に対応付けて、グループ識別子、テスト結果安定性指数、モジュール安定性指数も記憶されている。

次に、リスト作成部１８は、テスト結果記憶部１６に記憶された情報に基づいて、テストケースを集約して新たなテスト用リストを作成するテスト用リスト作成処理を行う。具体的には、テスト結果記憶部１６に記憶されたグループ識別子のグループのうち、テスト結果安定性指数及びモジュール安定性指数が閾値を超えるグループ内のテストケースを集約する。その際、グループに属するテストケースからテスト時間に基づいて１つのテストケースを選択する。例えば、グループに属するテストケースのうち、テスト時間が大きいものを優先的に除外する。

図９は、このようなテストケースの集約について示した図である。
図には、まず、２４４３件のテストデータを用いてテストを行ったときのグループ識別子ごとに、テスト結果安定性指数、モジュール安定性指数、テストケースの件数（図では単に「件数」と表記）を示している。
ここで、第１閾値が０．３５であり、第２閾値が０．８である場合を考える。即ち、あるグループにおいて、テスト結果安定性指数が０．３５を超えており、かつ、モジュール安定性指数が０．８を超えていれば、そのグループ内のテストケースを集約するものとする。図では、テスト結果安定性指数が０．３５を超えており、かつ、モジュール安定性指数が０．８を超えているグループに対して、判定結果「ＴＲＵＥ」を示し、それ以外のグループに対して、判定結果「ＦＡＬＳＥ」を示している。判定結果が「ＴＲＵＥ」のグループについて、テストケースを集約することになるが、件数が「１」の場合はこれ以上集約できないので、件数が「２」以上のグループについて集約する。即ち、件数が「２」以上で判定結果が「ＴＲＵＥ」のグループ（図中、太線囲みで示す）に属するテストケースは１つを除いてテスト用リストに含める対象から除外する。

尚、テスト結果安定性指数及びモジュール安定性指数の両方が「１」であるグループについては、テスト結果は安定しているが、そのグループに属するテストケースが同じモジュールに関連するものと推測し難いため、本実施の形態では、テストケースの集約を行わない。
また、テスト結果安定性指数が「０」でモジュール安定性指数が「１」であるグループについては、テスト結果が全て「フェイル」ということだけを表すものであるので、本実施の形態では、テストケースの集約を行わない。
図では、各グループに対して、このような集約を行った後のテストケースの件数（図では単に「集約後」と表記）も示している。全体では、２４４３件のテストケースが、集約後は２２２６件となり、約８．９％のテストケースが削減されている。

次いで、このようなテスト用リスト作成処理を行うリスト作成部１８の動作について、フローチャートを参照して説明する。
図１０は、Ｎ回目のリリースのＣＡＤソフトについてのリスト作成部１８の動作例を示したフローチャートである。尚、１回目から（Ｎ−１）回目までのリリースのＣＡＤソフトについての動作をこのフローチャートに含める場合は、フローチャートの先頭に、何回目のリリースのＣＡＤソフトについての動作であるかを判断するステップを設けるとよい。そして、そのステップで１回目のリリースのＣＡＤソフトについての動作であると判断されれば、リスト作成条件設定部１７により設定されたテストケース数及びテスト時間の制限内のテストケースを記述したテスト用リストを作成する処理のみを行い、そのステップで２回目から（Ｎ−１）回目までのリリースのＣＡＤソフトについての動作であると判断されれば、全ての処理をスキップし、そのステップでＮ回目のリリースのＣＡＤソフトについての動作であると判断されれば、図示した処理を行うようにするとよい。

さて、動作を開始すると、リスト作成部１８は、リスト作成条件設定部１７により設定されたテスト結果安定性指数の閾値である第１閾値及びモジュール安定性指数の閾値である第２閾値を取得する（ステップ１５１）。
また、リスト作成部１８は、テスト結果記憶部１６に記憶されたデータを、一時的にグループごとにまとめる処理を行う（ステップ１５２）。具体的には、同じグループ識別子に対応付けられたテストケースのデータをまとめる。
そして、リスト作成部１８は、テスト結果記憶部１６に記憶されたグループの中に、未処理のグループがあるかどうかを判定する（ステップ１５３）。未処理のグループがあると判定されれば、そのグループの中から、１つグループのデータを読み出す（ステップ１５４）。

次に、リスト作成部１８は、読み出したグループのデータに含まれるテストケースが１つであるかどうかを判定する（ステップ１５５）。テストケースが１つであると判定されれば、そのテストケースは集約対象とならないので、読み出したデータをそのままメモリに記憶する（ステップ１６０）。

テストケースが１つでないと判定されれば、リスト作成部１８は、読み出したグループのデータにおけるモジュール安定性指数が「１」であるかどうかを判定する（ステップ１５６）。モジュール安定性指数が「１」であると判定されれば、このグループに属するテストケースのテスト結果はずっと同じであり、テスト結果からはテストケースを集約できると言えないので、読み出したデータをそのままメモリに記憶する（ステップ１６０）。

モジュール安定性指数が「１」でないと判定されれば、リスト作成部１８は、読み出したグループのデータにおけるテスト結果安定性指数が、ステップ１５１で取得した第１閾値を超えているかどうかを判定する（ステップ１５７）。テスト結果安定性指数が第１閾値を超えていないと判定されれば、このグループに属するテストケースのテスト結果は安定しておらず、テストケースを集約できないので、読み出したデータをそのままメモリに記憶する（ステップ１６０）。

テスト結果安定性指数が第１閾値を超えていると判定されれば、リスト作成部１８は、読み出したグループのデータにおけるモジュール安定性指数が、ステップ１５１で取得した第２閾値を超えているかどうかを判定する（ステップ１５８）。モジュール安定性指数が第２閾値を超えていないと判定されれば、このグループに属するテストケースに関連するモジュールは頻繁に変更されており、テストケースを集約できないので、読み出したデータをそのままメモリに記憶する（ステップ１６０）。

モジュール安定性指数が第２閾値を超えていると判定されれば、リスト作成部１８は、読み出したグループのデータに含まれるテストケースのうち、テスト時間が最も短いもののみを残してそれ以外は除去し、その結果のデータをメモリに記憶する（ステップ１５９）。

その後、処理はステップ１５３に戻り、未処理のグループがないと判定されるまで、ステップ１５４〜１６０の処理を繰り返す。
そして、ステップ１５３で未処理のグループがないと判定されれば、リスト作成部１８は、ステップ１５９又はステップ１６０でメモリに記憶されたデータ内のテストケース名を記述したテスト用リストを作成し、リスト記憶部１９に記憶する（ステップ１６１）。

尚、この動作例では、あるグループについて、モジュール安定性指数が「１」でないという第１の条件、テスト結果安定性指数が第１閾値を超えているという第２の条件、及び、モジュール安定性指数が第２閾値を超えているという第３の条件が全て満たされた場合に、そのグループ内のテストケースを集約するようにしたが、この限りではない。
例えば、第１の条件は、このテスト用リスト作成処理で判断する条件から除外してもよい。
また、第２の条件及び第３の条件は、両方が満たされることを要求するのではなく、何れか一方のみが満たされることを要求するものでもよい。
更に、第２の条件及び第３の条件は、独立の条件とするのではなく、「テストケース重要度＝第１重み係数×テスト結果安定性指数＋第２重み係数×モジュール安定性指数」により算出されるテストケース重要度が閾値を超えている、という１つの条件にまとめてもよい。

また、この動作例では、リスト作成部１８は、グループのデータが条件を満たす場合にそのグループ内の残すテストケース以外のテストケースを除去するのみであった。しかしながら、除去したテストケースの代わりに、別途テストしてテスト結果が「フェイル」であったテストケースや、新しい機能や重要な箇所に関連するテストケースを追加するようにしてもよい。但し、この場合も、リスト作成条件設定部１７により設定されたテストケース数及びテスト時間の制限内に収まるようにテストデータを追加するのが望ましい。
加えて、その際、リスト作成条件設定部１７により設定されたテスト時間の制限までどの程度の余裕があるかを知らせるために、テスト用リストに含まれる全てのテストケースに基づくテストを行った場合の想定合計時間を算出するようにしてもよい。
以上により、Ｎ回目のリリースのＣＡＤソフトについての動作の説明を終了する。

そして、その後、（Ｎ＋１）回目以降のリリースのＣＡＤソフトについても同様の動作が繰り返される。

このように、本実施の形態では、ユーザの過去の障害履歴に基づいたテストケースの実行結果（リリース及びテスト結果）を保存するデータベースを設けた。そして、このデータベースに保存されたデータに基づいてテストケースに自動的に優先順位を付与し、これによってテストケースの適用条件を決定するようにした。
具体的には、第一に、ユーザの過去の障害履歴に基づいたテストケースの実行結果間の相関関係に着目し、この相関関係に基づいて、テストケースが利用するモジュール及び機能を類推する。つまり、複数のテストケースに基づくテスト結果の一致度を算出し、一致度が閾値以上となった場合に、これら複数のテストケースは同一モジュールに関連するものであると判断して集約する。
第二に、ユーザの過去の障害履歴に基づいたテストケースに基づくリリースごとのテスト結果の時系列の出現パターンに着目し、各テストケースにおけるリリース及びテスト結果に基づいて、テストケースに紐付いたモジュールの安定性を示す指数を算出し、指数が閾値以上となった場合に、そのテストケースは安定した状態であると判断して集約する。

そして、このような処理を行う本実施の形態によれば、限定された制約の下で、最適なテストケースを選択し、最適化されたテストを実行することが可能となる。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１１は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ（Central Processing Unit）９０ａと、Ｍ／Ｂ（マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図１１において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

１０…テスト実行装置、１１…テストデータ記憶部、１２…テストデータ追加部、１３…テスト条件設定部、１４…テスト実行部、１５…テスト結果分析部、１６…テスト結果記憶部、１７…リスト作成条件設定部、１８…リスト作成部、１９…リスト記憶部

Claims (10)

1. ソフトウェアの複数のバージョンの動作をテストする装置であって、
   複数のデータの各データと、当該各データを識別するデータ識別情報とを対応付けて記憶する記憶部と、
   前記複数のデータの各データを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列と、当該各データを識別するデータ識別情報とを対応付けたテスト結果情報を取得する取得部と、
   前記複数のデータをグループ化して得られる複数のグループであって各グループに属するデータを識別するデータ識別情報に前記テスト結果情報において対応付けられた前記テスト結果列が同一又は類似である複数のグループの当該各グループを、当該テスト結果列によって識別するグループ識別情報と、当該各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を、当該テスト結果列における連続して成功を示すテスト結果の多さによって示すテスト結果安定性情報と、当該各グループに属するデータを用いてテストされる前記ソフトウェアのモジュールの安定性を、当該テスト結果列におけるテスト結果の変動の少なさによって示すモジュール安定性情報と、当該各グループに属するデータを識別するデータ識別情報とを対応付けたグループ情報を生成するグループ情報生成部と、
   前記複数のグループの各グループを識別するグループ識別情報に前記グループ情報において少なくとも２つのデータ識別情報が対応付けられており、当該グループ識別情報に当該グループ情報において対応付けられた前記テスト結果安定性情報が予め定めた第１の基準を超える安定性を示しており、当該グループ識別情報に当該グループ情報において対応付けられた前記モジュール安定性情報が予め定めた第２の基準を超える安定性を示しているが前記テスト結果列におけるテスト結果の変動が１回以上あることを示している場合に、当該各グループに属するデータを識別するデータ識別情報として当該少なくとも２つのデータ識別情報のうちの特定のデータ識別情報を含み当該特定のデータ識別情報以外は含まないリストを生成するリスト生成部と、
   前記複数のグループの各グループに属するデータとして、前記リスト生成部により生成された前記リストに当該各グループに属するデータを識別するデータ識別情報として含まれる前記特定のデータ識別情報に対応付けて前記記憶部に記憶されたデータを用いて、前記ソフトウェアの新たなバージョンのテストを実行するテスト実行部と
   を含む、装置。
2. ソフトウェアの複数のバージョンの動作をテストする装置であって、
   複数のデータの各データについて、当該各データを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得する取得部と、
   前記複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて前記取得部により取得された前記テスト結果列が同一又は類似である複数のグループの当該各グループについて、当該各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成する生成部と、
   前記複数のグループの少なくとも２つのデータが属する各グループについて前記生成部により生成された前記テスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、当該少なくとも２つのデータから前記ソフトウェアの動作をテストする際に用いるデータを選択する選択部と
   を含む、装置。
3. 前記生成部は、前記複数のグループの各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列における成功を示すテスト結果の出現状況に基づいて、前記テスト結果安定性情報を生成する、請求項２の装置。
4. 前記生成部は、前記複数のグループの各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列において、当該複数のバージョンのうちの最新のバージョンから遡って連続するバージョンの動作をテストしたときのテスト結果が成功を示し続ける長さが長いほど、高い安定性を示す前記テスト結果安定性情報を生成する、請求項２又は請求項３の装置。
5. 前記生成部は、前記複数のグループの各グループに属するデータを用いてテストされる前記ソフトウェアのモジュールの安定性を示すモジュール安定性情報を更に生成し、
   前記選択部は、前記少なくとも２つのデータが属する各グループについて前記生成部により生成された前記モジュール安定性情報が予め定めた基準を超える安定性を示している場合に、当該少なくとも２つのデータから前記ソフトウェアの動作をテストする際に用いるデータを選択する、請求項２の装置。
6. 前記生成部は、前記複数のグループの各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列におけるテスト結果の変動状況に基づいて、前記モジュール安定性情報を生成する、請求項５の装置。
7. 前記生成部は、前記複数のグループの各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列において、当該複数のバージョンの各バージョンの動作をテストしたときのテスト結果の変動に当該各バージョンの新しさに応じた重みを付加して加算することで得られた変動の度合いが低いほど、高い安定性を示す前記モジュール安定性情報を生成する、請求項５又は請求項６の装置。
8. 前記選択部は、前記少なくとも２つのデータの各データを用いて前記ソフトウェアの動作をテストするのに要する時間に基づいて、当該少なくとも２つのデータから前記ソフトウェアの動作をテストする際に用いるデータを選択する、請求項２乃至請求項７の何れかの装置。
9. ソフトウェアの複数のバージョンの動作をテストする方法であって、
   複数のデータの各データについて、当該各データを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得するステップと、
   前記複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて取得された前記テスト結果列が同一又は類似である複数のグループの当該各グループについて、当該各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成するステップと、
   前記複数のグループの少なくとも２つのデータが属する各グループについて生成された前記テスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、当該少なくとも２つのデータから前記ソフトウェアの動作をテストする際に用いるデータを選択するステップと
   を含む、方法。
10. ソフトウェアの複数のバージョンの動作をテストする装置としてコンピュータを機能させるプログラムであって、
    前記コンピュータを、
    複数のデータの各データについて、当該各データを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果列を取得する取得部と、
    前記複数のデータをグループ化して得られる複数のグループであって各グループに属するデータについて前記取得部により取得された前記テスト結果列が同一又は類似である複数のグループの当該各グループについて、当該各グループに属するデータを用いて前記ソフトウェアの複数のバージョンの動作をテストしたときのテスト結果の安定性を示すテスト結果安定性情報を生成する生成部と、
    前記複数のグループの少なくとも２つのデータが属する各グループについて前記生成部により生成された前記テスト結果安定性情報が予め定めた基準を超える安定性を示している場合に、当該少なくとも２つのデータから前記ソフトウェアの動作をテストする際に用いるデータを選択する選択部と
    して機能させる、プログラム。

Images