(57)【特許請求の範囲】
【請求項１】
テスト項目を特定する情報と、当該テスト項目の実行対象のソフトウエアのバージョンを示す情報と、前記バージョンに対する当該テスト項目の実行の結果であるテスト結果とを有するテスト結果データから、一つのテスト項目を各バージョンのソフトウエアに実施したテスト結果の変化の有無を表す情報を有するテスト結果変化データを生成する生成手段と、
前記テスト結果変化データに基づいて、テスト項目間の類似度を算出する算出手段と、
前記類似度に基づいて関連テスト項目を抽出する抽出手段と
を有する関連テスト項目提示装置。
【請求項２】
前記算出手段は、前記テスト結果変化データから２つのテスト項目間について存在する同タイミング変化パターンの個数に基づいて、類似度を算出する請求項１の関連テスト項目提示装置。
【請求項３】
前記算出手段は、テスト結果変化データのそれぞれのレコードを、対応するテスト項目のベクトルとして扱い、２つのテスト項目のベクトルのコサイン類似度を計算し、得られた値を当該２つのテスト項目の類似度とする、請求項１の関連テスト項目提示装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に記載の実施の形態は、関連テスト項目提示装置に関する。
【背景技術】
【０００２】
近年、製品の高性能・高機能化に伴い、ソフトウエアは急激に大規模・複雑化している。そのため、ソフトウエアの品質を確認するために実施するテスト項目が増加し、テストにかかる工数が増加している
【０００３】
一方で、短期間での市場への製品リリースが求められていることから、開発期間の短縮が重要な課題となっている。
【０００４】
短期間でソフトウエアの品質を確保するために、ソフトウエアに潜在する不具合を効率的に発見することが求められており、テスト項目の選択の重要性は高まっている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−１０２４７５号公報
【特許文献２】特開２００１−１６０９５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、開発期間の短縮により、リグレッションテストのたびに、膨大なテスト項目すべてを繰り返し実施するのは難しい。効率的にリグレッションテストを実施するには、優先して実施すべきテスト項目を的確に選択し、不具合修正の確認やデグレードの発見を迅速に行う必要があるが、従来の手法では、テスト担当者の勘と経験にたよって、重要な機能に関連するテスト項目、最近不具合が頻発していた機能に関連するテスト項目、変更箇所に関連している可能性のあるテスト項目、これまであまり実施していなかったテスト項目、などを優先して実施すべきテスト項目を選択しており、優先して実施すべきテスト項目を的確に選択するのに高いスキルが必要であった。
【０００７】
本発明は、テスト担当者の熟練度合いに左右されることなく、優先して実施すべきテスト項目を選択でき、且つ短期間でも不具合の修正確認やデグレードの発見を効率的に行うことができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一の実施の形態によれば、関連テスト項目提示装置が提案される。関連テスト項目提示装置は、生成手段と、算出手段と、抽出手段とを有する。生成手段は、テスト項目の実行の結果であるテスト結果とそのテスト項目とテスト項目の実行の対象のバージョンを示す情報を有するテスト結果データから、一つのテスト項目を各バージョンのソフトウエアに実施したテスト結果の変化の有無を表す情報を有するテスト結果変化データを生成する。算出手段は、前記テスト結果変化データに基づいて、テスト項目間の類似度を算出する。抽出手段は前記類似度に基づいて関連テスト項目を抽出する。
【図面の簡単な説明】
【０００９】
【図１】複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示す図
【図２】複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示す別の図
【図３】テスト項目、機能、モジュール、ソースコードの関連の例を示す図
【図４】図３の後のテスト項目、機能、モジュール、ソースコードの関連の例を示す図
【図５】複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示すさらに別の図
【図６】テスト項目、機能、モジュール、ソースコードの関連の例を示す図
【図７】図６の後のテスト項目、機能、モジュール、ソースコードの関連の例を示す図
【図８】（Ａ）は同タイミング変化パターンと扱わない、変化パターンを示す図、（Ｂ）は同タイミング変化パターンと扱わない、別の変化パターンを示す図、（Ｃ）は同タイミング変化パターンと扱わない、さらに別の変化パターンを示す図
【図９】テスト結果変化データの例を示す図
【図１０】関連テスト項目提示装置の構成例を示すブロック図
【図１１】テスト項目データのレコードのデータ構成例を示す図
【図１２】テスト結果データのレコードのデータ構成例を示す
【図１３】関連テスト項目提示処理の例を示したフローチャート
【図１４】テスト結果データの例を示す図
【図１５】テスト結果集約データのデータ構成例を示す図
【図１６】テスト結果集約データからテスト結果変化データを生成する処理を説明するための例を示す図
【図１７】図１６のテスト結果集約データから生成されたテスト結果変化データの例を示す図
【図１８】項目間類似度データの例を示す図
【図１９】関連テスト項目表示部によって表示される画面例を示す図
【図２０】図１９の画面においてテスト項目が選択された後に遷移する画面例を示す図
【図２１】項目間類似度データの例を示す図
【図２２】項目間類似データにおいて、方法１の抽出する基準を満たした数値を太字下線付きで表示した図
【図２３】図１９の画面においてテスト項目が選択された後に遷移する画面例を示す図
【発明を実施するための形態】
【００１０】
以下、添付の図面を参照しながら、本発明の実施の形態に係る関連テスト項目提示装置の例を説明する。
[０．用語の定義]
まず、本実施の形態において用いる用語の定義を述べる。
[０.１．テスト]
「テスト」とは、ソフトウエアの開発において、実装したソースコードが仕様通り動作するか否かを確認する作業をいう。
[０．２．不合格]
「不合格」とは、テストを実施した結果、動作結果がテストで期待する結果にならないことをいう。
[０．３．合格]
「合格」とは、テストを実施した結果、動作結果がテストで期待する結果となったことをいう。
[０．４．欠陥]
「欠陥」とは、ソースコードの誤りをいう。「バグ」も「欠陥」に含まれる。
[０．５．不具合]
「不具合」とは、ソフトウエアが期待通りに動作しない現象のこと
[０．６．デグレード]
「デグレード」とは、ソフトウエアの変更を行った後、一度テストに合格しているテスト項目を再度テストした際に、不合格になること
[０．７．テスト項目]
「テスト項目」とは、テストの実施の単位をいう。「テスト項目」が決定されると、どのような具体的内容のテストを実行するかが定まる。一つのテスト項目には、チェックポイントや実施手順、期待する値などを記録する。なお、本明細書中「テスト項目を実行（実施）する」とは、そのテスト項目に定められた内容のテストを実行することをいうものとする。
[０．８．テスト結果]
「テスト結果」は、テスト項目を実施した際の合格又は不合格を示す記録をいう。テスト結果は合格又は不合格のいずれかであり、他に日付やバージョンなどの情報も同時に記録される。
[０．９．バージョン]
「バージョン」とは、テスト対象のソフトウエアとテスト結果を対応付ける属性であって、当該ソフトウエアが何回改訂・更新されたものかを識別可能とする情報である。。バージョンを元に、どの構成でテストを実施しているか把握できる。ソフトウエアのビルドＮｏ（ナンバー）や、構成管理システムのリビジョンNo、マイルストーンごとにつけるタグ（β版やRC版）などをバージョンとする。
[０．１０．リグレッションテスト（回帰テスト）]
「リグレッションテスト」とは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するために行うテストをいう。ソースコードの欠陥を取り除いたことによって、代わりに新しい欠陥が埋め込まれていないか確認する。
【００１１】
[１．概要]
以下に本実施の形態の概要を述べる。  
本実施の形態では、登録されている複数のテスト項目の中から、リグレッションテストで実施するテスト項目（実施テスト項目）と関連している可能性が高いテスト項目（関連テスト項目）を抽出し、関連テスト項目を、他の登録されている複数のテスト項目に優先して実施すべきテスト項目として出力する。
【００１２】
関連テスト項目は、ソースコードの変更による影響を受けて、実施テスト項目と同時にテスト結果が変化する可能性があるテスト項目と想定されるテスト項目である。
【００１３】
本関連テスト項目提示装置は、一連のテスト結果の履歴データに基づいて、過去に実施テスト項目と同じタイミング（テスト対象のバージョンの変更）でテスト結果が変化したことがあるテスト項目群を関連テスト項目として抽出する。
テスト結果が、合格→不合格、或いは不合格→合格に変化するということは、ソースコードの変更による影響を受けているということである。
【００１４】
[１．１．複数のテスト項目のテスト結果の変化パターン]
以下に、本実施の形態において複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターン（「同タイミング変化パターン」と呼ぶ）について説明する。同タイミング変化パターンは、テスト項目が相互に関連テスト項目であるか否かを計算する基礎情報となる。
【００１５】
[１．１．１．変化パターン（１）]
本実施の形態において、同タイミング変化パターンの第１は、２つのテスト項目のテスト結果が同時に不合格から合格へ変化する、又は、合格から不合格へ変化する場合である。図１、図２に変化パターン（１）の例を示す。図１の例では、テスト項目ＡをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2についてについて実施した場合のテスト結果が「○(合格)」であるのに対して、テスト項目ＢをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2について実施した場合のテスト結果が「○(合格)」である。図２は、図１の逆のパターンである。
【００１６】
上記の同タイミング変化パターンが生ずる場合の、テスト項目、機能、モジュール、ソースコードの関係を説明する。図３は、テスト項目、機能、モジュール、ソースコードの関連の例を示す図である。
【００１７】
この例では、あるバージョンのソフトウエアについて、機能Ａ、機能Ｂ，機能Ｃがあり、これら機能Ａ，機能Ｂ，機能Ｃについて検証するためのテスト項目であるテスト項目Ａ、テスト項目Ｂ、テスト項目Ｃがある。
【００１８】
機能Ａを実現するために使用されるモジュールとして、モジュール１とモジュール２があり、機能Ｂを実現するために使用されるモジュールとして、モジュール２とモジュール３があり、機能Ｃを実現するために使用されるモジュールとして、モジュール４とモジュール５がある。モジュール２は機能Ａと機能Ｂに共通のモジュールである。
【００１９】
各モジュールは、1又は複数のサブモジュールで構成される。モジュール１は、ソースコードａに対応するサブモジュールとソースコードｂに対応するサブモジュールで構成される。モジュール２は、ソースコードｃに対応するサブモジュールとソースコードｄに対応するサブモジュールとソースコードｅに対応するサブモジュールで構成される。モジュール３は、ソースコードｅに対応するサブモジュールとソースコードｆに対応するサブモジュールで構成される。モジュール４は、ソースコードｇに対応するサブモジュールとソースコードｈに対応するサブモジュールで構成される。モジュール５は、ソースコードｉに対応するサブモジュールとソースコードｊに対応するサブモジュールで構成される。なお、本明細書では、説明の便宜上サブモジュールに代えてそのサブモジュールに対応するソースコードを用いて説明する。
【００２０】
さて、このソフトウエアについて、テスト項目Ａ、テスト項目Ｂ、テスト項目Ｃが実施された結果、機能Ａについて不具合がありテスト項目Ａのテスト結果は不合格となり、機能Ｂについて不具合がありテスト項目Ｂのテスト結果は不合格となり、機能Ｃについては不具合はなくテスト項目Ｃのテスト結果は合格となった。
ここで、機能Ａ、機能Ｂの不具合の原因はモジュール２にあり、そのソースコードｃに欠陥があったものとする。
【００２１】
次にソースコードｃの欠陥が修正されたソフトウエアの次バージョンが作成されたものとする。このソフトウエアの次バージョンについてテスト項目Ａ、テスト項目Ｂ、テスト項目Ｃが実施された結果、機能Ａについて不具合はなくテスト項目Ａのテスト結果は合格となり、機能Ｂについて不具合はなくテスト項目Ｂのテスト結果は合格となり、機能Ｃについては不具合はなくテスト項目Ｃのテスト結果も合格となった。かかる状態を図４に示す。
図３及び図４で示した例は、図１に示した同タイミング変化パターンに相当する。
【００２２】
[１．１．２．パターン（２）]
本実施の形態において、同タイミング変化パターンの第２は、あるテスト項目のテスト結果が不合格から合格へ変化したタイミングで、別のテスト項目のテスト結果が合格から不合格へ変化する場合である。図５に変化パターン（２）の例を示す。この例では、テスト項目ＡをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2について実施した場合のテスト結果が「○(合格)」であるのに対して、テスト項目ＢをバージョンV0.1について実施した場合のテスト結果が「○(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2についてについて実施した場合のテスト結果が「×(合格)」である。
【００２３】
上記の同タイミング変化パターンが生ずる場合の、テスト項目、機能、モジュール、ソースコードの関係を説明する。図６は、テスト項目、機能、モジュール、ソースコードの関連の例を示す図であって、ソフトウエアを構成するテスト項目、機能、モジュール、ソースコードは前述の図３、図４に示した例と同様である。
【００２４】
さて、このソフトウエアについて、テスト項目Ａ、テスト項目Ｂ、テスト項目Ｃが実施された結果、機能Ａについて不具合がありテスト項目Ａのテスト結果は不合格となり、機能Ｂについては不具合はなくテスト項目Ｂのテスト結果は合格となり、機能Ｃについては不具合はなくテスト項目Ｃのテスト結果は合格となった。
ここで、機能Ａの不具合の原因はモジュール２にあり、そのソースコードｃに欠陥があったものとする。但し、この欠陥は機能Ｂに影響しないものであった。
【００２５】
次にソースコードｃの欠陥が修正されたソフトウエアの次バージョンが作成されたものとする。しかし、ソースコードｃの欠陥修正の結果、別の新たな「欠陥’」がソースコードｃに内在し、この新たな欠陥は機能Ｂに影響するものであった。
【００２６】
このソフトウエアの次バージョンについてテスト項目Ａ、テスト項目Ｂ、テスト項目Ｃを実施すると、機能Ａについて不具合はなくテスト項目Ａのテスト結果は合格となり、機能Ｂについて不具合がありテスト項目Ｂのテスト結果は不合格となり、機能Ｃについては不具合はなくテスト項目Ｃのテスト結果は合格となった。かかる状態を図７に示す。
この図６及び図７で示した例は、前述の図５に示した同タイミング変化パターンに相当する。
【００２７】
[１．１．３．同じタイミングで変化したと捉えられない]
同じタイミングで変化したと捉えられないパターンについて説明する。一方のテスト項目のみテスト結果が変化し、他方のテスト項目のテスト結果が変化しない場合は、本実施の形態は、同タイミング変化パターンとは扱わない。図８に同タイミング変化パターンと扱わない変化パターンを示す。図８（Ａ）、（Ｂ）は一方のテスト項目のテスト結果のみが変化し他方のテスト項目のテスト結果は変化しない変化パターンであり、この変化パターンは同タイミング変化パターンと扱わない。図８（Ｃ）は、いずれのテスト項目についてもテスト結果が変化しないパターンで、もちろんこれも同タイミング変化パターンと扱わない。
【００２８】
[１．２．関連テスト項目抽出用のデータ]
本実施の形態は、２つのテスト項目について同タイミング変化パターンが発生しているか否かを示すデータを生成し、これに基づいて、関連テスト項目であるか否かを決定する。２つのテスト項目について同タイミング変化パターンが発生しているか否かを示すデータとして、テスト結果の変化の履歴を表すベクトルを利用する。このベクトルの次元は、ソースコードを修正した回数である。例えば、あるソフトウエアが当初バージョン１であったものを修正しバージョン２となり、バージョン2を修正してバージョン３となった場合は、２回修正されているので、ベクトルの次元は「２」である。ベクトルの要素（成分）は、テスト結果の変化の有無を表す情報である。ここではテスト結果に変化がある場合、その要素の値を「１」とし、テスト結果に変化がない場合その要素の値を「０」と記述する。なお、変化の有無を表す情報は有無の区別がつけられるものならどのようなものでもよいことは言うまでもない。
【００２９】
ベクトルの要素の順序は、ソースコードの修正を時系列に並べたものである。例えば、上記の２次元ベクトルの例を用いて述べると、あるテスト項目についてバージョン１に行ったテスト結果と、バージョン２に行ったテスト結果との変化の有無を2次元ベクトルの第1の要素とし、あるテスト項目についてバージョン２に行ったテスト結果と、バージョン３に行ったテスト結果との変化の有無を２次元ベクトルの第２の要素とするのである。
【００３０】
ベクトルの要素の順序は、ソースコードの修正（バージョンの変更）を時系列に並べた順とするのが好ましいが、その他の順で並べる構成としても本実施の形態は成立する。
【００３１】
関連テスト項目抽出用のデータであるテスト結果変化データは、上記のベクトルをテスト項目ごとに作成することによって生成される。テスト結果変化データの例を図９に示す。この例では、テスト対象であるソフトウエアが、バージョンv0.4、バージョンv0.5、バージョンv0.6、バージョンv0.7、バージョンv0.8と順に４回修正されている。
【００３２】
関連テスト項目の抽出対象となるテスト項目は、テスト項目１（テストＩＤ：１）、テスト項目２（テストＩＤ：２）、テスト項目３（テストＩＤ：３）、テスト項目４（テストＩＤ：４）、テスト項目５（テストＩＤ：５）の５つである。各テスト項目に対応するベクトルは、バージョンv0.4とバージョンv0.5とのテスト結果の変化の有無に対応する第1要素、バージョンv0.5とバージョンv0.6とのテスト結果の変化の有無に対応する第２要素、バージョンv0.6とバージョンv0.7とのテスト結果の変化の有無に対応する第３要素、バージョンv0.7とバージョンv0.8とのテスト結果の変化の有無に対応する第４要素を有する。
【００３３】
本実施の形態において、関連テスト項目抽出用のデータであるテスト結果変化データに含まれる任意の２つのベクトルにおける同一の要素の値がともにテスト結果の変化ありを示していれば、その２つのベクトルに対応するテスト項目に同一タイミング変化パターンが存在すると判定する。
【００３４】
例えば、図９のテスト項目１とテスト項目２は第２要素においてともに同一タイミング変化パターンとなっている。一方、テスト項目１とテスト項目４はいずれの要素においても同一タイミング変化パターンはない。よって、テスト項目1に対してテスト項目２は関連テスト項目となりうるが、テスト項目1に対してテスト項目４は関連テスト項目たりえない、という判定ができることになる。
【００３５】
[２．第１の実施の形態]
[２．１．装置構成例]
第１の実施の形態にかかる関連テスト項目提示装置の構成例を説明する。
関連テスト項目提示装置は、例えばコンピュータ、ワークステーションなどの情報処理装置によって実現される装置である。この情報処理装置は、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、及び必要な場合にはハードディスク装置等の外部記憶装置を具備している装置である。
【００３６】
図１０は、関連テスト項目提示装置の構成例を示すブロック図である。関連テスト項目提示装置１は、データ記憶部１０と、テスト結果変化データ生成部２０と、類似度計算部３０と、関連テスト項目抽出部４０と、関連テスト項目表示部５０と、入力部６０とを有している。なお、これら構成要素は関連テスト項目提示装置１の機能を機能ごとにまとめてブロックとして捉えたものであり、関連テスト項目提示装置１は各構成要素に対応するモジュール、装置、回路、部品などを備えていることを意味するわけではない。
【００３７】
データ記憶部１０はテスト結果変化データ生成部２０に接続されている。テスト結果変化データ生成部２０は類似度計算部３０に接続されている。類似度計算部３０は関連テスト項目抽出部４０に接続されている。関連テスト項目抽出部４０は関連テスト項目表示部５０に接続されている。入力部６０は関連テスト項目抽出部４０に接続されている。
【００３８】
ここで「接続されている」とは、データ、情報、命令などの送受信、授受が可能な状態になっていることをいい、配線で連結されているような物理的な接続に限られる意味ではない。
【００３９】
データ記憶部１０は、関連テスト項目の抽出に必要なデータを記憶する機能を有する。本実施の形態では、データ記憶部１０はテスト項目データと、テスト結果データとを記憶する。
【００４０】
[テスト項目データ]
テスト項目データは、複数のテスト項目それぞれを特定する情報（本実施の形態ではテストＩＤ）及びその他の情報を格納するレコードが複数集合して構成されるデータである。図１１に、テスト項目データのレコードのデータ構成例を示す。それぞれのレコードは、テストＩＤを格納するテストＩＤフィールド１１００と、フォルダＩＤを格納するフォルダＩＤ格納フィールド１１０１と、タイトルを格納するタイトル格納フィールド１１０２と、優先度を格納する優先度格納フィールド１１０３と、チェックポイントを格納するチェックポイント格納フィールド１１０４と、テスト方法を格納するテスト方法格納フィールド１１０５と、成功条件を格納する成功条件格納フィールド１１０６と、試験環境を格納する試験環境格納フィールド１１０７と、タグを格納するタグ格納フィールド１１０８と、特記事項を格納する特記事項格納フィールド１１０９と、登録日を格納する登録日格納フィールド１１１０と、更新日を格納する更新日格納フィールド１１１１と、添付ファイルの保存場所を示すパスを格納する添付ファイル格納フィールド１１１２とを有する。
【００４１】
「テストＩＤ」は、テスト項目を一意に特定する情報であって、例えばユニークに定められた番号等である。
「フォルダＩＤ」は、テスト項目の格納先を示す情報である。
「タイトル」は、そのテスト項目を示す文字列等である。
「優先度」は、そのテスト項目を実施する必要性の高低を示す情報である。
「チェックポイント」は、テスト項目の意図や確認すべき点についての記述である。
「テスト方法」は、テストの実行方法の記述である。
「成功条件」は、そのテスト項目のテスト結果を成功と判定するために必要な条件である。
「試験環境」は、そのテスト項目を実施する場合に満たすべき、装置、ソフトウエアなどの規定である。
「タグ」は、そのテスト項目を検索するための情報である。
「特記事項」は、そのテスト項目に関する特別のコメント、留意点などの情報である。
「登録日」は、このテスト項目レコードが登録された日付である。
「更新日」は、このテスト項目レコードが更新された日付である。
「添付ファイル」は、そのテスト項目に関する説明資料などである。
【００４２】
（テスト結果データ）
テスト結果データ１４００は、テスト結果を特定する情報（本実施の形態ではテスト結果ＩＤ）及びその他の情報を格納するレコードが複数集合して構成されるデータである。図１２に、テスト結果データのレコードのデータ構成例を示す。それぞれのレコードは、テスト結果ＩＤを格納するテスト結果ＩＤ格納フィールド１２００と、テストＩＤを格納するテストＩＤ格納フィールド１２０１と、合否を示す情報を格納する合否格納フィールド１２０２と、結果詳細を格納する結果詳細格納フィールド２０３と、不具合情報を格納する不具合情報格納フィールド１２０４と、実施日を格納する実施日格納フィールド１２０５と、バージョンを格納するバージョン格納フィールド１２０６と、担当を格納する担当格納フィールド１２０７と、機種を格納する機種格納フィールド１２０８と、工数を格納する工数格納フィールド１２０９と、予定名を格納する予定名格納フィールド１２１０と、添付ファイルを格納する添付ファイル格納フィールド１２１１とを有している。
【００４３】
「テスト結果ＩＤ」は、テスト項目を実行した場合の結果を一意に特定する情報である。
「テストＩＤ」は、テスト項目を一意に特定する情報であって、テスト項目レコードに使用されるテストＩＤと関連付けされている。
「合否」は、そのテスト結果が合格か不合格かを示す情報である。
「結果詳細」は、そのテスト結果の詳細な内容を記述した情報である。
「不具合情報」は、そのテスト結果に伴って発見された不具合を記述した情報である。
「実施日」は、そのテスト項目が実行された日付である。
「バージョン」は、テスト対象であるソフトウエア（ソースコード含む）バージョンを示す情報である。
「担当」は、そのテスト項目を実行した担当者を示す情報である。
「機種」は、そのテスト項目が実行された装置の種類を特定する情報である。
「工数」は、そのテスト項目の実行に要した時間を示す情報である。
「予定名」は、テスト項目毎に実施期間や担当者を別途管理するテストの実施予定を用いたとき、このテスト結果情報がどのテスト実施予定に属するかを特定する情報である。
「添付ファイル」は、そのテスト結果に関する説明資料などである。
【００４４】
テスト結果変化データ生成部２０は、テスト項目ごとに、各バージョンについてのテスト結果の変化の有無を記述した情報であるテスト結果変化データを生成する機能を有する。テスト結果変化データ生成部２０は生成手段に相当する。
【００４５】
類似度計算部３０は、テスト結果変化データに基づいてテスト項目相互の類似度を算出する機能を有する。類似度計算部３０は、算出手段に相当する。
【００４６】
関連テスト項目抽出部４０は、テスト項目相互の類似度に基づいて、指定されたテスト項目について、当該テスト項目の関連テスト項目を抽出する機能を有する。関連テスト項目抽出部４０は抽出手段に相当する。
【００４７】
関連テスト項目表示部５０は、抽出された関連テスト項目をユーザに提示する機能を有する。提示する方法は、紙によるプリントアウト、液晶ディスプレイ装置による画像表示、その他の態様による提示であってもかまわない。
【００４８】
入力部６０は、関連テスト項目抽出部４０に、ユーザに選択されたテスト項目を示す情報を送信する機能を有し、例えば、ポインティングデバイス、キーボード、タッチパネルなどである。
【００４９】
[２．２．動作例]
次に、関連テスト項目提示装置１の動作例について説明する。図１３は、関連テスト項目提示装置１の主要動作である関連テスト項目提示処理の例を示したフローチャートである。
【００５０】
まず、関連テスト項目提示装置１のデータ記憶部１０に、あらかじめテスト結果データを記憶させておく。テスト結果データは、他のシステムや装置から取り込んだり、オペレータにより入力しておく。
【００５１】
関連テスト項目提示処理が開始されると、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、データ記憶部１０からテスト結果データを読み取る（Ｓ１０）。図１４にテスト結果データの例を示す。テスト結果データ１４００は、一つのテスト結果について一つのレコード１４０１を有するデータである。各レコード１４０１は、テスト結果を特定する情報であるテスト結果ＩＤを格納するテスト結果ＩＤ格納フィールド１４１１と、テスト項目を特定する情報であるテストＩＤを格納するテストＩＤ格納フィールド１４１２と、テスト結果が合格であるか不合格であるかを示す情報であるテスト結果格納フィールド１４１３と、テストの対象となったソフトウエアのバージョンを示す情報を格納するバージョン格納フィールド１４１４と、テスト項目が実施されそのテスト結果が得られた日付を示す情報が格納される実施日格納フィールド１４１５とを有している。
【００５２】
次に、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果データから、テスト項目のそれぞれについて、それぞれのバージョンについてのテスト結果を格納した情報であるテスト結果集約データを生成する（Ｓ２０）。図１５にテスト結果集約データのデータ構成例を示す。テスト結果集約データ１５００は、一つのテスト項目につき一つのレコード１５０１を有するデータである。各レコード１５０１は、テスト項目に対応するテストＩＤを格納するテストＩＤ格納フィールド１５１１と、各バージョンについての当該テスト項目のテスト結果を格納する第１テスト結果格納フィールド１５１２、第２テスト結果格納フィールド１５１３、第３テスト結果格納フィールド１５１４、第４テスト結果格納フィールド１５１５、第５テスト結果格納フィールド１５１６とを有する。関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果データ１４００を参照し、第1テスト結果格納フィールド１５１２、第２テスト結果格納フィールド１５１３、第３テスト結果格納フィールド１５１４、第４テスト結果格納フィールド１５１５、第５テスト結果格納フィールド１５１６にテスト結果を示す情報を格納する。
【００５３】
例えば、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果データ１４００の第1のレコード（図中テーブルのタイトル行の直下のレコード）を読み取る。第1のレコードには、テストＩＤ１に対応するテスト項目をバージョンｖ０．４について実施したところテスト結果は合格であることが記述されている。関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果集約データ１５００のテストＩＤ格納フィールド１５１１にテストＩＤ＝１が格納されているレコード（図中、タイトル行の直化のレコード）のバージョンｖ０．４に対応する第1テスト結果格納フィールド１５１２に「合格」を示す情報を格納する。なお、図示した例では合格を記号「○」、不合格を記号「×」として記述している。同様にして、テスト結果データ１４００の各レコードを読み取って、対応するテスト結果集約データ１５００の対応するテスト結果格納フィールドに合格又は不合格を示す情報を記述し、すべてのテスト結果データ１４００のレコードを同様に処理してテスト結果集約データ１５００の生成が完了する。
【００５４】
[同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合]
同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合、テスト結果集約データにどのようにテスト結果を記述するかについて一例をあげると、それらテスト結果すべて合格だった場合、当該バージョンのテスト結果を「合格」と記述し、それらテスト結果のうち一つでも不合格がある場合、当該バージョンのテスト結果を「不合格」とする処理方法が考えられるが、この処理法に限定されず他の処理法を用いて同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合の、当該テスト項目当該バージョンにおけるテスト結果の合格、不合格を決定するようにしてもかまわない。
【００５５】
次に、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果集約データ１５００から、テスト結果の変化の履歴を表すベクトルで構成される情報であるテスト結果変化データを生成する。
【００５６】
図１６は、テスト結果集約データ１５００からテスト結果変化データを生成する処理を説明するための例を示す図である。
関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果集約データ１５００の各テスト結果格納フィールド１５１２〜１５１６のうち、隣接するもの同士に格納されているテスト結果を比較し、同一（合格同士、又は不合格同士）であれば、変化なしを示す情報（例えば、”０”）を、異なっている（一方が合格、他方が不合格）であれば、変化を示す情報（例えば”１）をテスト結果変化データの対応するレコードの対応するフィールドに書き込む。
【００５７】
図１６では、図中に、変化がある隣接フィールド間に記号「矢印」を付した。関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、矢印を付した隣接フィールドに対応するバージョン間にテスト結果の変化ありと判定する。図１７は、図１６のテスト結果集約データ１５００から生成されたテスト結果変化データ１７００の例を示す図である。
【００５８】
例えば、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、テスト結果集約データ１５００のテストＩＤ１に対応する第1レコードの内容に基づいて、テスト結果変化データ１７００のテストＩＤ１に対応するレコードに、テスト結果の変化を示す情報を書き込む場合、バージョンv0.4のテスト結果と次のバージョンv0.5のテスト結果は「○」同士なので、テスト結果変化データのテストＩＤ１に対応するレコードにおけるバージョンv0.4とv0.5のテスト結果変化を示す情報を、変化なしを示す情報”０”とする。次に、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、バージョンv0.5のテスト結果とその次のバージョンv0.6のテスト結果は「○」と「×」なので、テスト結果変化データ１７００のテストＩＤ１に対応するレコードにおけるバージョンv0.5とv0.6のテスト結果変化を示す情報を、変化ありを示す情報”１”とする。次に、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、バージョンv0.6のテスト結果とその次のバージョンv0.7のテスト結果は「×」同士なので、テスト結果変化データ１７００のテストＩＤ１に対応するレコードにおけるバージョンv0.6とv0.7のテスト結果変化を示す情報を「変化なし」を示す情報”０”とする。次に、関連テスト項目提示装置１、より詳しくはテスト結果変化データ生成部２０は、バージョンv0.7のテスト結果とその次のバージョンv0.8のテスト結果は「×」と「○」なので、テスト結果変化データ１７００のテストＩＤ１に対応するレコードにおけるバージョンv0.7とv0.8のテスト結果変化を示す情報を「変化あり」を示す情報”１”とする。
【００５９】
以上で、図１７に示したテスト結果変化データの第１行のレコードの記述が完成する。同様に、テスト結果変化データの第２行以降のレコードの記述が行われると、テスト結果変化データの生成が完了する。
【００６０】
なお、このテスト結果変化データ１７００は、前述した図９のテスト結果変化データと同様のデータ構成であるので、詳細な説明は省略する。
【００６１】
次に、関連テスト項目提示装置１、より詳しくは類似度計算部３０がテスト結果変化データに基づいて、テスト項目間の類似度を算出する（Ｓ４０）。「類似度」は、ソースコードの変更による影響を受けて、実施するテスト項目と同時にテスト結果が変化する可能性の高さ又は低さを示す情報である。
【００６２】
本実施の形態では、２つのテスト項目について、前述の同時タイミング変化パターンが多く存在するほど、類似度は高いと判定する。
【００６３】
図１８に、関連テスト項目提示装置１、より詳しくは類似度計算部３０が算出したテスト項目間の類似度を記述したデータである、項目間類似度データの例を示す。項目間類似度データ１８００は、テスト項目ごとに一つのレコード１８０１を有し、レコード１８０１は、テストＩＤを格納するテストＩＤ格納フィールド１８１１と、相手となるテスト項目ごとに類似度格納フィールドとを有する。この例では、テスト項目１からテスト項目５に対応する５つの類似度格納フィールド１８１２〜１８１６を有する。
【００６４】
本実施の形態では、類似度として、２つのテスト項目間に存在する同タイミング変化パターンの個数を用いる。関連テスト項目提示装置１、より詳しくは類似度計算部３０は、テスト結果変化データ１７００に基づいて２つのテスト項目の全ての組み合わせについて、２つのテスト項目間に存在する同タイミング変化パターンの個数をカウントし、類似度として項目間類似度データ１８００に記述する。
【００６５】
次に、関連テスト項目提示装置１、より詳しくは関連テスト項目抽出部４０は、項目間類似度データ１８００に基づいて、基準となるテスト項目についての関連テスト項目を抽出する（Ｓ５０）。
【００６６】
例えば、図１８に示した項目間類似度データ１８００に基づいて、テスト項目１（テストＩＤ：１）を基準となるテスト項目とした場合、類似度が「２」であるテスト項目３（テストＩＤ：３）と、類似度が「１」であるテスト項目２（テストＩＤ：２）及びテスト項目５（テストＩＤ：５）の３つのテスト項目を関連テスト項目提示装置１、より詳しくは関連テスト項目抽出部４０が抽出する。但し、類似度の値がどの大きさ以上であれば関連テスト項目として抽出するかについては、自由に設定してよく、例えばこの例で、類似度の大きさが「２」以上のテスト項目のみ関連テスト項目として抽出するようにしてもよく、その場合は基準となるテスト項目１について、類似度が「２」と計算されているテスト項目３のみ関連テスト項目として抽出されることとなる。
【００６７】
次に、関連テスト項目提示装置１、より詳しくは関連テスト項目表示部５０は、関連テスト項目抽出部４０によって抽出された関連テスト項目を表示若しくは出力する（Ｓ６０）。図１９は、関連テスト項目表示部５０によって表示される画面例である。この画面は基準となるテスト項目をユーザに選択させるユーザインターフェースとなっている。ユーザがポインティングデバイスや、キーボードによっていずれかのテスト項目を選択すると、テスト項目横のチェックボックスがオンになり、関連テスト項目抽出部４０が選択されたテスト項目についての関連テスト項目の抽出を行う。図２０は、図１９の画面においてテスト項目が選択された後に遷移する画面例であって、基準となるテスト項目についての関連テスト項目が関連テスト項目を表示する領域２００１に表示される。
以上で、関連テスト項目提示装置１は、関連テスト項目提示処理を終了する。
【００６８】
ユーザは選択したテスト項目を実施する際に、領域２００１に表示された関連テスト項目を実施することを、直感や経験に頼ることなく直ちに検討することができる。
【００６９】
[３．第２の実施の形態]
第２の実施について説明する。第２の実施の形態は、２つのテスト項目のテスト結果の変化を示すベクトルのコサイン類似度を計算し、その値を類似度として用いる点で第１の実施の形態にかかる関連テスト項目提示装置１と異なっている。
【００７０】
[３．１．装置構成例]
第２の実施の形態にかかる関連テスト項目提示装置１は、第1の実施の形態にかかる関連テスト項目提示装置１と同様であって、図１０に示したように、データ記憶部１０と、テスト結果変化データ生成部２０と、類似度計算部３０と、関連テスト項目抽出部４０と、関連テスト項目表示部５０と、入力部６０とを有している。類似度計算部３０を除く各構成要素の動作は、第1の実施の形態と同様なのでこれらの説明は省略する。
【００７１】
第２の実施の形態における類似度計算部３０＿２（区別のため参照符号２を３０＿２と表記する）は、テスト結果変化データ１７００に基づいて、コサイン類似度を適用して２つのテスト項目間の類似度を算出し、算出した類似度を格納したデータである項目間類似度データを生成する。
【００７２】
コサイン類似度は、ベクトルの向きの近さを類似性の指標とする手法である。
以下の式で表されるベクトルＡ，Ｂ
【数１】
0005300992.tif 000002
について、コサイン類似度Ｐは以下の式で計算される。
【数２】
0005300992.tif 000003
【００７３】
類似度計算部３０＿２は、テスト結果変化データ１７００のそれぞれのレコードを対応するテスト項目のベクトルとして扱い、２つのテスト項目のベクトルのコサイン類似度を計算し、得られた値を当該２つのテスト項目の類似度として、項目間類似度データに格納する。
【００７４】
第２の実施の形態における類似度の計算例を示す。前述の図１７に示したテスト結果変化データ１７００に基づいて、テスト項目１（テストＩＤ：1）とテスト項目２（テストＩＤ：２）との類似度を算出する。テスト項目１のテスト結果変化の履歴をベクトルＡとすると、その成分表示はＡ＝（０，１，０，１）である。テスト項目２のテスト結果変化の履歴をベクトルＢとすると、その成分表示はＢ＝（０，１，０，０）である。ベクトルＡとベクトルＢの類似度Ｐは
【数３】
0005300992.tif 000004
となる。
【００７５】
また、テスト項目１（テストＩＤ：１）とテスト項目４（テストＩＤ：４）について同様に類似度Ｐを計算すると、
【数４】
0005300992.tif 000005
このようにして２つのテスト項目のすべての組み合わせについて、類似度を計算し、項目間類似度データを生成する。図２１にテスト結果変化データ１７００に基づいて類似度計算部３０＿２が生成した項目間類似度データの例を示す。関連テスト項目抽出部４０は、項目間類似度データに基づいて基準であるテスト項目についての関連テスト項目を抽出する。
【００７６】
関連テスト項目を抽出する方法としては、例えば以下の基準を用いる方法がある。
方法１．類似度が0.0より大きい場合は、推薦する
方法２．類似度がユーザが指定した閾値以上の場合は、推薦する
方法３．ユーザが指定した工数以内で実施可能な数だけ推薦する（その場合、テスト項目に予定工数を設定する必要がある）
どのような方法により関連テスト項目抽出部４０に抽出を行わせるかは、テスト環境や開発進行状況などに基づいてユーザが設定してよい。
【００７７】
図２２は、図２１に示した項目間類似データにおいて、上記方法１の抽出する基準を満たした数値を太字下線付きで表示した図である。例えば、テスト項目５（テストＩＤ：５）について、関連テスト項目の抽出を方法１により行うとすると、関連テスト項目抽出部４０は、テスト項目１（テストＩＤ：１）とテスト項目３（テストＩＤ：３）のみテスト項目５の関連テスト項目として抽出する。
【００７８】
関連テスト項目提示装置１、より詳しくは関連テスト項目表示部５０は、関連テスト項目抽出部４０によって抽出された関連テスト項目を表示若しくは出力する。まず、先述した図１９に示した画面が表示され、ユーザがポインティングデバイスや、キーボードによっていずれかのテスト項目を選択すると、テスト項目横のチェックボックスがオンになり、関連テスト項目抽出部４０が選択されたテスト項目についての関連テスト項目の抽出を行う。図２３は、図１９の画面においてテスト項目が選択された後に遷移する画面例であって、基準となるテスト項目についての関連テスト項目が関連テスト項目を表示する領域２３０１に表示される。
【００７９】
[３．２．動作例]
第２の実施の形態にかかる関連テスト項目提示装置１は、その主要動作として関連テスト項目提示処理を実行する。関連テスト項目提示処理の内容は第１の実施の形態と、類似度の計算法を除いて同様であるので、詳細な説明は省略する。
【００８０】
[４．まとめ]
以上、本発明の実施の形態を説明したが、本発明はこれらに限定されるものではなく、発明の趣旨を逸脱しない範囲内において、種々の変更、追加、組み合わせ等が可能である。
【００８１】
上記第１、第２実施の形態では、関連テスト項目提示装置１はユーザ等が選択したテスト項目についての関連テスト項目を提示するとしたが、ユーザの選択を待たずにすべてのテスト項目についてそれぞれの関連テスト項目を提示するようにしてもよい。
【００８２】
[５．その他]
本関連テスト項目提示装置によれば、テスト担当者の勘や経験に左右されず、限られた時間の中で効率的にリグレッションテストを実施できる。
本関連テスト項目提示装置が自動的に関連テスト項目を抽出・表示するため、テスト担当者の熟練度合いに左右されず、優先して実施すべきテスト項目を選択できる。
短期間でも、不具合の修正確認やデグレードの発見を効率的に行うことができる。
【００８３】
なお、出願人は、関連テスト項目を正しく抽出できるかを確認するため、評価実験を実施したところ、正解として準備した関連テスト項目がすべて抽出できたことを確認した。これは、関連が明らかになっているテスト項目を正解として準備し、それらを抽出できるかを確認するという方法で評価実験を行った結果である。
【符号の説明】
【００８４】
１・・・関連テスト項目提示装置；  １０・・・データ記憶部；  ２０・・・テスト結果変化データ生成部；  ３０・・・類似度計算部；  ４０・・・関連テスト項目抽出部；  ５０・・・関連テスト項目表示部；  
【図１】
0005300992.tif 000006
【図２】
0005300992.tif 000007
【図３】
0005300992.tif 000008
【図４】
0005300992.tif 000009
【図５】
0005300992.tif 000010
【図６】
0005300992.tif 000011
【図７】
0005300992.tif 000012
【図８】
0005300992.tif 000013
【図９】
0005300992.tif 000014
【図１０】
0005300992.tif 000015
【図１１】
0005300992.tif 000016
【図１２】
0005300992.tif 000017
【図１３】
0005300992.tif 000018
【図１４】
0005300992.tif 000019
【図１５】
0005300992.tif 000020
【図１６】
0005300992.tif 000021
【図１７】
0005300992.tif 000022
【図１８】
0005300992.tif 000023
【図１９】
0005300992.tif 000024
【図２０】
0005300992.tif 000025
【図２１】
0005300992.tif 000026
【図２２】
0005300992.tif 000027
【図２３】
0005300992.tif 000028