(57)【要約】      （修正有）【課題】検査対象ソフトウェアについて必要な追加テストケースを抽出し、その合否判定を自動的に出力する。【解決手段】検査対象ソフトウェアを入力して２１、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成し２３、既存テストケース２２を制御フローグラフ上で実行し、制御フローグラフ上で通過した経路を記録し２４、既存テストケースだけでは制御パステスト法による所定の網羅基準に満たない場合に、所定の網羅基準を満たすように追加される追加テストケースを生成し２５、追加テストケースに書かれた条件でプログラムを実行した場合に、その結果として得られるべき期待結果を生成し２５４、テストケース実行部で追加テストケースのみを実行して得られた追加テストケースの実行結果および期待結果に基づいて、追加テストケースのテスト結果を算出する２６。【選択図】図１
2016115175.tif 000002
【特許請求の範囲】
【請求項１】
入力した検査対象ソフトウェアについて、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成する制御フローグラフ生成部と、
既にプログラムの実行を確認済みの既存テストケースを取得し、この既存テストケースを前記制御フローグラフ上で実行し、前記制御フローグラフ上で通過した経路を記録するテストケース実行部と、
前記既存テストケースだけでは制御パステスト法による所定の網羅基準に満たない場合に、前記所定の網羅基準を満たすように追加される追加テストケースを生成する追加テストケース生成部と、
前記追加テストケースに書かれた条件でプログラムを実行した場合に、 その結果として得られるべき期待結果を生成する期待結果生成部と、
前記テストケース実行部で前記追加テストケースのみを実行して得られた前記追加テストケースの実行結果および前記期待結果に基づいて、前記追加テストケースのテスト結果を算出する合否判定部とを、備えるソフトウェアテスト装置。
【請求項２】
前記検査対象ソフトウェアを入力する検査対象ソフトウェア入力部と、
前記既存テストケースを保持する既存テストケース保持部と、
を備える請求項１に記載のソフトウェアテスト装置。
【請求項３】
前記合否判定部から、前記追加テストケースのテスト結果を取得し、前記既存テストケースおよび前記追加テストケースの合否結果の一覧を出力するテスト結果一覧出力部を
備える請求項１又は請求項２に記載のソフトウェアテスト装置。
【請求項４】
前記合否結果は、前記既存テストケースについては合否、前記追加テストケースについてはテスト結果である請求項３に記載のソフトウェアテスト装置。
【請求項５】
前記検査対象ソフトウェアの入力形式は、ソースコード、あるいはバイナリ、あるいはバイトコードのいずれかである請求項１乃至請求項４のいずれか1項に記載のソフトウェアテスト装置。
【請求項６】
前記所定の網羅基準は、条件網羅あるいは分岐網羅である請求項１乃至請求項５のいずれか1項に記載のソフトウェアテスト装置。
【請求項７】
前記期待結果は、平均値と分散から算出される幅をもつ確率密度関数として生成される請求項１乃至請求項６のいずれか1項に記載のソフトウェアテスト装置。
【請求項８】
前記追加テストケース生成部は、
前記所定の網羅基準と、前記既存テストケースの実行により通過したパスを比較し、不足パスを生成する不足パス生成部と、
前記不足パス毎に、前記不足パスを通過するノードの式を充足可能性問題の制約として与えて解き、前記不足パスを通過するための入力値を生成する入力値生成部と、
前記不足パス毎に、前記制御フローグラフ上で通過した経路の開始点と前記不足パスの開始点が同じになるテストケース群を前記既存テストケースから抽出したものを教師データとし、この教師データを用いる回帰モデルを生成する回帰モデル生成部と、
前記不足パス毎に、前記入力値生成部によって生成された入力値と前記回帰モデル生成部によって生成された前記回帰モデルから、前記期待結果を生成する前記期待結果生成部とで構成される請求項１乃至請求項５のいずれか1項に記載のソフトウェアテスト装置。
【請求項９】
前記追加テストケースは、前記不足パスを通るような入力値、動作させる機能および前記期待結果で特定される請求項８に記載のソフトウェアテスト装置。
【請求項１０】
前記動作させる機能は、前記不足パスの出発点として使用される請求項９に記載のソフトウェアテスト装置。
【請求項１１】
前記不足パスは、前記所定の網羅基準により通る必要があるノード、エッジまたはそれらの組み合わせのうち、全ての前記既存テストケースを実行しても通らなかったノード、エッジまたはそれらの組み合わせを通るように探索された経路である請求項８乃至請求項１０のいずれか1項に記載のソフトウェアテスト装置。
【請求項１２】
前記不足パス１つにつき、１つの前記追加テストケースが生成される請求項８乃至請求項１１のいずれか1項に記載のソフトウェアテスト装置。
【請求項１３】
検査対象ソフトウェアと既にプログラムの実行を確認済みの既存テストケースを入力するソフトウェアテスト装置に、
前記検査対象ソフトウェアについて、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成する機能と、
前記既存テストケースを前記制御フローグラフ上で実行し、前記制御フローグラフ上で通過した経路を記録する機能と、
前記既存テストケースだけでは制御パステスト法による所定の網羅基準に満たない場合に、前記所定の網羅基準を満たすように追加される追加テストケースを生成する機能と、
前記追加テストケースに書かれた条件でプログラムを実行した場合に、 その結果として得られるべき期待結果を生成する機能と、
前記追加テストケースのみを実行して得られた前記追加テストケースの実行結果および期待結果に基づいて、前記追加テストケースのテスト結果を算出する機能とを、
実現させるためのソフトウェアテストプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ソフトウェアテスト装置およびソフトウェアテストプログラムに関する。
【背景技術】
【０００２】
ソフトウェアテストのテスト自動化では、検査対象ソフトウェアの変更に合わせて、テストケースとテストコードを常に保守する必要がある。
【０００３】
そのため、保守のコストを削減するべく、テストケースを自動設計する技術、テストコードを自動生成する技術が提案されている。
【０００４】
しかしながら、テストケース設計において、期待結果を自動的に生成するための有力な手段はない、という問題があった。これは、以下の様な理由による。
【０００５】
検査対象ソフトウェアから期待結果を生成しても、その期待結果が正しいか分からない。また、検査対象ソフトウェア以外に、期待結果を生成するための情報を入力するとすれば、その情報は検査対象ソフトウェアのあるべき姿そのものであり、検査対象のソフトウェアを開発する意味が無い。
【０００６】
同じ仕様で、２つの実装をして、入力に対する出力が同じになるかで合否を判定する方法はあるが、コストがかかるだけでなく、出力が異なるとき、どちらが間違っているかわからない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１２−３７９３８号公報
【特許文献２】特開２０１２−１８５５３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が解決しようとする課題は、検査対象ソフトウェアについて必要な追加テストケースを抽出し、その合否判定を自動的に出力するソフトウェアテスト装置およびソフトウェアテストプログラムを提供することである。
【課題を解決するための手段】
【０００９】
実施形態のソフトウェアテスト装置は、入力した検査対象ソフトウェアについて、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成する制御フローグラフ生成部と、既にプログラムの実行を確認済みの既存テストケースを取得し、この既存テストケースを前記制御フローグラフ上で実行し、前記制御フローグラフ上で通過した経路を記録するテストケース実行部と、前記既存テストケースだけでは制御パステスト法による所定の網羅基準に満たない場合に、前記所定の網羅基準を満たすように追加される追加テストケースを生成する追加テストケース生成部と、前記追加テストケースに書かれた条件でプログラムを実行した場合に、 その結果として得られるべき期待結果を生成する期待結果生成部と、前記テストケース実行部で前記追加テストケースのみを実行して得られた前記追加テストケースの実行結果および期待結果に基づいて、前記追加テストケースのテスト結果を算出する合否判定部とを、備える。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係るソフトウェアテスト装置の概略構成を示すブロック図である。
【図２】検査対象ソフトウェアの一例を示す図である。
【図３】既存テストケースの一例を示す図である。
【図４】図２に示す検査対象ソフトウェアの制御フローグラフを示した図である。
【図５】図４に示す制御フローグラフのデータ構造を表す図である。
【図６】記録する通過した経路（パス）の一例を示す図である。
【図７】不足パスの一例を示す図である。
【図８】図７に示す不足パスに対応する制約（ノードの式）の一例を示す図である。
【図９】不足パスを通過するため入力値の一例を示す図である。
【図１０】制御フローグラフ上で通過したパスおよび不足パスを参考にして、教師データとして用いるパスの抽出の一例を示した図である。
【図１１】既存テストケースから抽出された教師データの一例を示す図である。
【図１２】回帰モデルから生成した期待結果の一例を示す図である。
【図１３】追加テストケースの実行結果と期待結果に基づいて、テストケースのテスト結果が得られることを説明する図である。
【図１４】テスト結果一覧の出力の一例を示す図である。
【図１５】実施形態に係るソフトウェアテスト装置における期待結果の生成処理・テスト結果の算出処理の流れを示すフローチャートである。
【図１６】本実施例における検査対象ソフトウェアのソースコードを示す図である。
【図１７】図１６に示す検査対象ソフトウェアの既存テストケースを示す図である。
【図１８】検査対象ソフトウェアの仕様変更に伴い変更されたソースコードを示す図である。
【図１９】追加テストケースの入力値および期待結果を示す図である。
【図２０】追加テストケースの実行結果を示す図である。
【図２１】テスト結果に基づくソースコードの誤りの調査を説明する図である。
【発明を実施するための形態】
【００１１】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１２】
まず、本実施形態で用いる主要な用語について説明する。
【００１３】
「ソフトウェアテスト」とは、コンピュータのプログラムを実行し、正しく動作するかどうか確認する作業をいう。一般的に、テストケースの設計、テストの実行による結果の確認、レポート（合格、不合格一覧）の作成、のような作業をする必要がある。
【００１４】
「テストケース」とは、テストを行う際に、プログラムにどのような入力を与え、 その結果としてどのような出力が得られるべきか（期待結果）を記述したものをいう。
【００１５】
「期待結果」とは、テストケースに書かれた条件でプログラムを実行したとき、 その結果として得られるべき結果をいう。
【００１６】
「テスト自動化」とは、ソフトウェアテストの作業の一部を自動化することをいう。
【００１７】
「テストコード」とは、テストケースを実行可能なプログラムとして記述したものをいう。テストの実行と結果の確認をするために実装される。
【００１８】
「制御パステスト法」とは、ソフトウェアのテスト手法の一つで、プログラム中のコードが全て実行されるようにテストデータを与えるテストをいう。ソフトウェアの論理構造を分析するホワイトボックステストの一種で、プログラムの論理構造が意図した通りに記述されているか確かめるため、なるべく多くのコードが実行されるようなテストデータの組み合わせを考えてテストを行う。
【００１９】
「回帰モデル」とは、ある二つの変数の関係を表す式のうち、統計的手法によって推計された式をいう。回帰式ともいう。
【００２０】
本実施形態においては、制御パステスト法で所定の基準に満たない場合に追加のテストケースを見つけ出し、追加テストケースの期待結果を確率密度関数として生成し、既存テストケースの合否結果と合わせて、追加テストケースのテスト結果を算出する。
【００２１】
図１は、本発明の実施形態に係るソフトウェアテスト装置の概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータに、検査対象ソフトウェアと既にプログラムの実行を確認済みの既存テストケースを入力し、検査対象ソフトウェアについて、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成する機能と、既存テストケースを制御フローグラフ上で実行し、制御フローグラフ上で通過した経路を記録する機能と、既存テストケースだけでは制御パステスト法による所定の網羅基準に満たない場合に、所定の網羅基準を満たすように追加される追加テストケースを生成する機能と、追加テストケースに書かれた条件でプログラムを実行した場合に、 その結果として得られるべき期待結果を生成する機能と、追加テストケースのみを実行して得られた追加テストケースの実行結果および期待結果に基づいて、追加テストケースのテスト結果を算出する機能とを、実現させるためのソフトウェアテストプログラムとして実施することもできる。
【００２２】
図１に示すように、本実施形態に係るソフトウェアテスト装置１００は、主として、検査対象ソフトウェア入力部２１、既存テストケース保持部２２、制御フローグラフ生成部２３、テストケース実行部２４、追加テストケース生成部２５、合否判定部２６、テスト結果一覧出力部２７から構成されている。
【００２３】
検査対象ソフトウェア入力部２１は、ソフトウェアテスト装置１００で検査する検査対象ソフトウェアを入力する。入力した検査対象ソフトウェアは、制御フローグラフ生成部２３に送られる。検査対象ソフトウェアの入力形式は、ソースコード、あるいはバイナリ、あるいはバイトコードが好適である。図２は、検査対象ソフトウェアの一例を示す図である。図２に示す検査対象ソフトウェアは、３個の関数から成り、３番目の関数は１番目および２番目の関数を参照することを表している。
【００２４】
既存テストケース保持部２２は、既存テストケースを保持する。ここで、既存テストケースは、プログラムの実行を確認してあり、得られるべき期待結果に問題がないものである。既存テストケースは、“入力”および“期待結果”の組として別に記録されている。入力は、“動作させる機能”および“入力値”から成り、期待結果は、“期待値”として表される。既存テストケースは、例えば、外部から既存テストケース保持部２２に入力させる、あるいは、予め、既存テストケース保持部２２に保持しておく。尚、検査対象ソフトウェアが既存テストケースに合格するかは不明であり、不合格となるテストケースも存在する可能性がある。その場合、当該既存テストケースは学習データ（後述する）に用いない。
【００２５】
図３は、既存テストケースの一例を示す図である。図３に示す例では、５つのテストケースについて、それぞれの動作させる機能（clip_0to100やclip_0to200）、入力値（−１０、８３、−５、１３０、２５０）と期待結果（０、８３、０、１３０、２００）が示されている。動作させる機能は、１つのプログラムに複数存在することができ、不足パス（後述する）の出発点として使用される。既存テストケースのデータは、テストケース実行部２４に送られる。
【００２６】
制御フローグラフ生成部２３は、検査対象ソフトウェア入力部２１から受け取った検査対象ソフトウェアの制御フローグラフを生成する。制御フローグラフは、プログラムを実行したときに通過する、すなわち、パスを通す可能性のある全経路をグラフで表したものである。制御フローグラフの詳細は後述する。ここで、経路（パス）は、コマンドを実行するプログラムのある場所の意で、“パスを通す”とは、コマンドを実行するために、パスの設定をすることをいう。
【００２７】
＜制御フローグラフ＞
制御フローグラフは、プログラムを実行したときに通過する、すなわち、パスを通す可能性のある全経路をグラフで表したものである。図４は、図２に示す検査対象ソフトウェアの制御フローグラフを示した図である。図４に示す例では、始点“１”から終点“５”に至るパスを通す可能性のある全経路と、始点“６”から終点“１０”に至るパスを通す可能性のある全経路が示されている。動作させる機能は、制御フローグラフのノードのうち、どこからも矢印が繋がっていないノードである。
【００２８】
また、図５は、図４に示す制御フローグラフのデータ構造を表す図である。データ構造は、“ノード情報”と、“エッジ情報”から成っている。ノード情報は、各ノードについてのノードＩＤと、各ノードの内容（ノードの式）から成っている。また、エッジ情報は、始点ノードＩＤと終点ノードＩＤの組合せから成っている。図５に示す例では、ノード情報として、ノードＩＤ“１”からノードＩＤ“１５”について、それぞれノードの内容（ノードの式）が示されている。さらに、エッジ情報として、各ノードＩＤを始点ノードＩＤとしたときの終点ノードＩＤの関係が示されている。例えば、ノードＩＤ“３”については、終点ノードＩＤとしてノードＩＤ“４”あるいはノードＩＤ“５”が候補であることがわかる。同様に、ノードＩＤ“１５”については、終点ノードＩＤとしてノードＩＤ“３”あるいはノードＩＤ“８”が候補であることがわかる。
【００２９】
テストケース実行部２４は、既存テストケース保持部２２から既存テストケースを取得し、制御フローグラフ上で実行し、制御フローグラフ上で通過した経路（パス）を記録する。図６は、記録する通過した経路（パス）の一例を示す図である。図６に示す例では、図４に示す制御フローグラフと対比すると、ノードＩＤ“３”を始点としてノードＩＤ“４”を終点とする経路（パス）が、通過した経路となっていないことがわかる。
【００３０】
追加テストケース生成部２５は、追加テストケースを生成するものである。追加テストケースは、制御パステスト法で所定の“網羅基準”に満たない場合に、所定の網羅基準を満たすように追加されるテストケースである。ここで、所定の網羅基準としては、例えば、全ての条件において、それぞれ１度でもTrueあるいはFalseとなるテストケースを網羅する“条件網羅”や、全ての分岐が１度でも実行されるテストケースを網羅する“分岐網羅”が好適である。追加テストケースは、具体的には不足パス（後述する）を通るような“入力値”、“動作させる機能”および“期待結果”を記述することで特定される。不足パス１つにつき、１つの追加テストケースが生成される。尚、所定の網羅基準は、外部から追加テストケース生成部２５に入力させる、あるいは、予め追加テストケース生成部２５に保持しておく。
【００３１】
追加テストケース生成部２５は、不足パス生成部２５１、入力値生成部２５２、回帰モデル生成部２５３、期待結果生成部２５４に分けることができる。
【００３２】
不足パス生成部２５１は、所定の網羅基準と、既存テストケースの実行により通過したパスを比較し、不足パスを生成する。ここで、不足パスは、網羅基準により通る必要があるノード、エッジまたはそれらの組み合わせのうち、全ての既存テストケースを実行しても通らなかったノード、エッジまたはそれらの組み合わせを通るように探索された経路（パス）である。図７は、不足パスの一例を示す図である。図６に示した通過した経路（パス）の記録から、ノードＩＤ“３”を始点としてノードＩＤ“４”を終点とする経路（パス）が、通過した経路となっていないことがわかっている。図７に示す例では、ノードＩＤ“１”を始点としてノードＩＤ“５”を終点とする経路（パス）であって、ノードＩＤ“３”からノードＩＤ“４”を経由する経路（パス）が、不足パスであることが判明する。
【００３３】
入力値生成部２５２は、不足パス毎に、不足パスを通過する“ノードの式”を充足可能性問題の制約として与えて解き、不足パスを通過するため“入力値”を生成する。充足可能性問題の解は、制約を満たす具体的な１組の値が得られる。ノードの式は、制御フローグラフ生成時に作成されるもので、具体的には、図５に示すノード情報におけるノードの内容である。
【００３４】
図８は、図７に示す不足パスに対応する制約（ノードの式）の一例を示す図である。図８に示す例では、７つのノードの式が列挙されている。図９は、不足パスを通過するため入力値の一例を示す図である。図９に示す例では、７つのノードの式を充足可能性問題として解いた解として、入力値＝１０１となっている。上記した制約を満たす具体的な値は、尚、ノードの式の入力値が２つ以上の場合、制約を満たす具体的な値も２つ以上となることがあるが、図９に示す例では、clip_0to100 の入力値が 1 つであるため、解としての入力値は１つとなっている。上記した入力値＝１０１は、１次元のベクトルとして扱われる。
【００３５】
回帰モデル生成部２５３は、不足パス毎に、制御フローグラフ上で通過した経路（パス）の開始点と不足パスの開始点が同じになるテストケース群を既存テストケースから抽出したものを教師データとし、係る教師データを用いることで回帰モデルを生成する。図１０は、制御フローグラフ上で通過したパスおよび不足パスを参考にして、教師データとして用いるパスの抽出の一例を示した図である。図１１は、既存テストケースから抽出された教師データの一例を示す図である。図１１に示す例では、２個の既存テストケースが教師データとして抽出されている。
【００３６】
生成される回帰モデルは、（１）写像の形（線形等）を仮定しない、（２）多次元ベクトル→多次元ベクトルへの写像が可能、（３）予測を確率密度関数で得られる、という特徴を有する。
【００３７】
回帰モデルとしては、例えば、ガウス過程回帰（Gaussian Process Regression）や、関連ベクトルマシン（Relevance Vector Machine）を用いることができる。ガウス過程回帰は、与えられた入力値に対して、対応する予測値がガウス分布に従う確率変数であるとするガウス過程に基づいている。
【００３８】
例えば、回帰モデルの式をガウス過程回帰の式で表すと、以下のようになる。
【数１】
2016115175.tif 000003
【００３９】
上記において、
ynew は、確率密度関数、xnew は、追加テストケースの入力値である。
【００４０】
入力値は1つとは限らないので、xnew はベクトルである。
【００４１】
X は、既存テストケースの入力値を並べた行列、y は、既存テストケースの期待値を並べたベクトルである。
【００４２】
尚、テストによっては、複数の箇所の値（戻り値、変数など）が成功条件になるので、期待値も複数必要になることがあるが、その場合は、それぞれの戻り値、変数ごとに、モデルを作成する。β,θ、θ1、θ2 は定数であり、これらの定数は、回帰モデルが既存テストケースにフィットするように、焼きなまし法等で求める。
【００４３】
期待結果生成部２５４は、不足パス毎に、入力値生成部２５２によって生成された入力値と回帰モデル生成部２５３によって生成された回帰モデルから、“期待結果”を生成する。本実施形態における期待結果は、平均値と分散から算出される幅をもつ確率密度関数として生成される。図１２は、回帰モデルから生成した期待結果の一例を示す図である。図１２に示す例では、期待結果は、確率密度関数ｆ（ｘ）として生成されている。
【００４４】
合否判定部２６は、テストケース実行部２４から、追加テストケースのみを実行して得られた追加テストケースの実行結果を取得し、期待結果生成部２５４から期待結果の確率密度関数を取得する。合否判定部２６は、実行結果と期待結果に基づいて合否を計算するが、本実施形態では、期待結果を確率密度関数で表すので、合否判定部２６は、テスト結果を算出する。テスト結果は、追加テストケースが合格である確率であり、追加テストケースを実行して得た値を確率密度関数に代入することで、算出する。図１３は、追加テストケースの実行結果と期待結果に基づいて、テストケースのテスト結果が得られることを説明する図である。
【００４５】
テスト結果一覧出力部２７は、合否判定部２６から、追加テストケースのテスト結果を取得し、既存テストケースおよび追加テストケースの合否結果の一覧を出力する。図１４は、テスト結果一覧の出力の一例を示す図である。図１４に示すように、既存テストケースは合否、追加テストケースは確率で表したテスト結果が示されている。
【００４６】
次に、以上のように構成されたソフトウェアテスト装置１００における期待結果の生成処理・テスト結果の算出処理の流れについて説明する。図１５は、実施形態に係るソフトウェアテスト装置１００における期待結果の生成処理・テスト結果の算出処理の流れを示すフローチャートである。
【００４７】
まず、検査対象ソフトウェア入力部２１は、検査対象ソフトウェアを入力する（ステップＳ１５０１）。
【００４８】
次に、制御フローグラフ生成部２３は、入力した検査対象ソフトウェアについて、プログラムを実行した場合に通過してパスを通す可能性のある全ての経路をグラフで表した制御フローグラフを生成する（ステップＳ１５０２）。
【００４９】
次に、テストケース実行部２４は、既存テストケース保持部２２に保持され、既にプログラムの実行を確認済みの既存テストケースを制御フローグラフ上で実行し、制御フローグラフ上で通過したパスを記録する（ステップＳ１５０３）。
【００５０】
続いて、不足パス生成部２５１は、所定の網羅基準と、既存テストケースの実行により通過したパスを比較し、不足パスを生成する（ステップＳ１５０４）。不足パスは、所定の網羅基準により通る必要があるノード、エッジまたはそれらの組み合わせのうち、全ての既存テストケースを実行しても通らなかったノード、エッジまたはそれらの組み合わせを通るように探索された経路（パス）である。
【００５１】
次に、入力値生成部２５２は、不足パス毎に、通過するノードの式を充足可能性問題の制約として与えて解き、入力値を生成する（ステップＳ１５０５）。
【００５２】
次に、回帰モデル生成部２５３は、不足パス毎に、既存テストケースから、実行パスの開始点が同じになるテストケース群を抽出し、教師データとして用いることで回帰モデルを生成する（ステップＳ１５０６）。
【００５３】
続いて、期待結果生成部２５４は、入力値と回帰モデルから、期待結果の確率密度関数を生成する（ステップＳ１５０７）。
【００５４】
次に、テストケース実行部２４は、追加テストケースのみを実行し、実行結果を合否判定部に渡す（ステップＳ１５０８）。
【００５５】
続いて、合否判定部２６は、実行結果と、期待結果または期待結果の確率密度関数から合否またはテスト結果を計算する（ステップＳ１５０９）。
【００５６】
次に、テスト結果一覧出力部２７は、既存テストケースおよび追加テストケースの合否結果（既存テストケースは合否、追加テストケースはテスト結果）一覧を出力（ステップＳ１５１０）し、期待結果の生成処理・テスト結果の算出処理を終了する。
【００５７】
［実施例］
次に、本実施形態の実施例について説明する。本実施例は、cosｘをπ／１２刻みで線形補間を利用して算出する検査対象ソフトウェアである。図１６は、本実施例における検査対象ソフトウェアのソースコードを示す図である。図１６に示すように、本実施例では0°〜360°（２π）の範囲の角度に対応している。
【００５８】
図１７は、図１６に示す検査対象ソフトウェアの既存テストケースの記録状況を示す図である。図１７に示すように、０、π／１２、３π／４、π、７π／６、４π／３、１１π／６、２πの各入力値に対する、期待結果が記録されている。
【００５９】
図１８は、検査対象ソフトウェアの仕様変更に伴い変更されたソースコードを示す図である。本実施例では、0°〜360°（２π）以外の範囲の角度にも対応するように仕様変更に伴う追加のソースコードが加えられている。ソフトウェアテスト装置１００において、図１８に示すソースコードを入力し、既存テストケースを実行する。そして、１度も通らなかった（追加された２つの while 文の条件が真になる）パスを追加テストケースとして追加する。追加テストケースの期待結果は、既存のテストケースを教師データとして与えた回帰モデルに、そのテストケースの入力値を与えることで計算する。
【００６０】
図１９は、追加テストケースの入力値および期待結果を示す図である。図１９に示す例では、期待結果ｆ（ｘ）は、入力値（ｘ）に対する正規分布として得られている。
【００６１】
追加テストケースのテスト結果は、追加テストケースの入力値（ｘ）を検査対象ソフトウェアに与えて実行し、期待結果 を次式の実行結果 x に代入することで計算する。ここでは、回帰モデルにガウス過程回帰を用いる。
【数２】
2016115175.tif 000004
【００６２】
ここで、μ＝期待結果の平均値、σ＝分散である。
【００６３】
図２０は、追加テストケースの実行結果を示す図である。図２０に示すように、入力値ｘ＝−０．１では、cosｘの実行結果０．９８６９６・・・が得られ、その場合のテスト結果として７２．２０％が得られている。一方、入力値ｘ＝−０．１では、cosｘの実行結果−０．９８４７９・・・が得られ、その場合のテスト結果として０．４９％が得られている。
【００６４】
図２１は、テスト結果に基づくソースコードの誤りの調査を説明する図である。本実施例では、２つめの while 文の中を通る追加テストケースは、テスト結果の値が低くなっている。そこで、ソフトウェアの開発者あるいは試験担当者は、テスト結果の値が低い追加テストケースから確認することで、不具合修正活動をより効率的に行うことが出来る。図２１に示すように、間違っているソースコードを効率よく抽出することができる。
【００６５】
以上説明したように、本実施形態によれば、間違っているソースコードを効率よく抽出することができるので、ソフトウェアの不具合修正活動をより効率的に行うことが出来る。
【００６６】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６７】
１００・・・ソフトウェアテスト装置
２１・・・検査対象ソフトウェア入力部
２２・・・既存テストケース保持部
２３・・・制御フローグラフ生成部
２４・・・テストケース実行部
２５・・・追加テストケース生成部
２５１・・・不足パス生成部
２５２・・・入力値生成部
２５３・・・回帰モデル生成部
２５４・・・期待結果生成部
２６・・・合否判定部
２７・・・テスト結果一覧出力部
【図１】
2016115175.tif 000005
【図２】
2016115175.tif 000006
【図３】
2016115175.tif 000007
【図４】
2016115175.tif 000008
【図５】
2016115175.tif 000009
【図８】
2016115175.tif 000010
【図９】
2016115175.tif 000011
【図１１】
2016115175.tif 000012
【図１２】
2016115175.tif 000013
【図１３】
2016115175.tif 000014
【図１４】
2016115175.tif 000015
【図１５】
2016115175.tif 000016
【図１６】
2016115175.tif 000017
【図１７】
2016115175.tif 000018
【図１８】
2016115175.tif 000019
【図１９】
2016115175.tif 000020
【図２０】
2016115175.tif 000021
【図２１】
2016115175.tif 000022
【図６】
2016115175.tif 000023
【図７】
2016115175.tif 000024
【図１０】
2016115175.tif 000025