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

Abstract

【課題】プログラムのテストデータの生成技術に関し、オブジェクト型変数を用いたプログラムに適したテストデータを生成する。
【解決手段】テストケース生成方法は、テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含むシンボル変数を用いたシンボリック実行により第１のテストケースを生成し、第１のテストケースのパス条件から制御変数が満たすべき条件を省き、オブジェクト型変数が状態として満たすべき条件を加えた第２のテストケースを生成し、同義である第２のテストケースの省いた第３のテストケースを抽出する。
【選択図】図４４

Description

本技術は、プログラムのテストデータの生成技術に関する。

プログラムをテストするために準備されるテストケースには、テスト対象のプログラムへ入力するデータ（テスト入力という。）と期待結果が含まれる。期待結果は、テスト対象のプログラムの仕様に基づいて求められる。例えば、期待結果は、テスト対象のプログラムの出力データの値として設定される。

テストケースの生成では、テスト中にプログラム中の命令、分岐あるいは実行パスを網羅的に実行するようにテスト入力を生成することが望まれる。つまり、コードカバレッジを高めることが課題となる。

人的な判断に基づくテスト入力の生成の他に、ランダムにテスト入力を生成する方法や所定ルール（データの範囲やデータの形式）に従ってテスト入力を生成する方法もある。しかし、これらの方法では、プログラムのコードや仕様を反映してテスト入力を生成するわけではないので、コードカバレッジが上がりにくいという問題がある。また、コードカバレッジを上げるためにテストケースを増やすと、重複するテストケースが多くなる。

ホワイトボックステストを前提とした場合に、ソースコードを静的に解析して分岐条件を抽出し、その分岐条件に基づいてテスト入力を生成する方法もある。この方法によれば、プログラムのソースコードの実際の条件に従ってテスト入力を決めることができるので、テストケースの重複は避けやすい。しかし、実際にプログラムを実行するわけではないので、テストケースの欠落が生じる。

これに対して、プログラムを実行させながらテスト入力を生成するシンボリック実行という方法がある。この方法では、プログラム中の変数に具体的な値を設定せずに、シンボル値という特殊な値を持たせたままプログラムを実行する。

ここで、クラスをテスト対象とする例を示す。図１に、テスト対象クラスの例を示す。クラス「ＴａｒｇｅｔＣｌａｓｓ」に含まれるメソッド「ｍｅｔｈｏｄ１」をテストすることを想定する。

メソッド「ｍｅｔｈｏｄ１」に入力する変数は、ｉｎｔ型の「ａ」とｉｎｔ型の「ｂ」である。いずれの入力変数も、プリミティブ型の変数である。処理コードは、「ｉｆ（ａ！＝０）」１０１の判断による分岐処理と、「ｉｆ（ａ＞５）」１０３の判断による分岐処理と、「ｉｆ（ａ！＝０）」１０５の判断による分岐処理と、「ｉｆ（ｂ＜＝０）」１０９の判断による分岐処理を含んでいる。また、処理コードは、「ｂ＝ｂ＋１；」１０７の演算処理と、「ａ＝ｂ／ａ；」１１１の演算処理を含んでいる。

図１の処理を模式化したフローを図２に示す。前半のフローは、２０１から２０７の４つのルートを含んでいる。ルート２０１は、条件「ａ＝＝０」を満たす場合に通過する。ルート２０３は、条件「ａ！＝０」と条件「ａ＞５」と条件「ａ＝＝０」を満たす場合に通過する。ルート２０５は、条件「ａ！＝０」と条件「ａ＞５」と条件「ａ！＝０」を満たす場合に通過する。ルート２０７は、条件「ａ！＝０」と条件「ａ＜＝５」と条件「ｂ＝ｂ＋１」を満たす場合に通過する。また、ルート２０７は、「ｂ＝ｂ＋１」の演算処理を含んでいる。

後半のフローは、２０９と２１１の２つのルートを含んでいる。ルート２０９は、条件「ｂ＞０」を満たす場合に通過する。ルート２１１は、条件「ｂ＜＝０」を満たす場合に通過する。また、ルート２０９は、「ａ＝ｂ／ａ」の演算処理を含んでいる。

形式的には、前半のフローの４ルートと後半のフローの２ルートを任意に組み合わせることが可能なので、全体としては８通りのルートが考えられる。この例においてテストケースを動的に生成するために、入力変数ａと入力変数ｂにシンボル値を持たせることが考えられる。

シンボリック実行を行う場合には、シンボリック実行の対象となるメソッドを呼び出すためのドライバ（シンボル実行用ドライバという。）を用意する。シンボリック実行部は、シンボル実行用ドライバを起動し、シンボル実行用ドライバを介してシンボリック実行の対象となるプログラムの処理コードを実行する。

図１に示したメソッド「ｍｅｔｈｏｄ１」を呼び出すシンボル実行用ドライバの例を、図３に示す。シンボル実行用ドライバのクラス「ＳｙｍｂｏｌｉｃＤｒｉｖｅｒ」について説明する。３０１は、シンボル変数の宣言に関するコードである。シンボル変数は、シンボル値を保持する変数である。この宣言により、ｉｎｔ型の「Ｐ１」とｉｎｔ型の「Ｐ２」がシンボル変数となる。「ｔｅｓｔＦｕｎｃ（）；」３０３は、実行開始位置を示すコードである。「ｔａｒｇｅｔ．ｍｅｔｈｏｄ１（Ｐ１， Ｐ２）；」３０５は、対象メソッドを呼び出すコードである。引数に、「Ｐ１」と「Ｐ２」を設定することにより、入力変数「ａ」には、シンボル変数「Ｐ１」が割り当てられ、入力変数「ｂ」には、シンボル変数「Ｐ２」が割り当てられる。

対象となるプログラムにシンボル変数に関する分岐処理が含まれている場合には、複数の実行パターンに分けることにより、分岐可能なパスを網羅的に実行する。そして、実行パターンを実行する際に、その実行パターンを導いた判定が成立するためにシンボル値が満たさなければならない条件（パス条件という）を生成する。例えば、分岐処理がニ分岐型の場合に、シンボル変数に関する条件式が真となる実行パターンと、シンボル変数に関する条件式が偽となる実行パターンを別に実行する。そして、条件式が真となる実行パターンを実行する際には、条件式が真となるためのパス条件を生成し、条件式が偽となる実行パターンを実行する際には、条件式が偽となるためのパス条件を生成する。また、分岐処理が多分岐型の場合に、シンボル変数に関する条件式の選択候補毎に別の実行パターンを実行する。そして、条件式が選択候補となるためのパス条件を生成する。

図４に、図１に示したメソッド「ｍｅｔｈｏｄ１」をテスト対象として、シンボリック実行により生成したテストケースの例を示す。

ケース番号１のパス条件（Ｐ１＝＝０）とパス条件（Ｐ２＞０）は、図２に示したルート２０１とルート２０９を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝０、Ｐ２＝１」が得られる。このテストケースに従って入力変数ａに０を設定し、入力変数ｂに１を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０１とルート２０９を通過することになる。

ケース番号２のパス条件（Ｐ１＝＝０）とパス条件（Ｐ２＜＝０）は、図２に示したルート２０１とルート２１１を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝０、Ｐ２＝０」が得られる。このテストケースに従って入力変数ａに０を設定し、入力変数ｂに０を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０１とルート２１１を通過することになる。

ケース番号３のパス条件（Ｐ１！＝０）とパス条件（Ｐ１＞５）とパス条件（Ｐ２＜＝０）は、図２に示したルート２０５とルート２１１を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝６、Ｐ２＝０」が得られる。このテストケースに従って入力変数ａに６を設定し、入力変数ｂに０を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０５とルート２１１を通過することになる。

ケース番号４のパス条件（Ｐ１！＝０）とパス条件（Ｐ１＞５）とパス条件（Ｐ２＞０）は、図２に示したルート２０５とルート２０９を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝６、Ｐ２＝１」が得られる。このテストケースに従って入力変数ａに６を設定し、入力変数ｂに１を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０５とルート２０９を通過することになる。

ケース番号５のパス条件（Ｐ１！＝０）とパス条件（Ｐ１＜＝５）とパス条件（Ｐ２＋１＜＝０）は、図２に示したルート２０７とルート２１１を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝１、Ｐ２＝−１」が得られる。このテストケースに従って入力変数ａに１を設定し、入力変数ｂに−１を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０７とルート２１１を通過することになる。この例では、ルート２０７の演算処理「ｂ＝ｂ＋１」の結果がその後の条件判断に反映されている。

ケース番号６のパス条件（Ｐ１！＝０）とパス条件（Ｐ１＜＝５）とパス条件（Ｐ２＋１＞０）は、図２に示したルート２０７とルート２０９を組み合わせた実行パターンにより得られる。そして、これらのパス条件を充足する値として、テスト入力「Ｐ１＝１、Ｐ２＝０」が得られる。このテストケースに従って入力変数ａに１を設定し、入力変数ｂに０を設定して、メソッド「ｍｅｔｈｏｄ１」を実行するとルート２０７とルート２０９を通過することになる。この例でも、ルート２０７の演算処理「ｂ＝ｂ＋１」の結果がその後の条件判断に反映されている。

尚、ａ！＝０の条件を満たし、かつａ＝＝０の条件を満たすａの値は存在しないので、ルート２０３に至ることはない。つまり、ルート２０３とルート２０９を組み合わせた実行パターンと、ルート２０３とルート２１１を組み合わせた実行パターンは、パス条件を充足するような値がシンボル変数に対して存在しないことになる。このような実行パターンについては、実行不可能なのでテストケースとならない。

パス条件を充足可能な場合には、ケース番号１からケース番号６のようにテストケースが生成できる。このようにして、プログラムを実行しながらテストケースを生成することによって、高いコードカバレッジが期待できる。

しかし、シンボリック実行でシンボル変数として扱えるのは、主として数値や真偽値などのプリミティブ型変数である。オブジェクト指向プログラミング言語により記述されたプログラムについては、一般にオブジェクト型変数を用いており、そのような変数をテスト入力とするプログラムに対しては、シンボリック実行によりテストケースを生成することはできない。

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

従って、本技術の目的は、一側面では、オブジェクト型変数を用いたプログラムに適したテストデータを生成することである。

本実施の形態に係るテストケース生成方法は、（Ａ）テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、制御変数に応じたオブジェクト型変数の初期化とテスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出されるテスト対象のプログラムにおける実行パターン毎に、ドライバ及びテスト対象のプログラムの実行において一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、第１のパス条件と第１のパス条件に対する一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、（Ｂ）実行パターン毎に、テスト対象のプログラムの実行において状態としてオブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、（Ｃ）実行パターン毎に、第１のテストケースに含まれる第１のパス条件から、制御変数が満たすべき条件を省き、第２のパス条件を加えた第３のパス条件を求め、第３のパス条件と一又は複数のシンボル変数の充足値とを含む第２のテストケースを生成する第２の生成処理と、（Ｄ）第３のパス条件が同義である第２のテストケースが複数ある場合に、第３のパス条件が同義である複数の第２のテストケースのうち、いずれかの第２のテストケースを省き、残った第２のテストケースを抽出する抽出処理とを含む。

オブジェクト型変数を用いたプログラムに適したテストデータを生成できるようになる。

図１は、テスト対象クラスの例を示す図である。 図２は、フローの例を示す図である。 図３は、シンボル実行用ドライバの例を示す図である。 図４は、テストケースの例を示す図である。 図５は、テスト対象クラスの例を示す図である。 図６は、ライブラリの例を示す図である。 図７は、サンプルフォームの例を示す図である。 図８は、シンボル実行用ドライバの例を示す図である。 図９は、制御変数テーブルの例を示す図である。 図１０は、テストケース生成装置のうち準備処理に係る構成例を示す図である。 図１１は、準備処理フローの例を示す図である。 図１２は、ドライバ生成処理フローの例を示す図である。 図１３は、シンボル変数宣言処理フローの例を示す図である。 図１４は、制御変数宣言処理フローの例を示す図である。 図１５は、メンバ宣言処理フローの例を示す図である。 図１６は、初期化コード処理フローの例を示す図である。 図１７は、ｎｕｌｌ化処理フローの例を示す図である。 図１８は、クラス判定処理フローの例を示す図である。 図１９は、オブジェクト型変数初期化処理フローの例を示す図である。 図２０は、オブジェクト指定命令処理フローの例を示す図である。 図２１は、プリミティブ宣言処理フローの例を示す図である。 図２２は、対象クラス初期化処理フローの例を示す図である。 図２３は、対象メソッド呼び出し処理フローの例を示す図である。 図２４は、制御変数テーブル生成処理フローの例を示す図である。 図２５は、テストケース生成装置のうちシンボリック実行処理に係る構成例を示す図である。 図２６は、パターンテーブルの例を示す図である。 図２７は、シンボル変数テーブルの例を示す図である。 図２８は、オブジェクトテーブルの例を示す図である。 図２９ａは、第１テストケースの例を示す図である。 図２９ｂは、第１テストケースの例を示す図である。 図２９ｃは、第１テストケースの例を示す図である。 図３０は、オブジェクトパス条件の例を示す図である。 図３１は、シンボリック実行処理フローの例を示す図である。 図３２は、初期化処理フローの例を示す図である。 図３３は、実行パターン処理フローの例を示す図である。 図３４は、実行パターン処理の動作例を示す図である。 図３５は、オブジェクト特定処理フローの例を示す図である。 図３６は、実行パターン処理の動作例を示す図である。 図３７は、探索処理フローの例を示す図である。 図３８は、オブジェクトパス条件生成の動作例を示す図である。 図３９は、オブジェクトパス条件生成処理フローの例を示す図である。 図４０は、オブジェクトパス条件生成の動作例を示す図である。 図４１は、メモリ状態の例を示す図である。 図４２は、メモリ状態の例を示す図である。 図４３は、テストケース生成装置のうちパス条件更新とテストケース抽出に係る構成例を示す図である。 図４４は、パス条件更新の概要を示す図である。 図４５は、第２テストケース生成処理フローの例を示す図である。 図４６ａは、第２テストケースの例を示す図である。 図４６ｂは、第２テストケースの例を示す図である。 図４６ｃは、第２テストケースの例を示す図である。 図４７は、第３テストケースの例を示す図である。 図４８は、テストケース抽出処理フローの例を示す図である。 図４９は、コンピュータの構成の例を示す図である。

図５に、テスト対象クラスの例を示す。ここでは、テスト対象のクラス「ＴａｒｇｅｔＣｌａｓｓ」に含まれるテスト対象メソッド「ｔａｒｇｅｔＭｅｔｈｏｄ２」の動作をテストすることを想定する。テスト対象メソッド「ｔａｒｇｅｔＭｅｔｈｏｄ２」は、オブジェクト型変数「ｏｂｊ１」とオブジェクト型変数「ｏｂｊ２」を入力する構成になっている。

図６に、ライブラリの例を示す。クラスＡとクラスＢとクラスＣは、上述のテスト対象のクラス「ＴａｒｇｅｔＣｌａｓｓ」で用いられる。クラスＡは、メンバ変数ａ１を保持している。クラスＢは、クラスＡを継承している。つまり、Ｂは、親クラスＡの子クラスである。クラスＢは、メンバ変数ｂ１を保持している。クラスＣも、クラスＡを継承している。つまり、Ｃも、親クラスＡの子クラスである。

クラス「ＳｙｍｂｏｌｉｃＥｘｅｃＵｔｉｌ」が保持するメソッド「ｃａｌｃＰａｔｈＣｏｎｄｉｔｉｏｎ（Ｏｂｊｅｃｔ ｏｂｊ， Ｓｔｒｉｎｇ ｎａｍｅ）」は、オブジェクト指定命令である。オブジェクト指定命令は、パス条件の計算対象となるオブジェクト型変数を指定する命令である。シンボリック実行時にオブジェクト指定命令が呼ばれると、「ｏｂｊ」が参照するインスタンスについて、この命令以後のオブジェクトパス条件を計算する。また、オブジェクト指定命令は、オブジェクトパス条件内でｏｂｊを指す変数名としてｎａｍｅを使うことも指定している。但し、通常のプログラム実行時にオブジェクト指定命令が呼ばれても、何もしない。

テストケース生成装置は、テスト対象クラスとテスト対象クラスが用いるライブラリ（例えば、クラスＡとクラスＢとクラスＣ）に基づいて、シンボル実行用ドライバを生成する。シンボル実行用ドライバは、初期設定やテスト対象の呼び出しを行うドライバである。テストケース生成装置は、シンボル実行用ドライバを生成するために、サンプルフォームを用いる。

図７に、シンボル実行用ドライバのサンプルフォームの例を示す。シンボル変数宣言エリア７０１は、シンボル変数の宣言を設定する領域である。対象クラス初期化エリア７０３は、対象クラスの初期化を設定する領域である。初期化コードエリア７０５は、パス条件の計算対象となるオブジェクト型変数を初期化するコードを設定する領域である。オブジェクト指定命令エリア７０７は、オブジェクト指定命令を設定する領域である。対象メソッドの呼び出しエリア７０９は、対象メソッド呼び出し命令を設定する領域である。

図８に、サンプルフォームを用いて生成されたシンボル実行用ドライバの例を示す。

コード８０１とコード８０３とコード８０５とコード８０７は、オブジェクト型変数Ｐ１に関するシンボル変数を宣言するコードである。尚、コード８０１とコード８０３は、制御変数の宣言であり、コード８０５とコード８０７は、メンバシンボル変数の宣言である。制御変数とメンバシンボル変数は、いずれもシンボル変数である。

コード８０９は、シンボリック実行による実行開始位置を示すコードである。コード８１１は、対象クラスの初期化を行うコードである。コード８１３は、オブジェクト型変数の宣言を行うコードである。コード８１５は、オブジェクト型変数のｎｕｌｌ判定とｎｕｌｌ値の代入を行うコードである。尚、ｅｌｓｅにおける処理は、コード８１９によって閉じている。コード８１７は、オブジェクト型変数をクラス型に応じて初期化するコードである。コード８２１は、オブジェクト型変数をパス条件算出の対象とすることを指定するオブジェクト指定命令である。コード８２３は、テスト対象であるクラスを呼び出すコードである。

また、準備段階において、テスト対象クラスに基づいて制御変数テーブルも生成される。図９に、制御変数テーブルの例を示す。制御変数は、テスト対象メソッドへ入力されるオブジェクト型変数の状態を示している。この例で、制御変数Ｐ１＿ｃｎｕｌｌは、オブジェクト型変数Ｐ１がｎｕｌｌであるか否かを示している。制御変数Ｐ１＿ｃｎｕｌｌの値がｔｒｕｅである場合には、オブジェクト型変数Ｐ１がｎｕｌｌであることを意味しており、意味式「Ｐ１＝＝ｎｕｌｌ」と同義である。制御変数Ｐ１＿ｃｎｕｌｌの値がｆａｌｓｅである場合には、オブジェクト型変数Ｐ１がｎｕｌｌでないことを意味しており、意味式「Ｐ１！＝ｎｕｌｌ」と同義である。

この例で、制御変数Ｐ１＿ｃＣｌａｓｓは、オブジェクト型変数の実際のクラス型を示している。制御変数Ｐ１＿ｃＣｌａｓｓの値が０である場合には、オブジェクト型変数Ｐ１の実際の型がクラスＡであることを意味しており、意味式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ａ」と同義である。制御変数Ｐ１＿ｃＣｌａｓｓの値が１である場合には、オブジェクト型変数Ｐ１の実際の型がクラスＢであることを意味しており、意味式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ」と同義である。制御変数Ｐ１＿ｃＣｌａｓｓの値が０又は１以外である場合には、オブジェクト型変数Ｐ１の実際の型がクラスＣであることを意味しており、意味式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｃ」と同義である。尚、変数の入力方法は、参照可能な形式であればよく、引数形式に限らない。

まず、テストケース生成装置によりシンボル実行用ドライバと制御変数テーブルを生成する準備処理について説明する。図１０に、テストケース生成装置のうち準備処理に係る構成例を示す。テストケース生成装置は、受付部１００１、対象クラス格納部１００３、ライブラリ格納部１００５、サンプルフォーム格納部１００７、ドライバ生成部１００９、ドライバ格納部１０１１、制御変数テーブル生成部１０１３、及び制御変数テーブル格納部１０１５を有している。

受付部１００１は、対象クラスとライブラリを受け付けるように構成されている。対象クラス格納部１００３は、対象クラスを格納するように構成されている。ライブラリ格納部１００５は、ライブラリを格納するように構成されている。サンプルフォーム格納部１００７は、サンプルフォームを予め格納している。ドライバ生成部１００９は、シンボル実行用ドライバを生成するように構成されている。ドライバ格納部１０１１は、シンボル実行用ドライバを格納するように構成されている。制御変数テーブル生成部１０１３は、制御変数テーブルを生成するように構成されている。制御変数テーブル格納部１０１５は、制御変数テーブルを格納するように構成されている。

図１１に、準備処理フローの例を示す。受付部１００１は、対象クラスとライブラリを受け付ける（Ｓ１１０１）。そして、ドライバ生成部１００９は、ドライバ生成処理を行う（Ｓ１１０３）。続いて、制御変数テーブル生成部１０１３は、制御変数テーブル生成処理を行う（Ｓ１１０５）。制御変数テーブル生成処理（Ｓ１１０５）については、図２４を用いて後述する。

図１２に、ドライバ生成処理フローの例を示す。ドライバ生成部１００９は、まずサンプルフォーム格納部１００７からサンプルフォームを読み出す（Ｓ１２０１）。そして、ドライバ生成部１００９は、シンボル変数宣言処理を行う（Ｓ１２０３）。

図１３に、シンボル変数宣言処理フローの例を示す。ドライバ生成部１００９は、対象メソッドの入力変数を特定する（Ｓ１３０１）。例えば、図５では、「Ａ ｏｂｊ１」と「Ａ ｏｂｊ２」が入力変数である。尚、図１の例であれば、入力変数は「ｉｎｔ ａ」と「ｉｎｔ ｂ」が入力変数である。

そして、ドライバ生成部１００９は、入力変数毎に以下の処理を繰り返す（Ｓ１３０３）

ドライバ生成部１００９は、入力変数の型がオブジェクト型であるか、あるいはプリミティブ型であるかを判定する（Ｓ１３０５）。例えば、入力変数が「Ａ ｏｂｊ１」であれば、オブジェクト型であると判定し、入力変数が「ｉｎｔ ａ」であれば、プリミティブ型であると判定する。

まず、入力変数の型がオブジェクト型と判定された場合について説明する。ドライバ生成部１００９は、制御変数宣言処理を行う（Ｓ１３０７）。

図１４に、制御変数宣言処理フローの例を示す。ドライバ生成部１００９は、規約に従ってｎｕｌｌ制御変数名を決める（Ｓ１４０１）。この例で、ｉ番目の入力変数に対するｎｕｌｌ制御変数名は、「Ｐｉ＿ｃｎｕｌｌ」となる。そして、ドライバ生成部１００９は、サンプルフォームのシンボル変数宣言エリア７０１に「＠Ｓｙｍｂｏｌｉｃ（”ｔｒｕｅ”）」の行を追加し（Ｓ１４０３）、更に「ｐｕｂｌｉｃ ｓｔａｔｉｃ ｂｏｏｌｅａｎ；」の行を加える（Ｓ１４０５）。そして、ドライバ生成部１００９は、ｂｏｏｌｅａｎ型のｎｕｌｌ制御変数名を挿入する（Ｓ１４０７）。更に、ドライバ生成部１００９は、ｎｕｌｌ制御変数に具体値を代入するようにしてもよい。このようにして、例えば図８に示した８０１の宣言が生成される。

続いて、ドライバ生成部１００９は、規約に従って実際型制御変数名を決める（Ｓ１４０９）。この例で、ｉ番目の入力変数に対する実際型制御変数名は、「Ｐｉ＿ｃＣｌａｓｓ」となる。ドライバ生成部１００９は、サンプルフォームのシンボル変数宣言エリア７０１に「＠Ｓｙｍｂｏｌｉｃ（”ｔｒｕｅ”）」の行を追加し（Ｓ１４１１）、更に、「ｐｕｂｌｉｃ ｓｔａｔｉｃ ｉｎｔ；」の行を加え（Ｓ１４１３）。そして、ドライバ生成部１００９は、ｉｎｔ型の実際型制御変数名を挿入する（Ｓ１４１５）。ドライバ生成部１００９は、実際型制御変数に具体値を代入するようにしてもよい。このようにして、例えば図８に示した８０３の宣言が生成される。

図１３の処理に戻って、ドライバ生成部１００９は、メンバ宣言処理を行う（Ｓ１３０９）。

図１５に、メンバ宣言処理フローの例を示す。ドライバ生成部１００９は、オブジェクト型変数として保持し得るメンバ変数毎に以下の処理を繰り返す（Ｓ１５０１）。ドライバ生成部１００９は、規約に従ってメンバシンボル変数名を決める（Ｓ１５０３）。この例で、ｉ番目の入力変数のメンバ変数Ｍに対するメンバシンボル変数名は、「Ｐｉ＿ｍＭ」となる。ドライバ生成部１００９は、サンプルフォームのシンボル変数宣言エリア７０１に「＠Ｓｙｍｂｏｌｉｃ（”ｔｒｕｅ”）」の行を追加し（Ｓ１５０５）、更に、「ｐｕｂｌｉｃ ｓｔａｔｉｃ ；」の行を加える（Ｓ１５０７）。そして、ドライバ生成部１００９は、データの型を挿入し（Ｓ１５０９）、メンバシンボル変数名を挿入する（Ｓ１５１１）。ドライバ生成部１００９は、メンバシンボル変数に具体値を代入するようにしてもよい。このようにして、例えば図８に示した８０５と８０７の宣言が生成される。ドライバ生成部１００９は、すべてのメンバ変数について処理したか否かを判定する（Ｓ１５１３）。処理していないメンバ変数があると判定した場合には、Ｓ１５０１へ戻る。すべてのメンバ変数について処理したと判定した場合には、ドライバ生成部１００９は処理を終え、図１３のＳ１３１１へ戻る。

図１３の処理に戻って、ドライバ生成部１００９は、初期化コード処理を行う（Ｓ１３１１）。

図１６に、初期化コード処理フローの例を示す。ドライバ生成部１００９は、規約に従ってオブジェクト型変数名を決める（Ｓ１６０１）。この例で、ｉ番目の入力変数名は、プリミティブ型変数であるかオブジェクト型変数であるかを問わず、「Ｐｉ」となる。ドライバ生成部１００９は、サンプルフォームの初期化コードエリア７０５にオブジェクト型変数の宣言を追加する（Ｓ１６０３）。具体的には、クラス型とオブジェクト変数名が設定される。このようにして、例えば図８に示した８１３の宣言が生成される。

続いて、ドライバ生成部１００９は、ｎｕｌｌ化処理を行う（Ｓ１６０５）。図１７に、ｎｕｌｌ化処理フローの例を示す。ドライバ生成部１００９は、サンプルフォームの初期化コードエリア７０５に判定制御コードを追加する（Ｓ１７０１）。この例では、判定制御コードとして図８の８１５と８１９に示した「ｉｆ（）｛｝ｅｌｓｅ｛｝」（改行省略）を追加する。ドライバ生成部１００９は、ｎｕｌｌ判定条件を挿入する（Ｓ１７０３）。この例では、ｉｆ文の（）内にｎｕｌｌ制御変数名を挿入する。ドライバ生成部１００９は、ｉｆ文の判定が真の場合に、ｎｕｌｌ制御変数名へｎｕｌｌを代入する命令を追加し（Ｓ１７０５）、処理を終える。

図１６の処理に戻って、ドライバ生成部１００９は、クラス判定処理を行う（Ｓ１６０７）。ドライバ生成部１００９は、クラス判定処理で（Ｓ１６０７）、例えば図８の８１７のコードを設定する。

図１８に、クラス判定処理フローの例を示す。ドライバ生成部１００９は、サンプルフォームの初期化コードエリア７０５に分岐制御コードを追加する（Ｓ１８０１）。この例では、ｉｆ文の判定が偽の場合の分岐制御コードとして「ｓｗｉｔｃｈ（）｛ｃａｓｅ：ｂｒｅａｋ；ｃａｓｅ：ｂｒｅａｋ；ｄｅｆａｕｌｔ：ｂｒｅａｋ；｝」（改行省略）を追加する。ドライバ生成部１００９は、分岐条件を挿入し（Ｓ１８０３）、処理を終える。この例では、ｓｗｉｔｃｈ文の（）内に実際型制御変数名「Ｐ１＿ｃＣｌａｓｓ」を挿入し、各ｃａｓｅの後に「０」と「１」を挿入する。

図１６の処理に戻って、ドライバ生成部１００９は、オブジェクト型変数初期化処理を行う（Ｓ１６０９）。ドライバ生成部１００９は、オブジェクト型変数初期化処理（Ｓ１６０９）で、オブジェクト型変数の型の候補となるクラス型毎の初期化のコードを設定する。

図１９に、オブジェクト型変数初期化処理フローの例を示す。ドライバ生成部１００９は、候補となるクラス型毎に以下の処理を繰り返す（Ｓ１９０１）。ドライバ生成部１００９は、オブジェクト型変数生成の命令を追加する（Ｓ１９０３）。例えばクラス型がＡの場合には、「（オブジェクト型変数）＝ｎｅｗ Ａ（）；」のコードを追加する。ドライバ生成部１００９は、更に候補のクラス型で保持し得るメンバ変数についてメンバ初期化の命令を追加する（Ｓ１９０５）。具体的には、「（メンバ変数）＝（メンバシンボル変数名）；」のコードを追加する。ドライバ生成部１００９は、すべての候補となるクラス型について処理したか否かを判定する（Ｓ１９０７）。処理していないクラス型があると判定した場合には、ドライバ生成部１００９はＳ１９０１に戻る。すべての候補となるクラス型について処理したと判定した場合には、ドライバ生成部１００９は処理を終え、図１６の処理へ戻る。このようにして、例えば図８に示した８１７のコードが設定される。更に、ドライバ生成部１００９は図１６の処理を終え、図１３のＳ１３１３へ戻る。

図１３の処理に戻って、ドライバ生成部１００９は、オブジェクト指定命令処理を行う（Ｓ１３１３）。ドライバ生成部１００９は、オブジェクト指定命令処理（Ｓ１３１３）で、例えば、図８に示した８２１のコードを設定する。

図２０に、オブジェクト指定命令処理フローの例を示す。ドライバ生成部１００９は、サンプルフォームのオブジェクト指定命令エリア７０７にオブジェクト指定命令「ＳｙｍｂｏｌｉｃＥｘｅｃＵｔｉｌ．ｃａｌｃＰａｔｈＣｏｎｄｉｔｉｏｎ（）；」の行を追加する（Ｓ２００１）。ドライバ生成部１００９は、オブジェクト指定命令の引数にオブジェクト型変数名を挿入する（Ｓ２００３）。

また、ドライバ生成部１００９は、パス条件用変数名を特定する（Ｓ２００５）。パス条件用変数名は、このオブジェクト型変数についてのパス条件を生成する際に用いる変数名である。この例では、パス条件用変数名は、オブジェクト型変数名と同じである。ドライバ生成部１００９は、オブジェクト指定命令の引数にパス条件用変数名を挿入する（Ｓ２００７）。ドライバ生成部１００９は図２０の処理を終え、図１３のＳ１３１７へ戻る。

次に、図１３の処理に戻って、Ｓ１３０５で入力変数の型がプリミティブ型と判定された場合について説明する。

Ｓ１３０５で入力変数の型がプリミティブ型と判定された場合には、ドライバ生成部１００９は、プリミティブ宣言処理を行う（Ｓ１３１５）。図２１に、プリミティブ宣言処理フローの例を示す。ドライバ生成部１００９は、規約に従ってプリミティブ型変数名を決める（Ｓ２１０１）。この例で、ｉ番目の入力変数名は、プリミティブ型変数であるかオブジェクト型変数であるかを問わず、「Ｐｉ」となる。ドライバ生成部１００９は、サンプルフォームのシンボル変数宣言エリア７０１に「＠Ｓｙｍｂｏｌｉｃ（”ｔｒｕｅ”）」の行を追加する（Ｓ２１０３）。ドライバ生成部１００９は、「ｐｕｂｌｉｃ ｓｔａｔｉｃ ；」の行を加える（Ｓ２１０５）。ドライバ生成部１００９は、プリミティブ型変数のデータ型を挿入する（Ｓ２１０７）。ドライバ生成部１００９は、シンボル変数名を挿入する（Ｓ２１０９）。このようにして、例えば図３の３０１のコードが設定される。ドライバ生成部１００９は図２１の処理を終えると、図１３のＳ１３１７へ戻る。

図１３の処理に戻って、ドライバ生成部１００９は、すべての引数について処理したか否かを判定する（Ｓ１３１７）。処理していない引数があると判定した場合には、ドライバ生成部１００９はＳ１３０１へ戻る。すべての引数について処理したと判定した場合には、ドライバ生成部１００９は図１３の処理を終え、図１２のＳ１２０５へ戻る。

図１２の処理に戻って、ドライバ生成部１００９は、対象クラス初期化処理（Ｓ１２０５）で、対象クラスを初期化するコードを設定する。

図２２は、対象クラス初期化処理フローの例を示す図である。ドライバ生成部１００９は、図７に示したサンプルフォームの対象クラス初期化エリア７０３に「ＴａｒｇｅｔＣｌａｓｓ ｔａｒｇｅｔ ＝ ｎｅｗ （）；」の行を追加する（Ｓ２２０１）。ドライバ生成部１００９は、対象クラス名を特定し（Ｓ２２０３）、「（）」の前に挿入し（Ｓ２２０５）、処理を終える。このようにして、図８に示した８１１のコードが設定される。

図２２の処理を終えると、図１２の処理に戻って、ドライバ生成部１００９は、対象メソッド呼び出し処理を行う（Ｓ１２０７）。

図２３に、対象メソッド呼び出し処理フローの例を示す。ドライバ生成部１００９は、図７に示したサンプルフォームの対象メソッドの呼び出しエリア７０９に「ｔａｒｇｅｔ．（）；」 の行を追加する（Ｓ２３０１）。ドライバ生成部１００９は、対象メソッド名を特定し（Ｓ２３０３）、「．」の後に挿入する（Ｓ２３０５）。更に、ドライバ生成部１００９は、引数に設定する変数名を挿入し（Ｓ２３０７）、処理を終える。ドライバ生成部１００９は図１２の対象メソッド呼び出し処理（Ｓ１２０７）を終え、更に図１１のドライバ生成処理（Ｓ１１０３）を終える。

続いて、図１１の処理に戻って、Ｓ１１０５に示した制御変数テーブル生成処理について説明する。制御変数テーブル生成部１０１３は、制御変数テーブル生成処理で、例えば図９に示した制御変数テーブルを生成する。

図２４に、制御変数テーブル生成処理フローの例を示す。制御変数テーブル生成部１０１３は、対象メソッドの入力変数を特定し（Ｓ２４０１）、入力変数毎に以下の処理を繰り返す（Ｓ２４０３）。制御変数テーブル生成部１０１３は、入力変数の型がオブジェクト型であるか、あるいはプリミティブ型であるかを判定する（Ｓ２４０５）。入力変数の型がプリミティブ型であると判定した場合には、制御変数テーブル生成部１０１３はＳ２４１７を行う。

入力変数の型がオブジェクト型であると判定した場合には、制御変数テーブル生成部１０１３は、図１４のＳ１４０１で決めたｎｕｌｌ制御変数名を設定する（Ｓ２４０７）。そして、制御変数テーブル生成部１０１３は、ｔｒｕｅと意味式を設定する（Ｓ２４０９）。意味式は、「（オブジェクト型変数名）＝＝ｎｕｌｌ」となる。制御変数テーブル生成部１０１３は、更にｆａｌｓｅと意味式を設定する（Ｓ２４１１）。意味式は、「（オブジェクト型変数名）！＝ｎｕｌｌ」となる。

次に、制御変数テーブル生成部１０１３は、図１４のＳ１４０９で決めた実際型制御変数名を設定する（Ｓ２４１３）。更に、制御変数テーブル生成部１０１３は、候補クラスを示す値と意味式を設定する（Ｓ２４１５）。値に応じて、「（オブジェクト型変数名） ｉｎｓｔａｎｃｅｏｆ （候補クラス名）」とする。制御変数テーブル生成部１０１３は、すべての入力変数について処理した否かを判定する（Ｓ２４１７）。処理していない入力変数があると判定した場合には、制御変数テーブル生成部１０１３はＳ２４０３に戻る。すべての入力変数について処理したと判定した場合には、制御変数テーブル生成部１０１３は処理を終え、図１１に戻り、準備処理を終える。

このように準備処理において、シンボル実行用ドライバと制御変数テーブルを生成することにより、テストケース生成作業の省力化が図られる。

続いて、シンボリック実行処理について説明する。図２５は、テストケース生成装置のうちシンボリック実行処理に係る構成例を示す図である。テストケース生成装置は、更に、実行部１０１７、パターンテーブル格納部１０１９、シンボル変数テーブル記憶部１０２１、特定部１０２３、オブジェクトテーブル記憶部１０２５、第１テストケース格納部１０２７、第１生成部１０２９及びオブジェクトパス条件記憶部１０３１を有している。

実行部１０１７は、シンボリック実行を行い、第１テストケースを生成するように構成されている。パターンテーブル格納部１０１９は、プログラムパターンとメモリ条件パターンとパス条件パターンを対応付けるパターンテーブルを記憶するように構成されている。パターンテーブル格納部１０１９については、図２６を用いて後述する。

シンボル変数テーブル記憶部１０２１は、シンボル変数とその型を対応付けるシンボル変数テーブルを記憶するように構成されている。特定部１０２３は、オブジェクト型変数の実体が格納されている位置を特定したオブジェクトテーブルを生成する処理を行うように構成されている。オブジェクトテーブル記憶部１０２５は、オブジェクトテーブルを記憶するように構成されている。第１テストケース格納部１０２７は、第１テストケースの集合である第１テストケースセットを記憶するように構成されている。第１生成部１０２９は、オブジェクトテーブルに基づいて、オブジェクト型変数が満たすべきオブジェクトパス条件を生成する処理を行うように構成されている。オブジェクトパス条件記憶部１０３１は、オブジェクトパス条件を記憶するように構成されている。

図２６に、パターンテーブルの例を示す。パターンテーブルは、パターン番号、プログラムパターン、メモリ条件パターン及びパス条件パターンを対応付けている。プログラムに含まれる式のパターンにより導かれるオブジェクトパス条件のパターンを定めている。更に、プログラムに含まれる式のパターンに加えて、メモリの条件も加えて判断する場合のメモリ条件のパターンも定めている。

メモリ条件パターンが設定されていない場合には、プログラムパターンからパス条件パターンが導かれ、メモリ条件パターンが設定されている場合には、プログラムパターン及びメモリ条件パターンからパス条件パターンが導かれる。

「ＯＢＪＸ」と「ＯＢＪＹ」は、オブジェクトパス条件を計算する対象となるオブジェクト変数を示している。例えば、パターン番号１に示したように、プログラム中の命令に「ＯＢＪＸ＝＝ｎｕｌｌ」の式が含まれる場合には、パス条件として「ＯＢＪＸ＝＝ｎｕｌｌ」が導かれる。

また、「ＴＸ」は、型を示している。例えば、パターン番号３に示したように、プログラム中の命令に「ＯＢＪＸ ｉｎｓｔａｎｃｅｏｆ ＴＸ」の式が含まれる場合には、パス条件として「ＯＢＪＸ ｉｎｓｔａｎｃｅｏｆ ＴＸ」が導かれる。

「．ｍｅｍｂｅｒ」は、メンバ変数へのアクセスを示している。例えば、パターン番号５に示したように、プログラム中の命令に「ＯＢＪＸ．ｍｅｍｂｅｒ」の式が含まれる場合には、パス条件として「ＯＢＪＸ！＝ｎｕｌｌ」が導かれる。

「．ｍｅｔｈｏｄ（）」は、メソッドの呼び出しを示している。例えば、パターン番号６に示したように、プログラム中の命令に「ＯＢＪＸ．ｍｅｔｈｏｄ（）」の式が含まれる場合には、パス条件として「ＯＢＪＸ！＝ｎｕｌｌ」が導かれる。

「ＶＸ」と「ＶＹ」は、オブジェクトパス条件を計算する対象とならない変数を示している。例えば、パターン番号７に示したように、プログラム中の命令に「ＯＢＪＸ＝＝ＶＸ」の式が含まれ、更にメモリの状態が「ＶＸ＝＝ｎｕｌｌ」であれば、パス条件として「ＯＢＪＸ＝＝ｎｕｌｌ」が導かれる。

図２７に、シンボル変数テーブル記憶部１０２１で記憶されるシンボル変数テーブルの例を示す。このように、シンボル変数テーブル記憶部１０２１は、シンボル変数とその型を対応付ける。

図２８に、オブジェクトテーブル記憶部１０２５で記憶されるオブジェクトテーブルの例を示す。図２８に示したように、オブジェクトパス条件を計算する対象となるオブジェクト型変数名と、参照用ＩＤと、パス条件用変数名を対応付けている。参照用ＩＤは、オブジェクト型変数のインスタンスを参照するための情報である。パス条件用変数名は、オブジェクトパス条件で用いるオブジェクト型変数の変数名である。オブジェクト型変数名は、省略してもよい。

図２９ａ乃至図２９ｃに、第１テストケース格納部１０２７で記憶される第１テストケースセットの例を示す。テストケースを識別するケース番号と、テスト入力と、シンボルパス条件を対応付けている。第１テストケースは、シンボリック実行処理により生成される。

図３０に、オブジェクトパス条件記憶部１０３１で記憶されるオブジェクトパス条件の例を示す。テストケースを識別するケース番号とオブジェクトパス条件を対応付けている。例えば、ケース番号１の場合、「Ｐ１＿ｃｎｕｌｌ＝＝ｔｒｕｅ∧Ｐ２＿ｃｎｕｌｌ ＝＝ｔｒｕｅ」がオブジェクトパス条件となることを示している。オブジェクトパス条件は、第１生成部１０２９により生成される。

続いて、シンボリック実行処理について説明する。図３１に、シンボリック実行処理フローの例を示す。実行部１０１７は、まず初期化処理を行う（Ｓ３１０１）。

図３２に、初期化処理フローの例を示す。実行部１０１７は、シンボル変数テーブルを生成する（Ｓ３２０１）。シンボル変数テーブルは、シンボル実行用ドライバのシンボル変数宣言から抽出される。シンボル変数テーブルは、シンボル変数を特定するために用いられる。実行部１０１７は、実行開始位置を特定する（Ｓ３２０３）。実行開始位置は、図８の８０９のコードにより特定される。実行部１０１７は、第１テストケースに新規レコードを割り当てる（Ｓ３２０５）。このとき、ケース番号も割り振られる。実行部１０１７は処理を終了し、図３１のＳ３１０３へ戻る。

図３１の処理に戻って、実行部１０１７は、実行パターン処理を行う（Ｓ３１０３）。実行パターン処理では、実行パターン毎の処理を行う。図３３に、実行パターン処理フローの例を示す。実行部１０１７は、実行開始位置から順に命令を特定する（Ｓ３３０１）。実行部１０１７は、命令が有るか否かを判定する（Ｓ３３０３）。命令が無いと判定した場合には、実行パターンの終点であるので、実行部１０１７は、処理結果を完了として処理を終了する（Ｓ３３０５）。実行部１０１７が処理を終えると、図３１のＳ３１０５へ戻る。

図３３のＳ３３０３で命令が有ると判定した場合には、実行部１０１７は、命令がオブジェクト指定命令であるか否かを判定する（Ｓ３３０７）。オブジェクト指定命令は、例えば図８に示した８２１のコードである。命令がオブジェクト指定命令でないと判定した場合には、実行部１０１７はＳ３３１１へ処理を移す。命令がオブジェクト指定命令であると判定した場合には、特定部１０２３は、オブジェクト特定処理を行う（Ｓ３３０９）。

ここで、オブジェクト指定命令を判定する実行パターン処理の動作例を説明する。図３４に、実行パターン処理の動作例を示す。シンボル実行用ドライバと対象メソッド中の命令の遷移を、矢印で示している。「ｉｆ（Ｐ１＿ｃｎｕｌｌ）」の条件判断で、「ｔｒｕｅ」と判断され、シンボルパス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｔｒｕｅ」が生成される。また、「ｉｆ（Ｐ２＿ｃｎｕｌｌ）」の条件判断で、「ｔｒｕｅ」と判断され、シンボルパス条件「Ｐ２＿ｃｎｕｌｌ＝＝ｔｒｕｅ」が生成される。

「ＳｙｍｂｏｌｉｃＥｘｅｃＵｔｉｌ．ｃａｌｃＰａｔｈＣｏｎｄｉｔｉｏｎ（Ｐ１， “Ｐ１”）；」と「ＳｙｍｂｏｌｉｃＥｘｅｃＵｔｉｌ．ｃａｌｃＰａｔｈＣｏｎｄｉｔｉｏｎ（Ｐ２， “Ｐ２”）；」の行で、オブジェクト指定命令と判定され、オブジェクト特定処理が行われる。

続けて、図３３のオブジェクト特定処理（Ｓ３３０９）の説明をする。図３５に、オブジェクト特定処理フローの例を示す。特定部１０２３は、オブジェクト指定命令の引数であるオブジェクト型変数名を特定する（Ｓ３５０１）。図３４の例では、それぞれ「Ｐ１」と「Ｐ２」がオブジェクト型変数名である。特定部１０２３は、オブジェクト型変数名を実行部１０１７へ渡し、実行部１０１７からオブジェクト型変数のインスタンスを参照するための参照用ＩＤを取得する（Ｓ３５０３）。このとき、実行部１０１７は、オブジェクト型変数名を受け、そのオブジェクト型変数のインスタンスを参照するための参照用ＩＤを返すように動作する。特定部１０２３は、オブジェクト指定命令の引数であるパス条件用変数名を特定する（Ｓ３５０５）。図３４の例では、それぞれ「“Ｐ１”」と「“Ｐ２”」がパス条件用変数名である。特定部１０２３は、オブジェクト型変数名と参照用ＩＤとパス条件用変数名を対象テーブルのレコードに追加する（Ｓ３５０７）。特定部１０２３は処理を終え、図３３のＳ３３１１へ戻る。

図３３の処理に戻って、実行部１０１７は、Ｓ３３０１で特定した命令を解析し（Ｓ３３１１）、その命令が分岐命令であるか否かを判定する。（Ｓ３３１３）。その命令が分岐命令でないと判定した場合には、Ｓ３３１７へ移る。その命令が分岐命令であると判定した場合には、実行部１０１７は、未だパスとして選択していない分岐を選択する（Ｓ３３１５）。そして、実行部１０１７は、選択した分岐についてのシンボルパス条件を計算する（Ｓ３３１７）。但し、Ｓ３３１３で分岐命令でないと判定し、シンボルパス条件の計算を行なわない場合もある。シンボルパス条件の計算については、従来のシンボリック実行の場合と同様であるので、説明を省略する。

続いて、第１生成部１０２９は、オブジェクトパス条件生成処理を行う（Ｓ３３１９）。オブジェクトパス条件生成処理については、図３８から図４０を用いて後述する。

実行部１０１７は、パス条件の充足は可能であるか否かを判定する（Ｓ３３２１）。パス条件を充足できないと判定した場合には、実行不可能なパス（例えば、図２の２０３）を含むので、実行部１０１７は、処理結果を中断とする（Ｓ３３２３）。パス条件を充足できると判定した場合には、実行部１０１７は、命令を実行し（Ｓ３３２５）、Ｓ３３０１へ戻る。

図３６に、図３４の次の実行パターン処理の動作例を示す。図３４で「ｒｅｔｕｒｎ ０」に至り、図３３のＳ３３０３とＳ３３０５で示したように次の命令が無いと判定すると、処理結果を完了として一旦実行パターン処理を終える。そして、未実行パスを選択する。具体的には、バックトラックにより未選択の分岐がある分岐点までもどり、未選択の分岐を次のパスの実行開始位置とする。図３６の例では、次の実行開始位置「ｉｆ（Ｐ２＿ｃｎｕｌｌ）」の判断結果「ｆａｌｓｅ」を選択する。このとき、実行開始位置「ｉｆ（Ｐ２＿ｃｎｕｌｌ）」までに得られている既知のシンボルパス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｔｒｕｅ」が特定され、新しいシンボルパス条件に設定される。そして、シンボルパス条件「Ｐ２＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」が生成される。

図３１の処理に戻って、実行部１０１７は、Ｓ３１０３の実行パターン処理における処理結果が中断であるか、あるいは完了であるかを判定する（Ｓ３１０５）。処理結果が中断であると判定した場合には、実行部１０１７はテストケースを生成しない。処理結果が完了であると判定した場合には、実行部１０１７はテストケースを生成する（Ｓ３１０７）。具体的には、実行部１０１７は、シンボリックパス条件の充足値を求めて、その充足値をテスト入力に設定する。

次に、実行部１０１７は、探索処理を行う（Ｓ３１０９）。探索処理では、次のパスを探索する。

図３７に、探索処理フローの例を示す。実行部１０１７は、未実行パスを選択する（Ｓ３７０１）。具体的には、実行部１０１７は、図３６に示したように、バックトラックにより未選択の分岐がある分岐点までもどり、未選択の分岐を次のパスの実行開始位置とする。実行部１０１７は、未実行パスあったか否かを判定する（Ｓ３７０３）。バックトラックにより未選択の分岐が見つけられなかった場合には、実行部１０１７は未実行パスがないと判定して、処理結果をパスなしとする（Ｓ３７０５）。そして、実行部１０１７は処理を終え、図３１のＳ３１１１へ戻る。

バックトラックにより未選択の分岐が見つかった場合には、実行部１０１７は未実行パスがあると判定して、第１テストケースの新規レコードを割り当てる（Ｓ３７０７）。そして、実行部１０１７は、分岐点より上位の既知であるシンボリックパス条件を特定し、新たな第１テストケースのシンボリックパス条件に加える（Ｓ３７０９）。そして、実行部１０１７は、処理結果をパスありとして（Ｓ３７１１）、処理を終了する。そして、図３１のＳ３１１１へ戻る。

図３１の処理に戻って、実行部１０１７は、探索処理（Ｓ３１０９）の処理結果がパスありであるか、あるいはパスなしであるかを判定する（Ｓ３１１１）。探索処理（Ｓ３１０９）の処理結果がパスありであると判定すると、実行部１０１７はＳ３１０３の処理に戻り、シンボリック実行処理を続行する。探索処理（Ｓ３１０９）の処理結果がパスなしであると判定すると、実行部１０１７はシンボリック実行処理を終える。

次に、前述のオブジェクトパス条件生成処理（図３３のＳ３３１９）について説明する。

ここで、図３８にオブジェクトパス条件生成の動作例を示す。図３８の例では、条件判断命令「ｉｆ（ｏｂｊ１！＝ｎｕｌｌ）」から選択した分岐を示す式「ｏｂｊ１！＝ｎｕｌｌ」を得る。そして、オペランド「ｏｂｊ１」を参照先となるＩＤ「１００」を特定する。この参照先ＩＤ「１００」は、オブジェクトテーブルの参照用ＩＤ「１００」と一致するので、このオペランドの変数はオブジェクトパス条件の計算対象であると判定される。そして、式「ｏｂｊ１！＝ｎｕｌｌ」に相当するプログラムパターン「ＯＢＪＸ！＝ｎｕｌｌ」をパターンテーブルで特定し、プログラムパターンに対応するパス条件パターン「ＯＢＪＸ！＝ｎｕｌｌ」に基づいて、オブジェクトパス条件「Ｐ１！＝ｎｕｌｌ」を生成している。その際、参照用ＩＤ「１００」に対応するパス条件用変数名「Ｐ１」を用いている。尚、この例では、メモリ条件パターンは設定されていないので、メモリの状態については判定しない。

図３９に、オブジェクトパス条件生成処理フローの例を示す。第１生成部１０２９は、命令から式を特定し（Ｓ３９０１）、第１生成部１０２９は、オペランドの変数を特定する（Ｓ３９０３）。条件判断命令の場合には、第１生成部１０２９は選択した分岐を示す式を特定する。

そして、第１生成部１０２９は、変数の参照先ＩＤを実行部１０１７から取得する（Ｓ３９０５）。このとき、第１生成部１０２９は変数名を実行部１０１７に渡す。これに対して、実行部１０１７はその変数名によるインスタンスを参照するためのＩＤを返すように動作する。第１生成部１０２９は、取得した参照先ＩＤがオブジェクトテーブルのいずれかの参照用ＩＤと一致するか否かを判定する（Ｓ３９０７）。取得した参照先ＩＤがオブジェクトテーブルのいずれの参照用ＩＤとも一致しないと判定した場合には、第１生成部１０２９は処理を終え、図３３のＳ３３２１へ戻る。

図３９のＳ３９０７で、取得した参照先ＩＤがオブジェクトテーブルのいずれかの参照用ＩＤと一致すると判定した場合には、第１生成部１０２９は、Ｓ３９０１で特定した式に対応するプログラムパターンを特定する（Ｓ３９０９）。Ｓ３９０１で特定した式が否定形式の場合には、肯定形式の式に置き換えてプログラムパターンと対比するようにしてもよい。第１生成部１０２９は、パターンテーブルにプログラムパターンに対応するメモリ条件パターンがあるか否かを判定する（Ｓ３９１１）。パターンテーブルにプログラムパターンに対応するメモリ条件パターンないと判定した場合には、第１生成部１０２９はＳ３９１７へ移る。

パターンテーブルにプログラムパターンに対応するメモリ条件パターンあると判定した場合には、第１生成部１０２９は、メモリ条件パターンに関するメモリ情報を取得する（Ｓ３９１３）。例えば、第１生成部１０２９は「ＶＸ」に相当する変数名を実行部１０１７へ渡し、実行部１０１７はメモリに格納されている変数の値又はｎｕｌｌを返す。あるいは、別の例で第１生成部１０２９は「ＯＢＪＸ」に相当するオブジェクト型変数がｎｕｌｌであるか否かを問い合わせる要求を実行部１０１７へ渡し、実行部１０１７は「ＯＢＪＸ」に相当するオブジェクト型変数がｎｕｌｌであるか否かを示す回答を返す。

そして、第１生成部１０２９は、メモリ情報がメモリ条件パターンに合致するか否かを判定する（Ｓ３９１５）。メモリ情報がメモリ条件パターンに合致しないと判定した場合には、第１生成部１０２９は処理を終了し、図３３のＳ３３２１へ戻る。

メモリ情報がメモリ条件パターンに合致すると判定した場合には、第１生成部１０２９は、オブジェクトパス条件を生成する（Ｓ３９１７）。具体的には、プログラムパターンに対応するパス条件パターンを特定し、パス条件パターンに基づいて、オブジェクトパス条件を生成する。その際、パス条件パターン中のオブジェクト変数（例えば「ＯＢＪＸ」）を、そのオブジェクト変数に相当するオブジェクト変数（「例えば、Ｐ１」）に対応するパス条件用変数名（例えば、「”Ｐ１”」）に変換する。尚、前述のように、特定した式が否定形式の場合であり、式を肯定形式に置き換えてプログラムパターンを特定した場合には、オブジェクトパス条件も肯定形式から否定形式に変換する。そして、第１生成部１０２９は、生成したオブジェクトパス条件をオブジェクトテーブル記憶部１０２５にケース番号に対応付けて記憶させる（Ｓ３９１９）。

図４０に、図３８に続くオブジェクトパス条件生成の動作例を示す。図４０の例では、条件判断命令「ｉｆ（ｏｂｊ１ ｉｎｓｔａｎｃｅｏｆ Ｂ）」で偽が選択されたと想定し、分岐を示す式「！（ｏｂｊ１ ｉｎｓｔａｎｃｅｏｆ Ｂ）」を得る。そして、オペランド「ｏｂｊ１」の参照先となるＩＤ「１００」を特定する。この参照先ＩＤ「１００」は、オブジェクトテーブルの参照用ＩＤ「１００」と一致するので、このオペランドの変数はオブジェクトパス条件の計算対象であると判定される。そして、式「ｏｂｊ１ ｉｎｓｔａｎｃｅｏｆ Ｂ」に相当するプログラムパターン「ＯＢＪＸ ｉｎｓｔａｎｃｅｏｆ ＴＸ」をパターンテーブルで特定し、プログラムパターンに対応するパス条件パターン「ＯＢＪＸ ｉｎｓｔａｎｃｅｏｆ ＴＸ」に基づいて、オブジェクトパス条件「！（Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ）」を生成する。その際、参照用ＩＤ「１００」に対応するパス条件用変数名「Ｐ１」を用いている。また、「ＴＸ」は対応する「Ｂ」に置き換えている。この例では、式が否定形式であるので、オブジェクトパス条件も否定形式となっている。

前述の参照用ＩＤは、オブジェクト変数のインスタンスを参照する情報である。図４１に、メモリ状態の例を示す。スタックでは、変数毎に変数名と型と参照用ＩＤを記憶している。ヒープでは、インスタンスを格納している。インスタンスは、参照用ＩＤによって特定できるように構成されている。例えば、「ｏｂｊ１．ａ１」のメンバ変数の値を取得する場合には、スタックの情報に基づいて「ｏｂｊ１」の変数名に対応する参照用ＩＤ「１００」を特定し、更に参照用ＩＤ「１００」で特定されるインスタンスから、メンバ変数の値を取得する。通常の実行においては、メンバ変数には具体的な値が設定されているが、シンボリック実行においては、シンボル変数として宣言されているメンバ変数には、シンボル値が設定されている。図中、「ｓｙｍｂｏｌ＿Ｐ１＿ｍａ１」と「ｓｙｍｂｏｌ＿Ｐ２＿ｍａ１」は、シンボル値の例である。

複数の変数から同じインスタンスを参照する場合もある。図４２に、複数の変数から同じインスタンスを参照する場合の例を示す。例えば、「（Ｂ）ｏｂｊ１．ｂ１」のメンバ変数の値を取得する場合には、内部処理によってスタックに「ｏｂｊ１」と同じインスタンスを指すクラスＢ型の変数「ｔｍｐ１」を用意する。そして、「ｔｍｐ１」の変数名に対応する参照用ＩＤ「１００」を特定し、更に参照用ＩＤ「１００」で特定されるインスタンスから、メンバ変数の値を取得する。この場合も、シンボル変数として宣言されているメンバ変数にはシンボル値が設定されている。図中、「ｓｙｍｂｏｌ＿Ｐ１＿ｍｂ１」は、シンボル値の例である。

上述のようにシンボリック実行処理により、第１テストケースセットとオブジェクトパス条件が生成される。図２９ａ〜図２９ｃに示した２６の第１テストケースセットは、想定されるオブジェクト型変数の状態の組合せを網羅している。制御情報である「Ｐ１＿ｃｎｕｌｌ」、「Ｐ２＿ｃｎｕｌｌ」、「Ｐ１＿ｃＣｌａｓｓ」、あるいは「Ｐ２＿ｃＣｌａｓｓ」を含むシンボルパス条件により、想定されるオブジェクト型変数の状態を読み取ることができる。

但し、これらの制御情報を含むシンボルパス条件は、シンボル実行用ドライバの初期化コード（例えば、図８の８１５と８１７）での分岐により生成されたものであって、テスト対象のプログラムにおける分岐に基づくものではない。従って、これらの制御情報を含むパス条件は、テストケースを欠落させることなく抽出するためには役立つが、テスト対象のプログラムに対するコードカバレッジを判断するためには不適切なデータであると言える。

一方、オブジェクトパス条件は、テスト対象のプログラムにおけるオブジェクト型変数の状態に関する分岐によるパス条件であり、テスト対象のプログラムに対するコードカバレッジを判断するのに適切なデータであると言える。

以下で説明するパス条件更新処理では、第１テストケースに含まれる制御変数を含むシンボルパス条件を除き、オブジェクトパス条件を加えた第２テストケースを生成する。第２テストケースは、テスト対象のプログラムに対するコードカバレッジの判断に適した対象内パス条件を備える。

また、パス条件更新処理に続くテストケース抽出処理では、第２テストケースセットから重複するテストケースを排除した第３テストケースセットを生成する。第３テストケースセットによるコードカバレッジは、第２テストケースセットによるコードカバレッジと等しい。

続いて、パス条件更新処理とテストケース抽出処理について説明する。図４３は、テストケース生成装置のうちパス条件更新とテストケース抽出に係る構成例を示す図である。テストケース生成装置は、更に、第２生成部１０３３、第２テストケース格納部１０３５、抽出部１０３７、第３テストケース格納部１０３９及びテストケース出力部１０４１を有している。第２生成部１０３３は、パス条件を更新し、第２テストケースを生成するように動作する。第２テストケース格納部１０３５は、第２テストケースセットを記憶するように構成されている。抽出部１０３７は、第２テストケースセットから第３テストケースを抽出するように動作する。第３テストケース格納部１０３９は、第３テストケースの集合である第３テストケースセットを記憶するように構成されている。テストケース出力部１０４１は、第３テストケースセットを出力するように動作する。

図４４に、パス条件更新の概要を示す。第１テストケースのシンボルパス条件のうち、制御変数を含まないシンボルパス条件のみが第２テストケースの対象内パス条件にコピーされる。図４４の例では、シンボルパス条件「（Ｐ２＿ｍａ１＞Ｐ１＿ｍａ１）」が対象内パス条件にコピーされている。シンボルパス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」は、制御変数「Ｐ１＿ｃｎｕｌｌ」を含んでいるので、対象内パス条件にコピーされない。同様に、シンボルパス条件「Ｐ１＿ｃＣｌａｓｓ＝＝０」は、制御変数「Ｐ１＿ｃＣｌａｓｓ」を含んでいるので、対象内パス条件にコピーされない。同様に、シンボルパス条件「Ｐ２＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」は、制御変数「Ｐ２＿ｃｎｕｌｌ」を含んでいるので、対象内パス条件にコピーされない。同様に、シンボルパス条件「Ｐ２＿ｃＣｌａｓｓ＝＝０」は、制御変数「Ｐ２＿ｃＣｌａｓｓ」を含んでいるので、対象内パス条件にコピーされない。

また、オブジェクトパス条件が第２テストケースの対象内パス条件にコピーされる。オブジェクトパス条件は、コピーの際に制御変数が満たすべき条件の形式に変換される。図４４の例では、オブジェクトパス条件「Ｐ１！＝ ｎｕｌｌ」は、対象内パス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」に変換されている。オブジェクトパス条件「！（Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ）」は、対象内パス条件「Ｐ１＿ｃＣｌａｓｓ！＝１」に変換されている。オブジェクトパス条件「Ｐ２！＝ｎｕｌｌ」は、対象内パス条件「Ｐ２＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」に変換されている。オブジェクトパス条件「（Ｐ２．ｍａ１＞Ｐ１．ｍａ１）」は、対象内パス条件「（Ｐ２＿ｍａ１＞Ｐ１＿ｍａ１）」に変換されている。対象内パス条件「（Ｐ２＿ｍａ１＞Ｐ１＿ｍａ１）」は、シンボルパス条件と重複しているので、１つの対象内パス条件のみ設定される。このように、オブジェクトパス条件とシンボルパス条件の一部が重複することも想定される。

制御変数が満たすべき条件の形式に変換することによって、テスト入力との関係を把握しやすくなる。

更に、第１テストケースのテスト入力が第２テストケースのテスト入力にコピーされる。

テスト入力「Ｐ１＿ｃｎｕｌｌ＝ｆａｌｓｅ」と、テスト入力「Ｐ１＿ｃＣｌａｓｓ＝０」と、テスト入力「Ｐ１＿ｍａ１＝０」と、テスト入力「Ｐ２＿ｃｎｕｌｌ＝ｆａｌｓｅ」と、テスト入力「Ｐ２＿ｃＣｌａｓｓ＝０」と、テスト入力「Ｐ２＿ｍａ１＝１」が、第１テストケースから第２テストケースへコピーされている。

図４５に、第２テストケース生成処理フローの例を示す。第２生成部１０３３は、ケース番号毎に以下の処理を繰り返す（Ｓ４５０１）。第２生成部１０３３は、更にシンボルパス条件毎に以下の処理を繰り返す（Ｓ４５０３）。第２生成部１０３３は、シンボルパス条件が制御変数名を含むか否かを判定する（Ｓ４５０５）。シンボルパス条件が制御変数名を含ないと判定した場合には、第２生成部１０３３は、シンボルパス条件をコピーする（Ｓ４５０７）。一方、シンボルパス条件が制御変数名を含むと判定した場合には、第２生成部１０３３は、シンボルパス条件をコピーしない。第２生成部１０３３は、すべてのシンボルパス条件について処理したか否かを判定する（Ｓ４５０９）。処理していないシンボルパス条件があると判定した場合には、第２生成部１０３３はＳ４５０３へ処理を戻す。すべてのシンボルパス条件について処理したと判定した場合には、第２生成部１０３３はＳ４５１１へ処理を移す。

続いて、第２生成部１０３３は、オブジェクトパス条件毎に以下の処理を繰り返す（Ｓ４５１１）。第２生成部１０３３は、制御変数テーブルでオブジェクトパス条件と一致する意味式を特定する（Ｓ４５１３）。第２生成部１０３３は、意味式に対応する制御変数名と値を特定し、制御変数と値を用いた対象内パス条件を生成し、第２テストケースに加える（Ｓ４５１５）。例えば、図４４の例でオブジェクト条件「Ｐ１！＝ｎｕｌｌ」と一致する意味式「Ｐ１！＝ｎｕｌｌ」に対応する制御変数名「Ｐ１＿ｃｎｕｌｌ」と値「ｆａｌｓｅ」を特定する。そして、対象内パス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｆａｌｓｅ」を生成する。

オブジェクトパス条件が否定形式である場合であり、オブジェクトパス条件を肯定形式に置き換えて意味式を特定するようにしてもよい。その場合には、制御変数と値を用いたパス条件を否定形式に置き換えることによって対象内パス条件を生成する。

例えば、図４４の例で否定形式のオブジェクトパス条件「！（Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ）」を肯定形式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ」に置き換えて、意味式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ」を特定する。そして、意味式「Ｐ１ ｉｎｓｔａｎｃｅｏｆ Ｂ」に対応する制御変数名「Ｐ１＿ｃＣｌａｓｓ」と値「１」を特定し、パス条件「Ｐ１＿ｃＣｌａｓｓ＝＝１」を生成し、否定形式に置き換えて対象内パス条件「Ｐ１＿ｃＣｌａｓｓ！＝１」を生成する。

尚、制御変数ではないメンバ変数についても、メンバ変数の変換規則に従って対象内パス条件に変換するようにしてもよい。図４４の例で、例えば変換規則で、「Ｐ２．ｍａ１」が「Ｐ２＿ｍａ１」に相当し、「Ｐ１．ｍａ１」が「Ｐ１＿ｍａ１」に相当すると規定されている場合には、オブジェクト条件「Ｐ２．ｍａ１＞Ｐ１．ｍａ１」は、対象内パス条件「Ｐ２＿ｍａ１＞Ｐ１＿ｍａ１」に変換される。

図４４に示したように、シンボル変数「Ｐ１＿ｍａ１」とシンボル変数「Ｐ２＿ｍａ１」に関するシンボルパス条件「Ｐ２＿ｍａ１＞Ｐ１＿ｍａ１」も同じ内容である。このように同じ内容である場合には、対象内パス条件には１つだけ設定される。第２生成部１０３３は、すべてのオブジェクトパス条件について処理したか否かを判定する（Ｓ４５１７）。処理していないオブジェクトパス条件があると判定した場合には、Ｓ４５１１へ戻る。

一方、すべてのオブジェクトパス条件について処理したと判定した場合には、第２生成部１０３３は、第１テストケースのテスト入力を第２テストケースにコピーする（Ｓ４５１９）。第２生成部１０３３は、すべてのケース番号について処理したか否かを判定する（Ｓ４５２１）。処理していないケース番号があると判定した場合には、第２生成部１０３３はＳ４５０１へ処理を戻す。すべてのケース番号について処理した場合には、第２生成部１０３３は処理を終了する。

図４６ａ乃至４６ｃに、第２テストケースの例を示す。第１テストケースに対応する第２テストケースが生成される。例えば、ケース番号１〜ケース番号４の第２テストケースは、同じ対象内パス条件「Ｐ１＿ｃｎｕｌｌ＝＝ｔｒｕｅ」を有する。ケース番号１〜ケース番号４は、テスト対象のプログラムの同じルートを通ることを示している。ケース番号１のテストケースで、テスト入力「Ｐ１＿ｃｎｕｌｌ＝ｔｒｕｅ」とテスト入力「Ｐ２＿ｃｎｕｌｌ＝ｔｒｕｅ」を入力して図５に示した対象クラスを実行した場合、「ｉｆ（ｏｂｊ１！＝ｎｕｌｌ）」で偽と判定され、「ｒｅｔｕｒｎ ０」で終了するルートを通る。更に、ケース番号２のテストケースで、テスト入力「Ｐ１＿ｃｎｕｌｌ＝ｔｒｕｅ」とテスト入力「Ｐ２＿ｃｎｕｌｌ＝ｆａｌｓｅ」とテスト入力「Ｐ２＿ｃＣｌａｓｓ＝０」を入力して図５に示した対象クラスを実行した場合にも、同様に「ｉｆ（ｏｂｊ１！＝ｎｕｌｌ）」で偽と判定され、「ｒｅｔｕｒｎ ０」で終了するルートを通る。更に、ケース番号３のテストケースで、テスト入力「Ｐ１＿ｃｎｕｌｌ＝ｔｒｕｅ」とテスト入力「Ｐ２＿ｃｎｕｌｌ＝ｆａｌｓｅ」とテスト入力「Ｐ２＿ｃＣｌａｓｓ＝１」を入力して図５に示した対象クラスを実行した場合にも、同様に「ｉｆ（ｏｂｊ１！＝ｎｕｌｌ）」で偽と判定され、「ｒｅｔｕｒｎ ０」で終了するルートを通る。更に、ケース番号４のテストケースで、テスト入力「Ｐ１＿ｃｎｕｌｌ＝ｔｒｕｅ」とテスト入力「Ｐ２＿ｃｎｕｌｌ＝ｆａｌｓｅ」とテスト入力「Ｐ２＿ｃＣｌａｓｓ＝−１」を入力して図５に示した対象クラスを実行した場合にも、同様に「ｉｆ（ｏｂｊ１！＝ｎｕｌｌ）」で偽と判定され、「ｒｅｔｕｒｎ ０」で終了するルートを通る。このようにテスト対象のプログラムの同じルートを通る複数のテストケースは冗長であるので、削減することが望ましい。

図４７に、第３テストケースの例を示す。この例では、同じルートを通る複数の第２テストケースのうち、最も小さいケース番号のテストケースを第３テストケースに移し、それ以外は排除している。例えば、ケース番号１〜ケース番号４の第２テストケースのうち、ケース番号１の第２テストケースは第３テストケースセットに移されるが、ケース番号２〜ケース番号４の第２テストケースは第３テストケースセットに移されない。

図４８は、テストケース抽出処理フローの例を示す図である。抽出部１０３７は、第２テストケース毎に以下の処理を繰り返す（Ｓ４８０１）。抽出部１０３７は、第２テストケースのパス条件と同じパス条件を有する第３テストケースがあるか否かを判定する（Ｓ４８０３）。つまり、抽出部１０３７は、第２テストケースのパス条件と同じパス条件を有する第３テストケースが第３テストケース記憶部１０３９に格納されているか否かを判定する。第２テストケースのパス条件と同じパス条件を有する第３テストケースがあると判定した場合には、抽出部１０３７はＳ４８０７へ処理を進める。

第２テストケースのパス条件と同じパス条件を有する第３テストケースがないと判定した場合には、抽出部１０３７は、第２テストケースを第３テストケースに加える（Ｓ４８０５）。つまり、抽出部１０３７は、第２テストケースを第３テストケース格納部１０３９に格納する。抽出部１０３７は、すべての第２テストケースについて処理したか否かを判定する（Ｓ４８０７）。処理していない第２テストケースがあると判定した場合には、Ｓ４８０１に戻る。すべての第２テストケースについて処理したと判定した場合には、抽出部１０３７は、第３テストケースセットを出力して（Ｓ４８０９）、終了する。

上述のパス条件更新処理とテストケース抽出処理は、連続して行ってもよく、又は別に行ってもよい。パス条件更新処理とテストケース抽出処理を行うことによって、制御変数を用いたシンボリック実行により高めたコードカバレッジを低下させることなく、テストケースを削減することができる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上述の機能ブロック構成は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した各記憶領域の構成は一例であって、必ずしも上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べたテストケース生成装置は、コンピュータ装置であって、図４９に示すように、メモリ２５０１とＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２５０３とハードディスク・ドライブ（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた実施の形態をまとめると、以下のようになる。

第１の実施の形態に係るプログラムは、（Ａ）テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、制御変数に応じたオブジェクト型変数の初期化とテスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出されるテスト対象のプログラムにおける実行パターン毎に、ドライバ及びテスト対象のプログラムの実行において一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、第１のパス条件と第１のパス条件に対する一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、（Ｂ）実行パターン毎に、テスト対象のプログラムの実行において状態としてオブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、（Ｃ）実行パターン毎に、第１のテストケースに含まれる第１のパス条件から、制御変数が満たすべき条件を省き、第２のパス条件を加えた第３のパス条件を求め、第３のパス条件と一又は複数のシンボル変数の充足値とを含む第２のテストケースを生成する第２の生成処理と、（Ｄ）第３のパス条件が同義である第２のテストケースが複数ある場合に、第３のパス条件が同義である複数の第２のテストケースのうち、いずれかの第２のテストケースを省き、残った第２のテストケースを抽出する抽出処理とをコンピュータに実行させる。

上で述べたようなシンボリック実行処理を実行するので、オブジェクト型変数の状態に関する分岐処理を含むテスト対象のプログラムにおけるテストケースのカバレッジを向上させることができる。

更に、上で述べたようにテストケースを絞り込んでいるので、カバレッジの向上に寄与しないテストケースを排除することができる。つまり、制御変数が満たすべき条件が異なるテストケース同士でも、もしそれらの第２のパス条件が共通であるならば、テスト対象プログラムにおける実行ルートは同じになる。従って、いずれかのテストケースを省くことにより無駄を減らすことができる。

また、上記シンボリック実行処理において、テスト対象のプログラムに含まれる複数の命令のうち、実行すべき命令を特定するようにしてもよい。この場合、上記第１の生成処理において、実行すべき命令に含まれる変数の実体を参照するための位置を特定し、オブジェクト型変数の実体が格納されている位置と参照するための位置が一致する場合に、実行すべき命令に基づいて第２のパス条件を生成するようにしてもよい。

このようにすれば、実行すべき命令に含まれる変数の実体を参照するための位置が、オブジェクト型変数の実体が格納されている位置と一致する場合に、実行すべき命令に基づいて第２のパス条件を生成するので、シンボル変数ではないオブジェクト型変数についてもパス条件を求めることができる。

また、上記シンボリック実行処理において、ドライバに含まれ、且つオブジェクト型変数を含む第１の命令を特定し、更に、第１の命令に基づいてオブジェクト型変数を特定し、特定されたオブジェクト型変数の実体が格納されている位置を特定する特定処理をコンピュータに実行させるようにしてもよい。

このようにすれば、ドライバに含まれる第１の命令に基づいてオブジェクト型変数を特定し、オブジェクト型変数の実体が格納されている位置を特定するので、ドライバから第２のパス条件の生成を指示できるようになる。従って、テスト対象のプログラムに手を加えることを要しない。

また、上記第２の生成処理において、第２のパス条件を制御変数が満たすべき条件の形式に変換するようにしてもよい。

このようにすれば、第２のパス条件を制御変数が満たすべき条件の形式に変換するので、オブジェクト型変数の状態に関する分岐におけるパス条件とシンボル変数の充足値を、ともに制御変数で表すことになり、これらの関係が把握されやすくなる。

上記状態は、オブジェクト型変数がnullであるか否かにより特定されるものであってもよい。

このようにすれば、オブジェクト型変数がnullであるか否かによる分岐を含むプログラムのテストケースを生成することができる。

上記状態は、オブジェクト型変数のクラス型により特定されるものであってもよい。

このようにすれば、オブジェクト型変数のクラス型による分岐を含むプログラムのテストケースを生成することができる。

上記複数のシンボル変数は、オブジェクト型変数のメンバを示すシンボル変数を含んでもよい。

このようにすれば、オブジェクト型変数のメンバによる分岐を含むプログラムのテストケースを生成することができる。

上記複数のシンボル変数は、テスト対象のプログラムへ入力されるプリミティブ型変数を示すシンボル変数を含んでもよい。

このようにすれば、プリミティブ型変数による分岐を含むプログラムのテストケースを生成することができる。

上記抽出処理は、第３のパス条件が同義である複数の第２のテストケースのうち、一つの第２のテストケース以外を省くようにしてもよい。

このようにすれば、テストケースを少なくすることができる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、
前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、
前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成処理と、
前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出処理と、
をコンピュータに実行させるためのプログラム。

（付記２）
前記シンボリック実行処理において、前記テスト対象のプログラムに含まれる複数の命令のうち、実行すべき命令を特定し、
前記第１の生成処理において、前記実行すべき命令に含まれる変数の実体を参照するための位置を特定し、前記オブジェクト型変数の実体が格納されている位置と前記参照するための位置が一致する場合に、前記実行すべき命令に基づいて前記第２のパス条件を生成する
付記１記載のプログラム。

（付記３）
前記シンボリック実行処理において、前記ドライバに含まれ、且つ前記オブジェクト型変数を含む第１の命令を特定し、
更に、前記第１の命令に基づいて前記オブジェクト型変数を特定し、特定された前記オブジェクト型変数の前記実体が格納されている前記位置を特定する特定処理をコンピュータに実行させる
付記２記載のプログラム。

（付記４）
前記第２の生成処理において、前記第２のパス条件を前記制御変数が満たすべき条件の形式に変換する
付記１乃至３のいずれか１つ記載のプログラム。

（付記５）
前記状態は、前記オブジェクト型変数がnullであるか否かにより特定される
付記１乃至４のいずれか１つ記載のプログラム。

（付記６）
前記状態は、前記オブジェクト型変数のクラス型により特定される
付記１乃至４のいずれか１つ記載のプログラム。

（付記７）
前記複数のシンボル変数は、前記オブジェクト型変数のメンバを示すシンボル変数を含む
付記１乃至６のいずれか１つ記載のプログラム。

（付記８）
前記複数のシンボル変数は、前記テスト対象のプログラムへ入力されるプリミティブ型変数を示すシンボル変数を含む
付記１乃至７のいずれか１つ記載のプログラム。

（付記９）
前記抽出処理は、前記第３のパス条件が同義である前記複数の第２のテストケースのうち、一つの前記第２のテストケース以外を省く
付記１乃至８のいずれか１つ記載のプログラム。

（付記１０）
テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、
前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、
前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成処理と、
前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出処理と、
を含みコンピュータが実行するテストケース生成方法。

（付記１１）
テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行を行う実行部と、
前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成部と、
前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成部と、
前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出部と、
を有するテストケース生成装置。

７０１ シンボル変数宣言エリア ７０３ 対象クラス初期化エリア
７０５ 初期化コードエリア ７０７ オブジェクト指定命令エリア
７０９ 対象メソッドの呼び出しエリア １００１ 受付部
１００３ 対象クラス格納部 １００５ ライブラリ格納部
１００７ サンプルフォーム格納部 １００９ ドライバ生成部
１０１１ ドライバ格納部 １０１３ 制御変数テーブル生成部
１０１５ 制御変数テーブル格納部 １０１７ 実行部
１０１９ パターンテーブル格納部 １０２１ シンボル変数テーブル記憶部
１０２３ 特定部 １０２５ オブジェクトテーブル記憶部
１０２７ 第１テストケース格納部 １０２９ 第１生成部
１０３１ オブジェクトパス条件記憶部 １０３３ 第２生成部
１０３５ 第２テストケース格納部 １０３７ 抽出部
１０３９ 第３テストケース格納部 １０４１ テストケース出力部

Claims (6)

1. テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、
   前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、
   前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成処理と、
   前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出処理と、
   をコンピュータに実行させるためのプログラム。
2. 前記シンボリック実行処理において、前記テスト対象のプログラムに含まれる複数の命令のうち、実行すべき命令を特定し、
   前記第１の生成処理において、前記実行すべき命令に含まれる変数の実体を参照するための位置を特定し、前記オブジェクト型変数の実体が格納されている位置と前記参照するための位置が一致する場合に、前記実行すべき命令に基づいて前記第２のパス条件を生成する
   請求項１記載のプログラム。
3. 前記シンボリック実行処理において、前記ドライバに含まれ、且つ前記オブジェクト型変数を含む第１の命令を特定し、
   更に、前記第１の命令に基づいて前記オブジェクト型変数を特定し、特定された前記オブジェクト型変数の前記実体が格納されている前記位置を特定する特定処理をコンピュータに実行させる
   請求項２記載のプログラム。
4. 前記第２の生成処理において、前記第２のパス条件を前記制御変数が満たすべき条件の形式に変換する
   請求項１乃至３のいずれか１つ記載のプログラム。
5. テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行処理と、
   前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成処理と、
   前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成処理と、
   前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出処理と、
   を含みコンピュータが実行するテストケース生成方法。
6. テスト対象のプログラムへ入力されるオブジェクト型変数の状態を示す制御変数を含む一又は複数のシンボル変数を用いて、前記制御変数に応じた前記オブジェクト型変数の初期化と前記テスト対象のプログラムの呼び出しを行うためのドライバ及び呼び出される前記テスト対象のプログラムにおける実行パターン毎に、前記ドライバ及び前記テスト対象のプログラムの実行において前記一又は複数のシンボル変数が満たすべき第１のパス条件を計算し、前記第１のパス条件と前記第１のパス条件に対する前記一又は複数のシンボル変数の充足値とを含む第１のテストケースを生成するシンボリック実行を行う実行部と、
   前記実行パターン毎に、前記テスト対象のプログラムの実行において前記状態として前記オブジェクト型変数が満たすべき第２のパス条件を生成する第１の生成部と、
   前記実行パターン毎に、前記第１のテストケースに含まれる前記第１のパス条件から、前記制御変数が満たすべき条件を省き、前記第２のパス条件を加えた第３のパス条件を求め、前記第３のパス条件と前記一又は複数のシンボル変数の前記充足値とを含む第２のテストケースを生成する第２の生成部と、
   前記第３のパス条件が同義である前記第２のテストケースが複数ある場合に、前記第３のパス条件が同義である複数の前記第２のテストケースのうち、いずれかの前記第２のテストケースを省き、残った前記第２のテストケースを抽出する抽出部と、
   を有するテストケース生成装置。

Images