JP2018112919A - テスト入力情報検索装置及び方法 - Google Patents

Abstract

【課題】データベースと画面を有する計算機システムのテストシナリオの作成において、テスト入力値の作成の効率化を支援し、テスト入力の候補となるデータベースレコードと整合する要素を検索する装置を提供する。
【解決手段】テスト入力情報検索装置１６において、記憶装置１５は、第１の構造で構成された複数の要素が含まれるデータベースの情報１０１と、第２の構造で構成されて表示される複数の要素を含む画面情報１０２を記憶する。計算機１２において、画面グラフ情報生成処理部１７１は、第２の構造から画面情報に含まれる複数の要素の中の要素間の関係を特定し、画面グラフ情報１５２を出力する。グラフ伝搬処理部１７２は、要素間の関係に情報を追加し検索グラフ情報１５３を出力する。候補レコード群検索処理部１７３は、特定された要素間の関係に基づいて、データベースの情報から複数の要素を、テスト入力のための候補として検索する。
【選択図】図１

Description

本発明は、テスト入力情報検索装置及び方法に関する。

画面とデータベースを有する大規模な計算機システムのプログラム開発においては、開発者が画面を操作することにより、計算機システムを利用する人の要求を計算機システムが満たしていることを確認するテストが必要である。テストを実行する際には、テストを実行する開発者は画面上の入力欄に文字列や数値などの値を入力し、画面上のボタンやリンクなどをクリックして計算機システムを操作する。

文字列や数値を入力する際には、テストの目的に沿った入力をし、期待どおりに計算機システムが動いているかを確認する。例えば、文字列を入力し、その文字列を含む住所の一覧を表示するような計算機システムにおいて、画面上に一定件数を超える住所を表示できるかをテストしたい場合には、開発者は一定件数の住所に含まれる文字列を入力しなければならない。あるいは、対応する住所がない場合にエラーメッセージが表示されるかを確認したい場合は、開発者はどの住所にも含まれない文字列を入力しなければならない。

テスト時の情報を管理し再現可能にしたい場合に、開発者は、テストに利用する入力値をテストの流れを表すドキュメントであるテストシナリオに明確に記さなければならない。更に、開発者は、テスト時に利用するデータベースにも、確認したい目的に応じた情報を格納しなければならない。前述の例では、同じ文字列を有する住所が一定件数はデータベースに存在し、また別の特定の文字列の住所だけがデータベースに存在してはならない。すなわち、開発者は画面入力値とデータベースを整合させなければならない。

一方で、テストに利用するデータベースレコードを、テストのために開発者が一から作ると工数がかかる。このため、開発者が実運用の計算機システムで利用するデータベースレコードを取得し、顧客情報をマスキングして利用したり、昔から利用しているテスト用のデータベースレコードを繰返し改変しながら利用し続けたりする。

他方で、画面を操作するテストのシナリオを作る開発者は、画面の仕様や、画面が満たすべき業務の要件に詳しくても、データベースにまで詳しいとは限らない。データベースレコードを一から作っているのではない場合、既存のデータベースの設計とそのレコードについて調査、理解しなければならず、時間がかかる。このため、データベースに詳しくない開発者でもデータベースの値と整合するテスト入力を作成可能とするための仕掛けが必要となる。

このようなテストに関連して特許文献１には、ソースコードのロジックをあらわす設計情報からテストケースを生成し、テストケースから生成した制約式をもとにデータベースレコードを作成する技術が開示されている。具体的には、コードのロジックを表す設計情報からテストケースを生成し、テストケースから生成した制約式をもとにデータベースレコードを生成する技術が開示されている。

特許第５５２３５２６号

特許文献１に開示された技術では、データベースレコードを作成するために設計情報を必要とする。しかしながら、開発者がプログラムの構造に詳しくない場合、ソースコードがない場合、複数のプログラミング言語からソースコードが構成される場合、あるいはソースコードの規模が大きく複雑である場合には設計情報を作成するのに工数がかかるため、設計情報を作成することは困難である。

これに対しては、設計情報や新たなデータベースレコードを作成することなく、既に存在するデータベースレコードと、そのデータベースに関する画面の情報とを利用し、データベースと整合する入力値としての要素をデータベースから見つけ出すことも考えられる。

本発明の目的は、データベースと画面を有する計算機システムのテストシナリオの作成において、テスト入力値の作成の効率化を支援するため、テスト入力の候補となるデータベースレコードと整合する要素を検索することにある。

本発明に係る代表的なテスト入力情報検索装置は、データベースのテスト入力のための候補を検索するテスト入力情報検索装置であって、第１の構造で構成された複数の要素が含まれる前記データベースの情報を記憶し、第２の構造で構成されて表示される前記複数の要素を含む画面情報を記憶し、前記画面情報に含まれる前記複数の要素の中の要素間の関係を、前記第２の構造から特定し、特定された要素間の関係に基づいて、前記データベースの情報から前記複数の要素を、テスト入力のための候補として検索することを特徴とする。

本発明によれば、データベースと画面を有する計算機システムのテストシナリオの作成において、テスト入力値の作成の効率化を支援するため、テスト入力の候補となるデータベースレコードと整合する要素を検索することが可能になる。

テスト入力情報検索装置の例を示す図である。 「ＢＵＹ」のテーブルの例を示す図である。 「ＩＴＥＭ」のテーブルの例を示す図である。 「ＰＲＤ」のテーブルの例を示す図である。 「ＡＣＣ」のテーブルの例を示す図である。 「ＰＡＹ」のテーブルの例を示す図である。 画面情報の例を示す図である。 テーブル種類情報の例を示す図である。 画面グラフ情報の例を示す図である。 検索グラフ情報の例を示す図である。 候補レコード群情報の例を示す図である。 テストシナリオ条件情報の例を示す図である。 条件対応候補レコード群情報の例を示す図である。 出力装置の第１の画面の例を示す図である。 出力装置の第２の画面の例を示す図である。 画面グラフ情報生成処理部の処理の例を示すフローチャートである。 グラフ伝搬処理部の処理の例を示すフローチャートである。 候補レコード群検索処理部の処理の例を示すフローチャートである。 結果出力処理部の処理の例を示すフローチャートである。

以下、図1〜１５を用いて、本発明を実施するための形態を説明する。この形態は、例えば、データベースと画面を有する情報システムのテストシナリオを作成する際に、データベースレコードと整合する画面入力値の作成の効率化を支援する、テスト入力情報検索装置あるいは計算機で実行されるテスト入力情報検索方法である。

図１は、テスト入力情報検索装置の例を示す図である。図１に示す計算機１は、データベースと画面を有する情報システムであって図示を省略した情報システムのテストシナリオを作成する際に、データベースレコードと整合する画面入力値の作成の効率化を支援するためのテスト入力情報検索装置１６を構成するものである。

以下、計算機１の構成の例を説明する。計算機１は、ＣＰＵ１１とメモリ１２を有する。ＣＰＵ１１とメモリ１２は、入力装置１３と出力装置１４に接続する。また、ＣＰＵ１１とメモリ１２は、記憶装置１５に接続する。

記憶装置１５は、テスト対象の情報システムが利用するデータベース情報１０１と、テスト対象の情報システムの画面情報１０２を保持する。なお、図１の例で、記憶装置１５は計算機１の内部に存在するが、計算機１の外部に存在してもよいし、テスト入力情報検索装置１６の内部に記憶装置１５は存在せず、テスト対象の情報システムに接続してデータベース情報１０１と画面情報１０２を直接に取得する構成であってもよい。

更に、メモリ１２は、テーブル種類情報１５１と、画面グラフ情報１５２と、検索グラフ情報１５３と、候補レコード群情報１５４と、テストシナリオ条件情報１５５と、条件対応候補レコード群情報１５６と、画面グラフ情報生成処理部１７１と、グラフ伝搬処理部１７２と、候補レコード群検索処理部１７３と、結果出力処理部１７４と、を保持する。ここで、メモリ１２に保持される各部はプログラムであってもよく、各部に対応するプログラムをＣＰＵ１１が実行することにより、ハードウェアとしての各部となってもよい。

記憶装置１５に保持されるデータベース情報１０１は、テストシナリオを作る対象となる情報システムで用いられるレコードを示す情報である。画面情報１０２は、テストシナリオを作る対象となる情報システムで用いられる画面を示す情報である。これらについては、図２〜３を用いて後で更に説明する。

メモリ１２に保持されるテーブル種類情報１５１は、データベース情報１０１に含まれるテーブルの種類を示す情報である。画面グラフ情報１５２は、画面情報１０２に含まれる要素とその関連情報を示す情報である。検索グラフ情報１５３は、データベース情報１０１より画面に対応する候補レコード群を検索するための情報である。

候補レコード群情報１５４は、画面に対応する候補レコード群を保持する情報である。
テストシナリオ条件情報１５５は、候補レコード群情報１５４を用い特定のテスト条件に合ったレコード群を示すための条件を保持する情報である。条件対応候補レコード群情報１５６は、画面と条件に対応する候補レコード群を保持する情報である。

画面グラフ情報生成処理部１７１は、画面情報１０２を読み込み、画面情報１０２の要素に要素間の関係（エッジ）を追加し、画面グラフ情報１５２を出力するためのものである。グラフ伝搬処理部１７２は、画面グラフ情報１５２を読み込み、画面グラフ情報１５２の要素間の関係に情報を追加し検索グラフ情報１５３を出力する。

候補レコード群検索処理部１７３は、本実施の形態の特徴の一つである。候補レコード群検索処理部１７３は、データベース情報１０１と、テーブル種類情報１５１と、検索グラフ情報１５３とを読み込み、優先順位をつけて検索し、候補レコード群情報１５４と条件対応候補レコード群情報１５６を出力する。

以上により、画面上に表示される要素の値と、要素の種類と、要素間の関係を基に、検索に用いるグラフ情報を作成し、画面上に表示される要素の値の元となっているデータベースレコードの候補を検索し、出力装置に表示することができる。更に、作成したいテストシナリオの条件を受け付け、その条件に合うデータベースレコードを画面に表示することができる。従って、テスト対象の情報システムが利用するデータベースの設計、データベースレコード及びプログラムに詳しくない開発者によるテストシナリオ作成作業を容易化できる。

結果出力処理部１７４は、候補レコード群情報１５４と、条件対応候補レコード群情報１５６とを読み込み、出力装置１４に表示する。

図２Ａ〜２Ｅは、データベース情報１０１の例を示す図である。図２Ａ〜２Ｅに示したテーブル１０１０〜１０１４は、テストシナリオを作る対象となる情報システムで用いられるレコードを保持する。以下、図２Ａに示したテーブル１０１０は、テーブル名「ＢＵＹ」とし、「発注情報」という名称で特定される情報を表すレコードを保持するテーブルとする。また、図２Ｂに示したテーブル１０１１は、テーブル名「ＩＴＥＭ」とし、「発注細目情報」という名称で特定される情報を表すレコードを保持するテーブルとする。

また、図２Ｃに示したテーブル１０１２は、テーブル名「ＰＲＤ」とし、「商品情報」という名称で特定される情報を表すレコードを保持するテーブルとする。また、図２Ｄに示したテーブル１０１３は、テーブル名「ＡＣＣ」とし、「担当者情報」という名称で特定される情報を表すレコードを保持するテーブルとする。また、図２Ｅに示したテーブル１０１４は、テーブル名「ＰＡＹ」とし、「支払情報」という名称で特定される情報を表すレコードを保持するテーブルとする。

以下、それぞれのテーブルのカラムとレコードを説明する。図２Ａに示したテーブル１０１０はカラムとして、ＢＵＹ＿ＩＤ１０１００１と、ＰＡＹＭ１０１００２と、ＡＣＣ１０１００３と、ＬＩＭＩＴ１０１００４と、ＣＨＡＲＧＥ１０１００５と、ＳＵＭＭＡＲＹ１０１００６と、ＮＯＴＥ１０１００７とを有する。

これらのカラムの中で、ＢＵＹ＿ＩＤ１０１００１は主キーであり、ＰＡＹＭ１０１００２はテーブル１０１４のＰＡＹ＿ＩＤ１０１４０１を参照する外部キーであり、ＡＣＣ１０１００３はテーブル１０１３のＡＣ＿ＩＤ１０１３０１を参照する外部キーである。図２Ａ〜２Ｅに示したテーブルのカラム名において、「＊」は主キーであることを表し、「＃」は外部キーであることを表す。以下、主キーについて、ある値を有するレコードの、主キーとなるカラムの値を「主キー値」と呼ぶ。例えば、カラム１０１００７の値「前回の発注と個数が異なるため注意してください。」の主キー値はカラム１０１００１の値「ＢＵＹ０００１」となる。

テーブル１０１０はレコード１０１０５１とレコード１０１０５２とを有する。レコード１０１０５１は、ＢＵＹ_ＩＤ１０１００１の値が「ＢＵＹ０００１」であるレコードにおいて、ＰＡＹＭ１０１００２の値は「１」であり、ＡＣＣ１０１００３の値は「Ａ１０１」であり、ＬＩＭＩＴ１０１００４の値は「２０１６／６／１」であり、ＣＨＡＲＧＥ１０１００５の値は「５００」であり、ＳＵＭＭＡＲＹ１０１００６の値は「１２５００」であり、ＮＯＴＥ１０１００７の値は「前回の発注と個数が異なるため注意してください。」であることを示す。

レコード１０１０５２もそれぞれのカラムに対して図２Ａに示した値を有する。テーブル１０１０のレコードは、レコード１０１０５１とレコード１０１０５２に限定されるものではなく、更にレコードを含んでもよい。これを図２Ａでは波線で表現し、以下の図２Ｂ〜２Ｄにおいても波線で表現する。

図２Ｂに示したテーブル１０１１はカラムとして、ＩＴＥＭ＿ＩＤ１０１１０１と、ＢＵＹ＿ＩＤ１０１１０２と、ＰＲＤ＿ＩＤ１０１１０３と、ＰＲＩＣＥ１０１１０４と、ＮＵＭ１０１１０５とを有する。これらのカラムの中で、ＩＴＥＭ＿ＩＤ１０１１０１は主キーであり、ＢＵＹ＿ＩＤ１０１１０２はテーブル１０１０のＢＵＹ＿ＩＤ１０１００１を参照する外部キーであり、ＰＲＤ＿ＩＤ１０１１０３はテーブル１０１２のＰＲＤ＿ＩＤ１０１２０１を参照する外部キーである。また、テーブル１０１１はレコード１０１１５１〜１０１１５４を有する。

図２Ｃに示したテーブル１０１２はカラムとして、ＰＲＤ＿ＩＤ１０１２０１と、ＰＲＤ＿ＮＡＭＥ１０１２０２とを有する。これらのカラムの中で、ＰＲＤ＿ＩＤ１０１２０１は主キーである。また、テーブル１０１２はレコード１０１２５１〜１０１２５４を有する。

図２Ｄに示したテーブル１０１３はカラムとして、ＡＣ＿ＩＤ１０１３０１と、ＡＣ＿ＮＡＭＥ１０１３０２とを有する。これらのカラムの中で、ＡＣ＿ＩＤ１０１３０１は主キーである。また、テーブル１０１３はレコード１０１３５１〜１０１３５４を有する。

図２Ｅに示したテーブル１０１４はカラムとして、ＰＡＹ＿ＩＤ１０１４０１と、ＰＡＹ＿ＮＡＭＥ１０１４０２とを有する。これらのカラムの中で、ＰＡＹ＿ＩＤ１０１４０１は主キーである。また、テーブル１０１４はレコード１０１４５１〜１０１４５３を有する。

図３は、画面情報１０２の例を示す図である。図３に示した画面情報１０２の情報１０２０に対応した出力装置１４の表示の例を、後ほど図１０を用いて説明する。図３の例で画面情報１０２は、画面への要素（画面要素）の表示に関する指示であるタグと、タグの属性（ｃｌａｓｓ）と、文字列から成るＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式を用いている。ＨＴＭＬ形式の情報は各要素の表示位置の情報も含む。文字列１０２０００は、「田中太郎」という文字列である。このように画面に表示される文字列や値が画面要素である。

タグ１０２００１は、出力装置１４の画面にリストの項目として「２０１６／０６／０１」を表示させるための指示である。タグ１０２０２２は「扇風機Ａ」をテーブルのセルとするための指示であり、属性１０２０２１すなわち「ｐｒｏｄｕｃｔ」という属性を有する。タグ１０２０２４、１０２０２６、１０２０３２、１０２０３４、１０２０３６も同じくそれぞれをテーブルのセルとするための指示であり、属性１０２０２３、１０２０２５、１０２０３１、１０２０３３、１０２０３５も同じくそれぞれの属性を有する。

タグ１０２０４２は、出力装置１４の画面に文字列「配送費： ５００円」を表示させるための指示であり、属性１０２０４１すなわち「ｃｈａｒｇｅ」という属性を有する。タグ１０２０４４も表示させるための指示であり、属性１０２０４３の属性を有する。タグ１０２０５１は文字列「支払方法： 銀行振込」を出力装置１４の画面にリストの項目として出力させるための指示であり、タグ１０２０６１も出力させるための指示である。なお、図３において画面情報１０２の情報１０２０をＨＴＭＬ形式で表したが、情報１０２０は要素と要素間の関係（画面要素間の表示位置関係等）を情報として持つ他の形式であってもよい。

図４は、テーブル種類情報１５１の例を示す図である。テーブル種類情報１５１のテーブル１５１０はカラムとして、テーブル名１５１００１とテーブル種類１５１００２とを有する。テーブル名１５１００１は、データベース情報１０１のテーブル１０１０〜１０１４のテーブル名を含むカラムである。

テーブル種類１５１００２は、テーブル名１５１００１に示されるテーブルが、情報システムが実現する業務のための処理において読み込み専用の台帳として利用され通常変更されることのないマスタであることを示す「マスタ」であるか、または、情報システムが実現する業務のための処理において取引等の業務により作成され、また蓄積されていくトランザクション情報を保存する「トラン」であるか、いずれかの種類を有する。

図４の例では、テーブル１５１０はレコード１５１０５１〜１５１０５４を有する。そして、レコード１５１０５１は、テーブル名１５１００１が「ＢＵＹ」であるレコードにおいて、テーブル種類１５１００２が「トラン」であることを示す。すなわち、テーブル名が「ＢＵＹ」であるテーブル１０１０が保持する「発注情報」のレコードは、トランザクション情報であることを示している。

レコード１５１０５２〜１５１０５４のそれぞれもテーブル名「ＰＲＤ」と「ＡＣＣ」と「ＰＡＹ」とが「マスタ」であることを示す。なお、テーブル１５１０は、更に他にもレコードを有してもよく、図４では他のレコードの省略を波線で表現する。

図５は、画面グラフ情報１５２の例を示す図である。画面グラフ情報１５２は、ノード１５２００１〜１５２００３、ノード１５２０１１〜１５２０１３、ノード１５２０２１〜１５２０２３、ノード１５２０３１〜１５２０３４と、エッジ１５２１０１〜１５２１０３と、エッジ１５２１１１〜１５２１１３と、エッジ１５２１２１〜１５２１２３と、エッジ１５２１３１〜１５２１３３と、グループ１５２２０１とから成る。

図５の例において、グループ１５２２０１は、エッジ１５２１０３がノード１５２００３から、グループ１５２２０１内の各ノードに関係付いていることを示す表現である。具体的には、エッジ１５２１０３が、ノード１５２０１１〜１５２０１３と、ノード１５２０２１〜１５２０２３と、ノード１５２０３１〜１５２０３４とに関係付いている。

ノード１５２００１は、図３に示した文字列１０２０００すなわち「田中太郎」の種類が「一般文字列」と「無」であらわされることを示す。また、エッジ１５２１０１の「階層」は、ノード１５２００１とノード１５２００２との間に、ノード１５２００１を親とする関係があることを示す。エッジが表すノード（画面要素）の関係（「階層」、「同行」、「同列」）は、図３に示したＨＴＭＬ形式の情報に含まれる表示位置の関係すなわち図１０に示す表示位置の関係である。

なお、図５の例では「田中太郎」等の文字列をノードの識別子としているが、図３に示した画面情報１０２の情報１０２０の各要素にＩＤ（画面要素ＩＤ）を割り振り、その画面要素ＩＤをノードの識別子として用いてもよい。特に、複数の要素に同じ文字列がある場合、それらに対しても異なる画面要素ＩＤを割り振ることは、ノードの識別に有効である。

図６は、検索グラフ情報１５３の例を示す図である。検索グラフ情報１５３のテーブル１５３０において、列１５３００１〜１５３０１３と行１５３０５１〜１５３０６３のそれぞれは、図５に示した画面グラフ情報１５２におけるノードの値（文字列）を示し、枠１５３０７０内のセルのそれぞれは、ノード間の関係を示す。

以下、図６に示す検索グラフ情報１５３のテーブル１５３０に含まれる情報は、列１５３００１〜１５３０１３と、行１５２０５１〜１５３０６３の文字列により、図５に示したノードを表し、枠１５３０７０のセルが、図５に示したエッジを表すグラフ情報であるとして説明する。また、列１５３００１〜１５３０１３と、行１５２０５１〜１５３０６３のノードは、図６に図示した文字列に加えて図５に示した種類の情報も持つものとして説明する。

なお、図６に示す行１５３０５２と列１５３００２の「２０１６〜」は、図５に示したノード１５２００２の「２０１６／６／１」を表し、図６に示す行１５３０６３と列１５３０１３の「前回の〜」は、図５に示したノード１５２０３４の「前回の発注と個数が異なるため注意してください。」を表す。

枠１５３０７０の各セルにおいて、「レ」は列の値（文字列）または列の値の主キー値と、行の値（文字列）または行の値の主キー値とが、同じレコードにありうることを示し、「カ」は列の値と行の値とが、同じカラムにありうることを示す。例えば、セル１５３０７１は値が「レ」のため、ノード１５２００１の「田中太郎、一般文字列、無」の「田中太郎」という文字列に対応する列１５３００１と、ノード１５２０３３の「銀行振込、一般文字列、無」の「銀行振込」という文字列との間に、同じレコードにありうるという関係があることを示す。なお、図２Ａのテーブル１０１０上では、図２Ｄのテーブル１０１３のレコード１０１３５１カラム１０１３０２の値「田中太郎」の主キー値「Ａ１０１」と、図２Ｅのテーブル１０１４のレコード１０１４５１カラム１０１４０２の値「銀行振込」の主キー値「１」とが、同じレコード１０１０５１にある。したがって、「レ」の示す関係が成り立っている。

セル１５３０７２は値が「カ」のため、ノード１５２０１１の「１、短数値、ｎｕｍ」の「１」という文字列（値）と、ノード１５２０２１の「２、短数値、ｎｕｍ」の「２」という文字列（値）との間に、同じカラムにありうるという関係があることを示す。なお、図６の例にはないが、関係がない場合、枠１５３０７０のセルにおいて、値は「×」となる。

図７は、候補レコード群情報１５４の例を示す図である。候補レコード群情報１５４のテーブル１５４０はカラムとして、候補番号１５４００１と、画面要素１５４００２と、対応レコード１５４００３と、対応カラム１５４００４とを有する。またテーブル１５４０は、レコード１５４０５１〜１５４０５７、レコード１５４０７１〜１５４０７４、レコード１５４０９１〜１５４０９４を有する。なお、テーブル１５４０は、更に他にもレコードを有してもよく、例えば候補番号１５４００１が「２」のレコードを有してもよく、図７では他のレコードの省略を波線で表現する。

レコード１５４０５１は、候補番号１５４００１が「１」かつ画面要素１５４００２が「前回の発注と個数が異なるため注意してください。」のレコードであり、そのレコード１５４０５１の対応レコード１５４００３は「ＢＵＹ．ＢＵＹ＿ＩＤ＝”ＢＵＹ０００１”」であり、対応カラム１５４００４は「ＢＵＹ．ＮＯＴＥ」であることを示している。

これにより、対応レコード１５４００３の「ＢＵＹ．ＢＵＹ＿ＩＤ＝”ＢＵＹ０００１”」は、テーブル名が「ＢＵＹ」のテーブル１０１０の、「ＢＵＹ_ＩＤ」のカラムが「ＢＵＹ０００１」であるレコード、すなわち、図２に示したレコード１０１０５１を示す。そして、対応カラム１５４００４の「ＢＵＹ．ＮＯＴＥ」は、テーブル名が「ＢＵＹ」のテーブル１０１０の「ＮＯＴＥ」のカラム、すなわち、図２のテーブル１０１０のＮＯＴＥ１０１００７を示す。

纏めると、レコード１５４０５１は、候補番号１５４００１が「１」の候補において、画面要素１４５００２の「前回の発注と個数が異なるため注意してください。」は、図２のテーブル１０１０のレコード１０１０５１のＮＯＴＥ１０１００７の「前回の発注と個数が異なるため注意してください。」を元情報としていることを示す。そして、後で図１０に示す文字列１４１０４１は、図７に示した画面要素１５４００２の「前回の発注と個数が異なるため注意してください。」を元情報としている。

図８は、テストシナリオ条件情報１５５の例を示す図である。テストシナリオ条件情報１５５のテーブル１５５０はカラムとして、条件情報１５５００１と、画面要素１５５００２とを有する。またテーブル１５５０はレコード１５５０５１を有する。レコード１５５０５１は、条件情報１５５００１の値が「最大文字長」であり、画面要素１５５００２が「田中太郎」であることを示す。

すなわち、レコード１５５０５１は、後で図１０に示す表示１４１０に表示される可変の文字列１４１００１の「田中太郎」について、「田中太郎」という文字列に対応するデータベース上のカラム内にて最長の文字列を探すというテストシナリオの条件を示す。

図９は、条件対応候補レコード群情報１５６の例を示す図である。条件対応候補レコード群情報１５６のテーブル１５６０はカラムとして、候補番号１５６００１と、画面要素１５６００２と、条件情報１５６００３と、対応レコード１５６００４と、対応カラム１５６００５と、対応値１５６００６とを有する。またテーブル１５６０はレコード１５６０５１を有する。各情報については、図１４を用いて後で説明する。

図１０は、出力装置１４の表示１４１０の例を示す図である。図１０に示す例は発注履歴であり、表示される情報は、図３に示した画面情報１０２の各要素に対応する。文字列１４１００１は文字列１０２０００に対応し、文字列１４１００２〜１４１０４１のそれぞれは、タグ１０２００１〜１０２０６１それぞれの文字列に対応する。また、文字列１４１０１０〜１４１０１２と文字列１４１０２０〜１４１０２２は、テーブルを形成する。

このテーブルは、図３に示したタグ１０２０２２、１０２０２４、１０２０２６により文字列１４１０１０〜１４１０１２の１つの行を形成し、タグ１０２０３２、１０２０３４、１０２０３６により文字列１４１０２０〜１４１０２２の１つの行を形成する。そして、例えば文字列１４１０１０と文字列１４１０２０とは１つの列を形成する。なお、図１０に示す表示は「トラン」の例である。

図１１は、出力装置１４の表示１４２０の例を示す図である。図１１に示す例は、候補の一覧と条件に合う値である。テーブル１４２００は、図７に示した候補レコード群情報１５４のテーブル１５４０の情報の表示である。テーブル１４２００の列１４２００１〜１４２００３は、図７に示したテーブル１５４０の画面要素１５４００２と対応レコード１５４００３と対応カラム１５４００４の情報の表示であり、テーブル１４２００の行１４２０５１〜１４２０６５は、図７に示したテーブル１５４０のレコード１５４０５１〜１５４０９４の情報の表示である。

また、図１１に示した「条件に合う値」の値１４２０８１と値１４２０８２と値１４２０８３のそれぞれは、図９に示した条件対応候補レコード群情報１５６のテーブル１５６０の画面要素１５６００２の値と条件情報１５６００３の値と対応値１５６００６の値である。

以下に、各部の処理の流れについて説明する。まず、画面グラフ情報生成処理部１７１処理の流れを、図１２のフローチャートと、図３の画面情報１０２と、図５の画面グラフ情報１５２とを参照しながら詳細に説明する。画面グラフ情報生成処理部１７１は処理を開始すると、入力装置１３から画面が「マスタ」か「トラン」かが指定される画面種類情報を読み込む（ステップ１７１００）。なお、画面種類情報については図示を省略した。

画面グラフ情報生成処理部１７１は、画面情報１０２を読み込み（ステップ１７１０１）、読み込んだ画面情報１０２に含まれる要素から１つの要素を取り出し（ステップ１７１１０）、要素の種類を示す情報を追加して画面グラフ情報１５２におけるノードとする（ステップ１７１１１）。

追加される要素の種類を示す情報は、例えば、アルファベットと数値のみからなるＮ文字以上（Ｎは予め設定される正の整数）の文字列の場合は、種類を「ＩＤ型」とする。種類が「ＩＤ型」とはならないＬ文字以上（Ｌは予め設定される正の整数）の文字列の場合は種類を「長文字列」とし、Ｍ文字以下（ＭはＬ未満の予め設定される正の整数）の文字列の場合は種類を「短文字列」と、種類が「長文字列」か「短文字列」のいずれにもならない文字列の場合は種類を「一般文字列」とする。

また、日付及び時間の場合は種類を「日時」とし、Ｊ桁数以上（Ｊは予め設定される正の整数）の数値の場合は種類を「長数値」とし、Ｋ桁数以下（ＫはＪ未満の予め設定される正の整数）の数値の場合は種類を「短数値」とし、種類が「短数値」か「長数値」のいずれにもならない数値の場合は種類を「数値」とする。

追加される要素の種類を示す情報は、１つに限定される必要はなく、図５の例では、画面情報１０２の情報１０２０の要素における属性（ｃｌａｓｓ）を追加している。例えば、図３に示したタグ１０２０３２に対応するノード１５２０２２は、「望遠鏡Ａ、一般文字列、ｐｒｏｄｕｃｔ」となる。

画面グラフ情報生成処理部１７１は、画面情報１０２に未処理の要素があるかを判定し（ステップ１７１１２）、未処理の要素がある場合はステップ１７１１０に戻り、未処理の要素がない場合はステップ１７１２０に進む。そして、ステップ１７１０１で読み込んだ画面情報１０２の２つの要素の組合せを取得し（ステップ１７１２０）、取得した要素間の関係を分類して画面グラフ情報１５２のエッジとする（ステップ１７１２１）。

図５の例では、タグが入れ子になっている場合は「階層」とし、タグの指示によるテーブルにおいて同じ行に要素がある場合は「同行」とし、タグの指示によるテーブルにおいて同じ列に要素がある場合は「同列」としている。このテーブルは、図１０の例では、文字列１４１０１０〜１４１０１２と文字列１４１０２０〜１４１０２２である。

また、図５の例では、タグ１０２０２２とタグ１０２０２４は表の同じ行にあるため、ノード１５２０１２の「扇風機Ａ、一般文字列、ｐｒｏｄｕｃｔ」と、ノード１５２０１３の「１００００、数値、ｐｒｉｃｅ」との間を、「同行」の関係のエッジ１５２１１３としている。関係はこれらに限定される必要はなく、画面上の座標に基づく関係、画面遷移に基づく関係、画面要素の出現順番であってもよい。

画面グラフ情報生成処理部１７１は、画面情報１０２に未処理の要素があるかを判定し（ステップ１７１２２）、未処理の要素がある場合はステップ１７１２０に戻り、未処理の要素がない場合はステップ１７１３０に進む。すなわち、グラフ伝搬処理部１７２を呼び出す（ステップ１７１３０）。

グラフ伝搬処理部１７２の処理の流れを、図１３のフローチャートと、図５の画面グラフ情報１５２と、図６の検索グラフ情報１５３とを参照しながら詳細に説明する。グラフ伝搬処理部１７２は、処理を開始すると、画面グラフ情報１５２を読み込み（ステップ１７２００）、画面グラフ情報１５２に含まれるノードの値（文字列）を検索グラフ情報１５３の行１５３０５１〜１５３０６３及び列１５３００１〜１５３０１３とする（ステップ１７２０１）。

グラフ伝搬処理部１７２は、画面グラフ情報１５２に含まれるエッジから１つのエッジを取り出し（ステップ１７２１０）、その種類に応じて、枠１５３０７０内のセルに値を入力する（ステップ１７２１１）。例えば、取り出したエッジの種類が「階層」である場合は、「階層」となる２つのノードの値（文字列）が、同じレコードにありうることを示す「レ」をセルの値とする。

また、取り出したエッジの種類が「同行」か「同列」の場合、エッジの種類を参照して判断する。すなわち、ｃｌａｓｓが異なるかｃｌａｓｓが指定されておらずノードの種類（要素の種類）が異なる場合は、ノードの値（文字列）が、同じレコードにありうることを示す「レ」をセルの値とする。逆に、ｃｌａｓｓが同じであるか、ｃｌａｓｓが無くノードの種類（要素の種類）が一定割合以上同じである場合は、テーブルの同じカラムに値があることを示す「カ」をセルの値とする。

グラフ伝搬処理部１７２は、画面グラフ情報１５２に未処理のエッジがあるかを判定し（ステップ１７２１２）、未処理のエッジがある場合はステップ１７２１０に戻り、未処理のエッジがない場合はステップ１７２２０に進む。ここで、ステップ１７２２０へ進む場合は未処理のエッジが無いのであるから、ステップ１７２２０へ進む時点で値の入力されていない枠１５３０７０内のセルは、対応するエッジが存在しない。

このため、グラフ伝搬処理部１７２は、枠１５３０７０内のセルであって、画面グラフ情報１５２において対応するエッジがないセルを１つ選択し（ステップ１７２２０）、他のエッジ（対応しないエッジ）の情報を元に、選択したセルの値を求める（ステップ１７２２１）。例えば、２つのノード（要素）が、同じ（１つの）ノード（要素）に対して「階層」の関係を有し、かつｃｌａｓｓが同じである場合は、セルの値を「カ」とする。

また、２つのノードが、同じノードに対して「階層」の関係を有し、かつｃｌａｓｓが異なる場合は、セルの値を「レ」とする。例えば、図５に示したグループ１５２２０１内の各ノードは、同じ１つのノード１５２００３と「階層」の関係を有するため、２つのノードであるノード１５２０３１の「５００、数値、ｃｈａｒｇｅ」とノード１５２０３３の「銀行振込、一般文字列、無」は、ノード１５２００３の「ＢＵＹ０００１、ＩＤ型、無」に対してエッジ１５２１０３の「階層」の関係を有するが、ｃｌａｓｓは異なる。従って、図６に示したセル１５３０７４のように値を「レ」とする。

「カ」と「レ」のどちらにも値を特定できない場合は、一度おいて他のセルを処理する。このため、ステップ１７２２１にて、「カ」か「レ」の値が特定された場合は特定された値をセルに入力し、特定されない場合はセルを未処理として（ステップ１７２２２）以後の処理の繰り返しで特定を試みる。

グラフ伝搬処理部１７２は、検索グラフ情報１５３の枠１５３０７０内のセルの状態が一定となっているかを判定する（ステップ１７２２３）。具体的には、枠１５３０７０内のセルが「カ」か「レ」の値で埋まれば、セルの値は変化しないため、セルの状態が一定になっていると判定する。また、枠１５３０７０内に未処理のセルが存在しても、ステップ１７２２０〜１７２２３の処理の繰り返しでは、その未処理のセルに値を入力できない場合もあり、このような場合は処理の繰り返しで未処理が変化しないため、セルの状態が一定になっていると判定する。

グラフ伝搬処理部１７２は、セルの状態が一定となっていないと判定した場合はステップ１７２２０に戻り、セルの状態が一定となっていると判定した場合はステップ１７２２４に進む。ここで、未処理のセルが残っている場合は、未処理のセルに無関係を示す値として「×」を入力し（ステップ１７２２４）、候補レコード群検索処理部１７３を呼び出す（ステップ１７２３０）。

候補レコード群検索処理部１７３の処理の流れを、図１４のフローチャートと、図２に示したデータベース情報１０１と、図４に示したテーブル種類情報１５１と、図６に示した検索グラフ情報１５３（図５に示した画面グラフ情報１５２）と、図８に示したテストシナリオ条件情報１５５と、図９に示した条件対応候補レコード群情報１５６を参照しながら詳細に説明する。

候補レコード群検索処理部１７３は、データベース情報１０１と、テーブル種類情報１５１と、検索グラフ情報１５３を読み込み（ステップ１７３００）、図６の検索グラフ情報１５３のノードを優先順位に基づき１つ選択し（ステップ１７３１０）、図６の検索グラフ情報１５３のノードとエッジ（セル）と、テーブル種類情報１５１を基にした優先順位により文字列を検索する（ステップ１７３１１）。

例えば、次に説明する優先順位に従いノードを選択し、階層の深さ優先で検索を実行する。最初のノード選択については、まず、ノードの種類を参照し、長文字列/長数値を日付及びＩＤ型に、日付及びＩＤ型をその他の種類に優先する。次に、日付及びＩＤ型が複数ある場合は、キー、ユニークな文字列を有するノードを優先する。最後に、ステップ１７１００で入力された画面種類情報と、テーブル種類情報１５１に示されるテーブルの種類が同じであるノードを優先する。

２回目以降のノード選択では、検索可能なエッジの種類が複数ある場合、エッジの「カ」を「レ」に優先する。次に、同じ種類のエッジが複数ある場合、エッジの先のノードの種類を参照し、長文字列/長数値を日付及びＩＤ型に、日付及びＩＤ型をその他の種類に優先する。次に、日付及びＩＤ型が複数ある場合は、キー、ユニークな文字列を有するノードを優先する。最後に、同じ文字列が２つ以上見つかる場合、エッジを辿って見つかる文字数の多い文字列を優先する。なお、エッジが「カ」の場合は同じカラムを、エッジが「レ」の場合は同じレコードを探す。

候補レコード群検索処理部１７３は、例えば図６に示した対象となる文字列が見つかるか、検索できるエッジがなくなるか、予め設定された一定時間以上経過した場合に、検索を終了する（ステップ１７３１２）。

ステップ１７３１０〜１７３１２を更に具体的に説明すると、候補レコード群検索処理部１７３は、まず画面グラフ情報１５２に含まれるノードの中で、長文字列であるノード１５２０３４の「前回の発注と個数が異なるため注意してください。」に対応する文字列をデータベース情報１０１から検索し、テーブル１０１０（ＢＵＹ）のレコード１０１０５１のＮＯＴＥ１０１００７を見つける。

次に、エッジの「レ」を基にレコード１０１０５１に含まれる値が「１」（ＰＡＹＭ１０１００２）、値が「Ａ１０１」（ＡＣＣ１０１００３）、値が「２０１６/６/１」（ＬＩＭＩＴ１０１００４、値が「５００」（ＣＨＡＲＧＥ１０１００５）、値が「１２５００」（ＳＵＭＭＡＲＹ１０１００６）を発見する。

次に、ＢＵＹ＿ＩＤ１０１００１は主キーであるため、外部キーとしてＢＵＹ＿ＩＤ１０１００１を参照する他のテーブルを検索し、テーブル１０１１（ＩＴＥＭ）のレコード１０１１５１の値が「１００００」（ＰＲＩＣＥ１０１１０４）と、値が「１」（ＮＵＭ１０１１０５）を見つけ、レコード１０１１５３の値が「２０００」（ＰＲＩＣＥ１０１１０４）と、値が「２」（ＮＵＭ１０１１０５）を見つける。

次に、テーブル１０１０（ＢＵＹ）のレコード１０１０５１の外部キーであるＰＡＹＭ１０１００２を辿り、テーブル１０１４（ＰＡＹ）のレコード１０１４５１の値が「銀行振込」（ＰＡＹ＿ＮＡＭＥ１０１４０２）を見つける。また、レコード１０１０５１の外部キーであるＡＣＣ１０１００２を辿り、テーブル１０１３（ＡＣＣ）のレコード１０１３５１の値が「田中太郎」（ＡＣ＿ＮＡＭＥ１０１３０２）を見つける。

更に、テーブル１０１１（ＩＴＥＭ）のレコード１０１１５１の外部キーであるＰＲＤ＿ＩＤ１０１１０３を辿り、テーブル１０１２（ＰＲＤ）のレコード１０１２５１の値が「扇風機Ａ」（ＰＲＤ＿ＮＡＭＥ１０１２０２）を見つける。また、レコード１０１１５３の外部キーであるＰＲＤ＿ＩＤ１０１１０３を辿り、テーブル１０１２（ＰＲＤ）のレコード１０１２５２の値が「望遠鏡Ａ」（ＰＲＤ＿ＮＡＭＥ１０１２０２）を見つける。

これにより、図６に示した文字列が見つけることができる。ここで、見つかった値（文字列）は、候補レコード群情報１５４の画面要素１５４００２とされてもよい。また、見つける際に用いられたレコードとカラムのそれぞれは、対応レコード１５４００３と対応カラム１５４００４とされてもよい。

候補レコード群検索処理部１７３は、テストシナリオ条件情報１５５の条件情報１５５００１と画面要素１５５００２を読み取り（ステップ１７３２０）、読み取った条件情報１５５００１の値と画面要素１５５００２の値のそれぞれを条件対応候補レコード群情報１５６の条件情報１５６００３と画面要素１５６００２に書き込む（ステップ１７３２１）。

候補レコード群検索処理部１７３は、候補レコード群情報１５４の画面要素１５４００２の値が、画面要素１５６００２の値と同じである候補レコード群情報１５４のレコード１５４０９２に含まれる対応レコード１５４００３の値と対応カラム１５４００４の値を読み取り、読み取った値それぞれを条件対応候補レコード群情報１５６の対応レコード１５６００４と対応カラム１５６００５に書き込む。

また、条件情報１５６００３に従う値をデータベース情報１０１から読み込み、読み込んだ値を対応値１５６００６に書き込む（ステップ１７３２２）。図９の例では、対応カラム１５６００５が「ＡＣＣ．ＡＣ＿ＮＡＭＥ」であるから、テーブル１０１３（ＡＣＣ）のＡＣ＿ＮＡＭＥ１０１３０２の中で、条件情報１５６００３の「最大文字長」に対応する「Ｊｏｈｎ Ａ．Ｂ．Ｓｍｉｔｈ」をデータベース情報から読み込み、対応値１５６００６に書き込む。そして、結果出力処理部１７４を呼び出す（ステップ１７３２３）。

最後に、結果出力処理部１７４の処理の流れを、図１５のフローチャートと、図７の候補レコード群情報１５４と、図９の条件対応候補レコード群情報１５６と、図１１の表示１４２０とを参照しながら詳細に説明する。

結果出力処理部１７４は、まず、表示１４２０にテーブル１４２００として候補レコード群情報１５４を表示する（ステップ１７４０１）。次に、表示１４２０に値１４２０８１〜１４２０８３として条件対応候補レコード群情報１５６の画面要素１５６００２と条件情報１５６００３と対応値１５６００６のそれぞれの値を表示する（ステップ１７４０２）。図１１では図示を省略した候補レコード群情報１５４の一部を更に表示してもよい。

以上で説明したように、画面上に表示される要素の値と、要素の種類と、要素間の関係を基に検索に用いるグラフ情報を作成し、画面上に表示される要素の値の元となっているデータベースレコードの候補を検索し、出力装置に候補を表示することができる。更に、作成したいテストシナリオの条件を受け付け、その条件に合うデータベースレコードを画面に表示することができる。

以上の説明では、図１２〜１５のそれぞれを画面グラフ情報生成処理部１７１とグラフ伝搬処理部１７２と候補レコード群検索処理部１７３と候補レコード群検索処理部１７３と結果出力処理部１７４のフローチャートとして説明したが、それぞれはＣＰＵ１１のプログラムのフローチャートであってもよい。また、計算機１を１台の計算機として説明したが、２台以上の計算機によりプログラムを実行してもよい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアを用いて実現してもよい。記憶装置１５は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）かＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、磁気テープかフラッシュメモリかＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）等の記録媒体であってもよい。

また、メモリ１２と記憶装置１５のそれぞれに記憶される情報は、図１に示した配置に限定されるものではなく、メモリ１２と記憶装置１５との間で転送されてもよい。そして、図１では図示を省略したプログラムとデータが、メモリ１２と記憶装置１５に格納されてもよい。

また、各構成要素の接続（情報のやり取り）は説明上必要と考えられるものを示しており、必ずしも全ての接続を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

最後に、本発明は上記した実施の形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記した処理に必要な情報を得るために、テスト入力情報検索装置１６の計算機環境等に応じて別の構成を備えてもよい。

１ 計算機
１１ ＣＰＵ
１２ メモリ
１５ 記憶装置
１６ テスト入力情報検索装置
１０１ データベース情報
１０２ 画面情報
１５１ テーブル種類情報
１５２ 画面グラフ情報
１５３ 検索グラフ情報
１５４ 候補レコード群情報
１５５ テストシナリオ条件情報
１５６ 条件対応候補レコード群情報
１７１ 画面グラフ情報生成処理部
１７２ グラフ伝搬処理部
１７３ 候補レコード群検索処理部
１７４ 結果出力処理部

Claims (15)

1. データベースのテスト入力のための候補を検索するテスト入力情報検索装置であって、
   第１の構造で構成された複数の要素が含まれる前記データベースの情報を記憶し、
   第２の構造で構成されて表示される前記複数の要素を含む画面情報を記憶し、
   前記画面情報に含まれる前記複数の要素の中の要素間の関係を、前記第２の構造から特定し、
   特定された要素間の関係に基づいて、前記データベースの情報から前記複数の要素を、テスト入力のための候補として検索すること
   を特徴とするテスト入力情報検索装置。
2. 請求項１に記載のテスト入力情報検索装置であって、
   前記第２の構造は、表示のための構造であり、前記画面情報に含まれる前記複数の要素の中の要素間の表示位置の関係と要素の属性とを含み、
   特定された要素間の関係に加えて、更に要素の属性に基づいて、前記データベースの情報から前記複数の要素を、テスト入力のための候補として検索すること
   を特徴とするテスト入力情報検索装置。
3. 請求項２に記載のテスト入力情報検索装置であって、
   前記画面情報に含まれる前記複数の要素の中の各要素の種類を特定し、要素と要素の属性と要素の種類とを組み合せたノードを複数生成し、
   要素間の関係として、生成された複数のノード間のエッジの種類を前記第２の構造から特定すること
   を特徴とするテスト入力情報検索装置。
4. 請求項３に記載のテスト入力情報検索装置であって、
   特定されたエッジの種類と、エッジの両端の２つのノードを構成する２つの要素の属性の関係と２つの要素の種類の関係とに基づいて、２つのノード間の関係をセルとして特定すること
   を特徴とするテスト入力情報検索装置。
5. 請求項４に記載のテスト入力情報検索装置であって、
   生成された複数のノードの中の第１のノードと第２のノードとの間のエッジの種類が、前記第２の構造から特定されない場合、生成された複数のノードの中の第３のノードと前記第１のノードとの間のエッジの種類と、前記第３のノードと前記第２のノードとの間のエッジの種類とに基づいて、前記第１のノードと前記第２のノードとの関係をセルとして特定すること
   を特徴とするテスト入力情報検索装置。
6. 請求項５に記載のテスト入力情報検索装置であって、
   特定された要素の種類に基づく優先順位に従って前記データベースの情報から前記複数の要素の一部を検索し、セルとして特定された関係に基づく優先順位に従って前記データベースの情報から前記複数の要素の一部を検索すること
   を特徴とするテスト入力情報検索装置。
7. 請求項６に記載のテスト入力情報検索装置であって、
   前記第１の構造は、それぞれが複数のカラムを有する複数のテーブルであり、
   要素の情報と条件の情報が指定され、
   前記データベースの情報から検索された前記複数の要素の中で、指定された要素の情報を含むカラムの、指定された条件の情報を満たす値を検索すること
   を特徴とするテスト入力情報検索装置。
8. 請求項７に記載のテスト入力情報検索装置であって、
   前記データベースはリレーショナルデータベースであること
   を特徴とするテスト入力情報検索装置。
9. 計算機がデータベースのテスト入力のための候補を検索するテスト入力情報検索方法であって、
   前記計算機は、
   ＣＰＵと、
   第１の構造で構成された複数の要素が含まれる前記データベースの情報を記憶し、第２の構造で構成されて表示される前記複数の要素を含む画面情報を記憶した記憶装置と
   を備え、
   前記ＣＰＵは、
   前記記憶装置から前記画面情報を読み込み、読み込んだ前記画面情報に含まれる前記複数の要素の中の要素間の関係を、前記第２の構造から特定し、
   前記記憶装置から前記データベースの情報を読み込み、特定された要素間の関係に基づいて、読み込んだ前記データベースの情報から前記複数の要素を、テスト入力のための候補として検索すること
   を特徴とするテスト入力情報検索方法。
10. 請求項９に記載のテスト入力情報検索方法であって、
    前記第２の構造は、表示のための構造であり、前記画面情報に含まれる前記複数の要素の中の要素間の表示位置の関係と要素の属性とを含み、
    前記ＣＰＵは、
    特定された要素間の関係に加えて、更に要素の属性に基づいて、読み込んだ前記データベースの情報から前記複数の要素を、テスト入力のための候補として検索すること
    を特徴とするテスト入力情報検索方法。
11. 請求項１０に記載のテスト入力情報検索方法であって、
    前記ＣＰＵは、
    読み込んだ前記画面情報に含まれる前記複数の要素の中の各要素の種類を特定し、要素と要素の属性と要素の種類とを組み合せたノードを複数生成し、
    要素間の関係として、生成された複数のノード間のエッジの種類を前記第２の構造から特定すること
    を特徴とするテスト入力情報検索方法。
12. 請求項１１に記載のテスト入力情報検索方法であって、
    前記ＣＰＵは、
    特定されたエッジの種類と、エッジの両端の２つのノードを構成する２つの要素の属性の関係と２つの要素の種類の関係とに基づいて、２つのノード間の関係をセルとして特定すること
    を特徴とするテスト入力情報検索方法。
13. 請求項１２に記載のテスト入力情報検索方法であって、
    前記ＣＰＵは、
    生成された複数のノードの中の第１のノードと第２のノードとの間のエッジの種類が、前記第２の構造から特定されない場合、生成された複数のノードの中の第３のノードと前記第１のノードとの間のエッジの種類と、前記第３のノードと前記第２のノードとの間のエッジの種類とに基づいて、前記第１のノードと前記第２のノードとの関係をセルとして特定すること
    を特徴とするテスト入力情報検索方法。
14. 請求項１３に記載のテスト入力情報検索方法であって、
    前記ＣＰＵは、
    特定された要素の種類に基づく優先順位に従って、読み込んだ前記データベースの情報から前記複数の要素の一部を検索し、セルとして特定された関係に基づく優先順位に従って、読み込んだ前記データベースの情報から前記複数の要素の一部を検索すること
    を特徴とするテスト入力情報検索方法。
15. 請求項１４に記載のテスト入力情報検索方法であって、
    前記第１の構造は、それぞれが複数のカラムを有する複数のテーブルであり、
    前記ＣＰＵは、
    要素の情報と条件の情報が指定され、
    読み込んだ前記データベースの情報から検索された前記複数の要素の中で、指定された要素の情報を含むテーブルのカラムから、指定された条件の情報を満たす値を検索すること
    を特徴とするテスト入力情報検索方法。

Images