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

Description

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

従来、ソフトウェア開発において、開発対象のプログラムに対してテストケースを生成する技術としてシンボリック実行が知られている。シンボリック実行は、入力変数に記号値などのシンボル値を設定して、プログラムの実行をエミュレートすることにより、プログラムを分析する技術である。

例えば、ＩＦ文を含むＣＯＢＯＬプログラムをシンボリック実行した場合、実行可能なパス、および、パス毎のパス条件が抽出される。ここで、パスは、実行された命令文の系列であり、パス条件は、パスが終了するまでに経由する条件のうち不定な変数値に関する条件式である。つまり、テスト対象を通過するパスがテストケースに該当し、パス条件を満たすプログラム変数の値が、テストケースのテストデータとなる。

一般に、プログラムは、入力である外部変数や局所変数に対して種々の処理が記述され、該処理が実行されることによって、所望の機能が実行される。このようなプログラムには、前処理（以降、チェック処理と記載する場合がある）と主処理（以降、メイン処理と記載する場合がある）が含まれる。前処理は、入力が所望条件を満たすことを判定する入力チェック処理であり、主処理は、所望の機能を実現する処理を記述したメイン処理である。

そして、前処理と主処理を含むプログラムに対してシンボリック実行を行った場合、それぞれの処理内の条件分岐においてパス分岐が発生するので、前処理をテストするためのテストケースおよび主処理をテストするためのテストケースが生成される。

特開２０００−３３９１９２号公報 特開２００７−４１８０４号公報 特開２０１３−１４３０６７号公報

しかしながら、上記技術では、入力チェック処理のテストケースが必要以上に多く生成される。

一般に、チェック処理は、多くのプログラムで共通して使用される定型的な処理であるので、チェック処理自体に対するテストの重要度は、メイン処理に対するテストに比較して低い。このため、チェック処理のテストケースは、メイン処理のテストケースと比較して、少数で済むと考えられる。しかしながら、シンボリック実行は、プログラム内のチェック処理とメイン処理を区別することができないので、チェック処理とメイン処理のテストケースを区別して生成することができない。

なお、シンボリック実行で生成されたテストケース全体から、重複するテストケースを除外することで、テストケース数を削減することも考えられる。しかし、シンボリック実行によって生成されるテストケース自体の数は変わらないので、テストケースの抽出時間が長時間化する。また、チェック処理をコメントアウトして、メイン処理だけをシンボリック実行の分析対象とすることも考えられるが、メイン処理の前提としてのチェック処理を無視することになる。このため、メイン処理が実行されないテストケースが除外されることになり、生成されるテストデータが不十分である。

また、チェック処理をコメントアウトし、入力チェックのパス条件をシンボリック実行の事前条件と指定することも考えられる。しかし、入力チェックの前にメイン処理があるようなプログラムでは、入力チェックのパス条件をプログラムの事前条件とすると、プログラムのロジックが変わってしまい、適切にテストケースとテストデータを生成することができない。

１つの側面では、テストケースの抽出数を削減することができるテストケース生成プログラム、テストケース生成方法およびテストケース生成装置を提供することを目的とする。

テストケース生成プログラムは、入力データが所定条件を満たすことを判定するチェック処理を含んだ対象プログラムを、当該チェック処理を除外した対象プログラムに変換する処理をコンピュータに実行させる。テストケース生成プログラムは、変換された対象プログラムに対してシンボリック実行が行われる際に、所定の命令において所定のチェック条件をパス条件に追加するよう制御する処理をコンピュータに実行させる。

一実施形態によれば、テストケースの抽出数を削減することができる。

図１は、実施例１に係るシステムの全体構成例を示す図である。 図２は、実施例１に係るテストケース生成装置の機能構成を示す機能ブロック図である。 図３は、入力情報ＤＢに記憶される情報の例を示す図である。 図４は、入力情報ＤＢに記憶される情報の別例を示す図である。 図５は、チェック仕様分析の例を説明する図である。 図６は、チェック条件生成の例を説明する図である。 図７は、プログラム変換の例を説明する図である。 図８は、失敗時のパス出力を説明する図である。 図９は、成功時のパス出力を説明する図である。 図１０は、テストケース出力を説明する図である。 図１１は、全体的な処理の流れを説明するフローチャートである。 図１２は、チェック仕様分析およびチェック条件生成の処理の流れを説明するフローチャートである。 図１３は、プログラム変換処理の流れを説明するフローチャートである。 図１４は、チェック条件追加処理の流れを説明するフローチャートである。 図１５は、テストケース出力処理の流れを説明するフローチャートである。 図１６は、チェック条件が複数ある場合の例を説明する図である。 図１７は、ハードウェア構成例を説明する図である。

以下に、本願の開示するテストケース生成プログラム、テストケース生成方法およびテストケース生成装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、テストケース生成装置１０は、シンボリック実行を実行してテストケースを生成するサーバやパーソナルコンピュータの一例である。

このテストケース生成装置１０は、テストケース生成対象のプログラム、プログラムにおいて入力データが所定条件を満たすことを判定するチェック処理の仕様であるチェック仕様、チェック処理の該当箇所を示すチェック部分情報を受け付ける。そして、テストケース生成装置１０は、これらの入力情報を用いて、テストケースを生成する。なお、本実施例では、ＣＯＢＯＬプログラムを例にして説明するが、これに限定されるものではなく、Ｃ言語など他のプログラムでも同様に実行できる。

具体的には、テストケース生成装置１０は、入力データが所定条件を満たすことを判定するチェック処理を含んだ対象プログラムを、当該チェック処理を除外した対象プログラムに変換する。そして、テストケース生成装置１０は、変換された対象プログラムに対してシンボリック実行が行われる際に、所定の命令において所定のチェック条件をパス条件に追加するよう制御する。

つまり、テストケース生成装置１０は、プログラムを入力チェックの条件分岐が除外された成功用と失敗用とに変換し、入力チェックの成功条件と失敗条件をパス条件に追加しながらシンボリック実行する。この結果、テストケース生成装置１０は、実行結果として得るテストケース数を削減できる。

［機能構成］
図２は、実施例１に係るテストケース生成装置の機能構成を示す機能ブロック図である。図２に示すように、テストケース生成装置１０は、入力情報ＤＢ１１、テストケースＤＢ１２、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７を有する。また、テストケース生成装置１０は、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０、テストケース出力部２１を有する。

なお、入力情報ＤＢ１１、テストケースＤＢ１２は、メモリやハードディスクなどの記憶装置に記憶されるデータベースである。入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０、テストケース出力部２１は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。また、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７は、シンボリック実行を行う前の前処理を実行する処理部である。

入力情報ＤＢ１１は、テストケース生成対象のプログラム、チェック仕様、チェック部分情報を記憶するデータベースである。ここで記憶される情報は、例えば管理者等が格納してもよく、ＣＡＳＥ（Computer Aided Software Engineering）ツールなどで生成される情報を格納してもよい。ＣＡＳＥツールとは、設計情報からプログラム等のソフトウェア製品を自動生成する機能を備えるものである。また、入力情報ＤＢ１１は、上記各情報をまとめた１つの情報で記憶することもでき、各情報を記憶することもできる。

図３は、入力情報ＤＢに記憶される情報の例を示す図である。図３の例は、テストケース生成対象のプログラムに各情報をまとめて記載した例である。図３に示すプログラムは、２個のＩＦ文が記述され、チェック処理とメイン処理があるプログラムである。

チェック処理は、３９行目から４５行目の入力チェックSECTIONであり、入力の３文字がアルファベットの大文字であること、すなわち、‘Ａ’から‘Ｚ’の間であることをチェックする。一方、メイン処理は、２３行目から２８行目のメイン処理SECTIONであり、チェック処理を通過したアルファベット大文字３文字の入力が、‘ＡＢＣ’’と等しいかを判定し、その結果を出力する。実行パスでは、まず、１５行目でチェック処理が呼び出され、次いで、１６行目のＩＦ文でチェックの成否が判定され、成功の場合に１７行目でメイン処理が呼び出される。

また、図３に示すプログラムには、コメントを利用して、チェック仕様とチェック処理部分を示す印が記述されている。具体的には、１５行目から１８行目がチェック仕様情報であり、１９行目から２１行目がチェック処理部分である。チェック仕様情報には、どのようなチェックなのかを記述する「チェック種別」、チェック種別の具体的なチェック条件を記述する「チェック条件」、チェック対象の変数を特定できるようにする「チェック対象」、チェック失敗の場合に実行される処理内容を記述する「チェック失敗の動作」が記述される。また、１９行目の“$CHECKSTART”がチェック処理の開始を意味し、２１行目の“$CHECKEND”がチェック処理の終了を意味する。

また、入力情報ＤＢ１１は、各情報を別々に記憶することもできる。図４は、入力情報ＤＢに記憶される情報の別例を示す図である。図４の例は、テストケース生成対象のプログラムと、チェック仕様およびチェック処理部分が別々に記憶される例である。

図４の（ａ）は、テストケース生成対象のプログラムであり、図４の（ｂ）がチェック仕様およびチェック処理部分を記述したテーブルの例である。図３と図４は同じ内容を示している。具体的には、図４の（ｂ）に示す「開始行」−「終了行」が図３における入力チェック処理を実行する２０行目に該当する。また、図４の（ｂ）に示す「ＣＨＥＣＫ」が図３の１５行目に該当し、「ＩＴＥＭ」が図３の１６行目に該当し、「ＣＯＮＤ」が図３の１７行目に該当し、「ＥＲＲＯＲ」が図３の１８行目に該当する。

テストケースＤＢ１２は、シンボリック実行によって生成されたテストケースを記憶するデータベースである。ここで記憶される情報は、入力チェックの分岐を通過する各パス条件が記憶される。また、ここで記憶される情報は、後述するテストケース出力部２１に記憶されるので、詳細は、後述する。

入力部１３は、前処理において、テストケース生成対象のプログラムとチェック仕様とチェック処理部分の情報を取得する処理部である。具体的には、入力部１３は、例えばキーボードによる入力等によりシンボリック実行の開始指示を受け付けると、入力情報ＤＢ１１に記憶される情報を読み込んで、チェック仕様分析部１４とプログラム変換部１６に出力する。

チェック仕様分析部１４は、チェック仕様情報を分析して、チェック仕様の内容を取得する処理部である。具体的には、チェック仕様分析部１４は、入力部１３から入力されたチェック仕様情報やプログラムなどから、チェック種別、チェック条件、チェック対象、チェック失敗の動作を抽出する。

図５は、チェック仕様分析の例を説明する図である。図５に示すように、チェック仕様分析部１４は、１５行目の「$CHECKTYPE文字種」の記述からチェック種別が文字種チェックであることを特定する。チェック仕様分析部１４は、対象プログラムの１６行目の「$ITEM入力OF引数」の記述からチェック対象変数が「入力OF引数」であることを特定する。チェック仕様分析部１４は、１７行目の「$COND英字大文字」の記述から、チェック条件が「英字大文字」であることを特定する。チェック仕様分析部１４は、１８行目の「$ERRORチェック結果＝１」の記述からチェック失敗の場合に、変数「チェック結果」に数値１が代入されることを特定する。さらに、チェック仕様分析部１４は、５行目および６行目の記述から、入力が外部から与えられるものであり、３ケタの文字列（Ｘ（３））であることを特定する。

そして、チェック仕様分析部１４は、図５に示すように、「行番号、項目、型、チェック種別（文字種、最小値、最大値、列挙値）、エラー」を有する情報を生成する。具体的には、チェック仕様分析部１４は、チェック仕様情報の開始が１５行目であることから、「行番号」に「１５」を設定する。また、チェック仕様分析部１４は、ITEMに引数の入力が記述されていることから、「項目」に「入力」を設定し、６行目において入力として「Ｘ（３）」が記述されていることから、「型」に「Ｘ（３）」を設定する。

さらに、チェック仕様分析部１４は、CONDに英字大文字が記述されていることから、「チェック種別（文字種）」に「英字大文字」を設定する。なお、他のチェック種別については、プログラムのチェック処理に記述されていないので、空白のままとする。また、チェック仕様分析部１４は、変数「チェック結果」に数値１を代入することが記述されているので、「エラー」に「チェック結果＝１」を設定する。その後、チェック仕様分析部１４は、生成した分析結果をチェック条件生成部１５に出力する。

チェック条件生成部１５は、プログラムとチェック処理の仕様とに基づいて、チェック処理が成功する成功条件とチェック処理が失敗する失敗条件とを生成する処理部である。具体的には、チェック条件生成部１５は、チェック仕様分析部１４から分析結果が入力されると、分析結果の「型」および「チェック種別」から、「型」が成功する条件と失敗する条件を生成する。

図６は、チェック条件生成の例を説明する図である。図６の例では、チェック条件生成部１５は、分析結果の「型」が「Ｘ（３）」であり、チェック種別が文字種「英字大文字」であることから、入力された３つの文字からなる文字列がすべて大文字である条件を成功条件、入力された３つの文字からなる文字列のいずれかが大文字ではない条件を失敗条件とする。つまり、チェック条件生成部１５は、入力文字列がすべて大文字である条件を成功条件、入力文字列が大文字ではない条件を失敗条件とする。

具体的には、図６に示すように、チェック条件生成部１５は、「Ｎｏ、行番号、成否、チェック条件」を有する情報を生成して、プログラム変換部１６とチェック条件制御部１７に出力する。

ここで「Ｎｏ．」は、入力されたチェック仕様のＮｏ．と関連付けられるＮｏ．が設定される。「行番号」は、入力されたチェック仕様の行番号が設定される。「成否」は、成功条件であれば「成功」、失敗条件であれば「失敗」が設定される。「チェック条件」は、成功条件または失敗条件が設定される。

図６の例では、チェック条件生成部１５は、上記条件を満たす成功条件として、「（'A‘＜＝入力（１：１）AND入力（１：１）＜＝’Z‘）AND（’A‘＜＝入力（２：１）AND入力（２：１）＜＝’Z‘）AND（’A‘＜＝入力（３：１）AND入力（３：１）＜＝’Z‘）」を生成する。また、チェック条件生成部１５は、上記条件を満たす失敗条件として、ＮＯＴ成功条件を生成する。つまり、チェック条件生成部１５は、「ＮＯＴ（（'A‘＜＝入力（１：１）AND入力（１：１）＜＝’Z‘）AND（’A‘＜＝入力（２：１）AND入力（２：１）＜＝’Z‘）AND（’A‘＜＝入力（３：１）AND入力（３：１）＜＝’Z‘））」を生成する。

プログラム変換部１６は、入力データが所定条件を満たすことを判定するチェック処理を含んだプログラムを、当該チェック処理を除外したプログラムに変換する処理部である。具体的には、プログラム変換部１６は、対象のプログラムから、チェック処理が成功する成功用のプログラムと、チェック処理が失敗する失敗用のプログラムとを複製して、チェック条件制御部１７に出力する。

図７は、プログラム変換の例を説明する図である。図７に示すように、プログラム変換部１６は、入力部１３が読み込んだプログラムを、チェック処理を実行対象外に設定し、チェック処理が成功して後続の処理が実行される命令文を追加した成功用のプログラムに変換する。例えば、プログラム変換部１６は、プログラムのチェック仕様情報の開始でありコメントアウトされている１５行目を命令「ＣＯＮＴＩＮＵＥ」に書き換える。さらに、プログラム変換部１６は、１９行目にチェック処理の開始の印、２１行目にチェック処理の終了の印があるので、それらの間の２０行目をコメントアウトして処理対象から除外する。このようにして、プログラム変換部１６は、成功用のプログラムを生成する。

また、プログラム変換部１６は、入力部１３が読み込んだプログラムを、チェック処理を実行対象外に設定し、チェック処理が失敗した際に実行される命令文を追加した失敗用のプログラムに変換する。例えば、プログラム変換部１６は、プログラムのチェック仕様情報の開始でありコメントアウトされている１５行目を命令文「ＭＯＶＥ １ ＴＯ チェック結果」に書き換える。さらに、プログラム変換部１６は、１９行目にチェック処理の開始の印、２１行目にチェック処理の終了の印があるので、それらの間の２０行目をコメントアウトして処理対象から除外する。このようにして、プログラム変換部１６は、失敗用のプログラムを生成する。

チェック条件制御部１７は、変換されたプログラムに対してシンボリック実行が行われる際に、所定の命令において所定のチェック条件をパス条件に追加するよう制御する処理部である。具体的には、チェック条件制御部１７は、成功用のプログラムに対してシンボリック実行が行われる際に、成功条件をパス条件に追加するよう制御し、失敗用のプログラムに対してシンボリック実行が行われる際に、失敗条件をパス条件に追加するよう制御する。

つまり、チェック条件制御部１７は、変換後プログラムと対応するチェック条件を管理してシンボリック実行で実行される命令文を監視して、規定の命令文で規定のチェック条件をパス条件に追加する。また、チェック条件制御部１７は、プログラム変換部１６から入力された成功用のプログラムおよび失敗用のプログラムをシンボリック実行入力部１８に出力する。

シンボリック実行入力部１８は、チェック条件制御部１７から、シンボリック実行の対象として成功用のプログラムおよび失敗用のプログラムを受け付けて、シンボリック実行制御部１９に出力する処理部である。

シンボリック実行制御部１９は、プログラムの外部変数にシンボル値を設定し、シンボル値のままプログラム実行をエミュレートしてパスを模擬的に実行する処理部である。ここでは、シンボリック実行制御部１９は、シンボリック実行入力部１８から入力される成功用のプログラムおよび失敗用のプログラムそれぞれについて、シンボリック実行を実行して、その結果をシンボリック実行出力部２０に出力する。

シンボリック実行出力部２０は、実行可能なパスとパス条件を、テストケース出力部２１に出力する処理部である。テストケース出力部２１は、シンボリック実行出力部２０から出力されたパスとパス条件をテストケースとして、テストケースＤＢ１２に格納する処理部である。なお、１組のパスとパス条件が１個のテストケースに該当する。

ここで、図８と図９を用いて、シンボリック実行時のパス条件の出力例を説明する。図８は、失敗時のパス出力を説明する図であり、図９は、成功時のパス出力を説明する図である。

図８に示すように、チェック条件制御部１７は、シンボリック実行制御部１９によって規定の実行順にしたがって命令文の実行がエミュレートされるのを監視し、監視対象の行番号「１５」が実行されると、行番号「１５」に対応する失敗用のチェック条件を抽出する。

具体的には、シンボリック実行出力部２０が、チェック条件制御部１７の監視の元で失敗用のプログラムをシンボリック実行すると、１５行目において書き換えられた命令文「ＭＯＶＥ １ ＴＯ チェック結果」によって、「チェック結果」項目に１が設定される。同時に、チェック条件制御部１７は、１５行目の命令文の実行時に、チェック条件生成部１５によって生成されたチェック失敗条件をパス条件に追加する。

引き続き、シンボリック実行出力部２０によってシンボリック実行が行われると、次いで、２３行目のIF文の分岐条件がFalseでELSEが実行され、「チェック失敗」セクションを実行して終了するパスが１個抽出される。この実行パスから、チェック失敗の１個のテストケースが生成される。

つまり、チェック条件制御部１７は、「ＮＯＴ（（'A‘＜＝入力（１：１）AND入力（１：１）＜＝’Z‘）AND（’A‘＜＝入力（２：１）AND入力（２：１）＜＝’Z‘）AND（’A‘＜＝入力（３：１）AND入力（３：１）＜＝’Z‘））」を抽出する。ここで、シンボリック実行出力部２０は、チェック処理が失敗する場合のプログラムであり、これ以上の分岐がないことから、上記チェック失敗条件を満たすテストケースを出力する。

また、図９に示すように、チェック条件制御部１７は、シンボリック実行制御部１９によって規定の実行順にしたがって命令文の実行がエミュレートされるのを監視し、監視対象の行番号「１５」が実行されると、行番号「１５」に対応する成功用のチェック条件を抽出する。

具体的には、シンボリック実行出力部２０が、チェック条件制御部１７の監視の元で成功用プログラムをシンボリック実行すると、１５行目のCONTINUE文でチェック成功の条件がパス条件に追加される。次いで、２３行目のIF文の分岐条件がTrueでTHENが実行される。さらに、メイン処理内の３０行目のIF文の条件分岐は、真偽とも充足可能であるため２つのパスが抽出され、２つのテストケースが生成される。

つまり、チェック条件制御部１７は、「（'A‘＜＝入力（１：１）AND入力（１：１）＜＝’Z‘）AND（’A‘＜＝入力（２：１）AND入力（２：１）＜＝’Z‘）AND（’A‘＜＝入力（３：１）AND入力（３：１）＜＝’Z‘）」を抽出する。ここで、シンボリック実行出力部２０は、メイン処理の分岐があることから「（チェック成功条件）AND（３０行目IF文条件がTrue）」を満たすテストケースと、「（チェック成功条件）AND（３０行目IF文条件のNotがTrue）」を満たすテストケースとを出力する。

次に、図１０を用いてテストケースの出力を説明する。図１０は、テストケース出力を説明する図である。図１０に示すように、テストケース出力部２１は、失敗用のプログラムに対するシンボリック実行に際して、入力１に記載される１つのチェック条件をシンボリック実行出力部２０から受け付ける。また、テストケース出力部２１は、成功用のプログラムに対するシンボリック実行に際して、入力２に記載される２つのチェック条件をシンボリック実行出力部２０から受け付ける。そして、テストケース出力部２１は、これらのチェック条件をマージして、テストケースＤＢ１２に格納する。

［処理の流れ］
次に、上述した各処理部が実行する処理について説明する。なお、シンボリック実行は、一般的なシンボリック実行と同様の処理なので、詳細な説明は省略する。

（全体的な処理の流れ）
図１１は、全体的な処理の流れを説明するフローチャートである。図１１に示すように、テストケース生成装置１０は、入力チェック仕様とプログラム部分の対応関係を入力情報ＤＢ１１から読み込む（Ｓ１０１）。

続いて、テストケース生成装置１０は、プログラムと関連付けられたチェック仕様情報から入力チェック（チェック処理）の成功と失敗のパス条件を生成する（Ｓ１０２）。そして、テストケース生成装置１０は、プログラムと関連付けられたチェック処理部分の印（コメント）を用いて、プログラムを入力チェックの成功用と失敗用とに変換する（Ｓ１０３）。

続いて、テストケース生成装置１０は、成功用と失敗用とのプログラムそれぞれについてシンボリック実行を行い、特定の命令文に到達したら、入力チェックのパス条件を付加する（Ｓ１０４）。その後、テストケース生成装置１０は、成功用と失敗用のテストケースを集計して、テスト対象プログラムのテストケースとする（Ｓ１０５）。

（チェック仕様分析、チェック条件生成）
図１２は、チェック仕様分析およびチェック条件生成の処理の流れを説明するフローチャートである。図１２に示すように、チェック仕様分析部１４は、チェック仕様が記述されたプログラム等を取得する（Ｓ２０１）。なお、入力は、コメントにチェック仕様が記述されたプログラムや表形式にチェック仕様が記述されたファイルなどである。

続いて、チェック仕様分析部１４は、チェック仕様からチェック仕様情報を抽出して（Ｓ２０２）、抽出したチェック仕様情報をチェック条件生成部１５に出力する（Ｓ２０３）。例えば、チェック仕様分析部１４は、チェック処理の行番号、対象となる項目、項目の型、チェック種別、チェック条件、エラー時の動作の情報を抽出する。

その後、チェック条件生成部１５は、チェック仕様分析部１４からチェック仕様情報を取得する（Ｓ２０４）。続いて、チェック条件生成部１５は、チェック仕様情報に基づき、チェック種別に応じて成功と失敗のチェック条件を生成し（Ｓ２０５）、生成した成功のチェック条件と失敗のチェック条件を、プログラム変換部１６とチェック条件制御部１７に出力する（Ｓ２０６）。

（プログラム変換）
図１３は、プログラム変換処理の流れを説明するフローチャートである。図１３に示すように、プログラム変換部１６は、プログラムとチェック仕様情報を入力部１３等から取得し（Ｓ３０１）、プログラム内に未処理のチェック処理があるか否かを判定する（Ｓ３０２）。

そして、プログラム変換部１６は、未処理のチェック処理がある場合（Ｓ３０２：Ｙｅｓ）、未処理のチェック処理を１つ選択してプログラムを複製する（Ｓ３０３）。続いて、プログラム変換部１６は、当該チェック処理の行番号に、エラー（失敗）の情報に基づいて、当該チェックの失敗の命令文に書き換える（Ｓ３０４）。

そして、プログラム変換部１６は、当該チェック処理以外のチェック処理の行番号に、チェック成功を示す命令文「CONTINUE」に書き換え（Ｓ３０５）、全てのチェック処理のプログラム部分をコメントアウト（除外）する（Ｓ３０６）。その後、プログラム変換部１６は、変換されたプログラムを当該チェック処理の失敗を関連付けて、メモリ等に記録する（Ｓ３０７）。

一方、プログラム変換部１６は、未処理のチェック処理がない場合（Ｓ３０２：Ｎｏ）、プログラムを複製する（Ｓ３０８）。続いて、プログラム変換部１６は、全てのチェック処理の行番号に、チェック成功を示す命令文「CONTINUE」に書き換える（Ｓ３０９）。

その後、プログラム変換部１６は、変換されたプログラムを全チェック処理の成功を関連付けて、メモリ等に記録する（Ｓ３１０）。

（チェック条件追加）
図１４は、チェック条件追加処理の流れを説明するフローチャートである。図１４に示すように、チェック条件制御部１７は、変換済プログラムとチェック条件を取得し（Ｓ４０１）、プログラム内に未処理のチェック処理があるか否かを判定する（Ｓ４０２）。

続いて、チェック条件制御部１７は、未処理のチェック処理がある場合（Ｓ４０２：Ｙｅｓ）、未処理のプログラムに対応するチェック条件を取得し、当該プログラムを対象としてシンボリック実行の分析を開始する（Ｓ４０３）。ここで、シンボリック実行制御部１９は、該当プログラムのシンボリック実行を開始する。

そして、シンボリック実行制御部１９は、プログラム終了の命令文ではない場合（Ｓ４０４：Ｎｏ）、命令文の処理をエミュレートする（Ｓ４０５）。続いて、チェック条件制御部１７は、チェック条件の行番号の命令文である場合（Ｓ４０６：Ｙｅｓ）、チェック条件の行番号の命令文で、規定チェック条件をパス条件に追加する（Ｓ４０７）。

その後、シンボリック実行制御部１９は、次の命令文を取得し（Ｓ４０８）、Ｓ４０４以降を繰り返す。一方、チェック条件の行番号の命令文ではない場合（Ｓ４０６：Ｎｏ）、Ｓ４０７を実行することなく、Ｓ４０８が実行される。

また、Ｓ４０４において、シンボリック実行出力部２０は、プログラム終了の命令文である場合（Ｓ４０４：Ｙｅｓ）、テストケースを記録する（Ｓ４０９）。また、Ｓ４０２において、未処理のチェック処理がない場合（Ｓ４０２：Ｎｏ）、シンボリック実行出力部２０は、生成したテストケースをプログラムと関連付けて出力する（Ｓ４１０）。

（テストケース出力）
図１５は、テストケース出力処理の流れを説明するフローチャートである。図１５に示すように、テストケース出力部２１は、変換後プログラム毎のテストケースリスト（パス条件）を、シンボリック実行出力部２０から取得する（Ｓ５０１）。

続いて、テストケース出力部２１は、未処理のテストケースリストがある場合（Ｓ５０２：Ｙｅｓ）、選択したテストケースリストから順にパス条件を取り出す（Ｓ５０３）。そして、テストケース出力部２１は、未処理のパス条件がある場合（Ｓ５０４：Ｙｅｓ）、集計テストケースのパス条件と一致するか否かを判定する（Ｓ５０５）。

その後、テストケース出力部２１は、集計テストケースのパス条件と一致しない場合（Ｓ５０５：Ｙｅｓ）、当該パス条件のテストケースを集計テストケースに追加し（Ｓ５０６）、Ｓ５０４以降を繰り返す。また、テストケース出力部２１は、集計テストケースのパス条件と一致する場合（Ｓ５０５：Ｎｏ）、Ｓ５０６を実行することなく、Ｓ５０４以降を繰り返す。

一方、Ｓ５０４において、テストケース出力部２１は、未処理のパス条件がない場合（Ｓ５０４：Ｎｏ）、Ｓ５０２以降を繰り返す。また、Ｓ５０２において、テストケース出力部２１は、未処理のテストケースリストがない場合（Ｓ５０２：Ｎｏ）、集計テストケースをテストケースＤＢ１２に出力する（Ｓ５０７）。

このフローにおいて集計テストケースのパス条件と一致しないかを判定している部分は、パス条件が同一、つまり、同一のテストケースが重複しないように集計する処理である。テストケース生成装置１０は、複数の変換後プログラムをチェック条件制御部１７の制御のもとでシンボリック実行してテストケースを抽出する。ここで、チェック処理（入力チェック処理）の前に入力チェック以外の別の処理が存在するプログラムが入力され、かつ、別の処理に条件分岐が存在する場合、テストケース出力部２１に入力されるテストケースのパス条件には重複が生じるので、本処理によって重複を除去している。

［効果］
実施例１によれば、テストケース生成装置１０は、入力チェック処理とメイン処理を含むようなプログラムに対して、プログラム全体のロジック内容は変えずに入力チェック処理を除外し、シンボリック実行でのパス追跡時の適切な命令文で、入力チェックのパス条件を追加することができる。また、テストケース生成装置１０は、入力チェックを過剰にテストするようなテストケースを除外して、テストケースを生成することができる。この結果、テストケース生成装置１０は、テストケース個数を削減し、さらに、テストケースの生成時間を短縮することができる。

［チェック条件が複数］
テストケース生成装置１０は、チェック条件が複数あった場合でも同様に処理することができる。図１６は、チェック条件が複数ある場合の例を説明する図である。図１６の上図には一般的なチェック条件に関する情報を例示する。

図１６に示すように、チェック種別が「文字種」の場合、チェック条件としては、英字、英数字、数字などである。チェック種別が「値範囲」の場合、チェック条件としては、数値の最小値や最大値、指定文字集合の範囲などがある。チェック種別が「列挙値」の場合、チェック条件としては、例えば、「１、１０、２０」などのように、複数の数値を具体的に列挙する列挙値の指定などがある。チェック種別が「桁範囲」の場合、チェック条件としては、文字列の最小桁数や最大桁数などがある。

そして、入力部１３は、例えば表形式のチェック仕様情報を読み込む。図１６の例では、Ｎｏ＝１は、プログラムの１００行目から１１０行目がチェック仕様情報であり、チェック種別が値範囲で、チェック対象が項目１、チェック条件が最小値“０＜＝”（０以上）だけが指定されている例である。Ｎｏ＝２は、プログラムの２００行目から２２０行目がチェック仕様情報であり、チェック種別が値範囲で、チェック対象が項目２、チェック条件が最小値“０＜＝”（０以上）と最大値“＜１００”（１００未満）の両方が指定されている例である。Ｎｏ＝３は、プログラムの３００行目から３３０行目がチェック仕様情報であり、チェック種別が列挙値で、チェック対象が項目３、チェック条件が列挙値｛‘A’，‘B’，‘C’｝に含まれる例である。なお、いずれもエラー処理は、チェック結果に１を代入する「チェック結果＝１」である。

続いて、チェック仕様分析部１４は、上記チェック仕様情報を分析して、チェック種別、チェック条件、チェック対象、チェック失敗の動作を抽出する。Ｎｏ＝１については、行番号＝１００、項目＝項目１、型＝９（３）、チェック種別として最小値が０以上、エラー処理として「チェック結果＝１」が抽出される。Ｎｏ＝２については、行番号＝２００、項目＝項目２、型＝９（３）、チェック種別として最小値が０以上かつ最大値が１００未満、エラー処理として「チェック結果＝１」が抽出される。Ｎｏ＝３については、行番号＝３００、項目＝項目３、型＝Ｘ（２）、チェック種別（列挙値）＝「Ａ、Ｂ、Ｃ」、エラー処理として「チェック結果＝１」が抽出される。なお、型＝９（３）は、３ケタ位の数字を意味する。

そして、チェック条件生成部１５は、成功条件と失敗条件を生成する。なお、失敗条件は、ＮＯＴ成功条件である。上記例では、チェック条件生成部１５は、対象プログラムについて、抽出された行番号ごとに成功条件と失敗条件を生成するので、合計６個の条件を生成する。

一例を挙げると、行番号１００については、成功条件として「０＜＝項目１」が生成され、失敗条件として「ＮＯＴ（０＜＝項目１）」が生成される。また、行番号２００については、成功条件として「（０＜＝項目２）ＡＮＤ（項目２＜１００）」が生成され、失敗条件として「ＮＯＴ（（０＜＝項目２）ＡＮＤ（項目２＜１００））」が生成される。

その後、プログラム変換部１６は、条件ごとに、条件を満たすプログラムを生成する。例えば、プログラム変換部１６は、Ｎｏ．１−１の成功条件を満たすプログラム、Ｎｏ．１−２の失敗条件を満たすプログラム、Ｎｏ．２−１の成功条件を満たすプログラムなどを生成する。

そして、チェック条件制御部１７は、生成された各プログラムに対してシンボリック実行がされる際に、命令を監視し、該当行番号の命令が実行されたときに、該当するチェック条件をパス条件として抽出する。例えば、チェック条件制御部１７は、項目１の成功用プログラムでは、１００行目が実行されたときに「０＜＝項目１」を抽出する。このように、テストケース生成装置１０は、チェック処理のチェック条件が複数あり、分岐が複雑な場合でも、各変換後プログラムと対応するチェック条件を管理してシンボリック実行で実行される命令文を監視して、規定の命令文で規定のチェック条件をパス条件に追加することができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［生成装置と実行装置］
上記実施例では、テストケース生成装置１０は、テストケースを生成する処理部とシンボリック実行を実行する処理部の両方を有する例を説明したが、これに限定されるものではない。例えば、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７、テストケース出力部２１を生成装置と、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０を有するシンボリック実行装置とに分割することもできる。

［システム］
また、図示した装置の各構成は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の単位で分散または統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

なお、本実施例で説明したテストケース生成装置１０は、テストケース生成プログラムを読み込んで実行することで、図２等で説明した処理と同様の機能を実行することができる。例えば、テストケース生成装置１０は、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０、テストケース出力部２１と同様の機能を有するプログラムをメモリに展開する。そして、テストケース生成装置１０は、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０、テストケース出力部２１と同様の処理を実行するプロセスを実行することで、上記実施例と同様の処理を実行することができる。

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

［ハードウェア構成］
上記テストケース生成装置１０は、例えば、次のようなハードウェア構成により実現することができる。図１７は、ハードウェア構成例を説明する図である。図１７に示すように、テストケース生成装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。

プロセッサ１０ｄの一例としては、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）等が挙げられる。また、メモリ１０ｃの一例としては、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。

そして、テストケース生成装置１０で行われる各種処理機能は、不揮発性記憶媒体などの各種メモリに格納されたプログラムを制御装置が備えるプロセッサで実行することによって実現してもよい。すなわち、入力部１３、チェック仕様分析部１４、チェック条件生成部１５、プログラム変換部１６、チェック条件制御部１７、シンボリック実行入力部１８、シンボリック実行制御部１９、シンボリック実行出力部２０、テストケース出力部２１によって実行される各処理に対応するプログラムがメモリ１０ｃに記録され、各プログラムがプロセッサ１０ｄで実行されてもよい。

１０ テストケース生成装置
１１ 入力情報ＤＢ
１２ テストケースＤＢ
１３ 入力部
１４ チェック仕様分析部
１５ チェック条件生成部
１６ プログラム変換部
１７ チェック条件制御部
１８ シンボリック実行入力部
１９ シンボリック実行制御部
２０ シンボリック実行出力部
２１ テストケース出力部

Claims (6)

1. コンピュータに、
   入力データが所定条件を満たすことを判定するチェック処理を含んだ対象プログラムを、当該チェック処理を除外した対象プログラムに変換し、
   前記対象プログラムと前記チェック処理の仕様とに基づいて、前記チェック処理が成功する成功条件と前記チェック処理が失敗する失敗条件とを生成し、
   変換された対象プログラムに対してシンボリック実行が行われる際に、前記成功条件と前記失敗条件とを、チェック条件が記述されていた行番号の命令文に追加する
   処理を実行させることを特徴とするテストケース生成プログラム。
2. 前記変換する処理は、前記対象プログラムを、前記チェック処理が成功する第１の対象プログラムと、前記チェック処理が失敗する第２の対象プログラムとに変換し、
   前記追加する処理は、前記第１の対象プログラムに対してシンボリック実行が行われる際に、前記成功条件をパス条件に追加するよう制御し、前記第２の対象プログラムに対してシンボリック実行が行われる際に、前記失敗条件をパス条件に追加するよう制御する
   ことを特徴とする請求項１に記載のテストケース生成プログラム。
3. 前記生成する処理は、前記成功条件の否定文を前記失敗条件として出力することを特徴とする請求項２に記載のテストケース生成プログラム。
4. 前記変換する処理は、前記対象プログラムに対して前記チェック処理を実行対象外に設定し、前記チェック処理が成功して後続の処理が実行される命令文を追加した前記第１の対象プログラムを生成し、前記チェック処理が失敗した際に実行される命令文を追加した前記第２の対象プログラムを生成することを特徴とする請求項２に記載のテストケース生成プログラム。
5. コンピュータが、
   入力データが所定条件を満たすことを判定するチェック処理を含んだ対象プログラムを、当該チェック処理を除外した対象プログラムに変換し、
   前記対象プログラムと前記チェック処理の仕様とに基づいて、前記チェック処理が成功する成功条件と前記チェック処理が失敗する失敗条件とを生成し、
   変換された対象プログラムに対してシンボリック実行が行われる際に、前記成功条件と前記失敗条件とを、チェック条件が記述されていた行番号の命令文に追加する
   処理を含むことを特徴とするテストケース生成方法。
6. 入力データが所定条件を満たすことを判定するチェック処理を含んだ対象プログラムを、当該チェック処理を除外した対象プログラムに変換する変換部と、
   前記対象プログラムと前記チェック処理の仕様とに基づいて、前記チェック処理が成功する成功条件と前記チェック処理が失敗する失敗条件とを生成する生成部と、
   前記変換部によって変換された対象プログラムに対してシンボリック実行が行われる際に、前記成功条件と前記失敗条件とを、チェック条件が記述されていた行番号の命令文に追加する追加制御部と
   を有することを特徴とするテストケース生成装置。

Images