JP5300992B2 - 関連テスト項目提示装置 - Google Patents

関連テスト項目提示装置 Download PDF

Info

Publication number
JP5300992B2
JP5300992B2 JP2012002178A JP2012002178A JP5300992B2 JP 5300992 B2 JP5300992 B2 JP 5300992B2 JP 2012002178 A JP2012002178 A JP 2012002178A JP 2012002178 A JP2012002178 A JP 2012002178A JP 5300992 B2 JP5300992 B2 JP 5300992B2
Authority
JP
Japan
Prior art keywords
test
test item
item
test result
result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012002178A
Other languages
English (en)
Other versions
JP2013142967A (ja
Inventor
愛美 佐々木
透 河村
秀人 小笠原
圭 久連石
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2012002178A priority Critical patent/JP5300992B2/ja
Publication of JP2013142967A publication Critical patent/JP2013142967A/ja
Application granted granted Critical
Publication of JP5300992B2 publication Critical patent/JP5300992B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Description

本明細書に記載の実施の形態は、関連テスト項目提示装置に関する。
近年、製品の高性能・高機能化に伴い、ソフトウエアは急激に大規模・複雑化している。そのため、ソフトウエアの品質を確認するために実施するテスト項目が増加し、テストにかかる工数が増加している
一方で、短期間での市場への製品リリースが求められていることから、開発期間の短縮が重要な課題となっている。
短期間でソフトウエアの品質を確保するために、ソフトウエアに潜在する不具合を効率的に発見することが求められており、テスト項目の選択の重要性は高まっている。
特開2007−102475号公報 特開2001−160955号公報
しかし、開発期間の短縮により、リグレッションテストのたびに、膨大なテスト項目すべてを繰り返し実施するのは難しい。効率的にリグレッションテストを実施するには、優先して実施すべきテスト項目を的確に選択し、不具合修正の確認やデグレードの発見を迅速に行う必要があるが、従来の手法では、テスト担当者の勘と経験にたよって、重要な機能に関連するテスト項目、最近不具合が頻発していた機能に関連するテスト項目、変更箇所に関連している可能性のあるテスト項目、これまであまり実施していなかったテスト項目、などを優先して実施すべきテスト項目を選択しており、優先して実施すべきテスト項目を的確に選択するのに高いスキルが必要であった。
本発明は、テスト担当者の熟練度合いに左右されることなく、優先して実施すべきテスト項目を選択でき、且つ短期間でも不具合の修正確認やデグレードの発見を効率的に行うことができる技術を提供することを目的とする。
一の実施の形態によれば、関連テスト項目提示装置が提案される。関連テスト項目提示装置は、生成手段と、算出手段と、抽出手段とを有する。生成手段は、テスト項目の実行の結果であるテスト結果とそのテスト項目とテスト項目の実行の対象のバージョンを示す情報を有するテスト結果データから、一つのテスト項目を各バージョンのソフトウエアに実施したテスト結果の変化の有無を表す情報を有するテスト結果変化データを生成する。算出手段は、前記テスト結果変化データに基づいて、テスト項目間の類似度を算出する。抽出手段は前記類似度に基づいて関連テスト項目を抽出する。
複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示す図 複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示す別の図 テスト項目、機能、モジュール、ソースコードの関連の例を示す図 図3の後のテスト項目、機能、モジュール、ソースコードの関連の例を示す図 複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターンの例を示すさらに別の図 テスト項目、機能、モジュール、ソースコードの関連の例を示す図 図6の後のテスト項目、機能、モジュール、ソースコードの関連の例を示す図 (A)は同タイミング変化パターンと扱わない、変化パターンを示す図、(B)は同タイミング変化パターンと扱わない、別の変化パターンを示す図、(C)は同タイミング変化パターンと扱わない、さらに別の変化パターンを示す図 テスト結果変化データの例を示す図 関連テスト項目提示装置の構成例を示すブロック図 テスト項目データのレコードのデータ構成例を示す図 テスト結果データのレコードのデータ構成例を示す 関連テスト項目提示処理の例を示したフローチャート テスト結果データの例を示す図 テスト結果集約データのデータ構成例を示す図 テスト結果集約データからテスト結果変化データを生成する処理を説明するための例を示す図 図16のテスト結果集約データから生成されたテスト結果変化データの例を示す図 項目間類似度データの例を示す図 関連テスト項目表示部によって表示される画面例を示す図 図19の画面においてテスト項目が選択された後に遷移する画面例を示す図 項目間類似度データの例を示す図 項目間類似データにおいて、方法1の抽出する基準を満たした数値を太字下線付きで表示した図 図19の画面においてテスト項目が選択された後に遷移する画面例を示す図
以下、添付の図面を参照しながら、本発明の実施の形態に係る関連テスト項目提示装置の例を説明する。
[0.用語の定義]
まず、本実施の形態において用いる用語の定義を述べる。
[0.1.テスト]
「テスト」とは、ソフトウエアの開発において、実装したソースコードが仕様通り動作するか否かを確認する作業をいう。
[0.2.不合格]
「不合格」とは、テストを実施した結果、動作結果がテストで期待する結果にならないことをいう。
[0.3.合格]
「合格」とは、テストを実施した結果、動作結果がテストで期待する結果となったことをいう。
[0.4.欠陥]
「欠陥」とは、ソースコードの誤りをいう。「バグ」も「欠陥」に含まれる。
[0.5.不具合]
「不具合」とは、ソフトウエアが期待通りに動作しない現象のこと
[0.6.デグレード]
「デグレード」とは、ソフトウエアの変更を行った後、一度テストに合格しているテスト項目を再度テストした際に、不合格になること
[0.7.テスト項目]
「テスト項目」とは、テストの実施の単位をいう。「テスト項目」が決定されると、どのような具体的内容のテストを実行するかが定まる。一つのテスト項目には、チェックポイントや実施手順、期待する値などを記録する。なお、本明細書中「テスト項目を実行(実施)する」とは、そのテスト項目に定められた内容のテストを実行することをいうものとする。
[0.8.テスト結果]
「テスト結果」は、テスト項目を実施した際の合格又は不合格を示す記録をいう。テスト結果は合格又は不合格のいずれかであり、他に日付やバージョンなどの情報も同時に記録される。
[0.9.バージョン]
「バージョン」とは、テスト対象のソフトウエアとテスト結果を対応付ける属性であって、当該ソフトウエアが何回改訂・更新されたものかを識別可能とする情報である。。バージョンを元に、どの構成でテストを実施しているか把握できる。ソフトウエアのビルドNo(ナンバー)や、構成管理システムのリビジョンNo、マイルストーンごとにつけるタグ(β版やRC版)などをバージョンとする。
[0.10.リグレッションテスト(回帰テスト)]
「リグレッションテスト」とは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するために行うテストをいう。ソースコードの欠陥を取り除いたことによって、代わりに新しい欠陥が埋め込まれていないか確認する。
[1.概要]
以下に本実施の形態の概要を述べる。
本実施の形態では、登録されている複数のテスト項目の中から、リグレッションテストで実施するテスト項目(実施テスト項目)と関連している可能性が高いテスト項目(関連テスト項目)を抽出し、関連テスト項目を、他の登録されている複数のテスト項目に優先して実施すべきテスト項目として出力する。
関連テスト項目は、ソースコードの変更による影響を受けて、実施テスト項目と同時にテスト結果が変化する可能性があるテスト項目と想定されるテスト項目である。
本関連テスト項目提示装置は、一連のテスト結果の履歴データに基づいて、過去に実施テスト項目と同じタイミング(テスト対象のバージョンの変更)でテスト結果が変化したことがあるテスト項目群を関連テスト項目として抽出する。
テスト結果が、合格→不合格、或いは不合格→合格に変化するということは、ソースコードの変更による影響を受けているということである。
[1.1.複数のテスト項目のテスト結果の変化パターン]
以下に、本実施の形態において複数のテスト項目のテスト結果が同じタイミングで変化したと捉える変化パターン(「同タイミング変化パターン」と呼ぶ)について説明する。同タイミング変化パターンは、テスト項目が相互に関連テスト項目であるか否かを計算する基礎情報となる。
[1.1.1.変化パターン(1)]
本実施の形態において、同タイミング変化パターンの第1は、2つのテスト項目のテスト結果が同時に不合格から合格へ変化する、又は、合格から不合格へ変化する場合である。図1、図2に変化パターン(1)の例を示す。図1の例では、テスト項目AをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2についてについて実施した場合のテスト結果が「○(合格)」であるのに対して、テスト項目BをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2について実施した場合のテスト結果が「○(合格)」である。図2は、図1の逆のパターンである。
上記の同タイミング変化パターンが生ずる場合の、テスト項目、機能、モジュール、ソースコードの関係を説明する。図3は、テスト項目、機能、モジュール、ソースコードの関連の例を示す図である。
この例では、あるバージョンのソフトウエアについて、機能A、機能B,機能Cがあり、これら機能A,機能B,機能Cについて検証するためのテスト項目であるテスト項目A、テスト項目B、テスト項目Cがある。
機能Aを実現するために使用されるモジュールとして、モジュール1とモジュール2があり、機能Bを実現するために使用されるモジュールとして、モジュール2とモジュール3があり、機能Cを実現するために使用されるモジュールとして、モジュール4とモジュール5がある。モジュール2は機能Aと機能Bに共通のモジュールである。
各モジュールは、1又は複数のサブモジュールで構成される。モジュール1は、ソースコードaに対応するサブモジュールとソースコードbに対応するサブモジュールで構成される。モジュール2は、ソースコードcに対応するサブモジュールとソースコードdに対応するサブモジュールとソースコードeに対応するサブモジュールで構成される。モジュール3は、ソースコードeに対応するサブモジュールとソースコードfに対応するサブモジュールで構成される。モジュール4は、ソースコードgに対応するサブモジュールとソースコードhに対応するサブモジュールで構成される。モジュール5は、ソースコードiに対応するサブモジュールとソースコードjに対応するサブモジュールで構成される。なお、本明細書では、説明の便宜上サブモジュールに代えてそのサブモジュールに対応するソースコードを用いて説明する。
さて、このソフトウエアについて、テスト項目A、テスト項目B、テスト項目Cが実施された結果、機能Aについて不具合がありテスト項目Aのテスト結果は不合格となり、機能Bについて不具合がありテスト項目Bのテスト結果は不合格となり、機能Cについては不具合はなくテスト項目Cのテスト結果は合格となった。
ここで、機能A、機能Bの不具合の原因はモジュール2にあり、そのソースコードcに欠陥があったものとする。
次にソースコードcの欠陥が修正されたソフトウエアの次バージョンが作成されたものとする。このソフトウエアの次バージョンについてテスト項目A、テスト項目B、テスト項目Cが実施された結果、機能Aについて不具合はなくテスト項目Aのテスト結果は合格となり、機能Bについて不具合はなくテスト項目Bのテスト結果は合格となり、機能Cについては不具合はなくテスト項目Cのテスト結果も合格となった。かかる状態を図4に示す。
図3及び図4で示した例は、図1に示した同タイミング変化パターンに相当する。
[1.1.2.パターン(2)]
本実施の形態において、同タイミング変化パターンの第2は、あるテスト項目のテスト結果が不合格から合格へ変化したタイミングで、別のテスト項目のテスト結果が合格から不合格へ変化する場合である。図5に変化パターン(2)の例を示す。この例では、テスト項目AをバージョンV0.1について実施した場合のテスト結果が「×(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2について実施した場合のテスト結果が「○(合格)」であるのに対して、テスト項目BをバージョンV0.1について実施した場合のテスト結果が「○(不合格)」、バージョンV0.1の次のバージョンであるバージョンV0.2についてについて実施した場合のテスト結果が「×(合格)」である。
上記の同タイミング変化パターンが生ずる場合の、テスト項目、機能、モジュール、ソースコードの関係を説明する。図6は、テスト項目、機能、モジュール、ソースコードの関連の例を示す図であって、ソフトウエアを構成するテスト項目、機能、モジュール、ソースコードは前述の図3、図4に示した例と同様である。
さて、このソフトウエアについて、テスト項目A、テスト項目B、テスト項目Cが実施された結果、機能Aについて不具合がありテスト項目Aのテスト結果は不合格となり、機能Bについては不具合はなくテスト項目Bのテスト結果は合格となり、機能Cについては不具合はなくテスト項目Cのテスト結果は合格となった。
ここで、機能Aの不具合の原因はモジュール2にあり、そのソースコードcに欠陥があったものとする。但し、この欠陥は機能Bに影響しないものであった。
次にソースコードcの欠陥が修正されたソフトウエアの次バージョンが作成されたものとする。しかし、ソースコードcの欠陥修正の結果、別の新たな「欠陥’」がソースコードcに内在し、この新たな欠陥は機能Bに影響するものであった。
このソフトウエアの次バージョンについてテスト項目A、テスト項目B、テスト項目Cを実施すると、機能Aについて不具合はなくテスト項目Aのテスト結果は合格となり、機能Bについて不具合がありテスト項目Bのテスト結果は不合格となり、機能Cについては不具合はなくテスト項目Cのテスト結果は合格となった。かかる状態を図7に示す。
この図6及び図7で示した例は、前述の図5に示した同タイミング変化パターンに相当する。
[1.1.3.同じタイミングで変化したと捉えられない]
同じタイミングで変化したと捉えられないパターンについて説明する。一方のテスト項目のみテスト結果が変化し、他方のテスト項目のテスト結果が変化しない場合は、本実施の形態は、同タイミング変化パターンとは扱わない。図8に同タイミング変化パターンと扱わない変化パターンを示す。図8(A)、(B)は一方のテスト項目のテスト結果のみが変化し他方のテスト項目のテスト結果は変化しない変化パターンであり、この変化パターンは同タイミング変化パターンと扱わない。図8(C)は、いずれのテスト項目についてもテスト結果が変化しないパターンで、もちろんこれも同タイミング変化パターンと扱わない。
[1.2.関連テスト項目抽出用のデータ]
本実施の形態は、2つのテスト項目について同タイミング変化パターンが発生しているか否かを示すデータを生成し、これに基づいて、関連テスト項目であるか否かを決定する。2つのテスト項目について同タイミング変化パターンが発生しているか否かを示すデータとして、テスト結果の変化の履歴を表すベクトルを利用する。このベクトルの次元は、ソースコードを修正した回数である。例えば、あるソフトウエアが当初バージョン1であったものを修正しバージョン2となり、バージョン2を修正してバージョン3となった場合は、2回修正されているので、ベクトルの次元は「2」である。ベクトルの要素(成分)は、テスト結果の変化の有無を表す情報である。ここではテスト結果に変化がある場合、その要素の値を「1」とし、テスト結果に変化がない場合その要素の値を「0」と記述する。なお、変化の有無を表す情報は有無の区別がつけられるものならどのようなものでもよいことは言うまでもない。
ベクトルの要素の順序は、ソースコードの修正を時系列に並べたものである。例えば、上記の2次元ベクトルの例を用いて述べると、あるテスト項目についてバージョン1に行ったテスト結果と、バージョン2に行ったテスト結果との変化の有無を2次元ベクトルの第1の要素とし、あるテスト項目についてバージョン2に行ったテスト結果と、バージョン3に行ったテスト結果との変化の有無を2次元ベクトルの第2の要素とするのである。
ベクトルの要素の順序は、ソースコードの修正(バージョンの変更)を時系列に並べた順とするのが好ましいが、その他の順で並べる構成としても本実施の形態は成立する。
関連テスト項目抽出用のデータであるテスト結果変化データは、上記のベクトルをテスト項目ごとに作成することによって生成される。テスト結果変化データの例を図9に示す。この例では、テスト対象であるソフトウエアが、バージョンv0.4、バージョンv0.5、バージョンv0.6、バージョンv0.7、バージョンv0.8と順に4回修正されている。
関連テスト項目の抽出対象となるテスト項目は、テスト項目1(テストID:1)、テスト項目2(テストID:2)、テスト項目3(テストID:3)、テスト項目4(テストID:4)、テスト項目5(テストID:5)の5つである。各テスト項目に対応するベクトルは、バージョンv0.4とバージョンv0.5とのテスト結果の変化の有無に対応する第1要素、バージョンv0.5とバージョンv0.6とのテスト結果の変化の有無に対応する第2要素、バージョンv0.6とバージョンv0.7とのテスト結果の変化の有無に対応する第3要素、バージョンv0.7とバージョンv0.8とのテスト結果の変化の有無に対応する第4要素を有する。
本実施の形態において、関連テスト項目抽出用のデータであるテスト結果変化データに含まれる任意の2つのベクトルにおける同一の要素の値がともにテスト結果の変化ありを示していれば、その2つのベクトルに対応するテスト項目に同一タイミング変化パターンが存在すると判定する。
例えば、図9のテスト項目1とテスト項目2は第2要素においてともに同一タイミング変化パターンとなっている。一方、テスト項目1とテスト項目4はいずれの要素においても同一タイミング変化パターンはない。よって、テスト項目1に対してテスト項目2は関連テスト項目となりうるが、テスト項目1に対してテスト項目4は関連テスト項目たりえない、という判定ができることになる。
[2.第1の実施の形態]
[2.1.装置構成例]
第1の実施の形態にかかる関連テスト項目提示装置の構成例を説明する。
関連テスト項目提示装置は、例えばコンピュータ、ワークステーションなどの情報処理装置によって実現される装置である。この情報処理装置は、演算処理装置(CPU)、主メモリ(RAM)、読出し専用メモリ(ROM)、入出力装置(I/O)、及び必要な場合にはハードディスク装置等の外部記憶装置を具備している装置である。
図10は、関連テスト項目提示装置の構成例を示すブロック図である。関連テスト項目提示装置1は、データ記憶部10と、テスト結果変化データ生成部20と、類似度計算部30と、関連テスト項目抽出部40と、関連テスト項目表示部50と、入力部60とを有している。なお、これら構成要素は関連テスト項目提示装置1の機能を機能ごとにまとめてブロックとして捉えたものであり、関連テスト項目提示装置1は各構成要素に対応するモジュール、装置、回路、部品などを備えていることを意味するわけではない。
データ記憶部10はテスト結果変化データ生成部20に接続されている。テスト結果変化データ生成部20は類似度計算部30に接続されている。類似度計算部30は関連テスト項目抽出部40に接続されている。関連テスト項目抽出部40は関連テスト項目表示部50に接続されている。入力部60は関連テスト項目抽出部40に接続されている。
ここで「接続されている」とは、データ、情報、命令などの送受信、授受が可能な状態になっていることをいい、配線で連結されているような物理的な接続に限られる意味ではない。
データ記憶部10は、関連テスト項目の抽出に必要なデータを記憶する機能を有する。本実施の形態では、データ記憶部10はテスト項目データと、テスト結果データとを記憶する。
[テスト項目データ]
テスト項目データは、複数のテスト項目それぞれを特定する情報(本実施の形態ではテストID)及びその他の情報を格納するレコードが複数集合して構成されるデータである。図11に、テスト項目データのレコードのデータ構成例を示す。それぞれのレコードは、テストIDを格納するテストIDフィールド1100と、フォルダIDを格納するフォルダID格納フィールド1101と、タイトルを格納するタイトル格納フィールド1102と、優先度を格納する優先度格納フィールド1103と、チェックポイントを格納するチェックポイント格納フィールド1104と、テスト方法を格納するテスト方法格納フィールド1105と、成功条件を格納する成功条件格納フィールド1106と、試験環境を格納する試験環境格納フィールド1107と、タグを格納するタグ格納フィールド1108と、特記事項を格納する特記事項格納フィールド1109と、登録日を格納する登録日格納フィールド1110と、更新日を格納する更新日格納フィールド1111と、添付ファイルの保存場所を示すパスを格納する添付ファイル格納フィールド1112とを有する。
「テストID」は、テスト項目を一意に特定する情報であって、例えばユニークに定められた番号等である。
「フォルダID」は、テスト項目の格納先を示す情報である。
「タイトル」は、そのテスト項目を示す文字列等である。
「優先度」は、そのテスト項目を実施する必要性の高低を示す情報である。
「チェックポイント」は、テスト項目の意図や確認すべき点についての記述である。
「テスト方法」は、テストの実行方法の記述である。
「成功条件」は、そのテスト項目のテスト結果を成功と判定するために必要な条件である。
「試験環境」は、そのテスト項目を実施する場合に満たすべき、装置、ソフトウエアなどの規定である。
「タグ」は、そのテスト項目を検索するための情報である。
「特記事項」は、そのテスト項目に関する特別のコメント、留意点などの情報である。
「登録日」は、このテスト項目レコードが登録された日付である。
「更新日」は、このテスト項目レコードが更新された日付である。
「添付ファイル」は、そのテスト項目に関する説明資料などである。
(テスト結果データ)
テスト結果データ1400は、テスト結果を特定する情報(本実施の形態ではテスト結果ID)及びその他の情報を格納するレコードが複数集合して構成されるデータである。図12に、テスト結果データのレコードのデータ構成例を示す。それぞれのレコードは、テスト結果IDを格納するテスト結果ID格納フィールド1200と、テストIDを格納するテストID格納フィールド1201と、合否を示す情報を格納する合否格納フィールド1202と、結果詳細を格納する結果詳細格納フィールド203と、不具合情報を格納する不具合情報格納フィールド1204と、実施日を格納する実施日格納フィールド1205と、バージョンを格納するバージョン格納フィールド1206と、担当を格納する担当格納フィールド1207と、機種を格納する機種格納フィールド1208と、工数を格納する工数格納フィールド1209と、予定名を格納する予定名格納フィールド1210と、添付ファイルを格納する添付ファイル格納フィールド1211とを有している。
「テスト結果ID」は、テスト項目を実行した場合の結果を一意に特定する情報である。
「テストID」は、テスト項目を一意に特定する情報であって、テスト項目レコードに使用されるテストIDと関連付けされている。
「合否」は、そのテスト結果が合格か不合格かを示す情報である。
「結果詳細」は、そのテスト結果の詳細な内容を記述した情報である。
「不具合情報」は、そのテスト結果に伴って発見された不具合を記述した情報である。
「実施日」は、そのテスト項目が実行された日付である。
「バージョン」は、テスト対象であるソフトウエア(ソースコード含む)バージョンを示す情報である。
「担当」は、そのテスト項目を実行した担当者を示す情報である。
「機種」は、そのテスト項目が実行された装置の種類を特定する情報である。
「工数」は、そのテスト項目の実行に要した時間を示す情報である。
「予定名」は、テスト項目毎に実施期間や担当者を別途管理するテストの実施予定を用いたとき、このテスト結果情報がどのテスト実施予定に属するかを特定する情報である。
「添付ファイル」は、そのテスト結果に関する説明資料などである。
テスト結果変化データ生成部20は、テスト項目ごとに、各バージョンについてのテスト結果の変化の有無を記述した情報であるテスト結果変化データを生成する機能を有する。テスト結果変化データ生成部20は生成手段に相当する。
類似度計算部30は、テスト結果変化データに基づいてテスト項目相互の類似度を算出する機能を有する。類似度計算部30は、算出手段に相当する。
関連テスト項目抽出部40は、テスト項目相互の類似度に基づいて、指定されたテスト項目について、当該テスト項目の関連テスト項目を抽出する機能を有する。関連テスト項目抽出部40は抽出手段に相当する。
関連テスト項目表示部50は、抽出された関連テスト項目をユーザに提示する機能を有する。提示する方法は、紙によるプリントアウト、液晶ディスプレイ装置による画像表示、その他の態様による提示であってもかまわない。
入力部60は、関連テスト項目抽出部40に、ユーザに選択されたテスト項目を示す情報を送信する機能を有し、例えば、ポインティングデバイス、キーボード、タッチパネルなどである。
[2.2.動作例]
次に、関連テスト項目提示装置1の動作例について説明する。図13は、関連テスト項目提示装置1の主要動作である関連テスト項目提示処理の例を示したフローチャートである。
まず、関連テスト項目提示装置1のデータ記憶部10に、あらかじめテスト結果データを記憶させておく。テスト結果データは、他のシステムや装置から取り込んだり、オペレータにより入力しておく。
関連テスト項目提示処理が開始されると、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、データ記憶部10からテスト結果データを読み取る(S10)。図14にテスト結果データの例を示す。テスト結果データ1400は、一つのテスト結果について一つのレコード1401を有するデータである。各レコード1401は、テスト結果を特定する情報であるテスト結果IDを格納するテスト結果ID格納フィールド1411と、テスト項目を特定する情報であるテストIDを格納するテストID格納フィールド1412と、テスト結果が合格であるか不合格であるかを示す情報であるテスト結果格納フィールド1413と、テストの対象となったソフトウエアのバージョンを示す情報を格納するバージョン格納フィールド1414と、テスト項目が実施されそのテスト結果が得られた日付を示す情報が格納される実施日格納フィールド1415とを有している。
次に、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果データから、テスト項目のそれぞれについて、それぞれのバージョンについてのテスト結果を格納した情報であるテスト結果集約データを生成する(S20)。図15にテスト結果集約データのデータ構成例を示す。テスト結果集約データ1500は、一つのテスト項目につき一つのレコード1501を有するデータである。各レコード1501は、テスト項目に対応するテストIDを格納するテストID格納フィールド1511と、各バージョンについての当該テスト項目のテスト結果を格納する第1テスト結果格納フィールド1512、第2テスト結果格納フィールド1513、第3テスト結果格納フィールド1514、第4テスト結果格納フィールド1515、第5テスト結果格納フィールド1516とを有する。関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果データ1400を参照し、第1テスト結果格納フィールド1512、第2テスト結果格納フィールド1513、第3テスト結果格納フィールド1514、第4テスト結果格納フィールド1515、第5テスト結果格納フィールド1516にテスト結果を示す情報を格納する。
例えば、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果データ1400の第1のレコード(図中テーブルのタイトル行の直下のレコード)を読み取る。第1のレコードには、テストID1に対応するテスト項目をバージョンv0.4について実施したところテスト結果は合格であることが記述されている。関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果集約データ1500のテストID格納フィールド1511にテストID=1が格納されているレコード(図中、タイトル行の直化のレコード)のバージョンv0.4に対応する第1テスト結果格納フィールド1512に「合格」を示す情報を格納する。なお、図示した例では合格を記号「○」、不合格を記号「×」として記述している。同様にして、テスト結果データ1400の各レコードを読み取って、対応するテスト結果集約データ1500の対応するテスト結果格納フィールドに合格又は不合格を示す情報を記述し、すべてのテスト結果データ1400のレコードを同様に処理してテスト結果集約データ1500の生成が完了する。
[同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合]
同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合、テスト結果集約データにどのようにテスト結果を記述するかについて一例をあげると、それらテスト結果すべて合格だった場合、当該バージョンのテスト結果を「合格」と記述し、それらテスト結果のうち一つでも不合格がある場合、当該バージョンのテスト結果を「不合格」とする処理方法が考えられるが、この処理法に限定されず他の処理法を用いて同一テスト項目、同一バージョンについて複数のテスト結果が存在する場合の、当該テスト項目当該バージョンにおけるテスト結果の合格、不合格を決定するようにしてもかまわない。
次に、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果集約データ1500から、テスト結果の変化の履歴を表すベクトルで構成される情報であるテスト結果変化データを生成する。
図16は、テスト結果集約データ1500からテスト結果変化データを生成する処理を説明するための例を示す図である。
関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果集約データ1500の各テスト結果格納フィールド1512〜1516のうち、隣接するもの同士に格納されているテスト結果を比較し、同一(合格同士、又は不合格同士)であれば、変化なしを示す情報(例えば、”0”)を、異なっている(一方が合格、他方が不合格)であれば、変化を示す情報(例えば”1)をテスト結果変化データの対応するレコードの対応するフィールドに書き込む。
図16では、図中に、変化がある隣接フィールド間に記号「矢印」を付した。関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、矢印を付した隣接フィールドに対応するバージョン間にテスト結果の変化ありと判定する。図17は、図16のテスト結果集約データ1500から生成されたテスト結果変化データ1700の例を示す図である。
例えば、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、テスト結果集約データ1500のテストID1に対応する第1レコードの内容に基づいて、テスト結果変化データ1700のテストID1に対応するレコードに、テスト結果の変化を示す情報を書き込む場合、バージョンv0.4のテスト結果と次のバージョンv0.5のテスト結果は「○」同士なので、テスト結果変化データのテストID1に対応するレコードにおけるバージョンv0.4とv0.5のテスト結果変化を示す情報を、変化なしを示す情報”0”とする。次に、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、バージョンv0.5のテスト結果とその次のバージョンv0.6のテスト結果は「○」と「×」なので、テスト結果変化データ1700のテストID1に対応するレコードにおけるバージョンv0.5とv0.6のテスト結果変化を示す情報を、変化ありを示す情報”1”とする。次に、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、バージョンv0.6のテスト結果とその次のバージョンv0.7のテスト結果は「×」同士なので、テスト結果変化データ1700のテストID1に対応するレコードにおけるバージョンv0.6とv0.7のテスト結果変化を示す情報を「変化なし」を示す情報”0”とする。次に、関連テスト項目提示装置1、より詳しくはテスト結果変化データ生成部20は、バージョンv0.7のテスト結果とその次のバージョンv0.8のテスト結果は「×」と「○」なので、テスト結果変化データ1700のテストID1に対応するレコードにおけるバージョンv0.7とv0.8のテスト結果変化を示す情報を「変化あり」を示す情報”1”とする。
以上で、図17に示したテスト結果変化データの第1行のレコードの記述が完成する。同様に、テスト結果変化データの第2行以降のレコードの記述が行われると、テスト結果変化データの生成が完了する。
なお、このテスト結果変化データ1700は、前述した図9のテスト結果変化データと同様のデータ構成であるので、詳細な説明は省略する。
次に、関連テスト項目提示装置1、より詳しくは類似度計算部30がテスト結果変化データに基づいて、テスト項目間の類似度を算出する(S40)。「類似度」は、ソースコードの変更による影響を受けて、実施するテスト項目と同時にテスト結果が変化する可能性の高さ又は低さを示す情報である。
本実施の形態では、2つのテスト項目について、前述の同時タイミング変化パターンが多く存在するほど、類似度は高いと判定する。
図18に、関連テスト項目提示装置1、より詳しくは類似度計算部30が算出したテスト項目間の類似度を記述したデータである、項目間類似度データの例を示す。項目間類似度データ1800は、テスト項目ごとに一つのレコード1801を有し、レコード1801は、テストIDを格納するテストID格納フィールド1811と、相手となるテスト項目ごとに類似度格納フィールドとを有する。この例では、テスト項目1からテスト項目5に対応する5つの類似度格納フィールド1812〜1816を有する。
本実施の形態では、類似度として、2つのテスト項目間に存在する同タイミング変化パターンの個数を用いる。関連テスト項目提示装置1、より詳しくは類似度計算部30は、テスト結果変化データ1700に基づいて2つのテスト項目の全ての組み合わせについて、2つのテスト項目間に存在する同タイミング変化パターンの個数をカウントし、類似度として項目間類似度データ1800に記述する。
次に、関連テスト項目提示装置1、より詳しくは関連テスト項目抽出部40は、項目間類似度データ1800に基づいて、基準となるテスト項目についての関連テスト項目を抽出する(S50)。
例えば、図18に示した項目間類似度データ1800に基づいて、テスト項目1(テストID:1)を基準となるテスト項目とした場合、類似度が「2」であるテスト項目3(テストID:3)と、類似度が「1」であるテスト項目2(テストID:2)及びテスト項目5(テストID:5)の3つのテスト項目を関連テスト項目提示装置1、より詳しくは関連テスト項目抽出部40が抽出する。但し、類似度の値がどの大きさ以上であれば関連テスト項目として抽出するかについては、自由に設定してよく、例えばこの例で、類似度の大きさが「2」以上のテスト項目のみ関連テスト項目として抽出するようにしてもよく、その場合は基準となるテスト項目1について、類似度が「2」と計算されているテスト項目3のみ関連テスト項目として抽出されることとなる。
次に、関連テスト項目提示装置1、より詳しくは関連テスト項目表示部50は、関連テスト項目抽出部40によって抽出された関連テスト項目を表示若しくは出力する(S60)。図19は、関連テスト項目表示部50によって表示される画面例である。この画面は基準となるテスト項目をユーザに選択させるユーザインターフェースとなっている。ユーザがポインティングデバイスや、キーボードによっていずれかのテスト項目を選択すると、テスト項目横のチェックボックスがオンになり、関連テスト項目抽出部40が選択されたテスト項目についての関連テスト項目の抽出を行う。図20は、図19の画面においてテスト項目が選択された後に遷移する画面例であって、基準となるテスト項目についての関連テスト項目が関連テスト項目を表示する領域2001に表示される。
以上で、関連テスト項目提示装置1は、関連テスト項目提示処理を終了する。
ユーザは選択したテスト項目を実施する際に、領域2001に表示された関連テスト項目を実施することを、直感や経験に頼ることなく直ちに検討することができる。
[3.第2の実施の形態]
第2の実施について説明する。第2の実施の形態は、2つのテスト項目のテスト結果の変化を示すベクトルのコサイン類似度を計算し、その値を類似度として用いる点で第1の実施の形態にかかる関連テスト項目提示装置1と異なっている。
[3.1.装置構成例]
第2の実施の形態にかかる関連テスト項目提示装置1は、第1の実施の形態にかかる関連テスト項目提示装置1と同様であって、図10に示したように、データ記憶部10と、テスト結果変化データ生成部20と、類似度計算部30と、関連テスト項目抽出部40と、関連テスト項目表示部50と、入力部60とを有している。類似度計算部30を除く各構成要素の動作は、第1の実施の形態と同様なのでこれらの説明は省略する。
第2の実施の形態における類似度計算部30_2(区別のため参照符号2を30_2と表記する)は、テスト結果変化データ1700に基づいて、コサイン類似度を適用して2つのテスト項目間の類似度を算出し、算出した類似度を格納したデータである項目間類似度データを生成する。
コサイン類似度は、ベクトルの向きの近さを類似性の指標とする手法である。
以下の式で表されるベクトルA,B

について、コサイン類似度Pは以下の式で計算される。
類似度計算部30_2は、テスト結果変化データ1700のそれぞれのレコードを対応するテスト項目のベクトルとして扱い、2つのテスト項目のベクトルのコサイン類似度を計算し、得られた値を当該2つのテスト項目の類似度として、項目間類似度データに格納する。
第2の実施の形態における類似度の計算例を示す。前述の図17に示したテスト結果変化データ1700に基づいて、テスト項目1(テストID:1)とテスト項目2(テストID:2)との類似度を算出する。テスト項目1のテスト結果変化の履歴をベクトルAとすると、その成分表示はA=(0,1,0,1)である。テスト項目2のテスト結果変化の履歴をベクトルBとすると、その成分表示はB=(0,1,0,0)である。ベクトルAとベクトルBの類似度Pは

となる。
また、テスト項目1(テストID:1)とテスト項目4(テストID:4)について同様に類似度Pを計算すると、

このようにして2つのテスト項目のすべての組み合わせについて、類似度を計算し、項目間類似度データを生成する。図21にテスト結果変化データ1700に基づいて類似度計算部30_2が生成した項目間類似度データの例を示す。関連テスト項目抽出部40は、項目間類似度データに基づいて基準であるテスト項目についての関連テスト項目を抽出する。
関連テスト項目を抽出する方法としては、例えば以下の基準を用いる方法がある。
方法1.類似度が0.0より大きい場合は、推薦する
方法2.類似度がユーザが指定した閾値以上の場合は、推薦する
方法3.ユーザが指定した工数以内で実施可能な数だけ推薦する(その場合、テスト項目に予定工数を設定する必要がある)
どのような方法により関連テスト項目抽出部40に抽出を行わせるかは、テスト環境や開発進行状況などに基づいてユーザが設定してよい。
図22は、図21に示した項目間類似データにおいて、上記方法1の抽出する基準を満たした数値を太字下線付きで表示した図である。例えば、テスト項目5(テストID:5)について、関連テスト項目の抽出を方法1により行うとすると、関連テスト項目抽出部40は、テスト項目1(テストID:1)とテスト項目3(テストID:3)のみテスト項目5の関連テスト項目として抽出する。
関連テスト項目提示装置1、より詳しくは関連テスト項目表示部50は、関連テスト項目抽出部40によって抽出された関連テスト項目を表示若しくは出力する。まず、先述した図19に示した画面が表示され、ユーザがポインティングデバイスや、キーボードによっていずれかのテスト項目を選択すると、テスト項目横のチェックボックスがオンになり、関連テスト項目抽出部40が選択されたテスト項目についての関連テスト項目の抽出を行う。図23は、図19の画面においてテスト項目が選択された後に遷移する画面例であって、基準となるテスト項目についての関連テスト項目が関連テスト項目を表示する領域2301に表示される。
[3.2.動作例]
第2の実施の形態にかかる関連テスト項目提示装置1は、その主要動作として関連テスト項目提示処理を実行する。関連テスト項目提示処理の内容は第1の実施の形態と、類似度の計算法を除いて同様であるので、詳細な説明は省略する。
[4.まとめ]
以上、本発明の実施の形態を説明したが、本発明はこれらに限定されるものではなく、発明の趣旨を逸脱しない範囲内において、種々の変更、追加、組み合わせ等が可能である。
上記第1、第2実施の形態では、関連テスト項目提示装置1はユーザ等が選択したテスト項目についての関連テスト項目を提示するとしたが、ユーザの選択を待たずにすべてのテスト項目についてそれぞれの関連テスト項目を提示するようにしてもよい。
[5.その他]
本関連テスト項目提示装置によれば、テスト担当者の勘や経験に左右されず、限られた時間の中で効率的にリグレッションテストを実施できる。
本関連テスト項目提示装置が自動的に関連テスト項目を抽出・表示するため、テスト担当者の熟練度合いに左右されず、優先して実施すべきテスト項目を選択できる。
短期間でも、不具合の修正確認やデグレードの発見を効率的に行うことができる。
なお、出願人は、関連テスト項目を正しく抽出できるかを確認するため、評価実験を実施したところ、正解として準備した関連テスト項目がすべて抽出できたことを確認した。これは、関連が明らかになっているテスト項目を正解として準備し、それらを抽出できるかを確認するという方法で評価実験を行った結果である。
1・・・関連テスト項目提示装置; 10・・・データ記憶部; 20・・・テスト結果変化データ生成部; 30・・・類似度計算部; 40・・・関連テスト項目抽出部; 50・・・関連テスト項目表示部;

Claims (3)

  1. テスト項目を特定する情報と、当該テスト項目の実行対象のソフトウエアのバージョンを示す情報と、前記バージョンに対する当該テスト項目の実行の結果であるテスト結果とを有するテスト結果データから、一つのテスト項目を各バージョンのソフトウエアに実施したテスト結果の変化の有無を表す情報を有するテスト結果変化データを生成する生成手段と、
    前記テスト結果変化データに基づいて、テスト項目間の類似度を算出する算出手段と、
    前記類似度に基づいて関連テスト項目を抽出する抽出手段と
    を有する関連テスト項目提示装置。
  2. 前記算出手段は、前記テスト結果変化データから2つのテスト項目間について存在する同タイミング変化パターンの個数に基づいて、類似度を算出する請求項1の関連テスト項目提示装置。
  3. 前記算出手段は、テスト結果変化データのそれぞれのレコードを、対応するテスト項目のベクトルとして扱い、2つのテスト項目のベクトルのコサイン類似度を計算し、得られた値を当該2つのテスト項目の類似度とする、請求項1の関連テスト項目提示装置。
JP2012002178A 2012-01-10 2012-01-10 関連テスト項目提示装置 Expired - Fee Related JP5300992B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012002178A JP5300992B2 (ja) 2012-01-10 2012-01-10 関連テスト項目提示装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012002178A JP5300992B2 (ja) 2012-01-10 2012-01-10 関連テスト項目提示装置

Publications (2)

Publication Number Publication Date
JP2013142967A JP2013142967A (ja) 2013-07-22
JP5300992B2 true JP5300992B2 (ja) 2013-09-25

Family

ID=49039511

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012002178A Expired - Fee Related JP5300992B2 (ja) 2012-01-10 2012-01-10 関連テスト項目提示装置

Country Status (1)

Country Link
JP (1) JP5300992B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6409577B2 (ja) 2015-01-05 2018-10-24 富士通株式会社 テスト選択プログラム、テスト選択方法、及びテスト選択装置
JP6615071B2 (ja) * 2016-09-01 2019-12-04 株式会社日立製作所 計算機システム及びテストケース管理方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2147036A1 (en) * 1994-05-16 1995-11-17 Yih-Farn Robin Chen System and method for selective regression testing
JP2006163519A (ja) * 2004-12-02 2006-06-22 Sharp Corp 試験選択方法および試験選択装置

Also Published As

Publication number Publication date
JP2013142967A (ja) 2013-07-22

Similar Documents

Publication Publication Date Title
US7913230B2 (en) Computer-implemented methods and systems for generating software testing documentation and test results management system using same
US9454466B2 (en) Explaining partially illegal combinations in combinatorial models
CN113168339A (zh) 软件测试
Montalvillo et al. Requirement-driven evolution in software product lines: A systematic mapping study
JP2005284751A (ja) 論理検証装置、論理検証方法および論理検証プログラム
JP5665128B2 (ja) 静的解析支援装置、静的解析支援方法、及びプログラム
JP6542612B2 (ja) テストシナリオ生成支援装置およびテストシナリオ生成支援方法
US20140214396A1 (en) Specification properties creation for a visual model of a system
US10871951B2 (en) Code correction
US20160048308A1 (en) Automatic flowchart-based webpage generation for troubleshooting or task completion without manual programming
JP5300992B2 (ja) 関連テスト項目提示装置
US8056040B2 (en) Method and system for visual implementation of layout structures for an integrated circuit
EP2063368A2 (en) Counter example analysis support apparatus
JP6310865B2 (ja) ソースコード評価システム及び方法
Aung et al. Interactive traceability links visualization using hierarchical trace map
CN111160843B (zh) 产品数据管理系统中图与文档自检方法
US20230059609A1 (en) Assistance information generation device, assistance information generation method, and program recording medium
JP5319643B2 (ja) ソフトウェアプロダクトライン開発支援装置およびその方法
JP5686826B2 (ja) 査読結果表生成装置及び査読結果表生成プログラム
JP5504212B2 (ja) テストケース自動生成システム、テストケース自動生成方法、およびテストケース自動生成プログラム
Chomal et al. Software template for evaluating and scoring software project documentations
US20120095969A1 (en) System, method and computer program product for collecting and managing alloy verification
CN113220596B (zh) 应用的测试方法、装置、设备、存储介质及程序产品
JP7322533B2 (ja) 情報処理装置、情報処理方法、情報処理システム及びプログラム
Chomal et al. Software Quality Improvement by Documentation-Knowledge Management Model

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130528

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130618

LAPS Cancellation because of no payment of annual fees