(57)【要約】【課題】システムに発生するバグの収束の判定をより正確に行うことが可能なソフトウェア品質判定方法を提供する。【解決手段】ソフトウェア品質判定装置１は、システムの構成要素ごとに、過去に実施されたテストの実施結果であるテスト実施結果を蓄積する。ソフトウェア品質判定装置１は、テスト対象の構成要素に類似する構成要素のテスト実施結果を抽出する。ソフトウェア品質判定装置１は、テスト対象の構成要素の規模とテスト実施結果とに応じて、テスト観点ごとのテスト実施基準量を算出する。ソフトウェア品質判定装置１は、テスト観点ごとのテスト実施量がテスト観点ごとのテスト実施基準量を超えた場合に、その構成要素について、そのテスト観点のバグ収束判定を行う。【選択図】図３
2018036772.tif 000002
【特許請求の範囲】
【請求項１】
システムに対してテストを実施することで前記システムに発生するバグの収束を判定するソフトウェア品質判定方法であって、
システムを構成する複数の構成要素それぞれについて、過去に実施されたテストの実施結果であるテスト実施結果を蓄積し、
前記蓄積されたテスト実施結果から、テスト対象である第１の構成要素に対応する構成要素に関する前記テスト実施結果を抽出し、
前記第１の構成要素の規模と前記抽出されたテスト実施結果とに基づいて、前記第１の構成要素について、テストを行う際の観点であるテスト観点ごとのテストの実施量の基準となるテスト実施基準量を算出し、
前記第１の構成要素に対して前記テスト観点ごとに実施されたテストの実施量であるテスト実施量が前記テスト実施基準量を超えた場合に、前記第１の構成要素について、前記テスト観点におけるバグの収束判定を行う
ソフトウェア品質判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア品質判定方法に関する。
【背景技術】
【０００２】
特許文献１には、バグ発生実績データからシステムに将来発生するバグ件数を予測し、予測したバグ件数と品質指標とに基づいて、バグの発生が収束する収束時期を予測するバグ収束予測装置が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１７４８９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
テストを実施することによってバグの発生の収束を判定する場合、テストを行う際の観点であるテスト観点ごとに、システムに対してテストが実施されることがある。システムは複数の構成要素から構成されていることが多いが、構成要素ごとに、構成要素の特性は異なる。そして、構成要素の特性に応じて、テスト観点についてバグの検出のしやすさが異なり得る。したがって、特許文献１にかかる技術では、あるテスト観点についてテストを実施する際に、バグの発生が収束する前にテストを終了してしまったり、バグが十分に収束しているのにも関わらず過度にテストを継続してしまったりするおそれがある。
【０００５】
本発明は、システムに発生するバグの収束の判定をより正確に行うことが可能なソフトウェア品質判定方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明にかかるソフトウェア品質判定方法は、システムに対してテストを実施することで前記システムに発生するバグの収束を判定するソフトウェア品質判定方法であって、システムを構成する複数の構成要素それぞれについて、過去に実施されたテストの実施結果であるテスト実施結果を蓄積し、前記蓄積されたテスト実施結果から、テスト対象である第１の構成要素に対応する構成要素に関する前記テスト実施結果を抽出し、前記第１の構成要素の規模と前記抽出されたテスト実施結果とに基づいて、前記第１の構成要素について、テストを行う際の観点であるテスト観点ごとのテストの実施量の基準となるテスト実施基準量を算出し、前記第１の構成要素に対して前記テスト観点ごとに実施されたテストの実施量であるテスト実施量が前記テスト実施基準量を超えた場合に、前記第１の構成要素について、前記テスト観点におけるバグの収束判定を行う。
【発明の効果】
【０００７】
本発明によれば、システムに発生するバグの収束の判定をより正確に行うことが可能なソフトウェア品質判定方法を提供できる。
【図面の簡単な説明】
【０００８】
【図１】実施の形態１にかかるソフトウェア品質判定装置を示す図である。
【図２】ソフトウェア品質判定装置によって判定される対象であるソフトウェアシステムの構成を例示する図である。
【図３】実施の形態１にかかるソフトウェア品質判定方法を示すフローチャートである。
【図４】構成要素ごとのバグ密度を例示する図である。
【図５】ある構成要素についてのテスト観点ごとのバグ比率及びバグ検出率を例示する図である。
【図６】テスト観点の別の例を示す図である。
【図７】ソフトウェア品質判定装置によって判定される対象であるソフトウェアシステムの構成を例示する図である。
【図８】図７に示すソフトウェアシステムの各構成要素についての、テスト観点ごとのバグ比率を例示する図である。
【発明を実施するための形態】
【０００９】
（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。
図１は、実施の形態１にかかるソフトウェア品質判定装置１を示す図である。また、図２は、ソフトウェア品質判定装置１によって判定される対象であるソフトウェアシステム９０の構成を例示する図である。
【００１０】
実施の形態１にかかるソフトウェア品質判定装置１は、システム（ソフトウェアシステム）に発生するバグの収束の判定を、システムの構成要素の特徴に応じた適切な量のテストを実施した後で開始することが可能である。ソフトウェア品質判定装置１は、ソフトウェアシステムを構成する複数の構成要素それぞれについて、テスト観点ごとに、過去のテスト実施結果とその構成要素の規模とに応じたテスト実施基準量を算出する。そして、ソフトウェア品質判定装置１は、テスト観点ごとに実施されたテストの実施量であるテスト実施量がテスト実施基準量を超えた場合に、バグの収束判定を行う。以下、詳述する。
【００１１】
図１に示すように、ソフトウェア品質判定装置１は、蓄積部１０、選択部１２、抽出部１４、規模取得部１６、バグ数推定部１８、実施基準量算出部２０、実施量取得部２２、及びバグ収束判定部２４を有する。なお、ソフトウェア品質判定装置１の各構成部分は、物理的に１つの装置で実現されてもよいし、複数の装置で実現されてもよい。
【００１２】
また、図２に例示するように、ソフトウェアシステム９０は、構成要素Ａ、構成要素Ｂ及び構成要素Ｃを含む。ソフトウェア品質判定装置１は、構成要素Ａについて上記処理を行い、構成要素Ｂについて上記処理を行い、構成要素Ｃについて上記処理を行う。ここで、「システムの構成要素」とは、そのシステムが実現する機能（機能モジュール）に対応する。例えば、ソフトウェアシステム９０が、機能Ａ、機能Ｂ及び機能Ｃを実現する場合、構成要素Ａ、構成要素Ｂ及び構成要素Ｃは、それぞれ、機能Ａ、機能Ｂ及び機能Ｃを実現し得る。
【００１３】
ソフトウェア品質判定装置１は、ＣＰＵ（Central Processing Unit）等のプロセッサ、メモリ等の記憶装置、ユーザインタフェース及び各種周辺回路によって構成されている。つまり、ソフトウェア品質判定装置１は、コンピュータとしての機能を有する。また、ソフトウェア品質判定装置１は、記憶装置に格納されたプログラムをプロセッサが実行することによって、蓄積部１０、選択部１２、抽出部１４、規模取得部１６、バグ数推定部１８、実施基準量算出部２０、実施量取得部２２及びバグ収束判定部２４といった構成部分を実現する。また、ソフトウェア品質判定装置１の各構成部分は、プログラムによるソフトウェアで実現することに限ることなく、ハードウェア、ファームウェア、及びソフトウェアのうちのいずれかの組み合わせ等により実現してもよい。また、ソフトウェア品質判定装置１の各構成部分は、例えばＦＰＧＡ（field-programmable gate array）又はマイコン等の、使用者がプログラミング可能な集積回路を用いて実現してもよい。この場合、この集積回路を用いて、上記の各構成部分から構成されるプログラムを実現してもよい。
【００１４】
なお、「構成要素の規模」とは、構成要素のボリューム及び複雑さを示す指標である。「構成要素の規模」は、例えば、そのシステムのプログラムのソースコード規模（実行コード行数など）、ソースコードの複雑さを示すソースコード複雑度、ＦＰ（Function Point）などによって示され得る。なお、複雑度は、プログラムの複雑度を計測するときに使用される循環的複雑度（Cyclomatic complexity）であってもよい。構成要素の規模は、既存の方法によって、構成要素ごとに算出され得る。
【００１５】
また、「テスト観点」とは、テストを行う際の観点である。より具体的には、「テスト観点」とは、例えば、プログラムが正常に動作するか否かを確認するための、テスト項目、着眼点、発想方法といった、テストを行う上での「切り口」であり、テストを実施するときの操作及び手順の着眼点である。このテスト観点を適切に設定することで、プログラムのバグを十分に発見することができる。テスト観点の例としては、後述する図５に例示するような、ＩＳＯ９１２６で定義される品質特性の指標である「機能性」、「効率性」及び「信頼性」等がある。また、別のテスト観点の例としては、後述する図６に例示するような、テスト対象のシステムの特性に応じてバグが発見されやすい動作を定義したものであってもよい。
【００１６】
蓄積部１０は、システムの構成要素ごとに、過去に実施されたテストの実施結果であるテスト実施結果を蓄積するデータベースである。つまり、図２の例では、蓄積部１０は、構成要素Ａ、構成要素Ｂ及び構成要素Ｃのそれぞれについて、テスト実施結果を蓄積する。蓄積部１０は、テスト実施結果と、そのテスト実施結果に関する構成要素とを対応付けて記憶する。蓄積部１０に蓄積されるテスト実施結果は、システムに対してテストが実施されるごとに更新される。
【００１７】
テスト実施結果は、「テスト観点ごとのバグ比率」、「バグ密度」、及び「テスト観点ごとのバグ検出率」を示すデータを含み得る。「テスト観点ごとのバグ比率」は、テスト実施結果に関する構成要素について、あるテスト観点でテストを行って検出されたバグの数（バグ数）の、その構成要素について検出されたバグの総数（バグ総数）に対する割合である。つまり、「テスト観点ごとのバグ比率」は、以下の式（１）で定義される。
［式（１）］
「テスト観点ごとのバグ比率」＝「あるテスト観点におけるバグ検出数」／「バグ総数」
ここで、「あるテスト観点におけるバグ検出数」は、そのテスト観点でテストを実施してバグが収束したときのバグ検出数である。また、「バグ総数」は、テスト観点ごとのバグ検出数を、全てのテスト観点について合計した数である。
【００１８】
また、「バグ密度」は、テスト実施結果に関する構成要素におけるバグの密度である。「バグ密度」は、以下の式（２）で定義される。
［式（２）］
「バグ密度」＝「バグ総数」／「構成要素の規模」
【００１９】
また、「テスト観点ごとのバグ検出率」は、テスト実施結果に関する構成要素について、あるテスト観点でテストを行って検出されたバグ数の、そのテスト観点におけるテスト実施量に対する比率である。「テスト観点ごとのバグ検出率」は、以下の式（３）で定義される。
［式（３）］
「テスト観点ごとのバグ検出率」＝「あるテスト観点におけるバグ検出数」／「あるテスト観点のテスト実施量」
【００２０】
ここで、「テスト実施量」とは、そのテスト観点で実施されたテストの量であり、具体的には、そのテスト観点でテストを実施してバグが収束したときのテスト量である。テスト実施量は、例えば、テスト件数又はテスト実施工数である。テスト件数は、テスト設計書に記載されたテスト項目のうち、実施されたテスト項目の件数である。また、テスト実施工数は、テストを実施した時間（工数）である。例えば、あるテストを２人で２時間行った場合、そのテスト実施工数は４時間（２＊２＝４［Ｈ］）となる。テスト設計書がある場合は、テスト実施量として、消化されたテスト項目数（テスト件数）が計測され得る。一方、テスト設計書がない場合は、テスト項目数を計測できないので、テスト実施量として、テストが実施された時間が計測される。なお、「テスト」は、ソフトウェアレビューを含む。したがって、テスト実施量は、レビュー実施工数であってもよい。
【００２１】
なお、蓄積部１０は、「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」のそのものを示すデータを蓄積していなくてもよい。蓄積部１０は、計算により「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」を求めることができる値を蓄積してもよい。つまり、蓄積部１０は、構成要素ごとに、「あるテスト観点におけるバグ検出数」、「バグ総数」、「構成要素の規模」、及び「あるテスト観点のテスト実施量」を蓄積してもよい。
【００２２】
選択部１２は、蓄積部１０に蓄積されたテスト実施結果に関する構成要素のうち、テスト対象の構成要素（第１の構成要素）に対応する構成要素を選択する。選択部１２は、例えばユーザインタフェースである。ユーザは、そのユーザインタフェースを操作して、蓄積部１０に蓄積されたテスト実施結果に関する構成要素のうち、テスト対象の構成要素に類似する構成要素を選択する。例えば、蓄積部１０が、構成要素Ａに関するテスト実施結果、構成要素Ｂに関するテスト実施結果、及び構成要素Ｃに関するテスト実施結果を蓄積しているとする。この場合に、テスト対象の構成要素Ａ１が構成要素Ａに類似しているとき、選択部１２は、構成要素Ａを選択する。ここで、「類似する構成要素」とは、互いの構成要素の特性が同じ構成要素であり得る。したがって、ユーザは、テスト対象の構成要素Ａ１の特性が構成要素Ａの特性と同じであるとき、選択部１２を用いて、構成要素Ａを選択する。
【００２３】
抽出部１４は、選択部１２によって選択された構成要素に関するテスト実施結果を、蓄積部１０から抽出する。例えば、選択部１２によって構成要素Ａが選択された場合、抽出部１４は、構成要素Ａに関するテスト実施結果を抽出する。抽出部１４は、抽出されたテスト実施結果をバグ数推定部１８及び実施基準量算出部２０に対して出力する。
【００２４】
規模取得部１６は、テスト対象の構成要素の規模を取得する。規模取得部１６は、テスト対象のソフトウェアシステムから、テスト対象の構成要素のソースコード規模等の規模を算出してもよい。また、規模取得部１６は、他の装置によって算出された構成要素の規模を受け付けてもよい。
【００２５】
バグ数推定部１８は、テスト対象の構成要素の規模と、抽出されたテスト実施結果とに応じて、「テスト対象の構成要素のテスト観点ごとのバグ数」を推定する。バグ数推定部１８は、推定された「テスト対象の構成要素のテスト観点ごとのバグ数」を、実施基準量算出部２０に対して出力する。
【００２６】
具体的には、バグ数推定部１８は、以下の式（４）により、テスト対象の構成要素の規模と、抽出されたテスト実施結果に含まれる「バグ密度」とから、テスト対象の構成要素のバグ総数を算出する。
［式（４）］
「テスト対象の構成要素のバグ総数」＝「バグ密度」＊「テスト対象の構成要素の規模」
【００２７】
次に、バグ数推定部１８は、以下の式（５）により、式（４）で算出された「テスト対象の構成要素のバグ総数」と、抽出されたテスト実施結果に含まれる「テスト観点ごとのバグ比率」とから、「テスト対象の構成要素のテスト観点ごとのバグ数」を算出する。
［式（５）］
「テスト対象の構成要素のテスト観点ごとのバグ数」＝「テスト対象の構成要素のバグ総数」＊「テスト観点ごとのバグ比率」
【００２８】
実施基準量算出部２０は、バグ数推定部１８によって算出された「テスト対象の構成要素のテスト観点ごとのバグ数」と、抽出されたテスト実施結果とに応じて、「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」を算出する。実施基準量算出部２０は、算出された「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」を、バグ収束判定部２４に対して出力する。ここで、「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」とは、テスト対象の構成要素のテスト観点ごとのテストの実施量の基準となる量である。
【００２９】
具体的には、実施基準量算出部２０は、以下の式（６）により、「テスト対象の構成要素のテスト観点ごとのバグ数」と、抽出されたテスト実施結果に含まれる「テスト観点ごとのバグ検出率」とから、「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」を算出する。
［式（６）］
「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」＝「テスト対象の構成要素のテスト観点ごとのバグ数」／「テスト観点ごとのバグ検出率」
【００３０】
ここで、特性が同じ構成要素の機能及び性能は、概ね同じである傾向にある。したがって、「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」は、特性が同じ構成要素について、概ね同じ傾向となり得る。言い換えると、ある構成要素の「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」は、それぞれ、特性が同じ構成要素の「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」と、概ね同じとなり得る。したがって、本実施の形態においては、テスト対象の構成要素に類似する構成要素に関する過去の実績値であるテスト実施結果を用いて、テスト実施基準量を算出することができる。
【００３１】
また、ある機能に関する構成要素に含まれるバグ総数は、構成要素の規模に応じて概ね定まっている。つまり、構成要素の規模が大きければ、バグ総数は多くなる傾向となる。さらに、構成要素の規模が大きければ、テスト実施量は増加する傾向となる。したがって、「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」は、その構成要素と同じ特性を有する構成要素の「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」と、テスト対象の構成要素の規模とから、テスト観点ごとに求められ得る。
【００３２】
実施量取得部２２は、テスト対象の構成要素に対してテスト観点ごとに実施されたテストの実施量（テスト実施量）を取得する。実施量取得部２２は、取得されたテスト実施量を、バグ収束判定部２４に対して出力する。ここで、実施量取得部２２は、ユーザインタフェースを用いてユーザがテスト実施量を入力することで、テスト実施量を取得してもよい。また、実施量取得部２２は、自動的にテスト実施量を計測することで、テスト実施量を取得してもよい。
【００３３】
バグ収束判定部２４は、実施量取得部２２によって取得されたテスト実施量が、実施基準量算出部２０によって算出されたテスト実施基準量を超えたか否かを判定する。そして、バグ収束判定部２４は、取得されたテスト実施量が算出されたテスト実施基準量を超えた場合に、その構成要素について、そのテスト観点のバグ収束判定を開始する。ここで、バグ収束判定部２４は、テスト実施量とバグの累積値との関係を示すバグ曲線の傾きによって、バグの発生が収束したか否かを判定してもよい。また、バグ収束判定部２４は、テスト期間（テストが実施された期間、つまり「テスト実施量」に対応する）の１／３程度のバグ曲線の傾きに対して、収束判定の対象となるテスト期間のバグ曲線の傾きがＸ％（Ｘは予め定められた値）となっている場合にバグの発生が収束していると判定してもよい。また、バグ収束判定部２４は、過去の実績値（構成要素の規模に対するバグの数）を基準として設定された目標バグ数と、累積バグ数との差が一定数以内であるか否かによって、バグの発生の収束を判定してもよい。
【００３４】
図３は、実施の形態１にかかるソフトウェア品質判定方法を示すフローチャートである。ソフトウェア品質判定装置１の蓄積部１０は、システムの構成要素ごとにテスト実施結果を蓄積する（ステップＳ１００）。この蓄積処理は、テストが実施されるごとに行われる。ソフトウェア品質判定装置１は、テスト対象の構成要素に類似する構成要素のテスト実施結果を抽出する（ステップＳ１０２）。具体的には、抽出部１４は、選択部１２によって選択された、テスト対象の構成要素に類似する構成要素に関するテスト実施結果を、蓄積部１０から抽出する。ここで、テスト実施結果には、「テスト観点ごとのバグ比率」、「バグ密度」及び「テスト観点ごとのバグ検出率」が含まれる。
【００３５】
次に、ソフトウェア品質判定装置１は、テスト対象の構成要素の規模とテスト実施結果とに応じて、「テスト観点ごとのテスト実施基準量」を算出する（ステップＳ１０４）。具体的には、規模取得部１６は、テスト対象の構成要素の規模を取得する。また、バグ数推定部１８は、テスト対象の構成要素の規模と、抽出されたテスト実施結果とに応じて、上記の式（４）及び式（５）を用いて、「テスト対象の構成要素のテスト観点ごとのバグ数」を算出する。そして、実施基準量算出部２０は、算出された「テスト対象の構成要素のテスト観点ごとのバグ数」と、抽出されたテスト実施結果とに応じて、上記の式（６）を用いて、「テスト対象の構成要素のテスト観点ごとのテスト実施基準量」を算出する。
【００３６】
ソフトウェア品質判定装置１は、「テスト観点ごとのテスト実施量」を取得する（ステップＳ１０６）。具体的には、実施量取得部２２は、テスト対象の構成要素に対してテスト観点ごとに実施されたテストの実施量を取得する。そして、ソフトウェア品質判定装置１のバグ収束判定部２４は、テスト観点ごとのテスト実施量がテスト観点ごとのテスト実施基準量を超えたか否かを判定する（ステップＳ１０８）。
【００３７】
テスト観点ごとのテスト実施量がテスト観点ごとのテスト実施基準量を超えた場合（Ｓ１０８のＹＥＳ）、バグ収束判定部２４は、その構成要素について、そのテスト観点のバグ収束判定を行う（ステップＳ１１０）。一方、テスト観点ごとのテスト実施量がテスト観点ごとのテスト実施基準量を超えていない場合（Ｓ１０８のＮＯ）、Ｓ１０６の工程に戻り、再度、テスト観点ごとのテスト実施量が取得される。
【００３８】
なお、バグの収束判定が行われた場合、蓄積部１０は、テスト実施結果として、テストが実施された構成要素ごとに、実施されたテストのテスト観点について、「テスト観点ごとのバグ比率」、「バグ密度」、及び「テスト観点ごとのバグ検出率」を含むデータを蓄積する。これにより、蓄積部１０に蓄積されるテスト実施結果は更新される。ここで、初期の段階では、ソフトウェア品質判定装置１はバグの収束判定を行っていない。したがって、この場合は、テスト観点ごとに生成されたバグ曲線を用いて、バグ曲線の傾きが一定以下となったときにバグの発生が収束したとみなし、そのときの上記値を蓄積部１０が蓄積する。
【００３９】
ソフトウェアシステムを構成する構成要素ごとに、その特性は異なる。例えば、ロボット制御に関するソフトウェアシステムが、ＵＩ（User Interface）に関する構成要素Ａと、センシングに関する構成要素Ｂと、制御コントロールに関する構成要素Ｃとを有するとする。このとき、構成要素Ａ、構成要素Ｂ及び構成要素Ｃそれぞれの特性は、互いに異なる。一方、バグを検出する際、バグの検出漏れを抑制するために、ユーザビリティに関するテスト観点Ｘ、又は電気ノイズなど外乱などを加えるテストに関するテスト観点Ｙといったような、様々なテスト観点でテストが実施される。このとき、構成要素Ａでは、テスト観点Ｘでテストを実施したときに、有効にバグを検出することができる可能性があるが、テスト観点Ｙでテストを実施したときは、有効にバグを検出することができない可能性がある。一方、構成要素Ｃでは、テスト観点Ｘでテストを実施したときに、有効にバグを検出することができない可能性があるが、テスト観点Ｙでテストを実施したときは、有効にバグを検出することができる可能性がある。つまり、構成要素の特性に応じて、テスト観点ごとのバグの検出のしやすさが異なる。
【００４０】
システム全体に対してテスト観点ごとにテストが実施される場合、そのシステムを構成する全ての構成要素に対して、そのテスト観点でテストが実施される。この場合、全ての構成要素に対して、同じテスト実施量のテストが実施される可能性がある。上記の例では、テスト観点Ｘでテストを実施する際、構成要素Ａと構成要素Ｃとで、同じテスト実施量のテストが実施される。この場合、構成要素Ａでは、比較的少ないテスト実施量でバグの発生が収束する可能性があるのに対し、構成要素Ｃでは、膨大な実施量でテストを行わないとバグの発生が収束しない可能性又は膨大な実施量でテストを行ってもバグの発生が収束しない可能性がある。したがって、システム全体に対してテスト観点ごとにテストが実施される場合、バグの発生が収束する前にテストを終了してしまったり、バグが十分に収束しているのにも関わらず過度にテストを継続してしまったりするおそれがある。
【００４１】
これに対し、本実施の形態にかかるソフトウェア品質判定装置１は、システムを構成する構成要素それぞれについて、テスト観点ごとに、構成要素の特性に応じたテスト実施基準量を算出している。そして、本実施の形態にかかるソフトウェア品質判定装置１は、テスト実施量がテスト実施基準量を超えた場合にバグの収束の判定を開始する。したがって、本実施の形態にかかるソフトウェア品質判定装置１は、システムに発生するバグの収束の判定を、システムの構成要素の特性に応じた適切な量でテストを実施した後で開始することが可能である。さらに、本実施の形態にかかるソフトウェア品質判定装置１は、システムの構成要素の特性に応じた適切なテスト観点でテストを実施して、バグの収束の判定を行うことが可能である。これにより、本実施の形態にかかるソフトウェア品質判定装置１及びソフトウェア品質判定方法は、より正確にバグの収束の判定を行うことが可能となる。
【００４２】
さらに、本実施の形態にかかるソフトウェア品質判定装置１は、上記のように構成されていることによって、システムに対するテストを、構成要素ごとに容易に行うことが可能となる。システムの規模が増大すると、システムに対するテストは、複数のチーム（組織）によって分担して実施されることが多い。したがって、本実施の形態にかかるソフトウェア品質判定方法によって、チームＡが構成要素Ａのテストを行い、チームＢが構成要素Ｂのテストを行うといったテストの分担を、より容易に行うことが可能となる。したがって、本実施の形態にかかるソフトウェア品質判定方法によって、規模の大きなシステムのテストをより容易に行うことが可能となる。
【００４３】
（具体例）
以下、図を参照して本実施の形態の具体例について説明する。
図４は、構成要素ごとのバグ密度を例示する図である。また、図５は、ある構成要素についてのテスト観点ごとのバグ比率及びバグ検出率を例示する図である。図４には、構成要素Ａ〜Ｃそれぞれのバグ密度が示されている。また、図５には、構成要素Ｂについてのテスト観点ごとのバグ比率及びバグ検出率が示されている。
【００４４】
図５には、テスト観点の例として、ＩＳＯ９１２６で定義される品質特性の指標である「機能性」、「効率性」、「信頼性」、「使用性」、「保守性」及び「可搬性」が挙げられている。また、図４及び図５に例示された値は、テスト実施結果として、蓄積部１０に蓄積されている。なお、図４に示すバグ密度は、各構成要素のソースコードの千行に対するバグの総数である。また、図５に示すバグ比率の単位は「％」である。また、バグ検出率は、テスト実施工数［単位：時間（Ｈ）］に対するバグ検出数である。
【００４５】
図４及び図５に示した例において、「構成要素Ｂ」に対する、テスト観点「機能性」についてのテスト実施基準量の算出について説明する。ソースコードの行数に対応する構成要素Ｂの規模をＭｂ［単位：千行］とすると、バグ数推定部１８は、上記の式（５）により、構成要素Ｂのテスト観点「機能性」についてのバグ数を、０．６＊Ｍｂ＊０．５＝０．３＊Ｍｂと求めることができる。そして、実施基準量算出部２０は、上記の式（６）により、構成要素Ｂのテスト観点「機能性」についてのテスト実施基準量を、０．３＊Ｍｂ／２．１≒０．１４＊Ｍｂ［時間］と求めることができる。したがって、ソフトウェア品質判定装置１を用いて、構成要素Ｂの規模に応じて、テスト観点「機能性」についてバグの収束を判定するまでに、適切な実施量でテストを実施することが可能となる。
【００４６】
図６は、テスト観点の別の例を示す図である。図６には、テスト観点として、テスト対象のシステムの特性に応じてバグが発見されやすい動作（カテゴリ）を定義したものが挙げられている。具体的には、図６には、テスト観点として、「同値」、「境界値」、「状態」、「論理」、「組み合わせ」、「タイミング」、「中断」、「繰り返し」、「順序」、「例外」、「異常入力」、「矛盾設定」、「切断再接続」、「負荷」、「性能」、「ユーザビリティ」、「意地悪」及び「同期」が挙げられている。なお、図６に示すテスト観点は、単なる例示であって、他のテスト観点でテストを実施してもよいことは言うまでもない。
【００４７】
図７に示すソフトウェアシステム９５の各構成要素についての、図６に例示したテスト観点ごとのバグ比率について説明する。図７は、ソフトウェア品質判定装置１によって判定される対象であるソフトウェアシステム９５の構成を例示する図である。ここで、構成要素ＡはＵＩ機能を有し、構成要素Ｂは制御機能を有し、構成要素Ｃはデバイスドライバ機能を有するとする。
【００４８】
図８は、図７に示すソフトウェアシステム９５の各構成要素についての、テスト観点ごとのバグ比率を例示する図である。図８に示すように、構成要素Ａについては、テスト観点「ユーザビリティ」のバグ比率が最も大きい。また、構成要素Ｂについては、テスト観点「繰り返し」のバグ比率が最も大きい。また、構成要素Ｃについては、テスト観点「中断（再開も含む）」及び「異常入力」等のバグ比率が比較的大きい。
【００４９】
このように、構成要素ごとに、その構成要素の特性に応じて、バグが発見されやすいテスト観点が存在する。例えば、構成要素Ａでは、バグが発見されやすいテスト観点は、テスト観点「ユーザビリティ」であり、構成要素Ｂでは、バグが発見されやすいテスト観点は、テスト観点「繰り返し」である。ソフトウェア品質判定装置１は、このような構成要素それぞれの特性に応じて、テスト観点ごとに、適切なテスト実施基準量を算出することができる。なお、構成要素Ａでは、バグが検出されたテスト観点は、「ユーザビリティ」、「タイミング」及び「中断」である。したがって、ソフトウェア品質判定装置１は、構成要素Ａについてのテストを、テスト観点「ユーザビリティ」、「タイミング」及び「中断」についてのテスト量を多く設定し、その他のテスト観点についてのテスト量を少なく設定して、実施してもよい。このように、テスト観点に応じてリソースを割り振ることができる。例えば、まず初めに、不具合を発見するためのテストとして、テスト観点「ユーザビリティ」、「タイミング」及び「中断」についてのテストを実施し、その後、品質保証のために、不具合が出る可能性の少ない「その他のテスト観点」についても網羅的にテストを実施してもよい。このように、実施の形態１にかかるソフトウェア品質判定装置１を用いて、効率的にテストを実施することが可能となる。
【００５０】
（変形例）
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、テスト観点は、図５及び図６に例示したものに限られず、バグの検出に寄与し得る任意のものであってもよい。
【００５１】
また、ソフトウェア品質判定装置１の構成は、上述したものに限られない。例えば、規模取得部１６、バグ数推定部１８及び実施基準量算出部２０は、１つの構成部分であってもよい。例えば、実施基準量算出部２０が、システムの各構成要素の規模を取得して、「テスト対象の構成要素のテスト観点ごとのバグ数」を算出し、テスト実施基準量を算出してもよい。また、バグ収束判定部２４は、実施量取得部２２の機能を有してもよい。つまり、バグ収束判定部２４が、テスト実施量を取得してもよい。
【００５２】
また、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【符号の説明】
【００５３】
１  ソフトウェア品質判定装置
１０  蓄積部
１２  選択部
１４  抽出部
１６  規模取得部
１８  バグ数推定部
２０  実施基準量算出部
２２  実施量取得部
２４  バグ収束判定部
【図１】
2018036772.tif 000003
【図２】
2018036772.tif 000004
【図３】
2018036772.tif 000005
【図４】
2018036772.tif 000006
【図５】
2018036772.tif 000007
【図６】
2018036772.tif 000008
【図７】
2018036772.tif 000009
【図８】
2018036772.tif 000010