JP2010267023A - テストデータ生成方法及び装置及びプログラム - Google Patents

Abstract

【課題】 テストデータを自動生成し、さらに、設計モデルの記述労力を削減する。
【解決手段】 本発明は、ユーザ端末より、ＵＭＬクラス図とアクティビティ図のみで記述した設計モデルを読み込み、設計モデルからアクティビティ図をテスト対象として抽出し、テスト対象から実行経路を抽出する。抽出された各実行経路の制約条件に基づいて、テストデータ仕様を更新する。テストデータ仕様を読み込み、因子毎に、「水準」を生成し、因子と水準の組み合わせである「入力」に対する実行経路を取得し、「入力」が実行経路にとって許容する入力である正常入力、または、該実行経路にとって許容しない入力である異常入力のいずれであるか、及び、実行経路中に事後条件が含まれるか否かにより期待値を求め、「入力」に該期待値を付与したテストデータを生成する。
【選択図】 図１

Description

本発明は、テストデータ生成方法及び装置及びプログラムに係り、特に、プログラム開発工程において、設計モデルに記述された設計意図の通りにシステムが構築されたか否かを確認するためのテストで用いるテストデータを人手により作成するのではなく、設計モデルにより自動的に作成するためのテストデータ生成方法及び装置及びプログラムに関する。

プログラム開発工程におけるテストでは、システムが設計どおりに構築されたか否かという確認を行うため、テストデータを用いる。当該テストデータを構築するために、人手に依らず自動でテストデータを準備できれば開発コストの改善が期待できる。

そのためのテストデータの自動生成技術として、プログラム中で扱う数値や論理値などの基本データ型に対応させてテストデータを生成する技術がある（例えば、非特許文献１参照）。しかし、当該技術では、階層構造を持つデータ型を多用する現実的なシステムへの適用には隔たりがある。そこで、階層構造を持つ複雑なデータ型を基本型にまで分解し、その各基本型に対して所定の値を与えることによりテストデータを生成する技術がある（例えば、特許文献１参照）。しかし、当該技術では、システム内部の実行経路を考慮していないため、効果的なテストデータが生成できないという問題がある。

また、設計モデルに基づいてテストデータを自動生成する技術がある（例えば、非特許文献２参照）。しかし、当該技術は、テストデータ自動生成の入力となる設計モデルを、利用者にとって難解な記法や独自の記法を用いて作成しなければならないため、利用障壁が高いという問題がある。

さらに、テストデータの自動生成の入力が、設計モデルであるか否かによらず、一般的に、特定実行経路をテストするためのテストデータ生成は、解くのが難しいとされる「制約充足問題」の一種である。動的な探索により適切な解を見つける手法がある（例えば、非特許文献３参照）。しかし、探索を用いた手法ではトライアンドエラーによる生成であるため、テストデータの網羅性を確保できないのが難点である。

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

Jon Edvardsson. "A Survey on Automatic Test Data Generation". In Proceedings of the 2nd Conference on Computer Science and engineering, pages 21-28, 1999. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.963 Eddie, Jaffuel, Bruno Legeard, "LEIRIOS Test Generator: Automated Test Generation from B Models", Lecture Notes in computer Science, Volume 4355, pages 277-280, 2006. http://www.springerlink.com/content/026252518x28211h/ Mark Harman, "Automated Test Data Generation using Search Based software Engineering, In Proceedings of the Second international Workshop on Automation of Software Test, International Conference on Software engineering. IEEE Computer Society, 2007. http://portal.acm.org/citation. cfm?id=127230.1270255

上記のように、従来の設計モデルを用いて特定実行経路のためのテストデータを生成する技術は、トライアンドエラーによる生成手法を用いるため、確実にテストデータの網羅性を保証できないという問題は解決できない。

本発明は、上記の点に鑑みなされたもので、構造体やオブジェクト型データを含む設計モデルに基づくシステムへのテストデータを自動生成することが可能で、さらに、設計モデルの記述労力の削減を可能とするテストデータ生成方法及び装置及びプログラムを提供することを目的とする。

図１は、本発明の原理構成図である。

本発明（請求項１）は、システムの設計情報を形式的な言語で記述した設計モデルの設計意図に沿って、システムが構築されたか否かを確認するためのテストデータを生成するテストデータ生成装置であって、
ユーザ端末より、ＵＭＬクラス図とアクティビティ図のみで記述した設計モデルを読み込む設計モデル読込手段１と、
読み込まれた設計モデルからアクティビティ図をテスト対象として抽出する設計モデル分析手段２と、
テスト対象から実行経路を抽出する実行経路抽出手段３と、
実行経路抽出手段３から抽出された各実行経路を持つアクティビティの入力パラメータを変数（実験計画法でいう「因子」）とし、該変数が満たすべき制約条件を実行経路の始点ノードから終点ノードを走査することで抽出し、該制約条件及び変数の型に基づいて、テストデータ仕様記憶手段８に格納されているテストデータ仕様を更新するテストデータ仕様生成手段４と、
テストデータ仕様記憶手段８からテストデータ仕様を読み込み、該テストデータ仕様毎に、因子のとる値（実験計画法でいう「水準」）を生成し、該因子と該水準を記憶手段に格納する水準生成手段５と、
因子と水準を取得して、該因子と該水準の組み合わせである「入力」に対する実行経路を取得し、該「入力」が実行経路にとって許容する入力である正常入力、または、該実行経路にとって許容しない入力である異常入力のいずれであるか、及び、実行経路中に事後条件が含まれるか否かにより期待値を求め、該「入力」に該期待値を付与したテストデータを生成する組み合わせ手段６と、
テストデータをユーザ端末に出力する出力手段７と、を有する。

また、本発明（請求項２）のテストデータ仕様生成手段３は、
テストデータ仕様が、オブジェクト型であるとき、
制約条件に含まれるオペレータが「null(ヌル)でない」の場合は、テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「Nullを許容しない」ことを記録する手段と、
制約条件に含まれるオペレータが「nullである」の場合は、テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「nullを許容する」ことを記録する手段と、
制約条件に含まれるオペレータが上記以外である場合は、テストデータ仕様記憶手段のテストデータ仕様に含まれる各属性の仕様の列を取得して、該テストデータ仕様の因子名と制約条件に含まれる因子名を比較して、一致する場合には、該制約条件を用いて該テストデータ仕様を更新する手段と、を含む。

また、本発明（請求項３）の水準生成手段５は、
テストデータ仕様が、オブジェクト型であるとき、水準を生成せず、
組み合わせ生成手段６は、
テストデータ仕様が、オブジェクト型であるとき、
オブジェクト型の階層構造を展開した際に、リーフのいずれかに異常を含む組み合わせをオブジェクト型の異常水準として生成し、全て正常である組み合わせを正常水準として生成する手段を含む。

また、本発明（請求項４）の組み合わせ生成手段６は、
水準生成手段５で求められた全因子の全ての正常水準を取得し、全因子の中で最も正常水準を多く持つ因子Ａの正常水準数を特定し、該因子Ａの正常水準を該正常水準数だけテストデータの正常入力に設定し、該因子Ａ以外の各因子については、該因子の正常水準をテストデータに設定する手段と、
水準生成手段５で求められた全因子の全ての異常水準を取得し、該異常水準数を特定し、生成した正常入力を異常入力に上書きする手段と、を含む。

図２は、本発明の原理を説明するための図である。

本発明（請求項５）は、システムの設計情報を形式的な言語で記述した設計モデルの設計意図に沿って、システムが構築されたか否かを確認するためのテストデータを生成するテストデータ生成方法であって、
ユーザ端末より、ＵＭＬクラス図とアクティビティ図のみで記述した設計モデルを読み込む設計モデル読込ステップ（ステップ１）と、
読み込まれた設計モデルからアクティビティ図をテスト対象として抽出する設計モデル分析ステップ（ステップ２）と、
テスト対象から実行経路を抽出する実行経路抽出ステップ（ステップ３）と、
抽出された各実行経路を持つアクティビティの入力パラメータを変数（実験計画法でいう「因子」）とし、該変数が満たすべき制約条件を実行経路の始点ノードから終点ノードを走査することで抽出し、該制約条件及び変数の型に基づいて、テストデータ仕様記憶手段に格納されているテストデータ仕様を更新するテストデータ仕様生成ステップ（ステップ４）と、
テストデータ仕様記憶手段からテストデータ仕様を読み込み、該テストデータ仕様毎に、因子のとる値（実験計画法でいう「水準」）を生成し、該因子と該水準を記憶手段に格納する水準生成ステップ（ステップ５）と、
因子と水準を取得して、該因子と該水準の組み合わせである「入力」に対する実行経路を取得し、該「入力」が実行経路にとって許容する入力である正常入力、または、該実行経路にとって許容しない入力である異常入力のいずれであるか、及び、実行経路中に事後条件が含まれるか否かにより期待値を求め、該「入力」に該期待値を付与したテストデータを生成する組み合わせステップ（ステップ６）と、
テストデータをユーザ端末に出力する出力ステップ（ステップ７）と、を行う。

また、本発明（請求項６）は、テストデータ仕様生成ステップにおいて、
テストデータ仕様が、オブジェクト型であるとき、
制約条件に含まれるオペレータが「null(ヌル)でない」の場合は、テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「Nullを許容しない」ことを記録し、
制約条件に含まれるオペレータが「nullである」の場合は、テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「nullを許容する」ことを記録し、
制約条件に含まれるオペレータが上記以外である場合は、テストデータ仕様記憶手段のテストデータ仕様に含まれる各属性の仕様の列を取得して、該テストデータ仕様の因子名と制約条件に含まれる因子名を比較して、一致する場合には、該制約条件を用いて該テストデータ仕様を更新する。

また、本発明（請求項７）は、水準生成ステップにおいて、テストデータ仕様が、オブジェクト型であるとき、水準は生成せずに、
組み合わせ生成ステップにおいて、オブジェクト型の階層構造を展開した際に、リーフのいずれかに異常を含む組み合わせをオブジェクト型の異常水準として生成し、全て正常である組み合わせを正常水準として生成する。

また、本発明（請求項８）は、組み合わせステップにおいて、
水準生成ステップで求められた全因子の全ての正常水準を取得し、全因子の中で最も正常水準を多く持つ因子Ａの正常水準数を特定し、該因子Ａの正常水準を該正常水準数だけテストデータの正常入力に設定し、該因子Ａ以外の各因子については、該因子の正常水準をテストデータに設定し、
全因子の全ての異常水準を取得し、該異常水準数を特定し、生成した正常入力を異常入力に上書きする。

本発明（請求項９）は、請求項１乃至４記載のいずれか１項記載のテストデータ生成装置を構成する各手段としてコンピュータを機能させるためのテストデータ生成プログラムである。

上記のように本発明によれば、基本データ型（Boolean型、Enum型、Integer型、String型）に対するテストデータ仕様を作成すると共に、それらを組み合わせたオブジェクト型テストデータ仕様を定義することで、複雑なデータ構造にも対応可能となる。これにより、階層構造を扱った現実的なシステムにおいてもテストデータ生成が利用可能である。

また、特殊な言語を使わずに、入力となる設計モデルを標準的なＵＭＬのクラス図とアクティビティ図のみとし、アクティビティ図を走査し、実行経路途中の制約条件に従ってテストデータ仕様を更新することで、テストデータ生成の適用障壁を低減させることが可能となる。

本発明の原理構成図である。 本発明の原理を説明するための図である。 本発明で用いるＵＭＬ設計モデルのイメージを示す図である。 本発明の一実施の形態におけるテストデータ生成装置の構成図である。 本発明の一実施の形態におけるテストデータ仕様のフォーマットを示す図である。 本発明の一実施の形態におけるテストデータ生成装置の入出力イメージである。 本発明の一実施の形態におけるテストデータ生成処理概要のフローチャートである。 本発明の一実施の形態における実行経路抽出部で抽出される実行経路の例である。 本発明の一実施の形態におけるテストデータ仕様生成部のフローチャートである。 本発明の一実施の形態における実行経路を説明するための図である。 本発明の一実施の形態におけるテストデータ仕様の初期化の例である。 本発明の一実施の形態におけるテストデータ仕様の初期化時のデフォルト値である。 本発明の一実施の形態におけるテストデータ仕様生成部のテストデータ仕様の更新のフローチャートである。 本発明の一実施の形態における制約条件によるテストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるステップ５２０の詳細なフローチャートである。 本発明の一実施の形態におけるBoolean型テストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるEnum型テストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるInteger型テストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるString型テストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるObject型テストデータ仕様の更新のフローチャートである。 本発明の一実施の形態におけるObject型テストデータ仕様の更新の例である。 本発明の一実施の形態における水準生成のフローチャートである。 本発明の一実施の形態におけるBoolean型テストデータ仕様からの水準生成のフローチャートである。 本発明の一実施の形態におけるEnum型テストデータ仕様からの水準生成のフローチャートである。 本発明の一実施の形態におけるInteger型テストデータ仕様からの水準生成のフローチャートである。 本発明の一実施の形態におけるString型テストデータ仕様からの水準生成のフローチャートである。 本発明の一実施の形態におけるステップ１６４２の詳細な動作のフローチャートである。 本発明の一実施の形態におけるステップ１６４３の詳細な動作のフローチャートである。 本発明の一実施の形態におけるObject型テストデータ仕様からの水準生成のフローチャートである。 本発明の一実施の形態におけるステップ１６５７の詳細なフローチャートである。 本発明の一実施の形態における水準設定の例である。 本発明の一実施の形態における組み合わせ生成部の処理のフローチャートである。 本発明の一実施の形態における正常入力の生成のフローチャートである。 本発明の一実施の形態における異常入力の生成のフローチャートである。 本発明の一実施の形態における入力に期待値を付与する処理のフローチャートである。

以下、図面と共に本発明の実施の形態を説明する。

最初に、以下の説明で用いられる用語について説明する。

「設計モデル」とは、図３に示すように、システムの設計情報を、曖昧性を持つ自然言語ではなく、何らかの形式的な記述言語により厳密的・形式的に記述したものである。図３は、ＵＭＬ設計モデルの例であり、クラス図とアクティビティ図を示しており、これがユーザ端末側からモデリングツールによりＸＭＬファイルにエクスポートされる。

「制約条件」とは、『ａ＞３』のようなある因子（ここではａ）の取り得る値に関する条件を指す。『ａ＞３』の例では、制約条件は因子の名前（ａ）、オペレータ（＞）、オペランド（３）から成り、当該制約条件が付けられている場所により、「不変条件」、「事前条件」、「分岐条件」の３種類に分かれる。制約条件のオペレータには、不等号や文字列比較等通常使われる記法を用いる。

「テストデータ仕様」とは、設計モデル中の特定の実行経路を通るための因子（変数）が満たすべき性質を集めたもので、テストデータが満たすべき「仕様」を指す。

「テストデータ仕様の更新」とは、テストデータ仕様を、生成直後の初期値から実行経路中の制約条件の処理に従って上書きしていくことである。

図４は、本発明の一実施の形態におけるテストデータ生成装置の構成を示す。

同図に示すテストデータ装置は、設計モデル読込部１、設計モデル分析部２、実行経路抽出部３、テストデータ仕様生成部４、水準生成部５、テストデータ生成部６、出力部７、実行経路・水準記憶部１１、テストデータ仕様記憶部１２、テストデータ記憶部１３から構成される。当該構成において、設計モデル読込部１、設計モデル分析部２、実行経路抽出部３、テストデータ仕様生成部４、水準生成部５、テストデータ生成部６、出力部７は、ＣＰＵ上の機能であり、実行経路・水準記憶部１１、テストデータ仕様記憶部１２、テストデータ記憶部１３は、ハードディスク装置等の記憶媒体である。また、図示しないが各構成要素内に一時的データを記憶するメモリを備えているものとする。

設計モデル読込部１は、ユーザ端末２０のモデリングツール２１からエクスポートされた図３に示すようなＸＭＬ形式のＵＭＬモデル（クラス図、アクティビティ図）を読み込む。

設計モデル分析部２は、読み込まれたＵＭＬモデルを分析して、アクティビティをテスト対象として抽出する。

実行経路抽出部３は、テスト対象から実行経路（Path）を抽出し、テストデータ仕様生成部４及び実行経路・水準記憶部１１に出力する。

テストデータ仕様生成部４は、実行経路抽出部３で抽出された全実行経路のうちの、各実行経路に対して当該実行経路を通るための、変数（実験計画法でいう「因子」）が満たすべき性質を集め、テストデータ仕様記憶部１２に格納する。オブジェクト型テストデータ仕様は、その内部に因子の属性（アトリビュート）のそれぞれのテストデータ仕様を再帰的に持つ。テストデータ仕様は、図５に示すように、データ型毎に異なり、因子を規定するドメインをもつ。ドメインは更新（上書き）されるに従い、範囲が狭められていくものとする。また、データ型は、Integer型、Enum型、Object型、Boolean型、String型、Collection型等がある。但し、Object型テストデータ仕様は、階層構造に対応するため、当該因子の属性のテストデータ仕様を含む。

水準生成部５は、テストデータ仕様記憶部１２からテストデータ仕様を読み込み、因子のとる値（実験計画法でいう「水準」）を生成し、実行経路・水準記憶部１１に格納する。なお、オブジェクト型テストデータ仕様からの水準の生成は、各属性（アトリビュート）がとる値の組み合わせを決める必要があるため、テストデータ生成部６で行う。

テストデータ生成部６は、実行経路・水準記憶部１１から実行経路と水準を取得し、入力と期待値のペアを含むテストデータを生成し、図６（Ｂ）に示すようなフォーマットでテストデータ記憶部１３に格納する。テストデータは、図６（Ｂ）に示すように、実行経路名、テストデータＩＤ、水準（値）、因子（変数）、期待値、正常入力または異常入力区別、テスト結果の項目からなる。なお、「入力」とは、因子と水準の組み合わせである。オブジェクト型テストデータ仕様からの水準の生成は、当該テストデータ生成部６の入力生成を利用する。オブジェクト型の階層構造を展開した際に、（リーフ）のどこかに異常を含むような組み合わせを、オブジェクト型の「異常水準」として生成し、全て正常であるような組み合わせを、オブジェクト型の「正常水準」として生成する。ここで「正常水準」とは、実行経路にとって許容する入力値であり、「異常水準」とは、実行経路にとって許容しない入力値をさす。

出力部７は、テストデータ生成部６で生成されたテストデータをテストデータ記憶部１３から読み出してユーザ端末２０に出力する。ここでは、ＣＳＶ形式で出力するものとする。

上記の構成における動作を説明する。

図７は、本発明の一実施の形態におけるテストデータ生成処理概要のフローチャートである。

ステップ１００） 設計モデル読込部１は、ユーザ端末２０から図６（Ａ）に示すようなＵＭＬ設計モデルを読み込む。

ステップ１１０） 設計モデル分析部２は、ＵＭＬ設計モデルを分解し、アクティビティをテスト対象として抽出する。

ステップ１２０） 実行経路抽出部３は、図８に示すように、アクティビティについて開始ノードから終了ノードまで走査し、実行経路を抽出し、テストデータ仕様生成部４と実行経路・水準記憶部１１に出力する。

ステップ１３０） テストデータ仕様生成部４は、実行経路抽出部３から取得した実行経路を内部のメモリ（図示せず）に格納し、図９に示す処理を行い、生成されたテストデータ仕様をテストデータ仕様記憶部１２に格納する。当該処理については後述する。

ステップ１４０） 水準生成部５は、テストデータ仕様記憶部１２からテストデータ仕様を読み込んで、各テストデータ仕様について図２２に示す処理を行うことにより水準を生成する。詳細については後述する。なお、水準生成部５は、生成された水準と、テストデータ仕様記憶部１２から取得したテストデータ仕様の「実行経路」の情報を関連付けて実行経路・水準記憶部１１に格納しておくものとする。

ステップ１５０） テストデータ生成部６は、水準生成部５で求められた実行経路に関連付けられた水準を実行経路・水準記憶部１１から取得して、図３２に示す処理を行い、テストデータをテストデータ記憶部１３に格納する。
ステップ１６０） 出力部７は、テストデータ記憶部１３からテストデータを取得してユーザ端末２０のビューア２２に出力する。

以下、テストデータ生成装置の各構成要素の動作を説明する。

＜テストデータ仕様生成部４＞
次に、上記のステップ１３０のテストデータ仕様生成部４の動作を説明する。

図９は、本発明の一実施の形態におけるテストデータ仕様生成部のフローチャートである。

ステップ３００） テストデータ仕様生成部４は、実行経路抽出部３から実行経路を取得しメモリ（図示せず）に格納する。

ステップ３１０） ステップ３００で取得した実行経路を持つアクティビティを取得する。

ステップ３２０） 取得したアクティビティの入力パラメータ（図１０の例では、「p:People」と「flag:Boolean」）を因子として抽出する。

ステップ３３０） 抽出した各因子に対して、テストデータ仕様記憶部１２に、テストデータ仕様のレコードを生成し、初期値を設定する。図１１は、本発明の一実施の形態におけるテストデータ仕様の初期化の例を示す。同図の例は、String型テストデータとInteger型テストデータ仕様を有する因子名「ｐ」のObject型テストデータ仕様の例である。初期化時は、同図（Ａ）に示すように、デフォルト値を埋めておく。また、因子の型（同図の例ではPeople）に付与される。不変条件があれば、同図（Ｂ）に示すようにテストデータ仕様の該当する箇所を不変条件で初期化する。各テストデータ仕様の型毎のデフォルト値を図１２に示す。なお、デフォルト値のMIN、MAXはInteger型がとり得る最大値、最小値を示す。また、nullは特に規定しないことを表す。

ステップ３４０） テストデータ仕様の更新を行う。以下にその詳細を説明する。

図１３は、本発明の一実施の形態におけるテストデータ仕様生成部のテストデータ仕様の更新のフローチャートである。

ステップ４００） 実行経路を取得する。当該実行経路は、図１０に示すように、ノードとエッジから構成される。

ステップ４１０） 実行経路中の全制約条件を取得する。

ステップ４２０） 制約条件に基づいてテストデータ仕様記憶部１２のテストデータ仕様を更新する。詳細については、以下図１４に沿って説明する。

図１４は、本発明の一実施の形態における制約条件によるテストデータ仕様の更新のフローチャートである。

ステップ５００） 実行経路抽出部３から取得した実行経路から制約条件を取得する。

ステップ５１０） テストデータ仕様記憶部１２より１件のテストデータ仕様を取得し、全て取得済みであれば、当該処理を終了する。

ステップ５２０） 未取得のテストデータ仕様がある場合は、テストデータ仕様の因子名と、制約条件に含まれる因子名を比較する。因子名が一致すれば、ステップ５３０に移行し、一致しなければステップ５１０に戻る。

ステップ５３０） テストデータ仕様記憶部１２のテストデータ仕様を、制約条件を用いて更新する。当該制約条件による更新処理については、図１５に沿って説明する。

図１５は、本発明の一実施の形態におけるステップ５２０の詳細なフローチャートである。

ステップ６００） テストデータ仕様記憶部１２から制約条件とテストデータ仕様を取得し、テストデータ仕様の型がどれであるか判断し、各テストデータ仕様の型に基づいて、以下の処理を行う。

ステップ６１０） テストデータ仕様の型が、Boolean型である場合は、制約条件に基づくBoolean型テストデータ仕様の更新を行う。当該処理の詳細については、以下図１６に沿って説明する。Boolean型のテストデータ仕様のフォーマットは図５に示す通りである。

ステップ６１１） 実行経路抽出部３から取得した実行経路から制約条件を取得し、制約条件に含まれるオペレータが、『≠』、『＝』、『その他』のいずれであるか判定する。

ステップ６１２） オペレータが『≠』の場合は、後続するオペランドを取得する。

ステップ６１３） オペランドが「true」か「false」のいずれかであれば、Boolean型テストデータ仕様の『値ｖ』をオペランドの値の「否定」にして更新し、処理を終了する。「true」か「false」のいずれでもない場合はステップ６１６に移行する。

ステップ６１４） 制約条件に含まれるオペレータが『＝』の場合は、後続するオペランドを取得する。

ステップ６１５） オペランドが「true」か「false」のいずれかであれば、Boolean型テストデータ仕様の『値ｖ』をオペランドの値にして更新し、ステップ６１６にする。「true」か「false」のいずれでもない場合は処理を終了する。

ステップ６１６） ステップ６１１において、制約条件に含まれるオペレータが「≠」か「＝」でない場合、及びオペランドが「true」か「false」のいずれでもない場合は、「異常状態」で停止する。

ステップ６２０） テストデータ仕様の型が、Enum型である場合は、制約条件に基づくEnum型テストデータ仕様の更新を行う。当該処理の詳細については、以下図１７に沿って説明する。図１７は、本発明の一実施の形態におけるEnum型テストデータ仕様の更新のフローチャートである。Enum型のテストデータ仕様のフォーマットは図５に示す通りである。

ステップ６２１） 実行経路抽出部３から取得した実行経路から制約条件を取得して、制約条件に含まれるオペレータが『≠』である場合は、ステップ６２２に移行し、『＝』である場合はステップ６２３に移行し、それ以外の場合はステップ６２６に移行する。

ステップ６２２） 後続するオペランドを取得して、オペランドの値が、テストデータ仕様の「許容する要素Ｓ」に含まれるかを判定し、含まれる場合はステップ６２３に移行し、含まれない場合は、ステップ６２６に移行する。

ステップ６２３） Enum型テストデータ仕様の「許容する要素Ｓ」を、Ｓから「オペランドの値」を除いたものに更新し、処理を終了する。

ステップ６２４） 後続するオペランドを取得して、オペランドの値がテストデータ仕様の「許容する要素Ｓ」に含まれるかを判定し、含まれる場合はステップ６２５に移行し、含まれない場合は、ステップ６２６に移行する。

ステップ６２５） Enum型テストデータ仕様の「許容する要素ｓの集合Ｓ」を「オペランドの値」に更新し、処理を終了する。

ステップ６２６） ステップ６２１で制約条件に含まれるオペレータが「≠」、「＝」のいずれでもない場合、または、ステップ６２２，６２４において、オペランドの値が、テストデータの「許容する要素Ｓ」に含まれない場合は、「異常状態」で停止する。

ステップ６３０） テストデータ仕様の型が、Integer型である場合は、制約条件に基づくInteger型テストデータ仕様の更新を行う。当該処理の詳細については、以下図１８に沿って説明する。図１８は、本発明の一実施の形態におけるInteger型テストデータ仕様の更新のフローチャートである。Integer型のテストデータ仕様のフォーマットは図５に示す通りである。

ステップ６３１） 制約条件を取得し、制約条件に含まれるオペレータを判定する。

ステップ６３２） オペレータが「＝」の場合は、後続するオペランドを取得して、Integer型テストデータ仕様の「下限Ｌ」と「上限Ｕ」をオペランドの値に更新し、処理を終了する。

ステップ６３３） オペレータが「＞」の場合は、後続するオペランドを取得して、Integer型テストデータ仕様の「下限Ｌ」をオペランドの値＋１に更新し、処理を終了する。

ステップ６３４） オペレータが「≧」の場合は、後続するオペランドを取得して、Integer型テストデータ仕様の「下限Ｌ」をオペランドの値に更新し、処理を終了する。

ステップ６３５） オペレータが「＜」の場合は、後続するオペランドを取得して、Integer型テストデータ仕様の「上限Ｕ」をオペランドの値−１に更新し、処理を終了する。

ステップ６３６） オペレータが「≦」の場合は、後続するオペランドを取得して、Integer型テストデータ仕様の「上限Ｕ」をオペランドの値に更新し、処理を終了する。

ステップ６３７） ステップ６３１で制約条件に含まれるオペレータが「＝」「＞」「≧」「＜」「≦」のいずれでもない場合には、「異常状態」で停止する。

ステップ６４０） テストデータ仕様の型が、String型である場合は、制約条件に基づくString型テストデータ仕様の更新を行う。当該処理の詳細については、以下、図１９に沿って説明する。図１９は、本発明の一実施の形態におけるString型テストデータ仕様の更新のフローチャートである。String型のテストデータ仕様のフォーマットは図５に示す通りである。

ステップ６４１） 制約条件を取得して、制約条件に含まれるオペレータが「contains」、「＝」、「length」、または、それ以外かを判定する。

ステップ６４２） オペレータが「contains」の場合は、後続するオペランドを取得して、String型テストデータ仕様の「部分文字列ｃ」をオペランドの値に更新する。そして、オペランドの長さがテストデータ仕様の「長さ下限Ｌ」より大きい場合は、String型テストデータ仕様の「長さ下限Ｌ」をオペランドの長さに更新する。

ステップ６４３） オペレータが「＝」の場合は、後続するオペランドを取得して、String型テストデータ仕様の「等しい文字列E」をオペランドの値に更新する。そして、String型テストデータ仕様の「長さ下限Ｌ」と「長さ上限Ｕ」をオペランドの長さに更新する。

ステップ６４４） オペレータが「length」であり、制約条件に更に含まれるオペレータが「＝」の場合は、後続するオペランドを取得して、String型テストデータ仕様の「長さ下限Ｌ」と「長さ上限Ｕ」をオペランドの値に更新する。

ステップ６４５） オペレータが「length」であり、制約条件に更に含まれるオペレータが『＞』の場合は、後続するオペランドを取得して、String型テストデータ仕様の「長さ下限Ｌ」をオペランドの値＋１に更新する。

ステップ６４６） オペレータが「length」であり、制約条件に更に含まれるオペレータが『≧』の場合は、後続するオペランドを取得して、String型テストデータ仕様の「長さ下限Ｌ」をオペランドの値に更新する。

ステップ６４７） オペレータが「length」であり、制約条件に更に含まれるオペレータが『＜』の場合は、後続するオペランドを取得して、String型テストデータ仕様の「長さ上限Ｕ」をオペランドの値−１に更新する。

ステップ６４８） オペレータが「length」であり、制約条件に更に含まれるオペレータが『≦』の場合は、後続するオペランドを取得して、String型テストデータ仕様の「長さ上限Ｕ」をオペランドの値に更新する。

ステップ６４９） 制約条件に含まれるオペレータが「contains」、「＝」、「length」のいずれでもなく、または、オペレータが「length」であっても、制約条件に更に含まれるオペレータが『＝』『＞』『≧』『＜』『≦』以外であれば、「異常状態」で停止する。

ステップ６５０） テストデータ仕様の型が、Object型である場合は、制約条件に基づくObject型テストデータ仕様の更新を行う。当該処理の詳細については、以下、図２０に沿って説明する。図２０は、本発明の一実施の形態におけるObject型テストデータ仕様の更新のフローチャートである。Object型のテストデータ仕様のフォーマットは図５に示す通りである。

ステップ６５１） 制約条件を取得し、当該制約条件に含まれるオペレータを判定する。

ステップ６５２） オペレータが「≠null」（nullでない）」の場合は、Object型テストデータ仕様の「ヌルかｎ」を「false」に更新する。

ステップ６５３） オペレータが「＝null」（nullである）」の場合は、Object型テストデータ仕様の「ヌルかｎ」を「true」に更新する。

ステップ６５４） オペレータが上記の「≠null」「＝null」のいずれでもない場合は、テストデータ仕様の「属性の仕様Ａ」より１件のテストデータ仕様を取得する。

ステップ６５５） 全ての取得済みである場合は、処理を終了し、全て取得済みでない場合は、テストデータ仕様の因子名と、制約条件に含まれる因子名を比較し、一致する場合はステップ６５６に移行し、一致しない場合は、ステップ６５４に移行する。

ステップ６５６） テストデータ仕様を制約条件を用いて更新する。

以下にObject型テストデータ仕様の更新の例を示す。

図２１は、本発明の一実施の形態におけるObject型テストデータ仕様の更新の例を示す。

同図（Ａ）のような入力されたＵＭＬモデル（クラス（因子の型）とアクティビティ）から開始ノードから終了ノードまでの実行経路を取得し、制約条件「p.age>=20」を取得し、オペレータが「≠null」でも「=null」でもないので、因子名ｐ自身ではなく、ｐの属性に関する制約条件であると判断し、テストデータ仕様記憶部１２からｐのテストデータ仕様のうち、各属性の仕様Ａの列要素の１つ１つを取得し、１件目の「name」のテストデータ仕様を見ると、因子名は不一致である。２件目の「age」のテストデータ仕様を見ると因子名が一致するので、当該テストデータ仕様を更新する。

＜水準生成部４＞
次に、図７のステップ１４０の水準生成部４の処理について説明する。

図２２は、本発明の一実施の形態における水準生成処理のフローチャートである。

ステップ１６００） テストデータ仕様記憶部１２からテストデータ仕様を取得して、テストデータの種類が、Boolean型、Enum型、Integer型、String型、Object型のいずれであるかを判定する。

ステップ１６１０） テストデータ仕様がBoolean型である場合は、図２３の処理により水準を生成し、実行経路に対応付けて実行経路・水準記憶部１１に格納する。図２３は、本発明の一実施の形態におけるBoolean型テストデータ仕様からの水準生成のフローチャートである。

ステップ１６１１） Boolean型テストデータ仕様の「値ｖ」を取得し、「値ｖ」が初期値であるかを判定する。

ステップ１６１２） 初期値である場合は、水準のtrue、falseを正常水準として生成し、実行経路と対応付けて実行経路・水準記憶部１１に格納し、ステップ１６１５に移行する。

ステップ１６１３） 初期値でない場合は、値ｖを正常水準として格納する。

ステップ１６１４） 値ｖの否定を異常水準として格納する。

ステップ１６１５） null、Boolean型でない値を異常水準として格納する。

ステップ１６２０） テストデータ仕様がEnum型である場合は、図２４の処理によりEnum型のテストデータ仕様からの水準を生成し、実行経路に対応付けて実行経路・水準記憶部１１に格納する。図２４は、本発明の一実施の形態におけるEnum型テストデータ仕様からの水準生成のフローチャートである。

ステップ１６２１） Enum型テストデータ仕様の許容する要素ｓの集合Ｓを取得する。

ステップ１６２２） 許容する要素ｓの集合Ｓ内の各要素ｓを正常水準として格納する。

ステップ１６２３） 因子の全選択肢のうち、許容する要素ｓの集合に属さない各要素ｓ'を異常水準として格納する。

ステップ１６２４） null、Enum型でない値を異常水準として格納する。

ステップ１６３０） テストデータ仕様がInteger型である場合は、図２５の処理によりInteger型のテストデータ仕様からの水準を生成し、実行経路と対応付けて実行経路・水準記憶部１１に格納する。図２５は、本発明の一実施の形態におけるInteger型テストデータ仕様からの水準生成のフローチャートである。

ステップ１６３１） Integer型テストデータ仕様の「下限Ｌ」、「上限Ｕ」を取得する。

ステップ１６３２） Ｌ，Ｌ＋１，Ｕ−１，Ｕを正常水準としてに格納する。

ステップ１６３３） ランダム値ｘ（Ｌ≦ｘ≦Ｕ）を正常水準として格納する。

ステップ１６３４） Ｌ−１，Ｕ＋１を異常水準として格納する。

ステップ１６３５） 正、負でオーバーフローとなる値を異常水準として格納する。

ステップ１６３６） null、Integer型でない値を異常水準として格納する。

ステップ１６４０） テストデータ仕様がString型である場合は、図２６の処理によりString型テストデータ仕様からの水準を生成し、実行経路と対応付けて実行経路・水準記憶部１１に格納する。図２６は、本発明の一実施の形態におけるString型テストデータ仕様からの水準生成のフローチャートである。

ステップ１６４１） String型テストデータ仕様の「長さ下限Ｌ」、「長さ上限Ｕ」、「部分文字列Ｃ」、「等しい文字列Ｅ」を取得する。

ステップ１６４２） 上記の「長さ下限Ｌ」、「長さ上限Ｕ」、「部分文字列Ｃ」、「等しい文字列Ｅ」に基づいて正常水準を生成し、実行経路と対応付けて実行経路・水準記憶部１１に格納する。以下、図２７を用いて詳細な処理を説明する。本発明の一実施の形態におけるステップ１６４２の詳細な処理のフローチャートである。

ステップ２２００） 「等しい文字列Ｅ」が設定済みの場合は、Ｅを正常水準として格納し、当該水準生成部の５の処理を終了する。

ステップ２２１０） 「等しい文字列Ｅ」が未設定であり、「部分文字列Ｃ」が設定済みの場合は、長さＬのＣを含むランダム文字列を正常水準として格納する。

ステップ２２２０） 長さＬ＋１の部分文字列Ｃを含むランダム文字列を正常水準として格納する。

ステップ２２３０） 長さＵ−１の部分文字列Ｃを含むランダム文字列を正常水準として格納する。

ステップ２２４０） 長さＵの部分文字列Ｃを含むランダム文字列を正常水準として格納し、当該水準生成部５の処理を終了する。

ステップ２２５０） 「等しい文字列Ｅ」が設定済みで、「部分文字列Ｃ」が設定済みである場合は、長さＬのランダム文字列を正常水準として格納する。

ステップ２２６０） 長さＬ＋１のランダム文字列を正常水準として格納する。

ステップ２２７０） 長さＵ−１のランダム文字列を正常水準として格納する。

ステップ２２８０） 長さＵのランダム文字列を正常水準として格納し、当該水準生成部５の処理を終了する。

ステップ１６４３） 上記の「長さ下限Ｌ」、「長さ上限Ｕ」、「部分文字列Ｃ」、「等しい文字列Ｅ」に基づいて異常水準を生成し、実行経路と対応付けて実行経路・水準記憶部１１に格納する。以下に、図２８を用いて当該処理を詳細な処理について説明する。図２８は、本発明の一実施の形態におけるステップ１６４３の詳細な動作のフローチャートである。

ステップ２３００） 「等しい文字列Ｅ」が設定済みであり、長さＬの部分文字列Ｃでない文字列を異常水準として格納する。

ステップ２３０５） 長さＵ＋１の等しい文字列Ｅでない文字列を異常水準としてメモリ（図示せず）に格納する。

ステップ２３１０） 長さＬ−１の等しい文字列Ｅでない文字列を異常水準として格納し、ステップ２３６０に移行する。

ステップ２３２０） 「等しい文字列Ｅ」が未設定であり、「部分文字列Ｃ」が設定済みである場合は、長さＬの部分文字列Ｃを含まない文字列を異常水準として格納する。

ステップ２３２５） 長さＵの部分文字列Ｃを含まない文字列を異常水準として格納する。

ステップ２３３０） 長さＬ−１の部分文字列Ｃを含まない文字列を異常水準として格納する。

ステップ２３３５） 長さＵ＋１の部分文字列Ｃを含まない文字列を異常水準として格納する。

ステップ２３５０） 長さＬ−１の部分文字列Ｃを含む文字列を異常水準として格納する。

ステップ２３４５） 長さＵ＋１の部分文字列Ｃを含む文字列を異常水準として格納し、ステップ２３６０に移行する。

ステップ２３５０） 等しい文字列Ｅが未設定で、部分文字列Ｃが未設定である場合は、長さＬ−１のランダム文字列を異常水準として格納する。

ステップ２３５５） 長さＬ＋１のランダム文字列を異常水準として格納し、ステップ２３６０に移行する。

ステップ１６５０） テストデータ仕様がObject型である場合、図２９の処理により、Object型テストデータ仕様から水準を生成し、実行経路と対応づけて実行経路・水準記憶部１１に格納する。図２９は、本発明の一実施の形態におけるObject型テストデータ仕様からの水準生成のフローチャートである。

ステップ１６５１） Object型テストデータ仕様の「nullかｎ」、「属性の仕様Ａ」を取得する。

ステップ１６５２） 「nullかｎ」が未設定であり、「属性の仕様Ａ」が空である場合は、任意のObjectを正常水準としてメモリ（図示せず）に格納し、当該処理を終了する。

ステップ１６５３） 「nullかｎ」が"true"である場合は、「null」を正常水準として格納する。

ステップ１６５４） 任意のObject(non-null)を異常水準として格納し、当該処理を終了する。

ステップ１６５５） 「nullかｎ」が"false"であり、「属性の仕様Ａ」が空である場合は、任意のObject(non-null)を正常水準として格納する。

ステップ１６５６） 「null」を異常水準として格納して当該処理を終了する。

ステップ１６５７） 「nullかｎ」が"false"であり、「属性の仕様Ａ」が空でない場合は、仕様Ａに含まれるテストデータ仕様に基づく水準を実行経路と対応付けて実行経路・水準記憶部１１に格納し、当該処理を終了する。当該処理の詳細については、図３０に沿って説明する。図３０は、本発明の一実施の形態におけるステップ１６５７の詳細なフローチャートである。

ステップ２４００） Object型テストデータ仕様から「属性の仕様Ａ」を取得する。

ステップ２４１０） 取得した属性の仕様Ａに含まれる各テストデータ仕様に対して、前述の図１９に示す方法により水準を生成し、格納する。

ステップ２４２０） テストデータ生成部６において、組み合わせを生成する。詳細な処理については、図３２で詳述する。

ステップ２４３０） テストデータ生成部６で生成された１つの組合せを１つの水準として実行経路・水準記憶部１１に格納する。

上記のようにして、特定実行経路に関する各因子の水準が決定され、図３１に示す内容が実行経路・水準記憶部１１に格納される。

＜組み合わせ生成部＞
次に、図７のステップ１５０におけるテストデータ生成部６の動作について説明する。

図３２は、本発明の一実施の形態における組み合わせ生成部の処理のフローチャートである。

ステップ１２００） テストデータ生成部６は、水準生成部５で求められた全因子の全水準を実行経路・水準記憶部１１から取得する。なお、ここで取得した水準には、実行経路が関連付けられている。

ステップ１２１０） 正常入力の生成を図３３に示す手法により行う。

ステップ１２１１） 全因子より、最も正常水準を多く持つ因子Ａの正常水準数Ｍを特定する。

ステップ１２１２） テストデータ記憶部１３上に、Ｍ件の空の正常入力を生成する。

ステップ１２１３） 因子Ａの正常水準を順番に正常入力に埋める。

ステップ１２１４） 因子Ａ以外の因子については、因子の正常水準を繰り返し正常入力に埋める。

ステップ１２２０） 異常入力の生成を図３４に示す手法により行う。

ステップ１２２１） 全因子より、各因子の異常水準数の合計Ｎを特定する。

ステップ１２２２） テストデータ記憶部１３上に、Ｎ件の空の異常入力を生成する。

ステップ１２２３） 生成した正常入力を繰り返し異常入力に上書きする。

ステップ１２２４） 各異常水準について、どの因子のものかに基づいて、異常水準を異常入力の該当箇所に上書きする。

ステップ１２３０） 上記のステップ１２１０で生成された正常入力及び、ステップ１２２０で生成された異常入力に対して、以下の図３５に示す方法により、入力の期待値を付与する。

ステップ１２３１） 入力に対応する実行経路を取得する。なお、当該実行経路は、水準生成部５で生成された水準と相互に関連付けられているため、当該入力に含まれる水準から実行経路を取得することができる。

ステップ１２３２） 実行経路中の全事後条件を取得する。実行経路はノードとエッジが数珠繋ぎになっているため、当該実行経路の先頭から順にノードをチェックし、当該ノードに事後条件があれば取得する。

ステップ１２３３） 入力が「正常入力」であり、事後条件がある場合は、期待値を事後条件の集合として、テストデータ記憶部１３に格納する。

ステップ１２３４） 入力が「正常入力」であり、事後条件がない場合は、期待値を「未定義」として、テストデータ記憶部１３に格納する。

ステップ１２３５） 入力が「異常入力」である場合は、期待値を「不定」として、テストデータ記憶部１３に格納する。

なお、図４に示すテストデータ生成装置の構成要素の動作をプログラムとして構築し、テストデータ生成装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

また、構築されたプログラムをハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１ 設計モデル読込手段、設計モデル読込部
２ 設計モデル分析手段、設計モデル分析部
３ 実行経路抽出手段、実行経路抽出部
４ テストデータ仕様生成手段、テストデータ仕様生成部
５ 水準生成手段、水準生成部
６ 組み合わせ手段、データ生成部
７ 出力手段、出力部
８ テストデータ仕様記憶手段、テストデータ仕様記憶部
１１ 実行経路・水準記憶部
１２ テストデータ仕様記憶部
１３ テストデータ記憶部

Claims (9)

1. システムの設計情報を形式的な言語で記述した設計モデルの設計意図に沿って、システムが構築されたか否かを確認するためのテストデータを生成するテストデータ生成装置であって、
   ユーザ端末より、ＵＭＬクラス図とアクティビティ図のみで記述した設計モデルを読み込む設計モデル読込手段と、
   読み込まれた前記設計モデルからアクティビティ図をテスト対象として抽出する設計モデル分析手段と、
   前記テスト対象から実行経路を抽出する実行経路抽出手段と、
   前記実行経路抽出手段から抽出された各実行経路を持つアクティビティの入力パラメータを変数（実験計画法でいう「因子」）とし、変数が満たすべき制約条件を実行経路の始点ノードから終点ノードを走査することで抽出し、該制約条件及び変数の型に基づいて、テストデータ仕様記憶手段に格納されているテストデータ仕様を更新するテストデータ仕様生成手段と、
   前記テストデータ仕様記憶手段から前記テストデータ仕様を読み込み、該テストデータ仕様毎に、前記因子のとる値（実験計画法でいう「水準」）を生成し、該因子と該水準を記憶手段に格納する水準生成手段と、
   前記因子と前記水準を取得して、該因子と該水準の組み合わせである「入力」に対する実行経路を取得し、該「入力」が実行経路にとって許容する入力である正常入力、または、該実行経路にとって許容しない入力である異常入力のいずれであるか、及び、実行経路中に事後条件が含まれるか否かにより期待値を求め、該「入力」に該期待値を付与したテストデータを生成する組み合わせ手段と、
   前記テストデータを前記ユーザ端末に出力する出力手段と、
   を有することを特徴とするテストデータ生成装置。
2. 前記テストデータ仕様生成手段は、
   前記テストデータ仕様が、オブジェクト型であるとき、
   前記制約条件に含まれるオペレータが「null(ヌル)でない」の場合は、前記テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「Nullを許容しない」ことを記録する手段と、
   前記制約条件に含まれるオペレータが「nullである」の場合は、前記テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「nullを許容する」ことを記録する手段と、
   前記前記制約条件に含まれるオペレータが上記以外である場合は、前記テストデータ仕様記憶手段のテストデータ仕様に含まれる各属性の仕様の列を取得して、該テストデータ仕様の因子名と前記制約条件に含まれる因子名を比較して、一致する場合には、該制約条件を用いて該テストデータ仕様を更新する手段と、を含む
   請求項２記載のテストデータ生成装置。
3. 前記水準生成手段は、
   前記テストデータ仕様が、オブジェクト型であるとき、前記水準を生成せず、
   前記組み合わせ生成手段は、
   前記テストデータ仕様が、オブジェクト型であるとき、
   オブジェクト型の階層構造を展開した際に、リーフのいずれかに異常を含む組み合わせをオブジェクト型の異常水準として生成し、全て正常である組み合わせを正常水準として生成する手段を含む
   請求項１記載のテストデータ生成装置。
4. 前記組み合わせ生成手段は、
   前記水準生成手段で求められた全因子の全ての正常水準を取得し、全因子の中で最も正常水準を多く持つ因子Ａの正常水準数を特定し、該因子Ａの正常水準を該正常水準数だけテストデータの正常入力に設定し、該因子Ａ以外の各因子については、該因子の正常水準をテストデータに設定する手段と、
   前記水準生成手段で求められた全因子の全ての異常水準を取得し、該異常水準数を特定し、生成した前記正常入力を異常入力に上書きする手段と、
   を含む請求項１記載のテストデータ生成装置。
5. システムの設計情報を形式的な言語で記述した設計モデルの設計意図に沿って、システムが構築されたか否かを確認するためのテストデータを生成するテストデータ生成方法であって、
   ユーザ端末より、ＵＭＬクラス図とアクティビティ図のみで記述した設計モデルを読み込む設計モデル読込ステップと、
   読み込まれた前記設計モデルからアクティビティ図をテスト対象として抽出する設計モデル分析ステップと、
   前記テスト対象から実行経路を抽出する実行経路抽出ステップと、
   抽出された各実行経路を持つアクティビティの入力パラメータを変数（実験計画法でいう「因子」）とし、該変数が満たすべき制約条件を実行経路の始点ノードから終点ノードを走査することで抽出し、該制約条件及び変数の型に基づいて、テストデータ仕様記憶手段に格納されているテストデータ仕様を更新するテストデータ仕様生成ステップと、
   前記テストデータ仕様記憶手段から前記テストデータ仕様を読み込み、該テストデータ仕様毎に、前記因子のとる値（実験計画法でいう「水準」）を生成し、該因子と該水準を記憶手段に格納する水準生成ステップと、
   前記因子と前記水準を取得して、該因子と該水準の組み合わせである「入力」に対する実行経路を取得し、該「入力」が実行経路にとって許容する入力である正常入力、または、該実行経路にとって許容しない入力である異常入力のいずれであるか、及び、実行経路中に事後条件が含まれるか否かにより期待値を求め、該「入力」に該期待値を付与したテストデータを生成する組み合わせステップと、
   前記テストデータを前記ユーザ端末に出力する出力ステップと、
   を行うことを特徴とするテストデータ生成方法。
6. 前記テストデータ仕様生成ステップにおいて、
   前記テストデータ仕様が、オブジェクト型であるとき、
   前記制約条件に含まれるオペレータが「null(ヌル)でない」の場合は、前記テストデータ仕様記憶手段のオブジェクト型テストデータ仕様に「Nullを許容しない」ことを記録し、
   前記制約条件に含まれるオペレータが「nullである」の場合は、前記テストデータ仕様記憶手段に「nullを許容する」ことを記録する、
   前記前記制約条件に含まれるオペレータが上記以外である場合は、前記テストデータ仕様記憶手段のテストデータ仕様に含まれる各属性の仕様の列を取得して、該テストデータ仕様の因子名と前記制約条件に含まれる因子名を比較して、一致する場合には、該制約条件を用いて該テストデータ仕様を更新する
   請求項５記載のテストデータ生成方法。
7. 前記水準生成ステップにおいて、前記テストデータ仕様が、オブジェクト型であるとき、前記水準は生成せずに、
   前記組み合わせ生成ステップにおいて、オブジェクト型の階層構造を展開した際に、リーフのいずれかに異常を含む組み合わせをオブジェクト型の異常水準として生成し、全て正常である組み合わせを正常水準として生成する
   請求項５記載のテストデータ生成方法。
8. 前記組み合わせステップにおいて、
   前記水準生成ステップで求められた全因子の全ての正常水準を取得し、全因子の中で最も正常水準を多く持つ因子Ａの正常水準数を特定し、該因子Ａの正常水準を該正常水準数だけテストデータの正常入力に設定し、該因子Ａ以外の各因子については、該因子の正常水準をテストデータに設定し、
   全因子の全ての異常水準を取得し、該異常水準数を特定し、生成した前記正常入力を異常入力に上書きする
   請求項５記載のテストデータ生成方法。
9. 請求項１乃至４記載のいずれか１項記載のテストデータ生成装置を構成する各手段としてコンピュータを機能させるためのテストデータ生成プログラム。

Images