(57)【要約】【課題】プログラムの検証にあたり、重複を抑制しながら少ない回数で網羅率の高い検証を行う。【解決手段】個々の検証項目ごとに検証できるプログラムの構成要素をリスト化した候補テーブルと、その候補テーブルにおける検証項目間の類似性一覧テーブルを予め作成しておき、  出現回数合計値が最少の上記構成要素を含む上記検証項目の中で、含む構成要素の数が最も多い上記検証項目を実行予定項目として選び、選んだ上記実行予定項目に含まれる構成要素を候補テーブルから削除した上で、上記実行予定項目の選択を行う作業を繰り返した上で、実際に検証を実行し、  バグを検出した場合には、その検出した検証項目との類似性が最も高い追加予定検証項目についても実際に検証を行い、さらにバグを検出した追加予定検証項目があれば、さらにその追加予定検証項目との類似性が高い検証項目を選んで検証を行う作業を繰り返す。【選択図】図５
2015169981.tif 000002
【特許請求の範囲】
【請求項１】
個々の検証項目ごとに検証できるプログラムの構成要素をリスト化した候補テーブルと、その候補テーブルにおける個々の検証項目で検証できる構成要素の類似性を評価する検証項目間の値である類似性一覧テーブルとに対して、
全ての上記検証項目について、出現回数の合計が最も少ない上記構成要素を含む上記検証項目の中で、含む構成要素の数が最も多い上記検証項目を実行予定項目として候補テーブルから選び、選んだ上記実行予定項目に含まれる構成要素を候補テーブルから削除した上で、次の上記実行予定項目の選択を行う作業を繰り返し、
それらの選択した上記実行予定項目について実際に検証を実行した上で、
その検証の実行にあたってバグを検出した場合には、そのバグを検出した検証項目との類似性が最も高い検証項目を、又は網羅性の評価値が最も高い検証項目を、追加予定検証項目として選んで、その追加予定検証項目についても実際に検証を行い、
それらの追加予定検証項目の中にバグを検出した検証項目があれば、さらにその追加予定検証項目との類似性が高い検証項目を、又はバグを検出しなかった検証項目の全てに対する類似性の評価値の合計が最も低い検証項目を、選んで検証を行う、プログラムの検証方法。
【請求項２】
上記検証項目ごとに検証可能であるプログラムの上記構成要素をリスト化し、上記構成要素ごとに全検証項目中における検証に該当する件数の出現回数合計値を算出可能又は利用可能とした候補テーブルと、上記候補テーブルにおける上記検証項目ごとの他の上記検証項目との間の類似性を評価する値のテーブルである類似性一覧テーブルとを用いて、
下記の（１）及び（２）のステップを、上記構成要素が上記候補テーブルから無くなるまで繰り返す選択ループステップ、
上記（１）で登録された実行予定項目について検証を実行する基本検証ステップ、
上記基本検証ステップにおいてバグを検出した場合、そのバグを検出した上記検証項目に対して上記類似性一覧テーブルにおける類似性が最も高い上記検証項目を、又は、バグを検出しなかった上記検証項目の全てに対する類似性の評価値の合計が最も低い上記検証項目を、追加予定検証項目として登録する、バグ対応追加選択ステップ、
上記の追加予定検証項目について検証を実行する追加検証ステップ、
上記追加検証ステップにおいてバグを検出した場合に、上記バグ対応追加選択ステップと同じ手順を実行した後、さらなる上記追加予定検証項目に対して上記追加検証ステップを実行する工程を、バグが検出されなくなるまで繰り返す消尽ループステップ、
を順に実行する、請求項１に記載のプログラムの検証方法。
記
（１）上記検証項目のうち、上記出現回数合計値が最も少ない上記構成要素を検証対象として含む中で、内包する上記構成要素が最も多い上記検証項目を、実行予定項目として登録する予定登録ステップ。
（２）上記で登録された上記実行予定項目に含まれる上記構成要素のレコードを上記候補テーブルから削除する候補除外ステップ。
【請求項３】
上記類似性一覧テーブルにおける上記検証項目間の類似性の値が、含有する上記構成要素を成分とするベクトルで表した個々の上記検証項目同士の内積の値である、
請求項２に記載のプログラムの検証方法。
【請求項４】
上記バグ対応追加選択ステップにおいて、類似性が最も高い上記検証項目が複数ある場合、その直前に行った上記基本検証ステップ又は上記追加検証ステップにおいて検証しながらバグを検出しなかった検証項目の全てに対する類似性の評価値の合計が最も低いものを選ぶ、請求項２又は３に記載のプログラムの検証方法。
【請求項５】
請求項１乃至４のいずれかに記載のプログラムの検証方法を実行した後に、
バグが検出された検証項目に含まれる上記構成要素を変更する構成要素改修ステップと、
上記候補テーブル及び上記類似性一覧テーブルを上記変更後に対応したものとして、変更した当該構成要素を含む上記検証項目のうち、網羅性の値が最も高い上記検証項目を追加予定検証項目として選択する、改修後追加選択ステップ、
を実行した後に、
上記追加検証ステップ及び上記消尽ループステップを実行する、プログラムの検証方法。
【請求項６】
上記のプログラムがＷＥＢのＧＵＩを構築するものであり、
上記検証項目に、ｗｅｂページの描写及びｗｅｂページ間の遷移を含み、
上記構成要素が、Ｊａｖａｓｃｒｉｐｔ（登録商標）で書かれた関数又はその集合体である、
請求項１乃至５のいずれかに記載のプログラムの検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、プログラムを開発する際に効率良くバグの有無を検証する方法に関する。
【背景技術】
【０００２】
プログラムの開発においてバグの発生は避けられず、出来うる限り広範なテストを繰り返してバグを検出し、それらを改善していかなければならない。オブジェクト指向のプログラミング言語により、関数をできるだけ共有するようになっても、検証項目を減らすことは容易ではなかった。
【０００３】
例えばＷＥＢ−ＧＵＩ画面を含むプログラムを開発するにあたっては、Ｊａｖａｓｃｒｉｐｔ（登録商標）による個々のページでの挙動とともに、前ページから次のページへのクリックによる遷移の際の挙動を調べることになる。ところが、現代においては実行環境が次々と新しくなっていくため、ＯＳやブラウザがバージョンアップするごとに、それに対応していかなければならない。これを単純に全てのケースをカバーしようとすると、全ての種類かつ全てのバージョンのＯＳとブラウザ、全ての画面（ページ）の描画と、それらの画面（ページ）間の遷移との全パターンを検証項目とすることになり、膨大な検証回数を要することになった。特に、機能の違いを超えて検証項目を抽出し、少ない件数で検証を完了させることは難しく、技術者の経験によるところが大きかった。経験則だけでは網羅性が不十分となったり、逆に重複のため非効率になったりすることが避けられなかった。加えて、多機能を作業分担で開発することが多い大規模開発では、機能の違いによって担当者が異なるため、重複を避けることが、より、難しくなる傾向がある。このため、膨大な数の検証項目の中から、実際に検証する項目を選ぶにあたって、一定の法則にのっとって機械的に選びだすことが必要となる。
【０００４】
これはＷＥＢ−ＧＵＩに限るものではなく、例えば交通系のシステム開発のような、様々なバリエーションでの事象を想定しなければならないプログラムの開発では、同じような問題が起きる。交通系のシステム開発では、駅が新たに一つ増えたり、システムに参加する会社が増えたりするごとに、検証しなければならない項目が組み合わせ的に増加していくことになる。
【０００５】
特許文献１には、概念的機能を抽出し、抽出した概念的機能のそれぞれを構成する構成要素的機能を抽出して、その構成要素的機能のそれぞれを検証項目として設定しながら、上記概念的機能のそれぞれにおける重複度合いに基づいて検証項目の優先順位を決定する、検証項目の自動生成方法が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−２８３１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載の方法では、初期段階で決めた優先順位に従って検証項目を順次進めていくため、実際の検証途中でバグが発生した場合でも、その発生したバグが与える影響を無視してあくまで重複度合いのみを優先して検証することになった。重複度合いの高い検証項目から順次実行していくため、みかけの検証の進行は速いが、実際に見つかったバグによる影響が関連している場合には、検証すべき内容が後に残りやすく、効率性の点からは不十分になることがあった。
【０００８】
そこでこの発明は、検証項目を選ぶにあたりできるだけ重複を抑制して効率を上げつつ、バグの検出に対応して、動的に追加検証項目を追加して、実質的な品質の向上に繋げることを目的とする。
【課題を解決するための手段】
【０００９】
この発明は、個々の検証項目ごとに検証できるプログラムの構成要素をリスト化した候補テーブルと、その候補テーブルにおける個々の検証項目で検証できる構成要素の類似性を評価する検証項目間の値である類似性一覧テーブルを予め作成しておき、
全ての上記検証項目について、出現回数の合計が最も少ない上記構成要素を含む上記検証項目の中で、含む構成要素の数が最も多い上記検証項目を実行予定項目として候補テーブルから選び、選んだ上記実行予定項目に含まれる構成要素を候補テーブルから削除した上で、さらに上記実行予定項目の選択を行う作業を繰り返し、
それらの選択した上記実行予定項目について実際に検証を実行した上で、
その検証の実行にあたってバグを検出した場合には、そのバグを検出した検証項目との類似性が最も高い検証項目を追加予定検証項目として選んで、その追加予定検証項目についても実際に検証を行い、
さらにバグを検出した追加予定検証項目があれば、さらにその追加予定検証項目との類似性が高い検証項目を選んで検証を行う繰り返しの検証方法により、上記の課題を解決したのである。
【００１０】
ここで検証項目とは、テストを行う具体的な作業のことであり、例えばＷＥＢ−ＧＵＩであれば、一のＯＳかつ一のブラウザにおける、ページそのものの表示や、特定のクリック作業、あるいは別ページへの遷移といった具体的にユーザーが行いうる動作が挙げられる。また、構成要素とはプログラムを構成する所定の単位のまとまりをいい、オブジェクト指向言語であればユーザー定義関数ごとに一つの構成要素としてもよいし、複数の関数を集めたモジュール単位でもよい。
【００１１】
このように、類似性一覧テーブルを用いて、バグが検出されたときに、その検出された検証項目と類似性の高い項目を優先して実行することで、動的に検証項目を増やしながら、バグの起こりうる可能性の高い項目に絞って検証することができるので、検証の実行数の無駄な増加を抑えて、効率良く網羅性の高い検証ができる。
【００１２】
具体的なプログラムの検証方法は次のような構成により実施できる。
検証項目ごとに検証可能であるプログラムの構成要素をリスト化し、上記構成要素ごとに全検証項目中における検証に該当する件数の出現回数合計値を算出可能又は利用可能とした候補テーブルと、上記候補テーブルにおける上記検証項目ごとの他の上記検証項目との間の類似性を評価する値のテーブルである類似性一覧テーブルとを用いて、
下記の（１）及び（２）のステップを、上記構成要素が上記候補テーブルから無くなるまで繰り返す選択ループステップ、
上記（１）で選択された実行予定項目について検証を実行する基本検証ステップ、
上記基本検証ステップにおいてバグを検出した上記検証項目に対して、上記類似性一覧テーブルにおける類似性が最も高い上記検証項目を、追加予定検証項目として選択する、バグ対応追加選択ステップ、
上記の追加予定検証項目について検証を実行する追加検証ステップ、
上記追加検証ステップにおいてバグを検出した場合に、当該バグを検出した上記検証項目に対して、上記バグ対応追加選択ステップと同じ手順を実行した後、さらなる上記追加予定検証項目に対して上記追加検証ステップを実行するステップを、バグが検出されなくなるまで繰り返す消尽ループステップ、
を順に実行する。上記選択ループステップを構成する（１）（２）のステップは次の通りである。
（１）上記検証項目のうち、上記出現回数合計値が最も少ない上記構成要素を検証対象として含む中で、内包する上記構成要素が最も多い上記検証項目を、実行予定項目として選択する予定登録ステップ。
（２）上記で選択された上記実行予定項目に含まれる上記構成要素のレコードを上記候補テーブルから削除する候補除外ステップ。
となる。
【００１３】
類似性を評価する値としては、例えば、上記検証項目のそれぞれにおける、個々の構成要素の有無を成分が１である多次元ベクトルで表して、その多次元ベクトル同士の内積の値によって類似性の高さを示すことができる。逆に網羅性を高めようとするのであれば、一の検証項目を選んだ後、次に選ぶ検証項目は、一の検証項目との内積が小さいものを選んだり、外積が大きい物を選んだりすることで実現できる。より細かくチェックするのであれば、一旦検証項目を実際に検証した後に、それに含まれる上記構成要素を外したテーブルを作成した上で、その新たなテーブルの中で上記構成要素の数が最も多いものを選ぶという手順でも可能である。
【発明の効果】
【００１４】
この発明により、プログラムの開発にあたってバグの有無を検証する際に、バグを検出した際には、バグを検出した検証項目に対して類似性の高い検証項目を選び直し、又はバグを検出しなかった検証項目が併せて存在する場合には、その検証項目に対して類似性の低い検証項目を選び直すことで、無駄な重複となる検証を出来るだけ抑制しながら、バグの検出に対応して動的に検証項目を充実させることができ、高い網羅率を少ない回数で達成してプログラムの検証ができるので、プログラムの開発効率を向上させることが出来る。
【図面の簡単な説明】
【００１５】
【図１】この発明を実行するプログラムの例における候補テーブルの図
【図２】図１の候補テーブルから導かれる内積で表した類似性一覧テーブル
【図３】この発明にかかる検証方法の実施フローを示す図の前半
【図４】候補除外ステップを実行中の一時的候補テーブルの例図
【図５】この発明にかかる検証方法の実施フローを示す図の後半
【発明を実施するための形態】
【００１６】
以下、この発明について実施形態を挙げて詳細に説明する。
この発明は、プログラムにより動作するシステムの開発にあたり、バグを検証するための効率的な検証方法である。
【００１７】
この発明が対象とするプログラムとしては、モジュール（構成要素）の集合体としてプログラミングできる言語によるものをいい、基本的にはオブジェクト指向の言語に対して有効に用いることができる。例えば、Ｃ＋＋、Objective-C、Javascript（登録商標）、ＪＡＶＡ（登録商標）などによる開発の際に用いることができる。これらの場合の構成要素としては、具体的には個々のユーザー定義関数を構成要素としてもよいし、複数のユーザー定義関数を纏めたものを構成要素として捉えてもよい。特に、これらの構成要素となる関数が統一された基準で定義されており、関数の共用が計られるプログラムにおいて、この発明にかかる検証方法は有効に働く。例えば、JAVAのプログラムによって機械的に生成されるJavascriptのコードのように、人為的な定義が関与するところが少ないほど、構成要素の共用が計られているため、類似性の評価が現実に近い物となるため好ましい。
【００１８】
この発明で検証する検証項目とは、プログラムが実際にユーザやシステムそのものにより実行される際に、起こりうるケースを想定した具体的なテストである。例えばＧＵＩ−ＷＥＢシステムの開発においては、個々の構成要素がJavascriptを含むＷｅｂページについて個々に表示するテストだけでなく、個々のｗｅｂページＡからｗｅｂページＢへの遷移とその逆遷移、さらにはcookieの値を変化させての個々のｗｅｂページの遷移など、実際の利用の際に起こりうるケースを想定した活動を検証項目として列挙していき、それぞれの際に実行している構成要素をリスト化する。
【００１９】
このような、検証項目毎に、それが含む、すなわちその検証項目によってチェックが可能な構成要素の一覧をリスト化した候補テーブルの例を図１に示す。ＷＥＢ−ＧＵＩの開発にあたっての検証を例にとり、横軸のＡ〜Ｆは個々のｗｅｂページやページ間の遷移である検証項目であり、縦軸のａ〜ｅはそれぞれのページや遷移で用いているJavascriptの関数である構成要素である。表中右端のチェック回数とは、上記構成要素（Javascriptの関数）ごとに、全ての検証項目の中で該当する項目が何件存在するかを示す出現回数合計値である。この出現回数合計値が高い構成要素は、多くの検証項目でカバーできる構成要素であることを意味しており、出現回数合計値が１の構成要素は、ある特定の一つの検証項目でしかチェックできないことを意味している。また、個々の検証項目が有する構成要素の数の合計は、一つの検証項目で検証できる網羅性の高さを示しており、検証項目を選択する際の判断基準の一つとなる。
【００２０】
実際の検証にあたっては、縦軸横軸ともにレコード数、カラム数が膨大なものとなることがあるので、個々の検証項目において出現する構成要素（関数）の抽出はソースコードの全文検索により自動的に行うことが好ましい。
【００２１】
この候補テーブルの値を用いて、上記検証項目ごとの、他の上記検証項目との間の類似性を評価する値のテーブルである類似性一覧テーブルを作成する。ここで類似性とは、他の検証項目との間で共通している構成要素の数の多さであり、類似性が高いほど、同じ構成要素を重複してチェックすることになる。この類似性の値の出し方は特に限定されないが、例えば、上記候補テーブルにおける個々の検証項目Ａ〜Ｆにおいて、個々の構成要素を成分としたベクトル同士の、内積の値の大きさによって表現することができる。図１の候補テーブルを元に、類似性の計算に内積を用いた類似性一覧テーブルの例を図２に示す。すなわち、Ａ＝（１，１，１，０，０）Ｔ、Ｂ＝（０，０，１，１，０）Ｔとの内積Ａ・Ｂ＝１となる。これは、構成要素ｃのみが共通していることによる。一方、Ａ・Ｃ＝２であり、これは構成要素ａ，ｂの２つが共通していることによる。
【００２２】
これらのうち、まず候補テーブルを用いて、実際に検証を行う項目を決定する手順を図３のフローと図４の表により説明する。なお、ここで用いる候補テーブルは、最初に作った候補テーブルを保存した上で、作業用に別途同一のテーブルをメモリ空間に用意した上でテーブルに対する削除を含めた編集を行うことが好ましい。この、作業を行うコピーした候補テーブルを、下記の説明で一時的候補テーブルと記載することがある。
【００２３】
まず（Ｓ１０１）、検証項目の候補一覧である候補テーブルを、プログラムの解析によって作成する（Ｓ１０２）。この候補テーブルをコピーした一時的候補テーブルに対して、次の選択ループステップ（Ｓ１０３〜）を実行することで、実際に検証を行う実行予定項目を選択する。選択ループステップでは、選択した検証項目を実行予定項目として登録する予定登録ステップ（１）と、その登録した実行予定項目に含まれる上記構成要素のレコードを削除する候補除外ステップ（２）とを繰り返す。これを順に説明する。
【００２４】
その時点における一時的候補テーブルに残る検証項目のうち、「出現回数合計値が最少である構成要素」を含む検証項目を抽出する（Ｓ１０３）。例えば図１では、出現回数合計値（チェック回数）が最少である構成要素は、値が１である構成要素ｄである。この構成要素ｄは検証項目Ｂでしか検証できないことがわかる。このとき、出現回数合計値が最少である構成要素が、同値で複数ある場合は（Ｓ１０４−Ｎｏ）、それぞれを含む検証項目のうち、網羅性が高いものを選択する（Ｓ１０５）。また、最少の出現回数合計値である構成要素の値が２以上である場合にも（Ｓ１０４−Ｎｏ）、その構成要素を有する検証項目のうち、内包する構成要素の数が最も多い、すなわち網羅性の評価値の高い検証項目を選択する（Ｓ１０５）。一度により多くの構成要素についてチェックできる検証項目を優先して選ぶことで、検証回数を圧縮することが出来るからである。なお、網羅性も同値である検証項目が複数ある場合は（Ｓ１０６−Ｎｏ）、二番目に出現回数合計値が少ない構成要素を含む検証項目を優先し（Ｓ１０７）、その条件も同じであれば（Ｓ１０４−Ｎｏ）、網羅性の評価値がより高い検出項目を優先し（Ｓ１０５）、三番目に出現回数合計値が少ない構成要素を含む検証項目を優先・・という順序で条件を絞り込んでいく。これにより、できるだけ高い効率での検証を可能にする検証項目が選択できる。ただしこれは一例であり、同値複数の場合はランダムでいずれかを優先したり、あるいはテーブルで先にある方を優先したりすることで、フローを簡略化することも可能である。
【００２５】
こうして抽出、選択された検証項目を（Ｓ１０８）、実際に検証を行う予定である実行予定項目として記憶部に登録する予定登録ステップを行う（Ｓ１１１）。この登録された実行予定項目に含まれる上記構成要素を、一時的候補テーブルから削除する候補除外ステップを行う（Ｓ１１２）。図１の候補テーブルでは、最少の出現回数合計値である１となる構成要素ｄを含む検証項目Ｂが該当し、検証項目Ｂに含まれる構成要素ｃとｄを一時的候補テーブルから削除する。この削除した後の一時的候補テーブルを図４に示す。
【００２６】
既に上記実行予定項目に含まれる構成要素の挙動については、ひとまずその実行予定項目によって検証できる。そこで、まだ検証されていない構成要素を出来るだけ効率良く選択するために、構成要素数が減少した一時的候補テーブルに対して、さらに上記と同様の予定登録ステップと候補除外ステップからなる選択ループステップを実行する。すなわち、一時的候補テーブルから、登録された上記実行予定項目に含まれる構成要素のレコードを削除し（Ｓ１１２）、まだ一時的候補テーブルに構成要素のレコードが残っているのであれば（Ｓ１１３−Ｙｅｓ）、再びＳ１０３から同じフローを実行する。これを、一時的候補テーブルから全ての構成要素のレコードが無くなるまで、すなわち、全ての上記構成要素が、登録された実行予定項目のいずれかによって、少なくとも一度は検証される準備が整うまで繰り返す（Ｓ１１３−Ｎｏ→Ｓ１１５）。
【００２７】
図４に対して同様の手順を行うと、残る構成要素のうち、最少の出現回数合計値である構成要素はｂである。構成要素ｂを含む検証項目はＡとＣであるが、検証項目Ａは構成要素ａ，ｂの２つで、検証項目Ｃはａ，ｂ，ｅの３つであるため、一つの検証項目でより多くの構成要素を検証できる検証項目Ｃを選択する。検証項目Ｃは残る構成要素の全てをカバーできるので、一時的候補テーブルから全ての構成要素のレコードはこれで無くなることになる。
【００２８】
以上の手順により登録された実行予定項目について、実際にバグが生じるか否か、検証を行う基本検証ステップを実行する（Ｓ１１７）。ここで、全ての登録した実行予定項目について一括して検証を行った後に、次のステップへと移る。ただし、全ての検証項目について終える前に、一つ又は規定数のバグが検出された時点で次のステップに進んで動的に検証項目を追加しても良い。
【００２９】
この基本検証ステップでバグを検出した検証項目に着目し、これと類似性の高い検証項目について、さらに検証を行う追加予定検証項目として選択するバグ対応追加選択ステップを実行する。このフローを図５に示す。上記の基本検証ステップでの結果、バグを検出した検証項目を抽出する（Ｓ１２２）。抽出された検証項目は複数である場合もある。バグを検出した検証項目が含む構成要素のうち、どれによってバグが発生したのかを突き止めるため、その検証項目に類似した検証項目について、追加で検証を行う。まず、抽出した検証項目のうち（Ｓ１２３）、一の検証項目に対して、最も類似性が高い検証項目を、さらに検証を行うための追加の検証項目候補として選択する（Ｓ１２４）。この選択した項目が一つであれば（Ｓ１２５−Ｙｅｓ）その選択した検証項目候補を、記憶部に追加予定検証項目に登録する（Ｓ１３１）。前記の選択した項目が複数であれば（Ｓ１２５−Ｎｏ）、その複数の選択した項目のうち、先の検証においてバグを検出しなかった検証項目との類似度が最低の検証項目候補を選択する（Ｓ１２６）。これは、バグを検出しなかった検証項目に類似しているほどバグが無い可能性が高く、非類似であるほどバグがある可能性が高くなるからである。なお、前記の類似度が最低の検証項目が一つであれば（Ｓ１２７−Ｙｅｓ）、先の複数の選択項目の中からその項目を選んで追加予定検証項目に登録する（Ｓ１３１）。類似度が最低の検証項目が複数であれば（Ｓ１２７−Ｎｏ）、他にバグを検出しなかった項目とも比較して、その中で類似度がより低いものを追加予定検証項目として登録する（Ｓ１２８、Ｓ１３１）。このような追加予定検証項目への登録を、先にバグを検出した検証項目ｎの分だけ繰り返す（Ｓ１２３，Ｓ１３２，Ｓ１３３）。
【００３０】
なお、追加予定検証項目に登録しようとする検証項目が、既にここまでの段階で検証済みである場合は、Ｓ１３１での登録は行わずにフローを進める。
【００３１】
具体例により説明すると、先の図１及び図４の候補テーブルから選択した実行予定検証項目Ｂ，Ｃのうち、仮に、Ｂでバグが検出され、Ｃでは検出されなかったとする。この場合、Ｂに対する類似性を、図２の類似性一覧テーブルを参照すると、Ｂに対する類似性は、Ａ，Ｄ，Ｆが１で、Ｃ，Ｅが０である。このうち、Ｃは既に実行した検証項目なので除外し、類似度が最も高いものはＡ，Ｄ，Ｆとなる（Ｓ１２４）。これらのうち、バグを検出しなかった検証項目Ｃに対する類似性が最も低いものを選ぶとなると、Ａは２、Ｄは１、Ｆは２なので、類似性最低の検証項目候補はＤが唯一となる（Ｓ１２６、Ｓ１２７−Ｙｅｓ）。従って、追加予定検証項目にＤを登録する（Ｓ１３１）。
【００３２】
先に行った検証の実行によりバグが検出された検証項目の全てに対してここまでのバグ対応追加選択ステップを実行して、追加予定検証項目を記憶部に登録し終えたら、それら登録した追加予定検証項目について実際に検証する追加検証ステップを実行する（Ｓ１３４）。
【００３３】
さらに、上記の追加検証ステップにおいてバグを検出した場合に（Ｓ１３５−Ｙｅｓ）、当該バグを検出した上記検証項目に対して、上記バグ対応追加選択ステップと同じ手順を実行した後、さらなる上記追加予定検証項目に対して上記の追加検証ステップを実行する工程をバグが検出されなくなるまで繰り返す、消尽ループステップを実行する。なお、実行予定の検証項目を全て検証した上で、それら全てでバグの検出が無くなった時点で検証は完了する（Ｓ１３５−Ｎｏ、Ｓ１３６）。
【００３４】
さらにまた、上記とは別のバグ対応追加選択ステップを行っても良い。直前の検証において、バグを検出した上記検証項目と、バグを検出しなかった上記検証項目との両方がある場合に、バグを検出した上記検証項目ではなく、バグを検出しなかった上記検証項目の全てを基準として、それに対する類似性の値の合計が最も低い上記検証項目を、追加予定検証項目として登録する。例えば、検証項目Ｐ、Ｑ、Ｒにおいてバグが検出されなかった場合、他の検証項目のそれぞれについて、Ｐ，Ｑ，Ｒとの間の類似性の値を合計した値を求める。その合計値が最も小さかったものが、Ｐ，Ｑ，Ｒとの全てからの類似性を仮想的に表した距離が総合的にもっとも低いものであるため、次に検証したときに、バグが見つかる可能性が最も高くなる。ここで、類似性の値は、上記の内積の値を使っても良い。または、網羅性を高めるという意味で、バグを出さなかった上記検証項目との外積を最大とするような上記検証項目を選択してもよい。外積を用いるとはすなわち、未検証の検証項目のそれぞれを表す縦ベクトルについて、既検証かつバグ非検出の検証項目のそれぞれ（例えば上記のＰ，Ｑ，Ｒ）に対する、縦ベクトルの外積のスカラー量が最大になる上記検証項目を、追加予定検証項目として登録する。外積のスカラー量は、類似性が低くなるほど大きくなるため、バグを検出しなかった上記検証項目との類似性が低い、つまり、バグを検出する可能性が高い上記検証項目を、追加予定検証項目として選ぶことができる。
【００３５】
上記の方法により、バグの検出がされたら、当然にバグが検出された検証項目に含まれる上記構成要素を修正変更する構成要素改修ステップを実行する。すなわち、プログラムのバグフィクスである。上記構成要素を変更した後は、バグの出現状況が変わってくるため、改めてプログラムの検証を行うことが望ましい。各検証項目が含む上記構成要素の関係まで変わってくる場合は、上記候補テーブルや上記類似性一覧テーブルを、変更後の状況に則したものに更新する。そうでない場合は引き続き同一のテーブルを利用しても、変更後に対応できる。この変更後に対応した上記候補テーブルや上記類似性一覧テーブルについて、上記構成要素改修ステップにて変更した当該構成要素を含む上記検証項目のうち、網羅性の値が最も高い上記検証項目を追加予定検証項目として選択する、改修後追加選択ステップを実行する。変更した上記構成要素が複数ある場合には、それらの全てをカバーできるまで、追加予定検証項目の選択を同様に行う。こうして選択した後、上記追加検証ステップと、上記消尽ループステップを実行して、上記と同様の検証を行う。このときにまたバグが検出されたら、再び上記の構成要素改修ステップを行い、以後、バグが検出されなくなるまで繰り返す。
【図１】
2015169981.tif 000003
【図２】
2015169981.tif 000004
【図３】
2015169981.tif 000005
【図４】
2015169981.tif 000006
【図５】
2015169981.tif 000007