(57)【要約】【課題】構成要素毎のバグ収束の判定結果を、比較し易いように表示すること。【解決手段】ソフトウェア品質判定装置は、システムを構成する構成要素毎及びシステムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定するバグ収束判定部と、構成要素毎及びテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示部と、を備える。バグ収束判定部は、構成要素毎及びテスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定する。構成要素毎及びテスト観点毎の実施量及び実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている。【選択図】図１
2019101582.tif 000002
【特許請求の範囲】
【請求項１】
システムに発生するバグの収束を判定するソフトウェア品質判定装置であって、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定するバグ収束判定部と、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示部と、を備え、
前記バグ収束判定部は、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている、ソフトウェア品質判定装置。
【請求項２】
前記構成要素の規模は、ソースコードの規模、ソースコードの複雑度を表す指標、ファンクションポイントのいずれかである、請求項１に記載のソフトウェア品質判定装置。
【請求項３】
前記構成要素毎に、該構成要素が実施すべき前記テスト観点が予め設定されており、
前記バグ収束判定部は、前記構成要素毎及び該構成要素が実施すべき前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記表示部は、前記構成要素毎及び該構成要素が実施すべき前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する、請求項１又は２に記載のソフトウェア品質判定装置。
【請求項４】
システムに発生するバグの収束を判定するソフトウェア品質判定装置によるソフトウェア品質判定方法であって、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定する判定ステップと、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示ステップと、を含み、
前記判定ステップでは、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている、ソフトウェア品質判定方法。
【請求項５】
システムに発生するバグの収束を判定するコンピュータに、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定する判定手順と、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示手順と、を実行させるためのソフトウェア品質判定プログラムであり、
前記判定手順では、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている、
ソフトウェア品質判定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムに関する。
【背景技術】
【０００２】
近年、システムに発生するバグの収束を判定する技術が提案されている。
例えば、特許文献１には、過去のバグ発生実績データからシステムに将来発生するバグ件数を予測し、予測したバグ件数とシステムに要求される品質を示す品質指標とに基づいて、バグが収束する収束時期を予測する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１７４８９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、システムを構成する構成要素毎に規模が異なる。そのため、仮に構成要素毎にバグの収束を判定し、その判定結果を並べて表示した場合、判定結果を見るユーザにとっては、各構成要素の規模が異なるため、判定結果を比較しにくいなどの問題がある。
【０００５】
本発明は、上記を鑑みなされたものであって、構成要素毎のバグ収束の判定結果を、比較し易いように表示することができるソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムを提供するものである。
【課題を解決するための手段】
【０００６】
本発明の一態様に係るソフトウェア品質判定装置は、
システムに発生するバグの収束を判定するソフトウェア品質判定装置であって、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定するバグ収束判定部と、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示部と、を備え、
前記バグ収束判定部は、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている。
【０００７】
本発明の一態様に係るソフトウェア品質判定方法は、
システムに発生するバグの収束を判定するソフトウェア品質判定装置によるソフトウェア品質判定方法であって、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定する判定ステップと、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示ステップと、を含み、
前記判定ステップでは、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている。
【０００８】
本発明の一態様に係るソフトウェア品質判定プログラムは、
システムに発生するバグの収束を判定するコンピュータに、
前記システムを構成する構成要素毎及び前記システムをテストする際の観点であるテスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定する判定手順と、
前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストで発生したバグの収束の判定結果を表示する表示手順と、を実行させるためのソフトウェア品質判定プログラムであり、
前記判定手順では、前記構成要素毎及び前記テスト観点毎に、該構成要素及び該テスト観点のテストの実施量が、該構成要素及び該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該構成要素及び該テスト観点のテストで発生したバグの収束を判定し、
前記構成要素毎及び前記テスト観点毎の前記実施量及び前記実施基準量は、該構成要素の規模を示す指標値に応じて重み付けされている。
【発明の効果】
【０００９】
上述した本発明の態様によれば、構成要素毎のバグ収束の判定結果を、比較し易いように表示することができるソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態に係るソフトウェア品質判定装置のブロック構成の一例を示すブロック図である。
【図２】実施の形態に係る構成要素の一例を示す図である。
【図３】実施の形態に係る構成要素の一例を示す図である。
【図４】実施の形態に係るテスト観点の一例を示す図である。
【図５】実施の形態に係るテスト観点の一例を示す図である。
【図６】実施の形態に係るテスト観点の一例を示す図である。
【図７】実施の形態に係るソフトウェア品質判定装置によるデータベースを更新する方法の一例を示すフロー図
【図８】実施の形態に係るバグ収束判定の判定結果を表示する方法の一例を示すフロー図である。
【図９】図８のステップＳ２１のバグ収束判定処理の一例を示すフロー図である。
【図１０】実施の形態に係る構成要素の一例を示す図である。
【図１１】実施の形態に係るデータベースに保持されている、構成要素毎の実施すべきテスト観点の一例を示す図である。
【図１２】実施の形態に係る構成要素のテスト観点のテスト結果の一例を示すグラフである。
【図１３】実施の形態に係る構成要素のテスト観点のテスト結果の一例を示すグラフである。
【図１４】実施の形態に係る構成要素毎及びテスト観点毎のバグ収束判定の判定結果の表示例を示すグラフである。
【図１５】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図１６】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図１７】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図１８】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図１９】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図２０】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図２１】構成要素毎の実施すべきテスト観点の一例を示す図である。
【図２２】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図２３】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【図２４】構成要素のテスト観点のバグ曲線の一例を示すグラフである。
【発明を実施するための形態】
【００１１】
以下、図面を参照して本発明の実施の形態について説明する。なお、以下で説明する各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。また、以下の実施の形態で示す具体的な数値などは、発明の理解を容易とするための例示にすぎず、これに限定されるものではない。
【００１２】
＜実施の形態に係るソフトウェア品質判定装置の構成＞
まず、本実施の形態に係るソフトウェア品質判定装置１の構成について説明する。
図１は、本実施の形態に係るソフトウェア品質判定装置１のブロック構成の一例を示すブロック図である。本実施の形態に係るソフトウェア品質判定装置１は、システム（テスト対象）に発生するバグの収束を判定するものである。
【００１３】
図１に示されるように、本実施の形態に係るソフトウェア品質判定装置１は、入力部１１と、データベース１２と、変更規模算出部１３と、データベース更新部１４と、バグ検出率算出部１５と、バグ収束判定部１６と、表示部１７と、を備えている。
【００１４】
入力部１１は、例えば、ユーザが任意のデータ（後述のバグ検出数やテスト実施量など）をソフトウェア品質判定装置１に入力し設定するための入力装置である。入力部１１は、例えば、キーボート、マウス、タッチスクリーン、無線携帯端末（スマートフォンやタブレットなど）などの任意の入力装置である。
【００１５】
データベース１２は、ユーザが入力部１１に入力し設定したデータなどを保持する。
例えば、データベース１２は、システムを構成する構成要素毎及びシステムをテストする際の観点であるテスト観点毎に、その構成要素及びそのテスト観点のテストで発生した、その構成要素の単位規模（以下、単位規模）当たりのバグの検出数（以下、バグ検出数）を保持する。構成要素とは、ソフトウェアの保有する機能要素、又は、ソフトウェアアーキテクチャによって分割されたソフトウェアアイテムである。テスト観点とは、例えば、プログラムが正常に動作するか否かを確認するための、テスト項目、着眼点、発想方法といった、テストを行う上での「切り口」であり、テストを実施するときの操作や手順の着眼点である。バグは、このような着眼点を変更することによって、検出できることが知られている。規模とは、ソースコードの規模、ソースコードの複雑度を表す指標、ファンクションポイント（ＦＰ：Function Point）などのいずれかである。ここで、規模は、初期状態では、構成要素の元々の規模であり、ソースコードの変更があった後は、構成要素の変更規模となる。変更規模とは、構成要素の変更前の規模と、構成要素の変更箇所（追加、削除、修正）の規模と、を加算したものである。例えば、構成要素の変更前の規模が１００行で、変更箇所の規模が３０行（例えば、追加が１０行、修正が５行、削除が１５行）である場合は、構成要素の変更規模は１３０行となる。変更規模算出部１３により構成要素毎の変更規模が算出される度に、データベース１２に保持される、構成要素毎及びテスト観点毎の単位規模当たりのバグ検出数は、データベース更新部１４により更新される。
【００１６】
また、データベース１２は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのテストの実施量（以下、テスト実施量）を保持する。テスト実施量とは、例えば、プログラムに対して実施したテストの工数（以下、テスト工数）や件数（以下、テスト件数）である。変更規模算出部１３により構成要素毎の変更規模が算出される度に、データベース１２に保持される、構成要素毎及びテスト観点毎の単位規模当たりのテスト実施量は、データベース更新部１４により更新される。
【００１７】
また、データベース１２は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのテスト実施量の基準となる実施基準量（以下、テスト実施基準量）を保持する。テスト実施基準量は、バグ収束判定部１６が、バグの収束判定を行うトリガとなる。すなわち、バグ収束判定部１６は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのテスト実施量が、その構成要素及びそのテスト観点の単位規模当たりのテスト実施基準量に到達した後に、バグの収束判定を行う。
【００１８】
このように、データベース１２に保持される、構成要素毎及びテスト観点毎のバグ検出数、テスト実施量、及びテスト実施基準量は、その構成要素の単位規模当たりの値となっており、その構成要素の規模を示す指標値に応じて重み付け（正規化）されている。
【００１９】
また、データベース１２は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点のテストで発生したバグの検出率（以下、バグ検出率）の基準となる基準値を保持する。バグ検出率は、単位規模当たりのバグ検出数を、単位規模当たりのテスト実施量で除算したものである。
【００２０】
また、データベース１２は、構成要素毎の変更規模を保持する。データベース１２は、初期状態では、構成要素毎の変更規模を保持せず、変更規模算出部１３により構成要素毎の変更規模が算出されると、その変更規模を保持する。以降、変更規模算出部１３により構成要素毎の変更規模が算出される度に、データベース１２に保持される構成要素毎の変更規模は、データベース更新部１４により更新される。
【００２１】
また、データベース１２は、構成要素毎に、その構成要素が実施すべきテスト観点として予め設定されたテスト観点を保持する。
【００２２】
変更規模算出部１３は、システムのバグ修正などに伴い、ソースコードに変更があった場合、構成要素毎の変更規模を算出する。
【００２３】
データベース更新部１４は、変更規模算出部１３で構成要素毎の変更規模が算出されると、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのバグ検出数及びテスト実施量を算出する。そして、データベース更新部１４は、データベース１２に保持されている、構成要素毎及びテスト観点毎の単位規模当たりのバグ検出数及びテスト実施量を更新する。
【００２４】
バグ検出率算出部１５は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点のバグ検出率を算出する。具体的には、バグ検出率算出部１５は、データベース１２に保持されているバグ検出数を、データベース１２に保持されているテスト実施量で除算して、バグ検出率を算出する。
【００２５】
バグ収束判定部１６は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのテスト実施量が、その構成要素及びそのテスト観点の単位規模当たりのテスト実施基準量に到達した後に、その構成要素及びそのテスト観点の単位規模当たりのテストで発生したバグの収束判定を行う。具体的には、バグ収束判定部１６は、構成要素毎及びテスト観点毎に、以下の動作を行う。すなわち、バグ収束判定部１６は、データベース１２に保持されている単位規模当たりのテスト実施量が、データベース１２に保持されている単位規模当たりのテスト実施基準量に到達したか否かを判定する。テスト実施量がテスト実施基準量に到達していれば、バグ収束判定部１６は、バグ検出率算出部１５で算出されたバグ検出率と、データベース１２に保持されているバグ検出率の基準値と、を基に、バグの収束判定を行う。例えば、バグ収束判定部１６は、テスト実施量がテスト実施基準量に到達した後に、予め設定されたタイミングの時点でバグ検出率が基準値以上であれば、バグが収束していないと判定する。さらに、バグ収束判定部１６は、バグが収束していないと判定した場合、バグ検出率と基準値との差分が閾値以上であれば、まだバグが検出されるリスクが高いと判定しても良い。
【００２６】
表示部１７は、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点について、バグ収束判定部１６で判定された判定結果を表示し、ユーザに提示する表示装置である。表示部１７は、例えば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイなどである。
【００２７】
＜実施の形態に係る構成要素＞
続いて、本実施の形態に係る構成要素の具体例について説明する。
図２に示されるように、構成要素は、ソフトウェアの保有する機能要素としても良い。例えば、あるソフトウェアでは、機能要素として、「画像処理」、「外部ＩＦ（Interface）制御」、「内部ＩＦ制御」、「ＧＵＩ（Graphical User Interface）制御」、「入出力」、「ファイル管理」、「ＧＵＩ管理」、「データ変換」、「その他」があるとする。図２の例では、これらのソフトウェアの機能要素を、構成要素としている。
【００２８】
また、図３に示されるように、構成要素は、ソフトウェアアーキテクチャによって分割されたソフトウェアアイテムとしても良い。図３の例では、ソフトウェア全体のシステムがソフトウェアアイテムＸとソフトウェアアイテムＹとに分割され、さらに、ソフトウェアアイテムＹがソフトウェアアイテムＹ−１とソフトウェアアイテムＹ−２とに分割されている。この場合、構成要素は、「ソフトウェアアイテムＸ」、「ソフトウェアアイテムＹ−１」、「ソフトウェアアイテムＹ−２」の３つとする。
【００２９】
＜実施の形態に係るテスト観点＞
続いて、本実施の形態に係るテスト観点及びテスト実施基準量の具体例について説明する。
図４に示されるように、テスト観点は、ＩＳＯ（International Organization for Standardization）９１２６の品質特性としても良い。図４の例では、テスト観点は、「機能性」、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」となっている。また、テスト観点毎の単位規模当たりのテスト実施基準量は、テスト工数／ＫＬＯＣとしても良い。図４の例では、「機能性」の単位規模当たりのテスト実施基準量をＡとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位規模当たりのテスト実施基準量は、それぞれ、０．１Ａ、０．４Ａ、０．６Ａ、１．１Ａ、０．２Ａとなっている。
【００３０】
図５の例では、結合テストの場合、「機能性」の単位開発規模当たりのテスト実施基準量をＡとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位規模当たりのテスト実施基準量は、それぞれ、０．７Ａ、０．５Ａ、０．５Ａ、０．５Ａ、０．１Ａとなっている。、また、システムテストの場合、「機能性」の単位開発規模当たりのテスト実施基準量をａとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位規模当たりのテスト実施基準量は、それぞれ、０．８ａ、０．３ａ、０．３ａ、０．１ａ、０．１ａとなっている。システムテストとは、ソフトウェア全体のテストであり、統合テスト又は総合テストとも呼ばれる。結合テストとは、一部の構成要素がない状態での全てのテストである。
【００３１】
また、テスト観点毎の単位規模当たりのテスト実施基準量は、以下の非特許文献１に記載された、単位規模当たりのテスト件数の統計データを使用しても良い。
非特許文献１：独立行政法人情報処理推進機構  技術本部  ソフトウェア高信頼化センター、「ソフトウェア開発データ白書２０１６−２０１７」、２０１６年１０月１日、第２１４頁
【００３２】
また、図６に示されるように、テスト観点は、ＯＤＣ（Orthogonal Defect Classification）分析（ＯＤＣ分析は、例えば、以下の非特許文献２を参照）でバグを発見するトリガーとなる発見トリガーとしても良い。図６の例では、テスト観点は、結合テストの場合、「基本」、「組み合わせ」、「順序・繰り返し」、「相互作用」となり、システムテストの場合、「負荷・ストレス」、「回復・例外」、「起動・再起動」、「構成」、「シナリオ」となっている。
非特許文献２：山崎隆  オリンパスソフトウェアテクノロジー株式会社、「ＯＤＣ分析による欠陥除去と品質成熟度の可視化」、Embedded Technology West 2014 IPAセミナー、２０１４年７月２９日
【００３３】
＜実施の形態に係るソフトウェア品質判定方法＞
続いて、本実施の形態に係るソフトウェア品質判定装置１によるソフトウェア品質判定方法について説明する。
まず、本実施の形態に係るソフトウェア品質判定装置１によるデータベース１２を更新する方法について説明する。
図７は、本実施の形態に係るソフトウェア品質判定装置１によるデータベース１２を更新する方法の一例を示すフロー図である。
【００３４】
図７に示されるように、データベース１２は、ユーザが入力部１１に入力し設定した以下のデータを取得し保持する（ステップＳ１１）。
・構成要素毎及びテスト観点毎の単位規模当たりのバグ検出数
・構成要素毎及びテスト観点毎の単位規模当たりのテスト実施量
・構成要素毎及びテスト観点毎の単位規模当たりのテスト実施基準量
・構成要素毎及びテスト観点毎のバグ検出率の基準値
・構成要素毎の実施すべきテスト観点
【００３５】
変更規模算出部１３は、システムのバグ修正などに伴い、ソースコードが変更されると（ステップＳ１２のＹｅｓ）、構成要素毎の変更規模を算出する（ステップＳ１３）。ソースコードに変更がなければ（ステップＳ１２のＮｏ）、ステップＳ１２の処理に戻る。
【００３６】
データベース更新部１４は、変更規模算出部１３で構成要素毎の変更規模が算出されると、構成要素毎及びテスト観点毎に、その構成要素及びそのテスト観点の単位規模当たりのバグ検出数及びテスト実施量を算出する（ステップＳ１４）。そして、データベース更新部１４は、データベース１２に保持されている、構成要素毎の変更規模を更新すると共に、データベース１２に保持されている、構成要素毎及びテスト観点毎の単位規模当たりのバグ検出数及びテスト実施量を更新する（ステップＳ１５）。なお、初期状態では、データベース１２に構成要素毎の変更規模が保持されていないため、データベース１２に構成要素毎の変更規模を新規に登録する。その後、ステップＳ１２の処理に戻る。
以降も、ソースコードが変更される度に、ステップＳ１３〜Ｓ１５の処理が行われる。
【００３７】
続いて、本実施の形態に係るソフトウェア品質判定装置１によるバグ収束判定の判定結果を表示する方法について説明する。
図８は、本実施の形態に係るバグ収束判定の判定結果を表示する方法の一例を示すフロー図である。以下で説明する処理は、データベース１２に保持されている最新のデータを用いて行われるものとする。
【００３８】
まず、バグ検出率算出部１５及びバグ収束判定部１６により、構成要素毎及びその構成要素が実施すべきテスト観点としてデータベース１２に保持されているテスト観点毎に、バグ収束を判定するためのバグ収束判定処理が行われる（ステップＳ２１）。
【００３９】
その後、表示部１７は、構成要素毎及びその構成要素が実施すべきテスト観点としてデータベース１２に保持されているテスト観点毎に、上記ステップＳ２１のバグ収束判定処理により判定されたバグ収束の判定結果を表示する（ステップＳ２２）。
【００４０】
続いて、図８のステップＳ２１のバグ収束判定処理について説明する。
図９は、図８のステップＳ２１のバグ収束判定処理の一例を示すフロー図である。なお、図９は、構成要素Ａが実施すべきテスト観点ａのバグ収束判定処理のフローの例を示している。
【００４１】
図９に示されるように、バグ収束判定部１６は、データベース１２に保持されているテスト観点ａの単位規模当たりのテスト実施量が、データベース１２に保持されているテスト観点ａの単位規模当たりのテスト実施基準量に到達したか否かを判定する（ステップＳ３１）。
【００４２】
テスト実施量がテスト実施基準量に到達していれば（ステップＳ３１のＹｅｓ）、バグ収束判定部１６は、バグ検出率算出部１５で算出されたテスト観点ａのバグ検出率と、データベース１２に保持されているテスト観点ａのバグ検出率の基準値と、を基に、テスト観点ａではバグが収束しているか否かを判定する（ステップＳ３２）。
【００４３】
例えば、バグ収束判定部１６は、テスト実施量がテスト実施基準量に到達した後に、予め設定されたタイミングの時点で、テスト観点ａのバグ検出率がテスト観点ａの基準値以上であれば、テスト観点ａではバグが収束していないと判定する。さらに、バグ収束判定部１６は、テスト観点ａではバグが収束していないと判定した場合、テスト観点ａのバグ検出率がテスト観点ａの基準値との差分が閾値以上であれば、テスト観点ａではまだバグが検出されるリスクが高いと判定しても良い。
【００４４】
テスト実施量がテスト実施基準量に到達していなければ（ステップＳ３１のＮｏ）、ステップＳ３１の処理に戻る。
【００４５】
以上がテスト観点ａのバグ収束判定処理のフローとなる。構成要素Ａにテスト観点ａ以外で実施すべき他のテスト観点が存在する場合は、他のテスト観点についても図９と同様のバグ収束判定処理のフローを実施する。
また、構成要素Ａ以外の構成要素についても、その構成要素が実施すべきテスト観点毎に、図９と同様のバグ収束判定処理のフローを実施する。
【００４６】
ここで、本実施の形態に係るソフトウェア品質判定装置１により、バグ収束の判定結果を表示する方法について具体例を挙げて説明する。ここでは、図１０に示されるように、構成要素は、「構成要素Ａ〜Ｃ」であるとする。また、図６に示されるように、ＯＤＣ分析の発見トリガーに基づき、結合テストのテスト観点は、「基本」、「組み合わせ」、「順序・繰り返し」、「相互作用」であり、システムテストのテスト観点は、「負荷・ストレス」、「回復・例外」、「起動・再起動」、「構成」、「シナリオ」であるとする。
【００４７】
まず、「構成要素Ａ〜Ｃ」毎の実施すべきテスト観点の例について説明する。
図１１は、データベース１２に保持されている、「構成要素Ａ〜Ｃ」毎の実施すべきテスト観点の一例を示す図である。なお、図１１において、「〇」が実施すべきテスト観点を示している。
【００４８】
図１１に示されるように、例えば、「構成要素Ａ」が実施すべきテスト観点は、「基本」、「組み合わせ」、「負荷・ストレス」の３つである。また、「構成要素Ｂ」が実施すべきテスト観点は、「基本」、「順序・繰り返し」、「相互作用」の３つである。また、「構成要素Ｃ」が実施すべきテスト観点は、「基本」、「相互作用」の２つである。
【００４９】
続いて、「構成要素Ａ〜Ｃ」のうち「構成要素Ｃ」のテスト観点毎のテスト結果の例について説明する。
図１２及び図１３は、「構成要素Ｃ」のテスト観点毎のテスト結果の一例を示すグラフである。図１２は「基本」、図１３は「相互作用」のテスト結果をそれぞれ示している。
【００５０】
バグ収束判定部１６は、「構成要素Ｃ」のテスト観点毎に、そのテスト観点の単位規模当たりのテスト実施量が、そのテスト観点の単位規模当たりのテスト実施基準量に到達した後に、そのテスト観点のバグ検出率及び基準値を基に、バグ収束の判定を開始する。このとき、バグ収束判定部１６は、バグ検出率が基準値以上であれば、バグが収束していないと判定する。さらに、バグ収束判定部１６は、バグが収束していないと判定した場合、バグ検出率と基準値との差分が閾値以上であれば、まだバグが検出されるリスクが大きいと判定する。ここでは、バグ収束判定部１６は、バグ検出率が基準値以上の場合は、バグが収束していないと判定すると共に、リスクが大きいと判定し（すなわち、閾値はゼロ）、その他の場合は、リスクが小さいと判定するものとする。
【００５１】
図１２に示されるように、「基本」については、単位規模当たりのテスト実施量が、単位規模当たりのテスト実施基準量に到達していない。そのため、バグ収束判定部１６は、バグ収束の判定を開始できないため、「不明」と判定する。
【００５２】
図１３に示されるように、「相互作用」については、単位規模当たりのテスト実施量が、単位規模当たりのテスト実施基準量に到達しているため、バグ収束判定部１６は、バグ収束の判定を開始する。しかし、テスト実施量がテスト実施基準量に到達した後のバグ検出率は、基準値以上となっている。そのため、バグ収束判定部１６は、「相互作用」については、バグが収束しておらず、「リスク大」と判定する。
【００５３】
バグ収束判定部１６は、「構成要素Ａ」の「基本」、「組み合わせ」、「負荷・ストレス」と、「構成要素Ｂ」の「基本」、「順序・繰り返し」、「相互作用」と、についても、上記と同様に、バグ収束の判定を行う。
【００５４】
続いて、「構成要素Ａ」、「構成要素Ｂ」、「構成要素Ｃ」毎及びテスト観点毎のバグ収束判定の判定結果の表示例について説明する。
図１４は、「構成要素Ａ」、「構成要素Ｂ」、「構成要素Ｃ」毎及びテスト観点毎のバグ収束判定の判定結果の表示例を示すグラフである。
【００５５】
図１４に示されるように、表示部１７は、「構成要素Ａ」、「構成要素Ｂ」、「構成要素Ｃ」毎及び図１１に示されるその構成要素が実施すべきテスト観点毎に、バグ収束判定部１６により判定されたバグ収束の判定結果を表示する。
【００５６】
なお、図１４においては、表示部１７は、テスト実施量がテスト実施基準量に到達していないテスト観点を「不明」と表示し、リスクが大きいテスト観点を「大」と表示し、リスクが小さいテスト観点を「小」と表示している。ただし、バグ収束の判定結果の表示方法はこれに限定されない。
【００５７】
例えば、表示部１７は、バグ収束の判定結果がリスクが「大」であるテスト観点については、「大」の代わりに、又は、「大」に追加して、バグ検出率を表示しても良いし、バグ検出率と基準量との差分を表示しても良い。
【００５８】
また、表示部１７は、バグ収束の判定結果が「不明」であるテスト観点については、「不明」の代わりに、又は、「不明」に追加して、テスト実施基準量に到達するまでに、単位規模当たりであとどれくらいのテスト実施量のテストを実施すべきかを表示しても良い。
【００５９】
また、表示部１７は、バグ収束の判定結果がリスクが「大」であるテスト観点については、「大」の代わりに、又は、「大」に追加して、バグ検出率が基準値を下回るまでに、単位規模当たりであとどれくらいのテスト実施量のテストを実施すべきかを表示しても良い。これは、バグ検出率は、単位規模当たりのバグ検出数を単位規模当たりのテスト実施量で除算したものであるため、分母（単位規模当たりのテスト実施量）が増えれば、バグ検出率が下がるためである。
【００６０】
＜バグ曲線の応用＞
ユーザは、本実施の形態に係るソフトウェア品質判定方法を、従来のバグ曲線（信頼度成長曲線とも呼ばれる）に応用して、テストを実施していないテスト観点があるか、すなわち、テスト漏れ（テスト抜けとも呼ばれる）がないかを確認することができる。
【００６１】
ここで、本実施の形態に係るソフトウェア品質判定方法を、従来のバグ曲線に応用して、テスト漏れがないかを確認する方法について、具体例を挙げて説明する。ここでは、テスト観点は、ＯＤＣ分析の発見トリガーに基づき、「基本」、「相互作用」、「操作順序」、「負荷・ストレス」、「回復・例外」、「ＧＵＩ」の６つであるものとする。
【００６２】
図１５〜図２０は、ある構成要素のテスト観点毎のバグ曲線の一例を示すグラフである。図１５は「基本」、図１６は「相互作用」、図１７は「操作順序」、図１８は「負荷・ストレス」、図１９は「回復・例外」、図２０は「ＧＵＩ」のバグ曲線をそれぞれ示している。
【００６３】
ユーザは、テスト実施量がテスト実施基準量に到達していない場合や、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値以上である場合は、バグが収束しておらず、まだバグが検出される可能性が高いと判定する（品質はＮＧ）。一方、ユーザは、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値を下回っている場合は、バグが収束しており、これからバグが検出される可能性は低いと判定する（品質はＯＫ）。
【００６４】
図１５〜図２０に示されるように、「基本」、「相互作用」、「ＧＵＩ」については、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値を下回っているため、ユーザは、品質はＯＫと判定する。一方、「操作順序」、「負荷・ストレス」、「回復・例外」については、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値以上であるため、ユーザは、品質はＮＧと判定する。
【００６５】
続いて、本実施の形態に係るソフトウェア品質判定方法を、従来のバグ曲線に応用して、テスト漏れがないかを確認する方法について、別の具体例を挙げて説明する。ここでは、構成要素は、「構成要素Ｐ〜Ｕ」の６つであるものとする。また、テスト観点は、ＯＤＣ分析の発見トリガーに基づき、「基本」、「組み合わせ」、「順序・繰り返し」、「相互作用」、「負荷・ストレス」、「回復・例外」、「構成」、「シナリオ」の８つであるものとする。
【００６６】
図２１は、「構成要素Ｐ〜Ｕ」毎の実施すべきテスト観点の一例を示す図である。なお、図２１において、「〇」が実施すべきテスト観点を示している。
図２１に示されるように、例えば、「負荷・ストレス」を実施すべき構成要素は、「構成要素Ｐ」、「構成要素Ｒ」、「構成要素Ｕ」の３つである。そのため、ユーザは、「負荷・ストレス」については、「構成要素Ｐ」、「構成要素Ｒ」、「構成要素Ｕ」のバグ収束を判定し、どの構成要素に問題があるのか確認すれば良い。
【００６７】
図２２〜図２４は、「構成要素Ｐ」、「構成要素Ｒ」、「構成要素Ｕ」毎の「負荷・ストレス」のバグ曲線の一例を示している。図２２は「構成要素Ｐ」の「負荷・ストレス」、図２３は「構成要素Ｒ」の「負荷・ストレス」、図２４は「構成要素Ｕ」の「負荷・ストレス」のバグ曲線をそれぞれ示している。
【００６８】
図２２〜図２４に示されるように、「構成要素Ｕ」については、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値を下回っているため、ユーザは、品質はＯＫと判定する。一方、「構成要素Ｐ」については、テスト実施量がテスト実施基準量に到達した後のバグ検出率が基準値以上であるため、ユーザは、品質はＮＧと判定する。また、「構成要素Ｒ」については、テスト実施量がテスト実施基準量に到達していないため、ユーザは、品質はＮＧと判定する。
従って、ユーザは、「負荷・ストレス」については、「構成要素Ｐ」、「構成要素Ｒ」が問題であることがわかる。
【００６９】
＜実施の形態の効果＞
上述したように本実施の形態によれば、構成要素毎及びテスト観点毎のテスト実施量、テスト実施基準量などは、構成要素の単位規模当たりの値とされ、構成要素の規模を示す指標値に応じて重み付けされている。バグ収束判定部１６は、構成要素毎及びテスト観点毎に、構成要素の規模で重み付けされたテスト実施量が、構成要素の規模で重み付けされたテスト実施基準量に到達した後に、バグの収束を判定し、その判定結果を表示部１７が表示する。
【００７０】
従って、表示部１７に表示されたバグ収束の判定結果を見たユーザは、規模が異なる構成要素毎の判定結果を比較し易くなる。また、構成要素毎及びテスト観点毎に、バグ収束の判定結果を表示するため、ユーザは、改善すべきテスト観点の優先順位を付けることなどができるようになる。
【００７１】
また、本実施の形態によれば、構成要素の規模は、ソースコードの規模、ソースコードの複雑度を表す指標、ファンクションポイントのいずれかであり、ソースコードに応じた量として定義されている。従って、様々な構成要素やテスト観点に対して、高い自由度で重み付けを行うことができる。
【００７２】
また、本実施の形態によれば、構成要素毎に、その構成要素が実施すべきテスト観点が予め設定されており、バグ収束判定部１６は、構成要素毎及びその構成要素が実施すべきテスト観点毎に、バグの収束を判定する。従って、特定の構成要素には効果のないテストを実施してしまうことなどを抑制することができる。
【００７３】
以上、実施の形態を参照して本発明を説明したが、本発明は、上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
例えば、上記実施の形態に係るソフトウェア品質判定装置１は、設計及び実装のレビュー工程に適用されても良い。この場合、テスト実施量をレビュー工数、規模をドキュメントのボリューム（行数、頁数、文字数など）、テスト観点をレビュー観点に置き換えて適用できる。なお、レビュー観点は、例えば、組織が有する観点表を用いても良いし、ＯＤＣ分析のレビュー工程の発見トリガーを用いても良い。
【００７４】
また、上記実施の形態に係るソフトウェア品質判定装置１は、例えば、演算処理などを行うＣＰＵ（Central Processing Unit）などのプロセッサ、プロセッサによって実行されるプログラムや各種のデータなどを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などからなるメモリ、及び、外部と信号の入出力を行うインターフェイス部（Ｉ／Ｆ）などからなるハードウェア構成のコンピュータで実現される。プロセッサ、メモリ及びインターフェイス部は、データバスなどを介して相互に接続される。
【００７５】
メモリは、データベース１２の役割を果たす。また、メモリは、変更規模算出部１３、データベース更新部１４、バグ検出率算出部１５、バグ収束判定部１６、及び表示部１７の機能を実現するプログラムを記憶し、プロセッサは、これらプログラムを実行することで、変更規模算出部１３、データベース更新部１４、バグ検出率算出部１５、バグ収束判定部１６、及び表示部１７の機能をそれぞれ実現する。
【００７６】
また、上記プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−Ｒ／Ｗ（CD-ReWritable）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバなどの有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【符号の説明】
【００７７】
１  ソフトウェア品質判定装置
１１  入力部
１２  データベース
１３  変更規模算出部
１４  データベース更新部
１５  バグ検出率算出部
１６  バグ収束判定部
１７  表示部
【図１】
2019101582.tif 000003
【図２】
2019101582.tif 000004
【図３】
2019101582.tif 000005
【図４】
2019101582.tif 000006
【図５】
2019101582.tif 000007
【図６】
2019101582.tif 000008
【図７】
2019101582.tif 000009
【図８】
2019101582.tif 000010
【図９】
2019101582.tif 000011
【図１０】
2019101582.tif 000012
【図１１】
2019101582.tif 000013
【図１２】
2019101582.tif 000014
【図１３】
2019101582.tif 000015
【図１４】
2019101582.tif 000016
【図１５】
2019101582.tif 000017
【図１６】
2019101582.tif 000018
【図１７】
2019101582.tif 000019
【図１８】
2019101582.tif 000020
【図１９】
2019101582.tif 000021
【図２０】
2019101582.tif 000022
【図２１】
2019101582.tif 000023
【図２２】
2019101582.tif 000024
【図２３】
2019101582.tif 000025
【図２４】
2019101582.tif 000026