(57)【要約】【課題】登録アプリケーションを用いてデータベースにデータを登録するような環境においてテストの目的に適合したテストデータを自動的にデータベースに登録する。【解決手段】データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いてデータベースに登録する方法は、テストの条件に関するデータを取得し、テスト条件データ格納部に格納する工程と、テスト条件データ格納部に格納されたテストの条件に関するデータ、及びデータ登録アプリケーションの仕様データから特定され且つデータ登録アプリケーションの逆処理を規定する逆仕様データに基づき、データ登録アプリケーションに対する入力候補値を生成する工程と、入力候補値をデータ登録アプリケーションに入力して、データベースに対する登録処理を実施させる工程とを含む。【選択図】図２
2008176760.tif 000002
【特許請求の範囲】
【請求項１】
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録するプログラムであって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成ステップと、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させる入力ステップと、
を含み、コンピュータに実行されるテストデータ登録プログラム。
【請求項２】
前記生成ステップが、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータに従って前記データ登録アプリケーションに対する初期入力候補値を生成する初期入力候補値生成ステップと、
前記データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、前記初期入力候補値から前記入力候補値を生成する入力候補値生成ステップと、
を含む請求項１記載のテストデータ登録プログラム。
【請求項３】
前記生成ステップが、
前記テストの条件に関するデータが規定されていないデータ項目について、入力代表値データ格納部に格納されている入力代表値を入力候補値として特定するステップ
を含む請求項１記載のテストデータ登録プログラム。
【請求項４】
前記生成ステップが、
前記テストの条件に関するデータから前記初期入力候補値を特定できないデータ項目について、データ登録アプリケーション仕様データ格納部に格納された、前記データ登録アプリケーションの仕様データに含まれる処理ロジックから、前記データ登録アプリケーションに対する第２の初期入力候補値を生成するステップと、
前記データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、前記第２の初期入力候補値から前記入力候補値を生成するステップと、
をさらに含む請求項２記載のテストデータ登録プログラム。
【請求項５】
前記入力ステップが、
各データ項目の前記入力候補値を組み合わせて複数の入力メッセージを生成するステップ
を含む請求項４記載のテストデータ登録プログラム。
【請求項６】
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるための方法であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成ステップと、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させるステップと、
を含み、コンピュータに実行されるテストデータ登録方法。
【請求項７】
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるためのテストデータ登録装置であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納する手段と、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成手段と、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させる手段と、
を有するテストデータ登録装置。
【請求項８】
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるための方法であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションが利用する第２のデータベースにデータを登録するための第２のデータ登録アプリケーションの仕様データから特定され且つ前記第２のデータ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記第２のデータ登録アプリケーションに対する第１入力候補値を生成し、記憶装置に格納するステップと、
前記記憶装置に格納された前記第１入力候補値を前記第２のデータ登録アプリケーションに入力して、前記第２のデータベースに対する登録処理を実施させるステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する第２入力候補値を生成し、前記記憶装置に格納するステップと、
前記記憶装置に格納された前記第２入力候補値を前記データ登録アプリケーションに入力して、前記第２のデータベースを利用した、前記データベースに対する登録処理を実施させるステップと、
を含み、コンピュータに実行されるテストデータ登録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースを利用するアプリケーションのテストに用いるデータをデータベースに登録するための技術に関する。
【背景技術】
【０００２】
従来、データベースを利用するアプリケーションのテストを実施する際にそのデータベースを用意する方法には、以下の２つの方法が存在している。
（Ａ）データベースへデータを直接登録する方法
ＳＱＬ（Structured Query Language）などを使ってデータをデータベースに直接登録する方法では、カラム１つ１つについてスキーマに基づき適切な値を設定しなければならない。また、業務上のデータの関連を保持するためには、他のデータベースへも適切に関連データを別途登録する必要がある。各カラムへ適切な値を設定するには工数が大きく、業務上の整合性を保つデータの設定を人手で行うのは、非常に困難である。
【０００３】
そのため例えば特開２０００−２０５２９号公報には、データベースが有するスキーマ情報にデータ生成ルールと結合情報とを与えて、テストデータを自動生成する技術が開示されている。具体的には、データウェアハウステストデータ作成装置は、データベースと、データベースのデータベースアクセス手段と、データベースのスキーマ情報にデータ生成ルール及び結合情報を入力してなるデータ作成情報を保持するデータ作成情報記憶手段と、データ生成ルール及び結合情報の関連情報を入力するデータ作成情報登録手段と、スキーマ情報及び関連情報によりテストデータを生成するデータ作成手段と、指示及びパラメータを入力するデータ作成起動手段と、テストデータ生成の作業域のデータメモリと、を具備する。しかし、データベースにデータを登録する登録アプリケーションを用いる場合を想定していない。
【０００４】
また、特開２００１−２５６０７６号公報には、実環境に適したテストデータを簡単かつ適切に生成するテストデータ生成技術が開示されている。具体的には、テストデータ作成装置は、ユーザーがテストデータ生成のパラメータを設定すると、既存のデータベースに接続して、既存のデータベース内のデータ格納情報を取得する。次に、当該データ格納情報を参照しつつ、既存データベースのテーブルに格納されているレコードを読み出して、カラムデータの特徴を算出し、既存のデータベースを切り離した後、当該既存のデータベースの特徴を用いてテストデータを生成する。テストデータを作成すると、開発対象のデータベースに接続して、作成したテストデータのレコードを開発対象のデータベースに格納する。したがって、実稼働している既存のデータベースに格納されているデータを用いて、より一層実情に即したダミーのテストデータを生成することができ、データベースのチューニングを適切に行うことができる。但し、テスト対象となるアプリケーションのテストの目的に合致したデータがデータベースに登録されないと、アプリケーションのテストが適切に行われないが、この点については考慮されていない。
（Ｂ）登録アプリケーションを利用した登録方法
テスト対象のアプリケーションが利用するデータベースには、当該データベースに業務上の整合性などを保つようにデータ登録を行う登録アプリケーションが用意される場合がある。このような登録アプリケーションが存在する場合には、業務上の整合性などを保つという点についてはユーザは気にする必要はないが、どのようなデータを登録アプリケーションに入力すれば、テスト対象のアプリケーションの適切なテストが行えるかは、簡単には分からない。
【特許文献１】特開２０００−２０５２９号公報
【特許文献２】特開２００１−２５６０７６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このように従来では、登録アプリケーションを用いてデータベースにデータを登録するような環境においてテストの目的に適合したテストデータを自動的に登録することができなかった。
【０００６】
従って、本発明の目的は、登録アプリケーションを用いてデータベースにデータを登録するような環境においてテストの目的に適合したテストデータを自動的にデータベースに登録するための技術を提供することである。
【０００７】
また、本発明の他の目的は、テスト対象アプリケーションのテストを漏れの無いように実施するためのデータを生成するための技術を提供することである。
【課題を解決するための手段】
【０００８】
本発明に係るテストデータ登録方法は、データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて上記データベースに登録する方法であって、テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、テスト条件データ格納部に格納されたテストの条件に関するデータ、及びデータ登録アプリケーションの仕様データから特定され且つデータ登録アプリケーションの逆処理を規定する逆仕様データに基づき、データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成ステップと、記憶装置に格納された入力候補値（例えば入力メッセージとして）をデータ登録アプリケーションに入力して、データベースに対する登録処理を実施させる入力ステップとを含む。
【０００９】
このようにすればテストの目的に適合したデータがデータ登録アプリケーションを介して業務上の整合性などを保持しつつデータベースに登録されるようになる。すなわち、テスト対象アプリケーションのテストに適切なデータがデータベースに蓄積されるようになる。
【００１０】
なお、上で述べた生成ステップが、テスト条件データ格納部に格納されたテストの条件に関するデータに従ってデータ登録アプリケーションに対する初期入力候補値（例えば実施の形態における初期候補値）を生成する初期入力候補値生成ステップと、データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、初期入力候補値から入力候補値を生成する入力候補値生成ステップとを含むようにしてもよい。このようにすれば、テストの目的に適合したデータが、正しくデータベースに登録されるようになる。
【００１１】
さらに、初期入力候補値生成ステップ及び入力候補値生成ステップが、テストの条件に関するデータが規定されているデータ項目について実施されるようにしてもよい。
【００１２】
また、上で述べた初期入力候補値生成ステップが、テストの条件に関するデータから直接上記初期入力候補値を特定できない場合には、入力代表値データ格納部に格納されている入力代表値を初期入力候補値として特定するステップを含むようにしてもよい。例えば、テストの条件に関するデータが、「Ａ」を含まないというテスト条件である場合に、Ａ以外の値を入力代表値から得るものである。
【００１３】
さらに、上で述べた生成ステップが、テストの条件に関するデータが規定されていないデータ項目について、入力代表値データ格納部に格納されている入力代表値を入力候補値として特定するステップを含むようにしてもよい。テストの条件に関するデータが規定されていないデータ項目については任意の値を設定できるためである。
【００１４】
また、本発明において、データ登録アプリケーションの仕様データから、データ登録アプリケーションの逆処理を規定する逆仕様データを生成する逆仕様データ生成ステップをさらに含むようにしてもよい。このようにすれば、自動的に逆仕様データを生成することができる。
【００１５】
なお、上で述べた逆仕様データ生成ステップが、データ登録アプリケーションの仕様データ内のデータ入力又はデータチェックにおける演算を逆演算に変更するステップと、データ登録アプリケーションの仕様データ内のデータ入力又はデータチェックにおける入力項目と出力項目を入れ替えるステップとを含むようにしてもよい。このようにすれば適切な逆処理を規定する逆仕様データが生成される。
【００１６】
また、上で述べた生成ステップが、テストの条件に関するデータから初期入力候補値を特定できないデータ項目について、データ登録アプリケーション仕様データ格納部に格納された、データ登録アプリケーションの仕様データに含まれる処理ロジックから、データ登録アプリケーションに対する第２の初期入力候補値を生成するステップと、データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、第２の初期入力候補値から入力候補値を生成するステップとをさらに含むようにしてもよい。このようにすれば、入力候補値のバリエーションを増加させ、テスト漏れを防止することができるようになる。
【００１７】
また、上で述べた入力ステップが、各データ項目の入力候補値を組み合わせて複数の入力メッセージを生成するステップを含むようにしてもよい。このようにすれば、適切に複数のテストレコードをデータベースに登録できるようになる。
【００１８】
さらに、上で述べた生成ステップが、テストの条件に関するデータから初期入力候補値を特定できないデータ項目について、仕様データ格納部に格納された、上記アプリケーションの仕様データに含まれる処理ロジックから、データ登録アプリケーションに対する第３の初期入力候補値を生成するステップと、上記アプリケーションの逆処理を規定する第２の逆仕様データ及びデータ登録アプリケーションの逆処理を規定する逆仕様データを用いて、第３の初期入力候補値から入力候補値を生成するステップとをさらに含むようにしてもよい。このようにすれば、さらに入力候補値のバリエーションを増加させ、テスト漏れを防止することができるようになる。
【００１９】
また、本発明において、上記データベースに既登録のデータから入力候補値を抽出するステップをさらにようにしてもよい。さらに入力候補値のバリエーションを増加させることができる。
【００２０】
さらに、本発明において、入力ステップによって上記データベースに登録されたレコード及び上記テストに関するデータから、テストの条件に関する新たなデータを生成するステップをさらに含むようにしても良い。このようにすれば、テスト実行者に漏れなくテストを行わせることができるようになる。
【００２１】
なお、本方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
【発明を実施するための最良の形態】
【００２２】
［実施の形態１］
まず、図１を用いて本発明の第１の実施の形態における前提となるシステム概要を説明する。テスト対象アプリケーション１０６は、実行中データベース（ＤＢ）１０３を参照する構成となっている。このＤＢ１０３へのデータ登録には、登録アプリケーション１０２が用いられ、登録アプリケーション１０２は、当該登録アプリケーション１０２用の入力メッセージ１０１に応じてデータをＤＢ１０３に登録する。また、テスト対象アプリケーション１０６のテストを行う場合には、当該テストの条件を規定したテストケース１０４及び当該テストケース１０４のためのテスト入力値１０５を用意して、当該テスト入力値１０５をテスト対象アプリケーション１０６に入力する。これによって、テスト対象アプリケーション１０６のテストを行う。
【００２３】
このような前提の下、ＤＢ１０３に、テストケース１０４に従ったデータを蓄積させるには、入力メッセージ１０１を適切に生成する必要がある。図２乃至図１６を用いて、入力メッセージ１０１を適切に生成するためのテストデータ登録装置について説明する。
【００２４】
本実施の形態に係るテストデータ登録装置は、テストケースに関するデータを入力するためのテストケース入力部１と、テストケース入力部１により入力されたテストケースに関するデータを格納するテストケースデータ格納部３と、入力代表値を入力するための入力代表値入力部１１と、入力代表値入力部１１により入力された入力代表値を格納するための入力代表値格納部１３と、登録アプリケーション１０２の仕様データを格納する登録アプリケーション仕様データ格納部５と、登録アプリケーション仕様データ格納部５及び入力代表値格納部１３に格納されているデータを用いて登録アプリケーション１０２の逆処理を行うための逆仕様データを生成するための処理を実施する仕様リバース部７と、仕様リバース部７の処理結果である逆仕様データを格納する逆仕様データ格納部９と、テストケースデータ格納部３と逆仕様データ格納部９と入力代表値格納部１３とに格納されたデータを用いて登録アプリケーション１０２に対する入力メッセージを生成する処理を実施する入力メッセージ生成部１５と、入力メッセージ生成部１５により生成された入力メッセージを格納する入力メッセージ格納部１７と、入力メッセージ格納部１７に格納されている入力メッセージを登録アプリケーション１０２に入力する処理を実施する入力実行部１９とを有する。
【００２５】
次に、登録アプリケーション仕様データ格納部５に格納されるデータの一例を図３に示す。なお、本実施の形態における登録アプリケーション１０２が受け付ける入力メッセージは、商品名と数量と単位という項目セットを含む。また、登録アプリケーション１０２は、入力メッセージにおける商品及び数量を１レコードとしてＤＢ１０３に登録するが、その際、入力メッセージにおける単位が「本」である場合には、入力メッセージにおける数量を整数として登録し、単位が「ダース」の場合には、入力メッセージにおける数量を１２倍した整数を数量として登録する。このような処理を行う登録アプリケーション１０２の仕様は、例えば添付の付録に記載されているＸＭＬデータ仕様記述法に従って記述されれば、図３に示すようなデータになる。
【００２６】
仕様リバース部７は、後に詳細に説明する処理を行って、登録アプリケーション１０２の逆処理を行うための逆仕様データを生成し、逆仕様データ格納部９に格納する。図３に示した仕様データに対応する逆仕様データの一例を図４に示す。図４において四角で囲まれた部分が図３から実質的に変更された部分である。具体的には、入力であった「入力Ｍｓｇ．数量」が出力になり、出力であった「ｔｅｓｔＤＢ．数量」が入力になっている。さらに、ｆｕｎｃｔｉｏｎ属性の値（メソッド）がｉｎｔからＳｔｒｉｎｇに変更されている。さらにｏｐ属性の値がＭＵＬ（かけ算）からＤＩＶ（割り算）に変更されている。また、入力であった「入力Ｍｓｇ．商品」が出力になり、出力であった「ｔｅｓｔＤＢ．商品」が入力になっている。なお、ｔｅｓｔＤＢは、ＤＢ１０３を意味する。
【００２７】
図４の内容を具体的に説明すれば、以下のようになる。
・入力Ｍｓｇ．商品 ＝ ｔｅｓｔＤＢ．商品
・入力Ｍｓｇ．単位が「本」の場合、入力Ｍｓｇ．数量 ＝ ｔｅｓｔＤＢ．数量
・入力Ｍｓｇ．単位が「ダース」の場合、入力Ｍｓｇ．数量 ＝ ｔｅｓｔＤＢ．数量／１２
より具体的には、入力メッセージの商品はｔｅｓｔＤＢの商品である。入力メッセージの単位がダースであれば、ｔｅｓｔＤＢ．数量／１２がその入力メッセージの数量となる。単位が本であれば、ｔｅｓｔＤＢ．数量がその入力メッセージの数量である。
【００２８】
本実施の形態では、仕様リバース部７によって自動的に逆仕様データを生成する例を示すが、逆仕様データをユーザが用意するようにしても良い。
【００２９】
なお、テスト対象アプリケーション１０６は、以下のような処理を行うプログラムであるとする。
・テスト対象アプリケーション１０６に対する入力メッセージは、商品名と数量というデータ項目を有する。
・入力メッセージにおける商品がＤＢ１０３に存在しなければエラー。
・入力メッセージにおける商品に対応する数量がＤＢ１０３における同じ商品の数量よりも大きければエラー。
【００３０】
このようなプログラムの仕様は、図３と同じＸＭＬデータ仕様記述法を用いれば例えば図５に示すように記述できる。
【００３１】
次に、図２に示したテストデータ登録装置の処理フローを図６乃至図１６を用いて説明する。まず、テストケース入力部１は、ユーザに対してテスト入力値及びテスト条件の入力を促し、ユーザから当該テスト入力値及びテスト条件の入力を受け付け、テストケースデータ格納部３に格納する（ステップＳ１）。例えば、図７に示すようなデータがテストケースデータ格納部３に格納される。図７の例では、テスト番号１の場合、ＤＢ１０３に入力メッセージに係る商品名が存在していないケースをテストするものとする。このような場合、テスト番号１として、テスト入力値が、商品＝”Ｄ”であり、数量＝任意と設定される。また、テスト条件として、ｔｅｓｔＤＢ．商品（ｃｈａｒ型）に「Ｄ」を含まないという条件が設定される。テスト条件としては、値を含む、含まない、より大きい、以上、より小さい、以下、一致、不一致などを設定できるようになっている。図７の例では、数値は任意であるから、テスト条件は設定されていない。
【００３２】
また、図８の例では、テスト番号２の場合、入力メッセージに係る商品の数量が、ＤＢ１０３における商品の数量より多いケースをテストするものである。このような場合、テスト番号２として、テスト入力値が、商品＝”Ｅ”で、数量＝２５と設定される。また、テスト条件として、ｔｅｓｔＤＢ．商品（ｃｈａｒ型）に「Ｅ」を含むという条件と、ｔｅｓｔＤＢ．数量（integer型）に、「２５」より小さいという条件が設定される。
【００３３】
ユーザは、このようにテスト入力値及びテスト条件をテストケース入力部１により入力する。
【００３４】
次に、入力代表値入力部１１は、ユーザに対して入力代表値の入力を促し、ユーザから当該入力代表値の入力を受け付け、入力代表値を入力代表値格納部１３に格納する（ステップＳ３）。例えば図９に示すようなデータが入力され、入力代表値格納部１３に格納される。図９の例では、入力メッセージに含まれる商品という項目の値「Ｆ」及び型「Ｓｔｒｉｎｇ」と、数量という項目の値「１００」及び型「Ｓｔｒｉｎｇ」と、単位という項目の値「ダース」及び型「Ｓｔｒｉｎｇ」とが入力され、格納される。
【００３５】
そして、仕様リバース部７は、登録アプリケーション仕様データ格納部５及び入力代表値格納部１３に格納されたデータを用いて、逆仕様データの生成処理を実施する（ステップＳ４）。この処理については、後に詳述する。結果として図４に示すようなデータが、逆仕様データ格納部９に格納される。また、人手によって逆仕様データを生成する場合には、本ステップはスキップされる。
【００３６】
そして、入力メッセージ生成部１５は、テストケースデータ格納部３を参照して、未処理のテストケースのデータを取得する（ステップＳ７）。また、例えば入力代表値格納部１３を参照して、未処理のＤＢ項目を特定する（ステップＳ９）。未処理のＤＢ項目については、例えば逆仕様データ格納部９に格納されている逆仕様データにおいて、条件として規定されているようなＤＢ項目を優先して特定する。図４の例では、「単位」が条件として規定されているので、「単位」を先に処理する。
【００３７】
その後、入力メッセージ生成部１５は、ステップＳ９で特定したＤＢ項目に条件が付されているか否かを、ステップＳ７で取得したテストケースのデータに基づき判断する（ステップＳ１１）。例えば、テスト番号１の場合、条件が付されているのはｔｅｓｔＤＢ．商品のみであるから、商品については条件が付されており、他のＤＢ項目については条件が付されていないということを判断することができる。また、テスト番号２の場合、条件が付されているのはｔｅｓｔＤＢ．商品及びｔｅｓｔＤＢ．数量であるから、これらについては条件が付されていると判断し、単位というＤＢ項目については条件が付されていないと判断される。
【００３８】
ここでステップＳ９で特定されたＤＢ項目が条件付きではないと判断された場合には、入力メッセージ生成部１５は、入力代表値格納部１３から、該当ＤＢ項目の入力代表値を入力候補値として取得し、例えばメインメモリなどの記憶装置に格納する（ステップＳ１３）。そして端子Ａを介して図１０の処理に移行する。
【００３９】
例えば、テスト番号１又は２において、「単位」というＤＢ項目を処理している場合には、該当ＤＢ項目の入力代表値である「ダース」を入力候補値として特定する。
【００４０】
例えば、テスト番号１の場合、「数量」というＤＢ項目を処理する場合には、テスト条件が設定されていないので、該当ＤＢ項目の入力代表値である「１００」を入力候補値として特定する。
【００４１】
一方、ステップＳ９で特定されたＤＢ項目が条件付きであると判断された場合には、入力メッセージ生成部１５は、ステップＳ９で特定されたＤＢ項目が文字列であるか判断する（ステップＳ１５）。ステップＳ９で特定されたＤＢ項目が文字列であると判断された場合には、入力メッセージ生成部１５は、ステップＳ７で取得されたテストケースのテスト条件、又は当該テスト条件で特定できない場合には該当ＤＢ項目の入力代表値に従って、初期候補値を特定する（ステップＳ２１）。
【００４２】
そして、入力メッセージ生成部１５は、初期候補値を逆仕様データ格納部９に格納されている逆仕様データで解釈し、入力候補値を特定する（ステップＳ２３）。その後、処理は端子Ａを介して図１０の処理に移行する。
【００４３】
例えば、テスト番号１の場合、文字列（ｃｈａｒａｃｔｅｒ）である「商品」というＤＢ項目には、図７に示すように、テスト条件である「Ｄ」を含まないという条件が設定されているが、このテスト条件だけでは「Ｄ」以外の商品名を特定できないので、該当ＤＢ項目の入力代表値である「Ｆ」を特定し、初期候補値とする。また、上で述べた逆仕様データを適用すれば、「Ｆ」がそのまま入力候補値となる。
【００４４】
また、テスト番号２の場合、「商品」というＤＢ項目には、図８に示すように、テスト条件である「Ｅ」を含むという条件が設定されているので、当該テスト条件から初期候補値は「Ｅ」と特定される。また、上で述べた逆仕様データを適用すれば、「Ｅ」がそのまま入力候補値となる。
【００４５】
さらに、ＤＢ項目が文字列ではないと判断された場合には、入力メッセージ生成部１５は、ステップＳ７で取得されたテストケースのテスト条件に従って初期候補値を特定する（ステップＳ１７）。そして、当該初期候補値を逆仕様データ格納部９に格納されている逆仕様データで解釈し、入力候補値を特定する（ステップＳ１９）。その後、処理は端子Ａを介して図１０の処理に移行する。
【００４６】
例えば、テスト番号２の場合、数値（ｉｎｔ）である「数量」というＤＢ項目には、図８に示すように、テスト条件である「２５」より小さい整数という条件が設定されているので、当該テスト条件から初期候補値は「２４」と特定される。なお、「２４」以下の整数であれば、他の値であってもよい。また、上で述べた逆仕様データを適用すれば、「ダース」が単位として特定されているので、２４／１２＝２が算出されて「２」が入力候補値として特定される。
【００４７】
図１０の処理の説明に移行して、全てのＤＢ項目について処理したか判断する（ステップＳ２５）。未処理のＤＢ項目が存在する場合には端子Ｂを介して図６のステップＳ９に戻る。
【００４８】
一方、全てのＤＢ項目について処理した場合には、入力候補値を組み合わせて入力メッセージを生成し、入力メッセージ格納部１７に格納する（ステップＳ２７）。例えば、図１１に示すようなデータが格納される。図１１の例では、テスト番号毎に、商品、数量及び単位が格納されるようになっている。上で述べたように、テスト番号１の場合には、商品「Ｆ」、数量「１００」及び単位「ダース」が入力メッセージとして特定される。テスト番号２の場合には、商品「Ｅ」、数量「２」及び単位「ダース」が入力メッセージとして特定される。
【００４９】
そして、入力実行部１９は、入力メッセージ格納部１７に格納されている入力メッセージを登録アプリケーション１０２に出力する（ステップＳ２９）。そうすると、登録アプリケーション１０２は、登録アプリケーション仕様データ格納部５に格納されている仕様データに従った処理を行って、データをＤＢ１０３に登録する。図１１に示したような入力メッセージを登録アプリケーション１０２に出力した場合には、図１２に示すようなデータがＤＢ１０３に登録される。すなわち、テスト番号１の場合には、商品「Ｆ」及び数量「１２００」（＝１００×１２）が登録され、テスト番号２の場合には、商品「Ｅ」及び数量「２４」（＝２×１２）が登録される。
【００５０】
その後、入力メッセージ生成部１５は、全てのテストケースについて処理したか判断する（ステップＳ３１）。未処理のテストケースが存在する場合には端子Ｃを介して図６のステップＳ７に戻る。一方、全てのテストケースについて処理した場合には、処理を終了する。
【００５１】
以上のような処理を実施すれば、登録アプリケーション１０２を介して各テストケースに適合した形でデータがＤＢ１０３に登録されるようになる。なお、登録アプリケーション１０２を用いているのでＤＢ１０３におけるデータの整合性については問題はない。従って、テスト対象アプリケーション１０６についてのテスト環境作成が効率化される。
【００５２】
なお、入力メッセージ格納部１７には、入力メッセージのデータに対応してテストケースのデータを対応付けて登録しておくようにしても良い。このようにすれば、どのようなテストケースの場合にどのような入力メッセージを登録アプリケーション１０２に出力すべきかということを保持しておくことができ、再度同じようなテストを行う場合に、入力メッセージ格納部１７に格納されている入力メッセージを再利用できるためである。
【００５３】
なお、図１に示した本実施の形態の前提となるシステム概要は一例であって、例えば図１３に示すようなシステムの場合もある。具体的には、テスト対象アプリケーション２０６は、ＤＢ１を参照するので、ＤＢ１にテストデータを登録する必要があるが、当該ＤＢ１に対する登録アプリケーションＢが、さらにＤＢ１とは別のＤＢ２を参照し、ＤＢ２に対する登録アプリケーションＡが別に存在する場合がある。このような場合には、ＤＢ２にデータを登録するための入力メッセージＸを生成し、登録アプリケーションＡによってＤＢ２にデータを登録する。さらに、ＤＢ１にデータを登録するための入力メッセージＹを生成し、登録アプリケーションＢによってＤＢ１にデータを登録する。このように再帰的にテスト用のＤＢを構築してテスト対象アプリケーション２０６のテストを行うことができる。なお、入力メッセージＸ及びＹの生成については、上で述べた方法を用いることができる。
【００５４】
次に、図１４乃至図１６を用いて逆仕様データ生成処理について説明する。なお、ＸＭＬによる登録アプリケーション１０２についての仕様記述には、２種類の目的がある。すなわち、入力値のチェック及びエラーと、入力値の演算及び格納である。本実施の形態では、仕様の完全な逆仕様を得ることが目的ではなく、あくまでデータに着目し、入力値の演算及び格納を解析することを目的とする。
【００５５】
そこで、仕様リバース部７は、ｅＳｐｅｃタグから探索を開始し、仕様記述の単位であるSpecificationタグを検索し、未処理のSpecificationタグが存在するか判断する（ステップＳ４１）。未処理のSpecificationタグが存在する場合には、未処理のSpecificationタグを１つ特定する（ステップＳ４３）。一方、未処理のSpecificationタグが存在しない場合には、元の処理に戻る。
【００５６】
仕様リバース部７は、未処理のSpecificationタグを特定すると、当該Specificationタグの配下においてControlタグを検索し、未処理のControlタグが存在するか判断する（ステップＳ４５）。未処理のControlタグが存在しない場合にはステップＳ４１に戻る。一方、未処理のControlタグが存在する場合には、未処理のControlタグを１つ特定する（ステップＳ４７）。そして、当該Controlタグ配下の未処理のValidateタグにおけるsection属性の属性値を取得する（ステップＳ４９）。図３の例では、「処理」が特定される。
【００５７】
また、Section属性の属性値と同じnameのSectionタグを探索し、特定する（ステップＳ５１）。図３の例では６行目に該当するSectionタグが存在している。そして、特定した１つのSectionタグについてSection内処理を実施する（ステップＳ５３）。このSection内処理については後に詳細に説明する。
【００５８】
Section内処理が終了すると、ステップＳ５１で特定された全てのSectionタグについて処理したか判断する（ステップＳ５５）。未処理のSectionタグが存在する場合にはステップＳ５１に戻る。一方、ステップＳ５１で特定された全てのSectionタグについて処理した場合には、未処理のValidateタグが存在するか判断する（ステップＳ５７）。未処理のValidateタグが存在する場合にはステップＳ４９に戻る。一方、全てのValidateタグを処理した場合には、全てのControlタグを処理したか判断する（ステップＳ５９）。全てのControlタグを処理した場合には、ステップＳ４１に戻る。未処理のControlタグが存在する場合には、ステップＳ４７に戻る。
【００５９】
このような処理を行うことによって、ＸＭＬによる登録アプリケーション１０２の仕様において、必要な部分につきもれなく処理を行うことができるようになる。
【００６０】
次にSection内処理について図１５及び図１６を用いて説明する。blockタグの配下には、termタグ、valueタグ、verifyタグが存在する場合があるが、valueタグ及びverifyタグの場合には、入力データのチェック処理であり本実施の形態では関係ない。termタグだけが本実施の形態に関係する。そこで、仕様リバース部７は、blockタグを探索して、未処理のblockタグが存在するか判断する（ステップＳ６１）。全てのblockタグについて処理した場合には元の処理に戻る。一方、未処理のblockタグが存在する場合には、未処理のblockタグを１つ特定する（ステップＳ６３）。そして、当該blockタグのproperty属性が入力メッセージに関するものであるか判断する（ステップＳ６５）。図３の例では、８行目のblockタグが特定され、property属性が「入力Ｍｓｇ．単位」であるから、入力メッセージに関するものであると判断される。property属性が入力メッセージに関するものではない場合にはステップＳ６１に戻る。一方、property属性が入力メッセージに関するものである場合には、当該blockタグの配下を検索して未処理のtermタグが存在するか判断する（ステップＳ６７）。未処理のtermタグが存在しない場合にはステップＳ６１に戻る。
【００６１】
一方、未処理のtermタグが存在する場合には、当該未処理のtermタグを特定し（ステップＳ６９）、target属性が存在するか判断する（ステップＳ７１）。target属性が存在していない場合には、チェック処理なので、ステップＳ６７に戻る。一方、target属性が存在する場合には、target属性の属性値がＤＢ項目に関するものであるか判断する（ステップＳ７３）。図３の第９行目及び第１０行目の例では、target＝ｔｅｓｔＤＢ．数量となっているので、ＤＢ項目に関するものであることが分かる。target属性の属性値がＤＢ項目に関するものではない場合には、ステップＳ６７に戻る。一方、target属性の属性値がＤＢ項目に関するものである場合、ｏｐ属性が論理演算を示しているか判断する（ステップＳ７５）。ｏｐ属性が論理演算である場合には、逆仕様を生成することができないので、ステップＳ６９で特定されたtermタグにおけるＤＢ項目について、対応する入力代表値を取得するように変更する（ステップＳ７９）。そして端子Ｅを介してステップＳ６７に移行する。
【００６２】
一方、ｏｐ属性が論理演算でない場合には、ｏｐ属性の値を以下のように変更する（ステップＳ７７）。すなわち、ＡＤＤであればＳＵＢに、ＳＵＢであればＡＤＤに、ＭＵＬであればＤＩＶに、ＤＩＶであればＭＵＬに変更する。ＥＱの場合には、変更はない。図３の第９行目及び第１０行目の場合、「ＭＵＬ」がＤＩＶに変更される。
【００６３】
処理は端子Ｄを介して図１６に移行して、仕様リバース部７は、function属性が存在するか判断し（ステップＳ８１）、存在しない場合にはステップＳ８９に移行する。存在する場合には、functionのメソッドが所定のもの（ここではint, long, double, boolean, string）以外であるか判断する（ステップＳ８３）。このような所定のもの以外である場合には、逆仕様を特定できないので、ステップＳ６９で特定されたtermタグにおけるＤＢ項目について、対応する入力代表値を取得するように変更する（ステップＳ８５）。そして端子Ｅを介してステップＳ６７に移行する。
【００６４】
一方、functionのメソッドが所定のものである場合には、function属性を入力メッセージにおいて該当する項目の型に変換する（ステップＳ８７）。具体的には、入力代表値格納部１３に格納されている入力代表値の該当する項目の型に変換する。図３の第９行目及び第１０行目の場合、function属性のメソッドは「ｉｎｔ」であり、数量についての入力代表値の型がStringであるので、Ｓｔｒｉｎｇに変換される。
【００６５】
そして、property属性とtarget属性の値を交換する（ステップＳ８９）。そして、変更後のデータを逆仕様データ格納部９に格納する（ステップＳ９１）。そして端子Ｅを介してステップＳ６７に戻る。
【００６６】
以上のような処理を実施すれば、図３のような仕様は、図４に示すような仕様に変換されて逆仕様データ格納部９に格納される。
【００６７】
上で述べた処理に従えば、図３の第９行及び第１０行は、図４の第８行及び第９行となり、図３の第１１行は、図４の第１０行となる。また、図３の第１３行は、図４の第１２行となり、図３の第１４行は、図４の第１３行となる。
【００６８】
以上本発明の第１の実施の形態について説明したが、本発明はこれに限定されるものではない。例えば、図２の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。
【００６９】
また、処理フローについても、順番を入れ替えたり並行して実行するようにしても、同様の結果を得られれば、そのように変形しても良い。例えば、ステップＳ３とステップＳ１は順番を入れ替えても良い。
【００７０】
また、図１５のステップＳ６５及びＳ７３については、ＸＭＬ仕様記述によっては全てＹｅｓと判断すべき場合もある。
【００７１】
［実施の形態２］
第１の実施の形態によれば、自動的にテストケースに応じたデータをデータベースに登録することができるようになるが、必ずしも十分なバリエーションをデータベースに登録できているわけではない。
【００７２】
例えば、データ登録アプリケーションである注文受付アプリケーション１５１により注文テーブルを含むＤＢ１５２にデータが登録され、当該注文テーブルをテスト対象アプリケーションである金額計算アプリケーション１５３が参照して、金額テーブル１５４にデータを登録するシステム（図１７）を用いて説明する。ここで注文受付アプリケーション１５１は、顧客からの入力メッセージについては当該顧客の顧客ＩＤを登録し、営業からの入力メッセージについては当該営業担当者の営業ＩＤを登録することとなっている。また、金額計算アプリケーション１５３は、注文テーブルの顧客ＩＤを参照して対応する単価で金額を計算することとなっている。  
【００７３】
アプリケーションに関して生ずる障害は、主に開発者間による仕様解釈のずれに基づく。図１７の例では、データ登録アプリケーション１５１の開発者は、図１８（ａ）に示すように、伝票ＩＤが「１」のようなレコードや伝票ＩＤが「２」のようなレコードが登録されることを想定しているが、テスト対象アプリケーションの開発者は「顧客ＩＤ」が空（ｎｕｌｌ）である場合を想定して開発していないと、図１８（ａ）の伝票ＩＤが「１」のレコードについては図１８（ｂ）に示すようなデータが金額テーブル１５４に問題なく登録されるが、伝票ＩＤが「２」のレコードについては障害が生じ得る。また、伝票ＩＤが「２」のような場合のためのテストケースも用意されない。従って、このような問題はテストにおいて検出されない可能性がある。本実施の形態では、このような問題に対処すべく、データ登録アプリケーション１５１を介してＤＢ１５２に登録されるデータのバリエーションを豊富化し、テストケースを追加することによって、テストに漏れを無くして、後工程での手戻りを防止できるようにする。
【００７４】
本実施の形態におけるテストデータ登録装置の機能ブロック図を図１９に示す。なお、以下で述べる第３及び第４の実施の形態において必要なモジュールについても併せて示している。本システムは、テストケース入力部２０１と、テストケース入力部２０１などによって入力されたテストケースを格納するテストケースデータ格納部２０２と、登録アプリケーション仕様データ格納部２０３と、テスト対象アプリケーション仕様データ格納部２０４と、入力代表値入力部２０７と、入力代表値入力部２０７によって入力された入力代表値を格納する入力代表値格納部２０８と、入力代表値格納部２０８、登録アプリケーション仕様データ格納部２０３及びテスト対象アプリケーション仕様データ格納部２０４に格納された仕様データの逆仕様データを生成する仕様リバース部２０５と、仕様リバース部によって生成された逆仕様データを格納する逆仕様データ格納部２０６と、テストケースデータ格納部２０２と登録アプリケーション仕様データ格納部２０３と入力代表値格納部２０８と逆仕様データ格納部２０６と場合によってはテスト対象アプリケーション仕様データ格納部２０４及びＤＢ１５２に格納されたデータを用いて入力メッセージを生成する入力メッセージ生成部２０９と、入力メッセージ生成部２０９によって生成された入力メッセージを格納する入力メッセージ格納部２１０と、入力メッセージ格納部２１０に格納された入力メッセージについてデータ登録アプリケーション１５１に登録処理を実行させる入力実行部２１１と、テストケースデータ格納部２０２とＤＢ１５２に格納されたデータを用いて追加のテストケースを生成するテストケース生成部２１３とを含む。
【００７５】
登録アプリケーション仕様データ格納部２０３には、例えば図２０及び図２１に示すようなデータが格納される。図２０は、入力メッセージ（入力Ｍｓｇ）におけるデータ項目をデータ登録アプリケーション１５１内の対応するデータ項目に転記又は変換するためのセクション（section name="msgcopy"）と、データ登録アプリケーション１５１内のデータ項目をＤＢ１５２の注文テーブルの対応するデータ項目に転記又は変換するためのセクション（section name="dbcopy"）とを有する転記情報を示したものである。なお、記述法は、以下のＸＭＬ仕様記述法に示すとおりである。図２０の例では、入力メッセージにおける入力Ｍｓｇ．商品ＩＤ、入力Ｍｓｇ．数量、入力Ｍｓｇ．顧客ＩＤ及び入力Ｍｓｇ．営業ＩＤが、そのままデータ登録アプリケーション１５１の各データ項目に転記される。そして、データ登録アプリケーション１５１における伝票ＩＤ、商品ＩＤ、数量、顧客ＩＤ及び営業ＩＤが、注文テーブルにおける注文テーブル．伝票ＩＤ、注文テーブル．商品ＩＤ、注文テーブル．数量、注文テーブル．顧客ＩＤ及び注文テーブル．営業ＩＤにそのまま転記される。
【００７６】
また、図２１は、データ登録アプリケーション１５１における処理ロジックを示したものである。図２１では、ｖａｌｕタグが、その属性ｓｅｑ＝”１”から属性ｓｅｑ＝”４”までの４つ設けられており、これらに数量、商品ＩＤ、顧客ＩＤ及び営業ＩＤについての条件式が規定されている。具体的には、数量≦０、商品ＩＤ！＝ｎｕｌｌ、顧客ＩＤ＝ｎｕｌｌ、営業ＩＤ＝ｎｕｌｌという条件式で表される。そして、ｄｅｃｉｓｉｏｎタグが４つ設けられており、エラー、商品ＩＤの存在チェック、顧客ＩＤの存在チェック、営業ＩＤの存在チェックの条件を、属性ｓｅｑの４つの式を用いて規定している。具体的には、図２２に示すような処理ロジックが規定されている。但し、条件式で「＝」とされている場合においても、ｄｅｃｉｓｉｏｎタグにおいて論理条件がｆａｌｓｅとなっている場合には、「！＝」に条件式を書き直しており、同様に、条件式で「！＝」とされている場合においても、ｄｅｃｉｓｉｏｎタグにおいて論理条件がｆａｌｓｅとなっている場合には、「＝」に条件式を書き直している。
【００７７】
次に、図２３乃至図３９を用いて、図１９に示したシステムの動作を説明する。まず、テストケース入力部２０１は、ユーザに対してテスト入力値及びテスト条件の入力を促し、ユーザから当該テスト入力値及びテスト条件の入力を受け付け、テストケースデータ格納部２０２に格納する（ステップＳ１０１）。例えば、図２４に示すようなデータがテストケースデータ格納部２０２に格納される。図２４の例では、テスト番号１０の場合、ＤＢ１５２の注文テーブルにおいて数量が１０以上のケースをテストするものとする。このような場合、テスト番号１０として、テスト入力値が、伝票ＩＤ＝任意と設定される。また、テスト条件として、注文テーブル．数量が１０「以上」という条件が設定される。テスト条件としては、値を含む、含まない、より大きい、以上、より小さい、以下、一致、不一致などを設定できるようになっているが、ここでは図示を省略している。ユーザは、このようにテスト入力値及びテスト条件をテストケース入力部２０１により入力する。
【００７８】
次に、入力代表値入力部２０７は、ユーザに対して入力代表値の入力を促し、ユーザから当該入力代表値の入力を受け付け、入力代表値を入力代表値格納部２０８に格納する（ステップＳ１０３）。例えば図２５に示すようなデータが入力され、入力代表値格納部２０８に格納される。図２５の例では、入力メッセージ（入力Ｍｓｇ）に含まれる商品ＩＤという項目の値「００１」「００２」と、数量という項目の値「１」「１０００」と、顧客ＩＤという項目の値「Ｃ００１」と、営業ＩＤという項目の値「Ｓ００１」とが入力され、格納される。
【００７９】
そして、仕様リバース部２０５は、登録アプリケーション仕様データ格納部２０３及び入力代表値格納部２０８に格納されたデータを用いて、逆仕様データの生成処理を実施する（ステップＳ１０５）。この処理については、第１の実施の形態と同じであるから、説明は省略する。結果として図２６に示すようなデータが、逆仕様データ格納部２０６に格納される。また、人手によって逆仕様データを生成する場合には、本ステップはスキップされる。
【００８０】
その後、入力メッセージ生成部２０９は、テストケースデータ格納部２０２及び逆仕様データ格納部２０６に格納されているデータを用いて第１入力候補値抽出処理を実施する（ステップＳ１０７）。第１入力候補値抽出処理については、図２７乃至図２９を用いて説明する。
【００８１】
第１入力候補値抽出処理において、まず、入力メッセージ生成部２０９は、テストケースデータ格納部２０２から未処理のテストケースを１つ取り出す（ステップＳ１２１）。また、入力メッセージ生成部２０９は、入力候補値を設定すべき未処理のデータ項目を１つ特定する（ステップＳ１２３）。データ項目の種別については、例えば逆仕様データ格納部２０６に格納されている逆仕様データのうち、出力となるデータ項目（入力メッセージのデータ項目）に対応し且つ起点となるデータ項目（注文テーブルのデータ項目）を特定する。図２６の例では、section name="msgcopy"の部分の入力Ｍｓｇ.商品ＩＤ、入力Ｍｓｇ．数量、入力Ｍｓｇ．顧客ＩＤ及び入力Ｍｓｇ．営業ＩＤが出力となるデータ項目として特定され、それらに対応する、注文テーブル．商品ＩＤ、注文テーブル．数量、注文テーブル．顧客ＩＤ及び注文テーブル．営業ＩＤが特定される。
【００８２】
次に、入力メッセージ生成部２０９は、テストケースデータ格納部２０２に格納されたテストケースにおいて、ステップＳ１２３で特定されたデータ項目に対して条件が付されているか判断する（ステップＳ１２５）。図２４の例では、注文テーブル．数量については１０以上という条件が付されている。従って、ステップＳ１２３で特定されたデータ項目に対して条件が付されていない場合、すなわち注文テーブル．数量以外のデータ項目の場合には、ステップＳ１３３に移行する。一方、ステップＳ１２３で特定されたデータ項目に対して条件が付されている場合、すなわち注文テーブル．数量というデータ項目の場合には、テストケースの条件に従って初期候補値を特定できるか判断する（ステップＳ１２７）。例えば、図２８に示すようなルールに従う。図２８の例では、ＧＴ（greater than）、ＧＥ（greater than or equal to）、ＬＴ（less than）、ＬＥ（less than or equal to）、ＥＱ（equal to）、ＮＥ（not equal to）の各々に、条件を満たす値の特定ルール（ｏｐｅｒａｎｄ＋１，ｏｐｅｒａｎｄ，ｏｐｅｒａｎｄ−１，又は特定できず）及び条件を満たさない値の特定ルール（ｏｐｅｒａｎｄ＋１，ｏｐｅｒａｎｄ，ｏｐｅｒａｎｄ−１，又は特定できず）が規定されている。ここで、条件を満たす値について「特定できず」という特定ルールが規定されているケースに該当する場合には、ステップＳ１３３に移行する。
【００８３】
一方、テストケースの条件に従って初期候補値を特定できる場合には、入力メッセージ生成部２０９は、テストケースの条件に従って初期候補値を特定する（ステップＳ１２９）。図２８のルールに従って、１０以上という条件であれば、ｏｐｅｒａｎｄである「１０」をそのまま初期候補値として特定する。そして、入力メッセージ生成部２０９は、初期候補値を逆仕様データ格納部２０６に格納されている逆仕様データで解釈し、入力候補値を特定し、メインメモリなどの記憶装置に格納する（ステップＳ１３１）。例えば図２６に示した逆仕様データを用いて、注文テーブルについてのデータ項目から入力メッセージについてのデータ項目に変換する。図２６の例では単に転記する。そして、例えば、メインメモリには、図２９に示すように、入力Ｍｓｇ．商品ＩＤ、入力Ｍｓｇ．数量、入力Ｍｓｇ．顧客ＩＤ及び入力Ｍｓｇ．営業ＩＤの入力候補値を格納するエリアを確保しておき、入力Ｍｓｇ．数量の領域に、「１０」を格納する。
【００８４】
そして、全てのデータ項目について処理したか判断する（ステップＳ１３３）。未処理のデータ項目が存在している場合には、ステップＳ１２３に戻る。一方、全てのデータ項目について処理が完了した場合には、全てのテストケースについて処理したか判断する（ステップＳ１３５）。図２４の例では、テストケースは１つだけであったが、複数存在しており、未処理のテストケースが存在する場合には、ステップＳ１２１に戻る。一方、全てのテストケースの処理が完了した場合には、元の処理に戻る。
【００８５】
図２３の処理の説明に戻って、次に、メッセージ生成部２０９は、第２入力候補値抽出処理を実施する（ステップＳ１０９）。第２入力候補値抽出処理については、図３０乃至図３５を用いて説明する。
【００８６】
入力メッセージ生成部２０９は、例えばメインメモリの入力候補値を格納するエリアを参照して、登録アプリケーション仕様データ格納部２０３に格納されているデータ登録アプリケーションの仕様データにおける処理ロジック（図２１）から、入力候補値が未特定のデータ項目に関する条件データを取得する（ステップＳ１４１）。図２１の例では、図３１に示したような条件データが初期的には抽出され、図２６に示した逆仕様データで解釈すれば入力Ｍｓｇ．数量、入力Ｍｓｇ．商品ＩＤ、入力Ｍｓｇ．顧客ＩＤ、入力Ｍｓｇ．営業ＩＤが特定される。しかしながら、メインメモリの入力候補値を格納するエリアにおいてデータが既に登録されている入力Ｍｓｇ．数量は除外されるので、図３２に示すような条件データに絞り込まれる。
【００８７】
次に、入力メッセージ生成部２０９は、ステップＳ１４１で抽出された条件のうち未処理の条件を１つ特定する（ステップＳ１４３）。そして、特定された条件を満たす初期候補値を特定する（ステップＳ１４５）。この処理では、図２８で示した特定ルールに従う。すなわち、本ステップでは「条件を満たす値」の列のルールに従って初期候補値を特定する。例えば図３２の第１行目の条件「商品ＩＤ」の場合、論理演算「ＮＥ」であるから、初期候補値は特定できないことになる。
【００８８】
ここで入力メッセージ生成部２０９は、初期候補値を特定できたか判断する（ステップＳ１４７）。初期候補値が特定できなければ、ステップＳ１５１に移行する。一方、初期候補値が特定できた場合には、初期候補値を逆仕様データで解釈し、入力候補値を特定して、例えばメインメモリの入力候補値を格納するエリアに格納する（ステップＳ１４９）。
【００８９】
ステップＳ１４７で初期候補値を特定できないと判断された場合又はステップＳ１４９の後に、入力メッセージ生成部２０９は、特定された条件を満たさない初期候補値を特定する（ステップＳ１５１）。この処理では、図２８で示した特定ルールに従う。すなわち、本ステップでは「条件を満たさない値」の列のルールに従って初期候補値を特定する。例えば図３２の第１行目の条件「商品ＩＤ」の場合、論理演算「ＮＥ」であるから、初期候補値は「ｎｕｌｌ」ということになる。
【００９０】
ここで入力メッセージ生成部２０９は、ステップＳ１５１で初期候補値を特定できたか判断する（ステップＳ１５３）。初期候補値が特定できなければ、ステップＳ１５７に移行する。一方、初期候補値が特定できた場合には、初期候補値を逆仕様データで解釈し、入力候補値を特定して、例えばメインメモリの入力候補値を格納するエリアに格納する（ステップＳ１５５）。図３２の第１行目の条件「商品ＩＤ」の場合、図３３に示したように入力Ｍｓｇ．商品ＩＤに「ｎｕｌｌ」が登録される。
【００９１】
そして、入力メッセージ生成部２０９は、全ての条件について処理したか判断する（ステップＳ１５７）。未処理の条件が残っている場合には、ステップＳ１４３に戻る。全ての条件を処理した場合には、元の処理に戻る。
【００９２】
図３２の第２行目の条件「顧客ＩＤ」の場合、論理演算「ＥＱ」なので、ステップＳ１４５及びＳ１４９で図３４に示すように入力Ｍｓｇ．顧客ＩＤに「ｎｕｌｌ」が登録される。図３２の第３行目の条件「営業ＩＤ」の場合、論理演算「ＥＱ」なので、ステップＳ１４５及びＳ１４９で図３５に示すように入力Ｍｓｇ．営業ＩＤに「ｎｕｌｌ」が登録される。
【００９３】
図２３の処理の説明に戻って、入力メッセージ生成部２０９は、第２入力候補値抽出処理において入力候補値が抽出されたデータ項目について、入力代表値を入力候補値としてメインメモリの入力候補値を格納するエリアに追加格納する（ステップＳ１１１）。上で述べた例では、入力Ｍｓｇ．商品ＩＤ、入力Ｍｓｇ．顧客ＩＤ及び入力Ｍｓｇ．営業ＩＤが、第２入力候補値抽出処理において入力候補値が抽出されたデータ項目であり、図２５に示した入力代表値から、入力Ｍｓｇ．商品ＩＤについては「００１」及び「００２」、入力Ｍｓｇ．顧客ＩＤについては「Ｃ００１」、入力Ｍｓｇ．営業ＩＤについては「Ｓ００１」が抽出されて、図３６に示すようにそれぞれのエリアに追加格納される。
【００９４】
そして、入力メッセージ生成部２０９は、各データ項目についての入力候補値を例えば直交表やＡｌｌＰａｉｒ法などの周知の方法を用いて組み合わせ、入力メッセージを生成し、入力メッセージ格納部２１０に格納する（ステップＳ１１３）。例えば、図３７に示すような６つの入力メッセージが生成される。但し、ステップＳ１１３では、データ登録アプリケーション１５１の処理ロジックにおけるチェックを通るか否かについては考慮していないため、生成された入力メッセージが全て有効なものであるとは限らない。
【００９５】
そして、入力実行部２１１は、入力メッセージ格納部２１０から入力メッセージを読み出し、データ登録アプリケーション１５１に当該入力メッセージを出力して、ＤＢ１５２に登録するための処理を実施させる（ステップＳ１１５）。例えば図２２のような処理ロジックが適用されるため、図３７に示した入力メッセージのうち入力メッセージ２、５及び６は、エラーとなって、ＤＢ１５２には登録されない。従って、図３８に示すようなデータが、ＤＢ１５２の注文テーブルに登録されることになる。なお、伝票ＩＤについては、データ登録アプリケーション１５１において発行される。
【００９６】
その後、テストを実施するユーザのために、テストケース生成部２１３は、ＤＢ１５２に登録されているデータを基にテストケースのデータを生成し、テストケースデータ格納部２０２に格納する（ステップＳ１１７）。必要があれば、テストケースデータ格納部２０２に格納されているテストケースを、表示装置やプリンタなどの出力装置に出力するようにしても良い。上で述べた図２４の例では、伝票ＩＤは任意であったが、入力メッセージを入力した後のＤＢ１５２には、図３８に示すように伝票ＩＤが１乃至３のレコードが登録されているので、テストケース生成部２１３は、伝票ＩＤをそれぞれプライマリキーとして指定するテストケースに拡張する。具体的には、図３９に示すように、伝票ＩＤ＝１となるレコードについてのテストケース１０と、伝票ＩＤ＝２となるレコードについてのテストケース１０−２と、伝票ＩＤ＝３となるレコードについてのテストケース１０−３とを生成し、テストケースデータ格納部２０２に格納する。
【００９７】
以上のような処理を実施することによって、入力メッセージにバリエーションを与えることができるようになり、様々なケースについてテストを実施することができるようになるため、テスト漏れを防止し、手戻りを削減することによって、テストを効率化すると共に開発コストを削減することができるようになる。
【００９８】
［実施の形態３］
第２の実施の形態では、データ登録アプリケーション１５１の仕様データを用いて、入力候補値のバリエーションを増やすことを行ったが、本実施の形態では、さらにテスト対象アプリケーション１５３の仕様データを用いて入力候補値のバリエーションを増やすこととする。基本的な処理フローは図２３と同様であるが、ステップＳ１０９の後に、図４０に示すような処理を実施する。なお、ステップＳ１０５では、テスト対象アプリケーション１５３の逆仕様データをも生成する。
【００９９】
すなわち、入力メッセージ生成部２０９は、例えばメインメモリの入力候補値を格納するエリアを参照して、テスト対象アプリケーション仕様データ格納部２０４に格納されているテスト対象アプリケーション１５３の仕様データにおける処理ロジックから、第１入力候補値抽出処理で入力候補値が未特定のデータ項目に関する条件データを取得する（ステップＳ１６１）。例えば、ここでは図４１に示すように、入力Ｍｓｇ．顧客ＩＤについての条件が取得されるものとする。なお、図４２に示すようなテスト対象アプリケーション１５３の逆仕様データ（転記情報の逆仕様データ。図４２は模式図。）及び図２６に示すようなデータ登録アプリケーション１５１の逆仕様データを用いて、入力メッセージにおけるデータ項目との対応関係を特定する。
【０１００】
次に、入力メッセージ生成部２０９は、ステップＳ１６１で抽出された条件のうち未処理の条件を１つ特定する（ステップＳ１６３）。そして、特定された条件を満たす初期候補値を特定する（ステップＳ１６５）。この処理では、図２８で示した特定ルールに従う。すなわち、本ステップでは「条件を満たす値」の列のルールに従って初期候補値を特定する。例えば図４１の条件「顧客ＩＤ」の場合、論理演算「ＥＱ」であるから、初期候補値はＣ９９９となる。
【０１０１】
ここで入力メッセージ生成部２０９は、初期候補値を特定できたか判断する（ステップＳ１６７）。初期候補値が特定できなければ、ステップＳ１７１に移行する。一方、初期候補値が特定できた場合には、初期候補値をテスト対象アプリケーション１５３の逆仕様データ及びデータ登録アプリケーション１５１の逆仕様データで解釈し、入力候補値を特定して、例えばメインメモリの入力候補値を格納するエリアに格納する（ステップＳ１６９）。
【０１０２】
ステップＳ１６９の処理を模式的に書けば図４３のようになる。処理ロジックである「顧客ＩＤ＝”Ｃ９９９”は、テスト対象アプリケーション１５３である金額計算アプリケーション内の処理ロジックであるから、ＤＢ１５２内の注文テーブル内の対応するデータ項目は、テスト対象アプリケーション１５３の逆仕様データによって「注文テーブル．顧客ＩＤ」と特定される。さらに、ＤＢ１５２における注文テーブルのデータ項目「注文テーブル．顧客ＩＤ」からデータ登録アプリケーション１５１である注文受付アプリケーション内のデータ項目「顧客ＩＤ」に転記・変換するには、データ登録アプリケーション１５１の逆仕様データ（section name="dbcopy"部分）を用いる。さらに、データ登録アプリケーション１５１のデータ項目「顧客ＩＤ」から入力メッセージ内におけるデータ項目「入力Ｍｓｇ．顧客ＩＤ」に転記・変換するには、データ登録アプリケーション１５１の逆仕様データ（section name="msgcopy"部分）を用いる。そうすると、入力Ｍｓｇ．顧客ＩＤについて図４４に示すように”Ｃ９９９”が登録されるようになる。
【０１０３】
ステップＳ１６７で初期候補値を特定できないと判断された場合又はステップＳ１６９の後に、入力メッセージ生成部２０９は、特定された条件を満たさない初期候補値を特定する（ステップＳ１７１）。この処理では、図２８で示した特定ルールに従う。すなわち、本ステップでは「条件を満たさない値」の列のルールに従って初期候補値を特定する。例えば図４１の条件「顧客ＩＤ」の場合、論理演算「ＥＱ」であるから、初期候補値は「特定できない」ということになる。
【０１０４】
ここで入力メッセージ生成部２０９は、ステップＳ１７１で初期候補値を特定できたか判断する（ステップＳ１７３）。初期候補値が特定できなければ、ステップＳ１７７に移行する。一方、初期候補値が特定できた場合には、初期候補値をテスト対象アプリケーション１５３の逆仕様データ及びデータ登録アプリケーション１５１の逆仕様データで解釈し、入力候補値を特定して、例えばメインメモリの入力候補値を格納するエリアに格納する（ステップＳ１７５）。図４３で説明したとおりの処理である。
【０１０５】
そして、入力メッセージ生成部２０９は、全ての条件について処理したか判断する（ステップＳ１７７）。未処理の条件が残っている場合には、ステップＳ１６３に戻る。全ての条件を処理した場合には、元の処理に戻る。
【０１０６】
このような処理を追加で行うことによって、図４４で示すように、入力候補値のバリエーションを増やすことができ、さらに入力メッセージのバリエーションも増やすことができる。特に、テスト対象アプリケーション１５３の処理ロジックにおいて特別な取り扱いがなされると考えられる値を入力候補値に含めることによって、より漏れのないテストを実施できるようになる。
【０１０７】
［実施の形態４］
第３の実施の形態では、第２入力候補値抽出処理の後に入力代表値から入力候補値を生成するような例を示した。第４の実施の形態では、データ登録アプリケーション１５１の仕様データに含まれる転記情報を用いる。具体的には、図４５に模式的に示すような転記情報が別途存在する場合には、ＤＢ１５２における商品テーブルに登録済みのデータを入力候補値に用いることができる。図４６に模式的に示すように、入力メッセージ生成部２０９は、上記転記情報の逆仕様データを用いて、商品テーブルの商品コードの値を、入力Ｍｓｇ．商品ＩＤの入力候補値に変換して登録する。
【０１０８】
このようにすれば、他のテーブルで用いられている、すなわち整合性のとれているデータを用いて、入力候補値を豊富化して、入力メッセージのバリエーションを増加させることができるようになる。
【０１０９】
以上本発明の第２乃至４の実施の形態について説明したが、本発明はこれに限定されるものではない。例えば、図１９の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。
【０１１０】
また、図２及び図１９に示したテストデータ登録装置は、コンピュータ装置であって、図４７に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１１１】
［ＸＭＬ仕様記述法］
Ｗｅｂサーバ上で、データBean、HashMap（java.util.HashMap）、ＸＭＬデータBean（com.fujitsu.uji.xml.XmlDataBean）などのデータ項目について範囲のチェックやデータの転記、変換などの処理を実行する場合がある。ＸＭＬデータ仕様記述は、業務依存の仕様変更が多いデータ項目の転記処理やチェック処理を外付けのファイルにＸＭＬ形式で記述し、実行する機能である。仕様を外付けのファイルに記述することにより、仕様変更に対して、プログラムを変更することなく対応が可能になり、保守性の向上が期待できる。
【０１１２】
ＸＭＬデータ仕様記述を利用するシステムの概要を図４８に示す。
１）ＸＭＬデータ仕様記述
ユーザが、各データ項目について、データの範囲、文字列パターンのマッチングなどの仕様をＸＭＬ形式で記述する。使用できるデータ項目は、データBean、HashMap、ＸＭＬデータBeanのデータ項目である。実行時には、ＸＭＬファイルをインタープリタ機能を使用してそのまま実行したり、コンパイラ機能を使用してコンパイルして実行することが可能である。ＸＭＬファイルをそのまま実行することによって、データチェック仕様などの変更に対してプログラムを変更することなく対応することが可能である。
２）ＸＭＬデータ仕様記述コンパイラ
作成したＸＭＬデータ仕様記述を、Ｊａｖａ（登録商標）のクラスにコンパイルして使用することが可能である。ＸＭＬデータ仕様記述コンパイラは、ＸＭＬデータ仕様記述から、Ｊａｖａソースファイルを出力する。アプリケーション実行時にＸＭＬを解析する必要がなくなるため、ＸＭＬファイルをそのまま使用する場合に比べて実行性能が向上する。
３）ＸＭＬデータ仕様記述実行系
作成したＸＭＬデータ仕様記述を実行する。入力として、データBean、HashMap、ＸＭＬデータBeanを使用できる。入力に指定したオブジェクトのデータ項目を参照、更新すること、出力先のオブジェクトのデータ項目を更新することが可能である。
【０１１３】
ＸＭＬデータ仕様記述の概要を図４９に示す。各要素の概要は以下のとおりである。
・config要素 
ＸＭＬデータ仕様記述の情報を指定する。
・specification要素 
処理の単位を示す。ＸＭＬデータ仕様記述実行時には、この要素のnameアトリビュートで指定された名前を使用して処理を呼び出す。
・control要素 
チェックの順番およびチェック対象のオブジェクトを指定する。この中に記述したvalidate要素の順番で処理が実行される。 
・validate要素 
この要素のsectionアトリビュートで、実行するsection要素を指定する。
・section要素 
一連の処理の実行単位を示す。
・block要素
条件の判定の範囲を指定する。
・term要素
条件および条件が真の場合に行う動作を指定する。
・verify要素
条件および条件が偽の場合に行う動作を指定する。
・decision要素
value要素で保存された条件の組が真の場合に行う動作を指定する。
・status要素
decision要素の判定条件を示す。
【０１１４】
次に、図５０にＸＭＬデータ仕様定義の記述例を示し、その動作の概要を説明する。
・specification name="checkValue"のタグを呼び出した場合
１．controlタグに指定されているvalidateタグを順に実行する。例では、check1, check2の順に該当するsectionタグを呼び出す。
２．controlタグから最初に呼び出されたsection name="check1"のタグは、value項目の値が０乃至１００のデータであるか否かをチェックする。
３．チェック結果、value項目の値が０乃至１００のデータの場合には、「valueは０乃至１００の間です」の文字列を持つESpecResultExceptionの例外を発生させる。
４．check1で例外にならない場合には、section name="check2"のタグがcontrolタグから呼び出される。 
５．section name="check2"のタグは、データ項目textの値がnullまたは空文字列をチェックする。
６．チェック結果、text項目の値がnullまたは空文字列の場合には、「値が設定されていません」の文字列を持つESpecResultExceptionの例外を発生させる。
７．check2で例外にならない場合には、正常終了する。
・specification name="copyValue"のタグを呼び出した場合
１．controlタグに指定されているvalidateタグを実行する。 例では、arrayData の配列要素、t_arrayData の配列要素に対してcopyセクションを要素数の数だけ実行する。
２．controlタグから呼び出されたsection name="copy"のタグは、データ項目"value" が０でないとき、"t_value" にコピーする。
３．要素数の数だけcopyセクションを実行後正常終了する。
【０１１５】
次に、使用できるオブジェクト式と演算子について説明する。以下のＸＭＬ記述で、term要素のpropertyアトリビュートやoperandアトリビュートにはオブジェクト式が記述できる。
＜term property="value" op="LE" operand="100" exception="#valueは0と100の間"/＞
記述できるオブジェクト式の一覧を図５１に示す。
【０１１６】
また、opアトリビュートには、論理演算子または算術演算子が指定できる。指定できる演算子を図５２に示す。
【０１１７】
さらに、以下のＸＭＬ記述でvalue要素のfunctionアトリビュートにはpropertyに適用するメソッドを記述できる。
＜value seq="2" property="text" function="stringLength" op="EQ" operand="0"/＞
記述できるメソッドを図５３に示す。
【０１１８】
また、正規表現では図５４の記法が使用できる。
【０１１９】
さらに、利用者メソッドの定義方法は以下のとおりである。
【０１２０】
ＸＭＬデータ仕様記述ではstaticメソッドおよびESpecValidatorクラスを継承したクラスのメソッドを利用者メソッドとして使用することができる。利用者メソッドの定義方法を以下に説明する。
・staticメソッドを使用する
ＸＭＬデータ仕様記述では、staticメソッドを呼び出すことができる。呼び出し方法は、functionアトリビュート、またはvalueFunctionアトリビュートへ「パッケージ名.クラス名.メソッド名」の形式で指定する。例を以下に示す。
ＸＭＬデータ仕様記述例
＜term property="#abc" function="some_package.some_class.some_function" /＞
利用者メソッド例
package some_package; class some_class { static void some_function(String arg1) { ... } }
・ESpecValidatorクラスを継承したクラスのメソッドを使用する
ESpecValidatorクラスを継承し、そのクラスのメソッドを呼び出す例を以下に示す。
ＸＭＬデータ仕様記述例
＜term property="#abc" function="some_function" /＞
利用者メソッド例
class SomeClass extends EspecValidator {    void some_function(String arg1) {       ...    }} 
パラメタは以下の形式で定義する。
・任意の型 some_function(任意の型 ,...); 
任意の型への型合わせは自動的に行われるが、型を合わせることができない場合には例外になる。
・任意の型 some_function(Object []args); 
パラメタは、Object型の配列で渡される。
【０１２１】
複数のパラメタをユーザ定義メソッドへ渡す例を以下に示す。propertyアトリビュートに複数のオブジェクトをカンマで区切って記述すると順に利用者定義メソッドのパラメタと対応づけて呼び出される。以下の例では、some_functionには、param1には数値の1、param2には文字列のabc、param3には数値の2が渡される。
ＸＭＬデータ仕様記述例
＜term property="1,#abc,2" function="some_function" /＞
利用者メソッド例
void some_function(int param1, String param2, int param3) {   ...}
【０１２２】
（付記１）
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録するプログラムであって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成ステップと、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させる入力ステップと、
を含み、コンピュータに実行されるテストデータ登録プログラム。
【０１２３】
（付記２）
前記生成ステップが、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータに従って前記データ登録アプリケーションに対する初期入力候補値を生成する初期入力候補値生成ステップと、
前記データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、前記初期入力候補値から前記入力候補値を生成する入力候補値生成ステップと、
を含む付記１記載のテストデータ登録プログラム。
【０１２４】
（付記３）
前記初期入力候補値生成ステップ及び前記入力候補値生成ステップが、前記テストの条件に関するデータが規定されているデータ項目について実施される
付記２記載のテストデータ登録プログラム。
【０１２５】
（付記４）
前記初期入力候補値生成ステップが、
前記テストの条件に関するデータから直接前記初期入力候補値を特定できない場合には、入力代表値データ格納部に格納されている入力代表値を前記初期入力候補値として特定するステップ
を含む付記２記載のテストデータ登録プログラム。
【０１２６】
（付記５）
前記生成ステップが、
前記テストの条件に関するデータが規定されていないデータ項目について、入力代表値データ格納部に格納されている入力代表値を入力候補値として特定するステップ
を含む付記１記載のテストデータ登録プログラム。
【０１２７】
（付記６）
前記データ登録アプリケーションの仕様データから、前記データ登録アプリケーションの逆処理を規定する逆仕様データを生成する逆仕様データ生成ステップ
をさらに含む付記１記載のテストデータ登録プログラム。
【０１２８】
（付記７）
前記逆仕様データ生成ステップが、
前記データ登録アプリケーションの仕様データ内のデータ入力又はデータチェックにおける演算を逆演算に変更するステップと、
前記データ登録アプリケーションの仕様データ内のデータ入力又はデータチェックにおける入力項目と出力項目を入れ替えるステップと、
を含む付記６記載のテストデータ登録プログラム。
【０１２９】
（付記８）
前記データ登録アプリケーションが第２のデータベースを参照する場合、前記第２のデータベースにデータを登録するために前記生成ステップ以降を前記第２のデータベースにデータを登録するための第２のデータ登録アプリケーションに対して実行する
付記１記載のテストデータ登録プログラム。
【０１３０】
（付記９）
前記生成ステップが、
前記テストの条件に関するデータから前記初期入力候補値を特定できないデータ項目について、データ登録アプリケーション仕様データ格納部に格納された、前記データ登録アプリケーションの仕様データに含まれる処理ロジックから、前記データ登録アプリケーションに対する第２の初期入力候補値を生成するステップと、
前記データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、前記第２の初期入力候補値から前記入力候補値を生成するステップと、
をさらに含む付記２記載のテストデータ登録プログラム。
【０１３１】
（付記１０）
前記入力ステップが、
各データ項目の前記入力候補値を組み合わせて複数の入力メッセージを生成するステップ
を含む付記９記載のテストデータ登録プログラム。
【０１３２】
（付記１１）
前記生成ステップが、
前記テストの条件に関するデータから前記初期入力候補値を特定できないデータ項目について、仕様データ格納部に格納された、前記アプリケーションの仕様データに含まれる処理ロジックから、前記データ登録アプリケーションに対する第３の初期入力候補値を生成するステップと、
前記アプリケーションの逆処理を規定する第２の逆仕様データ及び前記データ登録アプリケーションの逆処理を規定する逆仕様データを用いて、前記第３の初期入力候補値から前記入力候補値を生成するステップと、
をさらに含む付記２記載のテストデータ登録プログラム。
【０１３３】
（付記１２）
前記データベースに既登録のデータから前記入力候補値を抽出するステップ
をさらにコンピュータに実行させるための付記１記載のテストデータ登録プログラム。
【０１３４】
（付記１３）
前記入力ステップによって前記データベースに登録されたレコード及び前記テストに関するデータから、前記テストの条件に関する新たなデータを生成するステップ
をさらにコンピュータに実行させるための付記１記載のテストデータ登録プログラム。
【０１３５】
（付記１４）
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるための方法であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成ステップと、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させるステップと、
を含み、コンピュータに実行されるテストデータ登録方法。
【０１３６】
（付記１５）
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるためのテストデータ登録装置であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納する手段と、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する入力候補値を生成し、記憶装置に格納する生成手段と、
前記記憶装置に格納された前記入力候補値を前記データ登録アプリケーションに入力して、前記データベースに対する登録処理を実施させる手段と、
を有するテストデータ登録装置。
【０１３７】
（付記１６）
データベースを利用するアプリケーションのテストに用いるデータをデータ登録アプリケーションを用いて前記データベースに登録させるための方法であって、
前記テストの条件に関するデータを取得し、テスト条件データ格納部に格納するステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションが利用する第２のデータベースにデータを登録するための第２のデータ登録アプリケーションの仕様データから特定され且つ前記第２のデータ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記第２のデータ登録アプリケーションに対する第１入力候補値を生成し、記憶装置に格納するステップと、
前記記憶装置に格納された前記第１入力候補値を前記第２のデータ登録アプリケーションに入力して、前記第２のデータベースに対する登録処理を実施させるステップと、
前記テスト条件データ格納部に格納された前記テストの条件に関するデータ、及び前記データ登録アプリケーションの仕様データから特定され且つ前記データ登録アプリケーションの逆処理を規定する逆仕様データに基づき、前記データ登録アプリケーションに対する第２入力候補値を生成し、前記記憶装置に格納するステップと、
前記記憶装置に格納された前記第２入力候補値を前記データ登録アプリケーションに入力して、前記第２のデータベースを利用した、前記データベースに対する登録処理を実施させるステップと、
を含み、コンピュータに実行されるテストデータ登録方法。
【図面の簡単な説明】
【０１３８】
【図１】本発明の第１の実施の形態の前提となるシステム概要を示す図である。
【図２】本発明の第１の実施の形態に係るシステムの機能ブロック図である。
【図３】登録アプリケーションのＸＭＬ仕様記述の一例を示す図である。
【図４】登録アプリケーションの逆処理のＸＭＬ仕様記述の一例を示す図である。
【図５】テスト対象アプリケーションのＸＭＬ仕様記述の一例を示す図である。
【図６】本発明の実施の形態におけるメインの処理フローを示す図である。
【図７】テスト番号１のテストケースデータを示す図である。
【図８】テスト番号２のテストケースデータを示す図である。
【図９】入力代表値の一例を示す図である。
【図１０】本発明の実施の形態におけるメインの処理フローの第２の部分を示す図である。
【図１１】入力メッセージの一例を示す図である。
【図１２】ＤＢに登録されるデータの一例を示す図である。
【図１３】必要なＤＢが複数の場合の例を示す図である。
【図１４】逆仕様データ生成処理の処理フローを示す図である。
【図１５】Section内処理の処理フローを示す図である。
【図１６】Section内処理の処理フローの第２の部分を示す図である。
【図１７】本発明の第２の実施の形態の前提となるシステム概要を示す図である。
【図１８】（ａ）は注文テーブルの一例を、（ｂ）は金額テーブルの一例を示す図である。
【図１９】本発明の第２乃至第４の実施の形態に係るシステムの機能ブロック図である。
【図２０】データ登録アプリケーションの仕様データ（転記情報）の一例を示す図である。
【図２１】データ登録アプリケーションの仕様データ（処理ロジック）の一例を示す図である。
【図２２】データ登録アプリケーションの仕様データにおける処理ロジックの模式図である。
【図２３】本発明の第２の実施の形態におけるメインの処理フローを示す図である。
【図２４】テストケースデータの一例を示す図である。
【図２５】入力代表値の一例を示す図である。
【図２６】逆仕様データの一例を示す図である。
【図２７】第１入力候補値抽出処理の処理フローを示す図である。
【図２８】処理ロジックなどから初期候補値を特定するためのルールを示す図である。
【図２９】第１入力候補値抽出処理の処理結果の一例を示す図である。
【図３０】第２入力候補値抽出処理の処理フローを示す図である。
【図３１】第２入力候補値抽出処理で初期的に抽出される処理ロジックの例を示す図である。
【図３２】第２入力候補値抽出処理で抽出される処理ロジックの例を示す図である。
【図３３】第２入力候補値抽出処理の第１段階の処理結果を示す図である。
【図３４】第２入力候補値抽出処理の第２段階の処理結果を示す図である。
【図３５】第２入力候補値抽出処理の第３段階の処理結果を示す図である。
【図３６】入力代表値を用いて入力候補値を特定した際の処理結果を示す図である。
【図３７】生成された入力メッセージのバリエーションを示す図である。
【図３８】注文テーブルに登録されるデータの一例を示す図である。
【図３９】第２の実施の形態において拡張されたテストケースの一例を示す図である。
【図４０】第３入力候補値抽出処理の処理フローを示す図である。
【図４１】テスト対象アプリケーションの処理ロジックの模式図である。
【図４２】テスト対象アプリケーションの逆仕様データの模式図である。
【図４３】本発明の第３の実施の形態の処理を模式的に示す図である。
【図４４】本発明の第３の実施の形態の処理結果である入力候補値のバリエーションを示す図である。
【図４５】本発明の第４の実施の形態を説明するための転記情報の模式図である。
【図４６】本発明の第４の実施の形態を説明するための模式図である。
【図４７】コンピュータの機能ブロック図である。
【図４８】ＸＭＬデータ仕様記述を利用するシステムの概要を示す図である。
【図４９】ＸＭＬデータ仕様記述の構成を示す図である。
【図５０】ＸＭＬデータ仕様記述の一例を示す図である。
【図５１】記述できるオブジェクト式の一覧を示す図である。
【図５２】ｏｐアトリビュートで指定できる演算子の一覧を示す図である。
【図５３】value要素のfunctionアトリビュートのpropertyに適用するメソッドの一覧を示す図である。
【図５４】正規表現の記法を示す図である。
【符号の説明】
【０１３９】
１  テストケース入力部    ３  テストケースデータ格納部
５  登録アプリケーション仕様データ格納部
７  仕様リバース部    ９  逆仕様データ格納部
１１  入力代表値入力部    １３  入力代表値格納部
１５  入力メッセージ生成部    １７  入力メッセージ格納部
１９  入力実行部
【図１】
2008176760.tif 000003
【図２】
2008176760.tif 000004
【図３】
2008176760.tif 000005
【図４】
2008176760.tif 000006
【図５】
2008176760.tif 000007
【図６】
2008176760.tif 000008
【図７】
2008176760.tif 000009
【図８】
2008176760.tif 000010
【図９】
2008176760.tif 000011
【図１０】
2008176760.tif 000012
【図１１】
2008176760.tif 000013
【図１２】
2008176760.tif 000014
【図１３】
2008176760.tif 000015
【図１４】
2008176760.tif 000016
【図１５】
2008176760.tif 000017
【図１６】
2008176760.tif 000018
【図１７】
2008176760.tif 000019
【図１８】
2008176760.tif 000020
【図１９】
2008176760.tif 000021
【図２０】
2008176760.tif 000022
【図２１】
2008176760.tif 000023
【図２２】
2008176760.tif 000024
【図２３】
2008176760.tif 000025
【図２４】
2008176760.tif 000026
【図２５】
2008176760.tif 000027
【図２６】
2008176760.tif 000028
【図２７】
2008176760.tif 000029
【図２８】
2008176760.tif 000030
【図２９】
2008176760.tif 000031
【図３０】
2008176760.tif 000032
【図３１】
2008176760.tif 000033
【図３２】
2008176760.tif 000034
【図３３】
2008176760.tif 000035
【図３４】
2008176760.tif 000036
【図３５】
2008176760.tif 000037
【図３６】
2008176760.tif 000038
【図３７】
2008176760.tif 000039
【図３８】
2008176760.tif 000040
【図３９】
2008176760.tif 000041
【図４０】
2008176760.tif 000042
【図４１】
2008176760.tif 000043
【図４２】
2008176760.tif 000044
【図４３】
2008176760.tif 000045
【図４４】
2008176760.tif 000046
【図４５】
2008176760.tif 000047
【図４６】
2008176760.tif 000048
【図４７】
2008176760.tif 000049
【図４８】
2008176760.tif 000050
【図４９】
2008176760.tif 000051
【図５０】
2008176760.tif 000052
【図５１】
2008176760.tif 000053
【図５２】
2008176760.tif 000054
【図５３】
2008176760.tif 000055
【図５４】
2008176760.tif 000056