JP2013148968A - テストデータ生成装置、テストデータ生成プログラムおよびテストデータ生成方法 - Google Patents

Abstract

【課題】仕様と作成したプログラムの不整合を検出するテストデータ生成装置、テストデータ生成プログラムおよびテストデータ生成方法を提供する。
【解決手段】仕様条件と実装条件とを組み合わせて組合条件を生成し、組合条件に含まれる変数の充足解を充足値生成部を用いて求め、仕様条件と実装条件に充足解を関連付けてテストデータ情報を生成する生成部と、２つの異なる仕様条件の組み合わせ条件を表す組合条件を生成し、組合条件に含まれる変数の充足解を充足値生成部を用いて求め、充足解をもたない組合条件を検出して排他的仕様条件とする排他的仕様条件検出部と、前記テストデータ情報を参照して、実装条件に対して排他的仕様条件に含まれる２つの仕様条件それぞれが充足解を有するか否かを検出するテストケース検出部と、を備えるテストデータ生成装置である。
【選択図】図２

Description

本発明は、プログラムのテストに用いるデータを生成するテストデータ生成装置、テストデータプログラムおよびテストデータ生成方法に関する。

従来、プログラムのテストを網羅的に行う方法として、仕様に基づいて作成したテストデータを用いてプログラムのテストを行う方法が知られている。
関連する技術として、自然言語の仕様とＣ言語のプログラムとＧｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ（ＧＵＩ）ベースの制御ロジックとのクロス検証を行うことができ、結果的に当該開発の効率を高めることができるクロス検証が開示されている。このクロス検証によれば、動作仕様、エンジン制御用のＣコードおよびエンジン制御用のＧＵＩロジックを作成する。そして、作成した動作仕様、ＣコードおよびＧＵＩロジックに基づいてアサーションを生成し、生成したアサーションを当該Ｃコードおよび当該ＧＵＩロジックに挿入する。その後、生成したアサーション、アサーションが挿入された後のＣコードおよびアサーションが挿入された後のＧＵＩロジックをＣｏｎｊｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ（ＣＮＦ）へ変換する。そして、作成した動作仕様に基づいて、変換した後のＣコードおよびＧＵＩロジックのクロス検証を行い、その検証結果を表示する。

また、関連する技術として、ウェブアプリケーションを検証するためのシンボリック実行につて開示がされている。
また、関連する技術として、現実のシステムを反映する複雑な動作仕様や多様な事象を取り扱いつつ、規模を抑えたシステム状態遷移系ならびにテストケースを生成する技術が開示されている。この技術によれば、システム動作仕様記述に基づいて遷移事象を順次生起させてシステム状態遷移系を生成する。その際に、遷移事象の順序制約を表現するシナリオ状態遷移系も同時に遷移させ、順次生起させる遷移事象を、当該シナリオ状態遷移系で遷移可能なものに制限する。

また、関連する技術として、計算機プログラムのソースコードが意味するプログラムの振る舞いに関する性質を検査するソースコード検査方法が開示されている。このソースコード検査方法では、計算機プログラムのソースコードにより記述されたプログラムを模擬的に実行して実際に実行される命令列を抽出し、抽出した命令列に基づいてソースコードの検査内容を決定する。

特開２００８−２７６５５６号公報 特開２００９−８７３５５号公報 特開２０１０−２１１４８１号公報 国際公開第２００６／０３８３９４号

本発明は、仕様と作成したプログラムの不整合を検出するテストデータ生成装置、テストデータ生成プログラムおよびテストデータ生成方法を提供することを目的とする。

本発明の態様のひとつであるテストデータ生成装置は、充足値生成部、生成部、排他的仕様条件検出部、テストケース検出部を備えている。
充足値生成部は、プログラムで用いられるコードに含まれる変数の充足解を求める。

生成部は、複数の第１のコードと複数の第２のコードと、を組み合わせて上記仕様条件と上記実装条件との組み合わせ条件を表す複数の第３のコードを生成する。第１のコードは、上記プログラムの仕様条件を変数を用いて表したコードである。第２のコードは、上記プログラムを入力とするシンボリック実行により抽出された上記プログラムが実行し得るパス各々に対応する実装条件を変数を用いて表したコードである。また、上記第３のコードに含まれる上記変数の充足解を上記充足値生成部を用いて求め、上記仕様条件と上記実装条件に充足解を関連付けてテストデータ情報を生成する。

排他的仕様条件検出部は、２つの異なる上記第１のコードの組み合わせ条件を表す複数の第４のコードを生成し、上記第４のコード各々に含まれる上記変数の充足解を上記充足値生成部を用いて求める。そして、充足解をもたない上記第４のコードを検出して排他的仕様条件とする。

テストケース検出部は、上記テストデータ情報を参照して、上記第２のコードに対して上記排他的仕様条件に含まれる２つの上記第１のコードそれぞれが充足解を有するか否かを検出する。

実施の態様によれば、仕様と作成したプログラムの不整合を検出することができるという効果を奏する。

テストデータ生成装置のハードウェアの一実施例を示す図である。 テストデータ生成装置の制御部の一実施例を示す図である。 抽出部、生成部、充足値生成部の動作の一実施例を示すフロー図である。 仕様情報とプログラム情報の一実施例と、仕様条件情報と実装条件情報のデータ構造の一実施例を示す図である。 組合条件情報のデータ構造の一実施例を示す図である。 テストデータ情報のデータ構造の一実施例を示す図である。 排他的仕様条件検出部の動作の一実施例を示すフロー図である。 排他的仕様条件検出で用いる仕様条件情報と組合条件情報のデータ構造の一実施例を示す図である。 組合条件に対してＳＭＴソルバにより求められる解の一実施例と、排他的仕様情報のデータ構造の一実施例を示す図である。 テストケース検出部の動作の一実施例を示すフロー図である。 排他的仕様条件と実装条件の関係を示す図である。 同一パスを通ることを説明する図である。 テストケース提示部の動作の一実施例を示すフロー図である。 出力部に提示する画面の一実施例を示す図である。

以下図面に基づいて、実施形態について詳細を説明する。
テストデータ生成装置１について説明する。
図１は、テストデータ生成装置のハードウェアの一実施例を示す図である。テストデータ生成装置１は、制御部２、記憶部３、記録媒体読取装置４、入出力インタフェース５（入出力Ｉ／Ｆ）、通信インタフェース６（通信Ｉ／Ｆ）などを備えている。また、上記各構成部はバス７によってそれぞれ接続されている。

制御部２は、後述する抽出部２０１、生成部２０２、充足値生成部２０３、排他的仕様条件検出部２０４、テストケース検出部２０５、テストケース提示部２０６などを有している。また、制御部２はCentral Processing Unit（ＣＰＵ）、マルチコアＣＰＵ、プログラマブルなデバイス（Field Programmable Gate Array（ＦＰＧＡ）、Programmable Logic Device（ＰＬＤ）など）を用いることが考えられる。

記憶部３は、後述する仕様情報、プログラム情報、仕様条件情報、実装条件情報、組合条件情報、テストデータ情報、排他的仕様条件を求めるための仕様条件情報と組合条件情報、排他的仕様条件情報などを記憶している。記憶部３は、例えばRead Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）などのメモリやハードディスクなどが考えられる。なお、記憶部３にはパラメータ値、変数値などのデータを記録してもよいし、実行時のワークエリアとして用いてもよい。上記仕様情報、プログラム情報、仕様条件情報、実装条件情報、組合条件情報、テストデータ情報、排他的仕様条件を求めるための仕様条件情報と組合条件情報、排他的仕様条件情報などは、データベースに記録されていてもよい。

記録媒体読取装置４は、制御部２の制御に従って記録媒体８に対するデータのリード／ライトを制御する。そして、記録媒体８に記録媒体読取装置４の制御で書き込まれたデータを記録させたり、記録媒体８に記録されたデータを読み取らせたりする。また、着脱可能な記録媒体８は、コンピュータで読み取り可能なnon-transitory（非一時的）な記録媒体として、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）などがある。光ディスクには、Digital Versatile Disc（ＤＶＤ）、ＤＶＤ−ＲＡＭ、Compact Disc Read Only Memory（ＣＤ−ＲＯＭ）、ＣＤ−Ｒ(Recordable)／ＲＷ（ReWritable）などがある。光磁気記録媒体には、Magneto-Optical disk（ＭＯ）などがある。なお、記憶部３もnon-transitory（非一時的）な記録媒体に含まれる。

入出力インタフェース５には、入出力部９が接続され、利用者が入力した情報（例えば、プログラムやモデル記述などのデータ）を受信し、バス７を介して制御部２または記憶部３などに送信する。また、制御部２からの命令に従ってディスプレイの画面上に出力情報（プログラムのテスト結果など）や操作情報などを表示する。入出力部９の入力装置は、例えば、キーボード、ポインティングデバイス（マウスなど）、タッチパネルなどが考えられる。なお、入出力部９の出力部であるディスプレイは、例えば、液晶ディスプレイなどが考えられる。また、出力部はCathode Ray Tube（ＣＲＴ）ディスプレイ、プリンタなどの出力装置であってもよい。

通信インタフェース６は、Local Area Network（ＬＡＮ）接続やインターネット接続や無線接続を行うためのインタフェースである。また、通信インタフェース６は必要に応じ、他のコンピュータとの間のＬＡＮ接続やインターネット接続や無線接続を行うためのインタフェースである。また、他の装置に接続され、外部装置からのデータの入出力を制御する。

このようなハードウェア構成を有するコンピュータを用いることによって、後述する各種処理機能が実現される。その場合システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能（例えば、後述する図３、図７、図１０、図１３に示すフロー）がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体８に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの記録媒体８が販売される。また、プログラムをサーバコンピュータの記憶装置に記録しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、記録媒体８に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶部３に記録する。そして、コンピュータは、自己の記憶部３からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、記録媒体８から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

制御部２について説明する。
図２は、テストデータ生成装置の制御部の一実施例を示す図である。制御部２は、抽出部２０１、生成部２０２、充足値生成部２０３、排他的仕様条件検出部２０４、テストケース検出部２０５、テストケース提示部２０６を有する。

抽出部２０１は、例えば、プログラムを入力としてシンボリック実行を行い、抽出されたパス各々で用いられている変数に対する条件（実装条件）を抽出する。シンボリック実行では、プログラムを、そのプログラムに含まれる変数に具体的な数値を入力する代わりに、数値を代表するシンボルでプログラムを模擬的に実行し、その結果を評価する。なお、抽出部２０１は、テストデータ生成装置と別に設けられていてもよい。すなわち、対象のプログラムを入力とし、別のコンピュータによりシンボリック実行を行って実装条件を求めてもよい。

生成部２０２は、仕様に基づいて作成した仕様条件各々（第１のコード）と、シンボリック実行を用いて抽出された実装条件各々（第２のコード）とを組み合わせた組合条件（第３のコード）を生成し、生成部２０２は充足値生成部２０３に生成した組合条件各々を送信する。また、生成部２０２は、充足値生成部２０３が求めた組合条件各々を充足する組合条件に含まれる変数の解を取得し、組合条件に関連付けてテストデータを記憶部３の後述するテストデータ情報に記憶する。

充足値生成部２０３は、例えば、ＳＭＴソルバを用いてテストデータを求めることが考えられる。
ＳＭＴソルバは、論理式が矛盾していないことを示すために、論理式全体を真とするような各部分論理式の真偽時の組み合わせが存在するか否かを判定する。なお、ＳＭＴソルバは、整数、実数、配列などを扱うことができるという利点がある。ＳＭＴソルバに関しては、例えば、次の非特許文献を参照されたい。

・足立正和，他、「充足可能性判定に基づくリアルタイムシステムのスケジューリング解析」、組込みシステムシンポジウム２００８、平成２０年１０月
・Armin Biere, Marijn Heule, Hans Van Maaren, Toby Walsh, "Handbook of Satisfiability(Frontiers in Artificial Intelligence and Applications)",IOS Press, ２００９年２月
・R.E. Bryant, Daniel Kroening, Ofer Strichman, "Decision Procedures: An Algorithmic Point of View (Texts in Theoretical Computer Science. An EATCS Series)", Springer, ２００８年７月７日
排他的仕様条件検出部２０４は、２つの異なる仕様条件の組み合わせ条件を表す複数の組合条件（第４のコード）を生成し、組合条件各々に含まれる変数の充足解を充足値生成部を用いて求める。そして、充足解をもたない組合条件を検出して排他的仕様条件とする。

テストケース検出部２０５は、テストデータ情報を参照して、実装条件に対して排他的仕様条件に含まれる２つの仕様条件それぞれが充足解を有するか否かを検出する。
テストケース提示部２０６は、テストケース検出部２０５が検出した２つの異なる仕様条件と実装条件に不整合があることを提示する画面を生成する。

なお、抽出部２０１、生成部２０２、充足値生成部２０３、排他的仕様条件検出部２０４、テストケース検出部２０５、テストケース提示部２０６各々の機能を、それぞれを異なるコンピュータに実装し、コンピュータ各々をネットワークにより接続してテストデータを生成してもよい。

テストデータ生成装置の動作について説明する。
図３は、抽出部、生成部、充足値生成部の動作の一実施例を示すフロー図である。ステップＳ１では、生成部２０２が仕様に基づいてモデル記述した仕様条件を示すコードが記憶されている記憶部３の仕様条件情報を参照して、未処理の仕様条件を特定する。仕様条件情報は、例えば、図４に示す仕様条件情報４０２などが考えられる。

図４は、仕様情報とプログラム情報の一実施例と、仕様条件情報と実装条件情報のデータ構造の一実施例を示す図である。仕様情報４０１は、例えば、仕様書の内容を示す情報である。本例では、仕様１として入力データである変数ａ＞＝０の場合にａ×１０が表示されること、仕様２として変数ｂ＞＝０の場合にｂ×１０が表示されること、仕様３として変数ａ＜０かつ変数ｂ＜０の場合に何も表示されないこと、が記載されている。

仕様条件情報４０２は、「Ｎｏ」「仕様条件」「処理済」などに記憶される情報を有する。「Ｎｏ」は仕様条件に関連付けられる識別子で、本例では、識別子「１」「２」「３」などが記憶されている。「仕様条件」には、仕様条件が識別子「１」「２」「３」に関連付けて記憶されている。本例では、識別子「１」「２」「３」の記載に対してモデル記述した仕様条件を示すコードが、「Ｎｏ」に関連付けられて記憶されている。図４の仕様条件情報４０２の例では、「ａ＞＝０」、「ｂ＞＝０」、「ａ＜０＆ｂ＜０」の仕様に対応する仕様条件である。「処理済」には、現在選択されている仕様条件を示すコードに対して後述する実装条件と組み合わせた（例えば、論理積＆で結合した）条件を生成したか否かを示す情報が記憶されている。本例では、「２」「１」「０」が記載されており、現在選択されている仕様条件に対して全ての実装条件が組み合わされている場合（ステップＳ３の処理が実施されている場合）、識別子「２」が記憶される。現在選択されている仕様条件に対してまだ組み合わされていない実装条件がまだある場合、識別子「１」が記憶される。まだ選択されていない仕様条件に対しては識別子「０」が記憶される。

すなわち、ステップＳ１では仕様条件情報４０２の「処理済」を参照し、「処理済」に「１」または「０」が記載されている仕様条件を選択する。図４の仕様条件情報４０２の場合であれば、「Ｎｏ」の「２」に関連する「処理済」が「１」の状態の仕様条件を選択する。

ステップＳ２では、生成部２０２が現在選択されている仕様条件に対して未処理の実装条件を示すコードを特定する。
実装条件について説明する。実装条件を示すコードは、例えば、抽出部２０１が図４のプログラム情報４０３を記憶部３から取得して、プログラム情報４０３に対してシンボリック実行を行って得られるコードである。本例では、プログラム情報４０３に対してシンボリック実行を行って得られる条件として、図４に示す実装条件情報４０４が得られる。プログラム情報４０３は、上記仕様１〜３に基づいて作成したプログラムであり、５行目に誤りがある。本来、仕様に基づいてプログラムを作成すると５行目の記載は、「ｉｆ （ｂ＞＝０）｛ 」でなければならない。

実装条件情報４０４には、プログラム情報４０３に対してシンボリック実行を行った結果である実装条件が記憶され、「Ｎｏ」「実装条件」「処理済」などに記憶される情報を有する。「Ｎｏ」は実装条件に関連付けられる識別子で、本例では、識別子「１」「２」「３」「４」などが記憶されている。「実装条件」には対象のプログラムに対してシンボリック実行を行った結果である実装条件が、識別子「１」「２」「３」「４」に関連付けて記憶されている。本例では、シンボリック実行をした結果として「ａ＞＝０＆ｂ＞０」「ａ＞＝０＆ｂ＜＝０」「ａ＜０＆ｂ＞０」「ａ＜０＆ｂ＜＝０」が記憶されている。「処理済」には現在選択されている仕様条件と実装条件とを組み合わせた組合条件が生成されたか否かを示す情報が記憶される。本例では、「１」「０」が記載されており、現在選択されている仕様条件と実装条件とが組合条件に対してステップＳ３の処理が実施されていれば、識別子「１」が記憶される。現在選択されている仕様条件に対してまだ組み合わされていない実装条件には識別子「０」が記憶される。また、「処理済」には１つの仕様条件を示すコードに対して全ての実装条件を示すコードを組み合わせて生成された組合条件を示すコード全てに対してステップＳ３の処理が実施されると、全ての「処理済」に「０」が記憶される。

なお、ステップＳ１の処理とステップＳ２の処理の順番はどちらが先でもよい。
ステップＳ３では、仕様条件と実装条件とを＆で結合して組合条件を生成して、充足値生成部２０３に送信する。このとき、記憶部３に組合条件を記憶してもよい。なお、＆は上述した＆と同じように論理積を示す記号である。図５は、組合条件情報のデータ構造の一実施例を示す図である。図５の組合条件情報５０１は、「Ｎｏ」「組合条件」などに記憶される情報を有する。「Ｎｏ」は組合条件に関連付けられる識別子で、本例では、識別子「１」〜「１２」が記憶されている。「組合条件」には、仕様条件を示すコードと実装条件を示すコードとを＆で結合したコードが、識別子「Ｎｏ」に関連付けて記憶されている。本例では、組合条件情報５０１の識別子「１」〜「１２」に関連付けられて、「ａ＞＝０ ＆ ａ＞＝０ ＆ ｂ＞０」〜「ａ＜０ ＆ ｂ＜０ ＆ ａ＜０ ＆ ｂ＜＝０」が記憶されている。

例えば、組合条件情報５０１の識別子「１」に関連付けられている「ａ＞＝０ ＆ ａ＞＝０ ＆ ｂ＞０」を生成する場合、ステップＳ１で仕様条件情報４０２の最初のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択される。ステップＳ２で実装条件情報４０４の最初のＮｏ「１」に対応する実装条件「ａ＞＝０ ＆ ｂ＞０」が選択され、＆で結合される。このとき、仕様条件情報４０２の最初のＮｏ「１」に対応する「処理済」を「０」から「１」にし、実装条件情報４０４の最初のＮｏ「１」に対応する「処理済」は「０」から「１」にする。

次にステップＳ３で組合条件情報５０１の識別子「２」に関連付けられている「ａ＞＝０ ＆ ａ＞＝０ ＆ ｂ＜＝０」を生成する場合、ステップＳ１で仕様条件情報４０２の最初のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択されたまま、ステップＳ２で実装条件情報４０４の未処理のＮｏ「２」に対応する実装条件「ａ＞＝０ ＆ ｂ＜＝０」が選択され、＆で結合される。このとき、仕様条件情報４０２の最初のＮｏ「１」に対応する「処理済」は「１」のままで、実装条件情報４０４のＮｏ「２」に対応する「処理済」は「０」から「１」になる。

次にステップＳ３で組合条件情報５０１の識別子「３」に関連付けられている「ａ＞＝０ ＆ ａ＜０ ＆ ｂ＞０」を生成する場合、ステップＳ１で仕様条件情報４０２の最初のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択されたまま、ステップＳ２で実装条件情報４０４の未処理のＮｏ「３」に対応する実装条件「ａ＜０ ＆ ｂ＞０」が選択され、＆で結合される。このとき、仕様条件情報４０２の最初のＮｏ「１」に対応する「処理済」は「１」のままで、実装条件情報４０４のＮｏ「３」に対応する「処理済」は「０」から「１」になる。

続いて、仕様条件「ａ＞＝０」において、実装条件情報４０４のＮｏ「３」に関連する実装条件を用いた処理が終了すると、次にステップＳ３で実装条件情報４０４のＮｏ「４」に関連する実装条件「ａ＜０ ＆ ｂ＜＝０」を生成する場合、ステップＳ１で仕様条件情報４０２のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択されたまま、ステップＳ２で実装条件情報４０４の最後の未処理のＮｏ「４」に対応する実装条件が選択され、＆で結合される。このとき、仕様条件情報４０２のＮｏ「１」に対応する「処理済」は「１」から「２」になり、実装条件情報４０４のＮｏ「４」に対応する「処理済」は「０」から「１」になる。

続いて、仕様条件情報４０２のＮｏ「１」の処理が終了（仕様条件情報４０２のＮｏ「１」の「処理済」が「２」）し、仕様条件情報４０２のＮｏ「２」がステップＳ１で選択される（「処理済」が「１」）。このとき、実装条件情報４０４のＮｏ「１」〜「４」に対応する「処理済」はすべて「０」にする。

続いて、仕様条件情報４０２のＮｏ「２」〜「３」に対応する仕様条件各々について、実装条件情報４０４のＮｏ「１」〜「４」に関連する実装条件各々と組み合わせて、組合条件情報５０１に示す組合条件を生成する。仕様条件情報４０２のＮｏ「３」が選択され、実装条件情報４０４のＮｏ「５」が選択されているとき（全て組み合わされたとき）、仕様条件情報４０２の「処理済」はすべて「２」になり、実装条件情報４０４の「処理済」はすべて「２」にる。

ステップＳ４では、充足値生成部２０３が組合条件を生成部２０２から取得し、組合条件に対してＳＭＴソルバを用いて条件を同時に充足する解を求め、求めた解を生成部２０２に送信する。また、充足値生成部２０３は組合条件に対して求めた解を、仕様条件各々と実装条件各々に対応付けて記憶する。図６は、テストデータ情報のデータ構造の一実施例を示す図である。組合条件情報５０１において、解が存在するのはＮｏ「１」「２」、「５」〜「８」、「１２」に対応する組合条件である。そして、Ｎｏ「１」の解は「ａ＝０，ｂ＝１」、Ｎｏ「２」の解は「ａ＝１，ｂ＝０」である。また、Ｎｏ「５」の解は「ａ＝０，ｂ＝１」、Ｎｏ「６」の解は「ａ＝０，ｂ＝０」、Ｎｏ「７」の解は「ａ＝−１，ｂ＝１」、Ｎｏ「８」の解は「ａ＝−１，ｂ＝０」である。また、Ｎｏ「１２」の解は「ａ＝−１，ｂ＝−１」である。

ステップＳ５では、生成部２０２が充足値生成部２０３から求めた解を受信し、解が存在するか否かを判定し、解が存在する場合にはステップＳ６（Ｙｅｓ）に移行し、解が存在しない場合にはステップＳ７（Ｎｏ）に移行する。

続いて、ステップＳ５で判定をした組合条件について、解がある場合にはステップＳ６で、生成部２０２は解をテストデータとして記憶部３に記憶する。よって、生成部２０２は記憶部３にテストデータとしてａ＝−１、０、１とｂ＝−１、０、１を記憶する。

ステップＳ７では、生成部２０２が現在選択されている仕様条件に対して未処理の実装条件が存在するか否かを判定し、未処理の実装条件が存在する場合にはステップＳ２（Ｙｅｓ）に移行し、未処理の実装条件がない場合にはステップＳ８（Ｎｏ）に移行する。本例では、実装条件情報４０４の「処理済」を参照して未処理の実装条件が存在するか否かを判定する。「処理済」のいずれかに未処理を示す「０」が記憶されているときにはステップＳ２（Ｙｅｓ）に移行する。「処理済」がすべて「１」である場合には、ステップＳ８（Ｎｏ）に移行する。

ステップＳ８では、生成部２０２が未処理の仕様条件が存在するか否かを判定し、未処理の仕様条件が存在する場合にはステップＳ１（Ｙｅｓ）に移行し、未処理の仕様条件がない場合には処理を終了（Ｎｏ）する。本例では、仕様条件情報４０２の「処理済」を参照して未処理の実装条件が存在するか否かを判定する。「処理済」のいずれかに未処理を示す「０」または処理中であることを示す「１」が記憶されているときにはステップＳ１（Ｙｅｓ）に移行する。「処理済」に記憶されている情報が、すべての処理が終了したことを示す「２」である場合には処理を終了する（Ｎｏ）。

上記の処理により、仕様と異なる誤りを有するプログラムを用いて該プログラムのテストを行う場合であっても、必要十分なテストデータを生成できる。また、プログラムに誤りがあっても、仕様と異なる分岐条件（ｉｆ分など）がある部分を検出できるテストケースが生成でき、その結果プログラムの分岐条件の確認に必要十分なテストデータが生成できる。また、仕様条件と実装条件とが同時に満たされるテストケースを求めているため、冗長なテストデータが生成されない。

排他的仕様条件検出部の動作について説明する。
図７は、排他的仕様条件検出部の動作の一実施例を示すフロー図である。ステップＳ７０１では、排他的仕様条件検出部２０４が仕様に基づいてモデル記述した仕様条件を示すコードが記憶されている記憶部３の仕様条件情報を参照して、未処理の仕様条件を特定する。

ステップＳ７０２では、排他的仕様条件検出部２０４が特定した仕様条件に対して仕様条件情報を参照して未処理の仕様条件を特定する。
仕様条件情報は、例えば、図８に示す仕様条件情報８０１などが考えられる。図８は、排他的仕様条件検出で用いる仕様条件情報と組合条件情報のデータ構造の一実施例を示す図である。仕様情報８０１は、例えば、仕様書の内容を示す情報である。本例では、仕様１として入力データである変数ａ＞＝０の場合にａ×１０が表示されること、仕様２として変数ｂ＞＝０の場合にｂ×１０が表示されること、仕様３として変数ａ＜０かつ変数ｂ＜０の場合に何も表示されないこと、が記載されている。

図８の仕様条件情報８０１は、「Ｎｏ」「仕様条件」「処理済」などに記憶される情報を有する。「Ｎｏ」は仕様条件に関連付けられる識別子で、本例では、識別子「１」「２」「３」などが記憶されている。「仕様条件」には、仕様条件が識別子「１」「２」「３」に関連付けて記憶されている。本例では、識別子「１」「２」「３」の記載に対してモデル記述した仕様条件を示すコードが、「Ｎｏ」に関連付けられて記憶されている。図８の仕様条件情報８０１の例では、「ａ＞＝０」、「ｂ＞＝０」、「ａ＜０＆ｂ＜０」の仕様に対応する仕様条件である。「処理済」には、現在選択されている仕様条件を示すコードに対して未処理の他の仕様条件と組み合わせた（例えば、論理積＆で結合した）条件を生成したか否かを示す情報が記憶されている。本例では、「２」「１」「０」が記載されており、現在選択されている仕様条件に対して全ての未処理の他の仕様条件が組み合わされている場合（ステップＳ７０３の処理が実施されている場合）、識別子「２」が記憶される。現在選択されている仕様条件に対してまだ組み合わされていない仕様条件がまだある場合、識別子「１」が記憶される。まだ選択されていない仕様条件に対しては識別子「０」が記憶される。

すなわち、ステップＳ７０１、Ｓ７０２では仕様条件情報８０１の「処理済」を参照し、「処理済」に「１」または「０」が記載されている仕様条件を選択する。図８の仕様条件情報８０１の場合であれば、「Ｎｏ」の「２」に関連する「処理済」が「１」の状態の仕様条件を選択する。

ステップＳ７０３では、排他的仕様条件検出部２０４が選択された仕様条件と未処理の他の仕様条件とを＆で結合して組合条件を生成して、充足値生成部２０３に送信する。このとき、記憶部３に組合条件を記憶してもよい。なお、＆は上述した＆と同じように論理積を示す記号である。

図８の組合条件情報８０２は、「Ｎｏ」「組合条件」などに記憶される情報を有する。「Ｎｏ」は組合条件に関連付けられる識別子で、本例では、識別子「１」〜「３」が記憶されている。「組合条件」には、２つの異なる仕様条件（選択された仕様条件と未処理の他の仕様条件）を示すコードを＆で結合したコードが、識別子「Ｎｏ」に関連付けて記憶されている。本例では、組合条件情報８０２の識別子「１」〜「３」に関連付けられて、「ａ＞＝０ ＆ ｂ＞＝０」「ａ＞＝０ ＆ ａ＜０ ＆ ｂ＜０」「ｂ＞＝０ ＆ ａ＜０ ＆ ｂ＜０」が記憶されている。

例えば、組合条件情報８０２の識別子「１」に関連付けられている「ａ＞＝０ ＆ ｂ＞＝０」を生成する場合、ステップＳ７０１で仕様条件情報８０１の最初のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択される。ステップＳ７０２で仕様条件情報８０１の未処理の他の仕様条件である最初のＮｏ「２」に対応する実装条件「ｂ＞＝０」が選択され、＆で結合される。このとき、仕様条件情報８０１の最初のＮｏ「１」に対応する「処理済」を「０」から「１」にし、仕様条件情報８０１のＮｏ「２」に対応する「処理済」は「０」から「１」にする。

次に、組合条件情報８０２の識別子「２」に関連付けられて「ａ＞＝０ ＆ ａ＜０ ＆ ｂ＜０」を生成する場合、ステップＳ７０１で仕様条件情報８０１の最初のＮｏ「１」に対応する仕様条件「ａ＞＝０」が選択されたまま、ステップＳ７０２で未処理のＮｏ「３」に対応する仕様条件「ａ＜０ ＆ ｂ＜０」が選択され、＆で結合される。このとき、仕様条件情報４０２の最初のＮｏ「１」に対応する「処理済」は「２」になり、Ｎｏ「３」に対応する「処理済」は「０」から「１」になる。

続いて、仕様条件情報８０１のＮｏ「１」の処理が終了し（仕様条件情報８０１のＮｏ「１」の「処理済」が「２」）、仕様条件情報８０１のＮｏ「２」がステップＳ７０１で選択される（「処理済」が「１」）。このとき、仕様条件情報８０１のＮｏ「３」に対応する「処理済」は「０」にする。

続いて、仕様条件情報８０１のＮｏ「２」に対応する仕様条件について、Ｎｏ「３」に関連する仕様条件各々と組み合わせて、組合条件情報８０２に示す組合条件を生成する。仕様条件情報８０１のＮｏ「２」と「３」が選択されているとき（全て組み合わされたとき）、仕様条件情報８０１の「処理済」はすべて「２」になる。

ステップＳ７０４では、充足値生成部２０３が組合条件を排他的仕様条件検出部２０４または記憶部３から取得し、組合条件に対してＳＭＴソルバを用いて条件を同時に充足する解を求め、求めた解を排他的仕様条件検出部２０４に送信する。

ステップＳ７０５では、排他的仕様条件検出部２０４が充足値生成部２０３から求めた解を受信し、解が存在するか否かを判定し、解が存在しない場合にはステップＳ７０６（Ｎｏ）に移行し、解が存在する場合にはステップＳ７０７（Ｙｅｓ）に移行する。

続いて、ステップＳ７０５で判定をした組合条件について、解がない場合にはステップＳ７０６で、排他的仕様条件検出部２０４は解をテストデータとして記憶部３に記憶する。図９は、組合条件に対してＳＭＴソルバにより求められる解の一実施例と、排他的仕様情報のデータ構造の一実施例を示す図である。図９の表９０１に示すように、組合条件情報８０２において、解が存在するのはＮｏ「１」に対応する組合条件である。解が存在しないのはＮｏ「２」、「３」に対応する組合条件である。

また、排他的仕様条件検出部２０４は排他的仕様条件情報に解のない仕様条件のペアを記憶する。図９の排他的仕様条件情報９０２は排他的仕様条件のペアが記憶されている。本例では、「排他的仕様条件１」に関連付けて「仕様条件１」（ａ＞＝０）と「仕様条件３」（ａ＜０ ＆ ｂ＜０）からなる排他的仕様条件を記憶部３に記憶する。また、「排他的仕様条件２」に関連付けて「仕様条件２」（ｂ＞＝０）と「仕様条件３」（ａ＜０ ＆ ｂ＜０）からなる排他的仕様条件とを記憶部３に記憶する。

ステップＳ７０７では、排他的仕様条件検出部２０４が現在選択されている仕様条件に対して未処理の他の仕様条件が存在するか否かを判定し、未処理の他の仕様条件が存在する場合にはステップＳ７０２（Ｙｅｓ）に移行し、未処理の他の仕様条件がない場合にはステップＳ７０８（Ｎｏ）に移行する。

ステップＳ７０８では、排他的仕様条件検出部２０４が未処理の仕様条件が存在するか否かを判定し、未処理の仕様条件が存在する場合にはステップＳ７０１（Ｙｅｓ）に移行し、未処理の仕様条件がない場合には処理を終了（Ｎｏ）する。

テストケース検出部の動作について説明する。
図１０は、テストケース検出部の動作の一実施例を示すフロー図である。ステップＳ１００１では、テストケース検出部２０５が排他的仕様条件情報を参照して、未処理の排他的仕様条件を特定する。例えば、図９の排他的仕様条件情報９０２の場合であれば排他的仕様条件１または排他的仕様条件２が特定される。

ステップＳ１００２では、テストケース検出部２０５が特定した排他的仕様条件の仕様条件をそれぞれ特定する。例えば、図９の排他的仕様条件９０２の排他的仕様条件１が特定されると仕様条件１と仕様条件３が特定される。排他的仕様条件２が特定されると仕様条件２と仕様条件３が特定される。

ステップＳ１００３では、テストケース検出部２０５が現在特定されている排他的仕様条件に対して、テストデータ情報の未処理の実装条件を一つ特定する。
ステップＳ１００４では、テストケース検出部２０５が現在特定されている排他的仕様条件の仕様条件それぞれについて、現在の実装条件に対応するテストデータが両方の仕様条件に存在するか判定する。

ステップＳ１００５では、テストケース検出部２０５が両方に存在する場合にはステップＳ１００６（Ｙｅｓ）に移行し、存在しない場合にはステップＳ１００７（Ｎｏ）に移行する。

ステップＳ１００３〜Ｓ１００５について説明をする。ステップＳ１００１で図９の排他的仕様条件情報９０２の排他的仕様条件１が特定されると、排他的仕様条件１の仕様条件１と仕様条件３がステップＳ１００２で特定される。

続いて、ステップＳ１００３で図６のテストデータ情報の仕様条件１と仕様条件３に対応する実装条件１を特定する。
ステップＳ１００４、Ｓ１００５では、図１１の表１１０１に示すように、まず実装条件１に対応する仕様条件１と仕様条件３の両方にテストデータが存在するかを判定する。図１１は、排他的仕様条件と実装条件の関係を示す図である。実装条件１の場合には、仕様条件１側にしかテストデータがないのでステップＳ１００７に移行する。実装条件２の場合にも、仕様条件１側にしかテストデータがないのでステップＳ１００７に移行する。実装条件３の場合には、仕様条件１と仕様条件３側にテストデータがないのでステップＳ１００７に移行する。実装条件４の場合には、仕様条件３側にしかテストデータがないのでステップＳ１００７に移行する。

ステップＳ１００７で全ての実装条件１〜４について判定をするとステップＳ１００８に移行する。そして、未処理の排他的仕様条件２があるのでステップＳ１００１に移行する。

ステップＳ１００１で図９の排他的仕様条件情報９０２の排他的仕様条件２が特定されると、排他的仕様条件２の仕様条件２と仕様条件３がステップＳ１００２で特定される。
続いて、ステップＳ１００３で図６のテストケース生成情報の仕様条件２と仕様条件３に対応する実装条件１を特定する。

ステップＳ１００４、Ｓ１００５では、図１１の表１１０２に示すように、まず実装条件１に対応する仕様条件２と仕様条件３の両方にテストデータが存在するかを判定する。実装条件１の場合には、仕様条件２側にしかテストデータがないのでステップＳ１００７に移行する。実装条件２の場合にも、仕様条件２側にしかテストデータがないのでステップＳ１００７に移行する。実装条件３の場合にも、仕様条件２側にしかテストデータがないのでステップＳ１００７に移行する。実装条件４の場合には、仕様条件２と仕様条件３のそれぞれの側にテストデータがあるのでステップＳ１００６に移行する。すなわち、同一のパスを通るテストデータがあることが判定できる。プログラムが仕様通りに作成されている場合、仕様が排他となるペアで重複するテストケースは生成されない。もし、重複するテストケースが生成されれば、その箇所のプログラムに問題があると判断できる。

ステップＳ１００６では、テストケース検出部２０５が現在の仕様条件と実装条件を記憶部３に記憶する。本例では、実装条件４、仕様条件２、仕様条件３を記憶する。

図１２は、同一パスを通ることを説明する図である。図１２のフロー図は仕様に沿ったフローを示している。仕様条件２（ｂ＞＝０）でテストケースがａ＝−１とｂ＝０である場合と、仕様条件３（ａ＜０ ＆ ｂ＜０）で、テストケースがａ＝−１とｂ＝−１である場合とにおいて、同じパスを（太線矢印）通ることを図１２は示している。

ステップＳ１００７では、テストケース検出部２０５が現在の排他的仕様条件に対してテストケース生成情報の未処理の実装条件が存在するか否かを判定し、未処理の実装条件がある場合にはステップＳ１００２（Ｙｅｓ）に移行する。未処理の実装条件がない場合にはステップＳ１００８（Ｎｏ）に移行する。

ステップＳ１００８では、テストケース検出部２０５が未処理の排他的仕様条件が存在するか否かを判定し、未処理の排他的仕様条件がある場合にはステップＳ１００１（Ｙｅｓ）に移行する。未処理の排他的仕様条件がない場合には終了（Ｎｏ）する。

その後、テストケース提示部２０６は図１４に示す画面を表示する。図１３は、テストケース提示部の動作の一実施例を示すフロー図である。ステップＳ１３０１では、テストケース提示部がステップＳ１００６において記憶部３に記憶した仕様条件と実装条件を取得する。すなわち、実装条件と、排他的仕様条件のうち該実装条件に対して充足解を２つ有する異なる仕様条件を取得する。本例では、実装条件４、仕様条件２、仕様条件３を記憶する。

ステップＳ１３０２でテストケース提示部は、取得した実装条件と仕様条件を用いて表示画面を提示するための情報を生成する。例えば、図１４に示す表示画面１４０１を生成して入出力部９の出力部に提示する。図１４は、出力部に提示する画面の一実施例を示す図である。本例では、「仕様とプログラムの間で以下の不整合を検出しました。不整合１：仕様条件２（ｂ＞＝０）に対応するテストケース（ａ＝−１，ｂ＝０）と、仕様条件３（ａ＜０ ＆ ｂ＜０）に対応するテストケース（ａ＝−１，ｂ＝−１）はプログラム中の同一のパスを通ります。不整合２：・・・・」を表示する。なお、表示内容は上記に限定されるものではない。

ステップＳ１３０３でテストケース提示部は、表示画面を提示するための情報を出力部に送信する。
上記実施形態によれば、仕様と作成したプログラムの不整合を検出することができるという効果を奏する。

また、大量のテストケースの中から、同一パスを通るテストケースを特定できるため、従来のようにテストケースに対して予め期待値を設定することや、テストを実際に実行した結果を確認しなくても、仕様と実装の不整合を確認できる。

また、テストを行う際に早い段階で同一パスを検出することができる。
なお、実施の形態で説明したテスト対象のプログラムは、例えば、業務アプリケーションなどに用いられるプログラムなどが考えられる。

また、本発明は、上記実施の形態に限定されるものでなく、本発明の要旨を逸脱しない範囲内で種々の改良、変更が可能である。

１ テストデータ生成装置
２ 制御部
３ 記憶部
４ 記録媒体読取装置
５ 入出力インタフェース
６ 通信インタフェース
７ バス
８ 記録媒体
９ 入出力部
２０１ 抽出部
２０２ 生成部
２０３ 充足値生成部
２０４ 排他的仕様条件検出部
２０５ テストケース検出部
２０６ テストケース提示部
４０１ 仕様情報
４０２ 仕様条件情報
４０３ プログラム情報
４０４ 実装条件情報
５０１ 組合条件情報
６０１ テストデータ情報
８０１ 仕様条件情報
８０２ 組合条件情報
９０２ 排他的仕様条件情報

Claims (6)

1. プログラムで用いられるコードに含まれる変数の充足解を求める充足値生成部と、
   前記プログラムの仕様条件を変数を用いて表した複数の第１のコードと、前記プログラムを入力とするシンボリック実行により抽出された前記プログラムが実行し得るパス各々に対応する実装条件を変数を用いて表した複数の第２のコードと、を組み合わせて前記仕様条件と前記実装条件との組み合わせ条件を表す複数の第３のコードを生成し、前記第３のコードに含まれる前記変数の充足解を前記充足値生成部を用いて求め、前記仕様条件と前記実装条件に充足解を関連付けてテストデータ情報を生成する生成部と、
   ２つの異なる前記第１のコードの組み合わせ条件を表す複数の第４のコードを生成し、前記第４のコード各々に含まれる前記変数の充足解を前記充足値生成部を用いて求め、充足解をもたない前記第４のコードを検出して排他的仕様条件とする排他的仕様条件検出部と、
   前記テストデータ情報を参照して、前記第２のコードに対して前記排他的仕様条件に含まれる２つの前記第１のコードそれぞれが充足解を有するか否かを検出するテストケース検出部と、
   を備えることを特徴とするテストデータ生成装置。
2. 前記テストケース検出部が検出した２つの異なる前記第１のコードに対応する前記仕様条件と前記実装条件とに不整合があることを提示する画面を生成するテストケース提示部、を備えることを特徴とするテストデータ生成装置。
3. プログラムの仕様条件を変数を用いて表した複数の第１のコードと、前記プログラムを入力とするシンボリック実行により抽出された前記プログラムが実行し得るパス各々に対応する実装条件を変数を用いて表した複数の第２のコードと、を組み合わせて前記仕様条件と前記実装条件との組み合わせ条件を表す複数の第３のコードを生成し、
   前記第３のコードに含まれる前記変数の充足解を求め、
   前記仕様条件と前記実装条件に充足解を関連付けてテストデータ情報を生成し、
   ２つの異なる前記第１のコードの組み合わせ条件を表す複数の第４のコードを生成し、
   前記第４のコード各々に含まれる前記変数の充足解を求め、
   充足解をもたない前記第４のコードを検出し、
   前記テストデータ情報を参照して、前記第２のコードに対して前記排他的仕様条件に含まれる２つの前記第１のコードそれぞれが充足解を有するか否かを検出する、
   処理をコンピュータに実行させるテストデータ生成プログラム。
4. 前記第２のコードに対してそれぞれが充足解を有する２つの異なる前記第１のコードに対応する前記仕様条件と前記実装条件に不整合があることを提示する画面を生成する、処理を前記コンピュータに実行させることを特徴とする請求項３に記載のテストデータ生成プログラム。
5. コンピュータによって実行されるテストデータ生成方法であって、
   プログラムの仕様条件を変数を用いて表した複数の第１のコードと、前記プログラムを入力とするシンボリック実行により抽出された前記プログラムが実行し得るパス各々に対応する実装条件を変数を用いて表した複数の第２のコードと、を組み合わせて前記仕様条件と前記実装条件との組み合わせ条件を表す複数の第３のコードを生成し、
   前記第３のコードに含まれる前記変数の充足解を求め、
   前記仕様条件と前記実装条件に充足解を関連付けてテストデータ情報を生成し、
   ２つの異なる前記第１のコードの組み合わせ条件を表す複数の第４のコードを生成し、
   前記第４のコード各々に含まれる前記変数の充足解を求め、
   充足解をもたない前記第４のコードを検出し、
   前記テストデータ情報を参照して、前記第２のコードに対して前記排他的仕様条件に含まれる２つの前記第１のコードそれぞれが充足解を有するか否かを検出する、
   ことを特徴とするテストデータ生成方法。
6. 前記コンピュータが、前記第２のコードに対してそれぞれが充足解を有する２つの異なる前記第１のコードに対応する前記仕様条件と前記実装条件に不整合があることを提示する画面を生成し、前記画面を出力部に出力させる、ことを特徴とする請求項５に記載のテストデータ生成方法。

Images