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

プログラム検証装置、方法及びプログラム Download PDF

Info

Publication number
JP5464031B2
JP5464031B2 JP2010099995A JP2010099995A JP5464031B2 JP 5464031 B2 JP5464031 B2 JP 5464031B2 JP 2010099995 A JP2010099995 A JP 2010099995A JP 2010099995 A JP2010099995 A JP 2010099995A JP 5464031 B2 JP5464031 B2 JP 5464031B2
Authority
JP
Japan
Prior art keywords
program
verification
approximation
over
verification target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010099995A
Other languages
English (en)
Other versions
JP2011232814A (ja
Inventor
祐介 橋本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2010099995A priority Critical patent/JP5464031B2/ja
Publication of JP2011232814A publication Critical patent/JP2011232814A/ja
Application granted granted Critical
Publication of JP5464031B2 publication Critical patent/JP5464031B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Description

本発明は、プログラムを検証するプログラム検証装置、プログラム検証方法及びプログラム検証用プログラムに関する。
プログラムが検証したい性質(プロパティ property)を満たすか否かをモデル検査法(model checking)により静的に調べて、不具合を検出する方法があり、ソフトウェアモデル検査(software model checking)またはモダンモデル検査(modern model checking)と呼ばれている。
なお、対象プログラムを静的に検証するとは、コンピュータに対象プログラムを実行させずに、不具合の有無を確認することを意味する。例えば、静的解析ツールによって、対象プログラムのソースコードや実行可能なバイナリコードを用いて検証する。
また、対象プログラムを動的に検証するとは、コンピュータに対象プログラムを実行させて、不具合の有無を確認することを意味する。プログラミング言語によっては、対象プログラムのソースコードを実行可能なバイナリコードに変換することや、ソースコードをそのままインタープリタによって実行することもある。
モデル検査法とは、システムやソフトウェアの振舞いを表した、有限個の状態(state)および状態間の遷移(transition)から成る有限状態空間(finite state space)において、空間内を網羅探索することにより、検証したい性質が成立するか否かを調べる手法である。とくに、探索の深さを限定した有界モデル検査法(bounded model checking)は、不具合の検出に有効であるとされている。有界モデル検査法を用いたソフトウェアモデル検査においては、検証対象プログラムに出現する全ての変数に関して、変数値の組合せの一つ一つが状態である。
非特許文献1には、有界モデル検査法をプログラムの検証へ適用した一例が記載されている。非特許文献1に記載された例では、プログラムに表れる各変数の値の遷移を制約式Cとして表現し、検証したい性質を論理式Pとして表現し、C∧¬P(∧は論理和、¬は否定)を満たす変数値の推移を網羅探索により検出することを試みる。
この変数値の推移は反例(counter-example)と呼ばれており、反例が検出された場合、反例として示された変数の値の推移を行うようなパスを辿ると、検証したい性質を満たさないような不具合が発生するといえる。尚、非特許文献1では、プログラムをモデル検査用の制約式に変換する際に、ループをN回までの固定回数の繰り返しで打ち切るといった近似を行うことが説明されている。
非特許文献2には、検証したい性質を表現する一つの考え方に「契約による設計」(Design by Contract(登録商標))が記載されている。この考え方では、検証対象プログラムに、検証対象プログラムの開始状態で満たされるべき事前条件と検証対象プログラムの終了状態が満たすべき事後条件と、検証対象プログラムの実行によっても変わらないデータの不変条件と、を表明(Assertion)として記述する。そして、表明に照らしてプログラムが正しく実装されているか否かを、プログラムを実行して動的に検証する、またはプログラムを実行せずに静的に検証する。
表明に照らしてのプログラムの検証をモデル検査により静的に行って、不具合を検出する方法の一例が特許文献1に記載されている。
なお、本発明に関連する研究として、検証対象プログラムによって変更される出力変数を含まないガード条件(Guard condition)と出力変数を含む定義条件(Defining condition)との論理積を項とする選言標準形(DNF. Disjunctive normal form)で、事後条件を表現する考え方が非特許文献3に記載されている。
また、線形演算などを含む論理式について、論理式を真とするような数値を算出する技術SMT(Satisfiable Modulo Theories)ソルバの一例が非特許文献4に記載されており、例えば、0≦x∧x<y(∧は論理積)を満たす値の組として(x,y)=(0,1)などを算出できる。
また、プログラムの構造カバレッジに関しては、命令カバレッジ(Statement coverage)、判定カバレッジ(Decision coverage)、または、MC/DCカバレッジ(Modified decision condition coverage)がプログラムを実行してのテストでよく使われている。命令カバレッジは、各文(Statement)を一度は実行したことを示す。判定カバレッジは、各ループや分岐の判定(Decision)が真となる場合と偽となる場合とを一度は実行したことを示す。MC/DCカバレッジは、各ループや分岐の判定を構成する条件(Condition)が、他の条件の値を固定した場合に、ある条件の真偽によって判定の真偽が決まるような条件の組合せを一度は実行したことを示す。
特開2009−211503号公報
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)を行うと、不具合を見落とし得るという問題がある。
特許文献1に記載された例においても、判定不能、過大近似による見掛けの不具合、過小近似による不具合の見落としが起こり得る。
判定不能について具体的に説明する。変数が32ビットの符号付き整数型であるとすると、変数の定義域は、−2の31乗から2の31乗−1までの約42億通りである。また、変数x、y、・・・に対して変数値の組合せは、42億×42億×・・・通りであり、変数の個数に対して指数関数的に増える。そのため、ソフトウェアモデル検査ツールの利用者が許容できる時間内で、またはソフトウェアモデル検査ツールに与えられた資源の範囲で、変数値の推移を網羅探索することが困難になる。
次に、過大近似について具体的に説明する。ソフトウェアモデル検査においては、検証対象プログラムに出現する全ての変数に関して、各変数の値の組合せの一つ一つが状態である。プログラムで多用される配列とは、配列要素という変数が複数集まったものであるから、配列のサイズが大きくなれば変数の個数も増える。すなわち、配列のサイズが大きくなれば状態数も増えることになり、上記の判定不能を引き起こしやすい。そこで、判定不能を避けるために、配列の特定の要素のみを変数として扱い、他の要素は変数として扱わないような近似を行うことが考えられる。
例えば、配列a[10]では、状態数は、近似を行わないと約42億の10乗となるが、最初の2個(a[0]とa[1])の要素だけを変数とする近似を行えば約42億の2乗となる。ここで、変数として扱わない配列要素について、値の設定を無視し、値の取得時には任意値を返すと解釈すると、プログラムの振る舞いが増えるので、過大近似が導入されている。
例えば、配列aの3番目の要素a[2]について、プログラム上において、a[2]=10;といった値の設定を行う文を無視し、後続にif(a[2]==10){A}else{B}といった値の取得を行う分岐がある場合を想定する。この場合、本来は分岐の判定が真に対応するブロックAしか実行され得ないにも関わらず、a[2]から任意値が取得されるという近似により、分岐の判定が偽に対応するブロックBも実行され得ると解釈することになり、プログラムの振る舞いが増える。この状況でブロックBにおける不具合を検出した場合、その不具合は本当にプログラムを実行した場合には起こらないので、見掛けの不具合である。
次に、過小近似について具体的に説明する。判定不能や見掛けの不具合を避けるために、変数から任意値ではなく特定の値が取得されると解釈すると、プログラムの振る舞いが減るので、過小近似が導入されている。例えば、大域変数gについて、本来は任意の値の可能性がある場合にも、特定の値である0のみであると解釈する場合を想定する。この場合、if(g==0){A}else{B}といった値の取得を行う分岐では、本来は分岐の判定が真に対応するブロックAも偽に対応するブロックBも実行し得るにも関わらず、gを0とする近似により、分岐の判定が真に対応するブロックAしか実行され得ないと解釈することになり、プログラムの振る舞いが減る。この状況ではソフトウェアモデル検査においてブロックBを探索していないので、もし不具合がブロックBにあるならば不具合の見落としが起こる。
ソフトウェアモデル検査を用いたプログラム検証では、判定不能と過大近似と過小近似とに関してソフトウェアモデル検査以外の方法で表明に照らしてプログラムを検査する必要がある。このため、判定不能以外の結果に関して、過大近似および過小近似の導入を検知できる必要がある。
そこで、本発明は、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができるプログラム検証装置、プログラム検証装置、プログラム検証方法及びプログラム検証用プログラムを提供することを目的とする。
本発明によるプログラム検証装置は、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証手段と、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形手段と、ソフトウェアモデル検証手段の検証結果が反例ありを示している場合には、反例ごとに中間プログラムに対する過大近似の導入を検出する過大近似検出手段と、ソフトウェアモデル検証手段の検証結果が判定不能以外の結果を示している場合には、中間プログラムに対する過小近似の導入を検出する過小近似検出手段とを備えたことを特徴とする。
本発明によるプログラム検証方法は、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証ステップと、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形ステップと、中間プログラムについてソフトウェアモデル検証ステップで検出した不具合について過大近似の導入を検出する過大近似検出ステップと、中間プログラムについて過小近似の導入を検出する過小近似検出ステップとを含むことを特徴とする。
本発明によるプログラム検証用プログラムは、コンピュータに、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証処理と、検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形処理と、中間プログラムについてソフトウェアモデル検証処理で検出した不具合について過大近似の導入を検出する過大近似検出処理と、中間プログラムについて過小近似の導入を検出する過小近似検出処理とを実行させることを特徴とする。
本発明によれば、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができる。
本発明によるプログラム検証方法を適用した情報処理装置の全体構成の一例を示すブロック図である。 プログラム検証方法を適用した情報処理装置の全体的な処理の流れの一例を示すフロー図である。 プログラムの整形ルールの具体例を示す説明図である。 プログラムの整形の具体例を示す説明図である。 過大近似の検知方法の具体例を示す説明図である。 過小近似の検知方法の具体例を示す図説明である。 テストケース生成&実行ステップの処理の流れの具体例を示すフロー図である。 機能シナリオの抽出の具体例を示す説明図である。 テスト入力の生成とテストプログラムの生成の具体例を示す説明図である。 検証対象プログラムへのカバレッジ測定用コードの挿入方法の具体例を示す説明図である。 プログラム検証装置の最小の構成例を示すブロック図である。
以下、本発明の実施形態について図面を参照して説明する。
<装置構成>
図1は、本発明によるプログラム検証方法を適用した情報処理装置100の概略構成を示す図である。情報処理装置100は、情報処理部180とファイル格納部190とを含む。情報処理装置100は、具体的にはパーソナルコンピュータ等によって実現される。情報処理部180は、具体的には、プログラムに従って動作する情報処理装置のCPUによって実現される。ファイル格納部190は、具体的には、光ディスク装置や磁気ディスク装置、メモリ等の記憶装置によって実現される。
情報処理部180は、制御モジュール110と、ソフトウェアモデル検査モジュール120と、プログラム整形モジュール130と、過大近似検知モジュール140と、過小近似検知モジュール150と、テストケース生成モジュール160と、テスト実行モジュール170とを含む。
情報処理部180が含むこれらのモジュールのうち、制御モジュール110は、利用者による検証対象プログラムの指定操作に従って、他のモジュールに図2で示す一連の処理を実行させる機能を備えている。各モジュールは、具体的には、情報処理装置が備えるプログラムによって実現される。また、情報処理装置は、各モジュールに従って処理を実行する。
ここで、本実施形態において、検証対象プログラムは、C言語で記述されており、かつ、検証の対象である関数(検証対象関数)と、その関数に付与された事前条件および事後条件といった表明を含むものとする。また、事後条件は、選言標準形で記述されているものとする。なお、本実施形態では、C言語で記述されたプログラムを検証対象とするが、検証対象のプログラムはC言語以外のプログラム言語(例えば、Java(登録商標)など)で記述されていてもよい。
ソフトウェアモデル検査モジュール120は、検証対象プログラムを検証する機能を備えている。具体的には、ソフトウェアモデル検査モジュール120は、ファイル格納部190から検証対象プログラムを含むファイルを読み込み、検証対象プログラムに付記された表明に照らして検証対象関数を検証し、不具合を検出すれば反例を出力する。
プログラム整形モジュール130は、検証対象プログラムを整形して中間プログラムを生成する機能を備えている。具体的には、プログラム整形モジュール130は、検証対象プログラムをC言語のサブセットの表現に変換し、構造カバレッジの観点で検査すべき箇所を独立した分岐ブロックに分解し、表明も含めて中間プログラムとして出力する。
過大近似検知モジュール140は、中間プログラムから過大近似を検知する機能を備えている。具体的には、過大近似検知モジュール140は、反例ごとに、中間プログラムに過大近似を検知するためのコードと過大近似が導入されなかったことを示す表明とを挿入する。そして、過大近似検知モジュール140は、上記の中間プログラムについてソフトウェアモデル検査モジュール120を用いてソフトウェアモデル検査を行い、表明違反が検出されれば過大近似が導入されたと判断する。
過小近似検知モジュール150は、中間プログラムから過小近似を検知する機能を備えている。具体的には、過小近似検知モジュール150は、中間プログラムに過小近似を検知するためのコードと過小近似が導入されたことを示す表明とを挿入する。そして、過小近似検知モジュール150は、ソフトウェアモデル検査モジュール120を用いてソフトウェアモデル検査を行い、表明違反が検出されなければ過小近似が導入されたと判断する。
テストケース生成モジュール160は、テストプログラムとカバレッジ測定用検証対象プログラムを生成する機能を備えている。具体的には、テストケース生成モジュール160は、検証対象関数に付記された事前条件と事後条件の一部とをテスト入力として、事後条件の残りを期待結果とするようなテストプログラムを生成して出力する。また、テストケース生成モジュール160は、中間プログラムにカバレッジを測定するためのコードを挿入したカバレッジ測定用検証対象プログラムを生成して出力する。
テスト実行モジュール170は、テストプログラムとカバレッジ測定用検証対象プログラムとを実行する機能を備えている。
本実施形態では、ソフトウェアモデル検査モジュール120は、特許文献1に記載された技術を用いて実現される。また、テストケース生成モジュール160は、非特許文献3の事後条件を選言標準形で表現する考え方を採用し、非特許文献4のSMTソルバの技術を利用することによって実現される。
<全体の処理の流れ>
次に、図1及び図2のフローチャートを参照して本実施形態の全体の動作について説明する。図2は、プログラム検証方法を適用した情報処理装置の全体的な処理の流れの一例を示すフロー図である。
制御モジュール110は、利用者による検証対象プログラムの指定操作に従って、他のモジュールに図2に示す一連の処理を実行させる。
プログラムの検証を行うために、利用者は、情報処理装置で検査対象のプログラムを指定する操作を行う。すると、ソフトウェアモデル検査モジュール120は、利用者の操作に従って、ファイル格納部190から検証対象プログラムを読み込み、検証対象プログラムにおける変数の値の推移を表す制約式Cを求める。
次いで、ソフトウェアモデル検査モジュール120は、求めた制約式Cと検証対象プログラムに付記された表明である事前条件Preと事後条件Postとから、論理式Pre∧C∧¬Postの式を作成する。
次いで、ソフトウェアモデル検査モジュール120は、網羅探索により、作成した論理式を満たす変数の値の組合せを計算する。そして、(1)与えたプログラムが大きすぎるか複雑すぎるなどにより網羅探索できなかった場合には、ソフトウェアモデル検査モジュール120は、「判定不能」を検証結果として出力する。
また、(2)論理式を満たす変数値の組合せが算出できた場合には、ソフトウェアモデル検査モジュール120は、「反例あり」を検証結果として出力する。また、(3)判定不能ではなく、かつ変数値の組合せが算出できなかった場合には、ソフトウェアモデル検査モジュール120は、「反例なし」を検証結果として出力する(ステップS201)。
次いで、制御モジュール110は、ソフトウェアモデル検査モジュール120が出力した検証結果が「判定不能」であるか否かを判断する(ステップS202)。
ステップS202において、ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合には、制御モジュール110は、テスト実行のための一連の処理(ステップS203〜S204)を行うように制御する。
一方、ステップS202においてソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合には、制御モジュール110は、検証結果が「反例あり」であるか否かを判断する(ステップS211)。そして、ソフトウェアモデル検査の検証結果が「反例あり」であると判断した場合には、制御モジュール110は、反例毎に過大近似の検知とテストとを実行するための一連の処理(ステップS212〜S215)を行うように制御する。
また、ステップS202においてソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合には、制御モジュール110は、ステップS211〜S216とは並列的に、過小近似の検知とテストとを実行するための一連の処理(ステップS221〜S224)も行うように制御する。
なお、本実施形態において、制御モジュール110は、過大近似および過小近似に関する一連の処理については、並列または順不同に行ってよい。具体的には、制御モジュール110は、「判定不能」でないと判断した後の、ステップS211からS216までの処理と、ステップS211からS224までの処理とを、並列または順不同に行うように制御してもよい。図2に示す処理例では、ステップS205が並列に行える処理の流れの始まりを、ステップS206が並列に行える処理の流れの終わりを示す。
次に、過大近似の検知とテストとを実行するための一連の処理(ステップS212〜S215)の流れについて説明する。
ソフトウェアモデル検査の検証結果が「反例あり」であると判断した場合(ステップS211)、プログラム整形モジュール130は、検証対象プログラムを過大近似検知モジュール140(及び過小近似検知モジュール150)が適用可能なC言語のサブセットの表現に変換する。そして、プログラム整形モジュール130は、変換した検証対象プログラムに表明を含めて中間プログラムとして、過大近似検知モジュール140に出力する(ステップS212)。
次いで、過大近似検知モジュール140は、プログラム整形モジュールが出力した中間プログラムから過大近似の検知を行い(ステップS213)、過大近似が導入されたか否かを反例ごとに判断する(ステップS214)。
具体的には、過大近似検知モジュール140は、反例ごとに、中間プログラムに過大近似を検知するためのコードと過大近似が導入されなかったことを示す表明とを挿入する。そして、過大近似検知モジュール140は、ソフトウェアモデル検査モジュール120を用いてソフトウェアモデル検査を行い、表明違反が検出されれば過大近似が導入されたと判断し、反例から算出した入力条件を事前条件に追加した中間プログラムを出力する。
ステップS214において過大近似が導入されなかったと判断した場合には、制御モジュール110は、ステップS216に処理を移行し、未処理の反例があるか否かを判断する(ステップS216)。すなわち、制御モジュール110は、過大近似検知モジュール140が過大近似の検知処理を行っていない反例が中間プログラムに存在するか否かを判断する。そして、未処理の反例があると判断した場合には、制御モジュール110は、処理をステップS213に移行し、未処理の反例がなくなるまで、その後の処理を繰り返し実行するように制御する。
一方、ステップS214において過大近似が導入されたと判断した場合には、テストケース生成モジュール160は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール160は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。
次いで、テスト実行モジュール170は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う(ステップS215)。その後、制御モジュール110は、処理をステップS216に移行する。そして、制御モジュール110は、過小近似の検知とテストとを実行するための一連の処理(ステップS221〜S224)が完了していれば、処理を終了する。
次に、過小近似の検知とテストとを実行するための一連の処理(ステップS221〜S224)の流れについて説明する。
ソフトウェアモデル検査の検証結果が「判定不能」でないと判断した場合(ステップS202)、プログラム整形モジュール130は、検証対象プログラムを過小近似検知モジュール150(及び過大近似検知モジュール140)が適用可能なC言語のサブセットの表現に変換する。そして、プログラム整形モジュール130は、変換した検証対象プログラムに表明を含めて中間プログラムとして過小近似検知モジュール150に出力する(ステップS221)。
次いで、過小近似検知モジュール150は、プログラム整形モジュールが出力した中間プログラムから過小近似の検知を行い(ステップS222)、過小近似が導入されたか否かを判断する(ステップS223)。
具体的には、過小近似検知モジュール150は、中間プログラムに過小近似を検知するためのコードと過小近似が導入されたことを示す表明とを挿入する。そして、過小近似検知モジュール150は、ソフトウェアモデル検査モジュール120を用いてソフトウェアモデル検査を行い、表明違反が検出されなければ過小近似が導入されたと判断する。
過小近似が導入されたと判断した場合には(ステップS223)、テストケース生成モジュール160は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール160は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。そして、テスト実行モジュール170は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う(ステップS224)。その後、制御モジュール110は、処理をステップS206に移行する。
一方、過小近似が導入されていないと判断した場合には(ステップS223)、制御モジュール110は、処理をステップS206に移行する。そして、制御モジュール110は、過大近似の検知とテストとを実行するための一連の処理(ステップS212〜S215)が完了していれば、処理を終了する。
次に、ステップS202において、ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合に実行する一連の処理(ステップS203〜S204)の流れについて説明する。
ソフトウェアモデル検査の検証結果が「判定不能」であると判断した場合(ステップS202)、プログラム整形モジュール130は、検証対象のプログラムを整形する(ステップS203)。
具体的には、プログラム整形モジュール130は、検証対象プログラムを過大近似検知モジュール140および過小近似検知モジュール150が適用可能なものと同じC言語のサブセットの表現に置換する。そして、プログラム整形モジュール130は、それらに表明を含めて中間プログラムとしてテスト生成モジュール160に出力する。
次いで、テストケース生成モジュール160は、中間プログラムの事前条件・事後条件を用いてテストプログラムを生成する。また、テストケース生成モジュール160は、中間プログラムを用いてカバレッジ測定用検証対象プログラムを生成する。
次いで、テスト実行モジュール170は、テストプログラムおよびカバレッジ測定用検証対象プログラムの実行と、カバレッジの測定とを行う(ステップS204)。その後、制御モジュール110は、処理を終了する。
<<プログラムの整形>>
次に、プログラムの整形ステップ(ステップS212、ステップS221)の具体例について、図3および図4を用いて説明する。図3は、プログラムの整形ルールの具体例を示す説明図である。図4は、プログラムの整形の具体例を示す説明図である。
図3の整形ルール31では、=の左辺が変換前の表現であり、右辺が変換後の表現である。本実施形態では、プログラム整形モジュール130は、変換前の表現が1から10までのいずれかのルールの左辺に合致すれば、整形ルール31を用いて、右辺の表現に変換する。そして、変換後の表現が1から10までのいずれかのルールの左辺に合致すれば、プログラム整形モジュール130は、再び右辺の表現に変換するという処理を、合致するルールが出現しなくなるまで繰り返し行う。
具体的には、プログラム整形モジュール130は、図4(a)の検証対象プログラム41について、関数全体(検証対象プログラム41の3行目から11行目)に対して整形ルール31のルール1を適用する。このことにより、整形された中間プログラム42には4a行目が追加される(図4(b)参照)。
さらに、プログラム整形モジュール130は、条件文(検証対象プログラム41の5行目)に対して整形ルール31のルール6を適用する。このことにより、整形された中間プログラム42には5aから5f行目が追加され、元の5行目の判定「mode==0」が「__d」に置換される。
<<過大近似の検知>>
次に、過大近似の検知ステップ(ステップS213)の具体例について、図5を用いて説明する(プログラムの整形は省略して説明する)。図5は、過大近似の検知方法の具体例を示す説明図である。
過大近似の具体例はソフトウェア検査モデル技術によって異なる。ここでは「配列の2番目以降の要素からは任意値が取得される」という近似の例を扱う(図5(a)の過大近似の検知方法の例51の1行目)。また、検知の方法としては、過大近似の検知方法の例51の2行目に示したo1からo4までの手順により、元の検証対象プログラム52(図5(b)参照)を過大近似検知用プログラム53(図5(c)参照)に変換する。
図5の過大近似検知用プログラム53の左列は、過大近似の検知方法の例51の2行目の手順o1からo4が関係することを示す。また、過大近似検知用プログラム53の中列は、元の検証対象プログラムの行番号(図5の検証対象プログラム52の左列)を示す。
過大近似検知モジュール140は、過大近似の検知方法の例51のo1に従い、検証対象プログラム52の1行目の配列a[10]に対して同サイズのトラップ配列trap_a[10]とトラップ変数TrapOとを挿入する(過大近似検知用プログラム53のo1行目)。トラップ変数TrapOは、真(1)のときのみ過大近似が導入されたことを示す変数である。
次いで、過大近似検知モジュール140は、過大近似の検知方法の例51のo2に従い、検証対象プログラム52の4行目の変数宣言の後で、トラップ変数TrapOに偽(0)を、トラップ要素trap_a[i](i=0..9)に固定値(0)を設定する(過大近似検知用プログラム53のo2行目)。
次いで、過大近似検知モジュール140は、過大近似の検知方法の例51のo3に従い、配列要素の取得(検証対象プログラム52の6行目および8行目)の前で、トラップ要素が固定値でなければトラップ変数に真(1)を設定する(過大近似検知用プログラム53のo3行目)。
次いで、過大近似検知モジュール140は、過大近似の検知方法の例51のo4に従い、return文(検証対象プログラム52の11行目)の前に、トラップ変数TrapOが偽(0)であることを示す表明(__assert(!TrapO))を挿入する(過大近似検知用プログラム53のo4行目)。
次いで、過大近似検知モジュール140は、過大近似の検知方法の例51のo5に従い、ソフトウェアモデル検査モジュール120を用いて過大近似検知用プログラムの実行文(過大近似検知用プログラム53の4行目から10行目)が表明(過大近似検知用プログラム53のo4行目)に違反しないかを調べる。このとき、反例が得られたということは、トラップ変数TrapOが真(1であった、すなわち過大近似が起きたことを示す。
<<過小近似の検知>>
次に、過小近似の検知ステップ(ステップS222)の具体例について、図4と図6を用いて説明する。図6は、過小近似の検知方法の具体例を示す図説明である。
過小近似の具体例はソフトウェア検査モデル技術によって異なる。ここでは「大域変数の値が初期値のままと見なす」という近似の例(図6(a)の過小近似の検知方法の例61の1行目)を扱う。また、検知の方法としては、過小近似の検知方法の例61の2行目に示したu1からu4までの手順により、元の検証対象プログラム41から整形された中間プログラム42を過小近似検知用プログラム62および63(図6(b)(c)参照)に変換する。
過小近似検知用プログラム62および63の左列は、過小近似の検知方法の例61の2行目の手順u1からu3が関係することを示す。また、過小近似検知用プログラム62および63の中列は、整形された中間プログラムの行番号(整形された中間プログラム42の左列)を示す。
過小近似検知モジュール150は、過小近似の検知方法の例61のu1に従い、トラップ変数TrapUを挿入し、真(1)を設定する(過小近似検知用プログラム62のu1行目)。なお、トラップ変数TrapUは、真(1)のときのみ過小近似が導入されたことを示す変数である。
次いで、過小近似検知モジュール150は、過小近似の検知方法の例61のu2における「検査すべき箇所」として、ここでは整形された中間プログラム上で、分岐の判定式が「__d」以外であり、分岐先の実行文が「__d=1;」または「;」だけであるブロックを選ぶ。なお、プログラムの整形ルール31は、このブロックがMC/DCカバレッジを満たすための判定を構成する条件の組合せに相当するようになっている。
次いで、過小近似検知モジュール150は、1つ目の検査すべき箇所(整形された中間プログラム42の5c行目)について、過小近似の検知方法の例61のu3に従い、トラップ変数に偽(0)を設定する(過小近似検知用プログラム62のu3行目)。
次いで、過小近似検知モジュール150は、過小近似の検知方法の例61のu4に従い、return文(整形された中間プログラム42の10行目)の前に、トラップ変数TrapUが真(1)であることを示す表明(__assert(TrapU))を挿入する(過小近似検知用プログラム62のu4行目)。
次いで、過小近似検知モジュール150は、過小近似の検知方法の例61のu5に従い、ソフトウェアモデル検査モジュール120を用いて過小近似検知用プログラムの実行文(過小近似検知用プログラム62の4行目から9行目)が表明(過小近似検知用プログラム62のu4行目)に違反しないかを調べる。このとき、反例が得られないということは、トラップ変数TrapUが真(1)であった、すなわち過小近似が導入されて62のu3行目が実行されなかったことを示す。
また、過小近似検知モジュール150は、2つ目の検査すべき箇所(整形された中間プログラム42の53行目)についても、過小近似の検知方法の例61のu3に従い、トラップ変数に偽(0)を設定し(過小近似検知用プログラム63のu3行目)、1つ目の検査すべき箇所と同様に過小近似の検知方法の例61のu4およびu5の手順を行う。なお、全ての検査すべき箇所のうち、1箇所でも過小近似の導入が検知されれば、プログラム全体についてテストを行う必要がある。
<<テストケース生成&実行>>
次に、テストケース生成&実行ステップ(ステップS204、ステップS215およびステップS224)の具体例について、図7と図8と図9と図10とを用いて説明する。図7は、テストケース生成&実行ステップの処理の流れの具体例を示すフロー図である。図8は、機能シナリオの抽出の具体例を示す説明図である。図9は、テスト入力の生成とテストプログラムの生成の具体例を示す説明図である。図10は、検証対象プログラムへのカバレッジ測定用コードの挿入方法の具体例を示す説明図である。
テストケース生成モジュール160は、プログラム整形モジュール130または過大近似検知モジュール140が出力した中間プログラムを読み込み、中間プログラムの事前条件および事後条件から機能シナリオ(図8(a)の機能シナリオの抽出81の6行目)を抽出する(ステップS701)。
具体的には、テストケース生成モジュール160は、図8の例では検証対象関数の表明82(図8(b))から、図8(c)に示す機能シナリオ1(83)と図8(d)に示す機能シナリオ2(84)とを抽出する。
次いで、テストケース生成モジュール160は、固定回数だけ以降の一連の処理(ステップS703〜S708)を繰り返す(ステップS702)。
テストケース生成モジュール160は、機能シナリオ毎に(ステップS703)、機能シナリオのうち、事前条件Preと事後条件のガード条件Cとの論理積(機能シナリオ1(83)の1行目、機能シナリオ2(84)の1行目)をSMTソルバが適用可能な形式に変換する。そして、テストケース生成モジュール160は、SMTソルバを用いてPre∧Cが真となる変数値の組合せを生成する(ステップS704)。テストケース生成モジュール160は、SMTソルバが適用可能な形式として、例えば、図9(a)のテスト入力生成用論理式(SMT−LIB形式)91に変換する。
ここで、SMTソルバを用いて生成した組合せ(図9(b)のSMTソルバで生成したテスト入力92)は、引数xが0(SMTソルバで生成したテスト入力92の4行目)、引数yが1(SMTソルバで生成したテスト入力92の5行目)、大域変数modeが0(SMTソルバで生成したテスト入力92の6行目)となっている。また、SMTソルバを用いて生成した組合せ(SMTソルバで生成したテスト入力92)は、機能シナリオ1(83)事前条件Preと事後条件のガード条件C1との論理積(機能シナリオ1(83)の1行目)を満たすテスト入力となっている。
次いで、テストケース生成モジュール160は、SMTソルバで生成したテスト入力92と機能シナリオ1(83)から、テストプログラムの形式93(図9(c)参照)に合致するような、テストプログラム94(図9(d)参照)を生成する(ステップS705)。
テストプログラム94に従って処理を実行するテスト実行モジュール170は、テスト入力(SMTソルバで生成したテスト入力92の4行目から6行目)に対応して変数にテスト入力値を設定(テストプログラム94のc1行目からc3行目)する。そして、テスト実行モジュール170は、検証対象関数を呼び出し(テストプログラム94のd行目)、機能シナリオの定義条件(機能シナリオ1(83)の2行目)を期待結果と見なして、検証対象関数の結果を期待結果に照らしてテストの合否を出力する(テストプログラム94のe1行目からe4行目)。
また、テストケース生成モジュール160は、図10(a)のカバレッジ測定用コードの挿入方法1001に従って中間プログラムにカバレッジ測定用コードを挿入し、図10(b)に示すようなカバレッジ測定用検証対象プログラム1002を生成して出力する。
テストケース生成モジュール160が全ての機能シナリオについてテストプログラムの生成を終えると(ステップS703)、テスト実行モジュール170は、ステップS705において生成したテストプログラム94とカバレッジ測定用検証プログラム1002とを実行する(ステップS706、S707)。
ステップS706においてテストプログラム毎のループ(すなわち、生成した全てのプログラムの実行)が終了すると、テストケース生成モジュール160は、実行結果(カバレッジ測定用検証プログラム1002の例ではc2行目のログの出力)を調べて、カバレッジが十分か否かを判断する(ステップS708)。そして、全ての検査したい箇所が少なくとも一度実行されていればカバレッジが十分と判断し、十分であると判断した場合には、制御モジュール110は、テストケース生成&実行ステップ(ステップS204、S215、S224)の一連の処理を終える。
一方、十分でないと判断した場合には、制御モジュール110は、処理をステップS702(固定回数のループ制御)に移行する(ステップS708)。そして、ステップS703からS708までの一連の処理を固定回数だけ繰り返したのちに、制御モジュール110は、テストケース生成&実行ステップ(ステップS204、S215、S224)の一連の処理を終える(ステップS702)。
なお、ステップS703からS708までの一連の処理の繰り返しにおけるテスト入力の生成(ステップS704)においては、以前に生成した入力を除外するために、以前に生成した入力を否定する制約と以前の事前条件との論理積を新たな事前条件としてテスト入力を生成する。
例えば、以前に生成したテスト入力(SMTソルバで生成したテスト入力92)について、これを否定する制約は(!(x==0&&y==1&&mode==0))(!は否定、&&は論理積、==は等号)である。この制約と以前の事前条件(検証対象関数の表明82の事前条件Pre)との論理積(mode==0||mode==1)&&(0<=x&&x<y)&&(!(x==0&&y==1&&mode==0))を新たな事前条件とすることにより、テストケース生成モジュール160は、次のテスト入力では以前とは異なるテスト入力を得ることができる。
以上のように、本実施形態では、C言語で記述された対象プログラムのソースコードを、実行可能なバイナリコードではなく、静的解析ツール(ソフトウェアモデル検査手段)が処理しやすい形式のソースコードに変換する。
また、本実施形態では、検証対象プログラムに付記された表明に照らしてのプログラムの検証において、まずモデル検査法を用いて、検証対象プログラムを実行せずに静的に検証を行う。そして、過大近似の導入により検証結果に見掛けの不具合が含まれ得る場合と、過小近似の導入により検証結果に不具合の見落としがあり得る場合と、プログラムのサイズが大き過ぎたり制御が複雑過ぎたりすることにより検証結果が判定不能であった場合とに、表明に基づいてテストプログラムを生成することで、検証対象プログラムを実行して動的に検査を行うことができる。
以上のことから、本発明は、事前条件や事後条件といった表明に照らしてプログラムを静的に検証するための技術、および動的にテストするための技術に関する。そして、本発明によれば、ソフトウェアモデル検査の判定不能以外の結果に関して過大近似と過小近似の導入を検知することができ、判定不能と過大近似と過小近似に関して検証対象プログラムに記述された表明を元にテストケースを生成し、プログラム実行を伴うテストによって、表明に照らして検証対象プログラムを検証することができる。
次に、本発明によるプログラム検証装置の最小構成について説明する。図11は、プログラム検証装置の最小の構成例を示すブロック図である。図1に示すように、プログラム検証装置は、最小の構成要素として、ソフトウェアモデル検証手段10と、プログラム整形手段20と、過大近似検出手段30と、過小近似検出手段40とを含む。
図11に示す最小構成のプログラム検証装置では、ソフトウェアモデル検証手段10は、検証対象プログラムに付記された表明に基づいて検証対象プログラムを静的に検証する。そして、ソフトウェアモデル検証手段10の検証結果が反例ありを示している場合には、過大近似検出手段30は、反例ごとに、プログラム整形手段20が検証対象プログラムをプログラムの構造上のカバレッジ基準に合せて変換した中間プログラムに対する過大近似の導入を検出する。また、ソフトウェアモデル検査手段10の検証結果が判定不能以外を示している場合には、過小近似検出手段40は、中間プログラムに対する過小近似の導入を検出する。
従って、最小構成のプログラム検証装置によれば、ソフトウェアモデル検査を用いたプログラム検証において、判定不能と判断した場合や過大近似、過小近似である場合にも、表明に照らしてプログラムを検証することができる。
なお、本実施形態では、以下の(1)〜(5)に示すようなプログラム検証装置の特徴的構成が示されている。
(1)プログラム検証装置は、検証対象プログラム(例えば、検証対象プログラム41)に付記された表明に基づいて検証対象プログラムを静的に検証するソフトウェアモデル検証手段(例えば、ソフトウェアモデル検証モジュール120によって実現される)と、検証対象プログラムをプログラムの構造上のカバレッジ基準に合せて変換し中間プログラム(例えば、整形された中間プログラム42)として出力するプログラム整形手段(例えば、プログラム整形モジュール130によって実現される)と、ソフトウェアモデル検証手段の検証結果が反例ありの場合には、反例ごとに中間プログラムへの過大近似の導入を検出する過大近似検出手段(例えば、過大近似検知モジュール140によって実現される)と、ソフトウェアモデル検証手段の検証結果が判定不能以外の場合には、中間プログラムへの過小近似の導入を検出する過小近似検出手段(例えば、過小近似検知モジュール150によって実現される)とを備えたことを特徴とする。
(2)プログラム検証装置において、ソフトウェアモデル検証手段の検証結果が判定不能であることを示していた場合と過大近似の導入が検出された場合と過小近似の導入が検出された場合とに、中間プログラムにカバレッジ測定用コードを挿入したカバレッジ測定用検証対象プログラム(例えば、カバレッジ測定用検証対象プログラム1002)と、検証対象プログラムに付記された表明に基づいて生成されたテスト入力データ(例えば、SMTソルバで生成したテスト入力92)を用いて、カバレッジ測定用検証対象プログラムを呼び出して、カバレッジ測定用検証対象プログラムを実行した結果を検証対象プログラムに付記された表明に基づいて検証するためのテストプログラム(例えば、テストプログラム94)とを生成するテストケース生成手段(例えば、テストケース生成モジュール160によって実現される)と、テストプログラムとカバレッジ測定用検証対象プログラムとを実行するテスト実行手段(例えば、テスト実行モジュール170)とを備えるように構成されていてもよい。
(3)プログラム検証装置において、テストケース生成手段は、テスト入力データを繰り返し生成する際には、検証対象プログラムに付記された表明の事前条件と以前のテスト入力データを否定する制約との論理積を新たな事前条件として用いることにより、以前のテスト入力データとは異なるテスト入力を生成するように構成されていてもよい。
(4)プログラム検証装置において、プログラム整形手段は、MC/DCカバレッジをプログラムの構造上のカバレッジ基準として用いるように構成されていてもよい。
(5)プログラム検証装置において、過大近似検出手段は、中間プログラムに過大近似を検出するためのコードと過大近似が導入されなかったことを示す表明とを挿入して(例えば、過大近似検知用プログラム53を生成して)検証を行い、表明違反が検出されれば過大近似が導入されたと判断するように構成されていてもよい。
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
(付記1)検証対象プログラムに付記された表明に基づいて、前記検証対象プログラムを静的に検証するソフトウェアモデル検証手段と、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形手段と、前記ソフトウェアモデル検証手段の検証結果が反例ありを示している場合には、前記反例ごとに前記中間プログラムに対する過大近似の導入を検出する過大近似検出手段と、前記ソフトウェアモデル検証手段の検証結果が判定不能以外の結果を示している場合には、前記中間プログラムに対する過小近似の導入を検出する過小近似検出手段とを備えたことを特徴とするプログラム検証装置。
(付記2)ソフトウェアモデル検証手段の検証結果が判定不能であることを示していた場合と過大近似の導入が検出された場合と過小近似の導入が検出された場合とに、中間プログラムにカバレッジ測定用コードを挿入したカバレッジ測定用検証対象プログラムと、前記検証対象プログラムに付記された表明に基づいて生成されたテスト入力データを用いて、前記カバレッジ測定用検証対象プログラムを呼び出して、該カバレッジ測定用検証対象プログラムを実行した結果を前記検証対象プログラムに付記された表明に基づいて検証するためのテストプログラムとを生成するテストケース生成手段と、前記テストプログラムと前記カバレッジ測定用検証対象プログラムとを実行するテスト実行手段とを備える付記1記載のプログラム検証装置。
(付記3)テストケース生成手段は、テスト入力データを繰り返し生成する際には、検証対象プログラムに付記された表明の事前条件と以前のテスト入力データを否定する制約との論理積を新たな事前条件として用いることにより、以前のテスト入力データとは異なるテスト入力データを生成する付記2記載のプログラム検証装置。
(付記4)プログラム整形手段は、MC/DCカバレッジをプログラムの構造上のカバレッジ基準として用いる付記1から付記3のうちのいずれかに記載のプログラム検証装置。
(付記5)過大近似検出手段は、中間プログラムに過大近似を検出するためのコードと過大近似が導入されなかったことを示す表明とを挿入して検証を行い、表明違反が検出されれば過大近似が導入されたと判断する付記1から付記4のうちのいずれかに記載のプログラム検証装置。
(付記6)検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証ステップと、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形ステップと、前記中間プログラムについて前記ソフトウェアモデル検証ステップで検出した不具合について過大近似の導入を検出する過大近似検出ステップと、前記中間プログラムについて過小近似の導入を検出する過小近似検出ステップとを含むことを特徴とするプログラム検証方法。
(付記7)ソフトウェアモデル検証ステップの検証結果が判定不能であることを示していた場合と過大近似が検出された場合と過小近似が検出された場合とに、検証対象プログラムに付与された事前・事後条件といった表明に基づいてテストプログラムを生成し、かつ中間プログラムにカバレッジ測定用のコードを挿入してカバレッジ測定用の検証対象プログラムを生成し、さらに前記テストプログラムと前記カバレッジ測定用の検証対象プログラムとを実行するテストケース生成&実行ステップを含む付記6記載のプログラム検証方法。
(付記8)コンピュータに、検証対象プログラムに付記された表明に基づいて、検証対象プログラムを静的に検証するソフトウェアモデル検証処理と、前記検証対象プログラムをプログラムの構造上のカバレッジ基準に従って変換し中間プログラムとして出力するプログラム整形処理と、前記中間プログラムについて前記ソフトウェアモデル検証処理で検出した不具合について過大近似の導入を検出する過大近似検出処理と、前記中間プログラムについて過小近似の導入を検出する過小近似検出処理とを実行させるためのプログラム検証用プログラム。
(付記9)コンピュータに、ソフトウェアモデル検証処理の検証結果が判定不能であることを示していた場合と過大近似が検出された場合と過小近似が検出された場合とに、検証対象プログラムに付与された事前・事後条件といった表明に基づいてテストプログラムを生成し、かつ中間プログラムにカバレッジ測定用のコードを挿入してカバレッジ測定用の検証対象プログラムを生成し、さらに前記テストプログラムと前記カバレッジ測定用の検証対象プログラムとを実行するテストケース生成&実行処理を実行させる付記8記載のプログラム検証用プログラム。
本発明は、プログラムを検証する用途に適用可能である。
10 ソフトウェアモデル検証手段
20 プログラム整形手段
30 過大近似検出手段
40 過小近似検出手段

Claims (7)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010099995A JP5464031B2 (ja) 2010-04-23 2010-04-23 プログラム検証装置、方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010099995A JP5464031B2 (ja) 2010-04-23 2010-04-23 プログラム検証装置、方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2011232814A JP2011232814A (ja) 2011-11-17
JP5464031B2 true JP5464031B2 (ja) 2014-04-09

Family

ID=45322091

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010099995A Active JP5464031B2 (ja) 2010-04-23 2010-04-23 プログラム検証装置、方法及びプログラム

Country Status (1)

Country Link
JP (1) JP5464031B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014115759A1 (ja) * 2013-01-23 2014-07-31 日本電気株式会社 ネットワーク検証装置、ネットワーク検証方法及びプログラム
EP3570173B1 (en) 2017-02-22 2021-10-06 Mitsubishi Electric Corporation Equivalence verification apparatus and equivalence verification program
JP7329162B1 (ja) * 2023-05-11 2023-08-17 株式会社インターネットイニシアティブ 情報処理装置および情報処理方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009211503A (ja) * 2008-03-05 2009-09-17 Nec Corp ソースコード検証装置、及びソースコード検証方法

Also Published As

Publication number Publication date
JP2011232814A (ja) 2011-11-17

Similar Documents

Publication Publication Date Title
US10152406B2 (en) Software program repair
CN104899147B (zh) 一种面向安全检查的代码静态分析方法
WO2006038394A1 (ja) ソースコード検査器、方法、プログラム及び記憶媒体
BR102016018127A2 (pt) método para projeto com base em modelo de software de segurança crítica
US20030110474A1 (en) System for coverability analysis
Morgado et al. Automated pattern-based testing of mobile applications
Wille et al. Debugging of inconsistent UML/OCL models
US20120117424A1 (en) System-level testcase generation
US8117499B2 (en) Generation of a stimuli based on a test template
Saha et al. Llm for soc security: A paradigm shift
Jimenez et al. Software vulnerabilities, prevention and detection methods: A review1
JP5464031B2 (ja) プログラム検証装置、方法及びプログラム
JP2009211503A (ja) ソースコード検証装置、及びソースコード検証方法
JP6723483B2 (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
JP2012181666A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
US8903700B2 (en) Concretization of abstracted traces
Farias et al. ESBMC-Python: A Bounded Model Checker for Python Programs
KR101038397B1 (ko) 로봇 소프트웨어 화이트 박스 테스트를 위한 테스트 교호강도 결정 방법 및 자동화 테스트 시스템
von Detten Towards systematic, comprehensive trace generation for behavioral pattern detection through symbolic execution
JP2013065258A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
US8639490B2 (en) Concretization of abstracted traces
US8996435B2 (en) Determining invariants in a model
KR102692069B1 (ko) 악성코드 탐지 및 제거 시스템
Aoki et al. A method for detecting defects in source codes using model checking techniques
Freitez et al. Software vulnerabilities, prevention and detection methods: a review

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130306

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131224

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140106

R150 Certificate of patent or registration of utility model

Ref document number: 5464031

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150