(57)【要約】【課題】必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、バグの収束を判定することで、バグの収束の誤判定を抑制できること。【解決手段】ソフトウェア品質判定方法は、システムに発生するバグの収束を判定する。ソフトウェア品質判定方法は、システムをテストする際の観点であるテスト観点毎の該テストの実施量を取得するステップと、システムの開発規模を示す指標値に基づいて、テスト観点毎のテストの実施量の基準となる実施基準量と、を算出するステップと、取得したテスト観点毎のテストの実施量と、算出した対応する実施基準量と、を夫々比較した後、テストの観点毎に前記バグの収束を判定するステップと、を含む。【選択図】図５
2018026056.tif 000002
【特許請求の範囲】
【請求項１】
システムに発生するバグの収束を判定するソフトウェア品質判定方法であって、
前記システムをテストする際の観点であるテスト観点毎の該テストの実施量を取得するステップと、
前記システムの開発規模を示す指標値に基づいて、前記テスト観点毎のテストの実施量の基準となる実施基準量を算出するステップと、
前記取得したテスト観点毎のテストの実施量と、前記算出した対応するテスト観点毎の実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定するステップと、
を含む、ことを特徴とするソフトウェア品質判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムの品質を判定するソフトウェア品質判定方法に関する。
【背景技術】
【０００２】
バグ発生実績データからシステムに将来発生するバグ件数を予測し、予測したバグ件数と設定した品質指標とに基づいて、バグの発生が収束する収束時期を予測するソフトウェア品質判定方法が知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１７４８９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記ソフトウェア品質判定方法においては、バグの発生が収束したとしても、システムの開発規模（ソースコード規模、ソースコード複雑度、ＦＰ（Function Point）、など）に基づいてテストが十分に実施されていない場合や、テストする際のテスト観点が不足してる場合、がある。この場合、バグの収束を誤判定する虞がある。
【０００５】
本発明は、このような問題点を解決するためになされたものであり、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、バグの収束を判定することで、バグの収束の誤判定を抑制できるソフトウェア品質判定方法を提供することを主たる目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するための本発明の一態様は、
システムに発生するバグの収束を判定するソフトウェア品質判定方法であって、
前記システムをテストする際の観点であるテスト観点毎の該テストの実施量を取得するステップと、
前記システムの開発規模を示す指標値に基づいて、前記テスト観点毎のテストの実施量の基準となる実施基準量を算出するステップと、
前記取得したテスト観点毎のテストの実施量と、前記算出した対応するテスト観点毎の実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定するステップと、
を含む、ことを特徴とするソフトウェア品質判定方法
である。
【発明の効果】
【０００７】
本発明によれば、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、バグの収束を判定することで、バグの収束の誤判定を抑制できるソフトウェア品質判定方法を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態に係るソフトウェア品質判定装置の概略的なシステム構成を示すブロック図である。
【図２】テスト観点毎のテスト実施基準量の一例を示す図である。
【図３】ＩＳＯ９１２６のテスト観点の一例を示す図である。
【図４】テスト観点が機能性である場合のバグ曲線の一例を示す図である。
【図５】本発明の一実施形態に係るソフトウェア品質判定方法の処理フローの一例を示すフローチャートである。
【図６】テスト観点毎の合否結果とそのバグ曲線を表示装置を用いて表示した場合のフローチャートである。
【図７】テスト観点毎の合否結果とそのバグ曲線の一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の一実施形態に係るソフトウェア品質判定装置の概略的なシステム構成を示すブロック図である。本実施形態に係るソフトウェア品質判定装置１は、例えば、複数のプログラムで構成されてるシステムに発生するバグの収束を判定するものである。ここで、バグの収束判定を行う前に、必要なテスト観点を網羅し、かつ、該テスト観点毎に、システムの開発規模に応じた適切な量のテストを実施することが重要となる。本実施形態に係るソフトウェア品質判定装置１は、バグ収束判定を開始する前に、上記のような、必要なテスト観点を網羅し、かつ、該テスト観点毎の、システムの開発規模に応じた適切な量のテストを実施する。
【００１０】
ソフトウェア品質判定装置１は、例えば、演算処理等と行うＣＰＵ（Central Processing Unit）、ＣＰＵによって実行される演算プログラム、各種のデータを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）からなるメモリ、外部と信号の入出力を行うインターフェイス部（Ｉ／Ｆ）、などからなるマイクロコンピュータを中心にして、ハードウェア構成されている。ＣＰＵ、メモリ及びインターフェイス部は、データバスなどを介して相互に接続されている。
【００１１】
本実施形態に係るソフトウェア品質判定装置１は、入力部２と、システムをテストする際のテスト観点毎のテストの実施量を取得する実施量取得部３と、テスト観点毎のテストの実施量の基準となる実施基準量と算出する実施基準算出部４と、システムのバグの収束を判定するバグ収束判定部５と、を備えている。
【００１２】
入力部２は、例えば、ユーザが任意の数値（後述のテスト実施量や開発規模指標値など）をソフトウェア品質判定装置１に入力し設定するための装置である。入力部２は、例えば、キーボート、マウス、タッチスクリーン、無線携帯端末（スマートフォンやタブレットなど）等の任意の入力装置である。
【００１３】
実施量取得部３は、入力部２などを介して、システムをテストする際の観点であるテスト観点毎のテストの実施量（以下、テスト実施量）を取得する。テスト実施量は、例えば、プログラムに対してテストを実施する際に必要なテスト工数やテスト件数である。なお、実施量取得部３は、開発規模指標値に基づいて、テスト観点毎のテスト実施量を自動的に算出してもよい。
実施基準算出部４は、システムの開発規模を示す指標値（以下、開発規模指標値）に基づいて、テスト観点毎のテスト実施量の基準となる実施基準量（以下、テスト実施基準量）と算出する。このテスト実施基準量は、各テスト観点毎に算出され、例えば、各テスト観点において、システム開発規模に応じて必要なテスト実施量である。
【００１４】
開発規模指標値とは、例えば、そのシステムのプログラムのソースコード規模（実行コード行数など）、ソースコードの複雑さを示すソースコード複雑度、ＦＰ（Function Point）、などである。例えば、開発規模指標値は、上記メモリなどに予め設定されており、実施基準算出部４は、メモリから開発規模指標値を読み込む。
【００１５】
テスト観点とは、例えば、プログラムが正常に動作するか否かを確認するための、テスト項目、着眼点、発想方法といった、テストを行う上での「切り口」であり、テストを実施するときの操作や手順の着眼点である。このテスト観点を適切に設定することで、プログラムのバグを十分に補足できる。例えば、テスト項目などのテスト観点は、上記メモリなどに予め設定されており、実施基準算出部４は、メモリから設定されたテスト観点を読み込む。メモリに設定されたテスト観点は、例えば、入力部２を介してユーザが自由に設定変更できる。これにより、ユーザは、任意の処理過程において、必要なテスト観点を適宜追加及び変更できるため、必要なテスト観点を網羅できる。
また、実施基準算出部４は、例えば、ＯＤＣ(Orthogonal Defect Classification)分析（例えば、http://www.researcher.watson.ibm.com/researcher/files/us-pasanth/ODC-5-2-Extensions.pdfを参照）のバグを発見する観点や後述のＩＳＯ（International Organization for Standardization）９１２６の品質特性に基づいて、テスト観点を設定してもよい。
【００１６】
実施基準算出部４は、例えば、過去の開発規模指標値に基づいて、統計的にテスト実施基準量を算出してもよい。より具体的には、テスト観点毎にテストを実施し、バグが収束したときのテスト工数（テスト件数を含む）が過去実績としてメモリなどに保持され、累積される。実施基準算出部４は、図２に示す如く、メモリに保持された、テスト観点毎のバグが収束したときのテスト工数に基づいて、統計的にテスト実施基準量を算出する。実施基準算出部４は、テスト観点毎に、例えば、テスト実施基準量の平均値（テスト工数／ＫＬＯＣ）及びその分散を算出する。実施基準算出部４は、このテスト観点毎のテスト実施基準量の平均値（テスト工数／ＫＬＯＣ）と、開発規模指標値と、に基づいて、テスト観点毎のテスト実施基準量を算出する。なお、テスト観点は、図３に示す如くＩＳＯ９１２６のテスト観点であり、例えば、機能性、効率性、信頼性、使用性、保守性、可搬性となっている。テスト観点毎のテスト実施基準量は、２．１、０．１、０．８、３．２、０．６、０、７となっている（図２）。
【００１７】
また、実施基準算出部４は、テスト期間中のテスト工数とバグの発生状況とに基づいて、テスト観点毎のテスト実施基準量を算出してもよい。例えば、実施基準算出部４は、特許文献１に示す技術を用いて、横軸をテスト工数、縦軸をバグ総数とした、テスト観点毎のバグ曲線を生成する。
【００１８】
バグ曲線は、テスト観点毎に生成される。図４は、テスト観点が機能性である場合のバグ曲線の一例を示す図である。実施基準算出部４は、生成したバグ曲線に基づいて、バグ収束時のテスト工数を算出し、算出したテスト工数をテスト実施基準量とする。さらに、実施基準算出部４は、算出したテスト実施基準量を累積し、統計的なテスト実施基準量を算出してもよい。
【００１９】
ところで、従来のソフトウェア品質判定方法においては、バグの発生が収束したとしても、システムの開発規模に基づいてバグテストが十分に実施されていない場合や、バグテストする際のテスト観点が不足してる場合、がある。この場合、バグの収束を誤判定する虞がある。
【００２０】
これに対し、本実施形態においては、開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出し、取得したテスト観点毎のテスト実施量と、算出した対応するテスト実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定する。これにより、テスト観点毎に開発規模指標値に応じた適切な量のテストを実施した後に、より高精度なバグの収束の判定できる。すなわち、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、テスト観点毎にバグの収束を判定することで、バグの収束の誤判定を抑制できる。
【００２１】
バグ収束判定部５は、実施量取得部３により取得されたテスト観点毎のテスト実施量と、実施基準算出部４により算出された対応するテスト実施基準量と、を比較した後、テスト観点毎にバグの収束を判定する。バグ収束判定部５は、例えば、実施量取得部３により算出された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。
【００２２】
バグ収束判定部５は、上述の如く、テスト観点毎のテスト実施量と、対応するテスト実施基準量と、を個別に比較する。これにより、テスト観点毎に実施したテスト量をテスト観点毎に容易に把握でき、どのテスト観点をもっとテストすべきかが容易に把握できる。
【００２３】
そして、バグ収束判定部５は、上述の如く、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。これにより、必要な全テスト観点について、必要なテスト量のテストが実施された（テスト実施量＞テスト実施基準量）ことを判断した後、バグ収束判定を開始する。したがって、必要なテスト観点が抜けている、あるテスト観点についてテスト量不足である、といった問題が確実に解消できるため、その後のバグ収束判定をより確実に実行できる。なお、バグ収束判定部５は、一部のテスト観点のテスト実施量が対応するテスト実施基準量を超えると、逐次、そのテスト観点のバグ収束判定を開始してもよい。これにより、処理の高速化を図ることができる。
なお、バグ収束判定部５は、一定数以上のテスト観点のテスト実施量が対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始してもよい。
【００２４】
バグ収束判定部５は、例えば、図４に示す如く、実施量取得部３により取得されたテスト観点（機能性）のテスト実施量（テスト工数）が実施基準算出部４により算出されたテスト実施基準量を超えると、そのテスト観点（機能性）のバグ収束開始判定を合格とする。バグ収束判定部５は、この機能性と同様の判定を他のテスト観点についても行い、全テスト観点のバグ収束開始判定が合格となった場合に、テスト観点毎のバグ収束判定を開始する。このように、バグ収束判定部５は、テスト観点毎にテスト実施量とテスト実施基準量とを比較することで、バグ曲線の品質判定を行う。その後、バグ収束判定部５は、バグ収束判定を開始する。
【００２５】
なお、バグ収束判定部５は、実施量取得部３により取得された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。しかし、実際には、テスト実施基準量は、例えば、信頼区間９０％でＡ〜Ｂと言った幅を有する数値となる。すなわち、実施基準算出部４は、上記信頼区間を考慮してテスト実施基準量を算出する。このように、テスト実施基準量は平均値ではなく、信頼区間を考慮した値となる。このため、バグ収束判定部５は、テスト実施量がその信頼区間内に入っていれば、そのテスト実施基準量を満たしているを判定してもよい。
【００２６】
図５は、本実施形態に係るソフトウェア品質判定方法の処理フローの一例を示すフローチャートである。
【００２７】
実施基準算出部４は、メモリの開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出する（ステップＳ１０１）。
実施量取得部３は、テスト実施量を取得する（ステップＳ１０２）。
【００２８】
バグ収束判定部５は、実施量取得部３により取得された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えているか否かを判定する（ステップＳ１０３）。バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていると判定したとき（ステップＳ１０３のＹＥＳ）、テスト観点毎のバグ収束判定を開始する（ステップＳ１０４）。一方、バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていないと判定したとき（ステップＳ１０３のＮＯ）、上記（ステップＳ１０２）に戻る。
【００２９】
以上、本実施形態に係るソフトウェア品質判定装置１において、実施量取得部３は、テスト観点毎のテスト実施量を取得する。実施基準算出部４は、開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出する。バグ収束判定部５は、実施量取得部３により取得されたテスト観点毎のテスト実施量と、実施基準算出部４により算出された対応するテスト実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定する。これにより、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、テスト観点毎にバグの収束を判定することで、バグの収束の誤判定を抑制できる。
【００３０】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【００３１】
例えば、上記実施形態において、バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていないと判定したとき（ステップＳ１０３のＮＯ）、テスト観点毎の合否結果とそのバグ曲線を表示装置を用いてユーザに表示した（ステップＳ１０５）後、上記（ステップＳ１０２）に戻ってもよい（図６）。表示装置は、例えば、液晶ディスプレイ、有機ＥＬディスプレイなどである。表示装置は、例えば、図７に示すような、テスト観点毎の合否結果、そのバグ曲線、及びテスト実施基準量を表示する。これにより、テスト工数をテスト観点毎に容易に把握でき、どのテスト観点をもっとテストすべきかが明確に把握できる。
【００３２】
上記実施形態において、ソフトウェア品質判定装置１は、システムのテスト工程に適用されているが、これに限定されない。ソフトウェア品質判定装置１は、例えば、設計及び実装のレビュー工程に適用されてもよい。この場合、テスト実施量をレビュー工数、開発規模指標値をドキュメントのボリューム（行数、頁数、文字数など）、テスト観点をレビュー観点に置き換えて適用できる。なお、レビュー観点は、例えば、組織が有する観点表を用いてもよく、ＯＤＣ分析のレビュー工程のバグを発見する観点を用いてもよい。
【００３３】
本発明は、例えば、図５に示す処理を、ＣＰＵ又はＧＰＵ（Graphics Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。
【００３４】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。
【００３５】
プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【符号の説明】
【００３６】
１  ソフトウェア品質判定装置、２  入力部、３  実施量取得部、４  実施基準算出部、５  バグ収束判定部
【図１】
2018026056.tif 000003
【図２】
2018026056.tif 000004
【図３】
2018026056.tif 000005
【図４】
2018026056.tif 000006
【図５】
2018026056.tif 000007
【図６】
2018026056.tif 000008
【図７】
2018026056.tif 000009