JP2007323573A - 機能テスト・スクリプト生成装置 - Google Patents

Abstract

【課題】情報システム開発において、要件定義フェーズで決められた仕様のあいまいさや不正確さを排し、機能テスト・フェーズでは自動実行されるテスト・シナリオが元々の要件に合致したものかどうかをシステム的に検証することができる方法を提供すること。
【解決手段】（１）画面単位の機能仕様から入力変数、出力変数、及びそれぞれの変数のタイプ（型）を抽出する。（２）画面単位の仕様が複数組み合わされた複合機能仕様から画面遷移情報を抽出する。（３）（２）で得られた画面遷移に現れる１つ１つの画面に対し、先頭から順番に以下を行う。入力変数に対しては、それに対応するオブジェクト（ボタンやテキスト・フィールド等）に対するアクション（クリックや文字のセット）を表すスクリプトを生成する。出力変数に対しては、画面に表示されているテキスト情報を出力変数から決定される期待値と比較するスクリプトを生成する。
【選択図】図１

Description

本発明は、情報処理システム開発における機能テストのためのテスト・スクリプトを生成する装置、方法、およびプログラム等に関する。

近年、情報システム開発においては、テスト作業にかかるワークロードの増大がますます問題となっている。また、テストが要件定義で定められた機能仕様に合致したものであるか、テストのカバレージが十分であるかを検証するシステムも強く求められている。そのため従来から、情報システム開発におけるテスト・フェーズを効率的に行うための手法が多数提案されている。

例えば、特許文献１には、プログラムの仕様書とプログラムの処理形態ごとに定義したスクリプトファイルの標準型を合成することでプログラムのテスト実行用スクリプトファイルとテストデータを生成するテストケース生成装置が開示されている。また、特許文献２〜４には、ＧＵＩ部を有するアプリケーションに対し、その仕様を仕様ファイルまたは情報ファイルなどにより記述し、それからテスト・シナリオを網羅的に自動生成するシステムテスト支援装置などが開示されている。さらに他の特許文献においては、表形式の機能仕様書からテストケースを作成する方法（特許文献５）、操作仕様と初期条件入力から操作仕様を変換しテストケースを生成する装置（特許文献６）、プログラムへの入力条件と動作環境条件とから二次元の要因分析表を生成し、それに基づいて入力条件群および環境条件群を組み合わせてテスト・スクリプトを自動生成するソフトウェア検証方法（特許文献７）、その他、様々な独自の定義情報からテストケースを作成する方法等（例えば、特許文献８〜１１）が開示されている。

特開平６−１１０７３３号公報 特開平９−２２３０４０号公報 特開平９−２２３０４１号公報 特開平９−２２３０４２号公報 特開平１１−３０６０４６号公報 特開２０００−３３９１９３号公報 特開２００４−２８０２３１号公報 特開２００２−２５９１６１号公報 特開２００２−３６６３８７号公報 特開２００４−２２０３３０号公報 特開２００５−１１５５８２号公報

一般的に情報システムの開発においては、要件定義フェーズで決められた仕様のあいまいさや不正確さのために、システム構築のコストやリスクが増大することが知られている。このため例えば、形式仕様言語を用いてシステムを厳密に定義することにより、こうした問題を解決しようという試みが１９７０年代よりなされてきたが、導入コストが高いため広く使用されるにはいたっていない。一方、機能テスト・フェーズでは、自動実行ツールを使用することにより回帰テストの生産性を上げることが日常的に行われている。しかし、回帰テスト用のテスト・スクリプト（テスト記述書）の作成は、ツールのレコード機能を使用したり、人手によるコーディングによって行われるため、作成に時間とコストがかかり、また自動実行されるテスト・スクリプトがもともとの機能要件（仕様）に合致したものかをシステム的に検証することができないという課題がある。

上記の特許文献の手法は、いずれも独自の定義に基づく仕様ファイルや表形式のファイル、あるいは状態遷移図等の人手による作成を必要とし、システム開発手法として標準化された形式仕様言語やＵＭＬ（Ｕｎｉｖｅｒｓａｌ Ｍｏｄｅｌ Ｌａｎｇｕａｇｅ）を用いた仕様の記述方法には対応できるものではない。

本発明は、これらの課題を解決するためになされたものであり、形式仕様言語やＵＭＬモデリング記述による標準化された仕様記述の方法を用いたシステム開発において、要件定義で定められた仕様との整合性が保証され、かつ、テスト・スクリプトの作成にコストがかからないように効率的な手法を実現する機能テストのためのテスト・スクリプト生成装置等を提供することを目的とする。

本発明の第１の形態として、以下のような機能を備えるテスト・スクリプト生成装置を提供する。
（１） 情報処理システムの機能仕様からテスト仕様を生成する装置であって、前記情報処理システムの機能を記述した仕様ファイルからテスト対象のソフトウェアが生成する画面単位に、入力変数、出力変数、入力変数タイプ、および出力変数タイプを抽出する入出力変数抽出部と、前記仕様ファイルから画面遷移情報を抽出する画面遷移抽出部と、前記入力変数、前記出力変数、前記入力変数タイプ、前記出力変数および前記画面遷移情報を用いて、機能テスト実行のためのテスト・スクリプトを生成するテスト・スクリプト生成部と、を備えた装置。

（２）前記テスト・スクリプト生成部は、前記画面遷移情報から前記入力変数に対応するオブジェクトに対するアクションを表すテスト・スクリプトを生成し、前記出力変数に対して画面に表示されているテキスト情報を該出力変数から決定される期待値と比較するテスト・スクリプトを生成する、（１）に記載の装置。

（３）前記オブジェクトは、ボタン（ラジオボタン、リスト・ボックスを含む）、テキスト・フィールド、またはリスト・ボックスを含み、前記アクションは、ユーザのクリック操作、文字列の入力、またはリストからの選択に対応する、（２）に記載の装置。

（４） 前記テスト・スクリプト生成部は、画面をノード、画面遷移をエッジとする有向グラフにおいて、前記画面遷移の全てのエッジを少なくとも１回通過し、かつ冗長度が所定の値より小さいパス集合を求めることによりテスト回数の最適化を行う、（１）に記載の装置。

（５）前記パス集合は、所定の深さ優先−結合アルゴリズムによって求める、（４）に記載の装置。

（６）前記テスト・スクリプト生成部は、所定のＦｏｒｍ画面遷移アルゴリズムによってＦｏｒｍ要素の任意の組み合わせのテストを、最短の画面遷移で行うパスの集合を求める、（１）に記載の装置。

（７）前記仕様ファイルは、Ｚ言語を用いて作成される、（１）に記載の装置。

（８）前記入力変数のオブジェクト・タイプを決定する優先順位が、（１）所定のプロパティ・ファイルに記述されているオブジェクト・タイプ、（２）該入力変数が属するタイプ名、（３）Ｌｉｎｋオブジェクト・タイプの順である、（７）に記載の装置。

（９）前記テスト・スクリプトは、前記入力変数に関連付けられたオブジェクトを、テスト対象画面を表示するブラウザ内で前記オブジェクトのタイプとオブジェクト名称をキーとして動的に探索するために、アプリケーションのテスト実行時に呼び出される実行時ライブラリを用いる、（１）に記載の装置。

（１０）前記仕様ファイルは、ＵＭＬのアクティビティ図により記述される、（１）に記載の装置。

（１１）前記ＵＭＬのアクティビティ図は、画面要素、Ｆｏｒｍ要素、および画面遷移要素のうち少なくとも一つのＵＭＬ要素で構成される（１０）に記載の装置。

本発明の装置は、簡単にいうと以下の処理を行うことにより、機能仕様と合致したテスト・スクリプトを自動生成することができる。
１）仕様ファイルから、それぞれの画面に対して入力変数、出力変数、およびそれぞれの変数のタイプ（型）を抽出する。
２）仕様ファイルから画面遷移情報を抽出する。
３） ２）で得られた画面遷移に現れる１つ１つの画面に対し、先頭から順番に以下の
処理を行う。
ａ）入力変数に対しては、それに対応するオブジェクト（ボタンやテキスト・フィールド等）に対するアクション（クリックや文字のセット）を表すスクリプトを生成する。
ｂ）出力変数に対しては、画面に表示されているテキスト情報を出力変数から決定される期待値と比較するスクリプトを生成する。

さらに、本発明は、標準化された仕様記述の方法として、形式仕様言語であるＺ言語と、ＵＭＬを用いたモデリング記述法に対応する。しかし他の仕様記述方法（例えばＶＤＭ（Ｖｉｅｎｎａ Ｄｅｖｅｌｏｐｍｅｎｔ Ｍｅｔｈｏｄ）等）を排除するものではない。さらに、テストされるソフトウェアの各画面をノード、画面遷移をエッジとする有効グラフを考え、そのノード、エッジ間のパスを全てカバーし、かつ冗長度の少ないテスト・スクリプトを生成するためのアルゴリズムも提供する。

また、本発明は別の形態として、上記の装置の機能を実行する方法、またはその方法の各ステップあるいはアルゴリズムをコンピュータに実行させるコンピュータ・プログラムとしても提供可能である。さらに別の形態として、このコンピュータ・プログラムを記録したコンピュータ可読媒体を含むプログラム製品としても提供可能である。

本発明によれば、形式仕様言語、またはＵＭＬのモデリング記述法等の標準化された仕様記述の方法を用いた情報システム開発において、独自定義の仕様記述法を用いることなく、要件定義で定められた仕様との整合性が保証され、かつテスト・スクリプトの作成にコストがかからないような効率的な手法を実現するテスト・スクリプト生成装置等を提供することができる。これにより機能テストが要件定義を反映したものであることを保証すると同時に、仕様を機能テストにも流用できるため、その作成に要するコストの一部を補うこともできる。

図１は、本発明の好適な実施形態として、前述の解決手段を備えたテスト・スクリプト生成装置１０の機能ブロック図である。本装置は、主要部として、入出力変数抽出部２、画面遷移抽出部３、テスト・スクリプト生成部７から構成される。また、特に図示していないが、本装置は、制御部（ＣＰＵ）と記憶部を備える。また、本装置の操作員や他のシステムと交信する入出力部や通信制御部などを備えていてもよい。但し、これらの構成は一例であり、同等な機能を備えた他のバリエーションを含んでよい。本装置は、典型的にはパーソナルコンピュータや汎用コンピュータのようなコンピュータ装置で実現されるが、マイクロプロセッサ、記憶部、および適切な入出力手段を備えたその他の情報処理装置であってもよい。

本装置において入出力変数抽出部２は、開発者が記述したテスト対象システムの仕様ファイル１を入力データとして、その仕様ファイル１の記述法の特徴を利用し、画面単位にその画面で使用される入出力変数４を抽出する。このとき、入出力変数４とそれに対応する入出力変数タイプ５（入出力変数の型）を同時に抽出する。具体的な抽出方法については、後述の仕様記述の実施例ごとに説明する。

また、本装置の画面遷移抽出部３は、仕様ファイル１に含まれた画面ごとの情報を検出し、各画面間の画面遷移情報６を抽出する。具体的な抽出方法については、後述の仕様記述の実施例ごとに説明する。

さらに、本装置のテスト・スクリプト生成部７は、上述の入出力変数抽出部２と画面遷移抽出部３が出力した入出力変数４、入出力変数タイプ５、および画面遷移情報６を入力データとし、機能テスト自動実行のためのテスト・スクリプトファイル８を生成する。自動テスト実行ツール１３は、生成されたテスト・スクリプトファイル８を実行することによりテスト対象アプリケーション１２のテストを行う。テスト・スクリプトファイル８から呼び出された実行時ライブラリ１１は、入力変数に関連付けられたオブジェクトを、テスト対象画面を表示するブラウザ内でオブジェクト・タイプとオブジェクト名称をキーとしてテスト実行時に動的に探索することができる。本発明の一つの実施例においては、このテスト・スクリプトファイルは、公知の自動テスト実行ツールであるＲＦＴ（Ｒａｔｉｏｎａｌ Ｆｕｎｃｔｉｏｎａｌ Ｔｅｓｔｅｒ）（登録商標）の入力として使用できるように実装したが、自動テスト実行ツールはこれに限定されるものではない。この自動テスト実行ツール１３の備えるべき条件については後述する。以下では、本発明を実施例に基づいて具体的に説明する。

＜形式仕様言語としてＺを用いた実装例＞
ここでは、機能仕様を記述する形式仕様言語としてＺを、機能テスト用の自動実行ツールとして前述のＲＦＴを使用した実装例を以下に記す。

Ｚは形式仕様言語の中で最も多く使用されており、ＩＳＯによる標準化も行われている。Ｚは集合論と述語論理に基づいた記法を持ち、仕様はスキーマ（ｓｃｈｅｍａ）と呼ばれる単位で記述する。図２は、「Ｂｒｏｗｓｅ」という名称を持つ単純なスキーマの例を示したものである。この例では書籍一覧から特定の本を選択すると、その要約が表示されるという仕様を表している。図２の記述でスキーマは符号２３で示される部分である。スキーマ２３の上部２１は変数や関数の宣言を記述する宣言部を示す。例えば、変数ｘが集合Ｘの要素であることは「ｘ：Ｘ」と表記される。ここで、変数名「ｂｏｏｋ」の末尾の「？」はそれが入力変数であることを、変数名「ａｂｓｔｒａｃｔ」の末尾の「！」は出力変数であることを表す。

スキーマ宣言部２１では、変数名：タイプ名の形式で宣言されるので、その変数のタイプ（型）を知ることができる。さらにスキーマを組み合わせた「ｓｃｈｅｍａ ｃａｌｃｕｌｕｓ」が定義されている。その一つに「ｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎ」があり、複数のスキーマにまたがった状態遷移を記述できる。図２の例では、符号２４で示す部分がｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎを表す。本実施例では、画面単位でスキーマが定義されることを仮定している（Ｚ言語自体にはそのような制約は無い）。したがって、ｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎ２４によって画面遷移を記述できる。

上記のように、Ｚではスキーマ宣言部２１に記述される変数名から、入力変数か出力変数かを決定することができる。入力変数の場合は、それに対応するオブジェクトに対するアクションを表すスクリプトを生成し、出力変数の場合はブラウザに表示されているテキスト情報を、出力変数に対応する期待値と比較するスクリプトを自動生成するというのが基本的な考え方である。しかしＺで記述される仕様とＲＦＴのプログラミング・モデルの間にはセマンティック・ギャップ（文法的な相違）が存在するため、以下に述べる４つの課題を解決する必要がある。下記（Ａ）〜（Ｄ）にそれらを説明する。

（Ａ）画面遷移の導出規則
Ｚで記述された仕様では、それがどのような画面分割や画面遷移によって実現されるかは規定されない。そのため、以下の規則を定めることにより対処する。
規則１： スキーマと画面を１対１に対応させる。
規則２： 画面遷移はスキーマ複合によって表現する。
スキーマ複合（ｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎ）とはスキーマ演算の一種である。例えばスキーマＡがシステムの状態をＳ１→Ｓ２へ遷移させ、スキーマＢはＳ２→Ｓ３へ遷移させるとすると、２つのスキーマを複合したスキーマＣは以下の［数１］のように記述され、システムの状態をＳ１→Ｓ３へ遷移させる。

規則１により、スキーマＡ、Ｂはそれぞれある画面ＡＰ、ＢＰに対応するので、スキーマＣはＡＰ→ＢＰという画面遷移に対応すると解釈できる。

（Ｂ）入力変数とオブジェクト・タイプのマッピング
仕様の宣言部に現れる入力変数名からは、それがどのようなタイプのオブジェクトによって実装されるのかは決定できない。例えば図２のｂｏｏｋという変数は、ブラウザ上のテキスト・フィールドに本の名称を入力することなのか、本の名称がリンクとして表示されていて、それをクリックすることなのか判定できない。これを解決するためプロパティ・ファイルを用意し、後述する形式で変数名とオブジェクト・タイプ名のマッピングを記述する方法を採った。但し、全ての入力変数に対してこのような対応関係を記載することは煩雑なため、プロパティ・ファイルにエントリーが無い場合に適用される規則を考案した。これについては後述の実施例５で説明する。

（Ｃ）セッション情報の取り扱い
Ｗｅｂアプリケーションではセッション情報を保持するために、Ｃｏｏｋｉｅ等にセッション・キーが格納される。Ｚ言語を用いた仕様では、このセッション・キーは入力変数として記述される必要がある。一方、ＲＦＴのスクリプトはユーザ操作に対応しているため、ユーザの操作に現れないセッション・キーに関する情報は記述できない。この問題を解決するためＳｅｓｓｉｏｎというオブジェクト・タイプにマッピングされる入力変数に対してはスクリプトを生成しないこととする。なお、入力変数がマッピングされるオブジェクト・タイプは、以下の優先順位で決定される。
１）プロパティ・ファイルに記述されているオブジェクト・タイプ
２）入力変数が属する集合名がＳｅｓｓｉｏｎ、Ｓｕｂｍｉｔ（ｓｕｂｍｉｔボタンに対応）、Ｐａｓｓｗｏｒｄ（ｐａｓｓｗｏｒｄフィールドに対応）のいずれかの場合は集合名と同じオブジェクト・タイプ
３）Ｌｉｎｋというオブジェクト・タイプ（アンカー・タグに対応。デフォルトとして使用される。）

（Ｄ）オブジェクトの実行時特定方法
オブジェクト・タイプが決定されても、オブジェクトそのものがＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）ツリーのどこに存在するかは分からない。このため、ＲＦＴが提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を使用して動的にオブジェクトを探索する。探索のキーとなるのはオブジェクト・タイプと、リンクやボタン等の名称である。後者は仕様に記述される変数名とは一般に異なるため、ＲＦＴのデータ・プールを使用して入力変数名と実装名のマッピングを行う。データ・プールは出力変数名と期待値のマッピングにも使用し、テスト・スクリプトとデータの分離を実現する。

以下では、上記の課題に対する解決策についてより具体的に説明する。

（１）オブジェクト・タイプとｃｏｎｔｒｏｌ．ｐｒｏｐｅｒｔｉｅｓファイルについて
スキーマの宣言部の入力変数名からは、それがどのようなコントロール（ボタンやテキスト・フィールド等。以下、オブジェクト・タイプとも呼ぶ）によって実装されるかは決定できない。そのため、ｃｏｎｔｒｏｌ．ｐｒｏｐｅｒｔｉｅｓと名付けたプロパティ・ファイル内で以下の形式で入力変数名とオブジェクト・タイプ名のマッピングを記述する。
スキーマ名．入力変数名＝オブジェクト・タイプ名

例えば、Ｃｏｎｆｉｒｍ．ｕｓｅｒ＝Ｔｅｘｔという形式である。また、オブジェクト・タイプには例えば以下のものがある。

Ｓｅｓｓｉｏｎにマッピングされる入力変数に対しては、スクリプトは生成しない。これはＺ言語上ではセッション・キーは入力変数として記述せざるを得ないが、ＲＦＴ上のスクリプトには（ユーザ操作に対応しないので）セッション・キーは現れないためである。

（２）オブジェクト・タイプの決定方法
ｃｏｎｔｒｏｌ．ｐｒｏｐｅｒｔｉｅｓファイルに全ての入力変数のオブジェクト・タイプへのマッピングを記述するのは煩雑なため、以下の優先順位によりオブジェクト・タイプを決定することとした。これにより、多くの場合ｃｏｎｔｒｏｌ．ｐｒｏｐｅｒｔｉｅｓファイルにマッピングを記述する必要はなくなる。
１） ｃｏｎｔｒｏｌ．ｐｒｏｐｅｒｔｉｅｓに記述されているオブジェクト・タイプ
２） 入力変数が属するタイプ名がＳｅｓｓｉｏｎ，Ｓｕｂｍｉｔ，Ｐａｓｓｗｏｒｄのいずれかの場合は、タイプ名と同じオブジェクト・タイプ
３） Ｌｉｎｋオブジェクト・タイプ（デフォルトとして使用される）

（３）入力変数に対応するオブジェクトの動的探索とアクションの起動
生成されるスクリプトを簡潔な形で記述するため、各ＧＵＩオブジェクトに対し、ＲＦＴ ＡＰＩを使用してｗｒａｐｐｅｒ ｃｌａｓｓを作成した。例えばｏｒｄｅｒという入力変数で表されるＳｕｂｍｉｔボタンをクリックする場合は以下のようになる。

／／ ｉｎｉｔｉａｌｉｚａｔｉｏｎ
Ｓｕｂｍｉｔ ｓｕｂｍｉｔ ＝ ｎｅｗ Ｓｕｂｍｉｔ（ｔｈｉｓ）；
／／ ｂｏｄｙ
：
：
ｓｕｂｍｉｔ．ｃｌｉｃｋ（”ｏｒｄｅｒ”）；

Ｓｕｂｍｉｔクラスのｃｌｉｃｋメソッドの内部ではまず、”ｏｒｄｅｒ”に対応するオブジェクトをブラウザ内で動的に探索する。探索のキーとなるのはオブジェクト・タイプとボタン名称である。ここで”ｏｒｄｅｒ”いうのは仕様に現れる入力変数名だが、実装時のボタン名称は一般には異なることが予想される。そのためＳｕｂｍｉｔクラスの中でＲＦＴのデータ・プールにアクセスし、実装名を取得している。次いで探索されたオブジェクトに対しｃｌｉｃｋ ｍｅｔｈｏｄを呼び出している。

（４）出力変数に対応する期待値と、ブラウザ上に表示されるテキストとの比較
出力変数に対応する期待値と、ブラウザ上に表示されるテキストとの比較を行う。例えば、図２のスキーマの例ではａｂｓｔｒａｃｔが出力変数だが、これに対する期待値をＲＦＴのｄａｔａｐｏｏｌに記述することにより、スクリプトとデータの分離を実現している。ブラウザ上に表示されるテキストを取得するため、ＨｔｍｌＴｅｘｔというｗｒａｐｐｅｒ ｃｌａｓｓを作成し、その内部で”Ｈｔｍｌ．ＨｔｍｌＤｏｃｕｍｅｎｔ”というクラスのオブジェクトを動的に探索する。そのテキスト属性がブラウザ上に表示されるテキストである。期待値と実測値はＲＦＴのＶｅｒｉｆｉｃａｔｉｏｎＰｏｉｎｔクラスを使用して比較を行うことにより、テスト終了時にテスト結果を自動的に得ることができる。

（５）テスト・スクリプト生成アルゴリズム
個々の画面がそれぞれスキーマＡｉ（ｉ＝０， ．．．，ｎ−１）で表されているとする。それらのｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎ Ｃ＝Ａ０ ｏ Ａ１ ｏ ， ．．．， ｏ Ａｎ−１は画面遷移Ａ０→Ａ１→．．．→Ａｎ−１を表す。Ｃに対応するテスト・スクリプトを生成するアルゴリズムは以下のとおりである。

ｉ ＝ ０からｎ−１まで、以下を行う。
１）Ａｉの入力変数全てにつき、オブジェクト・タイプを（２）の方法により決定する。（例えばボタン）
２）決定されたオブジェクトに対しそれぞれ決まるアクションを決定する。（例えばボタンに対してはｃｌｉｃｋアクション）
３）（３）で示されるスクリプトを生成する。但し入力変数が複数ある場合、ＬｉｎｋまたはＳｕｂｍｉｔに対するスクリプトは最後に生成する。
４）Ａｉの出力変数につき、（４）の方法により期待値と実際のテキストの比較を行う。

図３、および図４は、以上で説明したスクリプトの生成方法とそれを用いた処理の流れをまとめたものである。図３において、ステップＳ３１ではプロパティ・ファイル３１を参照してオブジェクトのマッピングを行う。さらに、ステップＳ３３では、入力変数を抽出し、オブジェクトに対するアクションを生成する。また、出力変数に対しては、ステップＳ３２でアプリケーションの出力を期待値と比較する。その結果、機能テスト・スクリプト３４が生成される。次に図４において、ステップＳ３４で、データ・プール３５を参照して、仕様上の名称と実装名とのマッピングを行う。ステップＳ３４は、図１の実行時ライブラリ１１によって実行される。そして、ステップＳ３５では、探索キーとしてオブジェクト・タイプと名称を用いてＲＦＩのＡＰＩを使用したオブジェクトの動的探索を行う。

（６）有効性の検証
本発明の実施例の有効性を検証するため、ｅｃｌｉｐｓｅ上のプラグインとしてＺ言語エディタを実装し、ＲＦＴと連携させた。図５はこのシステム構成を示したものである。クラス・ライブラリ５６（Ｃｌａｓｓ Ｌｉｂｒａｒｙ）は、図１の実行時ライブラリ１１に相当し、前述の（３）、（４）で述べたｗｒａｐｐｅｒ ｃｌａｓｓである。Ｊａｖａ（登録商標）で記述されたテスト・スクリプト５５を実行することによって自動的にＷｅｂアプリケーションのテストを行うことができる。スクリプトは、ブラウザ上のＤＯＭオブジェクト（リンクやボタン等）に対するアクション（クリック等）として記述される。ＲＦＴ５４はオブジェクトに対するアクションという形でスクリプトを記述することができ、また動的にオブジェクトを探索するＡＰＩを備えている。検証のため、サンプル・アプリケーションの仕様をＺで記述し，エディタ・メニューから呼び出されるアクションによってＲＦＴ５４用の機能テスト・スクリプトを自動生成した。

以下のスクリプトの最初の２行が図２のスキーマ２３に対応している。このスクリプトをＲＦＴ上で実行することによりアプリケーションの挙動が再現され、ブラウザ上に表示されるテキストと期待値との比較を自動的に行うことができた。

ｌｉｎｋ．ｃｌｉｃｋ（”ｂｏｏｋ”）；
ｈｔｍｌＴｅｘｔ．ｔｅｓｔ（”ａｂｓｔｒａｃｔ”）；
ｓｕｂｍｉｔ．ｃｌｉｃｋ（”ｏｒｄｅｒ”）；
ｈｔｍｌＴｅｘｔ．ｔｅｓｔ（”ｐｒｏｍｐｔ”）
ｔｅｘｔＩｎｐｕｔ．ｓｅｔＴｅｘｔ（”ｕｓｅｒＮａｍｅ”，”ｕｓｅｒＶａｌｕｅ”）；
ｓｕｂｍｉｔ．ｃｌｉｃｋ（”ｃｏｎｆｉｒｍ”）；
ｈｔｍｌＴｅｘｔ．ｔｅｓｔ（”ａｃｃｅｐｔ”）；

上記の実施例１では、形式仕様言語としてＺ言語、自動テスト・ツールとしてＲＦＴを用いた場合を説明したが、形式仕様言語としては、前述したようにＺ言語に限定されず、ＶＤＭなどの他の言語を使用することができる。ここで形式仕様言語が満たすべき条件としては以下のものが挙げられる。
１）画面単位で仕様を記述できること
２）画面単位で記述した仕様を組み合わせて、画面遷移を記述できること。
３）入力変数と出力変数を特定できること。
４）入力変数のタイプ（型）を取得できること

また、本発明を適用するために自動テスト・ツールはＲＦＴに限定されるものでなく、下記の条件を満たすものであれば適用可能である。
１）オブジェクトに対するアクションという形式でスクリプトを記述できること。
２）実行時にＧＵＩオブジェクトを、オブジェクトの属性（クラス、ラベル等）をキーに指定することによって探索できること。

従来、形式仕様からプログラムを導出する方法は数多く研究されてきたが、仕様とプログラムには抽象度に大きな違いがあるため、人手を介する事が避けられなかった。本発明の実施例では、それらとは違って、仕様と機能テストを結びつけるアプローチを採り、形式仕様から自動的に機能テスト・スクリプトを生成する方法を提案した。これは仕様と機能テストの抽象度のレベルが、既に述べたようなギャップはあるにせよ基本的には近いために可能となった。こうした手法はこれまで知られておらず、今後様々な方向への展開が可能である。例えば、１つのスキーマ複合から、正常系とエラー系を含む複数のテスト・スクリプトを生成したり、複数のデータ・プール・レコードを使用して境界値テストを行うスクリプトを生成すること等が考えられる。

ここでは、仕様の記述にＵＭＬを使用した場合の実施例について説明する。

図６は、仕様記述にＵＭＬを使用したシステム構成図を示したものである。この構成では、仕様の記述にＵＭＬのアクティビティ図（アクティビティ・ダイアグラム）（符号６６で示す）を、自動テスト・ツールとして前記の実施例と同様にＲＦＴ６．１．１（符号６４）を使用した。ここでは、ｅｃｌｉｐｓｅ（符号６５）上でＵＭＬ２．０エディタ（符号６１）を用いて作成されたアクティビティ図が、トランスフォ−メーションＡＰＩ（符号６２）を介してテスト・スクリプト・ジェネレータ・プラグイン６３によって解析され、テスト・スクリプト６７が生成される。また、ＲＦＴ６．１．１（符号６４）は、ヘルパーＪａｖａクラス６８（図１の実行時ライブラリ１１に相当する）とＲＦＴデータ・プール６９を参照して、テスト・スクリプト６７を実行することによりテストを行う。以下、詳細に説明する。

（１）仕様の記述方法
まず、ＵＭＬのアクティビティ・ダイアグラムによって仕様を記述する。図７は、このアクティビティ・ダイアグラムの例を示したものであり、ここでアクティビティ・ダイアグラムに現れる各ＵＭＬ要素の役割は以下のとおりである。
・ ＣａｌｌＢｅｈａｖｉｏｒＡｃｔｉｏｎ
個々の画面を表す。図７中のＨｏｍｅ７０，Ｂｒｏｗｓｅ７４等
・ ＩｎｐｕｔＰｉｎ
テキスト・フィールド等のフォーム要素を表す。図７中のｔｉｔｌｅ７９，ｄｅｓｃｒｉｐｔｉｏｎ８０等
・ ＣｏｎｔｒｏｌＦｌｏｗ
画面遷移を表す。図７中のｂｒｏｗｓｅ８１，ｃａｔｅｇｏｒｙ８２等。

また、ＵＭＬプロファイルを定義し、以下のステレオタイプによってＵＭＬ要素を拡張する。
・ ＣａｌｌＢｅｈａｖｉｏｒＡｃｔｉｏｎに対するステレオタイプ：
ａｎｙ（任意の画面を表す）、ｎｏＴｅｓｔ（その画面のテキスト情報と期待値との比較を行わないこと、つまりテスト対象外であることを表す）
・ ＩｎｐｕｔＰｉｎに対するステレオタイプ：
ｔｅｘｔＦｉｅｌｄ（テキスト・フィールドを表す）、ｓｅｌｅｃｔ（リスト・ボックスを表す）、ｒａｄｉｏＢｕｔｔｏｎ（ラジオボタンを表す）、等。
・ ＣｏｎｔｒｏｌＦｌｏｗに対するステレオタイプ：
ｌｉｎｋ（アンカー・タグを表す）、ｓｕｂｍｉｔ（サブミット・ボタンを表す）
図８に、これらＵＭＬステレオタイプとその説明をまとめた。
以下に例を示す。→「例」とは？？？

（２）オブジェクトの動的探索とアクションの起動
生成されるスクリプトを簡潔な形で記述するため、各ＧＵＩオブジェクトに対し、ＲＦＴ ＡＰＩを使用してｗｒａｐｐｅｒ ｃｌａｓｓを作成した。例えばｇｏというサブミット・ボタンをクリックする場合は以下のようになる。

／／ ｉｎｉｔｉａｌｉｚａｔｉｏｎ
Ｓｕｂｍｉｔ ｓｕｂｍｉｔ ＝ ｎｅｗ Ｓｕｂｍｉｔ（ｔｈｉｓ）；
／／ ｂｏｄｙ
：
：
ｓｕｂｍｉｔ．ｃｌｉｃｋ（”ｇｏ”）；

Ｓｕｂｍｉｔクラスの内部ではまず、”ｇｏ”に対応するオブジェクトをブラウザ内で動的に探索する。探索のキーとなるのはオブジェクト・タイプとボタン名称である。ここで”ｇｏ”というのは仕様に現れるサブミット・ボタン名だが、実装時のボタン名称は一般には異なることが予想される。そのためＳｕｂｍｉｔクラスの中でＲＦＴのデータプール（ｄａｔａｐｏｏｌ）にアクセスし、実装名を取得している。但し全ての仕様名に対して実装名をｄａｔａｐｏｏｌに登録することは煩雑なため、ｄａｔａｐｏｏｌに登録されていない場合は仕様上の名称がそのまま使われるという工夫がしてある。次いで探索されたオブジェクトに対しｃｌｉｃｋ ｍｅｔｈｏｄを呼び出している。

（３）画面に表示されるテキストの期待値と、ブラウザ上に表示されるテキストとの比較
画面に表示されるテキストの期待値と、ブラウザ上に表示されるテキストとの比較を行う。例えば図７でＢｒｏｗｓｅ画面に対する期待値をＲＦＴのｄａｔａｐｏｏｌに記述することにより、スクリプトとデータの分離を実現している。ブラウザ上に表示されるテキストを取得するため、ＨｔｍｌＴｅｘｔというｗｒａｐｐｅｒ ｃｌａｓｓを作成し、その内部で”Ｈｔｍｌ．ＨｔｍｌＤｏｃｕｍｅｎｔ”というクラスのオブジェクトを動的に探索する。そのテキスト属性がブラウザ上に表示されるテキストである。期待値と実測値はＲＦＴのＶｅｒｉｆｉｃａｔｉｏｎＰｏｉｎｔクラスを使用して比較を行うことにより、テスト終了時にテスト結果を自動的に得ることができる。また、ブラウザ上に表示される全ての文字を期待値として入力することは煩雑なため、正規表現による期待値入力も行えるようにしてある。

（４）全てのＣｏｎｔｒｏｌＦｌｏｗを通過するテスト・スクリプト生成アルゴリズム
以下のアルゴリズム（４−１）および（４−２）を続いて行うことにより、アクティビティ・ダイアグラム上の全てのＣｏｎｔｒｏｌＦｌｏｗを少なくとも１回通過するテスト・スクリプトを生成する。

（４−１）：幅優先探索による複数のテスト・スクリプトの生成

１）アクティビティ・ダイアグラムの開始端の直後の画面（図７の場合Ｈｏｍｅ）より開始し、初期テスト・スクリプト＜Ｈｏｍｅ＞を得る。

２）テスト・スクリプトの末端の画面を起点とするＣｏｎｔｒｏｌＦｌｏｗの内、通過していないものの数（ｓｉｚｅと呼ぶ）だけ、以下を行う。なお＜＜ａｎｙ＞＞７１というステレオタイプを持つ画面は任意の画面を表すことも考慮する。そのため、例えばＨｏｍｅを起点とするＣｏｎｔｒｏｌＦｌｏｗにはｈｏｍｅ，ｂｒｏｗｓｅ，ｓｅａｒｃｈが含まれる。

３）テスト・スクリプトをｓｉｚｅの数コピーし、それぞれにＣｏｎｔｒｏｌＦｌｏｗの終点の画面を加える。これらのＣｏｎｔｒｏｌＦｌｏｗに通過済みのマークをし、２）へ戻る。

４）全てのテスト・スクリプトに対し、その末端の画面を起点とするＣｏｎｔｒｏｌＦｌｏｗでまだ通過していないものがなくなった時点で終了する。
この結果、図７の場合は以下の３つのテスト・スクリプトが生成される。
・＜Ｈｏｍｅ＞−＜Ｈｏｍｅ＞
・＜Ｈｏｍｅ＞−＜Ｂｒｏｗｓｅ＞−＜Ｃａｔｅｇｏｒｙ＞−＜Ｓｕｂｃａｔｅｇｏｒｙ＞−＜Ｉｔｅｍ＞−＜Ｈｏｍｅ＞
・＜Ｈｏｍｅ＞−＜Ｓｅａｒｃｈ＞−＜ＳｅａｒｃｈＲｅｓｕｌｔｓ＞−＜Ｉｔｅｍ＞−＜Ｈｏｍｅ＞

（４−２）：（４−１）で得られたテスト・スクリプトのマージ
（４−１）で得られたテスト・スクリプトを順番に連結する。この際、ｉ番目のテスト・スクリプトの最後の画面とｉ＋１番目のテスト・スクリプトの最初の画面が同じ場合は、後者を省略する。異なる場合は、アプリケーションのトップ画面（この場合Ｈｏｍｅ）のＵＲＬを指定した遷移を行うことにより、ｉ＋１番目のテスト・スクリプトの最初の画面へ遷移する。この結果、図７の場合以下の１つのテスト・スクリプトに連結される。
＜Ｈｏｍｅ＞−＜Ｈｏｍｅ＞−＜Ｂｒｏｗｓｅ＞−＜Ｃａｔｅｇｏｒｙ＞−＜Ｓｕｂｃａｔｅｇｏｒｙ＞−＜Ｉｔｅｍ＞−（ＵＲＬ遷移）−＜Ｈｏｍｅ＞−＜Ｓｅａｒｃｈ＞−＜ＳｅａｒｃｈＲｅｓｕｌｔｓ＞−＜Ｉｔｅｍ＞−＜Ｈｏｍｅ＞
以上、画面遷移のパスについてさらに詳細なアルゴリズムについては、後述する実施例３で説明する。

（５）Ｆｏｒｍ要素の組み合わせを網羅的に実行するテスト・スクリプトの生成アルゴリズム
ＨＴＭＬのＦｏｒｍ要素のうち、リスト・ボックスやラジオボタンのような複数項目から有限個を選択するもの（図７ではｔｉｔｌｅＯｐｔｉｏｎ，ｄｅｓｃｒｉｐｔｉｏｎＯｐｔｉｏｎ，ｃａｔｅｇｏｒｙＳｅｌｅｃｔｉｏｎ）については、その組み合わせを網羅的にテストする。図７のアプリケーションの場合、ｔｉｔｌｅＯｐｔｉｏｎが２通り、ｄｅｓｃｒｉｐｔｉｏｎＯｐｔｉｏｎが２通り、ｃａｔｅｇｏｒｙＳｅｌｅｃｔｉｏｎが７通りあるので、合計２×２×７＝２８回Ｆｏｒｍ要素を含む画面（Ｓｅａｒｃｈ画面）を繰り返し実行する必要がある。この繰り返し実行を最短のパスで行うため、以下のアルゴリズムを用いる。

１）Ｆｏｒｍ画面を起点とし、再びＦｏｒｍ画面に戻るパスのうち最小のものを求める。図７の場合、＜Ｓｅａｒｃｈ＞−＜ＳｅａｒｃｈＲｅｓｕｌｔｓ＞−＜Ｓｅａｒｃｈ＞が見出される。但し一般にはこのようなパスが存在するとは限らない。
２）Ｆｏｒｍ画面の次の画面からＵＲＬ遷移によってアプリケーションのトップ画面に遷移し、そこからＦｏｒｍ画面へいたるパスのうち、最小のものを求める。このようなパスは必ず存在する。
３）１と２のパスの長さを比較し、短い方のパスを用いて繰り返し実行を行う。
以上のＦｏｒｍ要素の組み合わせを網羅的にテストする最適の方法については実施例４でさらに説明する。

図９は、生成されたテスト・スクリプトの例である。符号９１で示される部分は、ヘルパークラスのインスタンス化によって得られる部分を示している。また、ユーザの画面操作において、符号９２で示される部分はリスト・ボックスの選択に、符号９３で示される部分はテキスト・フィールドのセットに、符号９４で示される部分はラジオ・ボタンの選択に、符号９５で示される部分はサブミット・ボタンのクリックに対応している。また、符号９６で示される部分は、テキストの比較に用いられる。

図１０には、ＧＵＩオブジェクトの動的探索を示す例として、”Ｒａｄｉｏ Ｂｕｔｔｏｎ”を探索する場合を示してある。探索キーはＣｌａｓｓ， Ｎａｍｅ， Ｖａｌｕｅの３つであるが、まずＣｌａｓｓキーはＲａｄｉｏ ＢｕｔｔｏｎヘルパークラスのインスタンスであることからＨｔｍｌ．ＩＮＰＵＴ．ｒａｄｉｏに確定する。また、ｓｅｌｅｃｔメソッドの第１引数の”ｃａｔｅｇｏｒｙＳｅｌｅｃｔｉｏｎ”をキーとしてデータ・プール９７を検索し、実装名”ｄｅｔａｉｌｅｄＳｅｒａｒｃｈＦｏｒｍ：ｒａｄｉｏ１”を得る。これがＮａｍｅキーとなる。ｓｅｌｅｃｔメソッドの第２引数である”Ａｌｌ”についても同様にデータ・プール９７上を検索するが、対応するエントリーが存在しないので仕様上の名称であるＡｌｌ自体がＶａｌｕｅキーとして使用される。これら３つのきーによりＧＵＩオブジェクトが動的に探索され、ラジオボタン群９９のうちから”Ａｌｌ Ｃａｔｅｇｏｒｉｅｓ”ボタンが取得される。

ここではこれまで述べてきたテスト・スクリプトについて、さらに冗長度の小さいものを生成するアルゴリズムについて説明する。

コンピュータ・アプリケーションの画面のナビゲーションは、１つのＨｏｍｅノードを起点とする有向グラフとして考えることができる。図１１はこの有向グラフを模式的に表したものである。画面はノードに対応して１，２等と記され、画面遷移はエッジに相当して（１，４）等と記述される。また、Ｈｏｍｅを起点とする連続した画面遷移をパスといい、（Ｈ，１，４）等と記す。Ｈｏｍｅを起点としない連続した画面遷移をサブパスと呼び、（１，４，６）等がある。

機能テストにおけるパス・カバレージの観点からは、
（ａ）全てのエッジを少なくとも１回通過するパスの集合を求めること
が必要となる。図１１の場合、例えば以下の集合Ａがこの条件を満たす。

集合Ａ＝｛（Ｈ，１，４，６），（Ｈ，２，６，Ｈ），（Ｈ，２，６，１），（Ｈ，３，５，７），（Ｈ，３，５，８，３）｝

但し、この集合ではエッジＨ→２，２→６，Ｈ→３，３→５をそれぞれ２度通過しているので冗長である。冗長度を表すために各エッジに対して通過回数を定義する。通過回数とはパスの集合によって各エッジが何回通過されるかを表す。集合Ａの場合これら４つのエッジの通過回数は２、それ以外のエッジの通過回数は１である。したがって、（ａ）の条件を満たし、かつ
（ｂ）通過回数の総和がなるべく小さくなるパスの集合を求めること
が望ましい。

（１）幅優先方式
（ａ）の条件を満たす簡単なアルゴリズムとして、幅優先方式が考えられる。この方法は、Ｈｏｍｅから始め、エッジが分岐するごとにパスをコピーしていく方法である。

＜アルゴリズム１＞
Ｐａｔｈｓ ＝ ｛（Ｈ）｝；
Ｏｕｔｐｕｔ ＝ ｛｝；
ｗｈｉｌｅ （Ｐａｔｈｓが空ではない） ｛
ＮｅｘｔＰａｔｈｓ ＝ ｛｝；
ｆｏｒ （Ｐａｔｈｓに含まれる全てのＰａｔｈについて） ｛
ＣｏｐｙＮｕｍ ＝ （Ｐａｔｈの末端のＮｏｄｅを起点とするエッジで未通過のものの数）；
ｉｆ （ＣｏｐｙＮｕｍ！＝ ０） ｛
ＣｏｐｙＮｕｍだけ、Ｐａｔｈをコピーする。；
コピーされた各パスの先端に、それぞれのエッジを追加する。；
ＮｅｘｔＰａｔｈｓにそれらのパスを追加する。；
｝
ｅｌｓｅ ｛
ＯｕｔｐｕｔにＰａｔｈを追加する。；
｝
｝
Ｐａｔｈｓ ＝ ＮｅｘｔＰａｔｈｓ；
｝
結果 ＝ Ｏｕｔｐｕｔ；

図１１にこの方式を適用した場合に、ｗｈｉｌｅ文の条件判断時にＰａｔｈｓとＯｕｔｐｕｔがどのように変化するかを図１２に示す。

（２）深さ優先方式
幅優先方式で生成されるパスの集合は冗長度が高く、また生成のために一時点で使用されるメモリ量が多いという欠点がある。これらを低減させる方式として、Ｈｏｍｅから可能な限りエッジをたどっていく深さ優先方式が考えられる。但し、単純な深さ優先方式だと通過できないエッジが生じるため、工夫が必要である。まず、以下を定義する。

定義：Ｈｏｍｅノードからノードへの距離
Ｈｏｍｅノードからそのノードに到達するために必要な最短のステップ数。例えば、図１１でＨｏｍｅノードからノード４への距離は２である。
定義：Ｈｏｍｅノードからエッジへの距離
Ｈｏｍｅノードからエッジの起点ノードへの距離。例えば、図１１でＨｏｍｅノードからエッジ（４，６）への距離は２である。

＜アルゴリズム２＞
Ｅｄｇｅｓ ＝ ｛全てのエッジの集合｝；
Ｏｕｔｐｕｔ ＝ ｛｝；
ｗｈｉｌｅ （Ｅｄｇｅｓが空でない） ｛
Ｅｄｇｅｓから、Ｈｏｍｅからの距離が一番短いＥｄｇｅＡを任意に１つ選ぶ。；
ＥｄｇｅＡにＥｄｇｅｓに属する他のエッジＥｄｇｅＢを連結する。ここで（ＥｄｇｅＡの終点ノード）＝（ ＥｄｇｅＢの起点ノード）である。このようなＥｄｇｅＢが複数存在する場合は、任意に１つを選ぶ。以下同様にＥｄｇｅＣ， ＥｄｇｅＤ，．．．等が存在する限り、連結していく。但し、Ｈｏｍｅに到達した場合は終了する。得られたサブパスをＳｕｂｐａｔｈとする。；
Ｓｕｂｐａｔｈに属するエッジをＥｄｇｅｓから取り除く。；
ＨｏｍｅとＳｕｂｐａｔｈの起点ノードを結ぶ最短のパス（複数ある場合は任意に選択）をＳｕｂｐａｔｈに連結する。得られたパスをＰａｔｈとする。；
ＯｕｔｐｕｔにＰａｔｈを追加する。；
｝
結果 ＝ Ｏｕｔｐｕｔ；

図１１の有向グラフにこの方式を適用した場合に、ｗｈｉｌｅ文の条件判断時にＥｄｇｅｓとＯｕｔｐｕｔがどのように変化するかを図１３に示す。なお、このアルゴリズムでは任意に選択する部分が３箇所あるため、これ以外の結果になる場合もある。

（３）深さ優先−結合方式
（２）で述べた方式は（１）に比べると冗長度が小さいが、図１１の有向グラフに適用した結果では（Ｈ，３，５，７）と（Ｈ，３，５，８，３）のパスにおいて（Ｈ，３，５）の部分が２度通過されている。

この点を改良した以下のアルゴリズム３を図１４のフローチャートに示す。以下、「中間ノード」とはパスに含まれるノードのうち、Ｈｏｍｅノードとも末端ノードとも異なるノードと定義する。

＜アルゴリズム３＞
Ｉｎｐｕｔ ＝ ｛深さ優先方式を適用した結果得られるパスの集合｝；
ｄｏ ｛
Ｐａｔｈ ＝ （Ｉｎｐｕｔに含まれる）ＡＮＤ（末端のノードが、Ｉｎｐｕｔに含まれる別のパスＰａｔｈＡの中間ノードと一致する）；
ｉｆ （Ｐａｔｈが存在する） ｛
Ｐａｔｈが複数存在する場合は、任意に１つ選択する；
Ｎｏｄｅ ＝ （Ｐａｔｈの末端ノード）；
ｉｆ （ＰａｔｈＡのＨｏｍｅとＮｏｄｅの間の全エッジの通過回数が２以上） ｛
Ｓｕｂｐａｔｈ ＝ （ＰａｔｈＡのＮｏｄｅと末端ノードの間の部分）；
ＰａｔｈにＳｕｂｐａｔｈを連結する；
ＰａｔｈＡのＨｏｍｅとＮｏｄｅの間の全エッジの通過回数を１減らす；
ＰａｔｈＡをＩｎｐｕｔから除く；
｝
｝
ｅｌｓｅ ｛
ｂｒｅａｋ；
｝
｝ ｗｈｉｌｅ （ｔｒｕｅ）
結果 ＝ Ｉｎｐｕｔ；

本方式を図１１に適用すると、結果として｛（Ｈ，１，４，６，Ｈ），（Ｈ，２，６，１），（Ｈ，３，５，８，３，５，７）｝が得られる。

以上をまとめると以下のとおりである。まず、冗長度をあるパスの集合において、全エッジの通過回数の総和からエッジの数を引いたものであると定義する。各方式を図１１の有向グラフに適用した場合の、冗長度の違いを図１５に示した。なお、図１１の場合ではこれ以上改善するのは不可能である。

ここでは、Ｆｏｒｍ要素の任意の組み合わせのテストを、最短の画面遷移で行うパスの集合を求める方法について説明する。一般にアプリケーションの画面は、図１６に示されるようなＦｏｒｍ要素を有する場合が多い。図１６の場合は図１７で示されるようなＦｏｒｍ要素を持つ。これらのＦｏｒｍ要素は、図１６の画面中では、Ｔｉｔｌｅ１２１のリスト・ボックス（選択肢の数２とする）、Ｄｅｓｃｒｉｐｔｉｏｎ１２３のリスト・ボックス（選択肢の数２とする）、Ｄｏｃｕｍｅｎｔ Ｄａｔｅｄ１２７のリスト・ボックス（選択肢の数３とする）、Ｄｉｓｐｌａｙ Ｒｅｓｕｌｔｓ１２８のリスト・ボックス（選択肢の数５）、Ｓｅｒａｃｈ ｉｎ Ｃａｔｅｇｏｒｉｅｓ１２９のラジオボタン（選択肢の数７）で示されている。但し、ＴｅｘｔＦｉｅｌｄ１２２，１２４，１２５，１２６は除いてある。

Ｆｏｒｍ要素を漏れなくテストするという観点からは、これらの任意の組み合わせをテストできることが望ましい。そのためには、４２０＝２×２×３×５×７回、この画面を反復実行する必要がある。

今、この画面が図１１のノード５であり、Ｓｅａｒｃｈ．．．ボタン１３０を押すことによってノード８へ遷移するものとする。Ｆｏｒｍ要素の組み合わせをくまなくテストするためエッジ（５，８）を４２０回実行する必要がある。ノード８への遷移の直後に再びノード５へ遷移できれば最短であるが、一般には不可能である。例えばアプリケーションがＷｅｂアプリケーションの場合、ブラウザーのロケーション・フィールドにノード５のＵＲＬを指定することができるが、アプリケーションは内部でステートを保持しているためエラーになることが多い。一般にそのような強制的な遷移はＨｏｍｅノードに対してのみ可能である。

したがって確実な方法は、ノード８への遷移後、Ｈｏｍｅノードへ直接遷移し（Ｈ，３，５）というパスをたどることである。これをＨｏｍｅ遷移方式と呼ぶ。この方式は、必ずしも最短のパスを与えるわけではない。この点を改良したアルゴリズム（Ｆｏｒｍ画面遷移方式）を以下に述べる。

まず、以下の定義を行う。
定義：Ｆｏｒｍノード
ＦｏｒｍノードとはＦｏｒｍ要素を有するノードである。例えば、図１１のノード５に相当する。
定義：Ｆｏｒｍ実行結果ノード
Ｆｏｒｍ実行結果ノードとは、Ｆｏｒｍノードを実行後に遷移するノードである。例えば図１１のノード８に相当する。また以下、記号「＋＝」は、左辺のパスの最後尾に右辺のパスを連結することを表すものとする。

＜アルゴリズム４＞
ＦｏｒｍノードをＮｏｄｅＡ、Ｆｏｒｍ実行結果ノードをＮｏｄｅＢとする。ＮｏｄｅＡへのパスをＰａｔｈＡとする。ＨｏｍｅノードとＮｏｄｅＡの距離をｘとする。Ｆｏｒｍノードの反復実行回数をＮとする。；
ＮｏｄｅＢからＮｏｄｅＡへの最短距離をＤｉｊｋｓｔｒａ法によって求めｙとし、そのサブパスをＳｕｂｐａｔｈとする。到達できない場合、ｙは＋無限大とする。；

ｉｆ （ｘ＋１ ＞ ｙ） ｛
Ｐａｔｈ ＝ ＰａｔｈＡ；
Ｐａｔｈ ＋＝ （ＮｏｄｅＡ，ＮｏｄｅＢ）；
Ｆｏｒ （ｉｎｔ ｉ＝０； ｉ＜Ｎ−１； ｉ＋＋） ｛
Ｐａｔｈ ＋＝ Ｓｕｂｐａｔｈ；
Ｐａｔｈ ＋＝ （ＮｏｄｅＡ，ＮｏｄｅＢ）；
｝
｝
ｅｌｓｅ ｛
Ｐａｔｈ ＝ ｎｕｌｌ；
ｆｏｒ （ｉｎｔ ｉ＝０； ｉ＜Ｎ−１； ｉ＋＋） ｛
Ｐａｔｈ ＋＝ ＰａｔｈＡ；
Ｐａｔｈ ＋＝ （ＮｏｄｅＡ，ＮｏｄｅＢ）；
Ｐａｔｈ ＋＝ （ＮｏｄｅＢ，Ｈｏｍｅ）；
｝
Ｐａｔｈ ＋＝ ＰａｔｈＡ；
Ｐａｔｈ ＋＝ （ＮｏｄｅＡ，ＮｏｄｅＢ）；
｝
結果 ＝ Ｐａｔｈ；

図１８は、アルゴリズム４を示したフローチャートである。

Ｈｏｍｅ遷移方式とＦｏｒｍ画面遷移方式を図１１の有向グラフに適用した場合の、画面遷移の実行回数を図１９にまとめた。Ｆｏｒｍ画面遷移方式では実行回数が少なくてすむことが判る。

ここでは、データ・プールの存在や、その中のエントリーの存在を仮定しない構成を考える。

Ｆｏｒｍ要素に対して、設計時に使用する名称と実装時に使用する名称は一般に異なる。例えばあるラジオボタンを設計時にはｃａｔｅｇｏｒｙＳｅｌｅｃｔｉｏｎと名付ける一方、実装時には（標準化などの理由により）ｄｅｔａｉｌｅｄＳｅａｒｃｈＦｏｒｍ：ｒａｄｉｏ１と命名することがある。この両者のマッピングをとるために、本発明ではデータ・プールを使用することを可能にしている。但し、データ・プールは使用しない構成も可能である。その場合、設計時に使用する名称がそのまま実装時にも使用されていると仮定する。さらにこの両者は混在することが可能である。即ち、あるＦｏｒｍ要素はデータ・プールを用いて設計時名称から実装時名称へマッピングする一方、別のＦｏｒｍ要素は設計時名称をそのまま使用するという構成が可能である。

混在構成を可能にする実装例を図２０に示す。符号１８０で示す行でデータ・プールにアクセスしているが、設計時名称をキーとするエントリーが存在しない場合は例外が発生し、設計時名称がそのまま使用される（符号１８１で示される行）。

（１）期待値での正規表現の使用
機能テスト実行時には、画面の実測値と期待値の比較が行われる。これはそれぞれの文字列の比較によって行われるが、一般に実測される文字列の量は膨大なものになりうるため、それと一致する期待値を入力することは労力を要し、また、入力ミスもあり得る。この問題に対処するため、本発明では期待値に正規表現を使用することを可能とした。例えば、実測される文字列「２００６年１月１６日 月曜日 Ｓｅａｒｃｈ ｆｏｒ Ｌｏｃａｔｉｏｎ Ｕｓｅｒｎａｍｅ Ｐａｓｓｗｏｒｄ」に対して、“．＊Ｓｅａｒｃｈ ｆｏｒ Ｌｏｃａｔｉｏｎ．＊”という正規表現で文字列を指定することにより、テストを成功させることができる。ここで、「．＊」は、任意のゼロ以上の文字を表すメタ文字である。

図２１は、図１で説明したテスト・スクリプト生成装置１０の典型的な例として情報処理装置１００を示したものである。以下、この情報処理装置１００のハードウェア構成の一例を示す。情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＡＲＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、並びにキーボードおよびマウス・アダプタ等１１００の入力手段１１５を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハード・ディスク１０７４、光ディスクドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。

音声プロセッサ１０３０には、増幅回路１０３２およびスピーカ１０３４が接続される。また、グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。

ＢＩＯＳ１０６０は、情報処理装置１００の起動時にＣＰＵ１０１０が実行するブートプログラムや、情報処理装置１００のハードウェアに依存するプログラム等を格納する。フレキシブル・ディスクドライブ１０７２は、フレキシブル・ディスク１０７１からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供する。

光ディスクドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク１０７７から光ディスクドライブ１０７６によりプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供することもできる。

情報処理装置１００に提供されるコンピュータ・プログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて利用者によって提供される。このコンピュータ・プログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、情報処理装置１００にインストールされ実行される。コンピュータ・プログラムが情報処理装置に働きかけて行わせる動作は、図１から図２０において説明したテスト・スクリプト生成装置１０における動作と同一であるので省略する。

前述のコンピュータ・プログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体、を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハード・ディスクまたは光ディスクライブラリー等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータ・プログラムを情報処理装置１００に提供してもよい。

以上の例は、情報処理装置１００について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。したがって、本発明において一つの実施形態として説明した情報処理装置は、方法およびそのコンピュータ・プログラムによっても実現可能である。

本発明の装置は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。かかる場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明にかかる処理を実行させる。このプログラムは、任意の言語、コード、または表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、または（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ可読媒体に格納することができる。かかるプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明の好適な実施形態における、テスト・スクリプト生成装置１０の機能ブロック図である。 本発明の実施例１において、「Ｂｒｏｗｓｅ」という名称を持つ単純なスキーマの例を示した図である。 本発明の実施例１において、スクリプトの生成方法とそれを用いた処理の流れ（１／２）を示した図である。 本発明の実施例１において、スクリプトの生成方法とそれを用いた処理の流れ（２／２）を示した図である。 本発明の実施例１において、ｅｃｌｉｐｓｅ上のプラグインとしてＺ言語エディタを実装し、ＲＦＴと連携させたシステム構成を示す図である。 本発明の実施例２において、仕様記述にＵＭＬを使用したシステム構成を示した図である。 本発明の実施例２において、ＵＭＬのアクティビティ・ダイアグラムの例を示した図である。 本発明の実施例２において、ＵＭＬステレオタイプとそのディスクリプションをまとめた図である。 本発明の実施例２において、画面遷移の実行回数を示した図である。 本発明の実施例２において、ＧＵＩオブェクトの動的探索を示す図である。 本発明の実施例３において、画面のナビゲーションを有向グラフで表した図である。 本発明の実施例３において、アルゴリズム１を図１１の有向グラフに適用した場合にＰａｔｈｓとＯｕｔｐｕｔがどのように変化するかを示した図である。 本発明の実施例３において、アルゴリズム２を図１１の有向グラフに適用した場合にＰａｔｈとＯｕｔｐｕｔがどのように変化するかを以下に示した図である。 本発明の実施例３において、アルゴリズム３を示したフローチャートである。 本発明の実施例３において、各方式を図１１の有向グラフに適用した場合の、冗長度の違いを示した図である。 本発明の実施例４において、Ｆｏｒｍ要素を有するアプリケーション画面の例を示す図である。 本発明の実施例４において、Ｆｏｒｍ要素と選択肢の数を示した図である。 本発明の実施例４において、アルゴリズム４を示したフローチャートである。 本発明の実施例４において、各方式による画面遷移実行回数の違いを示した図である。 本発明の実施例５において、データ・プールの存在や、その中のエントリーの存在を仮定しない構成において設計時名称と実装時名称が混在する構成を可能にする実装例を示した図である。 テスト・スクリプト生成装置１０の典型的ハードウェア例として情報処理装置１００を示した図である。

符号の説明

１ 仕様ファイル
２ 入出力変数抽出部
３ 画面遷移抽出部
４ 入出力変数
５ 入出力変数タイプ
６ 画面遷移情報
７ テスト・スクリプト生成部
８ テスト・スクリプトファイル
１０ テスト・スクリプト生成装置
１１ 実行時ライブラリ部
１２ テスト対象アプリケーション
１３ 自動テスト実行ツール
２０ 形式仕様
２１ 宣言部
２２ 公理部
２３ ｓｃｈｅｍａ
２４ ｓｃｈｅｍａ ｃｏｍｐｏｓｉｔｉｏｎ
３１ 入力変数ｂｏｏｋ
３２ 出力変数ａｂｓｔｒａｃｔ
３３ プロパティ・ファイル
３４ 機能テスト・スクリプト
３５ データ・プール
５１ Ｚ言語エディタ
５２ ＪＦａｃｅテキストエディタ・フレームワーク
５３ ｅｃｌｉｐｓｅランタイム
５４ ＲＦＴ
５５ テスト・スクリプト
５６ クラス・ライブラリ
５７ ＲＦＴテータ・プール
６０ ＵＭＬ仕様解析部
６１ ＵＭＬ２．０エディタ
６２ トランスフォーメーションＡＰＩ
６３ テスト・スクリプト・ジェネレータ・プラグイン
６４ ＲＦＴ６．１．１
６６ アクティビティ図
６７ テスト・スクリプト
６８ ヘルパーＪａｖａクラス
６９ ＲＦＴテータ・プール
７０ Ｈｏｍｅ画面
７１ Ａｌｌ Ｓｃｒｅｅｎ
７２ Ｓｅａｒｃｈ画面
７３ ＳｅａｒｃｈＲｅｓｕｌｔｓ
７４ Ｂｒｏｗｓｅ画面
７５ Ｃａｔｅｇｏｒｙ画面
７６ Ｓｕｂｃａｔｅｇｏｒｙ画面
７７ Ｉｔｅｍ画面
７８ ＣａｔｅｇｏｒｙＳｅｌｅｃｔｉｏｎ
７９ ｔｉｔｌｅ
８０ ｄｅｓｃｒｉｐｔｉｏｎ
８１ ｂｒｏｗｓｅ
８２ ｃａｔｅｇｏｒｙ
９１ ヘルパークラス・インスタンス化
９２ リスト・ボックス選択
９３ テキスト・フィールド・セッティング
９４ ラジオボタン選択
９５ サブミット・ボタン・クリック
９６ テキスト比較
９７ データ・プール
９８ テーブル
９９ ラジオボタン群
１００ 情報処理装置

Claims (16)

1. ソフトウェアの機能仕様から該ソフトウェアの機能テストを実行するためのテスト・スクリプトを生成する装置であって、
   前記機能仕様を記述した仕様ファイルから前記ソフトウェアが生成させる実行時の表示画面ごとに、入力変数、出力変数、入力変数タイプ、および出力変数タイプを抽出する入出力変数抽出部と、
   前記仕様ファイルから画面遷移情報を抽出する画面遷移抽出部と、
   前記入力変数、前記出力変数、前記入力変数タイプ、前記出力変数タイプ、および前記画面遷移情報を用いて、前記機能テストの実行のためのテスト・スクリプトを生成するテスト・スクリプト生成部と、
   を備えた装置。
2. 前記テスト・スクリプト生成部は、前記画面遷移情報に基づいて、
   前記入力変数に対しては、該入力変数に関連付けられたオブジェクトに対応するアクションを表すテスト・スクリプトを生成し、
   前記出力変数に対しては、前記ソフトウェアが実行時に生成させる表示画面に表示されるテキスト情報を該出力変数から決定される期待値と比較するテスト・スクリプトを生成する、
   請求項１に記載の装置。
3. 前記オブジェクトは、ボタン、テキスト・フィールド、またはリスト・ボックスを含み、前記アクションは、ユーザのクリック操作、文字列の入力操作、またはリストからの選択操作を含む、請求項２に記載の装置。
4. 前記テスト・スクリプト生成部は、画面をノード、画面遷移をエッジとする有向グラフにおいて、前記画面遷移の全てのエッジを少なくとも１回通過し、かつ前記全てのエッジの通過回数の総和から前記エッジの数を引いた冗長度が所定の値より小さくなるようなパス集合を求めることによりテスト回数の最適化を行う、請求項１に記載の装置。
5. 前記パス集合は、所定の「深さ優先−結合アルゴリズム」によって求める、請求項４に記載の装置。
6. 前記テスト・スクリプト生成部は、前記ソフトウェアが生成させる実行時の表示画面を構成するＦｏｒｍ要素の任意の組み合わせのテストのため、所定の「Ｆｏｒｍ画面遷移アルゴリズム」に基づいて、最短の画面遷移で行うパス集合を求める、請求項１に記載の装置。
7. 前記仕様ファイルは、Ｚ言語を用いて記述される、請求項１に記載の装置。
8. 前記テスト・スクリプト生成部は、前記入力変数に関連付けられたオブジェクトのタイプを、（１）所定のコントロール・プロパティ・ファイルに記述されているオブジェクト・タイプ、（２）該入力変数の属性を表すタイプ名がＳｅｓｓｉｏｎ、Ｓｕｂｍｉｔ、Ｐａｓｓｗｏｒｄのいずれかの場合は、前記タイプ名と同じオフジェクト・タイプ、（３）Ｌｉｎｋオブジェクト・タイプ、の順に低くなる優先順位に基づいて決定する、請求項７に記載の装置。
9. 前記テスト・スクリプトは、前記入力変数に関連付けられたオブジェクトを、テスト対象画面を表示するブラウザ内で前記オブジェクトのタイプとオブジェクト名称をキーとして動的に探索するために、アプリケーションのテスト実行時に呼び出される実行時ライブラリを用いる、請求項１に記載の装置。
10. 前記仕様ファイルは、ＵＭＬのアクティビティ図により記述される、請求項１に記載の装置。
11. 前記ＵＭＬのアクティビティ図は、画面要素、Ｆｏｒｍ要素、および画面遷移要素のうち少なくとも一つのＵＭＬ要素で構成される、請求項１０に記載の装置。
12. ソフトウェアの機能仕様から該ソフトウェアの機能テストを実行するためのテスト・スクリプトを生成する方法であって、
    前記機能仕様を記述した仕様ファイルから前記ソフトウェアが生成させる実行時の表示画面ごとに、入力変数、出力変数、入力変数タイプ、および出力変数タイプを抽出するステップと、
    前記仕様ファイルから画面遷移情報を抽出するステップと、
    前記入力変数、前記出力変数、前記入力変数タイプ、前記出力変数タイプおよび前記画面遷移情報を用いて、前記機能テストの実行のためのテスト・スクリプトを生成するステップと、
    を含む方法。
13. 前記生成するステップは、画面をノード、画面遷移をエッジとする有向グラフにおいて、前記画面遷移の全てのエッジを少なくとも１回通過し、かつ前記全てのエッジの通過回数の総和から前記エッジの数を引いた冗長度が所定の値より小さいパス集合を求めることによりテスト回数の最適化を行う、請求項１２に記載の方法。
14. 前記生成するステップは、前記ソフトウェアが生成させる表示画面を構成するＦｏｒｍ要素の任意の組み合わせのテストのため、所定の「Ｆｏｒｍ画面遷移アルゴリズム」に基づいて、最短の画面遷移で行うパス集合を求める、請求項１２に記載の方法。
15. 前記仕様ファイルは、Ｚ言語またはＵＭＬを用いて作成される、請求項１３に記載の方法。
16. ソフトウェアの機能仕様から該ソフトウェアの機能テストを実行するためのテスト・スクリプトを生成するコンピュータ・プログラムであって、
    コンピュータに、
    前記機能仕様を記述した仕様ファイルから前記ソフトウェアが生成させる実行時の表示画面ごとに、入力変数、出力変数、入力変数タイプ、および出力変数タイプを抽出するステップと、
    前記仕様ファイルから画面遷移情報を抽出するステップと、
    前記入力変数、前記出力変数、前記入力変数タイプ、前記出力変数タイプおよび前記画面遷移情報を用いて、前記機能テストの実行のためのテスト・スクリプトを生成するステップと、
    を実行させるコンピュータ・プログラム。

Images