JP5464031B2

JP5464031B2 - プログラム検証装置、方法及びプログラム

Info

Publication number: JP5464031B2
Application number: JP2010099995A
Authority: JP
Inventors: 祐介橋本
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2010-04-23
Filing date: 2010-04-23
Publication date: 2014-04-09
Anticipated expiration: 2030-04-23
Also published as: JP2011232814A

Description

本発明は、プログラムを検証するプログラム検証装置、プログラム検証方法及びプログラム検証用プログラムに関する。

プログラムが検証したい性質（プロパティ property）を満たすか否かをモデル検査法（model checking）により静的に調べて、不具合を検出する方法があり、ソフトウェアモデル検査（software model checking）またはモダンモデル検査（modern model checking）と呼ばれている。

なお、対象プログラムを静的に検証するとは、コンピュータに対象プログラムを実行させずに、不具合の有無を確認することを意味する。例えば、静的解析ツールによって、対象プログラムのソースコードや実行可能なバイナリコードを用いて検証する。

また、対象プログラムを動的に検証するとは、コンピュータに対象プログラムを実行させて、不具合の有無を確認することを意味する。プログラミング言語によっては、対象プログラムのソースコードを実行可能なバイナリコードに変換することや、ソースコードをそのままインタープリタによって実行することもある。

モデル検査法とは、システムやソフトウェアの振舞いを表した、有限個の状態（state）および状態間の遷移（transition）から成る有限状態空間（finite state space）において、空間内を網羅探索することにより、検証したい性質が成立するか否かを調べる手法である。とくに、探索の深さを限定した有界モデル検査法（bounded model checking）は、不具合の検出に有効であるとされている。有界モデル検査法を用いたソフトウェアモデル検査においては、検証対象プログラムに出現する全ての変数に関して、変数値の組合せの一つ一つが状態である。

非特許文献１には、有界モデル検査法をプログラムの検証へ適用した一例が記載されている。非特許文献１に記載された例では、プログラムに表れる各変数の値の遷移を制約式Cとして表現し、検証したい性質を論理式Pとして表現し、C∧¬P（∧は論理和、¬は否定）を満たす変数値の推移を網羅探索により検出することを試みる。

この変数値の推移は反例（counter-example）と呼ばれており、反例が検出された場合、反例として示された変数の値の推移を行うようなパスを辿ると、検証したい性質を満たさないような不具合が発生するといえる。尚、非特許文献１では、プログラムをモデル検査用の制約式に変換する際に、ループをＮ回までの固定回数の繰り返しで打ち切るといった近似を行うことが説明されている。

非特許文献２には、検証したい性質を表現する一つの考え方に「契約による設計」（Design by Contract（登録商標））が記載されている。この考え方では、検証対象プログラムに、検証対象プログラムの開始状態で満たされるべき事前条件と検証対象プログラムの終了状態が満たすべき事後条件と、検証対象プログラムの実行によっても変わらないデータの不変条件と、を表明（Assertion）として記述する。そして、表明に照らしてプログラムが正しく実装されているか否かを、プログラムを実行して動的に検証する、またはプログラムを実行せずに静的に検証する。

表明に照らしてのプログラムの検証をモデル検査により静的に行って、不具合を検出する方法の一例が特許文献１に記載されている。

なお、本発明に関連する研究として、検証対象プログラムによって変更される出力変数を含まないガード条件（Guard condition）と出力変数を含む定義条件（Defining condition）との論理積を項とする選言標準形（DNF. Disjunctive normal form）で、事後条件を表現する考え方が非特許文献３に記載されている。

また、線形演算などを含む論理式について、論理式を真とするような数値を算出する技術ＳＭＴ（Satisfiable Modulo Theories）ソルバの一例が非特許文献４に記載されており、例えば、０≦ｘ∧ｘ＜ｙ（∧は論理積）を満たす値の組として（ｘ，ｙ）＝（０，１）などを算出できる。

また、プログラムの構造カバレッジに関しては、命令カバレッジ（Statement coverage）、判定カバレッジ（Decision coverage）、または、MC/DCカバレッジ（Modified decision condition coverage）がプログラムを実行してのテストでよく使われている。命令カバレッジは、各文（Statement）を一度は実行したことを示す。判定カバレッジは、各ループや分岐の判定（Decision）が真となる場合と偽となる場合とを一度は実行したことを示す。MC/DCカバレッジは、各ループや分岐の判定を構成する条件（Condition）が、他の条件の値を固定した場合に、ある条件の真偽によって判定の真偽が決まるような条件の組合せを一度は実行したことを示す。

特開２００９−２１１５０３号公報

E. Clarke, D. Kroening, and F. Lerda.A Tool for Checking ANSI−C Programs.Proceedings of TACAS' 04, pages 1680-176, 2004.(検査の仕方は頁169-170の節2.1 Generating the Formulaを参照。ループの近似は同節の第2項を参照) B. Meyer.Applying "Design by Contract".IEEE Computer, Vol.25, No.10, pages 40-51. 1992.(頁42の節Assertions：Contracting for softwareおよびFigure 2を参照)※ Design by Contractは米国Eiffel Software, Inc.の登録商標です。 S. Liu, T. Tamai, and S.Nakajima.Integration of Formal Specification, Review, and Testing for Software Component Quality Assurance.Proceedings of the 2009 ACM symposium on Applied Computing, pages 415-421. 2009.(頁417のDefinition 1.を参照) B. Dutertre and L. de Moura.A fast linear-arithmetic solver for DPLL(T).Proceedings of the 18th International Conference on Computer Aided Verification (CAV'06), vol.4144, LNCS, pages 81-94. 2006.(節4.6 Exampleを参照)

ソフトウェアモデル検査を用いたプログラム検証ツール（ソフトウェアモデル検査ツール）には、与えた検証対象プログラムのサイズが大きいか制御ロジックが複雑であると、網羅探索に要するCPUの処理時間やメモリ・ディスク装置などの資源が指数関数的に増大して判定不能となり得るという問題がある。また、プログラムよりも振る舞いが増えるような過大近似（over-approximation）を行うと、実際には起きない不具合、いわゆる見掛けの不具合（spurious error）を検出し得るという問題がある。また、プログラムよりも振る舞いが減るような過小近似（under-approximation）を行うと、不具合を見落とし得るという問題がある。

特許文献１に記載された例においても、判定不能、過大近似による見掛けの不具合、過小近似による不具合の見落としが起こり得る。

判定不能について具体的に説明する。変数が３２ビットの符号付き整数型であるとすると、変数の定義域は、−２の３１乗から２の３１乗−１までの約４２億通りである。また、変数ｘ、ｙ、・・・に対して変数値の組合せは、４２億×４２億×・・・通りであり、変数の個数に対して指数関数的に増える。そのため、ソフトウェアモデル検査ツールの利用者が許容できる時間内で、またはソフトウェアモデル検査ツールに与えられた資源の範囲で、変数値の推移を網羅探索することが困難になる。

次に、過大近似について具体的に説明する。ソフトウェアモデル検査においては、検証対象プログラムに出現する全ての変数に関して、各変数の値の組合せの一つ一つが状態である。プログラムで多用される配列とは、配列要素という変数が複数集まったものであるから、配列のサイズが大きくなれば変数の個数も増える。すなわち、配列のサイズが大きくなれば状態数も増えることになり、上記の判定不能を引き起こしやすい。そこで、判定不能を避けるために、配列の特定の要素のみを変数として扱い、他の要素は変数として扱わないような近似を行うことが考えられる。

例えば、配列a[10]では、状態数は、近似を行わないと約４２億の１０乗となるが、最初の２個（a[0]とa[1]）の要素だけを変数とする近似を行えば約４２億の２乗となる。ここで、変数として扱わない配列要素について、値の設定を無視し、値の取得時には任意値を返すと解釈すると、プログラムの振る舞いが増えるので、過大近似が導入されている。

例えば、配列ａの３番目の要素a[2]について、プログラム上において、a[2]=10;といった値の設定を行う文を無視し、後続にif(a[2]==10){A}else{B}といった値の取得を行う分岐がある場合を想定する。この場合、本来は分岐の判定が真に対応するブロックＡしか実行され得ないにも関わらず、a[2]から任意値が取得されるという近似により、分岐の判定が偽に対応するブロックＢも実行され得ると解釈することになり、プログラムの振る舞いが増える。この状況でブロックＢにおける不具合を検出した場合、その不具合は本当にプログラムを実行した場合には起こらないので、見掛けの不具合である。

次に、過小近似について具体的に説明する。判定不能や見掛けの不具合を避けるために、変数から任意値ではなく特定の値が取得されると解釈すると、プログラムの振る舞いが減るので、過小近似が導入されている。例えば、大域変数ｇについて、本来は任意の値の可能性がある場合にも、特定の値である０のみであると解釈する場合を想定する。この場合、if(g==0){A}else{B}といった値の取得を行う分岐では、本来は分岐の判定が真に対応するブロックＡも偽に対応するブロックＢも実行し得るにも関わらず、ｇを０とする近似により、分岐の判定が真に対応するブロックＡしか実行され得ないと解釈することになり、プログラムの振る舞いが減る。この状況ではソフトウェアモデル検査においてブロックBを探索していないので、もし不具合がブロックＢにあるならば不具合の見落としが起こる。

ソフトウェアモデル検査を用いたプログラム検証では、判定不能と過大近似と過小近似とに関してソフトウェアモデル検査以外の方法で表明に照らしてプログラムを検査する必要がある。このため、判定不能以外の結果に関して、過大近似および過小近似の導入を検知できる必要がある。

そこで、本発明は、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができるプログラム検証装置、プログラム検証装置、プログラム検証方法及びプログラム検証用プログラムを提供することを目的とする。

本発明によるプログラム検証装置は、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証手段と、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形手段と、ソフトウェアモデル検証手段の検証結果が反例ありを示している場合には、反例ごとに中間プログラムに対する過大近似の導入を検出する過大近似検出手段と、ソフトウェアモデル検証手段の検証結果が判定不能以外の結果を示している場合には、中間プログラムに対する過小近似の導入を検出する過小近似検出手段とを備えたことを特徴とする。

本発明によるプログラム検証方法は、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証ステップと、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形ステップと、中間プログラムについてソフトウェアモデル検証ステップで検出した不具合について過大近似の導入を検出する過大近似検出ステップと、中間プログラムについて過小近似の導入を検出する過小近似検出ステップとを含むことを特徴とする。

本発明によるプログラム検証用プログラムは、コンピュータに、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証処理と、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形処理と、中間プログラムについてソフトウェアモデル検証処理で検出した不具合について過大近似の導入を検出する過大近似検出処理と、中間プログラムについて過小近似の導入を検出する過小近似検出処理とを実行させることを特徴とする。

本発明によれば、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができる。

本発明によるプログラム検証方法を適用した情報処理装置の全体構成の一例を示すブロック図である。プログラム検証方法を適用した情報処理装置の全体的な処理の流れの一例を示すフロー図である。プログラムの整形ルールの具体例を示す説明図である。プログラムの整形の具体例を示す説明図である。過大近似の検知方法の具体例を示す説明図である。過小近似の検知方法の具体例を示す図説明である。テストケース生成＆実行ステップの処理の流れの具体例を示すフロー図である。機能シナリオの抽出の具体例を示す説明図である。テスト入力の生成とテストプログラムの生成の具体例を示す説明図である。検証対象プログラムへのカバレッジ測定用コードの挿入方法の具体例を示す説明図である。プログラム検証装置の最小の構成例を示すブロック図である。

以下、本発明の実施形態について図面を参照して説明する。

＜装置構成＞
図１は、本発明によるプログラム検証方法を適用した情報処理装置１００の概略構成を示す図である。情報処理装置１００は、情報処理部１８０とファイル格納部１９０とを含む。情報処理装置１００は、具体的にはパーソナルコンピュータ等によって実現される。情報処理部１８０は、具体的には、プログラムに従って動作する情報処理装置のＣＰＵによって実現される。ファイル格納部１９０は、具体的には、光ディスク装置や磁気ディスク装置、メモリ等の記憶装置によって実現される。

情報処理部１８０は、制御モジュール１１０と、ソフトウェアモデル検査モジュール１２０と、プログラム整形モジュール１３０と、過大近似検知モジュール１４０と、過小近似検知モジュール１５０と、テストケース生成モジュール１６０と、テスト実行モジュール１７０とを含む。

情報処理部１８０が含むこれらのモジュールのうち、制御モジュール１１０は、利用者による検証対象プログラムの指定操作に従って、他のモジュールに図２で示す一連の処理を実行させる機能を備えている。各モジュールは、具体的には、情報処理装置が備えるプログラムによって実現される。また、情報処理装置は、各モジュールに従って処理を実行する。

ここで、本実施形態において、検証対象プログラムは、Ｃ言語で記述されており、かつ、検証の対象である関数（検証対象関数）と、その関数に付与された事前条件および事後条件といった表明を含むものとする。また、事後条件は、選言標準形で記述されているものとする。なお、本実施形態では、Ｃ言語で記述されたプログラムを検証対象とするが、検証対象のプログラムはＣ言語以外のプログラム言語（例えば、Ｊａｖａ（登録商標）など）で記述されていてもよい。

ソフトウェアモデル検査モジュール１２０は、検証対象プログラムを検証する機能を備えている。具体的には、ソフトウェアモデル検査モジュール１２０は、ファイル格納部１９０から検証対象プログラムを含むファイルを読み込み、検証対象プログラムに付記された表明に照らして検証対象関数を検証し、不具合を検出すれば反例を出力する。

プログラム整形モジュール１３０は、検証対象プログラムを整形して中間プログラムを生成する機能を備えている。具体的には、プログラム整形モジュール１３０は、検証対象プログラムをＣ言語のサブセットの表現に変換し、構造カバレッジの観点で検査すべき箇所を独立した分岐ブロックに分解し、表明も含めて中間プログラムとして出力する。

過大近似検知モジュール１４０は、中間プログラムから過大近似を検知する機能を備えている。具体的には、過大近似検知モジュール１４０は、反例ごとに、中間プログラムに過大近似を検知するためのコードと過大近似が導入されなかったことを示す表明とを挿入する。そして、過大近似検知モジュール１４０は、上記の中間プログラムについてソフトウェアモデル検査モジュール１２０を用いてソフトウェアモデル検査を行い、表明違反が検出されれば過大近似が導入されたと判断する。

過小近似検知モジュール１５０は、中間プログラムから過小近似を検知する機能を備えている。具体的には、過小近似検知モジュール１５０は、中間プログラムに過小近似を検知するためのコードと過小近似が導入されたことを示す表明とを挿入する。そして、過小近似検知モジュール１５０は、ソフトウェアモデル検査モジュール１２０を用いてソフトウェアモデル検査を行い、表明違反が検出されなければ過小近似が導入されたと判断する。

テストケース生成モジュール１６０は、テストプログラムとカバレッジ測定用検証対象プログラムを生成する機能を備えている。具体的には、テストケース生成モジュール１６０は、検証対象関数に付記された事前条件と事後条件の一部とをテスト入力として、事後条件の残りを期待結果とするようなテストプログラムを生成して出力する。また、テストケース生成モジュール１６０は、中間プログラムにカバレッジを測定するためのコードを挿入したカバレッジ測定用検証対象プログラムを生成して出力する。

テスト実行モジュール１７０は、テストプログラムとカバレッジ測定用検証対象プログラムとを実行する機能を備えている。

本実施形態では、ソフトウェアモデル検査モジュール１２０は、特許文献１に記載された技術を用いて実現される。また、テストケース生成モジュール１６０は、非特許文献３の事後条件を選言標準形で表現する考え方を採用し、非特許文献４のＳＭＴソルバの技術を利用することによって実現される。

＜全体の処理の流れ＞
次に、図１及び図２のフローチャートを参照して本実施形態の全体の動作について説明する。図２は、プログラム検証方法を適用した情報処理装置の全体的な処理の流れの一例を示すフロー図である。

制御モジュール１１０は、利用者による検証対象プログラムの指定操作に従って、他のモジュールに図２に示す一連の処理を実行させる。

プログラムの検証を行うために、利用者は、情報処理装置で検査対象のプログラムを指定する操作を行う。すると、ソフトウェアモデル検査モジュール１２０は、利用者の操作に従って、ファイル格納部１９０から検証対象プログラムを読み込み、検証対象プログラムにおける変数の値の推移を表す制約式Cを求める。

次いで、ソフトウェアモデル検査モジュール１２０は、求めた制約式Cと検証対象プログラムに付記された表明である事前条件Preと事後条件Postとから、論理式Pre∧C∧¬Postの式を作成する。

次いで、ソフトウェアモデル検査モジュール１２０は、網羅探索により、作成した論理式を満たす変数の値の組合せを計算する。そして、（１）与えたプログラムが大きすぎるか複雑すぎるなどにより網羅探索できなかった場合には、ソフトウェアモデル検査モジュール１２０は、「判定不能」を検証結果として出力する。

また、（２）論理式を満たす変数値の組合せが算出できた場合には、ソフトウェアモデル検査モジュール１２０は、「反例あり」を検証結果として出力する。また、（３）判定不能ではなく、かつ変数値の組合せが算出できなかった場合には、ソフトウェアモデル検査モジュール１２０は、「反例なし」を検証結果として出力する（ステップＳ２０１）。

次いで、制御モジュール１１０は、ソフトウェアモデル検査モジュール１２０が出力した検証結果が「判定不能」であるか否かを判断する（ステップＳ２０２）。

ステップＳ２０２において、ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合には、制御モジュール１１０は、テスト実行のための一連の処理（ステップＳ２０３〜Ｓ２０４）を行うように制御する。

一方、ステップＳ２０２においてソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合には、制御モジュール１１０は、検証結果が「反例あり」であるか否かを判断する（ステップＳ２１１）。そして、ソフトウェアモデル検査の検証結果が「反例あり」であると判断した場合には、制御モジュール１１０は、反例毎に過大近似の検知とテストとを実行するための一連の処理（ステップＳ２１２〜Ｓ２１５）を行うように制御する。

また、ステップＳ２０２においてソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合には、制御モジュール１１０は、ステップＳ２１１〜Ｓ２１６とは並列的に、過小近似の検知とテストとを実行するための一連の処理（ステップＳ２２１〜Ｓ２２４）も行うように制御する。

なお、本実施形態において、制御モジュール１１０は、過大近似および過小近似に関する一連の処理については、並列または順不同に行ってよい。具体的には、制御モジュール１１０は、「判定不能」でないと判断した後の、ステップＳ２１１からＳ２１６までの処理と、ステップＳ２１１からＳ２２４までの処理とを、並列または順不同に行うように制御してもよい。図２に示す処理例では、ステップＳ２０５が並列に行える処理の流れの始まりを、ステップＳ２０６が並列に行える処理の流れの終わりを示す。

次に、過大近似の検知とテストとを実行するための一連の処理（ステップＳ２１２〜Ｓ２１５）の流れについて説明する。

ソフトウェアモデル検査の検証結果が「反例あり」であると判断した場合（ステップＳ２１１）、プログラム整形モジュール１３０は、検証対象プログラムを過大近似検知モジュール１４０（及び過小近似検知モジュール１５０）が適用可能なＣ言語のサブセットの表現に変換する。そして、プログラム整形モジュール１３０は、変換した検証対象プログラムに表明を含めて中間プログラムとして、過大近似検知モジュール１４０に出力する（ステップＳ２１２）。

次いで、過大近似検知モジュール１４０は、プログラム整形モジュールが出力した中間プログラムから過大近似の検知を行い（ステップＳ２１３）、過大近似が導入されたか否かを反例ごとに判断する（ステップＳ２１４）。

具体的には、過大近似検知モジュール１４０は、反例ごとに、中間プログラムに過大近似を検知するためのコードと過大近似が導入されなかったことを示す表明とを挿入する。そして、過大近似検知モジュール１４０は、ソフトウェアモデル検査モジュール１２０を用いてソフトウェアモデル検査を行い、表明違反が検出されれば過大近似が導入されたと判断し、反例から算出した入力条件を事前条件に追加した中間プログラムを出力する。

ステップＳ２１４において過大近似が導入されなかったと判断した場合には、制御モジュール１１０は、ステップＳ２１６に処理を移行し、未処理の反例があるか否かを判断する（ステップＳ２１６）。すなわち、制御モジュール１１０は、過大近似検知モジュール１４０が過大近似の検知処理を行っていない反例が中間プログラムに存在するか否かを判断する。そして、未処理の反例があると判断した場合には、制御モジュール１１０は、処理をステップＳ２１３に移行し、未処理の反例がなくなるまで、その後の処理を繰り返し実行するように制御する。

一方、ステップＳ２１４において過大近似が導入されたと判断した場合には、テストケース生成モジュール１６０は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール１６０は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。

次いで、テスト実行モジュール１７０は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う（ステップＳ２１５）。その後、制御モジュール１１０は、処理をステップＳ２１６に移行する。そして、制御モジュール１１０は、過小近似の検知とテストとを実行するための一連の処理（ステップＳ２２１〜Ｓ２２４）が完了していれば、処理を終了する。

次に、過小近似の検知とテストとを実行するための一連の処理（ステップＳ２２１〜Ｓ２２４）の流れについて説明する。

ソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合（ステップＳ２０２）、プログラム整形モジュール１３０は、検証対象プログラムを過小近似検知モジュール１５０（及び過大近似検知モジュール１４０）が適用可能なＣ言語のサブセットの表現に変換する。そして、プログラム整形モジュール１３０は、変換した検証対象プログラムに表明を含めて中間プログラムとして過小近似検知モジュール１５０に出力する（ステップＳ２２１）。

次いで、過小近似検知モジュール１５０は、プログラム整形モジュールが出力した中間プログラムから過小近似の検知を行い（ステップＳ２２２）、過小近似が導入されたか否かを判断する（ステップＳ２２３）。

具体的には、過小近似検知モジュール１５０は、中間プログラムに過小近似を検知するためのコードと過小近似が導入されたことを示す表明とを挿入する。そして、過小近似検知モジュール１５０は、ソフトウェアモデル検査モジュール１２０を用いてソフトウェアモデル検査を行い、表明違反が検出されなければ過小近似が導入されたと判断する。

過小近似が導入されたと判断した場合には（ステップＳ２２３）、テストケース生成モジュール１６０は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール１６０は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。そして、テスト実行モジュール１７０は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う（ステップＳ２２４）。その後、制御モジュール１１０は、処理をステップＳ２０６に移行する。

一方、過小近似が導入されていないと判断した場合には（ステップＳ２２３）、制御モジュール１１０は、処理をステップＳ２０６に移行する。そして、制御モジュール１１０は、過大近似の検知とテストとを実行するための一連の処理（ステップＳ２１２〜Ｓ２１５）が完了していれば、処理を終了する。

次に、ステップＳ２０２において、ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合に実行する一連の処理（ステップＳ２０３〜Ｓ２０４）の流れについて説明する。

ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合（ステップＳ２０２）、プログラム整形モジュール１３０は、検証対象のプログラムを整形する（ステップＳ２０３）。

具体的には、プログラム整形モジュール１３０は、検証対象プログラムを過大近似検知モジュール１４０および過小近似検知モジュール１５０が適用可能なものと同じＣ言語のサブセットの表現に置換する。そして、プログラム整形モジュール１３０は、それらに表明を含めて中間プログラムとしてテスト生成モジュール１６０に出力する。

次いで、テストケース生成モジュール１６０は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール１６０は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。

次いで、テスト実行モジュール１７０は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う（ステップＳ２０４）。その後、制御モジュール１１０は、処理を終了する。

＜＜プログラムの整形＞＞
次に、プログラムの整形ステップ（ステップＳ２１２、ステップＳ２２１）の具体例について、図３および図４を用いて説明する。図３は、プログラムの整形ルールの具体例を示す説明図である。図４は、プログラムの整形の具体例を示す説明図である。

図３の整形ルール３１では、＝の左辺が変換前の表現であり、右辺が変換後の表現である。本実施形態では、プログラム整形モジュール１３０は、変換前の表現が１から１０までのいずれかのルールの左辺に合致すれば、整形ルール３１を用いて、右辺の表現に変換する。そして、変換後の表現が１から１０までのいずれかのルールの左辺に合致すれば、プログラム整形モジュール１３０は、再び右辺の表現に変換するという処理を、合致するルールが出現しなくなるまで繰り返し行う。

具体的には、プログラム整形モジュール１３０は、図４（ａ）の検証対象プログラム４１について、関数全体（検証対象プログラム４１の３行目から１１行目）に対して整形ルール３１のルール１を適用する。このことにより、整形された中間プログラム４２には４ａ行目が追加される（図４（ｂ）参照）。

さらに、プログラム整形モジュール１３０は、条件文（検証対象プログラム４１の５行目）に対して整形ルール３１のルール６を適用する。このことにより、整形された中間プログラム４２には５ａから５ｆ行目が追加され、元の５行目の判定「mode==0」が「__d」に置換される。

＜＜過大近似の検知＞＞
次に、過大近似の検知ステップ（ステップＳ２１３）の具体例について、図５を用いて説明する（プログラムの整形は省略して説明する）。図５は、過大近似の検知方法の具体例を示す説明図である。

過大近似の具体例はソフトウェア検査モデル技術によって異なる。ここでは「配列の２番目以降の要素からは任意値が取得される」という近似の例を扱う（図５（ａ）の過大近似の検知方法の例５１の１行目）。また、検知の方法としては、過大近似の検知方法の例５１の２行目に示したｏ１からｏ４までの手順により、元の検証対象プログラム５２（図５（ｂ）参照）を過大近似検知用プログラム５３（図５（ｃ）参照）に変換する。

図５の過大近似検知用プログラム５３の左列は、過大近似の検知方法の例５１の２行目の手順ｏ１からｏ４が関係することを示す。また、過大近似検知用プログラム５３の中列は、元の検証対象プログラムの行番号（図５の検証対象プログラム５２の左列）を示す。

過大近似検知モジュール１４０は、過大近似の検知方法の例５１のｏ１に従い、検証対象プログラム５２の１行目の配列a[10]に対して同サイズのトラップ配列trap_a[10]とトラップ変数TrapOとを挿入する（過大近似検知用プログラム５３のｏ１行目）。トラップ変数TrapOは、真(1)のときのみ過大近似が導入されたことを示す変数である。

次いで、過大近似検知モジュール１４０は、過大近似の検知方法の例５１のｏ２に従い、検証対象プログラム５２の４行目の変数宣言の後で、トラップ変数TrapOに偽(0)を、トラップ要素trap_a[i](i=0..9)に固定値(0)を設定する（過大近似検知用プログラム５３のｏ２行目）。

次いで、過大近似検知モジュール１４０は、過大近似の検知方法の例５１のｏ３に従い、配列要素の取得（検証対象プログラム５２の６行目および８行目）の前で、トラップ要素が固定値でなければトラップ変数に真(1)を設定する（過大近似検知用プログラム５３のｏ３行目）。

次いで、過大近似検知モジュール１４０は、過大近似の検知方法の例５１のｏ４に従い、return文（検証対象プログラム５２の１１行目）の前に、トラップ変数TrapOが偽(0)であることを示す表明(__assert(!TrapO))を挿入する（過大近似検知用プログラム５３のｏ４行目）。

次いで、過大近似検知モジュール１４０は、過大近似の検知方法の例５１のｏ５に従い、ソフトウェアモデル検査モジュール１２０を用いて過大近似検知用プログラムの実行文（過大近似検知用プログラム５３の４行目から１０行目）が表明（過大近似検知用プログラム５３のｏ４行目）に違反しないかを調べる。このとき、反例が得られたということは、トラップ変数TrapOが真(1であった、すなわち過大近似が起きたことを示す。

＜＜過小近似の検知＞＞
次に、過小近似の検知ステップ（ステップＳ２２２）の具体例について、図４と図６を用いて説明する。図６は、過小近似の検知方法の具体例を示す図説明である。

過小近似の具体例はソフトウェア検査モデル技術によって異なる。ここでは「大域変数の値が初期値のままと見なす」という近似の例（図６（ａ）の過小近似の検知方法の例６１の１行目）を扱う。また、検知の方法としては、過小近似の検知方法の例６１の２行目に示したｕ１からｕ４までの手順により、元の検証対象プログラム４１から整形された中間プログラム４２を過小近似検知用プログラム６２および６３（図６（ｂ）（ｃ）参照）に変換する。

過小近似検知用プログラム６２および６３の左列は、過小近似の検知方法の例６１の２行目の手順ｕ１からｕ３が関係することを示す。また、過小近似検知用プログラム６２および６３の中列は、整形された中間プログラムの行番号（整形された中間プログラム４２の左列）を示す。

過小近似検知モジュール１５０は、過小近似の検知方法の例６１のｕ１に従い、トラップ変数TrapUを挿入し、真(1)を設定する（過小近似検知用プログラム６２のｕ１行目）。なお、トラップ変数TrapUは、真(1)のときのみ過小近似が導入されたことを示す変数である。

次いで、過小近似検知モジュール１５０は、過小近似の検知方法の例６１のｕ２における「検査すべき箇所」として、ここでは整形された中間プログラム上で、分岐の判定式が「__d」以外であり、分岐先の実行文が「__d=1;」または「;」だけであるブロックを選ぶ。なお、プログラムの整形ルール３１は、このブロックがMC/DCカバレッジを満たすための判定を構成する条件の組合せに相当するようになっている。

次いで、過小近似検知モジュール１５０は、１つ目の検査すべき箇所（整形された中間プログラム４２の５ｃ行目）について、過小近似の検知方法の例６１のｕ３に従い、トラップ変数に偽(0)を設定する（過小近似検知用プログラム６２のｕ３行目）。

次いで、過小近似検知モジュール１５０は、過小近似の検知方法の例６１のｕ４に従い、return文（整形された中間プログラム４２の１０行目）の前に、トラップ変数TrapUが真(1)であることを示す表明(__assert(TrapU))を挿入する（過小近似検知用プログラム６２のｕ４行目）。

次いで、過小近似検知モジュール１５０は、過小近似の検知方法の例６１のｕ５に従い、ソフトウェアモデル検査モジュール１２０を用いて過小近似検知用プログラムの実行文（過小近似検知用プログラム６２の４行目から９行目）が表明（過小近似検知用プログラム６２のｕ４行目）に違反しないかを調べる。このとき、反例が得られないということは、トラップ変数TrapUが真(1)であった、すなわち過小近似が導入されて６２のｕ３行目が実行されなかったことを示す。

また、過小近似検知モジュール１５０は、２つ目の検査すべき箇所（整形された中間プログラム４２の５３行目）についても、過小近似の検知方法の例６１のｕ３に従い、トラップ変数に偽(0)を設定し（過小近似検知用プログラム６３のｕ３行目）、１つ目の検査すべき箇所と同様に過小近似の検知方法の例６１のｕ４およびｕ５の手順を行う。なお、全ての検査すべき箇所のうち、１箇所でも過小近似の導入が検知されれば、プログラム全体についてテストを行う必要がある。

＜＜テストケース生成＆実行＞＞
次に、テストケース生成＆実行ステップ（ステップＳ２０４、ステップＳ２１５およびステップＳ２２４）の具体例について、図７と図８と図９と図１０とを用いて説明する。図７は、テストケース生成＆実行ステップの処理の流れの具体例を示すフロー図である。図８は、機能シナリオの抽出の具体例を示す説明図である。図９は、テスト入力の生成とテストプログラムの生成の具体例を示す説明図である。図１０は、検証対象プログラムへのカバレッジ測定用コードの挿入方法の具体例を示す説明図である。

テストケース生成モジュール１６０は、プログラム整形モジュール１３０または過大近似検知モジュール１４０が出力した中間プログラムを読み込み、中間プログラムの事前条件および事後条件から機能シナリオ（図８（ａ）の機能シナリオの抽出８１の６行目）を抽出する（ステップＳ７０１）。

具体的には、テストケース生成モジュール１６０は、図８の例では検証対象関数の表明８２（図８（ｂ））から、図８（ｃ）に示す機能シナリオ１（８３）と図８（ｄ）に示す機能シナリオ２（８４）とを抽出する。

次いで、テストケース生成モジュール１６０は、固定回数だけ以降の一連の処理（ステップＳ７０３〜Ｓ７０８）を繰り返す（ステップＳ７０２）。

テストケース生成モジュール１６０は、機能シナリオ毎に（ステップＳ７０３）、機能シナリオのうち、事前条件Preと事後条件のガード条件Cとの論理積（機能シナリオ１（８３）の１行目、機能シナリオ２（８４）の１行目）をＳＭＴソルバが適用可能な形式に変換する。そして、テストケース生成モジュール１６０は、ＳＭＴソルバを用いてPre∧Cが真となる変数値の組合せを生成する（ステップＳ７０４）。テストケース生成モジュール１６０は、ＳＭＴソルバが適用可能な形式として、例えば、図９（ａ）のテスト入力生成用論理式（ＳＭＴ−ＬＩＢ形式）９１に変換する。

ここで、ＳＭＴソルバを用いて生成した組合せ（図９（ｂ）のＳＭＴソルバで生成したテスト入力９２）は、引数ｘが０（ＳＭＴソルバで生成したテスト入力９２の４行目）、引数ｙが１（ＳＭＴソルバで生成したテスト入力９２の５行目）、大域変数modeが０（ＳＭＴソルバで生成したテスト入力９２の６行目）となっている。また、ＳＭＴソルバを用いて生成した組合せ（ＳＭＴソルバで生成したテスト入力９２）は、機能シナリオ１（８３）事前条件Preと事後条件のガード条件C１との論理積（機能シナリオ１（８３）の１行目）を満たすテスト入力となっている。

次いで、テストケース生成モジュール１６０は、ＳＭＴソルバで生成したテスト入力９２と機能シナリオ１（８３）から、テストプログラムの形式９３（図９（ｃ）参照）に合致するような、テストプログラム９４（図９（ｄ）参照）を生成する（ステップＳ７０５）。

テストプログラム９４に従って処理を実行するテスト実行モジュール１７０は、テスト入力（ＳＭＴソルバで生成したテスト入力９２の４行目から６行目）に対応して変数にテスト入力値を設定（テストプログラム９４のｃ１行目からｃ３行目）する。そして、テスト実行モジュール１７０は、検証対象関数を呼び出し（テストプログラム９４のｄ行目）、機能シナリオの定義条件（機能シナリオ１（８３）の２行目）を期待結果と見なして、検証対象関数の結果を期待結果に照らしてテストの合否を出力する（テストプログラム９４のｅ１行目からｅ４行目）。

また、テストケース生成モジュール１６０は、図１０（ａ）のカバレッジ測定用コードの挿入方法１００１に従って中間プログラムにカバレッジ測定用コードを挿入し、図１０（ｂ）に示すようなカバレッジ測定用検証対象プログラム１００２を生成して出力する。

テストケース生成モジュール１６０が全ての機能シナリオについてテストプログラムの生成を終えると（ステップＳ７０３）、テスト実行モジュール１７０は、ステップＳ７０５において生成したテストプログラム９４とカバレッジ測定用検証プログラム１００２とを実行する（ステップＳ７０６、Ｓ７０７）。

ステップＳ７０６においてテストプログラム毎のループ（すなわち、生成した全てのプログラムの実行）が終了すると、テストケース生成モジュール１６０は、実行結果（カバレッジ測定用検証プログラム１００２の例ではｃ２行目のログの出力）を調べて、カバレッジが十分か否かを判断する（ステップＳ７０８）。そして、全ての検査したい箇所が少なくとも一度実行されていればカバレッジが十分と判断し、十分であると判断した場合には、制御モジュール１１０は、テストケース生成＆実行ステップ（ステップＳ２０４、Ｓ２１５、Ｓ２２４）の一連の処理を終える。

一方、十分でないと判断した場合には、制御モジュール１１０は、処理をステップＳ７０２（固定回数のループ制御）に移行する（ステップＳ７０８）。そして、ステップＳ７０３からＳ７０８までの一連の処理を固定回数だけ繰り返したのちに、制御モジュール１１０は、テストケース生成＆実行ステップ（ステップＳ２０４、Ｓ２１５、Ｓ２２４）の一連の処理を終える（ステップＳ７０２）。

なお、ステップＳ７０３からＳ７０８までの一連の処理の繰り返しにおけるテスト入力の生成（ステップＳ７０４）においては、以前に生成した入力を除外するために、以前に生成した入力を否定する制約と以前の事前条件との論理積を新たな事前条件としてテスト入力を生成する。

例えば、以前に生成したテスト入力（ＳＭＴソルバで生成したテスト入力９２）について、これを否定する制約は(!(x==0&&y==1&&mode==0))(!は否定、&&は論理積、==は等号)である。この制約と以前の事前条件（検証対象関数の表明８２の事前条件Pre）との論理積(mode==0||mode==1)&&(0<=x&&x<y)&&(!(x==0&&y==1&&mode==0))を新たな事前条件とすることにより、テストケース生成モジュール１６０は、次のテスト入力では以前とは異なるテスト入力を得ることができる。

以上のように、本実施形態では、Ｃ言語で記述された対象プログラムのソースコードを、実行可能なバイナリコードではなく、静的解析ツール（ソフトウェアモデル検査手段）が処理しやすい形式のソースコードに変換する。

また、本実施形態では、検証対象プログラムに付記された表明に照らしてのプログラムの検証において、まずモデル検査法を用いて、検証対象プログラムを実行せずに静的に検証を行う。そして、過大近似の導入により検証結果に見掛けの不具合が含まれ得る場合と、過小近似の導入により検証結果に不具合の見落としがあり得る場合と、プログラムのサイズが大き過ぎたり制御が複雑過ぎたりすることにより検証結果が判定不能であった場合とに、表明に基づいてテストプログラムを生成することで、検証対象プログラムを実行して動的に検査を行うことができる。

以上のことから、本発明は、事前条件や事後条件といった表明に照らしてプログラムを静的に検証するための技術、および動的にテストするための技術に関する。そして、本発明によれば、ソフトウェアモデル検査の判定不能以外の結果に関して過大近似と過小近似の導入を検知することができ、判定不能と過大近似と過小近似に関して検証対象プログラムに記述された表明を元にテストケースを生成し、プログラム実行を伴うテストによって、表明に照らして検証対象プログラムを検証することができる。

次に、本発明によるプログラム検証装置の最小構成について説明する。図１１は、プログラム検証装置の最小の構成例を示すブロック図である。図１に示すように、プログラム検証装置は、最小の構成要素として、ソフトウェアモデル検証手段１０と、プログラム整形手段２０と、過大近似検出手段３０と、過小近似検出手段４０とを含む。

図１１に示す最小構成のプログラム検証装置では、ソフトウェアモデル検証手段１０は、検証対象プログラムに付記された表明に基づいて検証対象プログラムを静的に検証する。そして、ソフトウェアモデル検証手段１０の検証結果が反例ありを示している場合には、過大近似検出手段３０は、反例ごとに、プログラム整形手段２０が検証対象プログラムをプログラムの構造上のカバレッジ基準に合せて変換した中間プログラムに対する過大近似の導入を検出する。また、ソフトウェアモデル検査手段１０の検証結果が判定不能以外を示している場合には、過小近似検出手段４０は、中間プログラムに対する過小近似の導入を検出する。

従って、最小構成のプログラム検証装置によれば、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができる。

なお、本実施形態では、以下の（１）〜（５）に示すようなプログラム検証装置の特徴的構成が示されている。

（１）プログラム検証装置は、検証対象プログラム（例えば、検証対象プログラム４１）に付記された表明に基づいて検証対象プログラムを静的に検証するソフトウェアモデル検証手段（例えば、ソフトウェアモデル検証モジュール１２０によって実現される）と、検証対象プログラムをプログラムの構造上のカバレッジ基準に合せて変換し中間プログラム（例えば、整形された中間プログラム４２）として出力するプログラム整形手段（例えば、プログラム整形モジュール１３０によって実現される）と、ソフトウェアモデル検証手段の検証結果が反例ありの場合には、反例ごとに中間プログラムへの過大近似の導入を検出する過大近似検出手段（例えば、過大近似検知モジュール１４０によって実現される）と、ソフトウェアモデル検証手段の検証結果が判定不能以外の場合には、中間プログラムへの過小近似の導入を検出する過小近似検出手段（例えば、過小近似検知モジュール１５０によって実現される）とを備えたことを特徴とする。

（２）プログラム検証装置において、ソフトウェアモデル検証手段の検証結果が判定不能であることを示していた場合と過大近似の導入が検出された場合と過小近似の導入が検出された場合とに、中間プログラムにカバレッジ測定用コードを挿入したカバレッジ測定用検証対象プログラム（例えば、カバレッジ測定用検証対象プログラム１００２）と、検証対象プログラムに付記された表明に基づいて生成されたテスト入力データ（例えば、ＳＭＴソルバで生成したテスト入力９２）を用いて、カバレッジ測定用検証対象プログラムを呼び出して、カバレッジ測定用検証対象プログラムを実行した結果を検証対象プログラムに付記された表明に基づいて検証するためのテストプログラム（例えば、テストプログラム９４）とを生成するテストケース生成手段（例えば、テストケース生成モジュール１６０によって実現される）と、テストプログラムとカバレッジ測定用検証対象プログラムとを実行するテスト実行手段（例えば、テスト実行モジュール１７０）とを備えるように構成されていてもよい。

（３）プログラム検証装置において、テストケース生成手段は、テスト入力データを繰り返し生成する際には、検証対象プログラムに付記された表明の事前条件と以前のテスト入力データを否定する制約との論理積を新たな事前条件として用いることにより、以前のテスト入力データとは異なるテスト入力を生成するように構成されていてもよい。

（４）プログラム検証装置において、プログラム整形手段は、MC/DCカバレッジをプログラムの構造上のカバレッジ基準として用いるように構成されていてもよい。

（５）プログラム検証装置において、過大近似検出手段は、中間プログラムに過大近似を検出するためのコードと過大近似が導入されなかったことを示す表明とを挿入して（例えば、過大近似検知用プログラム５３を生成して）検証を行い、表明違反が検出されれば過大近似が導入されたと判断するように構成されていてもよい。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）検証対象プログラムに付記された表明に基づいて、前記検証対象プログラムを静的に検証するソフトウェアモデル検証手段と、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形手段と、前記ソフトウェアモデル検証手段の検証結果が反例ありを示している場合には、前記反例ごとに前記中間プログラムに対する過大近似の導入を検出する過大近似検出手段と、前記ソフトウェアモデル検証手段の検証結果が判定不能以外の結果を示している場合には、前記中間プログラムに対する過小近似の導入を検出する過小近似検出手段とを備えたことを特徴とするプログラム検証装置。

（付記２）ソフトウェアモデル検証手段の検証結果が判定不能であることを示していた場合と過大近似の導入が検出された場合と過小近似の導入が検出された場合とに、中間プログラムにカバレッジ測定用コードを挿入したカバレッジ測定用検証対象プログラムと、前記検証対象プログラムに付記された表明に基づいて生成されたテスト入力データを用いて、前記カバレッジ測定用検証対象プログラムを呼び出して、該カバレッジ測定用検証対象プログラムを実行した結果を前記検証対象プログラムに付記された表明に基づいて検証するためのテストプログラムとを生成するテストケース生成手段と、前記テストプログラムと前記カバレッジ測定用検証対象プログラムとを実行するテスト実行手段とを備える付記１記載のプログラム検証装置。

（付記３）テストケース生成手段は、テスト入力データを繰り返し生成する際には、検証対象プログラムに付記された表明の事前条件と以前のテスト入力データを否定する制約との論理積を新たな事前条件として用いることにより、以前のテスト入力データとは異なるテスト入力データを生成する付記２記載のプログラム検証装置。

（付記４）プログラム整形手段は、MC/DCカバレッジをプログラムの構造上のカバレッジ基準として用いる付記１から付記３のうちのいずれかに記載のプログラム検証装置。

（付記５）過大近似検出手段は、中間プログラムに過大近似を検出するためのコードと過大近似が導入されなかったことを示す表明とを挿入して検証を行い、表明違反が検出されれば過大近似が導入されたと判断する付記１から付記４のうちのいずれかに記載のプログラム検証装置。

（付記６）検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証ステップと、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形ステップと、前記中間プログラムについて前記ソフトウェアモデル検証ステップで検出した不具合について過大近似の導入を検出する過大近似検出ステップと、前記中間プログラムについて過小近似の導入を検出する過小近似検出ステップとを含むことを特徴とするプログラム検証方法。

（付記７）ソフトウェアモデル検証ステップの検証結果が判定不能であることを示していた場合と過大近似が検出された場合と過小近似が検出された場合とに、検証対象プログラムに付与された事前・事後条件といった表明に基づいてテストプログラムを生成し、かつ中間プログラムにカバレッジ測定用のコードを挿入してカバレッジ測定用の検証対象プログラムを生成し、さらに前記テストプログラムと前記カバレッジ測定用の検証対象プログラムとを実行するテストケース生成＆実行ステップを含む付記６記載のプログラム検証方法。

（付記８）コンピュータに、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証処理と、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形処理と、前記中間プログラムについて前記ソフトウェアモデル検証処理で検出した不具合について過大近似の導入を検出する過大近似検出処理と、前記中間プログラムについて過小近似の導入を検出する過小近似検出処理とを実行させるためのプログラム検証用プログラム。

（付記９）コンピュータに、ソフトウェアモデル検証処理の検証結果が判定不能であることを示していた場合と過大近似が検出された場合と過小近似が検出された場合とに、検証対象プログラムに付与された事前・事後条件といった表明に基づいてテストプログラムを生成し、かつ中間プログラムにカバレッジ測定用のコードを挿入してカバレッジ測定用の検証対象プログラムを生成し、さらに前記テストプログラムと前記カバレッジ測定用の検証対象プログラムとを実行するテストケース生成＆実行処理を実行させる付記８記載のプログラム検証用プログラム。

本発明は、プログラムを検証する用途に適用可能である。

１０ソフトウェアモデル検証手段
２０プログラム整形手段
３０過大近似検出手段
４０過小近似検出手段

Claims

検証対象プログラムに付記された表明に基づいて、前記検証対象プログラムを静的に検証するソフトウェアモデル検証手段と、
前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形手段と、
前記ソフトウェアモデル検証手段の検証結果が反例ありを示している場合には、前記反例ごとに前記中間プログラムに対する過大近似の導入を検出する過大近似検出手段と、
前記ソフトウェアモデル検証手段の検証結果が判定不能以外の結果を示している場合には、前記中間プログラムに対する過小近似の導入を検出する過小近似検出手段とを
備えたことを特徴とするプログラム検証装置。
ソフトウェアモデル検証手段の検証結果が判定不能であることを示していた場合と過大近似の導入が検出された場合と過小近似の導入が検出された場合とに、中間プログラムにカバレッジ測定用コードを挿入したカバレッジ測定用検証対象プログラムと、前記検証対象プログラムに付記された表明に基づいて生成されたテスト入力データを用いて、前記カバレッジ測定用検証対象プログラムを呼び出して、該カバレッジ測定用検証対象プログラムを実行した結果を前記検証対象プログラムに付記された表明に基づいて検証するためのテストプログラムとを生成するテストケース生成手段と、
前記テストプログラムと前記カバレッジ測定用検証対象プログラムとを実行するテスト実行手段とを備える
請求項１記載のプログラム検証装置。
テストケース生成手段は、テスト入力データを繰り返し生成する際には、検証対象プログラムに付記された表明の事前条件と以前のテスト入力データを否定する制約との論理積を新たな事前条件として用いることにより、以前のテスト入力データとは異なるテスト入力データを生成する
請求項２記載のプログラム検証装置。
プログラム整形手段は、MC/DCカバレッジをプログラムの構造上のカバレッジ基準として用いる
請求項１から請求項３のうちのいずれか１項に記載のプログラム検証装置。
過大近似検出手段は、中間プログラムに過大近似を検出するためのコードと過大近似が導入されなかったことを示す表明とを挿入して検証を行い、表明違反が検出されれば過大近似が導入されたと判断する
請求項１から請求項４のうちのいずれか１項に記載のプログラム検証装置。
検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証ステップと、
前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形ステップと、
前記中間プログラムについて前記ソフトウェアモデル検証ステップで検出した不具合について過大近似の導入を検出する過大近似検出ステップと、
前記中間プログラムについて過小近似の導入を検出する過小近似検出ステップとを
含むことを特徴とするプログラム検証方法。
コンピュータに、
検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証処理と、
前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形処理と、
前記中間プログラムについて前記ソフトウェアモデル検証処理で検出した不具合について過大近似の導入を検出する過大近似検出処理と、
前記中間プログラムについて過小近似の導入を検出する過小近似検出処理とを
実行させるためのプログラム検証用プログラム。