テストケース自動生成システム、テストケース自動生成方法、およびテストケース自動生成プログラム
【課題】設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る。
【解決手段】コンピュータ１００が、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件についてテスト情報データベース１２６として記憶する処理と、設計書１０のデータをテーブルに照合し定義された項目に該当する情報を設計書１０から抽出し設計情報データベース１２５として記憶する処理と、設計情報データベース１２５のデータと各テストケースの出力条件とのパターンマッチングを行って出力条件が満たされたテストケース等について特定する処理と、特定したテストケースについて該当テストケースの定義が含む各項目に対応するデータを設計情報データベース１２５のデータから特定し設定することで該当テストケース２０を生成する処理を実行する。
【解決手段】コンピュータ１００が、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件についてテスト情報データベース１２６として記憶する処理と、設計書１０のデータをテーブルに照合し定義された項目に該当する情報を設計書１０から抽出し設計情報データベース１２５として記憶する処理と、設計情報データベース１２５のデータと各テストケースの出力条件とのパターンマッチングを行って出力条件が満たされたテストケース等について特定する処理と、特定したテストケースについて該当テストケースの定義が含む各項目に対応するデータを設計情報データベース１２５のデータから特定し設定することで該当テストケース２０を生成する処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テストケース自動生成システム、テストケース自動生成方法、およびテストケース自動生成プログラムに関するものであり、具体的には、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る技術に関する。
【背景技術】
【０００２】
システム開発の高品質化、短納期化が求められる中で、高品質なシステムを短期間で開発するため、ソースの自動生成やテスト作業の自動化が検討されている。テスト作業の自動化に関しては、さらにテストケース、テストデータの自動生成や、テストの自動実行、テスト結果の自動検証なども検討されている。特にテストケースの自動生成に関しては、テスト対象となるプログラムに関する設計書をもとにテストケースを自動生成するシステムが知られている。
【０００３】
そうした従来技術としては、例えば、テストケース及びテストデータを生成するためにコンピュータを、画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、前記対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、データ定義情報から、前記テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、前記テスト対象カラムに対する前記制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能させることを特徴とするテストケース生成プログラム（特許文献１参照）などが提案されている。
【０００４】
また、テストデータを構成する複数の項目情報と、該項目情報が漢字又は数字又は文字か否かの属性を示す属性情報と、前記項目情報のレコード長とを含むテストデータ仕様情報を複数格納する仕様書ファイル部と、テストデータの属性情報及びレコード長に対応した変数を含む複数の項目属性パラメータ情報を格納する項目属性パラメータファイル部と、前記仕様書ファイル部に格納したテストデータ仕様情報及び前記項目属性パラメータファイル部に格納した項目属性パラメータ情報を参照してコンピュータシステムのテストデータを内部テーブル部に生成する制御部とを備えるテストデータ作成システムであって、前記制御部が、前記仕様書ファイル部からテストデータ仕様情報を抽出する第１工程と、該第１工程により抽出したテストデータ仕様情報の属性情報及びレコード長に対応した複数の項目属性パラメータ情報を項目属性パラメータファイル部から抽出する第２工程と、前記第１工程により抽出したテストデータ仕様情報の複数の項目情報を該項目情報のレコード長に従って前記内部テーブル部に設定する第３工程と、該第３工程により設定した内部テーブル部の複数の項目情報に、前記該第２工程により抽出した項目属性パラメータ情報の変数に従ったデータを割り当てることによりテストデータを生成する第４工程とを実行するテストデータ作成システム（特許文献２参照）なども提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２６０３９０号公報
【特許文献２】特開２００９−２８９０８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術を利用することでテストケースの自動生成は可能である。しかしながら、テストケースの自動生成に利用する設計書については、そのフォーマット等が固定化されているのが前提であって、例えばフォーマットや記載項目が固定基準と異なる設計書について適用することが出来ないという課題が残されている。
【０００７】
また、従来技術によって出力されるテストケースの形式が固定であることから、設計書によっては不要な項目についてもテストケースが出力され、更にはその不要なテストケースの実行によって、システム検証の作業量自体が増大するという問題も生じる。一方で、必要なテストケースが出力されないことも起こりうるため、テスト漏れによるシステムの品質低下の事態が生じる恐れもある。
【０００８】
そこで本発明の目的は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決する本発明のテストケース自動生成システムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、を備える。
【００１０】
また、本発明のテストケース自動生成方法は、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行することを特徴とする。
【００１１】
また、本発明のテストケース自動生成プログラムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のテストケース自動生成システムの構成例を示す図である。
【図２】本実施形態における設計書のフォーマット例を示す図である。
【図３】本実施形態における設計項目間の関係例を示す図である。
【図４】本実施形態における設計書の例を示す図である。
【図５】本実施形態における設計項目データの関係例を示す図である。
【図６】設計情報データベースとテスト情報データベースのテーブル構成例を示す図である。
【図７】本実施形態における設計書テーブルの例を示す図である。
【図８】本実施形態における設計項目テーブルの例を示す図である。
【図９】本実施形態における設計書詳細テーブルの例を示す図である。
【図１０】本実施形態におけるテストケース自動生成方法の処理手順例１を示すフロー図である。
【図１１】本実施形態における設計項目データテーブルの例を示す図である。
【図１２】本実施形態における雛形ファイルの例を示す図である。
【図１３】本実施形態における環境設定ファイルの例を示す図である。
【図１４】本実施形態におけるテストケースの例を示す図である。
【図１５】本実施形態におけるテストケーステーブルの例を示す図である。
【図１６】本実施形態におけるテストケース詳細テーブルの例を示す図である。
【図１７】本実施形態における出力条件テーブルの例を示す図である。
【図１８】本実施形態におけるテストケース自動生成方法の処理手順例２を示すフロー図である。
【図１９】本実施形態におけるテストケース自動生成方法の処理手順例３を示すフロー図である。
【発明を実施するための形態】
【００１４】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のテストケース自動生成システム１００の構成例を示す図である。図１に示すテストケース自動生成システム１００は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図るコンピュータシステムである。
【００１５】
テストケース自動生成システム１００のハードウェア構成は例えば以下の如くとなる。前記テストケース自動生成システム１００は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶部１０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ１０３、前記記憶部１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算部１０４、ユーザからのキー入力等を受け付けるキーボードやマウス等の入力部１０５、処理データの表示を行うディスプレイ等の表示部１０６を備える。なお、記憶部１０１内には、本実施形態のテストケース自動生成システムとして必要な機能を実装する為のプログラム１０２と、各種テーブル、データ類が記憶されている。
【００１６】
記憶部１０１に格納されているテーブルやデータの類としては、各種設計書間に共通する項目について予め定義したテーブル１２５（設計書テーブル６０１、設計項目テーブル６０２、設計書詳細テーブル６０３、設計項目データテーブル６０４を含む）と、予めユーザから指定を受けているテスト情報データベース１２６（テストケーステーブル６０５、テストケース詳細テーブル６０６、出力条件テーブル６０７を含む）がある。また、その他にも、雛形ファイル１２７、環境設定ファイル１２８なども記憶部１０１に格納されている。これらデータベースやファイルに関しては後述する。
【００１７】
こうしたテストケース自動生成システム１００では、前記各テーブル６０１〜６０４らが示す項目に応じて、画面遷移定義情報５やデータ仕様情報６などで構成される設計書１０を設計情報データベース１２５に登録する。またテストケース自動生成システム１００は、設計情報データベース１２５、テスト情報データベース１２６、および環境設定ファイル１２８を元に、雛形ファイル１２７を利用してテストケース２０を自動生成することとなる。
【００１８】
続いて、本実施形態のテストケース自動生成システム１００が備える機能について説明する。上述したように、以下に説明する機能は、例えばテストケース自動生成システム１００の演算部１０４がプログラム１０２をそれぞれ実行することで実装される機能と言える。
【００１９】
前記テストケース自動生成システム１００は、テストケース別の、前記項目が記述に含まれたテスト内容の定義（テストケーステーブル６０５、テストケース詳細テーブル６０６）および出力条件（出力条件テーブル６０７）について、入力部１０５を介しユーザから指定を受けて、テスト情報データベース１２６として記憶部１０１に格納する機能を有している。
【００２０】
また、前記テストケース自動生成システム１００は、処理対象となる設計書１０のデータを前記各テーブル６０１〜６０４に照合し、該テーブルで定義された各項目に該当する情報を前記設計書１０のデータから抽出し、該抽出データを前記テーブル６０１〜６０４の項目に合わせて、設計情報データベース１２５として記憶部１０１にて記憶する機能を有している。
【００２１】
設計書１０はプログラム等を開発する上で必要となる設計項目を記載するものであり、同様のシステムを開発する場合、そのフォーマットはプロジェクト毎に異なるが、設計項目についてはプロジェクト間でほぼ共通となりやすい。そこで本実施形態のテストケース自動生成システム１００は、設計書１０のデータを、前記テーブル６０１〜６０４らのデータ項目に合わせて抽出し設計情報データベース１２５へ導入する処理を行うことで、テストケース２０の生成に利用する設計書１０の間のフォーマットの違いを吸収することとなる。
【００２２】
また、前記テストケース自動生成システム１００は、記憶部１０１から前記設計情報データベース１２５のデータを読み出し、該読み出したデータと、前記テスト情報データベース１２６における各テストケースの出力条件（出力条件テーブル６０７が示す情報）とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する機能を有している。
【００２３】
また、前記テストケース自動生成システム１００は、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベース１２５のデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する機能を有している。
【００２４】
なお、前記テストケース自動生成システム１００は、記憶部１０１から読み出した前記設計情報データベース１２５のデータと、前記テスト情報データベース１２６における各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベース１２５のデータに対しパターンマッチングさせるとすれば好適である。
【００２５】
こうした本実施形態のテストケース自動生成システム１００によれば、テスト情報データベース１２６におけるテーブル６０５〜６０７についてユーザがメンテナンス可能であり、テストケースに含ませるチェック条件や確認内容等、出力するテストケースの追加、変更、削除が可能となる。また、テストケースの出力条件の指定では正規表現を導入することで、パターンマッチングによるテストケースの出力制御を確実化かつ効率化できる。
【００２６】
続いて、本実施形態で処理対象となる設計書１０にデータ構成例等について説明しておく。図２は、本実施形態のテストケース自動生成システム１００における処理対象となる設計書１０のフォーマット例を示した図である。前記テストケース自動生成システム１００（以下、システム１００）が扱う設計書１０の一例としては、１つの表計算ファイルに存在する１つのシート上において、画面構成の定義等が記述されたデータを想定している（勿論、画面構成に関する設計書はあくまで一例である）。一般的に、表計算ファイルにおけるシートは、値の入力可能な矩形セルが縦横に行列配置されて構成されたものであり、各セルは行列中での配置を示す座標値（例えば、“Ａ列の３行目”であれば、「Ａ３」）でシート上の絶対位置が特定できる。１つの表計算ファイルに含まれるシート数に制限は無いことが普通であり、複数の各設計書１０を記述した複数のシートを、１つの表計算ファイルに含めておくことも可能である。
【００２７】
図２においては、画面一覧１１、画面項目定義書１２、画面ボタン定義書１３という３つの設計書フォーマットの例を示している。画面一覧１１は、システム開発で設計される全画面の情報を一覧化して表現した設計書フォーマットである。図２の例では、１つの表計算ファイル中の１つのシート（“画面一覧”のタグがシート左下に存在する）に記述したものとなっている。
【００２８】
一方、画面項目定義書１２と画面ボタン定義書１３は、前記画面一覧１１にて定義された各画面上に存在するすべての画面項目とボタン項目の情報をそれぞれ一覧化して表現した設計書フォーマットである。図２の例では、１つの表計算ファイル中のそれぞれシート（計２シート）に記述したものとなっている。よって、シート左下に“画面項目定義書”、“画面ボタン定義書”の各タグが存在している。
【００２９】
ここで、各シートの名、すなわちシート名は、処理対象の設計書１０が、後述する設計書テーブル６０１のどのレコードに該当するものか識別するため、設計書テーブル６０１で定義された「設計書名称」と同一名称である必要がある。したがって、図２の例に示す設計書フォーマットを考えた場合、設計書テーブル６０１には「設計書名称」として「画面一覧」、「画面項目定義書」、「画面ボタン定義書」という３つのレコードが存在することになる。
【００３０】
また、設計書１０に記載される設計項目は、１つの設計書において複数存在することを想定している。図２の例の場合、画面一覧１１においては、「画面ＩＤ」と「画面名」の２つの設計項目がある。また、画面項目定義書１２においては「画面ＩＤ」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」の６つの設計項目がある。また、画面ボタン定義書１３においては、「画面ＩＤ」、「画面ボタンＩＤ」、「画面ボタン名」の３つの設計項目がある。
【００３１】
なお、同一の設計項目が複数の設計書、すなわち図２の例の場合の画面一覧１１、画面項目定義書１２、画面ボタン定義書１３らに存在することも想定できる。複数の設計書に存在する設計項目は、設計書間の紐付けを行う設計項目であり、同一の設計項目のデータ値が互いに同じである設計書同士は関連する設計書となる。図２の例では、「画面ＩＤ」が複数の設計書に記述されており、この「画面ＩＤ」が一致する設計書同士が関連する設計書となる。
【００３２】
こうした設計書らのフォーマットに基づく設計項目間の関係例を図３にて示す。前記システム１００が扱う各設計項目の間は、１：Ｎの親子関係があることを想定している。親となる設計項目は子となる設計項目を一意に決定する設計項目である。親となる設計項目は複数の子となる設計項目を持つことができるが、子となる設計項目は親となる設計項目を１つしか持てない。したがって、親の設計項目に相当する値が決まると、子となる設計項目に相当する値が自動的に決まる。
【００３３】
図３に示す例では、図２に示した設計書フォーマット１１〜１３らの設計項目の間の親子関係が表現されている。この図において、「画面ＩＤ」は画面を一意に識別する設計項目であり、この画面ＩＤが決まると、「画面名」が自動的に決まるので、「画面ＩＤ」と「画面名」との間には「画面ＩＤ」が親かつ「画面名」が子という関係ができる。
【００３４】
また、「画面ＩＤ」に対して「画面名」は１つなので、「画面ＩＤ」と「画面名」は１：１の親子関係となる。「画面項目ＩＤ」は画面上の項目を一意に識別するためのＩＤである。画面上の項目は画面が決まると自動的に決まるので、「画面ＩＤ」と「画面項目ＩＤ」の間には「画面ＩＤ」が親かつ「画面項目ＩＤ」が子という関係ができる。また画面には複数の画面項目が存在するため、「画面ＩＤ」と「画面項目ＩＤ」の間は１：Ｎの親子関係となりうる。
【００３５】
また、「画面項目名」、「コントロール」、「桁」は「画面項目ＩＤ」が決まると自動的に決まる項目であり、「画面項目ＩＤ」と「画面項目名」、「コントロール」、「桁」には「画面項目ＩＤ」が親かつ「画面項目名」、「コントロール」、「桁」が子という関係ができる。また、「画面項目ＩＤ」に対して「画面項目名」、「コントロール」、「桁」はそれぞれ１つなので、「画面項目ＩＤ」と「画面項目名」、「コントロール」、「桁」の各間は１：１の親子関係となる。
【００３６】
また、「画面ボタンＩＤ」は「画面項目ＩＤ」と同様の理由から、「画面ＩＤ」が親かつ「画面ボタンＩＤ」が子という１：Ｎの親子関係となる。さらに、「画面ボタン名」は「画面項目名」、「コントロール」、「桁」と同様の理由から、「画面ボタンＩＤ」が親かつ「画面ボタン名」が子という１：１の親子関係となる。
【００３７】
このようなフォーマットに基づいてユーザが作成した設計書１０としては、画面一覧１４、画面項目定義書１５、および画面ボタン定義書１６の各例を図４に示す。図４に示す例では、開発対象となる画面数は２つあり、画面一覧１４には２つの画面の情報が一覧形式で記述されている。また、画面項目定義書１５と画面ボタン定義書１６は、１画面についてそれぞれ作成した例であり、画面項目定義書１５では画面上に存在する２つの画面項目の情報が一覧形式で記述されており、画面ボタン定義書１６では画面上に存在する１つのボタンの情報が一覧形式で記述されている。
【００３８】
こうした設計書について図３同様に設計項目間の関係を示したのが図５となる。図４でえ例示した設計例では、画面には２つの画面項目と１つのボタン項目が存在している。そこで、画面ＩＤ：ＳＣＲＥＥＮ０１には、１つの画面名：ユーザ登録画面と、２つの画面項目ＩＤ：ｕｓｅｒＩｄ、ｕｓｅｒＮａｍｅと、１つのボタン項目ＩＤ：ｉｎｓｅｒｔが子の設計項目データとして存在する。さらに画面項目ＩＤ：ｕｓｅｒＩｄには画面項目名：ユーザＩＤと、コントロール：テキストと、桁：１０と、必須：○、という子となる４つの設計項目データが存在し、画面項目ＩＤ：ｕｓｅｒＮａｍｅには、画面項目名：ユーザ名と、コントロール：テキストと、桁：５と、必須：−、という子となる４つの設計項目データが存在する。また、画面ボタンＩＤ：ｉｎｓｅｒｔには、画面ボタン名：登録という子となる１つの設計項目データが存在する。
【００３９】
続いて、前記システム１００が利用する設計情報データベース１２５とテスト情報データベース１２６のテーブル構成例について図６〜９に基づき説明する。
【００４０】
設計情報データベース１２５は、設計書テーブル６０１、設計項目テーブル６０２、設計書詳細テーブル６０３、および設計項目データテーブル６０４の４つのテーブルから構成される。
【００４１】
設計書テーブル６０１は、前記システム１００の入力となる設計書１０に関する情報を保持するためのテーブルである。この設計書テーブル６０１は、図７にも示すように、設計書ＩＤ７０１と設計書名称７０２の２つの項目からなる。設計書ＩＤ７０１は設計書テーブル６０１の主キーとなる項目であり、入力となる設計書を一意に識別するためのＩＤである。設計書名称７０２は入力となる設計書の日本語名称を表すものである。設計書名称７０２は、図２で説明したとおり、ユーザが指定した設計書がどの設計書なのかを識別するために、入力となる設計書のシート名と同一である必要がある。
【００４２】
上記図２の例では、設計書には画面一覧１４、画面項目定義書１５、および画面ボタン定義書１６の３つの設計書があるため、図７に示す設計書テーブル６０１の例では、各設計書３件の情報が登録されている。設計書ＩＤ７０１には一意となるＩＤを設定する必要があり、画面一覧１４、画面項目定義書１５、画面ボタン定義書１６に対する各設計書ＩＤには、それぞれ重複しない値として、例えば、「ＳｃｒｅｅｎＬｉｓｔ」、「ＳｃｒｅｅｎＩｔｅｍ」、「ＳｃｒｅｅｎＢｕｔｔｏｎ」を設定している。設計書名称７０２には、図２で説明したとおり表計算ファイルのシート名と一致する必要があるため、設計書名称７０２にはそれぞれ、「画面一覧」、「画面項目定義書」、「画面ボタン定義書」を設定している。
【００４３】
また、設計項目テーブル６０２はシステム開発する上で必要となる、設計書に記載された設計項目の情報を保持するためのテーブルである。この設計項目テーブル６０２は、図８にて示すように、設計項目ＩＤ８０１、設計項目名称８０２、親設計項目ＩＤ８０３の３つの項目からなる。設計項目ＩＤ８０１は設計項目テーブル６０２の主キーとなる項目であり、設計項目を一意に識別するためのＩＤである。設計項目名称８０３は入力となる設計書に記載された設計項目の日本語名称を表すものである。親設計項目ＩＤ８０２は、図３で説明したとおり、設計項目間に１：Ｎの親子関係があることを踏まえ、子となる設計項目に対して親となる設計項目の設計項目ＩＤを設定するための項目である。
【００４４】
図８に示す設計項目テーブル６０２の例においては、設計項目として、「画面一覧」について「画面ＩＤ」と「画面名」の２つの設計項目が、「画面項目定義書」について「画面ＩＤ」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」の６つの設計項目が、「画面ボタン定義書」について「画面ＩＤ」、「画面ボタンＩＤ」、「画面ボタン名」の３つの設計項目が存在する。また「画面ＩＤ」は「画面一覧」、「画面項目定義書」、「画面ボタン定義書」のすべての設計書に存在しており、設計項目としては重複を除き「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「」画面ボタンＩＤ」、「画面ボタン名」の９つの設計項目が存在する。したがって、設計項目テーブル６０２には、９件の情報が登録されている。設計項目ＩＤ８０１には一意となるＩＤを設定する必要があり、「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「画面ボタンＩＤ」、「画面ボタン名」に対する設計項目ＩＤにはそれぞれ重複しない値として、「ＳｃｒｅｅｎＩｄ」、「ＳｃｒｅｅｎＮａｍｅ」、「ＳｃｒｅｅｎＩｔｅｍＩｄ」、「ＳｃｒｅｅｎＩｔｅｍＮａｍｅ」、「ＳｃｒｅｅｎＩｔｅｍＣｔｌ」、「ＳｃｒｅｅｎＩｔｅｍＳｉｚｅ」、「ＳｃｒｅｅｎＩｔｅｍＮｅｃｅｓｓａｒｙ」、「ＳｃｒｅｅｎＢｕｔｔｏｎＩｄ」、「ＳｃｒｅｅｎＢｕｔｔｏｎＮａｍｅ」を設定している。
【００４５】
また、設計項目名称８０３は、設計項目の日本語名称であるため、「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「画面ボタンＩＤ」、「画面ボタン名」といった名称を設定している。さらに親項目の設計項目ＩＤ８０２には、設計項目間に図３に示す親子関係があるため、「画面ＩＤ」に関しては未設定を示す「−」が設定され、「画面名」、「画面項目ＩＤ」、「画面ボタンＩＤ」に関しては「ＳｃｒｅｅｎＩｄ」が設定され、「画面項目名」、「コントロール」、「桁」、「必須」に関しては「ＳｃｒｅｅｎＩｔｅｍＩｄ」が設定され、「画面ボタン名」に関しては「ＳｃｒｅｅｎＢｕｔｔｏｎＩｄ」が設定されている。
【００４６】
また、設計書詳細テーブル６０３は、設計書１０と設計項目とを紐付けるためのテーブルであり、設計書１０のどの位置にどの設計項目が存在するかという情報を保持するためのテーブルである。設計書詳細テーブル６０３は、図９に例示するように、設計書ＩＤ９０１、設計項目ＩＤ９０２、絶対位置９０３、繰返し有無９０４、データ読込方向９０５、登録有無９０６の６つの項目からなる。
【００４７】
設計書ＩＤ９０１と設計項目ＩＤ９０２は設計書詳細テーブル６０３の主キーとなる項目であり、どの設計書にどの設計項目が記載されるかを示すものである。設計書ＩＤ９０１は設計書テーブル６０１に存在する設計書ＩＤ７０１である必要があり、設計項目ＩＤ９０２は設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。絶対位置９０３は設計書のどの位置に設計項目が存在するかを示す情報である。図２をもとに例を示すと、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは「Ａ２」の位置から開始されるため、絶対位置９０３には「Ａ２」が設定される。また、繰り返し有無９０４は、設計項目のデータが設計書間で１つなのか複数なのかを示す情報であり、１つの場合には「無」が、複数の場合には「有」が設定される。図２の例をもとに説明すると、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは複数記述されるため、繰返し有無９０４には「有」が設定される。一方、設計書：画面項目定義書にある設計項目：画面ＩＤに対するデータは１つしか記述されないため、繰返し有無９０４には「無」が設定される。また、データ読込方向９０５は設計項目のデータが複数の場合に利用され、データの繰返し方向を示すものであり、該当設計項目が上方向に繰り返される場合には「↑」が、下方向に繰り返される場合には「↓」が、左方向に繰り返される場合には「←」が、右方向に繰り返される場合には「→」が設定される。また設計項目のデータが１つの場合には「−」が設定される。図２をもとに例を示すと、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは下方向に複数記述されるため、データ読込方向９０５には「↓」が設定される。一方、設計書：画面項目定義書にある設計項目：画面ＩＤに対するデータは１つしか記述されないため、データ読込方向９０５には「−」が設定される。また、登録有無９０６は複数の設計書に記載される設計項目に関して、どの設計書から設計項目データを登録するかを示す情報である。複数の設計書から同一の設計項目データを登録しても無駄な情報が増えてしまうだけなので、設計項目データは１つの設計書からしか登録できないようにしている。したがって、ある設計項目について、ある設計書で登録有無９０６が「有」になっている場合、その設計項目について他の設計書に関して「無」とする必要がある。図２をもとに例を示すと、設計項目：画面ＩＤは３つの設計書に記載されるため、このうちの１つの設計書でしか登録有無９０６を「有」に設定できない。したがって、設計書：画面一覧にて登録有無９０６を「有」に設定した場合、設計書：画面項目定義書と設計書：画面ボタン定義書では登録有無９０６を「無」にしか設定できない。
【００４８】
図９に例示した設計詳細テーブルでは、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＩｄ」と、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＮａｍｅ」という２つのレコードが登録されている。図２の例であれば、「画面ＩＤ」は「Ａ２」の位置から下方向に複数記述されるため、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＩｄ」のレコードの絶対位置９０３に「Ａ２」が、繰返し有無９０４には「有」が、データ読込方向９０５には「↓」が設定される。また、「画面ＩＤ」は複数の設計書に記述されており、この例では「画面一覧」から登録するため、登録有無９０６を「有」にしている。したがって、「画面ＩＤ」が記述されている画面項目定義書１５と画面ボタン定義書１６では登録有無９０６を「無」にしている。同様に「画面名」は「Ｂ２」の位置から下方向に複数記述されているため、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＮａｍｅ」のレコードの絶対位置９０３に「Ｂ２」が、繰返し有無９０４には「有」が、データ読込方向９０５には「↓」が設定される。また「画面名」は「画面一覧」にのみ記述されているため、登録有無９０６は「有」に設定されている。他の設計書についても同様に設定することができる。こうした、設計書のデータをテーブル１１〜１３の項目に基づいて抽出・設定し、設計情報データベース１２５を作成する処理は、前記システム１００が実行する。表計算ファイルのシートは上述のように絶対位置が判明しているセルによって構成されているから、前記システム１００は、設計書１０からのデータ抽出等に際しては、シート中の規定セル（例：“Ａ１”など最上行の最左列のセル）から順次セルの値を読み込んで、該当設計項目のＩＤや名称が設定されたセルを特定し、それと連結ないし隣接したセルの値すなわち設計項目の値を読み取るといった処理を実行していけばよい。他のテーブル類に基づく設計書１０からのデータ抽出についても同様である。
【００４９】
また、設計項目データテーブル６０４は、設計書１０から読込んだ設計項目のデータを保持するためのテーブルである。設計項目データテーブル６０４はデータ番号１１０１、設計項目ＩＤ１１０２、値１１０３、親項目のデータ番号１１０４という４つの項目からなる。データ番号１１０１は設計項目のデータを一意に識別するための情報であり、設計項目のデータを設計項目データテーブル６０４に格納する際にシステム１００が自動採番して作成する。設計項目ＩＤ１１０２は設計項目のデータがどの設計項目に関するものかを示すものであり、設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。値１１０３は設計書１０から読込んだ設計項目のデータを格納する。親項目のデータ番号１１０４は、図５で説明したとおり、設計項目間における１：Ｎの親子関係に基づいて、子となる設計項目データに対して親となる設計項目データのデータ番号を設定する項目である。親項目のデータ番号１１０４は設計項目データテーブル６０４に存在するデータ番号１１０１である必要がある。
【００５０】
一方、テスト情報データベース１２６は、テストケーステーブル６０５、テストケース詳細テーブル６０６、出力条件テーブル６０７の３つのテーブルから構成される。テストケーステーブル６０５は生成するテストケース１件の情報を保持するテーブルである。テストケーステーブル６０５は、図１５に示すようにテストケースＩＤ１５０１、テストケース名１５０２、出力条件ＩＤ１５０３の３つの項目からなる。テストケースＩＤ１５０１はテストケーステーブル６０５の主キーとなる項目であり、テストケースを一意に識別するためのＩＤである。テストケース名１５０２はテストケースの日本語名称を表すものである。出力条件ＩＤ１５０３はテストケースを出力するための条件を表すものであり、ここに値を設定することで、テストケースの出力制御が可能となる。出力条件ＩＤ１５０３は出力条件テーブル６０７に存在する出力条件ＩＤ１７０１である必要がある。
【００５１】
また、テストケース詳細テーブル６０６は、テストケースを実行する手順を操作単位で格納するテーブルである。図１６に示すように、テストケース詳細テーブル６０６はテストケースＩＤ１６０１、操作番号１６０２、出力区分１６０３、操作内容１６０４の４つの項目からなる。テストケースＩＤ１６０１と操作番号１６０２はテストケース詳細テーブル６０６の主キーとなる項目であり、テストケースを実現するための手順を構成する１つの操作を示すものである。テストケースＩＤ１６０１はテストケーステーブル６０５に存在するテストケースＩＤ１５０１である必要がある。出力区分１６０３は操作の区分を示すものであり、テストケースのチェック条件となる操作に対しては「条件」を、テストケースの確認内容となる操作に対しては「確認」を設定する。操作内容１６０４はテストする際の具体的な操作を示すものである。チェック条件となる操作としては「画面項目に値を入力する」、「ボタンを押す」などの操作があり、確認内容となる操作としては「ボタン押下後の画面状態を確認する」などの操作がある。また、操作内容１６０４には、設計情報データベース１２５の設計項目テーブル６０２における設計項目ＩＤ８０１が埋め込み可能であり、設計項目ＩＤ８０１を「｛設計項目ＩＤ｝」という形式で設定することで対応する設計項目のデータを出力可能にしている。ここで設定する設計項目ＩＤは、設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。さらに、出力するファイルで利用可能な関数を記述可能にすることで、設計項目を利用した関数による演算結果も出力することが可能である。
【００５２】
また、出力条件テーブル６０７はテストケースの出力を制御するための条件情報を格納するテーブルである。出力条件テーブル６０７は出力条件ＩＤ１７０１、設計項目ＩＤ１７０２、出力条件内容１７０３の３つの項目からなる。出力条件ＩＤ１７０１は出力条件テーブル６０７の主キーとなる項目であり、出力条件を一意に識別するＩＤである。設計項目ＩＤ１７０２と出力条件内容１７０３はテストケースを出力するための条件を表すものであり、設計項目ＩＤ１７０２に対する設計項目データが出力条件内容に指定されたパターンを満たす場合にテストケースを出力する。設計項目ＩＤ１７０２は設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。
【００５３】
続いて、本実施形態における設計書１０のデータを設計情報データベース１２５に登録する際の処理を図１０に基づき説明する。なお、上述したように、前記システム１００が、設計書１０のデータから、設計書テーブル６０１、設計項目テーブル６０２、および設計書詳細テーブル６０３の各設計項目について値を抽出し、該当テーブルに対応した形式で記憶部１０１にデータを保持しているものとする。
【００５４】
この場合、前記システム１００は、例えば、入力部１０５にてユーザより入力されたフォルダ名の情報を取得する（ステップ１１０）。システム１００は、例えば記憶部１０１に格納されていた該当フォルダにアクセスし、設計書１０を格納した表計算ファイルを全て取得する（ステップ１２０）。
【００５５】
次に前記システム１００は、前記ステップ１２０で取得した表計算ファイルを１つずつ読込んでいく。読込む表計算ファイルがある場合（ステップ１３０：有）、前記システム１００はステップ１４０に処理を進める。一方、読込む表計算ファイルが無い場合（ステップ１３０：無）、前記システム１００は処理を終了する。こうしたステップ１３０の処理は、前記ステップ１２０で得た全ての表計算ファイルについて、読込む表計算ファイルが無くなるまで繰り返し実行される。
【００５６】
続いて前記システム１００は、前記ステップ１２０で取得した表計算ファイルから、各設計書１０のデータが記述されたシートを取得する（ステップ１４０）。前記システム１００は、取得した表計算ファイルの全シートを１シートずつ読込んでいく（ステップ１５０）。読込むシートがある場合（ステップ１５０：有）、前記システム１００は処理をステップ１６０に進める。他方、読込むシートが無い場合（ステップ１５０：無）、前記システム１００は、処理をステップ１３０に戻す。こうした処理は、前記ステップ１４０で取得した全シートについて、読込むシートが無くなるまで繰り返し実行する。
【００５７】
続いて前記システム１００は、読込んだシートからシート名を取得する（ステップ１６０）。また前記システム１００は、設計情報データベース１２５の設計書テーブル６０１にアクセスし、設計書テーブル６０１の設計書名称７０２が前記取得したシート名と一致するレコードの設計書ＩＤ７０１を取得する（ステップ１７０）。
【００５８】
次に前記システム１００は、前記ステップ１７０で設計書ＩＤ７０１を取得できた場合（ステップ１８０：有）、処理をステップ１９０に進める。一方、前記ステップ１７０にて設計書ＩＤ７０１を取得できなかった場合（ステップ１８０：無）、前記システム１００は処理をステップ１５０に戻す。
【００５９】
続いて前記システム１００は、設計情報データベース１２５の設計書詳細テーブル６０３にアクセスし、設計詳細テーブルの設計書ＩＤ９０１が前記ステップ１７０で取得した設計書ＩＤ７０１と一致するレコード（設計書詳細レコード）を取得する（ステップ１９０）。前記システム１００は、取得した設計書詳細レコードを１つずつ読込んでいく。読込む設計書詳細レコードがある場合（ステップ２００：有）、前記システム１００は、処理をステップ２１０に進める。他方、読込む設計書詳細レコードが無い場合（ステップ２００：無）、前記システム１００は、処理をステップ１５０に戻す。こうした処理は、前記ステップ１９０で取得した全設計書詳細レコードについて、読込む設計書詳細レコードが無くなるまで繰り返し実行される。
【００６０】
続いて前記システム１００は、前記読み込んだ設計書詳細レコードから設計項目ＩＤ９０２、絶対位置９０３、繰返し有無９０４、データ読込方向９０５、登録有無９０６の各値を取得する（ステップ２１０）。そして前記システム１００は、ここで取得した登録有無９０６が「有」の場合（ステップ２２０：有）、処理をステップ２３０に進める。他方、登録有無９０６が「無」の場合（ステップ２２０：無）、前記システム１００は処理をステップ２００に戻す。
【００６１】
次に前記システム１００は、設計情報データベース１２５の設計項目テーブル６０２にアクセスし、設計項目テーブル６０２の設計項目ＩＤ８０１が前記ステップ２１０で取得した設計項目ＩＤ９０２と一致するレコードにおける、親項目の設計項目ＩＤ８０２を取得する（ステップ２３０）。
【００６２】
前記システム１００は、親項目の設計項目ＩＤ８０２を取得できた場合（ステップ２４０：有）、処理をステップ２５０に進める。他方、親項目の設計項目ＩＤ８０２を取得できなかった場合（ステップ２４０：無）、前記システム１００は処理をステップ２６０に進める。
【００６３】
続いて前記システム１００は、記憶部１０１にて保持する所定のデータ番号（後述するステップ２８０で採番したもの）中から、前記ステップ２３０で得た親項目の設計項目ＩＤ８０２に対応するデータ番号を、親項目のデータ番号として取得する（ステップ２５０）。勿論、前記ステップ１７０〜ステップ２４０の処理は、設計項目テーブル６０２における各設計項目間の親子関係に沿って最上位の親から順次行っていくから、当初は未だデータ番号が採番されていない状況であり、親項目のデータ番号は取得できない。よって、前記親子関係において親をもつ設計項目に関する処理が行われるまで、当該ステップはスルーする。
【００６４】
次に前記システム１００は、前記ステップ１４０より処理中となっている該当シートにおいて、絶対位置９０３にあるセルからデータを取得する（ステップ２６０）。前記ステップ２１０で得た繰返し有無９０４が「有」の場合、前記システム１００はデータ読込方向９０５を元に全データを取得する。
【００６５】
続いて前記システム１００は、前記ステップ２６０で取得した全データから１データずつ読込んでいく。読込むデータがある場合（ステップ２７０：有）、前記システム１００はステップ２８０に処理を進める。他方、読込むデータが無い場合（ステップ２７０：無）、前記システム１００は処理をステップ２００に戻す。こうした処理は、前記ステップ２６０で得た全データについて、読込むデータが無くなるまで繰り返し実行される。
【００６６】
次に前記システム１００は、前記ステップ２６０で得た各設計項目のデータを設計項目データテーブル６０４に登録すべく、該当データ（設計項目データ）用のデータ番号を自動採番する（ステップ２８０）。データ番号の自動採番については、登録順に１つずつ番号をインクリメントするといった一般的手法を採用すればよい。
【００６７】
続いて前記システム１００は、設計項目データテーブル６０４におけるデータ番号１１０１の欄に、前記ステップ２８０で自動採番したデータ番号を、また同様に、設計項目ＩＤ１１０２の欄に前記ステップ２１０で取得した設計項目ＩＤ９０２を、また同様に、値１１０３の欄に前記ステップ２６０で取得したデータを、また同様に、親項目のデータ番号すなわち親データ番号１１０４の欄に前記ステップ２５０で取得したデータ番号を設定し、データ登録を行う（ステップ２９０）。前記システム１００は、前記ステップ２８０で自動採番したデータ番号を記憶部１０１に保持し、ステップ２００に戻る（ステップ３００）。以降、前記システム１００は、設計書詳細レコードがある限り（ステップ２００：無→ステップ１５０）、またシートがある限り（ステップ１５０：無→ステップ１３０）、更に、表計算ファイルが無くなるまで（ステップ１３０：無→ＥＮＤ）、上記処理を繰り返し実行することとなる。
【００６８】
図１１は、図４の設計書１０を上述のフローを経て登録した設計項目データテーブル６０４の例を示す図である。ここでは一例として、設計書１０のうち画面一覧１４について説明する。システム１００は画面一覧１４のデータから「画面ＩＤ」と「画面名」を抽出し登録することになる。まず、「画面ＩＤ」は「ＳＣＲＥＥＮ０１」と「ＳＣＲＥＥＮ０２」の２つがあるため、システム１００は、データ番号１１０１には自動採番された「１」と「２」を、設計項目ＩＤ１１０２には「画面ＩＤ」の設計項目ＩＤ：ＳｃｒｅｅｎＩｄを、「値」には「ＳＣＲＥＥＮ０１」と「ＳＣＲＥＥＮ０２」をそれぞれ設定する。なお親データ番号１１０４は、「画面ＩＤ」に対する親項目の設計項目が無いため未設定となる。また、「画面名」は「ユーザ登録画面」と「結果画面」の２つがあるから、前記システム１００は、データ番号１１０１には自動採番した「３」と「４」を、設計項目ＩＤ１１０２には画面名の設計項目ＩＤ：ＳｃｒｅｅｎＮａｍｅを、値１１０３には「ユーザ登録画面」と「結果画面」をそれぞれ設定する。また「画面名」に対する親項目の設計項目が「画面ＩＤ」であるため、前記システム１００は、「ユーザ登録画面」の親データ番号１１０４として「１」を、また「結果画面」の親データ番号１１０４として「２」をそれぞれ設定する。その他の項目も同様に設定されるものである。
【００６９】
続いて、テストケース自動生成の処理について説明する。まずは、テストケース自動生成に際し前記システム１００が用いるファイル等について例示する。図１２は、前記システム１００が利用する雛形ファイル１２７の例を示す図である。前記システム１００がテストケース自動生成時に利用する雛形ファイル１２７は、設計書１０と同様に表計算ファイルが想定できる。前記システム１００は設計情報データベース１２５に保持する設計項目のデータと、テスト情報データベース１２６に予め保持するテストケースの定義とその出力条件をもとに、出力すべきテストケースを作成し、これを雛形ファイル１２７に適用し出力することでテストケース（のファイル）を自動生成する。１つの表計算ファイルは、図１３で説明する環境設定ファイル１２８で指定された設計項目ＩＤに対する設計項目データ単位に作成し、１つのテストケースは１つのシートに出力する。
【００７０】
図１３は、前記システム１００が利用する環境設定ファイル１２８の例を示す図である。前記システム１００がテストケース自動生成時に利用する環境設定ファイル１２８はテキストファイルが想定できる。環境設定ファイル１２８には、テストケースの出力単位となる設計項目ＩＤを指定する。前記システム１００ではこの環境設定ファイル１２８で指定された設計項目ＩＤに対する設計項目のデータと、その設計項目に紐づく子となるすべての設計項目のデータを元にテストケースを作成することになる。図１３の例では、設計項目ＩＤとして「画面ＩＤ」が指定されているため、この場合、前記システム１００は図５に示す画面ＩＤ：ＳＣＲＥＥＮ０１にぶら下がるすべての設計項目のデータを元にテストケースを作成する。
【００７１】
続いて、前記システム１００が自動生成したテストケース２０の例を示しておく。図１４に示す例ではテストケース２０が、「必須チェック（未入力）」と「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」の３つのテストケースから構成されている。
【００７２】
そのうち、「必須チェック（未入力）」は、必須指定された項目に対して未入力の場合に入力エラーが発生するかを確認するテストケースである。また、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」は、画面上の入力項目に対して桁数分しか入力できないことを確認するテストケースであり、入力項目への入力文字数のパターンとして桁数分と（桁数＋１）分の２つのパターンを用意している。
【００７３】
また、「必須チェック（未入力）」のテストケースは、設計項目のうち「必須」が「○」になっている項目に対してのみ実施するテストケースであり、図４の例においては、「ユーザＩＤ」のみ「必須」が「○」となっているため、「ユーザＩＤ」に対する１件のテストケース、すなわちこの図１４で示す「必須チェック（未入力）」のテストケースが出力された結果となっている。また、「入力可能桁数（桁数）」と「入力可能桁数（桁数＋１）」の各テストケースは、全画面項目に対して行うチェックであり、「ユーザＩＤ」と「ユーザ名」の両方に対してチェックしている。また、出力する表計算ファイルのシートはテストケース単位となっている。
【００７４】
続いて、前記システム１００がテストケース自動生成時に利用するテスト情報データベース１２６を構成するテーブルについて説明する。図１５は、テストケーステーブル６０５の例を示す図である。ここで例示するテストケーステーブル６０５は、テストケースとして「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」の３つのテストケースに関する計３件のレコードが登録されている。こうしたレコードは、テスト担当のユーザが事前に設定しており、必要に応じてユーザによる更新作業が可能となっている（システム１００が当該テーブルを出力部１０６に表示し、入力部１０５でユーザ指示を受ける）。以降、他のテーブルについても同様にシステム１００が情報の表示を行って、ユーザによる閲覧、更新、削除等の指示を受け付けてデータ更新等を実行可能とする。従って、図１５のテストケーステーブル６０５であれば、テストケースの追加や削除、テストケース名１５０２や出力条件ＩＤ１５０２の変更等も、システム１００が出力部１０６にて該当情報を表示してユーザ閲覧に供しつつ、入力部１０５にて変更等の指示を受けて、該当データの更新等を行うこととなる。
【００７５】
このテストケーステーブル６０５において、テストケースＩＤ１５０１は、テストケース毎に一意となる情報であるため、「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」のそれぞれに関し、互いに重複しない値として「ＴＣ００１」、「ＴＣ００２」、「ＴＣ００３」が設定されている。テストケース名１５０２はテストケースの日本語名称を表すものであるため、「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」が設定されている。また、出力条件ＩＤ１５０３はテストケースの出力制御を行うものであり、「必須チェック（未入力）」のテストケースは「必須」が「○」の場合にのみ出力するとの条件があるため、出力条件ＩＤ１５０３に例えば該当条件を示す「ＯＰ００１」が設定されている。他方、「入力可能桁数（桁数）」と「入力可能桁数（桁数＋１）」の各テストケースは、すべての画面項目に対して出力するテストケースであるため。出力条件ＩＤ１５０３は未設定となっている。
【００７６】
また、前記テスト情報データベース１２６を構成する、テストケース詳細テーブル６０６は、図１６に例示するように、各テストケース（上記例では３つのテストケース）に対してそれぞれ実行手順が記述されたテーブルとなる。ここでは、テストケース：必須チェック（未入力）に関して説明する。テストケース：必須チェック（未入力）は、５つのチェック条件に関する操作と３つの確認に関する操作の計８つの操作からなる。
【００７７】
操作内容１６０４には｛設計項目ＩＤ｝が埋め込まれており、システム１００が自動生成するテストケースにおいては、前記設計項目ＩＤの記述が、対応する設計項目のデータ（設計書１０から抽出したもの）で置換されて出力される。
【００７８】
また図１６において、操作番号１６０２が「１」の操作内容１６０４は「｛ＳｃｒｅｅｎＩｄ｝：｛ＳｃｒｅｅｎＮａｍｅ｝が表示されている。」となっており、設計項目ＩＤとして「ＳｃｒｅｅｎＩｄ」と「ＳｃｒｅｅｎＮａｍｅ」が埋め込まれているため、図４、図８の場合には、テストケースとしては｛ＳｃｒｅｅｎＩｄ｝が「ＳＣＲＥＥＮ０１」に、｛ＳｃｒｅｅｎＮａｍｅ｝が「ユーザ登録画面」に置換されて、「ＳＣＲＥＥＮ０１：ユーザ登録画面が表示されている。」が出力されることになる。また、操作番号１６０２が「２」の操作内容１６０４は「以下の項目を未入力にする」となっており、設計項目ＩＤは埋め込まれていないため、このまま出力される。また、操作番号１６０２が「３」の操作内容１６０４は「ＳｃｒｅｅｎＩｔｅｍＩｄ」：｛ＳｃｒｅｅｎＩｔｅｍＮａｍｅ｝」となっており、設計項目ＩＤとして「ＳｃｒｅｅｎＩｔｅｍＩｄ」、「ＳｃｒｅｅｎＩｔｅｍＮａｍｅ」が埋め込まれているため、図４、図８の場合には、画面項目が２つ存在しており、「ｕｓｅｒＩｄ：ユーザＩＤ」と「ｕｓｅｒＮａｍｅ：ユーザ名」の２行が出力される。その他の操作番号のレコードについても同様に出力されるものである。
【００７９】
図１７は、出力条件テーブル６０７の例を示す図である。上述までの例において、出力の制御をしたいテストケースとして「必須チェック(未入力)」がある。そこで図１７の出力条件テーブル６０７では、「必須チェック(未入力)」のテストケース用の出力条件として、１件のレコードが登録されている。このレコードが示す条件において、「必須チェック（未入力）」のテストケースは、画面項目に対する「必須」が「○」になっている場合にテストケースとして出力する。出力条件ＩＤ１７０１は出力条件を一意に識別するＩＤであり、ここでは「ＯＰ００１」が設定されている。また、前記「必須チェック（未入力）」のテストケースに関する出力条件が、画面項目に対する「必須」が「○」になっていることであることから、設計項目ＩＤ１７０２には、「必須」に対する設計項目ＩＤ：ＳｃｒｅｅｎＩｔｅｍＮｅｃｅｓｓａｒｙが、また、出力条件内容１７０３に「○」が設定されている。
【００８０】
続いて、前記システム１００が、設計情報データベース１２５とテスト情報データベース１２６に基づいてテストケース２０を自動生成する処理について、図１８，図１９に基づき説明する。まず、前記システム１００は、図１３に例示した環境設定ファイル１２８から画面ＩＤに相当する設計項目ＩＤを取得する（ステップ５１０）。
【００８１】
次に前記システム１００は、設計情報データベース１２５の設計項目データテーブル６０４にアクセスし、設計項目データテーブル６０４の設計項目ＩＤ１１０２が、前記ステップ５１０で取得した設計項目ＩＤと一致するレコード、すなわち設計項目データレコードを取得する（ステップ５２０）。
【００８２】
また、前記システム１００は、前記ステップ５２０で取得した設計項目データレコードを１つずつ読込んでいく。設計項目データレコードがある場合（ステップ５３０：有）、前記システム１００は処理をステップ５４０に進める。他方、設計項目データレコードが無い場合（ステップ５３０：無）、前記システム１００は処理を終了する。こうした処理は、前記ステップ５２０で得た設計項目データレコードが無くなるまで繰り返し実行される。
【００８３】
続いて前記システム１００は、前記ステップ５２０で取得したレコードからデータ番号１１０１を取得する（ステップ５４０）。また前記システム１００は、設計情報データベース１２５の設計項目データテーブル６０４にアクセスし、前記ステップ５４０で取得したデータ番号１１０１を頂点として連なる親子関係において、子となる設計項目のデータを、子が無くなるまですべて取得する（ステップ５５０）。つまり前記システム１００は図３と図５に相当する情報を作成する。
【００８４】
前記システム１００は、テスト情報データベース１２６のテストケーステーブル６０５にアクセスし、全てのテストケースのレコードを取得する（ステップ５６０）。また前記システム１００は、ここで取得したテストケースレコードを１つずつ読込んでいく。テストケースレコードがある場合（ステップ５７０：有）、前記システム１００は処理をステップ５８０に進める。他方、テストケースレコードが無い場合（ステップ５７０：無）、前記システム１００は処理を終了する。こうした処理は、前記ステップ５６０で得たテストケースレコードが無くなるまで繰り返し実行される。
【００８５】
続いて前記システム１００は、前記ステップ５７０で取得したレコードから出力条件ＩＤ１５０３を取得する（ステップ５８０）。また前記システム１００は、該ステップ５８０で出力条件ＩＤ１５０３を取得できた場合（ステップ５９０：有）、処理をステップ６００に進める。他方、出力条件ＩＤ１５０３が無かった場合（ステップ５９０：無）、前記システム１００は処理をステップ６５０に進める。
【００８６】
前記ステップ５９０に続き、前記システム１００は、テスト情報データベース１２６の出力条件テーブル６０７にアクセスし、出力条件テーブル６０７の出力条件ＩＤ１７０１が、前記ステップ５８０で取得した出力条件ＩＤ１５０３と一致する出力条件レコードを取得する（ステップ６００）。
【００８７】
そして前記システム１００は、前記ステップ６００で取得した出力条件レコードから設計項目ＩＤ１７０２と出力条件内容１７０３を取得する（ステップ６１０）。また前記システム１００は、ここで取得した設計項目ＩＤ１７０２に対応する設計項目の値１１０３を、前記ステップ５５０で取得、作成した情報から取得する（ステップ６２０）。
【００８８】
次に前記システム１００は、前記ステップ６１０で取得した出力条件内容１７０３について正規表現を用いて、前記ステップ６２０で取得した設計項目の値１１０３とのマッチングを行う（ステップ６３０）。正規表現は、文字列のパターンを表現する表記法であり、文字列の検索・置換を行うときに利用されるものとなる。正則表現と呼ばれることもある。この正規表現においては、通常の文字と、メタキャラクタと呼ばれる特別な意味を持った記号を組み合わせた表記がなされる。正規表現を用いれば、文字列を直接指定せず、「特徴」(パターン)を指定することができるため、表記の揺れを吸収して検索を行ったり、複数の異なる文字列を一括して置換したりすることができる。例えば「^」という文字は「行頭」、「.」は「任意の1文字」、「+」という文字は「直前の要素の１回以上の繰り返し」を意味するなどの規定がある。従って前記システム１００は、出力条内容１７０３が示す内容について、こうした正規表現にて記述するために、正規表現の規定について辞書データと所定の変換アルゴリズムを予め記憶部１０１に備えており、出力条件内容１７０３を入力として正規表現を生成し、これをベースにして、前記ステップ６２０で取得した設計項目の値１１０３とのパターンマッチングを行うものとする。
【００８９】
パターンマッチングの結果、前記出力条件内容１７０３と、前記ステップ６２０で取得した設計項目の値１１０３とがマッチした場合（ステップ６４０：可）、前記システム１００は該当テストケースについて出力可と判定し、他方、マッチしなかった場合（ステップ６４０：否）には出力不可と判定する。
【００９０】
続いて前記システム１００は、前記ステップ６４０での出力可否の結果をもとに、出力可の場合（ステップ６４０：可）、処理をステップ６５０に進める。他方、出力不可の場合（ステップ６４０：否）、前記システム１００は処理をステップ５７０に戻す。
【００９１】
前記システム１００は、前記ステップ５６０で取得したテストケースレコードからテストケースＩＤ１５０１とテストケース名１５０２を取得する（ステップ６５０）。この場合、前記システム１００は、雛形ファイル１２７からシート名が「ｔｅｍｐｌａｔｅ」となっているシートをコピーして、前記取得したテストケース名１５０２をシート名に持つ新規シートを作成する（ステップ６６０）。
【００９２】
次に前記システム１００は、テスト情報データベース１２６のテストケース詳細テーブル６０６にアクセスし、テストケース詳細テーブル６０６のテストケースＩＤ１６０１が前記ステップ６５０で取得したテストケースＩＤ１５０１と一致するレコード、すなわちテストケース詳細レコードを取得する（ステップ６７０）。
【００９３】
また前記システム１００は、前記ステップ６７０で取得したテストケース詳細レコードを１つずつ読込んでいく。テストケース詳細レコードがある場合（ステップ６８０：有）、システム１００は処理をステップ６９０に進める。他方、テストケース詳細レコードが無い場合（ステップ６８０：無）、前記システム１００は処理をステップ５７０に戻す。こうした処理は、前記ステップ６７０で得たテストケース詳細レコードが無くなるまで繰り返し実行される。
【００９４】
続いて前記システム１００は、前記ステップ６７０で取得したテストケース詳細レコードから出力区分１６０３と操作内容１６０４を取得する（ステップ６９０）。前記システム１００は、ここで取得した操作内容１６０４に含まれる設計項目ＩＤを取得する（ステップ７００）。この場合、前記システム１００は、操作内容１６０４のうち「｛」と「｝」に挟まれる値を設計項目ＩＤとして扱う。
【００９５】
前記システム１００は、前記ステップ７００で取得した設計項目ＩＤに対応する設計項目の値１１０３を、前記ステップ５５０で取得、作成した情報から取得する（ステップ７１０）。また前記システム１００は、前記ステップ７１０で取得した設計項目の値１１０３を、前記ステップ６９０で得た操作内容１６０４に含まれる設計項目ＩＤと置換する（ステップ７２０）。
【００９６】
前記システム１００は、前記ステップ６９０で取得した、「条件」や「確認」といった出力区分１６０３を元に、前記ステップ７２０で作成した操作内容をシート（前記ステップ６６０で雛形ファイル１２７から作成してあるシート。形式は図１２参照）における該当出力区分のセルに出力していくことで、テストケースの生成・出力処理を行う（ステップ７３０）。こうした処理を行うことで、図１４で例示したテストケース２０（のうち出力可のもの）が生成されることになる。こうしたテストケース出力後、前記システム１００は処理を前記ステップ６８０に戻す。以降、テストケース詳細レコードが無くなるまで（ステップ６８０：無し→ステップ５７０）、テストケースレコードが無くなるまで（ステップ５７０：無→ステップ５３０）、設計項目データレコードが無くなるまで（ステップ５３０：無→ＥＮＤ）、前記システム１００は処理を繰り返すこととなる。
【００９７】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００９８】
こうした本実施形態によれば、フォーマットが異なる各種設計書に対してテストケースを自動生成することが可能であり、テストケース生成作業の省略による作業量縮小を図ることができる。また、自動生成するテストケースに関して、ユーザによる追加、変更、削除も可能であり、不要なテストケースの消化による作業量増大や、必要なテストケースが出力されないことによるテスト漏れによる品質の低下といった事態の発生を防ぐことができる。
【００９９】
したがって、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。
【０１００】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、前記テストケース自動生成システムにおいて、前記演算部は、記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせるとしてもよい。
【符号の説明】
【０１０１】
５ 画面遷移定義情報
６ データ仕様情報
１０ 設計書
２０ テストケース
１００ テストケース自動生成システム
１０１ 記憶部
１０２ プログラム
１０３ メモリ
１０４ 演算部
１０５ 入力部
１０６ 出力部
１２５ 設計情報データベース
１２６ テスト情報データベース
１２７ 雛形ファイル
１２８ 環境設定ファイル
６０１ 設計書テーブル
６０２ 設計項目テーブル
６０３ 設計書詳細テーブル
６０４ 設計項目データテーブル
６０５ テストケーステーブル
６０６ テストケース詳細テーブル
６０７ 出力条件テーブル
【技術分野】
【０００１】
本発明は、テストケース自動生成システム、テストケース自動生成方法、およびテストケース自動生成プログラムに関するものであり、具体的には、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る技術に関する。
【背景技術】
【０００２】
システム開発の高品質化、短納期化が求められる中で、高品質なシステムを短期間で開発するため、ソースの自動生成やテスト作業の自動化が検討されている。テスト作業の自動化に関しては、さらにテストケース、テストデータの自動生成や、テストの自動実行、テスト結果の自動検証なども検討されている。特にテストケースの自動生成に関しては、テスト対象となるプログラムに関する設計書をもとにテストケースを自動生成するシステムが知られている。
【０００３】
そうした従来技術としては、例えば、テストケース及びテストデータを生成するためにコンピュータを、画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、前記対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、データ定義情報から、前記テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、前記テスト対象カラムに対する前記制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能させることを特徴とするテストケース生成プログラム（特許文献１参照）などが提案されている。
【０００４】
また、テストデータを構成する複数の項目情報と、該項目情報が漢字又は数字又は文字か否かの属性を示す属性情報と、前記項目情報のレコード長とを含むテストデータ仕様情報を複数格納する仕様書ファイル部と、テストデータの属性情報及びレコード長に対応した変数を含む複数の項目属性パラメータ情報を格納する項目属性パラメータファイル部と、前記仕様書ファイル部に格納したテストデータ仕様情報及び前記項目属性パラメータファイル部に格納した項目属性パラメータ情報を参照してコンピュータシステムのテストデータを内部テーブル部に生成する制御部とを備えるテストデータ作成システムであって、前記制御部が、前記仕様書ファイル部からテストデータ仕様情報を抽出する第１工程と、該第１工程により抽出したテストデータ仕様情報の属性情報及びレコード長に対応した複数の項目属性パラメータ情報を項目属性パラメータファイル部から抽出する第２工程と、前記第１工程により抽出したテストデータ仕様情報の複数の項目情報を該項目情報のレコード長に従って前記内部テーブル部に設定する第３工程と、該第３工程により設定した内部テーブル部の複数の項目情報に、前記該第２工程により抽出した項目属性パラメータ情報の変数に従ったデータを割り当てることによりテストデータを生成する第４工程とを実行するテストデータ作成システム（特許文献２参照）なども提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２６０３９０号公報
【特許文献２】特開２００９−２８９０８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術を利用することでテストケースの自動生成は可能である。しかしながら、テストケースの自動生成に利用する設計書については、そのフォーマット等が固定化されているのが前提であって、例えばフォーマットや記載項目が固定基準と異なる設計書について適用することが出来ないという課題が残されている。
【０００７】
また、従来技術によって出力されるテストケースの形式が固定であることから、設計書によっては不要な項目についてもテストケースが出力され、更にはその不要なテストケースの実行によって、システム検証の作業量自体が増大するという問題も生じる。一方で、必要なテストケースが出力されないことも起こりうるため、テスト漏れによるシステムの品質低下の事態が生じる恐れもある。
【０００８】
そこで本発明の目的は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図る技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決する本発明のテストケース自動生成システムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、を備える。
【００１０】
また、本発明のテストケース自動生成方法は、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行することを特徴とする。
【００１１】
また、本発明のテストケース自動生成プログラムは、システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、を実行させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のテストケース自動生成システムの構成例を示す図である。
【図２】本実施形態における設計書のフォーマット例を示す図である。
【図３】本実施形態における設計項目間の関係例を示す図である。
【図４】本実施形態における設計書の例を示す図である。
【図５】本実施形態における設計項目データの関係例を示す図である。
【図６】設計情報データベースとテスト情報データベースのテーブル構成例を示す図である。
【図７】本実施形態における設計書テーブルの例を示す図である。
【図８】本実施形態における設計項目テーブルの例を示す図である。
【図９】本実施形態における設計書詳細テーブルの例を示す図である。
【図１０】本実施形態におけるテストケース自動生成方法の処理手順例１を示すフロー図である。
【図１１】本実施形態における設計項目データテーブルの例を示す図である。
【図１２】本実施形態における雛形ファイルの例を示す図である。
【図１３】本実施形態における環境設定ファイルの例を示す図である。
【図１４】本実施形態におけるテストケースの例を示す図である。
【図１５】本実施形態におけるテストケーステーブルの例を示す図である。
【図１６】本実施形態におけるテストケース詳細テーブルの例を示す図である。
【図１７】本実施形態における出力条件テーブルの例を示す図である。
【図１８】本実施形態におけるテストケース自動生成方法の処理手順例２を示すフロー図である。
【図１９】本実施形態におけるテストケース自動生成方法の処理手順例３を示すフロー図である。
【発明を実施するための形態】
【００１４】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のテストケース自動生成システム１００の構成例を示す図である。図１に示すテストケース自動生成システム１００は、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図るコンピュータシステムである。
【００１５】
テストケース自動生成システム１００のハードウェア構成は例えば以下の如くとなる。前記テストケース自動生成システム１００は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶部１０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ１０３、前記記憶部１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算部１０４、ユーザからのキー入力等を受け付けるキーボードやマウス等の入力部１０５、処理データの表示を行うディスプレイ等の表示部１０６を備える。なお、記憶部１０１内には、本実施形態のテストケース自動生成システムとして必要な機能を実装する為のプログラム１０２と、各種テーブル、データ類が記憶されている。
【００１６】
記憶部１０１に格納されているテーブルやデータの類としては、各種設計書間に共通する項目について予め定義したテーブル１２５（設計書テーブル６０１、設計項目テーブル６０２、設計書詳細テーブル６０３、設計項目データテーブル６０４を含む）と、予めユーザから指定を受けているテスト情報データベース１２６（テストケーステーブル６０５、テストケース詳細テーブル６０６、出力条件テーブル６０７を含む）がある。また、その他にも、雛形ファイル１２７、環境設定ファイル１２８なども記憶部１０１に格納されている。これらデータベースやファイルに関しては後述する。
【００１７】
こうしたテストケース自動生成システム１００では、前記各テーブル６０１〜６０４らが示す項目に応じて、画面遷移定義情報５やデータ仕様情報６などで構成される設計書１０を設計情報データベース１２５に登録する。またテストケース自動生成システム１００は、設計情報データベース１２５、テスト情報データベース１２６、および環境設定ファイル１２８を元に、雛形ファイル１２７を利用してテストケース２０を自動生成することとなる。
【００１８】
続いて、本実施形態のテストケース自動生成システム１００が備える機能について説明する。上述したように、以下に説明する機能は、例えばテストケース自動生成システム１００の演算部１０４がプログラム１０２をそれぞれ実行することで実装される機能と言える。
【００１９】
前記テストケース自動生成システム１００は、テストケース別の、前記項目が記述に含まれたテスト内容の定義（テストケーステーブル６０５、テストケース詳細テーブル６０６）および出力条件（出力条件テーブル６０７）について、入力部１０５を介しユーザから指定を受けて、テスト情報データベース１２６として記憶部１０１に格納する機能を有している。
【００２０】
また、前記テストケース自動生成システム１００は、処理対象となる設計書１０のデータを前記各テーブル６０１〜６０４に照合し、該テーブルで定義された各項目に該当する情報を前記設計書１０のデータから抽出し、該抽出データを前記テーブル６０１〜６０４の項目に合わせて、設計情報データベース１２５として記憶部１０１にて記憶する機能を有している。
【００２１】
設計書１０はプログラム等を開発する上で必要となる設計項目を記載するものであり、同様のシステムを開発する場合、そのフォーマットはプロジェクト毎に異なるが、設計項目についてはプロジェクト間でほぼ共通となりやすい。そこで本実施形態のテストケース自動生成システム１００は、設計書１０のデータを、前記テーブル６０１〜６０４らのデータ項目に合わせて抽出し設計情報データベース１２５へ導入する処理を行うことで、テストケース２０の生成に利用する設計書１０の間のフォーマットの違いを吸収することとなる。
【００２２】
また、前記テストケース自動生成システム１００は、記憶部１０１から前記設計情報データベース１２５のデータを読み出し、該読み出したデータと、前記テスト情報データベース１２６における各テストケースの出力条件（出力条件テーブル６０７が示す情報）とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する機能を有している。
【００２３】
また、前記テストケース自動生成システム１００は、前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベース１２５のデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する機能を有している。
【００２４】
なお、前記テストケース自動生成システム１００は、記憶部１０１から読み出した前記設計情報データベース１２５のデータと、前記テスト情報データベース１２６における各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベース１２５のデータに対しパターンマッチングさせるとすれば好適である。
【００２５】
こうした本実施形態のテストケース自動生成システム１００によれば、テスト情報データベース１２６におけるテーブル６０５〜６０７についてユーザがメンテナンス可能であり、テストケースに含ませるチェック条件や確認内容等、出力するテストケースの追加、変更、削除が可能となる。また、テストケースの出力条件の指定では正規表現を導入することで、パターンマッチングによるテストケースの出力制御を確実化かつ効率化できる。
【００２６】
続いて、本実施形態で処理対象となる設計書１０にデータ構成例等について説明しておく。図２は、本実施形態のテストケース自動生成システム１００における処理対象となる設計書１０のフォーマット例を示した図である。前記テストケース自動生成システム１００（以下、システム１００）が扱う設計書１０の一例としては、１つの表計算ファイルに存在する１つのシート上において、画面構成の定義等が記述されたデータを想定している（勿論、画面構成に関する設計書はあくまで一例である）。一般的に、表計算ファイルにおけるシートは、値の入力可能な矩形セルが縦横に行列配置されて構成されたものであり、各セルは行列中での配置を示す座標値（例えば、“Ａ列の３行目”であれば、「Ａ３」）でシート上の絶対位置が特定できる。１つの表計算ファイルに含まれるシート数に制限は無いことが普通であり、複数の各設計書１０を記述した複数のシートを、１つの表計算ファイルに含めておくことも可能である。
【００２７】
図２においては、画面一覧１１、画面項目定義書１２、画面ボタン定義書１３という３つの設計書フォーマットの例を示している。画面一覧１１は、システム開発で設計される全画面の情報を一覧化して表現した設計書フォーマットである。図２の例では、１つの表計算ファイル中の１つのシート（“画面一覧”のタグがシート左下に存在する）に記述したものとなっている。
【００２８】
一方、画面項目定義書１２と画面ボタン定義書１３は、前記画面一覧１１にて定義された各画面上に存在するすべての画面項目とボタン項目の情報をそれぞれ一覧化して表現した設計書フォーマットである。図２の例では、１つの表計算ファイル中のそれぞれシート（計２シート）に記述したものとなっている。よって、シート左下に“画面項目定義書”、“画面ボタン定義書”の各タグが存在している。
【００２９】
ここで、各シートの名、すなわちシート名は、処理対象の設計書１０が、後述する設計書テーブル６０１のどのレコードに該当するものか識別するため、設計書テーブル６０１で定義された「設計書名称」と同一名称である必要がある。したがって、図２の例に示す設計書フォーマットを考えた場合、設計書テーブル６０１には「設計書名称」として「画面一覧」、「画面項目定義書」、「画面ボタン定義書」という３つのレコードが存在することになる。
【００３０】
また、設計書１０に記載される設計項目は、１つの設計書において複数存在することを想定している。図２の例の場合、画面一覧１１においては、「画面ＩＤ」と「画面名」の２つの設計項目がある。また、画面項目定義書１２においては「画面ＩＤ」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」の６つの設計項目がある。また、画面ボタン定義書１３においては、「画面ＩＤ」、「画面ボタンＩＤ」、「画面ボタン名」の３つの設計項目がある。
【００３１】
なお、同一の設計項目が複数の設計書、すなわち図２の例の場合の画面一覧１１、画面項目定義書１２、画面ボタン定義書１３らに存在することも想定できる。複数の設計書に存在する設計項目は、設計書間の紐付けを行う設計項目であり、同一の設計項目のデータ値が互いに同じである設計書同士は関連する設計書となる。図２の例では、「画面ＩＤ」が複数の設計書に記述されており、この「画面ＩＤ」が一致する設計書同士が関連する設計書となる。
【００３２】
こうした設計書らのフォーマットに基づく設計項目間の関係例を図３にて示す。前記システム１００が扱う各設計項目の間は、１：Ｎの親子関係があることを想定している。親となる設計項目は子となる設計項目を一意に決定する設計項目である。親となる設計項目は複数の子となる設計項目を持つことができるが、子となる設計項目は親となる設計項目を１つしか持てない。したがって、親の設計項目に相当する値が決まると、子となる設計項目に相当する値が自動的に決まる。
【００３３】
図３に示す例では、図２に示した設計書フォーマット１１〜１３らの設計項目の間の親子関係が表現されている。この図において、「画面ＩＤ」は画面を一意に識別する設計項目であり、この画面ＩＤが決まると、「画面名」が自動的に決まるので、「画面ＩＤ」と「画面名」との間には「画面ＩＤ」が親かつ「画面名」が子という関係ができる。
【００３４】
また、「画面ＩＤ」に対して「画面名」は１つなので、「画面ＩＤ」と「画面名」は１：１の親子関係となる。「画面項目ＩＤ」は画面上の項目を一意に識別するためのＩＤである。画面上の項目は画面が決まると自動的に決まるので、「画面ＩＤ」と「画面項目ＩＤ」の間には「画面ＩＤ」が親かつ「画面項目ＩＤ」が子という関係ができる。また画面には複数の画面項目が存在するため、「画面ＩＤ」と「画面項目ＩＤ」の間は１：Ｎの親子関係となりうる。
【００３５】
また、「画面項目名」、「コントロール」、「桁」は「画面項目ＩＤ」が決まると自動的に決まる項目であり、「画面項目ＩＤ」と「画面項目名」、「コントロール」、「桁」には「画面項目ＩＤ」が親かつ「画面項目名」、「コントロール」、「桁」が子という関係ができる。また、「画面項目ＩＤ」に対して「画面項目名」、「コントロール」、「桁」はそれぞれ１つなので、「画面項目ＩＤ」と「画面項目名」、「コントロール」、「桁」の各間は１：１の親子関係となる。
【００３６】
また、「画面ボタンＩＤ」は「画面項目ＩＤ」と同様の理由から、「画面ＩＤ」が親かつ「画面ボタンＩＤ」が子という１：Ｎの親子関係となる。さらに、「画面ボタン名」は「画面項目名」、「コントロール」、「桁」と同様の理由から、「画面ボタンＩＤ」が親かつ「画面ボタン名」が子という１：１の親子関係となる。
【００３７】
このようなフォーマットに基づいてユーザが作成した設計書１０としては、画面一覧１４、画面項目定義書１５、および画面ボタン定義書１６の各例を図４に示す。図４に示す例では、開発対象となる画面数は２つあり、画面一覧１４には２つの画面の情報が一覧形式で記述されている。また、画面項目定義書１５と画面ボタン定義書１６は、１画面についてそれぞれ作成した例であり、画面項目定義書１５では画面上に存在する２つの画面項目の情報が一覧形式で記述されており、画面ボタン定義書１６では画面上に存在する１つのボタンの情報が一覧形式で記述されている。
【００３８】
こうした設計書について図３同様に設計項目間の関係を示したのが図５となる。図４でえ例示した設計例では、画面には２つの画面項目と１つのボタン項目が存在している。そこで、画面ＩＤ：ＳＣＲＥＥＮ０１には、１つの画面名：ユーザ登録画面と、２つの画面項目ＩＤ：ｕｓｅｒＩｄ、ｕｓｅｒＮａｍｅと、１つのボタン項目ＩＤ：ｉｎｓｅｒｔが子の設計項目データとして存在する。さらに画面項目ＩＤ：ｕｓｅｒＩｄには画面項目名：ユーザＩＤと、コントロール：テキストと、桁：１０と、必須：○、という子となる４つの設計項目データが存在し、画面項目ＩＤ：ｕｓｅｒＮａｍｅには、画面項目名：ユーザ名と、コントロール：テキストと、桁：５と、必須：−、という子となる４つの設計項目データが存在する。また、画面ボタンＩＤ：ｉｎｓｅｒｔには、画面ボタン名：登録という子となる１つの設計項目データが存在する。
【００３９】
続いて、前記システム１００が利用する設計情報データベース１２５とテスト情報データベース１２６のテーブル構成例について図６〜９に基づき説明する。
【００４０】
設計情報データベース１２５は、設計書テーブル６０１、設計項目テーブル６０２、設計書詳細テーブル６０３、および設計項目データテーブル６０４の４つのテーブルから構成される。
【００４１】
設計書テーブル６０１は、前記システム１００の入力となる設計書１０に関する情報を保持するためのテーブルである。この設計書テーブル６０１は、図７にも示すように、設計書ＩＤ７０１と設計書名称７０２の２つの項目からなる。設計書ＩＤ７０１は設計書テーブル６０１の主キーとなる項目であり、入力となる設計書を一意に識別するためのＩＤである。設計書名称７０２は入力となる設計書の日本語名称を表すものである。設計書名称７０２は、図２で説明したとおり、ユーザが指定した設計書がどの設計書なのかを識別するために、入力となる設計書のシート名と同一である必要がある。
【００４２】
上記図２の例では、設計書には画面一覧１４、画面項目定義書１５、および画面ボタン定義書１６の３つの設計書があるため、図７に示す設計書テーブル６０１の例では、各設計書３件の情報が登録されている。設計書ＩＤ７０１には一意となるＩＤを設定する必要があり、画面一覧１４、画面項目定義書１５、画面ボタン定義書１６に対する各設計書ＩＤには、それぞれ重複しない値として、例えば、「ＳｃｒｅｅｎＬｉｓｔ」、「ＳｃｒｅｅｎＩｔｅｍ」、「ＳｃｒｅｅｎＢｕｔｔｏｎ」を設定している。設計書名称７０２には、図２で説明したとおり表計算ファイルのシート名と一致する必要があるため、設計書名称７０２にはそれぞれ、「画面一覧」、「画面項目定義書」、「画面ボタン定義書」を設定している。
【００４３】
また、設計項目テーブル６０２はシステム開発する上で必要となる、設計書に記載された設計項目の情報を保持するためのテーブルである。この設計項目テーブル６０２は、図８にて示すように、設計項目ＩＤ８０１、設計項目名称８０２、親設計項目ＩＤ８０３の３つの項目からなる。設計項目ＩＤ８０１は設計項目テーブル６０２の主キーとなる項目であり、設計項目を一意に識別するためのＩＤである。設計項目名称８０３は入力となる設計書に記載された設計項目の日本語名称を表すものである。親設計項目ＩＤ８０２は、図３で説明したとおり、設計項目間に１：Ｎの親子関係があることを踏まえ、子となる設計項目に対して親となる設計項目の設計項目ＩＤを設定するための項目である。
【００４４】
図８に示す設計項目テーブル６０２の例においては、設計項目として、「画面一覧」について「画面ＩＤ」と「画面名」の２つの設計項目が、「画面項目定義書」について「画面ＩＤ」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」の６つの設計項目が、「画面ボタン定義書」について「画面ＩＤ」、「画面ボタンＩＤ」、「画面ボタン名」の３つの設計項目が存在する。また「画面ＩＤ」は「画面一覧」、「画面項目定義書」、「画面ボタン定義書」のすべての設計書に存在しており、設計項目としては重複を除き「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「」画面ボタンＩＤ」、「画面ボタン名」の９つの設計項目が存在する。したがって、設計項目テーブル６０２には、９件の情報が登録されている。設計項目ＩＤ８０１には一意となるＩＤを設定する必要があり、「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「画面ボタンＩＤ」、「画面ボタン名」に対する設計項目ＩＤにはそれぞれ重複しない値として、「ＳｃｒｅｅｎＩｄ」、「ＳｃｒｅｅｎＮａｍｅ」、「ＳｃｒｅｅｎＩｔｅｍＩｄ」、「ＳｃｒｅｅｎＩｔｅｍＮａｍｅ」、「ＳｃｒｅｅｎＩｔｅｍＣｔｌ」、「ＳｃｒｅｅｎＩｔｅｍＳｉｚｅ」、「ＳｃｒｅｅｎＩｔｅｍＮｅｃｅｓｓａｒｙ」、「ＳｃｒｅｅｎＢｕｔｔｏｎＩｄ」、「ＳｃｒｅｅｎＢｕｔｔｏｎＮａｍｅ」を設定している。
【００４５】
また、設計項目名称８０３は、設計項目の日本語名称であるため、「画面ＩＤ」、「画面名」、「画面項目ＩＤ」、「画面項目名」、「コントロール」、「桁」、「必須」、「画面ボタンＩＤ」、「画面ボタン名」といった名称を設定している。さらに親項目の設計項目ＩＤ８０２には、設計項目間に図３に示す親子関係があるため、「画面ＩＤ」に関しては未設定を示す「−」が設定され、「画面名」、「画面項目ＩＤ」、「画面ボタンＩＤ」に関しては「ＳｃｒｅｅｎＩｄ」が設定され、「画面項目名」、「コントロール」、「桁」、「必須」に関しては「ＳｃｒｅｅｎＩｔｅｍＩｄ」が設定され、「画面ボタン名」に関しては「ＳｃｒｅｅｎＢｕｔｔｏｎＩｄ」が設定されている。
【００４６】
また、設計書詳細テーブル６０３は、設計書１０と設計項目とを紐付けるためのテーブルであり、設計書１０のどの位置にどの設計項目が存在するかという情報を保持するためのテーブルである。設計書詳細テーブル６０３は、図９に例示するように、設計書ＩＤ９０１、設計項目ＩＤ９０２、絶対位置９０３、繰返し有無９０４、データ読込方向９０５、登録有無９０６の６つの項目からなる。
【００４７】
設計書ＩＤ９０１と設計項目ＩＤ９０２は設計書詳細テーブル６０３の主キーとなる項目であり、どの設計書にどの設計項目が記載されるかを示すものである。設計書ＩＤ９０１は設計書テーブル６０１に存在する設計書ＩＤ７０１である必要があり、設計項目ＩＤ９０２は設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。絶対位置９０３は設計書のどの位置に設計項目が存在するかを示す情報である。図２をもとに例を示すと、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは「Ａ２」の位置から開始されるため、絶対位置９０３には「Ａ２」が設定される。また、繰り返し有無９０４は、設計項目のデータが設計書間で１つなのか複数なのかを示す情報であり、１つの場合には「無」が、複数の場合には「有」が設定される。図２の例をもとに説明すると、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは複数記述されるため、繰返し有無９０４には「有」が設定される。一方、設計書：画面項目定義書にある設計項目：画面ＩＤに対するデータは１つしか記述されないため、繰返し有無９０４には「無」が設定される。また、データ読込方向９０５は設計項目のデータが複数の場合に利用され、データの繰返し方向を示すものであり、該当設計項目が上方向に繰り返される場合には「↑」が、下方向に繰り返される場合には「↓」が、左方向に繰り返される場合には「←」が、右方向に繰り返される場合には「→」が設定される。また設計項目のデータが１つの場合には「−」が設定される。図２をもとに例を示すと、設計書：画面一覧にある設計項目：画面ＩＤに対するデータは下方向に複数記述されるため、データ読込方向９０５には「↓」が設定される。一方、設計書：画面項目定義書にある設計項目：画面ＩＤに対するデータは１つしか記述されないため、データ読込方向９０５には「−」が設定される。また、登録有無９０６は複数の設計書に記載される設計項目に関して、どの設計書から設計項目データを登録するかを示す情報である。複数の設計書から同一の設計項目データを登録しても無駄な情報が増えてしまうだけなので、設計項目データは１つの設計書からしか登録できないようにしている。したがって、ある設計項目について、ある設計書で登録有無９０６が「有」になっている場合、その設計項目について他の設計書に関して「無」とする必要がある。図２をもとに例を示すと、設計項目：画面ＩＤは３つの設計書に記載されるため、このうちの１つの設計書でしか登録有無９０６を「有」に設定できない。したがって、設計書：画面一覧にて登録有無９０６を「有」に設定した場合、設計書：画面項目定義書と設計書：画面ボタン定義書では登録有無９０６を「無」にしか設定できない。
【００４８】
図９に例示した設計詳細テーブルでは、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＩｄ」と、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＮａｍｅ」という２つのレコードが登録されている。図２の例であれば、「画面ＩＤ」は「Ａ２」の位置から下方向に複数記述されるため、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＩｄ」のレコードの絶対位置９０３に「Ａ２」が、繰返し有無９０４には「有」が、データ読込方向９０５には「↓」が設定される。また、「画面ＩＤ」は複数の設計書に記述されており、この例では「画面一覧」から登録するため、登録有無９０６を「有」にしている。したがって、「画面ＩＤ」が記述されている画面項目定義書１５と画面ボタン定義書１６では登録有無９０６を「無」にしている。同様に「画面名」は「Ｂ２」の位置から下方向に複数記述されているため、設計書ＩＤ９０１が「ＳｃｒｅｅｎＬｉｓｔ」かつ設計項目ＩＤ９０２が「ＳｃｒｅｅｎＮａｍｅ」のレコードの絶対位置９０３に「Ｂ２」が、繰返し有無９０４には「有」が、データ読込方向９０５には「↓」が設定される。また「画面名」は「画面一覧」にのみ記述されているため、登録有無９０６は「有」に設定されている。他の設計書についても同様に設定することができる。こうした、設計書のデータをテーブル１１〜１３の項目に基づいて抽出・設定し、設計情報データベース１２５を作成する処理は、前記システム１００が実行する。表計算ファイルのシートは上述のように絶対位置が判明しているセルによって構成されているから、前記システム１００は、設計書１０からのデータ抽出等に際しては、シート中の規定セル（例：“Ａ１”など最上行の最左列のセル）から順次セルの値を読み込んで、該当設計項目のＩＤや名称が設定されたセルを特定し、それと連結ないし隣接したセルの値すなわち設計項目の値を読み取るといった処理を実行していけばよい。他のテーブル類に基づく設計書１０からのデータ抽出についても同様である。
【００４９】
また、設計項目データテーブル６０４は、設計書１０から読込んだ設計項目のデータを保持するためのテーブルである。設計項目データテーブル６０４はデータ番号１１０１、設計項目ＩＤ１１０２、値１１０３、親項目のデータ番号１１０４という４つの項目からなる。データ番号１１０１は設計項目のデータを一意に識別するための情報であり、設計項目のデータを設計項目データテーブル６０４に格納する際にシステム１００が自動採番して作成する。設計項目ＩＤ１１０２は設計項目のデータがどの設計項目に関するものかを示すものであり、設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。値１１０３は設計書１０から読込んだ設計項目のデータを格納する。親項目のデータ番号１１０４は、図５で説明したとおり、設計項目間における１：Ｎの親子関係に基づいて、子となる設計項目データに対して親となる設計項目データのデータ番号を設定する項目である。親項目のデータ番号１１０４は設計項目データテーブル６０４に存在するデータ番号１１０１である必要がある。
【００５０】
一方、テスト情報データベース１２６は、テストケーステーブル６０５、テストケース詳細テーブル６０６、出力条件テーブル６０７の３つのテーブルから構成される。テストケーステーブル６０５は生成するテストケース１件の情報を保持するテーブルである。テストケーステーブル６０５は、図１５に示すようにテストケースＩＤ１５０１、テストケース名１５０２、出力条件ＩＤ１５０３の３つの項目からなる。テストケースＩＤ１５０１はテストケーステーブル６０５の主キーとなる項目であり、テストケースを一意に識別するためのＩＤである。テストケース名１５０２はテストケースの日本語名称を表すものである。出力条件ＩＤ１５０３はテストケースを出力するための条件を表すものであり、ここに値を設定することで、テストケースの出力制御が可能となる。出力条件ＩＤ１５０３は出力条件テーブル６０７に存在する出力条件ＩＤ１７０１である必要がある。
【００５１】
また、テストケース詳細テーブル６０６は、テストケースを実行する手順を操作単位で格納するテーブルである。図１６に示すように、テストケース詳細テーブル６０６はテストケースＩＤ１６０１、操作番号１６０２、出力区分１６０３、操作内容１６０４の４つの項目からなる。テストケースＩＤ１６０１と操作番号１６０２はテストケース詳細テーブル６０６の主キーとなる項目であり、テストケースを実現するための手順を構成する１つの操作を示すものである。テストケースＩＤ１６０１はテストケーステーブル６０５に存在するテストケースＩＤ１５０１である必要がある。出力区分１６０３は操作の区分を示すものであり、テストケースのチェック条件となる操作に対しては「条件」を、テストケースの確認内容となる操作に対しては「確認」を設定する。操作内容１６０４はテストする際の具体的な操作を示すものである。チェック条件となる操作としては「画面項目に値を入力する」、「ボタンを押す」などの操作があり、確認内容となる操作としては「ボタン押下後の画面状態を確認する」などの操作がある。また、操作内容１６０４には、設計情報データベース１２５の設計項目テーブル６０２における設計項目ＩＤ８０１が埋め込み可能であり、設計項目ＩＤ８０１を「｛設計項目ＩＤ｝」という形式で設定することで対応する設計項目のデータを出力可能にしている。ここで設定する設計項目ＩＤは、設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。さらに、出力するファイルで利用可能な関数を記述可能にすることで、設計項目を利用した関数による演算結果も出力することが可能である。
【００５２】
また、出力条件テーブル６０７はテストケースの出力を制御するための条件情報を格納するテーブルである。出力条件テーブル６０７は出力条件ＩＤ１７０１、設計項目ＩＤ１７０２、出力条件内容１７０３の３つの項目からなる。出力条件ＩＤ１７０１は出力条件テーブル６０７の主キーとなる項目であり、出力条件を一意に識別するＩＤである。設計項目ＩＤ１７０２と出力条件内容１７０３はテストケースを出力するための条件を表すものであり、設計項目ＩＤ１７０２に対する設計項目データが出力条件内容に指定されたパターンを満たす場合にテストケースを出力する。設計項目ＩＤ１７０２は設計項目テーブル６０２に存在する設計項目ＩＤ８０１である必要がある。
【００５３】
続いて、本実施形態における設計書１０のデータを設計情報データベース１２５に登録する際の処理を図１０に基づき説明する。なお、上述したように、前記システム１００が、設計書１０のデータから、設計書テーブル６０１、設計項目テーブル６０２、および設計書詳細テーブル６０３の各設計項目について値を抽出し、該当テーブルに対応した形式で記憶部１０１にデータを保持しているものとする。
【００５４】
この場合、前記システム１００は、例えば、入力部１０５にてユーザより入力されたフォルダ名の情報を取得する（ステップ１１０）。システム１００は、例えば記憶部１０１に格納されていた該当フォルダにアクセスし、設計書１０を格納した表計算ファイルを全て取得する（ステップ１２０）。
【００５５】
次に前記システム１００は、前記ステップ１２０で取得した表計算ファイルを１つずつ読込んでいく。読込む表計算ファイルがある場合（ステップ１３０：有）、前記システム１００はステップ１４０に処理を進める。一方、読込む表計算ファイルが無い場合（ステップ１３０：無）、前記システム１００は処理を終了する。こうしたステップ１３０の処理は、前記ステップ１２０で得た全ての表計算ファイルについて、読込む表計算ファイルが無くなるまで繰り返し実行される。
【００５６】
続いて前記システム１００は、前記ステップ１２０で取得した表計算ファイルから、各設計書１０のデータが記述されたシートを取得する（ステップ１４０）。前記システム１００は、取得した表計算ファイルの全シートを１シートずつ読込んでいく（ステップ１５０）。読込むシートがある場合（ステップ１５０：有）、前記システム１００は処理をステップ１６０に進める。他方、読込むシートが無い場合（ステップ１５０：無）、前記システム１００は、処理をステップ１３０に戻す。こうした処理は、前記ステップ１４０で取得した全シートについて、読込むシートが無くなるまで繰り返し実行する。
【００５７】
続いて前記システム１００は、読込んだシートからシート名を取得する（ステップ１６０）。また前記システム１００は、設計情報データベース１２５の設計書テーブル６０１にアクセスし、設計書テーブル６０１の設計書名称７０２が前記取得したシート名と一致するレコードの設計書ＩＤ７０１を取得する（ステップ１７０）。
【００５８】
次に前記システム１００は、前記ステップ１７０で設計書ＩＤ７０１を取得できた場合（ステップ１８０：有）、処理をステップ１９０に進める。一方、前記ステップ１７０にて設計書ＩＤ７０１を取得できなかった場合（ステップ１８０：無）、前記システム１００は処理をステップ１５０に戻す。
【００５９】
続いて前記システム１００は、設計情報データベース１２５の設計書詳細テーブル６０３にアクセスし、設計詳細テーブルの設計書ＩＤ９０１が前記ステップ１７０で取得した設計書ＩＤ７０１と一致するレコード（設計書詳細レコード）を取得する（ステップ１９０）。前記システム１００は、取得した設計書詳細レコードを１つずつ読込んでいく。読込む設計書詳細レコードがある場合（ステップ２００：有）、前記システム１００は、処理をステップ２１０に進める。他方、読込む設計書詳細レコードが無い場合（ステップ２００：無）、前記システム１００は、処理をステップ１５０に戻す。こうした処理は、前記ステップ１９０で取得した全設計書詳細レコードについて、読込む設計書詳細レコードが無くなるまで繰り返し実行される。
【００６０】
続いて前記システム１００は、前記読み込んだ設計書詳細レコードから設計項目ＩＤ９０２、絶対位置９０３、繰返し有無９０４、データ読込方向９０５、登録有無９０６の各値を取得する（ステップ２１０）。そして前記システム１００は、ここで取得した登録有無９０６が「有」の場合（ステップ２２０：有）、処理をステップ２３０に進める。他方、登録有無９０６が「無」の場合（ステップ２２０：無）、前記システム１００は処理をステップ２００に戻す。
【００６１】
次に前記システム１００は、設計情報データベース１２５の設計項目テーブル６０２にアクセスし、設計項目テーブル６０２の設計項目ＩＤ８０１が前記ステップ２１０で取得した設計項目ＩＤ９０２と一致するレコードにおける、親項目の設計項目ＩＤ８０２を取得する（ステップ２３０）。
【００６２】
前記システム１００は、親項目の設計項目ＩＤ８０２を取得できた場合（ステップ２４０：有）、処理をステップ２５０に進める。他方、親項目の設計項目ＩＤ８０２を取得できなかった場合（ステップ２４０：無）、前記システム１００は処理をステップ２６０に進める。
【００６３】
続いて前記システム１００は、記憶部１０１にて保持する所定のデータ番号（後述するステップ２８０で採番したもの）中から、前記ステップ２３０で得た親項目の設計項目ＩＤ８０２に対応するデータ番号を、親項目のデータ番号として取得する（ステップ２５０）。勿論、前記ステップ１７０〜ステップ２４０の処理は、設計項目テーブル６０２における各設計項目間の親子関係に沿って最上位の親から順次行っていくから、当初は未だデータ番号が採番されていない状況であり、親項目のデータ番号は取得できない。よって、前記親子関係において親をもつ設計項目に関する処理が行われるまで、当該ステップはスルーする。
【００６４】
次に前記システム１００は、前記ステップ１４０より処理中となっている該当シートにおいて、絶対位置９０３にあるセルからデータを取得する（ステップ２６０）。前記ステップ２１０で得た繰返し有無９０４が「有」の場合、前記システム１００はデータ読込方向９０５を元に全データを取得する。
【００６５】
続いて前記システム１００は、前記ステップ２６０で取得した全データから１データずつ読込んでいく。読込むデータがある場合（ステップ２７０：有）、前記システム１００はステップ２８０に処理を進める。他方、読込むデータが無い場合（ステップ２７０：無）、前記システム１００は処理をステップ２００に戻す。こうした処理は、前記ステップ２６０で得た全データについて、読込むデータが無くなるまで繰り返し実行される。
【００６６】
次に前記システム１００は、前記ステップ２６０で得た各設計項目のデータを設計項目データテーブル６０４に登録すべく、該当データ（設計項目データ）用のデータ番号を自動採番する（ステップ２８０）。データ番号の自動採番については、登録順に１つずつ番号をインクリメントするといった一般的手法を採用すればよい。
【００６７】
続いて前記システム１００は、設計項目データテーブル６０４におけるデータ番号１１０１の欄に、前記ステップ２８０で自動採番したデータ番号を、また同様に、設計項目ＩＤ１１０２の欄に前記ステップ２１０で取得した設計項目ＩＤ９０２を、また同様に、値１１０３の欄に前記ステップ２６０で取得したデータを、また同様に、親項目のデータ番号すなわち親データ番号１１０４の欄に前記ステップ２５０で取得したデータ番号を設定し、データ登録を行う（ステップ２９０）。前記システム１００は、前記ステップ２８０で自動採番したデータ番号を記憶部１０１に保持し、ステップ２００に戻る（ステップ３００）。以降、前記システム１００は、設計書詳細レコードがある限り（ステップ２００：無→ステップ１５０）、またシートがある限り（ステップ１５０：無→ステップ１３０）、更に、表計算ファイルが無くなるまで（ステップ１３０：無→ＥＮＤ）、上記処理を繰り返し実行することとなる。
【００６８】
図１１は、図４の設計書１０を上述のフローを経て登録した設計項目データテーブル６０４の例を示す図である。ここでは一例として、設計書１０のうち画面一覧１４について説明する。システム１００は画面一覧１４のデータから「画面ＩＤ」と「画面名」を抽出し登録することになる。まず、「画面ＩＤ」は「ＳＣＲＥＥＮ０１」と「ＳＣＲＥＥＮ０２」の２つがあるため、システム１００は、データ番号１１０１には自動採番された「１」と「２」を、設計項目ＩＤ１１０２には「画面ＩＤ」の設計項目ＩＤ：ＳｃｒｅｅｎＩｄを、「値」には「ＳＣＲＥＥＮ０１」と「ＳＣＲＥＥＮ０２」をそれぞれ設定する。なお親データ番号１１０４は、「画面ＩＤ」に対する親項目の設計項目が無いため未設定となる。また、「画面名」は「ユーザ登録画面」と「結果画面」の２つがあるから、前記システム１００は、データ番号１１０１には自動採番した「３」と「４」を、設計項目ＩＤ１１０２には画面名の設計項目ＩＤ：ＳｃｒｅｅｎＮａｍｅを、値１１０３には「ユーザ登録画面」と「結果画面」をそれぞれ設定する。また「画面名」に対する親項目の設計項目が「画面ＩＤ」であるため、前記システム１００は、「ユーザ登録画面」の親データ番号１１０４として「１」を、また「結果画面」の親データ番号１１０４として「２」をそれぞれ設定する。その他の項目も同様に設定されるものである。
【００６９】
続いて、テストケース自動生成の処理について説明する。まずは、テストケース自動生成に際し前記システム１００が用いるファイル等について例示する。図１２は、前記システム１００が利用する雛形ファイル１２７の例を示す図である。前記システム１００がテストケース自動生成時に利用する雛形ファイル１２７は、設計書１０と同様に表計算ファイルが想定できる。前記システム１００は設計情報データベース１２５に保持する設計項目のデータと、テスト情報データベース１２６に予め保持するテストケースの定義とその出力条件をもとに、出力すべきテストケースを作成し、これを雛形ファイル１２７に適用し出力することでテストケース（のファイル）を自動生成する。１つの表計算ファイルは、図１３で説明する環境設定ファイル１２８で指定された設計項目ＩＤに対する設計項目データ単位に作成し、１つのテストケースは１つのシートに出力する。
【００７０】
図１３は、前記システム１００が利用する環境設定ファイル１２８の例を示す図である。前記システム１００がテストケース自動生成時に利用する環境設定ファイル１２８はテキストファイルが想定できる。環境設定ファイル１２８には、テストケースの出力単位となる設計項目ＩＤを指定する。前記システム１００ではこの環境設定ファイル１２８で指定された設計項目ＩＤに対する設計項目のデータと、その設計項目に紐づく子となるすべての設計項目のデータを元にテストケースを作成することになる。図１３の例では、設計項目ＩＤとして「画面ＩＤ」が指定されているため、この場合、前記システム１００は図５に示す画面ＩＤ：ＳＣＲＥＥＮ０１にぶら下がるすべての設計項目のデータを元にテストケースを作成する。
【００７１】
続いて、前記システム１００が自動生成したテストケース２０の例を示しておく。図１４に示す例ではテストケース２０が、「必須チェック（未入力）」と「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」の３つのテストケースから構成されている。
【００７２】
そのうち、「必須チェック（未入力）」は、必須指定された項目に対して未入力の場合に入力エラーが発生するかを確認するテストケースである。また、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」は、画面上の入力項目に対して桁数分しか入力できないことを確認するテストケースであり、入力項目への入力文字数のパターンとして桁数分と（桁数＋１）分の２つのパターンを用意している。
【００７３】
また、「必須チェック（未入力）」のテストケースは、設計項目のうち「必須」が「○」になっている項目に対してのみ実施するテストケースであり、図４の例においては、「ユーザＩＤ」のみ「必須」が「○」となっているため、「ユーザＩＤ」に対する１件のテストケース、すなわちこの図１４で示す「必須チェック（未入力）」のテストケースが出力された結果となっている。また、「入力可能桁数（桁数）」と「入力可能桁数（桁数＋１）」の各テストケースは、全画面項目に対して行うチェックであり、「ユーザＩＤ」と「ユーザ名」の両方に対してチェックしている。また、出力する表計算ファイルのシートはテストケース単位となっている。
【００７４】
続いて、前記システム１００がテストケース自動生成時に利用するテスト情報データベース１２６を構成するテーブルについて説明する。図１５は、テストケーステーブル６０５の例を示す図である。ここで例示するテストケーステーブル６０５は、テストケースとして「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」の３つのテストケースに関する計３件のレコードが登録されている。こうしたレコードは、テスト担当のユーザが事前に設定しており、必要に応じてユーザによる更新作業が可能となっている（システム１００が当該テーブルを出力部１０６に表示し、入力部１０５でユーザ指示を受ける）。以降、他のテーブルについても同様にシステム１００が情報の表示を行って、ユーザによる閲覧、更新、削除等の指示を受け付けてデータ更新等を実行可能とする。従って、図１５のテストケーステーブル６０５であれば、テストケースの追加や削除、テストケース名１５０２や出力条件ＩＤ１５０２の変更等も、システム１００が出力部１０６にて該当情報を表示してユーザ閲覧に供しつつ、入力部１０５にて変更等の指示を受けて、該当データの更新等を行うこととなる。
【００７５】
このテストケーステーブル６０５において、テストケースＩＤ１５０１は、テストケース毎に一意となる情報であるため、「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」のそれぞれに関し、互いに重複しない値として「ＴＣ００１」、「ＴＣ００２」、「ＴＣ００３」が設定されている。テストケース名１５０２はテストケースの日本語名称を表すものであるため、「必須チェック（未入力）」、「入力可能桁数（桁数）」、「入力可能桁数（桁数＋１）」が設定されている。また、出力条件ＩＤ１５０３はテストケースの出力制御を行うものであり、「必須チェック（未入力）」のテストケースは「必須」が「○」の場合にのみ出力するとの条件があるため、出力条件ＩＤ１５０３に例えば該当条件を示す「ＯＰ００１」が設定されている。他方、「入力可能桁数（桁数）」と「入力可能桁数（桁数＋１）」の各テストケースは、すべての画面項目に対して出力するテストケースであるため。出力条件ＩＤ１５０３は未設定となっている。
【００７６】
また、前記テスト情報データベース１２６を構成する、テストケース詳細テーブル６０６は、図１６に例示するように、各テストケース（上記例では３つのテストケース）に対してそれぞれ実行手順が記述されたテーブルとなる。ここでは、テストケース：必須チェック（未入力）に関して説明する。テストケース：必須チェック（未入力）は、５つのチェック条件に関する操作と３つの確認に関する操作の計８つの操作からなる。
【００７７】
操作内容１６０４には｛設計項目ＩＤ｝が埋め込まれており、システム１００が自動生成するテストケースにおいては、前記設計項目ＩＤの記述が、対応する設計項目のデータ（設計書１０から抽出したもの）で置換されて出力される。
【００７８】
また図１６において、操作番号１６０２が「１」の操作内容１６０４は「｛ＳｃｒｅｅｎＩｄ｝：｛ＳｃｒｅｅｎＮａｍｅ｝が表示されている。」となっており、設計項目ＩＤとして「ＳｃｒｅｅｎＩｄ」と「ＳｃｒｅｅｎＮａｍｅ」が埋め込まれているため、図４、図８の場合には、テストケースとしては｛ＳｃｒｅｅｎＩｄ｝が「ＳＣＲＥＥＮ０１」に、｛ＳｃｒｅｅｎＮａｍｅ｝が「ユーザ登録画面」に置換されて、「ＳＣＲＥＥＮ０１：ユーザ登録画面が表示されている。」が出力されることになる。また、操作番号１６０２が「２」の操作内容１６０４は「以下の項目を未入力にする」となっており、設計項目ＩＤは埋め込まれていないため、このまま出力される。また、操作番号１６０２が「３」の操作内容１６０４は「ＳｃｒｅｅｎＩｔｅｍＩｄ」：｛ＳｃｒｅｅｎＩｔｅｍＮａｍｅ｝」となっており、設計項目ＩＤとして「ＳｃｒｅｅｎＩｔｅｍＩｄ」、「ＳｃｒｅｅｎＩｔｅｍＮａｍｅ」が埋め込まれているため、図４、図８の場合には、画面項目が２つ存在しており、「ｕｓｅｒＩｄ：ユーザＩＤ」と「ｕｓｅｒＮａｍｅ：ユーザ名」の２行が出力される。その他の操作番号のレコードについても同様に出力されるものである。
【００７９】
図１７は、出力条件テーブル６０７の例を示す図である。上述までの例において、出力の制御をしたいテストケースとして「必須チェック(未入力)」がある。そこで図１７の出力条件テーブル６０７では、「必須チェック(未入力)」のテストケース用の出力条件として、１件のレコードが登録されている。このレコードが示す条件において、「必須チェック（未入力）」のテストケースは、画面項目に対する「必須」が「○」になっている場合にテストケースとして出力する。出力条件ＩＤ１７０１は出力条件を一意に識別するＩＤであり、ここでは「ＯＰ００１」が設定されている。また、前記「必須チェック（未入力）」のテストケースに関する出力条件が、画面項目に対する「必須」が「○」になっていることであることから、設計項目ＩＤ１７０２には、「必須」に対する設計項目ＩＤ：ＳｃｒｅｅｎＩｔｅｍＮｅｃｅｓｓａｒｙが、また、出力条件内容１７０３に「○」が設定されている。
【００８０】
続いて、前記システム１００が、設計情報データベース１２５とテスト情報データベース１２６に基づいてテストケース２０を自動生成する処理について、図１８，図１９に基づき説明する。まず、前記システム１００は、図１３に例示した環境設定ファイル１２８から画面ＩＤに相当する設計項目ＩＤを取得する（ステップ５１０）。
【００８１】
次に前記システム１００は、設計情報データベース１２５の設計項目データテーブル６０４にアクセスし、設計項目データテーブル６０４の設計項目ＩＤ１１０２が、前記ステップ５１０で取得した設計項目ＩＤと一致するレコード、すなわち設計項目データレコードを取得する（ステップ５２０）。
【００８２】
また、前記システム１００は、前記ステップ５２０で取得した設計項目データレコードを１つずつ読込んでいく。設計項目データレコードがある場合（ステップ５３０：有）、前記システム１００は処理をステップ５４０に進める。他方、設計項目データレコードが無い場合（ステップ５３０：無）、前記システム１００は処理を終了する。こうした処理は、前記ステップ５２０で得た設計項目データレコードが無くなるまで繰り返し実行される。
【００８３】
続いて前記システム１００は、前記ステップ５２０で取得したレコードからデータ番号１１０１を取得する（ステップ５４０）。また前記システム１００は、設計情報データベース１２５の設計項目データテーブル６０４にアクセスし、前記ステップ５４０で取得したデータ番号１１０１を頂点として連なる親子関係において、子となる設計項目のデータを、子が無くなるまですべて取得する（ステップ５５０）。つまり前記システム１００は図３と図５に相当する情報を作成する。
【００８４】
前記システム１００は、テスト情報データベース１２６のテストケーステーブル６０５にアクセスし、全てのテストケースのレコードを取得する（ステップ５６０）。また前記システム１００は、ここで取得したテストケースレコードを１つずつ読込んでいく。テストケースレコードがある場合（ステップ５７０：有）、前記システム１００は処理をステップ５８０に進める。他方、テストケースレコードが無い場合（ステップ５７０：無）、前記システム１００は処理を終了する。こうした処理は、前記ステップ５６０で得たテストケースレコードが無くなるまで繰り返し実行される。
【００８５】
続いて前記システム１００は、前記ステップ５７０で取得したレコードから出力条件ＩＤ１５０３を取得する（ステップ５８０）。また前記システム１００は、該ステップ５８０で出力条件ＩＤ１５０３を取得できた場合（ステップ５９０：有）、処理をステップ６００に進める。他方、出力条件ＩＤ１５０３が無かった場合（ステップ５９０：無）、前記システム１００は処理をステップ６５０に進める。
【００８６】
前記ステップ５９０に続き、前記システム１００は、テスト情報データベース１２６の出力条件テーブル６０７にアクセスし、出力条件テーブル６０７の出力条件ＩＤ１７０１が、前記ステップ５８０で取得した出力条件ＩＤ１５０３と一致する出力条件レコードを取得する（ステップ６００）。
【００８７】
そして前記システム１００は、前記ステップ６００で取得した出力条件レコードから設計項目ＩＤ１７０２と出力条件内容１７０３を取得する（ステップ６１０）。また前記システム１００は、ここで取得した設計項目ＩＤ１７０２に対応する設計項目の値１１０３を、前記ステップ５５０で取得、作成した情報から取得する（ステップ６２０）。
【００８８】
次に前記システム１００は、前記ステップ６１０で取得した出力条件内容１７０３について正規表現を用いて、前記ステップ６２０で取得した設計項目の値１１０３とのマッチングを行う（ステップ６３０）。正規表現は、文字列のパターンを表現する表記法であり、文字列の検索・置換を行うときに利用されるものとなる。正則表現と呼ばれることもある。この正規表現においては、通常の文字と、メタキャラクタと呼ばれる特別な意味を持った記号を組み合わせた表記がなされる。正規表現を用いれば、文字列を直接指定せず、「特徴」(パターン)を指定することができるため、表記の揺れを吸収して検索を行ったり、複数の異なる文字列を一括して置換したりすることができる。例えば「^」という文字は「行頭」、「.」は「任意の1文字」、「+」という文字は「直前の要素の１回以上の繰り返し」を意味するなどの規定がある。従って前記システム１００は、出力条内容１７０３が示す内容について、こうした正規表現にて記述するために、正規表現の規定について辞書データと所定の変換アルゴリズムを予め記憶部１０１に備えており、出力条件内容１７０３を入力として正規表現を生成し、これをベースにして、前記ステップ６２０で取得した設計項目の値１１０３とのパターンマッチングを行うものとする。
【００８９】
パターンマッチングの結果、前記出力条件内容１７０３と、前記ステップ６２０で取得した設計項目の値１１０３とがマッチした場合（ステップ６４０：可）、前記システム１００は該当テストケースについて出力可と判定し、他方、マッチしなかった場合（ステップ６４０：否）には出力不可と判定する。
【００９０】
続いて前記システム１００は、前記ステップ６４０での出力可否の結果をもとに、出力可の場合（ステップ６４０：可）、処理をステップ６５０に進める。他方、出力不可の場合（ステップ６４０：否）、前記システム１００は処理をステップ５７０に戻す。
【００９１】
前記システム１００は、前記ステップ５６０で取得したテストケースレコードからテストケースＩＤ１５０１とテストケース名１５０２を取得する（ステップ６５０）。この場合、前記システム１００は、雛形ファイル１２７からシート名が「ｔｅｍｐｌａｔｅ」となっているシートをコピーして、前記取得したテストケース名１５０２をシート名に持つ新規シートを作成する（ステップ６６０）。
【００９２】
次に前記システム１００は、テスト情報データベース１２６のテストケース詳細テーブル６０６にアクセスし、テストケース詳細テーブル６０６のテストケースＩＤ１６０１が前記ステップ６５０で取得したテストケースＩＤ１５０１と一致するレコード、すなわちテストケース詳細レコードを取得する（ステップ６７０）。
【００９３】
また前記システム１００は、前記ステップ６７０で取得したテストケース詳細レコードを１つずつ読込んでいく。テストケース詳細レコードがある場合（ステップ６８０：有）、システム１００は処理をステップ６９０に進める。他方、テストケース詳細レコードが無い場合（ステップ６８０：無）、前記システム１００は処理をステップ５７０に戻す。こうした処理は、前記ステップ６７０で得たテストケース詳細レコードが無くなるまで繰り返し実行される。
【００９４】
続いて前記システム１００は、前記ステップ６７０で取得したテストケース詳細レコードから出力区分１６０３と操作内容１６０４を取得する（ステップ６９０）。前記システム１００は、ここで取得した操作内容１６０４に含まれる設計項目ＩＤを取得する（ステップ７００）。この場合、前記システム１００は、操作内容１６０４のうち「｛」と「｝」に挟まれる値を設計項目ＩＤとして扱う。
【００９５】
前記システム１００は、前記ステップ７００で取得した設計項目ＩＤに対応する設計項目の値１１０３を、前記ステップ５５０で取得、作成した情報から取得する（ステップ７１０）。また前記システム１００は、前記ステップ７１０で取得した設計項目の値１１０３を、前記ステップ６９０で得た操作内容１６０４に含まれる設計項目ＩＤと置換する（ステップ７２０）。
【００９６】
前記システム１００は、前記ステップ６９０で取得した、「条件」や「確認」といった出力区分１６０３を元に、前記ステップ７２０で作成した操作内容をシート（前記ステップ６６０で雛形ファイル１２７から作成してあるシート。形式は図１２参照）における該当出力区分のセルに出力していくことで、テストケースの生成・出力処理を行う（ステップ７３０）。こうした処理を行うことで、図１４で例示したテストケース２０（のうち出力可のもの）が生成されることになる。こうしたテストケース出力後、前記システム１００は処理を前記ステップ６８０に戻す。以降、テストケース詳細レコードが無くなるまで（ステップ６８０：無し→ステップ５７０）、テストケースレコードが無くなるまで（ステップ５７０：無→ステップ５３０）、設計項目データレコードが無くなるまで（ステップ５３０：無→ＥＮＤ）、前記システム１００は処理を繰り返すこととなる。
【００９７】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００９８】
こうした本実施形態によれば、フォーマットが異なる各種設計書に対してテストケースを自動生成することが可能であり、テストケース生成作業の省略による作業量縮小を図ることができる。また、自動生成するテストケースに関して、ユーザによる追加、変更、削除も可能であり、不要なテストケースの消化による作業量増大や、必要なテストケースが出力されないことによるテスト漏れによる品質の低下といった事態の発生を防ぐことができる。
【００９９】
したがって、設計書におけるフォーマットによらずテストケースを自動生成すると共に、ユーザによるテストケース編集も可能として、システム検証の効率化、品質低下の防止を図ることができる。
【０１００】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、前記テストケース自動生成システムにおいて、前記演算部は、記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせるとしてもよい。
【符号の説明】
【０１０１】
５ 画面遷移定義情報
６ データ仕様情報
１０ 設計書
２０ テストケース
１００ テストケース自動生成システム
１０１ 記憶部
１０２ プログラム
１０３ メモリ
１０４ 演算部
１０５ 入力部
１０６ 出力部
１２５ 設計情報データベース
１２６ テスト情報データベース
１２７ 雛形ファイル
１２８ 環境設定ファイル
６０１ 設計書テーブル
６０２ 設計項目テーブル
６０３ 設計書詳細テーブル
６０４ 設計項目データテーブル
６０５ テストケーステーブル
６０６ テストケース詳細テーブル
６０７ 出力条件テーブル
【特許請求の範囲】
【請求項１】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、
各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、
を備えるテストケース自動生成システム。
【請求項２】
前記演算部は、
記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせることを特徴とする請求項１に記載のテストケース自動生成システム。
【請求項３】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、
を実行することを特徴とするテストケース自動生成方法。
【請求項４】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、
を実行させることを特徴とするテストケース自動生成プログラム。
【請求項１】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成するコンピュータであって、
各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部と、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理を実行する演算部と、
を備えるテストケース自動生成システム。
【請求項２】
前記演算部は、
記憶部から読み出した前記設計情報データベースのデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行うに際し、前記出力条件が示す情報の組み合わせを正規表現とし、これを前記設計情報データベースのデータに対しパターンマッチングさせることを特徴とする請求項１に記載のテストケース自動生成システム。
【請求項３】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータが、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、
を実行することを特徴とするテストケース自動生成方法。
【請求項４】
システムの設計書のデータに基づいて前記システムのテストケースを自動生成すべく、各種設計書間に共通する項目について予め定義したテーブルを記憶した記憶部を備えたコンピュータに、
テストケース別の、前記項目が記述に含まれたテスト内容の定義および出力条件について、入力部を介しユーザから指定を受けて、テスト情報データベースとして記憶部に格納する処理と、
処理対象となる設計書のデータを前記テーブルに照合し、該テーブルで定義された各項目に該当する情報を前記設計書のデータから抽出し、該抽出データを前記テーブルの項目に合わせて、設計情報データベースとして記憶部にて記憶する処理と、
記憶部から前記設計情報データベースのデータを読み出し、該読み出したデータと、前記テスト情報データベースにおける各テストケースの出力条件とのパターンマッチングを行って、前記出力条件が満たされたテストケース、ないし、出力条件が元々設定されていなかったテストケースについて特定する処理と、
前記特定したテストケースについて、前記テスト情報データベースの該当テストケースの定義が含む各項目に対応するデータを、前記読み出した設計情報データベースのデータから特定し、該特定したデータを前記定義に設定することで該当テストケースを生成する処理と、
を実行させることを特徴とするテストケース自動生成プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１３−３７２９（Ｐ２０１３−３７２９Ａ）
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願番号】特願２０１１−１３２５１７（Ｐ２０１１−１３２５１７）
【出願日】平成２３年６月１４日（２０１１．６．１４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願日】平成２３年６月１４日（２０１１．６．１４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]