"システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、を備えるテストケース自動生成システム。前記演算部は、記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせることを特徴とする請求項1に記載のテストケース自動生成システム。システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行することを特徴とするテストケース自動生成方法。システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行させることを特徴とするテストケース自動生成プログラム。従来技術を利用することでテストケースの自動生成は可能である。しかしながら、テストケースの自動生成に利用する設計書については、そのフォーマット等が固定化されているのが前提であって、例えばフォーマットや記載項目が固定基準と異なる設計書について適用することが出来ないという課題が残されている。また、従来技術によって出力されるテストケースの形式が固定であることから、設計書によっては不要な項目についてもテストケースが出力され、更にはその不要なテストケースの実行によって、システム検証の作業量自体が増大するという問題も生じる。一方で、必要なテストケースが出力されないことも起こりうるため、テスト漏れによるシステムの品質低下の事態が生じる恐れもある。そこで本発明の目的は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る技術を提供することにある。上記課題を解決する本発明のテストケース自動生成システムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、を備える。また、本発明のテストケース自動生成方法は、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行することを特徴とする。また、本発明のテストケース自動生成プログラムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行させることを特徴とする。本発明によれば、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。以下に本発明の実施形態について図面を用いて詳細に説明する。図1は、本実施形態のテストケース自動生成システム100の構成例を示す図である。図1に示すテストケース自動生成システム100は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図るコンピュータシステムである。テストケース自動生成システム100のハードウェア構成は例えば以下の如くとなる。前記テストケース自動生成システム100は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶部101、RAMなど揮発性記憶装置で構成されるメモリ103、前記記憶部101に保持されるプログラム102をメモリ103に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうCPUなどの演算部104、ユーザからのキー入力等を受け付けるキーボードやマウス等の入力部105、処理データの表示を行うディスプレイ等の表示部106を備える。なお、記憶部101内には、本実施形態のテストケース自動生成システムとして必要な機能を実装する為のプログラム102と、各種テーブル、データ類が記憶されている。記憶部101に格納されているテーブルやデータの類としては、各種設計書間に共通する項目について予め定義したテーブル125設計書テーブル601、設計項目テーブル602、設計書詳細テーブル603、設計項目データテーブル604を含むと、予めユーザから指定を受けているテスト情報データベース126テストケーステーブル605、テストケース詳細テーブル606、出力条件テーブル607を含むがある。また、その他にも、雛形ファイル127、環境設定ファイル128なども記憶部101に格納されている。これらデータベースやファイルに関しては後述する。こうしたテストケース自動生成システム100では、前記各テーブル601~604らが示す項目に応じて、画面遷移定義情報5やデータ仕様情報6などで構成される設計書10を設計情報データベース125に登録する。またテストケース自動生成システム100は、設計情報データベース125、テスト情報データベース126、および環境設定ファイル128を元に、雛形ファイル127を利用してテストケース20を自動生成することとなる。続いて、本実施形態のテストケース自動生成システム100が備える機能について説明する。上述したように、以下に説明する機能は、例えばテストケース自動生成システム100の演算部104がプログラム102をそれぞれ実行することで実装される機能と言える。前記テストケース自動生成システム100は、テストケース別の、前記項目が記述に含まれたテスト内容の定義テストケーステーブル605、テストケース詳細テーブル606および出力条件出力条件テーブル607について、入力部105を介しユーザから指定を受けて、テスト情報データベース126として記憶部101に格納する機能を有している。また、前記テストケース自動生成システム100は、処理対象となる設計書10のデータを前記各テーブル601~604に照合し、該テーブルで定義された各項目に該当する情報を前記設計書10のデータから抽出し、該抽出データを前記テーブル601~604の項目に合わせて、設計情報データベース125として記憶部101にて記憶する機能を有している。設計書10はプログラム等を開発する上で必要となる設計項目を記載するものであり、同様のシステムを開発する場合、そのフォーマットはプロジェクト毎に異なるが、設計項目についてはプロジェクト間でほぼ共通となりやすい。そこで本実施形態のテストケース自動生成システム100は、設計書10のデータを、前記テーブル601~604らのデータ項目に合わせて抽出し設計情報データベース125へ導入する処理を行うことで、テストケース20の生成に利用する設計書10の間のフォーマットの違いを吸収することとなる。また、前記テストケース自動生成システム100は、記憶部101から前記設計情報データベース125のデータを読み出し、該読み出したデータと、前記テスト情報データベース126における各テストケースの出力条件出力条件テーブル607が示す情報とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する機能を有している。また、前記テストケース自動生成システム100は、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベース125のデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する機能を有している。なお、前記テストケース自動生成システム100は、記憶部101から読み出した前記設計情報データベース125のデータと、前記テスト情報データベース126における各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベース125のデータに対しパターンマッチングさせるとすれば好適である。こうした本実施形態のテストケース自動生成システム100によれば、テスト情報データベース126におけるテーブル605~607についてユーザがメンテナンス可能であり、テストケースに含ませるチェック条件や確認内容等、出力するテストケースの追加、変更、削除が可能となる。また、テストケースの出力条件の指定では正規表現を導入することで、パターンマッチングによるテストケースの出力制御を確実化かつ効率化できる。続いて、本実施形態で処理対象となる設計書10にデータ構成例等について説明しておく。図2は、本実施形態のテストケース自動生成システム100における処理対象となる設計書10のフォーマット例を示した図である。前記テストケース自動生成システム100以下、システム100が扱う設計書10の一例としては、1つの表計算ファイルに存在する1つのシート上において、画面構成の定義等が記述されたデータを想定している勿論、画面構成に関する設計書はあくまで一例である。一般的に、表計算ファイルにおけるシートは、値の入力可能な矩形セルが縦横に行列配置されて構成されたものであり、各セルは行列中での配置を示す座標値例えば、A列の3行目であれば、A3でシート上の絶対位置が特定できる。1つの表計算ファイルに含まれるシート数に制限は無いことが普通であり、複数の各設計書10を記述した複数のシートを、1つの表計算ファイルに含めておくことも可能である。図2においては、画面一覧11、画面項目定義書12、画面ボタン定義書13という3つの設計書フォーマットの例を示している。画面一覧11は、システム開発で設計される全画面の情報を一覧化して表現した設計書フォーマットである。図2の例では、1つの表計算ファイル中の1つのシート画面一覧のタグがシート左下に存在するに記述したものとなっている。一方、画面項目定義書12と画面ボタン定義書13は、前記画面一覧11にて定義された各画面上に存在するすべての画面項目とボタン項目の情報をそれぞれ一覧化して表現した設計書フォーマットである。図2の例では、1つの表計算ファイル中のそれぞれシート計2シートに記述したものとなっている。よって、シート左下に画面項目定義書、画面ボタン定義書の各タグが存在している。ここで、各シートの名、すなわちシート名は、処理対象の設計書10が、後述する設計書テーブル601のどのレコードに該当するものか識別するため、設計書テーブル601で定義された設計書名称と同一名称である必要がある。したがって、図2の例に示す設計書フォーマットを考えた場合、設計書テーブル601には設計書名称として画面一覧、画面項目定義書、画面ボタン定義書という3つのレコードが存在することになる。また、設計書10に記載される設計項目は、1つの設計書において複数存在することを想定している。図2の例の場合、画面一覧11においては、画面IDと画面名の2つの設計項目がある。また、画面項目定義書12においては画面ID、画面項目ID、画面項目名、コントロール、桁、必須の6つの設計項目がある。また、画面ボタン定義書13においては、画面ID、画面ボタンID、画面ボタン名の3つの設計項目がある。なお、同一の設計項目が複数の設計書、すなわち図2の例の場合の画面一覧11、画面項目定義書12、画面ボタン定義書13らに存在することも想定できる。複数の設計書に存在する設計項目は、設計書間の紐付けを行う設計項目であり、同一の設計項目のデータ値が互いに同じである設計書同士は関連する設計書となる。図2の例では、画面IDが複数の設計書に記述されており、この画面IDが一致する設計書同士が関連する設計書となる。こうした設計書らのフォーマットに基づく設計項目間の関係例を図3にて示す。前記システム100が扱う各設計項目の間は、1:Nの親子関係があることを想定している。親となる設計項目は子となる設計項目を一意に決定する設計項目である。親となる設計項目は複数の子となる設計項目を持つことができるが、子となる設計項目は親となる設計項目を1つしか持てない。したがって、親の設計項目に相当する値が決まると、子となる設計項目に相当する値が自動的に決まる。図3に示す例では、図2に示した設計書フォーマット11~13らの設計項目の間の親子関係が表現されている。この図において、画面IDは画面を一意に識別する設計項目であり、この画面IDが決まると、画面名が自動的に決まるので、画面IDと画面名との間には画面IDが親かつ画面名が子という関係ができる。また、画面IDに対して画面名は1つなので、画面IDと画面名は1:1の親子関係となる。画面項目IDは画面上の項目を一意に識別するためのIDである。画面上の項目は画面が決まると自動的に決まるので、画面IDと画面項目IDの間には画面IDが親かつ画面項目IDが子という関係ができる。また画面には複数の画面項目が存在するため、画面IDと画面項目IDの間は1:Nの親子関係となりうる。また、画面項目名、コントロール、桁は画面項目IDが決まると自動的に決まる項目であり、画面項目IDと画面項目名、コントロール、桁には画面項目IDが親かつ画面項目名、コントロール、桁が子という関係ができる。また、画面項目IDに対して画面項目名、コントロール、桁はそれぞれ1つなので、画面項目IDと画面項目名、コントロール、桁の各間は1:1の親子関係となる。また、画面ボタンIDは画面項目IDと同様の理由から、画面IDが親かつ画面ボタンIDが子という1:Nの親子関係となる。さらに、画面ボタン名は画面項目名、コントロール、桁と同様の理由から、画面ボタンIDが親かつ画面ボタン名が子という1:1の親子関係となる。このようなフォーマットに基づいてユーザが作成した設計書10としては、画面一覧14、画面項目定義書15、および画面ボタン定義書16の各例を図4に示す。図4に示す例では、開発対象となる画面数は2つあり、画面一覧14には2つの画面の情報が一覧形式で記述されている。また、画面項目定義書15と画面ボタン定義書16は、1画面についてそれぞれ作成した例であり、画面項目定義書15では画面上に存在する2つの画面項目の情報が一覧形式で記述されており、画面ボタン定義書16では画面上に存在する1つのボタンの情報が一覧形式で記述されている。こうした設計書について図3同様に設計項目間の関係を示したのが図5となる。図4でえ例示した設計例では、画面には2つの画面項目と1つのボタン項目が存在している。そこで、画面ID:SCREEN01には、1つの画面名:ユーザ登録画面と、2つの画面項目ID:userId、userNameと、1つのボタン項目ID:insertが子の設計項目データとして存在する。さらに画面項目ID:userIdには画面項目名:ユーザIDと、コントロール:テキストと、桁:10と、必須:○、という子となる4つの設計項目データが存在し、画面項目ID:userNameには、画面項目名:ユーザ名と、コントロール:テキストと、桁:5と、必須:-、という子となる4つの設計項目データが存在する。また、画面ボタンID:insertには、画面ボタン名:登録という子となる1つの設計項目データが存在する。続いて、前記システム100が利用する設計情報データベース125とテスト情報データベース126のテーブル構成例について図6~9に基づき説明する。設計情報データベース125は、設計書テーブル601、設計項目テーブル602、設計書詳細テーブル603、および設計項目データテーブル604の4つのテーブルから構成される。設計書テーブル601は、前記システム100の入力となる設計書10に関する情報を保持するためのテーブルである。この設計書テーブル601は、図7にも示すように、設計書ID701と設計書名称702の2つの項目からなる。設計書ID701は設計書テーブル601の主キーとなる項目であり、入力となる設計書を一意に識別するためのIDである。設計書名称702は入力となる設計書の日本語名称を表すものである。設計書名称702は、図2で説明したとおり、ユーザが指定した設計書がどの設計書なのかを識別するために、入力となる設計書のシート名と同一である必要がある。上記図2の例では、設計書には画面一覧14、画面項目定義書15、および画面ボタン定義書16の3つの設計書があるため、図7に示す設計書テーブル601の例では、各設計書3件の情報が登録されている。設計書ID701には一意となるIDを設定する必要があり、画面一覧14、画面項目定義書15、画面ボタン定義書16に対する各設計書IDには、それぞれ重複しない値として、例えば、ScreenList、ScreenItem、ScreenButtonを設定している。設計書名称702には、図2で説明したとおり表計算ファイルのシート名と一致する必要があるため、設計書名称702にはそれぞれ、画面一覧、画面項目定義書、画面ボタン定義書を設定している。また、設計項目テーブル602はシステム開発する上で必要となる、設計書に記載された設計項目の情報を保持するためのテーブルである。この設計項目テーブル602は、図8にて示すように、設計項目ID801、設計項目名称802、親設計項目ID803の3つの項目からなる。設計項目ID801は設計項目テーブル602の主キーとなる項目であり、設計項目を一意に識別するためのIDである。設計項目名称803は入力となる設計書に記載された設計項目の日本語名称を表すものである。親設計項目ID802は、図3で説明したとおり、設計項目間に1:Nの親子関係があることを踏まえ、子となる設計項目に対して親となる設計項目の設計項目IDを設定するための項目である。図8に示す設計項目テーブル602の例においては、設計項目として、画面一覧について画面IDと画面名の2つの設計項目が、画面項目定義書について画面ID、画面項目ID、画面項目名、コントロール、桁、必須の6つの設計項目が、画面ボタン定義書について画面ID、画面ボタンID、画面ボタン名の3つの設計項目が存在する。また画面IDは画面一覧、画面項目定義書、画面ボタン定義書のすべての設計書に存在しており、設計項目としては重複を除き画面ID、画面名、画面項目ID、画面項目名、コントロール、桁、必須、画面ボタンID、画面ボタン名の9つの設計項目が存在する。したがって、設計項目テーブル602には、9件の情報が登録されている。設計項目ID801には一意となるIDを設定する必要があり、画面ID、画面名、画面項目ID、画面項目名、コントロール、桁、必須、画面ボタンID、画面ボタン名に対する設計項目IDにはそれぞれ重複しない値として、ScreenId、ScreenName、ScreenItemId、ScreenItemName、ScreenItemCtl、ScreenItemSize、ScreenItemNecessary、ScreenButtonId、ScreenButtonNameを設定している。また、設計項目名称803は、設計項目の日本語名称であるため、画面ID、画面名、画面項目ID、画面項目名、コントロール、桁、必須、画面ボタンID、画面ボタン名といった名称を設定している。さらに親項目の設計項目ID802には、設計項目間に図3に示す親子関係があるため、画面IDに関しては未設定を示す-が設定され、画面名、画面項目ID、画面ボタンIDに関してはScreenIdが設定され、画面項目名、コントロール、桁、必須に関してはScreenItemIdが設定され、画面ボタン名に関してはScreenButtonIdが設定されている。また、設計書詳細テーブル603は、設計書10と設計項目とを紐付けるためのテーブルであり、設計書10のどの位置にどの設計項目が存在するかという情報を保持するためのテーブルである。設計書詳細テーブル603は、図9に例示するように、設計書ID901、設計項目ID902、絶対位置903、繰返し有無904、データ読込方向905、登録有無906の6つの項目からなる。設計書ID901と設計項目ID902は設計書詳細テーブル603の主キーとなる項目であり、どの設計書にどの設計項目が記載されるかを示すものである。設計書ID901は設計書テーブル601に存在する設計書ID701である必要があり、設計項目ID902は設計項目テーブル602に存在する設計項目ID801である必要がある。絶対位置903は設計書のどの位置に設計項目が存在するかを示す情報である。図2をもとに例を示すと、設計書:画面一覧にある設計項目:画面IDに対するデータはA2の位置から開始されるため、絶対位置903にはA2が設定される。また、繰り返し有無904は、設計項目のデータが設計書間で1つなのか複数なのかを示す情報であり、1つの場合には無が、複数の場合には有が設定される。図2の例をもとに説明すると、設計書:画面一覧にある設計項目:画面IDに対するデータは複数記述されるため、繰返し有無904には有が設定される。一方、設計書:画面項目定義書にある設計項目:画面IDに対するデータは1つしか記述されないため、繰返し有無904には無が設定される。また、データ読込方向905は設計項目のデータが複数の場合に利用され、データの繰返し方向を示すものであり、該当設計項目が上方向に繰り返される場合には↑が、下方向に繰り返される場合には↓が、左方向に繰り返される場合には←が、右方向に繰り返される場合には→が設定される。また設計項目のデータが1つの場合には-が設定される。図2をもとに例を示すと、設計書:画面一覧にある設計項目:画面IDに対するデータは下方向に複数記述されるため、データ読込方向905には↓が設定される。一方、設計書:画面項目定義書にある設計項目:画面IDに対するデータは1つしか記述されないため、データ読込方向905には-が設定される。また、登録有無906は複数の設計書に記載される設計項目に関して、どの設計書から設計項目データを登録するかを示す情報である。複数の設計書から同一の設計項目データを登録しても無駄な情報が増えてしまうだけなので、設計項目データは1つの設計書からしか登録できないようにしている。したがって、ある設計項目について、ある設計書で登録有無906が有になっている場合、その設計項目について他の設計書に関して無とする必要がある。図2をもとに例を示すと、設計項目:画面IDは3つの設計書に記載されるため、このうちの1つの設計書でしか登録有無906を有に設定できない。したがって、設計書:画面一覧にて登録有無906を有に設定した場合、設計書:画面項目定義書と設計書:画面ボタン定義書では登録有無906を無にしか設定できない。図9に例示した設計詳細テーブルでは、設計書ID901がScreenListかつ設計項目ID902がScreenIdと、設計書ID901がScreenListかつ設計項目ID902がScreenNameという2つのレコードが登録されている。図2の例であれば、画面IDはA2の位置から下方向に複数記述されるため、設計書ID901がScreenListかつ設計項目ID902がScreenIdのレコードの絶対位置903にA2が、繰返し有無904には有が、データ読込方向905には↓が設定される。また、画面IDは複数の設計書に記述されており、この例では画面一覧から登録するため、登録有無906を有にしている。したがって、画面IDが記述されている画面項目定義書15と画面ボタン定義書16では登録有無906を無にしている。同様に画面名はB2の位置から下方向に複数記述されているため、設計書ID901がScreenListかつ設計項目ID902がScreenNameのレコードの絶対位置903にB2が、繰返し有無904には有が、データ読込方向905には↓が設定される。また画面名は画面一覧にのみ記述されているため、登録有無906は有に設定されている。他の設計書についても同様に設定することができる。こうした、設計書のデータをテーブル11~13の項目に基づいて抽出設定し、設計情報データベース125を作成する処理は、前記システム100が実行する。表計算ファイルのシートは上述のように絶対位置が判明しているセルによって構成されているから、前記システム100は、設計書10からのデータ抽出等に際しては、シート中の規定セル例:A1など最上行の最左列のセルから順次セルの値を読み込んで、該当設計項目のIDや名称が設定されたセルを特定し、それと連結ないし隣接したセルの値すなわち設計項目の値を読み取るといった処理を実行していけばよい。他のテーブル類に基づく設計書10からのデータ抽出についても同様である。また、設計項目データテーブル604は、設計書10から読込んだ設計項目のデータを保持するためのテーブルである。設計項目データテーブル604はデータ番号1101、設計項目ID1102、値1103、親項目のデータ番号1104という4つの項目からなる。データ番号1101は設計項目のデータを一意に識別するための情報であり、設計項目のデータを設計項目データテーブル604に格納する際にシステム100が自動採番して作成する。設計項目ID1102は設計項目のデータがどの設計項目に関するものかを示すものであり、設計項目テーブル602に存在する設計項目ID801である必要がある。値1103は設計書10から読込んだ設計項目のデータを格納する。親項目のデータ番号1104は、図5で説明したとおり、設計項目間における1:Nの親子関係に基づいて、子となる設計項目データに対して親となる設計項目データのデータ番号を設定する項目である。親項目のデータ番号1104は設計項目データテーブル604に存在するデータ番号1101である必要がある。一方、テスト情報データベース126は、テストケーステーブル605、テストケース詳細テーブル606、出力条件テーブル607の3つのテーブルから構成される。テストケーステーブル605は生成するテストケース1件の情報を保持するテーブルである。テストケーステーブル605は、図15に示すようにテストケースID1501、テストケース名1502、出力条件ID1503の3つの項目からなる。テストケースID1501はテストケーステーブル605の主キーとなる項目であり、テストケースを一意に識別するためのIDである。テストケース名1502はテストケースの日本語名称を表すものである。出力条件ID1503はテストケースを出力するための条件を表すものであり、ここに値を設定することで、テストケースの出力制御が可能となる。出力条件ID1503は出力条件テーブル607に存在する出力条件ID1701である必要がある。また、テストケース詳細テーブル606は、テストケースを実行する手順を操作単位で格納するテーブルである。図16に示すように、テストケース詳細テーブル606はテストケースID1601、操作番号1602、出力区分1603、操作内容1604の4つの項目からなる。テストケースID1601と操作番号1602はテストケース詳細テーブル606の主キーとなる項目であり、テストケースを実現するための手順を構成する1つの操作を示すものである。テストケースID1601はテストケーステーブル605に存在するテストケースID1501である必要がある。出力区分1603は操作の区分を示すものであり、テストケースのチェック条件となる操作に対しては条件を、テストケースの確認内容となる操作に対しては確認を設定する。操作内容1604はテストする際の具体的な操作を示すものである。チェック条件となる操作としては画面項目に値を入力する、ボタンを押すなどの操作があり、確認内容となる操作としてはボタン押下後の画面状態を確認するなどの操作がある。また、操作内容1604には、設計情報データベース125の設計項目テーブル602における設計項目ID801が埋め込み可能であり、設計項目ID801を{設計項目ID}という形式で設定することで対応する設計項目のデータを出力可能にしている。ここで設定する設計項目IDは、設計項目テーブル602に存在する設計項目ID801である必要がある。さらに、出力するファイルで利用可能な関数を記述可能にすることで、設計項目を利用した関数による演算結果も出力することが可能である。また、出力条件テーブル607はテストケースの出力を制御するための条件情報を格納するテーブルである。出力条件テーブル607は出力条件ID1701、設計項目ID1702、出力条件内容1703の3つの項目からなる。出力条件ID1701は出力条件テーブル607の主キーとなる項目であり、出力条件を一意に識別するIDである。設計項目ID1702と出力条件内容1703はテストケースを出力するための条件を表すものであり、設計項目ID1702に対する設計項目データが出力条件内容に指定されたパターンを満たす場合にテストケースを出力する。設計項目ID1702は設計項目テーブル602に存在する設計項目ID801である必要がある。続いて、本実施形態における設計書10のデータを設計情報データベース125に登録する際の処理を図10に基づき説明する。なお、上述したように、前記システム100が、設計書10のデータから、設計書テーブル601、設計項目テーブル602、および設計書詳細テーブル603の各設計項目について値を抽出し、該当テーブルに対応した形式で記憶部101にデータを保持しているものとする。この場合、前記システム100は、例えば、入力部105にてユーザより入力されたフォルダ名の情報を取得するステップ110。システム100は、例えば記憶部101に格納されていた該当フォルダにアクセスし、設計書10を格納した表計算ファイルを全て取得するステップ120。次に前記システム100は、前記ステップ120で取得した表計算ファイルを1つずつ読込んでいく。読込む表計算ファイルがある場合ステップ130:有、前記システム100はステップ140に処理を進める。一方、読込む表計算ファイルが無い場合ステップ130:無、前記システム100は処理を終了する。こうしたステップ130の処理は、前記ステップ120で得た全ての表計算ファイルについて、読込む表計算ファイルが無くなるまで繰り返し実行される。続いて前記システム100は、前記ステップ120で取得した表計算ファイルから、各設計書10のデータが記述されたシートを取得するステップ140。前記システム100は、取得した表計算ファイルの全シートを1シートずつ読込んでいくステップ150。読込むシートがある場合ステップ150:有、前記システム100は処理をステップ160に進める。他方、読込むシートが無い場合ステップ150:無、前記システム100は、処理をステップ130に戻す。こうした処理は、前記ステップ140で取得した全シートについて、読込むシートが無くなるまで繰り返し実行する。続いて前記システム100は、読込んだシートからシート名を取得するステップ160。また前記システム100は、設計情報データベース125の設計書テーブル601にアクセスし、設計書テーブル601の設計書名称702が前記取得したシート名と一致するレコードの設計書ID701を取得するステップ170。次に前記システム100は、前記ステップ170で設計書ID701を取得できた場合ステップ180:有、処理をステップ190に進める。一方、前記ステップ170にて設計書ID701を取得できなかった場合ステップ180:無、前記システム100は処理をステップ150に戻す。続いて前記システム100は、設計情報データベース125の設計書詳細テーブル603にアクセスし、設計詳細テーブルの設計書ID901が前記ステップ170で取得した設計書ID701と一致するレコード設計書詳細レコードを取得するステップ190。前記システム100は、取得した設計書詳細レコードを1つずつ読込んでいく。読込む設計書詳細レコードがある場合ステップ200:有、前記システム100は、処理をステップ210に進める。他方、読込む設計書詳細レコードが無い場合ステップ200:無、前記システム100は、処理をステップ150に戻す。こうした処理は、前記ステップ190で取得した全設計書詳細レコードについて、読込む設計書詳細レコードが無くなるまで繰り返し実行される。続いて前記システム100は、前記読み込んだ設計書詳細レコードから設計項目ID902、絶対位置903、繰返し有無904、データ読込方向905、登録有無906の各値を取得するステップ210。そして前記システム100は、ここで取得した登録有無906が有の場合ステップ220:有、処理をステップ230に進める。他方、登録有無906が無の場合ステップ220:無、前記システム100は処理をステップ200に戻す。次に前記システム100は、設計情報データベース125の設計項目テーブル602にアクセスし、設計項目テーブル602の設計項目ID801が前記ステップ210で取得した設計項目ID902と一致するレコードにおける、親項目の設計項目ID802を取得するステップ230。前記システム100は、親項目の設計項目ID802を取得できた場合ステップ240:有、処理をステップ250に進める。他方、親項目の設計項目ID802を取得できなかった場合ステップ240:無、前記システム100は処理をステップ260に進める。続いて前記システム100は、記憶部101にて保持する所定のデータ番号後述するステップ280で採番したもの中から、前記ステップ230で得た親項目の設計項目ID802に対応するデータ番号を、親項目のデータ番号として取得するステップ250。勿論、前記ステップ170~ステップ240の処理は、設計項目テーブル602における各設計項目間の親子関係に沿って最上位の親から順次行っていくから、当初は未だデータ番号が採番されていない状況であり、親項目のデータ番号は取得できない。よって、前記親子関係において親をもつ設計項目に関する処理が行われるまで、当該ステップはスルーする。次に前記システム100は、前記ステップ140より処理中となっている該当シートにおいて、絶対位置903にあるセルからデータを取得するステップ260。前記ステップ210で得た繰返し有無904が有の場合、前記システム100はデータ読込方向905を元に全データを取得する。続いて前記システム100は、前記ステップ260で取得した全データから1データずつ読込んでいく。読込むデータがある場合ステップ270:有、前記システム100はステップ280に処理を進める。他方、読込むデータが無い場合ステップ270:無、前記システム100は処理をステップ200に戻す。こうした処理は、前記ステップ260で得た全データについて、読込むデータが無くなるまで繰り返し実行される。次に前記システム100は、前記ステップ260で得た各設計項目のデータを設計項目データテーブル604に登録すべく、該当データ設計項目データ用のデータ番号を自動採番するステップ280。データ番号の自動採番については、登録順に1つずつ番号をインクリメントするといった一般的手法を採用すればよい。続いて前記システム100は、設計項目データテーブル604におけるデータ番号1101の欄に、前記ステップ280で自動採番したデータ番号を、また同様に、設計項目ID1102の欄に前記ステップ210で取得した設計項目ID902を、また同様に、値1103の欄に前記ステップ260で取得したデータを、また同様に、親項目のデータ番号すなわち親データ番号1104の欄に前記ステップ250で取得したデータ番号を設定し、データ登録を行うステップ290。前記システム100は、前記ステップ280で自動採番したデータ番号を記憶部101に保持し、ステップ200に戻るステップ300。以降、前記システム100は、設計書詳細レコードがある限りステップ200:無→ステップ150、またシートがある限りステップ150:無→ステップ130、更に、表計算ファイルが無くなるまでステップ130:無→END、上記処理を繰り返し実行することとなる。図11は、図4の設計書10を上述のフローを経て登録した設計項目データテーブル604の例を示す図である。ここでは一例として、設計書10のうち画面一覧14について説明する。システム100は画面一覧14のデータから画面IDと画面名を抽出し登録することになる。まず、画面IDはSCREEN01とSCREEN02の2つがあるため、システム100は、データ番号1101には自動採番された1と2を、設計項目ID1102には画面IDの設計項目ID:ScreenIdを、値にはSCREEN01とSCREEN02をそれぞれ設定する。なお親データ番号1104は、画面IDに対する親項目の設計項目が無いため未設定となる。また、画面名はユーザ登録画面と結果画面の2つがあるから、前記システム100は、データ番号1101には自動採番した3と4を、設計項目ID1102には画面名の設計項目ID:ScreenNameを、値1103にはユーザ登録画面と結果画面をそれぞれ設定する。また画面名に対する親項目の設計項目が画面IDであるため、前記システム100は、ユーザ登録画面の親データ番号1104として1を、また結果画面の親データ番号1104として2をそれぞれ設定する。その他の項目も同様に設定されるものである。続いて、テストケース自動生成の処理について説明する。まずは、テストケース自動生成に際し前記システム100が用いるファイル等について例示する。図12は、前記システム100が利用する雛形ファイル127の例を示す図である。前記システム100がテストケース自動生成時に利用する雛形ファイル127は、設計書10と同様に表計算ファイルが想定できる。前記システム100は設計情報データベース125に保持する設計項目のデータと、テスト情報データベース126に予め保持するテストケースの定義とその出力条件をもとに、出力すべきテストケースを作成し、これを雛形ファイル127に適用し出力することでテストケースのファイルを自動生成する。1つの表計算ファイルは、図13で説明する環境設定ファイル128で指定された設計項目IDに対する設計項目データ単位に作成し、1つのテストケースは1つのシートに出力する。図13は、前記システム100が利用する環境設定ファイル128の例を示す図である。前記システム100がテストケース自動生成時に利用する環境設定ファイル128はテキストファイルが想定できる。環境設定ファイル128には、テストケースの出力単位となる設計項目IDを指定する。前記システム100ではこの環境設定ファイル128で指定された設計項目IDに対する設計項目のデータと、その設計項目に紐づく子となるすべての設計項目のデータを元にテストケースを作成することになる。図13の例では、設計項目IDとして画面IDが指定されているため、この場合、前記システム100は図5に示す画面ID:SCREEN01にぶら下がるすべての設計項目のデータを元にテストケースを作成する。続いて、前記システム100が自動生成したテストケース20の例を示しておく。図14に示す例ではテストケース20が、必須チェック未入力と入力可能桁数桁数、入力可能桁数桁数1の3つのテストケースから構成されている。そのうち、必須チェック未入力は、必須指定された項目に対して未入力の場合に入力エラーが発生するかを確認するテストケースである。また、入力可能桁数桁数、入力可能桁数桁数1は、画面上の入力項目に対して桁数分しか入力できないことを確認するテストケースであり、入力項目への入力文字数のパターンとして桁数分と桁数1分の2つのパターンを用意している。また、必須チェック未入力のテストケースは、設計項目のうち必須が○になっている項目に対してのみ実施するテストケースであり、図4の例においては、ユーザIDのみ必須が○となっているため、ユーザIDに対する1件のテストケース、すなわちこの図14で示す必須チェック未入力のテストケースが出力された結果となっている。また、入力可能桁数桁数と入力可能桁数桁数1の各テストケースは、全画面項目に対して行うチェックであり、ユーザIDとユーザ名の両方に対してチェックしている。また、出力する表計算ファイルのシートはテストケース単位となっている。続いて、前記システム100がテストケース自動生成時に利用するテスト情報データベース126を構成するテーブルについて説明する。図15は、テストケーステーブル605の例を示す図である。ここで例示するテストケーステーブル605は、テストケースとして必須チェック未入力、入力可能桁数桁数、入力可能桁数桁数1の3つのテストケースに関する計3件のレコードが登録されている。こうしたレコードは、テスト担当のユーザが事前に設定しており、必要に応じてユーザによる更新作業が可能となっているシステム100が当該テーブルを出力部106に表示し、入力部105でユーザ指示を受ける。以降、他のテーブルについても同様にシステム100が情報の表示を行って、ユーザによる閲覧、更新、削除等の指示を受け付けてデータ更新等を実行可能とする。従って、図15のテストケーステーブル605であれば、テストケースの追加や削除、テストケース名1502や出力条件ID1502の変更等も、システム100が出力部106にて該当情報を表示してユーザ閲覧に供しつつ、入力部105にて変更等の指示を受けて、該当データの更新等を行うこととなる。このテストケーステーブル605において、テストケースID1501は、テストケース毎に一意となる情報であるため、必須チェック未入力、入力可能桁数桁数、入力可能桁数桁数1のそれぞれに関し、互いに重複しない値としてTC001、TC002、TC003が設定されている。テストケース名1502はテストケースの日本語名称を表すものであるため、必須チェック未入力、入力可能桁数桁数、入力可能桁数桁数1が設定されている。また、出力条件ID1503はテストケースの出力制御を行うものであり、必須チェック未入力のテストケースは必須が○の場合にのみ出力するとの条件があるため、出力条件ID1503に例えば該当条件を示すOP001が設定されている。他方、入力可能桁数桁数と入力可能桁数桁数1の各テストケースは、すべての画面項目に対して出力するテストケースであるため。出力条件ID1503は未設定となっている。また、前記テスト情報データベース126を構成する、テストケース詳細テーブル606は、図16に例示するように、各テストケース上記例では3つのテストケースに対してそれぞれ実行手順が記述されたテーブルとなる。ここでは、テストケース:必須チェック未入力に関して説明する。テストケース:必須チェック未入力は、5つのチェック条件に関する操作と3つの確認に関する操作の計8つの操作からなる。操作内容1604には{設計項目ID}が埋め込まれており、システム100が自動生成するテストケースにおいては、前記設計項目IDの記述が、対応する設計項目のデータ設計書10から抽出したもので置換されて出力される。また図16において、操作番号1602が1の操作内容1604は{ScreenId}:{ScreenName}が表示されている。となっており、設計項目IDとしてScreenIdとScreenNameが埋め込まれているため、図4、図8の場合には、テストケースとしては{ScreenId}がSCREEN01に、{ScreenName}がユーザ登録画面に置換されて、SCREEN01:ユーザ登録画面が表示されている。が出力されることになる。また、操作番号1602が2の操作内容1604は以下の項目を未入力にするとなっており、設計項目IDは埋め込まれていないため、このまま出力される。また、操作番号1602が3の操作内容1604はScreenItemId:{ScreenItemName}となっており、設計項目IDとしてScreenItemId、ScreenItemNameが埋め込まれているため、図4、図8の場合には、画面項目が2つ存在しており、userId:ユーザIDとuserName:ユーザ名の2行が出力される。その他の操作番号のレコードについても同様に出力されるものである。図17は、出力条件テーブル607の例を示す図である。上述までの例において、出力の制御をしたいテストケースとして必須チェックがある。そこで図17の出力条件テーブル607では、必須チェックのテストケース用の出力条件として、1件のレコードが登録されている。このレコードが示す条件において、必須チェック未入力のテストケースは、画面項目に対する必須が○になっている場合にテストケースとして出力する。出力条件ID1701は出力条件を一意に識別するIDであり、ここではOP001が設定されている。また、前記必須チェック未入力のテストケースに関する出力条件が、画面項目に対する必須が○になっていることであることから、設計項目ID1702には、必須に対する設計項目ID:ScreenItemNecessaryが、また、出力条件内容1703に○が設定されている。続いて、前記システム100が、設計情報データベース125とテスト情報データベース126に基づいてテストケース20を自動生成する処理について、図18,図19に基づき説明する。まず、前記システム100は、図13に例示した環境設定ファイル128から画面IDに相当する設計項目IDを取得するステップ510。次に前記システム100は、設計情報データベース125の設計項目データテーブル604にアクセスし、設計項目データテーブル604の設計項目ID1102が、前記ステップ510で取得した設計項目IDと一致するレコード、すなわち設計項目データレコードを取得するステップ520。また、前記システム100は、前記ステップ520で取得した設計項目データレコードを1つずつ読込んでいく。設計項目データレコードがある場合ステップ530:有、前記システム100は処理をステップ540に進める。他方、設計項目データレコードが無い場合ステップ530:無、前記システム100は処理を終了する。こうした処理は、前記ステップ520で得た設計項目データレコードが無くなるまで繰り返し実行される。続いて前記システム100は、前記ステップ520で取得したレコードからデータ番号1101を取得するステップ540。また前記システム100は、設計情報データベース125の設計項目データテーブル604にアクセスし、前記ステップ540で取得したデータ番号1101を頂点として連なる親子関係において、子となる設計項目のデータを、子が無くなるまですべて取得するステップ550。つまり前記システム100は図3と図5に相当する情報を作成する。前記システム100は、テスト情報データベース126のテストケーステーブル605にアクセスし、全てのテストケースのレコードを取得するステップ560。また前記システム100は、ここで取得したテストケースレコードを1つずつ読込んでいく。テストケースレコードがある場合ステップ570:有、前記システム100は処理をステップ580に進める。他方、テストケースレコードが無い場合ステップ570:無、前記システム100は処理を終了する。こうした処理は、前記ステップ560で得たテストケースレコードが無くなるまで繰り返し実行される。続いて前記システム100は、前記ステップ570で取得したレコードから出力条件ID1503を取得するステップ580。また前記システム100は、該ステップ580で出力条件ID1503を取得できた場合ステップ590:有、処理をステップ600に進める。他方、出力条件ID1503が無かった場合ステップ590:無、前記システム100は処理をステップ650に進める。前記ステップ590に続き、前記システム100は、テスト情報データベース126の出力条件テーブル607にアクセスし、出力条件テーブル607の出力条件ID1701が、前記ステップ580で取得した出力条件ID1503と一致する出力条件レコードを取得するステップ600。そして前記システム100は、前記ステップ600で取得した出力条件レコードから設計項目ID1702と出力条件内容1703を取得するステップ610。また前記システム100は、ここで取得した設計項目ID1702に対応する設計項目の値1103を、前記ステップ550で取得、作成した情報から取得するステップ620。次に前記システム100は、前記ステップ610で取得した出力条件内容1703について正規表現を用いて、前記ステップ620で取得した設計項目の値1103とのマッチングを行うステップ630。正規表現は、文字列のパターンを表現する表記法であり、文字列の検索置換を行うときに利用されるものとなる。正則表現と呼ばれることもある。この正規表現においては、通常の文字と、メタキャラクタと呼ばれる特別な意味を持った記号を組み合わせた表記がなされる。正規表現を用いれば、文字列を直接指定せず、特徴を指定することができるため、表記の揺れを吸収して検索を行ったり、複数の異なる文字列を一括して置換したりすることができる。例えばという文字は行頭、は任意の1文字、という文字は直前の要素の1回以上の繰り返しを意味するなどの規定がある。従って前記システム100は、出力条内容1703が示す内容について、こうした正規表現にて記述するために、正規表現の規定について辞書データと所定の変換アルゴリズムを予め記憶部101に備えており、出力条件内容1703を入力として正規表現を生成し、これをベースにして、前記ステップ620で取得した設計項目の値1103とのパターンマッチングを行うものとする。パターンマッチングの結果、前記出力条件内容1703と、前記ステップ620で取得した設計項目の値1103とがマッチした場合ステップ640:可、前記システム100は該当テストケースについて出力可と判定し、他方、マッチしなかった場合ステップ640:否には出力不可と判定する。続いて前記システム100は、前記ステップ640での出力可否の結果をもとに、出力可の場合ステップ640:可、処理をステップ650に進める。他方、出力不可の場合ステップ640:否、前記システム100は処理をステップ570に戻す。前記システム100は、前記ステップ560で取得したテストケースレコードからテストケースID1501とテストケース名1502を取得するステップ650。この場合、前記システム100は、雛形ファイル127からシート名がtemplateとなっているシートをコピーして、前記取得したテストケース名1502をシート名に持つ新規シートを作成するステップ660。次に前記システム100は、テスト情報データベース126のテストケース詳細テーブル606にアクセスし、テストケース詳細テーブル606のテストケースID1601が前記ステップ650で取得したテストケースID1501と一致するレコード、すなわちテストケース詳細レコードを取得するステップ670。また前記システム100は、前記ステップ670で取得したテストケース詳細レコードを1つずつ読込んでいく。テストケース詳細レコードがある場合ステップ680:有、システム100は処理をステップ690に進める。他方、テストケース詳細レコードが無い場合ステップ680:無、前記システム100は処理をステップ570に戻す。こうした処理は、前記ステップ670で得たテストケース詳細レコードが無くなるまで繰り返し実行される。続いて前記システム100は、前記ステップ670で取得したテストケース詳細レコードから出力区分1603と操作内容1604を取得するステップ690。前記システム100は、ここで取得した操作内容1604に含まれる設計項目IDを取得するステップ700。この場合、前記システム100は、操作内容1604のうち{と}に挟まれる値を設計項目IDとして扱う。前記システム100は、前記ステップ700で取得した設計項目IDに対応する設計項目の値1103を、前記ステップ550で取得、作成した情報から取得するステップ710。また前記システム100は、前記ステップ710で取得した設計項目の値1103を、前記ステップ690で得た操作内容1604に含まれる設計項目IDと置換するステップ720。前記システム100は、前記ステップ690で取得した、条件や確認といった出力区分1603を元に、前記ステップ720で作成した操作内容をシート前記ステップ660で雛形ファイル127から作成してあるシート。形式は図12参照における該当出力区分のセルに出力していくことで、テストケースの生成出力処理を行うステップ730。こうした処理を行うことで、図14で例示したテストケース20のうち出力可のものが生成されることになる。こうしたテストケース出力後、前記システム100は処理を前記ステップ680に戻す。以降、テストケース詳細レコードが無くなるまでステップ680:無し→ステップ570、テストケースレコードが無くなるまでステップ570:無→ステップ530、設計項目データレコードが無くなるまでステップ530:無→END、前記システム100は処理を繰り返すこととなる。以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。こうした本実施形態によれば、フォーマットが異なる各種設計書に対してテストケースを自動生成することが可能であり、テストケース生成作業の省略による作業量縮小を図ることができる。また、自動生成するテストケースに関して、ユーザによる追加、変更、削除も可能であり、不要なテストケースの消化による作業量増大や、必要なテストケースが出力されないことによるテスト漏れによる品質の低下といった事態の発生を防ぐことができる。したがって、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、前記テストケース自動生成システムにおいて、前記演算部は、記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせるとしてもよい。"