JP2004220330A - テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム - Google Patents
テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム Download PDFInfo
- Publication number
- JP2004220330A JP2004220330A JP2003007024A JP2003007024A JP2004220330A JP 2004220330 A JP2004220330 A JP 2004220330A JP 2003007024 A JP2003007024 A JP 2003007024A JP 2003007024 A JP2003007024 A JP 2003007024A JP 2004220330 A JP2004220330 A JP 2004220330A
- Authority
- JP
- Japan
- Prior art keywords
- test
- test scenario
- rule
- scenario generation
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】テスト方針の蓄積・再利用を可能にして統一した手順でテスト仕様書を効率的に作成し得るテスト仕様作成支援装置、テスト仕様作成方法、この方法をコンピュータに実行させるテスト仕様作成プログラムおよびこの方法に用いるデータベースの構築方法を提供すること。
【課題手段】開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、ソフトウエアの設計仕様から定義し、テストシナリオ生成ルールの条件部とソフトウエアの設計仕様とのマッチングをとって、テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成する。
【選択図】 図１
【課題手段】開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、ソフトウエアの設計仕様から定義し、テストシナリオ生成ルールの条件部とソフトウエアの設計仕様とのマッチングをとって、テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、開発すべきソフトウエアをテストするためのテスト仕様作成支援装置、テスト仕様作成方法、この方法をコンピュータに実行させるテスト仕様作成プログラムおよびこの方法に用いるデータベースの構築方法に係り、特に、テスト仕様の効率的な生成に適するテスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、およびテスト仕様作成プログラムに関する。
【０００２】
【従来の技術】
単体テストが完了したプログラム実体間を組み合わせて実体間のインターフェースや機能またはサブシステムの相互作用を検証する結合テストでは、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）により、テストの内容および合格の判断基準は異なる。従来の技術では、ＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）など外部仕様に関するテスト支援が中心で（例えば下記特許文献１、２参照）、外部仕様に限られない処理機能の種類を考慮した結合テスト仕様の自動生成までは行なわれていなかった。また、従来技術には、処理機能の性質を考慮したテストのノウハウなどとしてのデータの表現形態が開示されておらず、ノウハウの蓄積・再利用ができなかった。
【０００３】
【特許文献１】
特開２００２−７３３７２号公報
【特許文献２】
特開平９−２２３０４０号公報
【０００４】
【発明が解決しようとする課題】
本発明は、上記の事情を考慮してなされたもので、テスト方針の蓄積・再利用を可能にして統一した手順でテスト仕様書を効率的に作成し得るテスト仕様作成支援装置、テスト仕様作成方法、この方法をコンピュータに実行させるテスト仕様作成プログラムおよびこの方法に用いるデータベースの構築方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の課題を解決するため、本発明に係るテスト仕様作成支援装置は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義する手段と、前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成する手段とを具備することを特徴とする。
【０００６】
すなわち、この装置はテストシナリオ生成ルールを定義する手段を具備し、テストシナリオ生成ルールは、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したものである。定義されたテストシナリオ生成ルールにより、その条件部および実行部を用い、条件部と設計仕様とのマッチングをとって実行部を実行するという手順が提供される。この手順によれば、テスト方針の蓄積・再利用をテストシナリオ生成ルールの蓄積・再利用という形で可能にし、統一した手順でテスト仕様書を効率的に作成することが可能になる。
【０００７】
ここでソフトウエアのテストの観点および判断基準は、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）に応じて決めることができる。
【０００８】
また、上記の各手段は、例えば、マイクロプロセッサやメモリなどのハードウエハとこのハードウエア上で動作する基本ソフトウエアおよび応用ソフトウエアとにより実現できる。
【０００９】
また、本発明に係るテスト仕様作成方法は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義するステップと、前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成するステップとを具備することを特徴とする。
【００１０】
この方法は、上記のテスト仕様作成支援装置における動作を実現するものであり、この方法によれば、上記同様の作用により同様の効果を得ることができる。方法ではなく、各ステップを実行するプログラムとすることもできる。
【００１１】
また、本発明に係るデータベースの構築方法は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールをデータベース化するデータベースの構築方法であって、前記条件部には前記ソフトウエアのテストの観点が表現され前記実行部には前記条件部が前記ソフトウエアの設計仕様に含まれていた場合に実行する判断基準が表現されている前記テストシナリオ生成ルールの前記条件部と前記実行部とをまとめて個々のテストシナリオ生成ルールごとにノードとしてくくり、前記ノード間に、該ノードに対応するテストシナリオ生成ルールを適用する順序情報を与えることを特徴とする。
【００１２】
また、本発明に係る別のデータベースの構築方法は、開発すべきソフトウエアの設計仕様情報をデータベース化するデータベースの構築方法であって、前記設計仕様に含まれる個々の動作ごとの処理仕様をそれぞれノードとしてくくり、前記ノード間に、該ノードに対応する処理仕様の流れを示す情報を与え、前記ノード間に、ひとつのアプリケーションを示す情報を与えることを特徴とする。
【００１３】
また、本発明に係るさらに別のデータベースの構築方法は、開発すべきソフトウエアのテストシナリオをデータベース化するデータベースの構築方法であって、前記テストシナリオに含まれる個々のテストごとにノードとしてくくり、前記ノード間に、該ノードに対応するテストの実施順序を示す情報を与えることを特徴とする。
【００１４】
これらのデータベースの構築方法は、上記のテスト仕様作成支援装置および方法において使用することができるものである。また、これらにより、処理機能の性質を考慮したテストのノウハウとしてのデータの表現形態が開示される。
【００１５】
【発明の実施の形態】
本発明の実施態様としてのテスト仕様作成支援装置は、前記設計仕様を入力する手段と、前記入力された設計仕様を蓄積する手段と、前記蓄積された設計仕様の中から任意のものを取り出す手段とをさらに具備する。装置の使い勝手を向上するため設計仕様の入力、蓄積、検索手段を設けるものである。
【００１６】
また、実施態様として、前記定義されたテストシナリオ生成ルールを蓄積する手段と、前記蓄積されたテストシナリオ生成ルールの中から任意のものを取り出す手段とをさらに具備する。同様に、テストシナリオ生成ルールの蓄積、検索手段を設けるものである。
【００１７】
また、実施態様として、前記定義する手段は、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出する手段と、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義する手段とを含む。設計仕様からテストの観点および判断基準を抽出するのを自動的に行なうものである。抽出されたテストの観点および判断基準はテストシナリオ生成ルールを作成するためのメタルールの一部とすることができる。
【００１８】
また、実施態様として、前記生成されたテストシナリオを蓄積する手段と、前記蓄積されたテストシナリオの中から任意のものを取り出す手段とをさらに具備する。装置の使い勝手を向上するためテストシナリオの蓄積、検索手段を設けるものである。
【００１９】
また、実施態様として、前記生成する手段は、前記設計仕様を展開保持する設計仕様展開保持部と、前記テストシナリオ生成ルールを展開保持するテストシナリオ生成ルール展開保持部と、前記展開保持された設計仕様と前記展開保持されたテストシナリオ生成ルールとからテストシナリオを生成するテストシナリオ生成エンジンと、前記生成されたテストシナリオを展開保持するテストシナリオ展開保持部とを含む。生成する手段を構成するひとつの例である。
【００２０】
また、本発明の実施態様としてのテスト仕様作成方法において、前記定義するステップは、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出するステップと、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義するステップとを含む。装置の場合と同様である。
【００２１】
また、実施態様として、前記生成するステップは、前記ソフトウエアの前記設計仕様から、生成すべきテストシナリオの項目および順序情報を抽出して前記生成すべきテストシナリオの初期情報を生成するステップを含む。これも装置の場合と同様である。
【００２２】
以上を踏まえ、以下では本発明の実施形態を図面を参照しながら説明する。図１は、本発明の一実施形態に係るテスト仕様作成支援装置の構成を示すブロック図である。
【００２３】
図１に示すように、このテスト仕様作成支援装置は、入力制御部１、出力制御部２、制御部３、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、テスト仕様書作成部７、設計仕様データベース（以下では、「データベース」を「ＤＢ」と記す。）８、テストシナリオ生成ルールＤＢ９、テストシナリオＤＢ１０、テスト仕様書ＤＢ１１、テストシナリオ生成メタルールＤＢ１２を有する。
【００２４】
入力制御部１は、ユーザ２０からの入力情報を取得し、これを制御部３に引き渡すものである。出力制御部２は、制御部３からの情報をユーザ２０に出力情報として引き渡すものである。
【００２５】
制御部３は、入力制御部１、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、およびテスト仕様書作成部７から情報を受け取り、また、受け取られた情報を、ステータスに応じて、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、またはテスト仕様書作成部７に引き渡すものである。また、必要に応じて、上記受け取られた情報を出力制御部２へ引き渡すものである。
【００２６】
設計仕様の選択・入力部４は、制御部３を介して入力制御部１から受け取った入力情報に応じて、次の処理を実行する。すなわち、入力情報が設計仕様の検索条件の場合には、設計仕様ＤＢ８より検索条件にマッチする設計仕様を検索し、検索された設計仕様を制御部３に保持する。制御部３に保持された設計仕様は、出力制御部２を通してユーザ２０に表示される。また、入力情報が設計仕様の登録条件の場合には、入力情報に含まれる設計仕様情報を制御部３に保持するとともに、設計仕様ＤＢ８に蓄積する。
【００２７】
テストシナリオ生成ルール選択・生成部５は、制御部３を介して入力制御部１から受け取った入力情報に応じて、次の処理を実行する。すなわち、入力情報がテストシナリオ生成ルールの検索条件の場合（テストシナリオ生成ルール選択時）には、テストシナリオ生成ルールＤＢ９より検索条件にマッチするテストシナリオ生成ルールを検索し、検索されたテストシナリオ生成ルールを制御部３に保持する。制御部に保持されたテストシナリオ生成ルールは、出力制御部２を通じてユーザに表示される。
【００２８】
また、テストシナリオ生成ルール選択・生成部５への入力情報がテストシナリオ生成ルールの登録条件の場合（テストシナリオ生成ルール作成時）には、テストシナリオ生成メタルールＤＢ１２に保持されたテストシナリオ生成メタルールに基づき、制御部３からの設計仕様情報よりテストの観点、判断基準を抽出し、抽出されたテストの観点、判断基準を制御部３、出力制御部２を介してユーザ２０に提示する。ユーザ２０は、提示されたテストの観点および判断基準に基づいてルール生成実行結果を入力制御部１に入力する。
【００２９】
入力されたルール生成実行結果は、制御部３を介してテストシナリオ生成ルール選択・生成部５に送られ、これによりテストシナリオ生成ルール選択・生成部５でテストシナリオ生成ルールが保持される。保持されたテストシナリオ生成ルールは、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータである。以上作成されたテストシナリオ生成ルールはテストシナリオ生成ルールＤＢ９に蓄積される。
【００３０】
テストシナリオ生成部６は、制御部３に保持された設計仕様情報およびテストシナリオ生成ルールからテストシナリオを自動生成し、自動生成されたテストシナリオを制御部３に保持するとともに、テストシナリオＤＢ１０に蓄積する。
【００３１】
テスト仕様書作成部７は、制御部３に保持されたテストシナリオに基づいて、制御部３、出力制御部２を通じて、ユーザ２０にテスト仕様書作成条件を提示する。また、ユーザ２０が入力した入力情報を入力制御部１、制御部３を介して受け取り、これに基づきテスト仕様書を作成しテスト仕様書ＤＢ１１に蓄積する。
【００３２】
なお、設計仕様ＤＢ８には、設計テンプレートに基づき作成された設計仕様が蓄積される。テストシナリオ生成ルールＤＢ９には、テストシナリオ生成ルールが蓄積される。テストシナリオＤＢ１０には、テストシナリオ生成部６にて生成されたテストシナリオが蓄積される。テスト仕様書ＤＢ１１には、テスト仕様書作成部７により生成されたテスト仕様書が蓄積される。テストシナリオ生成メタルールＤＢ１２には、テストシナリオ生成ルールを作成するためのメタルールが蓄積される。
【００３３】
図２は、図１中に示したテストシナリオ生成部６についての内部構成例を示すブロック図である。図２に示すように、このテストシナリオ生成部６は、設計仕様展開部６１、シナリオ生成ルール展開部６２、シナリオ生成エンジン６３、テストシナリオ展開部６４を有する。
【００３４】
設計仕様展開部６１は、シナリオ生成エンジン６３から渡された設計仕様情報を展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３の要求により保持された設計仕様情報を送出する。
【００３５】
シナリオ生成ルール展開部６２は、シナリオ生成エンジン６３から渡されたテストシナリオ生成ルールを展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３からの要求により保持されたテストシナリオ生成ルールを送出する。
【００３６】
シナリオ生成エンジン６３は、設計仕様およびシナリオ生成ルールの展開・保持、ならびに設計仕様とシナリオ生成ルールの条件部とのマッチング、シナリオ生成ルールの実行、および実行結果のテストシナリオＤＢ１０、制御部３への送出を行う。
【００３７】
テストシナリオ展開部６４は、シナリオ生成エンジン６３によって渡されたテストシナリオを展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３からの要求により保持されたテストシナリオを送出する。
【００３８】
次に、上記説明のテスト仕様作成支援装置を用いることによるテスト仕様書の作成手順を図３をも参照して説明する。図３は、テスト仕様書を作成する全体手順を示す流れ図である。
【００３９】
まず、設計仕様を選択または入力する（ステップ３１）。このステップは、ユーザ２０による入力制御部１への入力と、この入力による制御部３、設計仕様の選択・入力部４、設計仕様ＤＢ８の動作により完了する。
【００４０】
次に、テストシナリオ生成ルールの選択（または作成および選択）を行なう（ステップ３２）。テストシナリオ生成ルールを作成する場合には、すでに述べたように、テストシナリオ生成ルール選択・生成部５にて、テストシナリオ生成メタルールＤＢ１２に保持されたテストシナリオ生成メタルールに基づき、制御部３から渡される設計仕様よりテストシナリオ生成ルールを作成し、テストシナリオ生成ルールＤＢ９に蓄積する。作成されたテストシナリオ生成ルールは、上述したように、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータである。テストシナリオ生成ルールの選択は、テストシナリオ生成ルールＤＢ９から該当のものを検索することによりなされる。
【００４１】
次に、ステップ３１で入力した設計仕様とステップ３２で選択したテストシナリオ生成ルールより、テストシナリオ生成部６でテストシナリオを生成する（ステップ３３）。さらに、ステップ３３で生成したテストシナリオと、入力制御部１を介するユーザからの要件に基づいて、テスト仕様書作成部７にてテスト仕様書を作成する（ステップ３４）。これにより、目的のテスト仕様書が作成されれば終了であり、引き続きテスト仕様書を作成する必要（例えば設計仕様に内容を追加してテスト仕様書を作り直すなど）があれば継続して最初から処理を行なう（ステップ３５）。
【００４２】
図４は、図３中で説明したステップ３３（テストシナリオの生成）内におけるやや詳細な手順の例を示す流れ図である。
【００４３】
テストシナリオを生成するには、まず、制御部３に保持された設計仕様のデータを取得し、これを設計仕様展開部６１を構成する例えばメモリ上に保持する（ステップ３３１）。また、選択されたテストシナリオ生成ルールを制御部３から取得し、これをシナリオ生成ルール展開部６２を構成する例えばメモリ上に保持する（ステップ３３２）。
【００４４】
次に、生成されるべきテストシナリオについての初期化を行なう（ステップ３３３）。具体的には、ステップ３３１で展開された設計仕様から、テストシナリオとしての項目および順序情報を抽出し、これによりテストシナリオの初期情報を生成する。
【００４５】
次に、ステップ３３２で展開されたテストシナリオ生成ルールのうちから適用可能なものがあるか否かを判断する（ステップ３３４）。具体的には、テストシナリオ生成ルールそれぞれの条件部とステップ３３１で展開された設計仕様とをマッチングさせる。マッチした場合には、そのルールを選択し（ステップ３３５）、さらにそのルールの実行部を適用する。適用された結果は、テストシナリオの一部として出力される（ステップ３３６）。
【００４６】
同様に、別のテストシナリオ生成ルールについて設計仕様とのマッチが存在する限り、上記のステップ３３５、３３６の処理を行なう。これにより、マッチがすべて存在しなくなったときにテストシナリオが完成する。テストシナリオが完成したら、制御部３に出力し（ステップ３３７）、かつテストシナリオＤＢへの蓄積を行なう（ステップ３３８）。
【００４７】
以上説明のように、設計仕様を用いて、テストの観点および判断基準に関するノウハウであるテストシナリオ生成ルールを条件部→実行部の形式で生成してこれをＤＢ化することにより、ＤＢの内容の再利用を可能にし統一した手順でテスト仕様書を効率的に作成することができる。
【００４８】
【実施例】
次に、図５に示すような画面遷移を備えたＷｅｂバンキングシステムを例に取り、本発明の実施例としてのテスト仕様作成方法を説明する。図５は、本発明の実施例としてのＷｅｂバンキングシステムにおける表示画面（その一部）の変化を示す遷移図である。
【００４９】
図５に示すように、これらの画面５０、…、６０は、それぞれ名称が与えられ、かつ矢印のように遷移または上位、下位の関係を有する。このようなＧＵＩとこれに伴う処理（内部仕様に関する処理）とが開発・作成されるべきソフトウエアに相当する。
【００５０】
図６は、図５に示した画面遷移を備えたＷｅｂバンキングシステムの設計仕様を示す仕様書の記述例を表わす図である。この仕様書は、一定の設計テンプレートに従って作成されている。すなわち、図５において、表を構成する行それぞれはユーザからのひとつの動作（ボタンの押下、メニュー選択）によって実施する一塊の処理を示している。実施する処理の細目内容は、表を構成する列で項目ごとに分類して示される。
【００５１】
処理の項目（細目内容）は以下である：
・ユースケース：システムの業務機能。該当行の処理が関連する業務機能名。
・ユースケースシナリオ：該当行の処理が実施される際の状況。
・動作：該当行の処理を実施のトリガ。
・アクタ：該当行の処理を実施する権限のある利用者（または他システム、機能）
・順序：該当行の処理が前後の行の処理と連続する場合に、実行の順序を示す数値。
・入力画面：該当行の処理を開始する際に表示されている画面。
・入力データ：画面などから入力するデータ名。
・テーブル：対象となるテーブル名。
・条件：画面遷移／帳票出力／バッチ処理などの処理を実行する際に前提となる条件。
・メッセージ：該当行の処理実行時に表示するメッセージ内容。
・遷移先画面：該当行の処理の実行後に遷移する画面。
・出力帳票：該当行の処理の実行後に出力する帳票。
・処理種別：該当行の処理の種別（画面系、帳票系、バッチ系を複数選択）。
・タイプ：該当行の処理のタイプ（登録系、検索系、その他のいずれかを選択）。
【００５２】
このような項目はユーザが決定し入力制御部１より入力する。例えば、図６における１行目（Ｎｏ．１）の処理は、次のことを示す。
・当該行の処理は、ユースケース「各種情報を照会する」に関する処理である。・当該行の処理は、ユースケースシナリオ「残高を照会する」場合に実行する処理である。
・当該行の処理は、動作「情報照会」メニューのクリック」により実施する。
・当該行の処理は、アクタ「顧客」の権限を有するものが実施可能である。
・当該行の処理は、後続する一連の処理間において、１番目に実行する処理である。
・当該行の処理は、入力画面「メニュー画面」より開始する。
・当該行の処理は、入力データはない。
・当該行の処理は、対象となるテーブルはない。
・当該行の処理を実施するための条件はない。
・当該行の処理の実施後に、表示するメッセージはない。
・当該行の処理の実施後、遷移先画面「情報照会サブメニュー画面」に遷移する。
・当該行の処理は、出力帳票はない。
・当該行の処理は、処理種別「画面系」の処理である。
・当該行の処理は、タイプ「その他」の処理である。
他の行についても同様である。このような処理内容はユーザが決定し入力制御部１より入力する。
【００５３】
次に、図６に示したような設計仕様を設計仕様ＤＢ８内に蓄積するときの方式について説明する。図７は、図６で説明した設計仕様を設計仕様ＤＢ８に保存するときの方式を説明する図である。
【００５４】
図７において、○（ノード）は、一行分の仕様を示し、矢印および直線はノード間の関係を示す。矢印は、ノード間に連続した関係があることを示す（ノード間の関係は上記説明の項目「順序」より導出されている）。直線で結んだノードの集合は、それらが同一のアプリケーションに関する仕様であることを示している。例えば、図７（ａ）は、ノード１、…、ノード６、ノード９、…、１１が同一アプリケーションに関する仕様であることを示し、図７（ｂ）は、ノード５１、…、ノード５５、ノード５９、ノード６０が別の同一アプリケーションに関する仕様であることを示す。
【００５５】
次に、図７に示した各ノードおよびそれらの関係を記述する記述形式について説明する。各アプリケーションについて記述形式は、リストとして、例えば、［［ＡＰＮ］， ［［Ｓ１， Ｓ２， Ｓ３］， ［Ｓ４， Ｓ５， Ｓ６］，［Ｓ７］，…，［ＳＮ］］］ となる。
ここで、ＡＰＮはアプリケーション名、
Ｓ１， Ｓ２， Ｓ３，…，ＳＮは、それぞれ、一行分の設計仕様、
［Ｓ１， Ｓ２， Ｓ３］は、Ｓ１， Ｓ２， Ｓ３が一連の連続した処理であることを示す。［Ｓ４， Ｓ５，Ｓ６］も同様である。
【００５６】
１行分の設計仕様Ｓｍそれぞれの記述形式は、リストとして、例えば、［Ｎｏ（Ａ）， ユースケース（Ｂ）， ユースケースシナリオ（Ｃ）， 動作（Ｄ）， アクタ（Ｅ）， 順序（Ｆ）， 入力画面（Ｇ）， 入力データ（Ｈ）， テーブル（Ｉ）， 条件（Ｊ）， メッセージ（Ｋ）， 遷移先画面（Ｌ）， 出力帳票（Ｍ）， 処理種別（Ｎ）， タイプ（Ｏ）］ となる。ここで、Ａ〜Ｏは変数。Ｓｍを構成する要素のそれぞれが１階の述語論理に基づく論理式に相当する。
【００５７】
具体的な記述例を挙げると、図６の１行目の設計仕様については以下のようになる。
Ｓ１＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（“残高を照会する”）， 動作（“「情報照会メニュー」をクリック”）， アクタ（“顧客”）， 入力画面（“メニュー画面”）， 順序（“１”）， 入力データ（ｎｕｌｌ）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）， タイプ（“その他”）］
【００５８】
以上説明のように、例えば図６に示すような設計仕様は上記のように方式化、形式化され設計仕様ＤＢ８に蓄積される。すなわち、ユーザは、図６に示す表の形式により設計仕様を入力し、入力された設計仕様は、図７に示す方式により設計仕様ＤＢ８へ蓄積され、かつそれぞれのアプリケーションについて上記のような形式により記述されている。
【００５９】
すでに蓄積済みの設計仕様は、アプリケーション名を選択することにより、該当するアプリケーションとしてリンクづけられた仕様（ノード）を抽出し図６のような一覧表形式によりユーザに表示することができる。
【００６０】
図６のような設計仕様（開発・作成されるべきソフトウエアの設計仕様）が入力されたあと、このソフトウエアをテストするためのシナリオを生成することが、本発明を具体的に適用することにより可能となる。これを以下説明する。
【００６１】
基本的には、このシナリオは、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータであるテストシナリオ生成ルールを、上記の設計仕様に適用することによって生成することができる。テストシナリオ生成ルールは、あらかじめ作成しておいたものを用いる。
【００６２】
テストシナリオ生成ルールを作成する手順について説明する。テストシナリオ生成ルールは、テストシナリオ生成メタルール（以下ではメタルールという。）に基づいて、与えられた設計仕様から作成することができる。図８は、メタルールの例を示す図である。
【００６３】
メタルールは、設計仕様がベースとしている設計モデルに沿って、テストシナリオ生成ルールを作成するための上位の知識である。また、設計モデルとテストシナリオ生成ルールとを関連づける役割を持ち、結果として、設計モデルが提示する考え方に沿った形でテストシナリオを生成することを可能にするための知識である。
【００６４】
具体的には、メタルールは、設計仕様の構成要素（項目）と構成要素のとり得る値とを、テストシナリオ生成ルールの条件部に出現する節の候補として与える。図８に示すように、メタルールそれぞれの構成は以下のようになっている。
観点：設計仕様の構成要素（項目）。
基準値：「観点」の持つべき値や検証すべき値。（初期値は有無（１または０）とする。）
ルール：このメタルールにより作成したテストシナリオ生成ルールの識別子。（ルール番号やＩＤなどが相当する。このメタルールによりテストシナリオ生成ルールを作成した後、決定する。）
これにより、メタルールＤＢ１２には、これらのメタルールが、設計仕様にて定義している観点の数分、蓄積されていることになる。
【００６５】
図９は、図６に示す設計仕様を前提としたメタルールの一部を示す図である。具体的には、図９（ａ）、図９（ｂ）は、それぞれ、構成要素「遷移先画面」、「入力データ」に関してメタルールの初期値を定義した結果を示す。図１０は、図９に示すメタルールに対して、テストシナリオ生成ルールの定義（作成）後、これを、関連する「観点」に関連付けた結果を示す図である。
【００６６】
テストシナリオ生成ルールの具体的作成について説明する。まず、作成後のルールがテストシナリオ生成ルールＤＢ９に蓄積・保持されるときの保存方式を図１１を参照して述べる。図１１は、テストシナリオ生成ルールＤＢ９における保存方式を示す図である。図１１において、○（ノード）は、テストシナリオ生成のひとつのルールを示す。ノード間の矢印はルール間の関係（適用順序）を示すものである。
【００６７】
ここで、テストシナリオ生成ルールの記述形式を例えば以下のようにする。
［Ｒｕｌｅｓ， Ｏｒｄｅｒ］
Ｒｕｌｅｓ： ［Ｒ１， Ｒ２， Ｒ３，…， ＲＮ］
Ｒ１， Ｒ２， Ｒ３，…， ＲＮは、それぞれ、一つのテストシナリオ生成ルールを示すルールＩＤ。
Ｏｒｄｅｒ：［Ｏ１， Ｏ２， Ｏ３，…，ＯＮ］
Ｏ１， Ｏ２， Ｏ３，…，ＯＮ における Ｏｉ それぞれは、Ｒｉを実行後に次に実施可能なルールのルールＩＤを示すリスト。
【００６８】
これを用い、図１１に示すテストシナリオ生成ルールは、以下のように記述される。
［［ｒ１， ｒ２， ｒ３， ｒ４， ｒ５， ｒ６， ｒ７， ｒ８， ｒ９， ｒ１０， ｒ１１， ｒ１２］， ［［ｒ３， ｒ４］， ［ｒ３， ｒ４］， ［ｒ５， ｒ６］， ［ｒ５， ｒ６］， ［ｒ７， ｒ８］， ［ｒ７， ｒ８］， ［ｒ９］， ［ｒ９］， ［ｒ１０］， ［ｒ１１］， ［ｒ１２］， ［［］］］
すなわち、１２個のルールがあり、各識別子がｒ１〜ｒ１２となる。ルールｒ１の実行後に次に実施可能なルールは、ルールｒ３またはルールｒ４である。ルールｒ２以下ルールｒ１１まで同様である。ルールｒ１２の実行後の次に実施可能なルールは“［］”、すなわち、実施するルールはなく、ルールｒ１２が定義された最終のルールである。
【００６９】
ここで、テストシナリオ生成ルールＲｉそれぞれの記述形式は、例えば、以下の形式で記述することができる。
”Ｉｆ ＬＨＳ， ｔｈｅｎ ＲＨＳ．”
ここで、ＬＨＳおよびＲＨＳは１階の述語論理式である。
【００７０】
図６に示した設計仕様に対してメタルールを用いると、設計仕様の構成要素（項目）と構成要素のとり得る値とを、テストシナリオ生成ルールの条件部に出現する節の候補として与え、次のようにルールを定義（作成）することができる。
（ルールｒ１）データ入力後の画面遷移の場合： 指定したデータ入力後に指定した遷移先画面に遷移することを確認する。
（ルールｒ２）遷移先画面がある場合： 指定した遷移先に遷移することを確認する。
（ルールｒ３）データ入力後の帳票出力の場合： 指定したデータ入力後に指定した帳票が出力されることを確認する。
（ルールｒ４）出力帳票がある場合： 指定した帳票が出力されることを確認する。
（ルールｒ５）データ入力後のバッチ処理の場合： 指定したデータ入力後に指定したバッチ処理結果がテーブルの内容に反映されていることを確認する。
（ルールｒ６）バッチ処理の場合： バッチ処理結果がテーブルの内容に反映されていることを確認する。
（ルールｒ７）登録系の画面遷移の場合： 登録済みテーブルの内容と入力したデータとが一致することを確認する。
（ルールｒ８）検索系の画面遷移の場合： 登録済みテーブルの内容と表示したデータの内容とが一致することを確認する。
（ルールｒ９）利用者権限がある場合： 指定した利用者の権限にて処理が正しく実行されることを確認する。
（ルールｒ１０）画面遷移／帳票出力／バッチ処理実施のための条件が指定されている場合： 指定された条件にて正しく処理が実行されていることを確認する。
（ルールｒ１１）出力メッセージがある場合： 指定したメッセージが出力されることを確認する。
（ルールｒ１２）画面遷移／帳票出力／バッチ処理に一連の処理順序が設定されている場合： 一連の処理の流れが正しいことを確認する。
【００７１】
以上のルールｒ１〜ｒ１２同士の関係は、図１１に示すような関係になっている。ルールｒ１〜ｒ１２を、上記説明のルールの記述形式に従って表現すると以下のようになる。
【００７２】
（ルールｒ１）遷移先画面有り＆入力データ有
【数１】
【００７３】
（ルールｒ２）遷移先画面有り＆入力データなし
【数２】
【００７４】
（ルールｒ３）出力帳票有り＆入力データ有り
【数３】
【００７５】
（ルールｒ４）出力帳票有り＆入力データなし
【数４】
【００７６】
（ルールｒ５）バッチ処理＆入力データあり
【数５】
【００７７】
（ルールｒ６）バッチ処理＆入力データなし
【数６】
【００７８】
（ルールｒ７）登録系
【数７】
【００７９】
（ルールｒ８）検索系
【数８】
【００８０】
（ルールｒ９）利用者権限有無
【数９】
【００８１】
（ルールｒ１０）条件指定あり
【数１０】
【００８２】
（ルールｒ１１）出力メッセージあり
【数１１】
【００８３】
（ルールｒ１２） 画面に一連の処理の順序がある場合の確認
【数１２】
【００８４】
次に、テストシナリオの具体的生成について説明する。まず、作成後のシナリオがテストシナリオＤＢ１０に蓄積・保持されるときの保存方式を図１２を参照して述べる。図１２は、テストシナリオＤＢ１０における保存方式を示す図である。図１２において、○（ノード）は、ひとつのテストシナリオを示す。ノード間の矢印は、ノード間に連続した関係があることを示す。直線で結んだノードの集合は、それらが同一のアプリケーションに関するテストシナリオ（またはテスト仕様。「テスト仕様」は、テストシナリオをユーザに示す形式に変換したもの）であることを示す。
【００８５】
テストシナリオの記述形式は、例えば次にようにすることができる。
［［ＡＰＮ］， ［［Ｓ１， Ｓ２， Ｓ３］， ［Ｓ４， Ｓ５， Ｓ６］，［Ｓ７］，…，［ＳＮ］］］
ここで、ＡＰＮはアプリケーション名、
Ｓ１， Ｓ２， Ｓ３，…，ＳＮは、それぞれ、一行分のテストシナリオ、
［Ｓ１， Ｓ２， Ｓ３］は、Ｓ１，Ｓ２，Ｓ３が連続した一連のテストシナリオであることを示す。［Ｓ４， Ｓ５， Ｓ６］も同様。
【００８６】
１行分のテストシナリオＳｍそれぞれの記述形式は、リストとして、例えば、［Ｙ］＝［Ｎｏ（Ａ）， ユースケース（Ｂ）， ユースケースシナリオ（Ｃ）， タイプ（Ｏ）， 順序（Ｆ）， 確認項目（Ｐ）， アクタ（Ｅ）， 入力画面（Ｇ）， 入力データ（Ｈ）， 動作（Ｄ）， テーブル（Ｉ）， 条件（Ｊ）， メッセージ（Ｋ）， 遷移先画面（Ｌ）， 出力帳票（Ｍ）， 処理種別（Ｎ）］ となる。ここで、Ａ〜Ｐは変数。Ｓｍを構成する要素のそれぞれが１階の述語論理に基づく論理式に相当する。
【００８７】
図６に示したような、ひとつのアプリケーションの設計仕様と、これに対応する、ひとつのアプリケーションのテストシナリオ（後述する図１６、図１７）との記述上の関係は、次のように表わすことができる。
【数１３】
【００８８】
ひとつ（１行分）のテストシナリオの具体的な記述例は、例えば、Ｙ＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（“残高を照会する”）， タイプ（“単純遷移”）， 順序（“１”）， 確認項目（“アクアの権限のユーザによって、入力画面から動作実行後、遷移先画面への遷移が正しく行われることを確認する。”）， アクタ（“顧客”）， 入力画面（“メニュー画面”）， 入力データ（ｎｕｌｌ）， 動作（“「情報照会メニュー」をクリック”）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）］ となる（図１６の１行目のテスト仕様）。
【００８９】
上記ですでに説明した、ルールの例としてのルールｒ１〜ｒ１２は、図１３に示すような表形式でユーザが入力することができる。図１３は、ルールの入力、表示を行う画面の例を示す図である。入力されたルールはテストシナリオ生成ルールＤＢ９に蓄積される。また、入力・蓄積されているテストシナリオ生成ルールは、図１３に示すような表の形式にてユーザに表示することができる。
【００９０】
以上を前提にテストシナリオの具体的生成を、以下、説明する。まず、設計仕様を入力して設計仕様ＸＸＸＸを得（設計仕様展開部６１）、また、テストシナリオ生成ルール［Ｒｕｌｅｓ， Ｏｒｄｅｒ］をシナリオ生成ルール展開部６２に保持しておく。そして、図１４に示す処理を行なうことによりテストシナリオＹＹＹＹを初期化する。図１４は、テストシナリオを初期化する処理を示す流れ図であり、すでに説明した図４の流れ図におけるステップ３３３に相当する処理を示すものである。この初期化の過程では、設計仕様ＸＸＸＸから、テストシナリオＹＹＹＹとしての項目および順序情報を抽出する処理が含まれる。
【００９１】
図１４を参照するに、ステップ１４１からステップ１４５はこの処理の前処理に相当する。ステップ１４１でテストシナリオＹＹＹＹの空リストを用意し、ステップ１４２でアプリケーション名をテストシナリオＹＹＹＹに定義する。さらにステップ１４３で設計仕様ＸＸＸＸの２番目の要素（１番目の要素を除く全体）をＸＸＸとして、これに相当するテストシナリオの要素ＹＹＹの空リストを用意する。次に、ＸＸＸの長さ（要素の数：既知）をＬとして（ステップ１４４）、ＸＸＸの長さ分のループ処理（ステップ１４６以下）を行なうためのループ変数ｉを初期数に設定する（ステップ１４５）。
【００９２】
ステップ１４６の次に、ＸＸＸのｉ番目の要素を取出してＸＸとし（ステップ１４７）、ＸＸの長さ（既知）をＭとして、ＸＸの長さ分のループ処理（ステップ１４９以下）を行なうためのループ変数ｊを初期数に設定する（ステップ１４８）。
【００９３】
ステップ１４９の次に、ＸＸのｊ番目の要素をＸとし（ステップ１５０）、Ｘの内容をＹに代入する（ステップ１５１）。Ｙには要素として「確認項目」が付加されている。これが生成されるべきテスト仕様としての主要部分に相当する。図１４における処理では、初期化としてこの内容はｎｕｌｌとして出力される。
【００９４】
ステップ１５０の処理後、ワークエリアＺを空リストとして用意し（ステップ１５２）、ＹをＺに追加する（ステップ１５３）。さらに、ｊ値を更新して（ステップ１５４）、ステップ１４９からのループ処理を繰り返す。これで所定数Ｍ回のループ処理が行なわれてＸＸを構成する全部の要素について処理が終わる（ステップ１４９のＹ）。これにより、ステップ１５５でＹＹＹにＺの内容を追加し、ｉ値を更新して（ステップ１５６）、さらにステップ１４６からのループ処理を繰り返す。このループ処理が所定数Ｌ回行なわれるとＸＸＸを構成するすべての要素について処理が終わる（ステップ１４６のＹ）。これにより、ステップ１５７でＹＹＹＹにＹＹＹを追加し、テストシナリオＹＹＹＹの初期化を終了する。
【００９５】
次に、図１５に示す処理を行なう。図１５は、図１４に示す初期化処理に続くテストシナリオの具体的生成の処理手順を示す流れ図であり、すでに説明した図４の流れ図におけるステップ３３４からステップ３３６に相当する処理を示すものである。なお、図１５では、ステップ３３４からステップ３３６の処理に個々には対応する表現にはなっていない。
【００９６】
図１５に示す処理においては、ステップ１６１からステップ１６８、およびステップ１７０、ステップ１７１について、ほぼ、図１４に示したステップ１４３から１５０、およびステップ１５４、ステップ１５６とそれぞれ同様の処理が行なわれる。
【００９７】
図１５のステップ１６９の処理が、テストシナリオの自動生成に関する処理である。ステップ１６９は、ステップ１６８で１行分の設計仕様Ｘを取出すことを前提に開始される。すなわち、その後、まず、ルールを読み込んでかつステップ１６９ｃ以降のルール長さ分のループ処理を行なうためのループ変数ｋを初期数に設定し（ステップ１６９ａ）、実行済みのルールを記入するリストＱを空リスト（［］）に設定する（すなわちＱ＝［］とする（ステップ１６９ａ−１））。また、ルールのリストの長さ（既知）をＬ１とする（ステップ１６９ｂ）。
【００９８】
ステップ１６９ｃの後、ｋ番目のルールを適用する（ステップ１６９ｄ）。具体的には、Ｒｋのルールの条件部が真で、かつ実行済ルールリストＱにＲｋが含まれていない場合（ケース１）には、Ｒｋのルールの実行部を実行し、実行済ルールリストＱにはＲｋを追加する。この場合には、次にステップ１６９ｅに進む。また、Ｒｋのルールの条件部が真で、かつ実行済ルールにＲｋが含まれている場合（ケース２）には、Ｒｋの実行部は実行しない。このまま次にステップ１６９ｅに進む。また、Ｒｋのルールの条件部が偽である場合（ケース３）には、何もせず、次には直接ステップ１６９ｋに進む。
【００９９】
ステップ１６９ｅに進んだ場合には、次に、ステップ１６９ｇ以降の順序リスト長さ分のループ処理を行なうためのループ変数ｌを初期数に設定し（ステップ１６９ｅ）、順序リストの長さ（既知）をＬ２とする（ステップ１６９ｆ）。
【０１００】
次に、ｋ番目のルールの次に適用するルールの順序リストのｌ番目のルールを抽出し（ステップ１６９ｈ）、ルール番号を取得するとともにこのルールの条件部が真になる場合にその実行部を実行する（ステップ１６９ｉ）。そしてｌ値を更新して（ステップ１６９ｊ）、ステップ１６９ｇ以降のループ処理を行う。
【０１０１】
順序リストにあるすべてのルールについて上記処理が終了したら（ステップ１６９ｇのＹ）、ｋ値を更新し（ステップ１６９ｋ）、ステップ１６９ｃからのループ処理を繰り返す。すべてのルールについて処理が終われば（ステップ１６９ｃのＹ）、ｊ値またはｉ値を更新して（ステップ１７０、ステップ１７１）、同様に繰り返すことによりすべての処理を終了する。これによりテストシナリオＸＸＸＸを得ることができる。
【０１０２】
例えば、以下の場合：
【数１４】
に、上記説明した図１５の処理を行なうことにより、テストシナリオの確認項目（Ｐ）の要素に対し確認すべき項目をＰのリストに追加し、テストシナリオを生成すると、図６に示した１行目の設計仕様について以下のようになる。
【０１０３】
すなわち、この場合には、ルールｒ２、ルールｒ９で条件部が真となり、これらの実行部が適用され、以下のシナリオが生成される。
Ｙ＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（Ｃ）， タイプ（“その他”）， 順序（“１”）， 確認項目（“入力画面から動作実行後、遷移先画面への遷移が正しく行われることを確認する。指定した利用者の権限にて処理が正しく実行されることを確認する。”）， アクタ（“顧客”），入力画面（“メニュー画面”）， 入力データ（ｎｕｌｌ）， 動作（“「情報照会メニュ」をクリック”）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）］
【０１０４】
上記のようにして得られたＹそれぞれを最下位の要素としてテストシナリオＹＹＹＹを得たら、次に、このテストシナリオを、図１６、図１７に示す表形式のテスト仕様書に変換して、ユーザに表示する。図１６、図１７は、図６に示した設計仕様に対応するテスト仕様の生成例を示す図である。ユーザは、表形式の幅・高さ、項目名、列行の追加などの編集を行って、所望のテスト仕様書の形式に整形後、テスト仕様書ＤＢ１１に蓄積する。
【０１０５】
このあと、設計仕様の修正・変更やシナリオ生成ルールなどの追加・変更などがある場合には、図３に示す流れにより、そのステップ３１に戻りテストシナリオ生成の処理を繰り返すことができる。以上により、図５に示すような画面遷移を備えたＷｅｂバンキングシステムにおけるテスト仕様作成方法の流れをひととおり説明した。この実施例の説明で明らかなように、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）によりテストの内容や合格の判断基準が異なってもテスト仕様の自動生成が実現する。例えばＧＵＩ等の外部仕様に限らず、内部処理の設計仕様についてもテスト仕様の自動生成が可能になる。
【０１０６】
次に、設計仕様に追加を行い、これに対応してテストシナリオ（テスト仕様）を生成し直す例について以下説明する。図１８は、図６に示した設計仕様情報に仕様の追加を行った設計仕様例を示す図である。この設計仕様では、図示するように「サービス名」の列１８１が追加され、この列に交わる各行において、実行する処理としての関連サービス名が示されている。
【０１０７】
仕様が追加されると、テストシナリオ生成ルール選択・生成部５において、追加仕様に関するメタルールが初期生成される。図１９に、項目「サービス名」に関するメタルールの初期生成結果を示す。メタルールＤＢ１２には、図１０に示したメタルールに加えて図１９に示す「サービス名」に関するメタルールが追加・蓄積される。
【０１０８】
追加されたメタルールに基づいて、テストシナリオ生成ルールを新規追加する作業手順を図２０〜図２７に示す。図２０〜図２７は、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図である。メタルールによるテストシナリオ生成ルールの定義は、メタルール表示ウィンドウ２０１（２０１Ａ〜２０１Ｆ）およびテストシナリオ生成ルール定義ウインドウ２０２（２０２Ａ〜２０２Ｆ）を通して、相互にデータの参照および連携をとりながら進めることができる。
【０１０９】
図２０は、メタルール表示ウインドウ２０１およびテストシナリオ生成ルール定義ウインドウ２０２の初期画面を示している。メタルール表示ウインドウ２０１には、図１０および図１９にて定義したメタルール全体が表示される。テストシナリオ生成ルール定義ウインドウ２０２は、２つのウインドウにさらに分かれる。
【０１１０】
上部は、メタルール表示ウインドウ２０１での定義結果に基づいて、設計仕様に沿った条件式を構築する作業ウインドウ２０２ａ（２０２Ａａ〜２０２Ｆａ）である。下部は、ルールＮｏ．、条件部、実行部、次ルール、説明の項目からなり、テストシナリオ生成ルールを定義する作業ウインドウ２０２ｂ（２０２Ａｂ〜２０２Ｆｂ）である。なお、すでに説明した図１３は、ウインドウ２０２ｂの表示内容の例を拡大して示したものに相当する。
【０１１１】
テストシナリオ生成ルールを作成するには、メタルール表示ウインドウ２０１での定義結果を利用して条件式を定義し（作業ウインドウ２０２ａ）、さらに、ここで定義した条件式を利用して、テストシナリオ生成ルール定義ウインドウ２０２の下部の作業ウインドウ２０２ｂ内のルールＮｏ．、条件部、実行部、次ルール、説明の項目を記載しながら定義して行なう。
【０１１２】
図２１は、メタルール表示ウインドウ２０１Ａで、新規に追加した「観点：サービス名」に関するルールを作成するために、「観点：サービス名」を選択していることを示す。図２２は、マウス（入力制御部１の一部）のドラッグ＆ドロップにより、選択した「観点：サービス名」をテストシナリオ生成ルール定義ウインドウ２０２Ｂの「観点」エリアに配置したことを示す。図示するように、「観点：サービス」の配置により、基準値：有、基準値：無の初期値が表示される。
【０１１３】
図２３は、テストシナリオ生成ルール定義ウインドウ２０２Ｃにおいて、観点および基準値の情報を参照しながら、「条件式」を記載した結果を示している。ここで、ユーザは、必要に応じて、基準値を追加することができる。図２４は、テストシナリオ生成ルール定義ウインドウ２０２Ｄにおいて、ユーザが必要に応じて、新たに「基準値：ログ出力」を定義し、「条件式」を追記したことを示している。
【０１１４】
次に、図２４での観点、基準値、条件式を利用して、テストシナリオ生成ルール定義ウインドウ２０２Ｄの下部において、テストシナリオ生成ルールを定義する。図２５は、「観点：サービス」の追加により、新規に作成されたルールｒ１３およびｒ１４を示している。
【０１１５】
なお、追加のテストシナリオ生成ルールの定義後には、メタルールへその追加・変更を反映させる。図２６は、メタルール表示ウインドウ２０１Ｅに、「基準値：ログ出力」を追加している過程を示している。図２７は、メタルール表示ウインドウに２０１Ｆ、「基準値：ログ出力」が追加されたことを示す。
【０１１６】
また、テストシナリオ生成ルールによるテストシナリオ生成後、「観点：サービス名」に関するメタルールには、ルールｒ１３およびｒ１４を作成した情報が反映される。図２８は、ルールｒ１３およびルールｒ１４の適用後の「観点：サービス名」に関するメタルールを示す図である。
【０１１７】
以上説明のように、テストシナリオ生成ルールを追加することができる。この結果を用い、テストシナリオを再構成しテスト仕様を生成した例を図２９に示す。図２９は、図１６に示した設計仕様を用いてテスト仕様を作成した例を示す図である。図２９においてはサービス名の列２９１の追加がなされ、かつ、確認項目のうち欄２９２および２９３が、ルールｒ１３およびルールｒ１４の適用結果が反映されたものとなる。
【０１１８】
このように、テスト方針の蓄積・再利用を可能にして統一した手順でテスト仕様書を効率的に作成することができる。また、ソフトウェアの内部設計仕様に関する仕様から結合試験のテスト項目を自動生成し、テスト仕様作成の手間を軽減することができる。また、テストシナリオ生成ルールを作成するためのメタルールを備えることにより、設計仕様の拡張や変更に柔軟に対応して、テストシナリオの生成ルールの定義およびテストシナリオの生成を行うことができる。
【０１１９】
【発明の効果】
以上詳述したように、本発明では、テストシナリオ生成ルールを定義する手段を具備する。テストシナリオ生成ルールは、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したものである。定義されたテストシナリオ生成ルールにより、その条件部および実行部を用い、条件部と設計仕様とのマッチングをとって実行部を実行するという手順が提供される。この手順によれば、テスト方針の蓄積・再利用をテストシナリオ生成ルールの蓄積・再利用という形で可能にし、統一した手順でテスト仕様書を効率的に作成することが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るテスト仕様作成支援装置の構成を示すブロック図。
【図２】図１中に示したテストシナリオ生成部６についての内部構成例を示すブロック図。
【図３】図１に示したテスト仕様作成支援装置におけるテスト仕様書を作成する全体手順を示す流れ図。
【図４】図３中で説明したステップ３３（テストシナリオの生成）内におけるやや詳細な手順の例を示す流れ図。
【図５】本発明の実施例としてのＷｅｂバンキングシステムにおける表示画面（その一部）の変化を示す遷移図。
【図６】図５に示した画面遷移を備えたＷｅｂバンキングシステムの設計仕様を示す仕様書の記述例を表わす図。
【図７】図６で説明した設計仕様を設計仕様ＤＢ８に保存するときの方式を説明する図。
【図８】メタルールの例を示す図。
【図９】図６に示す設計仕様を前提としたメタルールの一部を示す図。
【図１０】図９に示すメタルールに対して、テストシナリオ生成ルールの定義（作成）後、これを、関連する「観点」に関連付けた結果を示す図。
【図１１】テストシナリオ生成ルールＤＢ９における保存方式を示す図。
【図１２】テストシナリオＤＢ１０における保存方式を示す図。
【図１３】ルールの入力、表示を行う画面の例を示す図。
【図１４】テストシナリオを初期化する処理を示す流れ図。
【図１５】図１４に示す初期化処理に続くテストシナリオの具体的生成の処理手順を示す流れ図。
【図１６】図６に示した設計仕様に対応するテスト仕様の生成例を示す図。
【図１７】図１６の続図であって、図６に示した設計仕様に対応するテスト仕様の生成例を示す図。
【図１８】図６に示した設計仕様情報に仕様の追加を行った設計仕様例を示す図。
【図１９】項目「サービス名」に関するメタルールの初期生成結果を示す図。
【図２０】追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２１】図２０の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２２】図２１の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２３】図２２の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２４】図２３の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２５】「観点：サービス」の追加により、新規に作成されたルールｒ１３およびｒ１４を示す図。
【図２６】図２４の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２７】図２６の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２８】ルールｒ１３およびルールｒ１４の適用後の「観点：サービス名」に関するメタルールを示す図。
【図２９】図１６に示した設計仕様を用いてテスト仕様を作成した例を示す図。
【符号の説明】
１…入力制御部 ２…出力制御部 ３…制御部 ４…設計仕様の選択・入力部５…テストシナリオ生成ルール選択・生成部 ６…テストシナリオ生成部 ７…テスト仕様書作成部 ８…設計仕様データベース ９…テストシナリオ生成ルールデータベース １０…テストシナリオデータベース １１…テスト仕様書データベース １２…テストシナリオ生成メタルールデータベース ６１…設計仕様展開部 ６２…シナリオ生成ルール展開部 ６３…シナリオ生成エンジン ６４…テストシナリオ展開部 ２０１、２０１Ａ、２０１Ｂ、２０１Ｃ、２０１Ｄ、２０１Ｅ、２０１Ｆ…メタルール表示ウインドウ ２０２、２０２Ａ、２０２Ｂ、２０２Ｃ、２０２Ｄ、２０２Ｅ、２０２Ｆ…テストシナリオ生成ルール定義ウインドウ ２０２ａ、２０２Ａａ、２０２Ｂａ、２０２Ｃａ、２０２Ｄａ、２０２Ｅａ、２０２Ｆａ…作業ウインドウ ２０２ｂ、２０２Ａｂ、２０２Ｂｂ、２０２Ｃｂ、２０２Ｄｂ、２０２Ｅｂ、２０２Ｆｂ…作業ウインドウ
【発明の属する技術分野】
本発明は、開発すべきソフトウエアをテストするためのテスト仕様作成支援装置、テスト仕様作成方法、この方法をコンピュータに実行させるテスト仕様作成プログラムおよびこの方法に用いるデータベースの構築方法に係り、特に、テスト仕様の効率的な生成に適するテスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、およびテスト仕様作成プログラムに関する。
【０００２】
【従来の技術】
単体テストが完了したプログラム実体間を組み合わせて実体間のインターフェースや機能またはサブシステムの相互作用を検証する結合テストでは、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）により、テストの内容および合格の判断基準は異なる。従来の技術では、ＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）など外部仕様に関するテスト支援が中心で（例えば下記特許文献１、２参照）、外部仕様に限られない処理機能の種類を考慮した結合テスト仕様の自動生成までは行なわれていなかった。また、従来技術には、処理機能の性質を考慮したテストのノウハウなどとしてのデータの表現形態が開示されておらず、ノウハウの蓄積・再利用ができなかった。
【０００３】
【特許文献１】
特開２００２−７３３７２号公報
【特許文献２】
特開平９−２２３０４０号公報
【０００４】
【発明が解決しようとする課題】
本発明は、上記の事情を考慮してなされたもので、テスト方針の蓄積・再利用を可能にして統一した手順でテスト仕様書を効率的に作成し得るテスト仕様作成支援装置、テスト仕様作成方法、この方法をコンピュータに実行させるテスト仕様作成プログラムおよびこの方法に用いるデータベースの構築方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の課題を解決するため、本発明に係るテスト仕様作成支援装置は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義する手段と、前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成する手段とを具備することを特徴とする。
【０００６】
すなわち、この装置はテストシナリオ生成ルールを定義する手段を具備し、テストシナリオ生成ルールは、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したものである。定義されたテストシナリオ生成ルールにより、その条件部および実行部を用い、条件部と設計仕様とのマッチングをとって実行部を実行するという手順が提供される。この手順によれば、テスト方針の蓄積・再利用をテストシナリオ生成ルールの蓄積・再利用という形で可能にし、統一した手順でテスト仕様書を効率的に作成することが可能になる。
【０００７】
ここでソフトウエアのテストの観点および判断基準は、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）に応じて決めることができる。
【０００８】
また、上記の各手段は、例えば、マイクロプロセッサやメモリなどのハードウエハとこのハードウエア上で動作する基本ソフトウエアおよび応用ソフトウエアとにより実現できる。
【０００９】
また、本発明に係るテスト仕様作成方法は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義するステップと、前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成するステップとを具備することを特徴とする。
【００１０】
この方法は、上記のテスト仕様作成支援装置における動作を実現するものであり、この方法によれば、上記同様の作用により同様の効果を得ることができる。方法ではなく、各ステップを実行するプログラムとすることもできる。
【００１１】
また、本発明に係るデータベースの構築方法は、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールをデータベース化するデータベースの構築方法であって、前記条件部には前記ソフトウエアのテストの観点が表現され前記実行部には前記条件部が前記ソフトウエアの設計仕様に含まれていた場合に実行する判断基準が表現されている前記テストシナリオ生成ルールの前記条件部と前記実行部とをまとめて個々のテストシナリオ生成ルールごとにノードとしてくくり、前記ノード間に、該ノードに対応するテストシナリオ生成ルールを適用する順序情報を与えることを特徴とする。
【００１２】
また、本発明に係る別のデータベースの構築方法は、開発すべきソフトウエアの設計仕様情報をデータベース化するデータベースの構築方法であって、前記設計仕様に含まれる個々の動作ごとの処理仕様をそれぞれノードとしてくくり、前記ノード間に、該ノードに対応する処理仕様の流れを示す情報を与え、前記ノード間に、ひとつのアプリケーションを示す情報を与えることを特徴とする。
【００１３】
また、本発明に係るさらに別のデータベースの構築方法は、開発すべきソフトウエアのテストシナリオをデータベース化するデータベースの構築方法であって、前記テストシナリオに含まれる個々のテストごとにノードとしてくくり、前記ノード間に、該ノードに対応するテストの実施順序を示す情報を与えることを特徴とする。
【００１４】
これらのデータベースの構築方法は、上記のテスト仕様作成支援装置および方法において使用することができるものである。また、これらにより、処理機能の性質を考慮したテストのノウハウとしてのデータの表現形態が開示される。
【００１５】
【発明の実施の形態】
本発明の実施態様としてのテスト仕様作成支援装置は、前記設計仕様を入力する手段と、前記入力された設計仕様を蓄積する手段と、前記蓄積された設計仕様の中から任意のものを取り出す手段とをさらに具備する。装置の使い勝手を向上するため設計仕様の入力、蓄積、検索手段を設けるものである。
【００１６】
また、実施態様として、前記定義されたテストシナリオ生成ルールを蓄積する手段と、前記蓄積されたテストシナリオ生成ルールの中から任意のものを取り出す手段とをさらに具備する。同様に、テストシナリオ生成ルールの蓄積、検索手段を設けるものである。
【００１７】
また、実施態様として、前記定義する手段は、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出する手段と、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義する手段とを含む。設計仕様からテストの観点および判断基準を抽出するのを自動的に行なうものである。抽出されたテストの観点および判断基準はテストシナリオ生成ルールを作成するためのメタルールの一部とすることができる。
【００１８】
また、実施態様として、前記生成されたテストシナリオを蓄積する手段と、前記蓄積されたテストシナリオの中から任意のものを取り出す手段とをさらに具備する。装置の使い勝手を向上するためテストシナリオの蓄積、検索手段を設けるものである。
【００１９】
また、実施態様として、前記生成する手段は、前記設計仕様を展開保持する設計仕様展開保持部と、前記テストシナリオ生成ルールを展開保持するテストシナリオ生成ルール展開保持部と、前記展開保持された設計仕様と前記展開保持されたテストシナリオ生成ルールとからテストシナリオを生成するテストシナリオ生成エンジンと、前記生成されたテストシナリオを展開保持するテストシナリオ展開保持部とを含む。生成する手段を構成するひとつの例である。
【００２０】
また、本発明の実施態様としてのテスト仕様作成方法において、前記定義するステップは、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出するステップと、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義するステップとを含む。装置の場合と同様である。
【００２１】
また、実施態様として、前記生成するステップは、前記ソフトウエアの前記設計仕様から、生成すべきテストシナリオの項目および順序情報を抽出して前記生成すべきテストシナリオの初期情報を生成するステップを含む。これも装置の場合と同様である。
【００２２】
以上を踏まえ、以下では本発明の実施形態を図面を参照しながら説明する。図１は、本発明の一実施形態に係るテスト仕様作成支援装置の構成を示すブロック図である。
【００２３】
図１に示すように、このテスト仕様作成支援装置は、入力制御部１、出力制御部２、制御部３、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、テスト仕様書作成部７、設計仕様データベース（以下では、「データベース」を「ＤＢ」と記す。）８、テストシナリオ生成ルールＤＢ９、テストシナリオＤＢ１０、テスト仕様書ＤＢ１１、テストシナリオ生成メタルールＤＢ１２を有する。
【００２４】
入力制御部１は、ユーザ２０からの入力情報を取得し、これを制御部３に引き渡すものである。出力制御部２は、制御部３からの情報をユーザ２０に出力情報として引き渡すものである。
【００２５】
制御部３は、入力制御部１、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、およびテスト仕様書作成部７から情報を受け取り、また、受け取られた情報を、ステータスに応じて、設計仕様の選択・入力部４、テストシナリオ生成ルール選択・生成部５、テストシナリオ生成部６、またはテスト仕様書作成部７に引き渡すものである。また、必要に応じて、上記受け取られた情報を出力制御部２へ引き渡すものである。
【００２６】
設計仕様の選択・入力部４は、制御部３を介して入力制御部１から受け取った入力情報に応じて、次の処理を実行する。すなわち、入力情報が設計仕様の検索条件の場合には、設計仕様ＤＢ８より検索条件にマッチする設計仕様を検索し、検索された設計仕様を制御部３に保持する。制御部３に保持された設計仕様は、出力制御部２を通してユーザ２０に表示される。また、入力情報が設計仕様の登録条件の場合には、入力情報に含まれる設計仕様情報を制御部３に保持するとともに、設計仕様ＤＢ８に蓄積する。
【００２７】
テストシナリオ生成ルール選択・生成部５は、制御部３を介して入力制御部１から受け取った入力情報に応じて、次の処理を実行する。すなわち、入力情報がテストシナリオ生成ルールの検索条件の場合（テストシナリオ生成ルール選択時）には、テストシナリオ生成ルールＤＢ９より検索条件にマッチするテストシナリオ生成ルールを検索し、検索されたテストシナリオ生成ルールを制御部３に保持する。制御部に保持されたテストシナリオ生成ルールは、出力制御部２を通じてユーザに表示される。
【００２８】
また、テストシナリオ生成ルール選択・生成部５への入力情報がテストシナリオ生成ルールの登録条件の場合（テストシナリオ生成ルール作成時）には、テストシナリオ生成メタルールＤＢ１２に保持されたテストシナリオ生成メタルールに基づき、制御部３からの設計仕様情報よりテストの観点、判断基準を抽出し、抽出されたテストの観点、判断基準を制御部３、出力制御部２を介してユーザ２０に提示する。ユーザ２０は、提示されたテストの観点および判断基準に基づいてルール生成実行結果を入力制御部１に入力する。
【００２９】
入力されたルール生成実行結果は、制御部３を介してテストシナリオ生成ルール選択・生成部５に送られ、これによりテストシナリオ生成ルール選択・生成部５でテストシナリオ生成ルールが保持される。保持されたテストシナリオ生成ルールは、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータである。以上作成されたテストシナリオ生成ルールはテストシナリオ生成ルールＤＢ９に蓄積される。
【００３０】
テストシナリオ生成部６は、制御部３に保持された設計仕様情報およびテストシナリオ生成ルールからテストシナリオを自動生成し、自動生成されたテストシナリオを制御部３に保持するとともに、テストシナリオＤＢ１０に蓄積する。
【００３１】
テスト仕様書作成部７は、制御部３に保持されたテストシナリオに基づいて、制御部３、出力制御部２を通じて、ユーザ２０にテスト仕様書作成条件を提示する。また、ユーザ２０が入力した入力情報を入力制御部１、制御部３を介して受け取り、これに基づきテスト仕様書を作成しテスト仕様書ＤＢ１１に蓄積する。
【００３２】
なお、設計仕様ＤＢ８には、設計テンプレートに基づき作成された設計仕様が蓄積される。テストシナリオ生成ルールＤＢ９には、テストシナリオ生成ルールが蓄積される。テストシナリオＤＢ１０には、テストシナリオ生成部６にて生成されたテストシナリオが蓄積される。テスト仕様書ＤＢ１１には、テスト仕様書作成部７により生成されたテスト仕様書が蓄積される。テストシナリオ生成メタルールＤＢ１２には、テストシナリオ生成ルールを作成するためのメタルールが蓄積される。
【００３３】
図２は、図１中に示したテストシナリオ生成部６についての内部構成例を示すブロック図である。図２に示すように、このテストシナリオ生成部６は、設計仕様展開部６１、シナリオ生成ルール展開部６２、シナリオ生成エンジン６３、テストシナリオ展開部６４を有する。
【００３４】
設計仕様展開部６１は、シナリオ生成エンジン６３から渡された設計仕様情報を展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３の要求により保持された設計仕様情報を送出する。
【００３５】
シナリオ生成ルール展開部６２は、シナリオ生成エンジン６３から渡されたテストシナリオ生成ルールを展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３からの要求により保持されたテストシナリオ生成ルールを送出する。
【００３６】
シナリオ生成エンジン６３は、設計仕様およびシナリオ生成ルールの展開・保持、ならびに設計仕様とシナリオ生成ルールの条件部とのマッチング、シナリオ生成ルールの実行、および実行結果のテストシナリオＤＢ１０、制御部３への送出を行う。
【００３７】
テストシナリオ展開部６４は、シナリオ生成エンジン６３によって渡されたテストシナリオを展開保持する記憶手段（例えばメモリ）である。シナリオ生成エンジン６３からの要求により保持されたテストシナリオを送出する。
【００３８】
次に、上記説明のテスト仕様作成支援装置を用いることによるテスト仕様書の作成手順を図３をも参照して説明する。図３は、テスト仕様書を作成する全体手順を示す流れ図である。
【００３９】
まず、設計仕様を選択または入力する（ステップ３１）。このステップは、ユーザ２０による入力制御部１への入力と、この入力による制御部３、設計仕様の選択・入力部４、設計仕様ＤＢ８の動作により完了する。
【００４０】
次に、テストシナリオ生成ルールの選択（または作成および選択）を行なう（ステップ３２）。テストシナリオ生成ルールを作成する場合には、すでに述べたように、テストシナリオ生成ルール選択・生成部５にて、テストシナリオ生成メタルールＤＢ１２に保持されたテストシナリオ生成メタルールに基づき、制御部３から渡される設計仕様よりテストシナリオ生成ルールを作成し、テストシナリオ生成ルールＤＢ９に蓄積する。作成されたテストシナリオ生成ルールは、上述したように、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータである。テストシナリオ生成ルールの選択は、テストシナリオ生成ルールＤＢ９から該当のものを検索することによりなされる。
【００４１】
次に、ステップ３１で入力した設計仕様とステップ３２で選択したテストシナリオ生成ルールより、テストシナリオ生成部６でテストシナリオを生成する（ステップ３３）。さらに、ステップ３３で生成したテストシナリオと、入力制御部１を介するユーザからの要件に基づいて、テスト仕様書作成部７にてテスト仕様書を作成する（ステップ３４）。これにより、目的のテスト仕様書が作成されれば終了であり、引き続きテスト仕様書を作成する必要（例えば設計仕様に内容を追加してテスト仕様書を作り直すなど）があれば継続して最初から処理を行なう（ステップ３５）。
【００４２】
図４は、図３中で説明したステップ３３（テストシナリオの生成）内におけるやや詳細な手順の例を示す流れ図である。
【００４３】
テストシナリオを生成するには、まず、制御部３に保持された設計仕様のデータを取得し、これを設計仕様展開部６１を構成する例えばメモリ上に保持する（ステップ３３１）。また、選択されたテストシナリオ生成ルールを制御部３から取得し、これをシナリオ生成ルール展開部６２を構成する例えばメモリ上に保持する（ステップ３３２）。
【００４４】
次に、生成されるべきテストシナリオについての初期化を行なう（ステップ３３３）。具体的には、ステップ３３１で展開された設計仕様から、テストシナリオとしての項目および順序情報を抽出し、これによりテストシナリオの初期情報を生成する。
【００４５】
次に、ステップ３３２で展開されたテストシナリオ生成ルールのうちから適用可能なものがあるか否かを判断する（ステップ３３４）。具体的には、テストシナリオ生成ルールそれぞれの条件部とステップ３３１で展開された設計仕様とをマッチングさせる。マッチした場合には、そのルールを選択し（ステップ３３５）、さらにそのルールの実行部を適用する。適用された結果は、テストシナリオの一部として出力される（ステップ３３６）。
【００４６】
同様に、別のテストシナリオ生成ルールについて設計仕様とのマッチが存在する限り、上記のステップ３３５、３３６の処理を行なう。これにより、マッチがすべて存在しなくなったときにテストシナリオが完成する。テストシナリオが完成したら、制御部３に出力し（ステップ３３７）、かつテストシナリオＤＢへの蓄積を行なう（ステップ３３８）。
【００４７】
以上説明のように、設計仕様を用いて、テストの観点および判断基準に関するノウハウであるテストシナリオ生成ルールを条件部→実行部の形式で生成してこれをＤＢ化することにより、ＤＢの内容の再利用を可能にし統一した手順でテスト仕様書を効率的に作成することができる。
【００４８】
【実施例】
次に、図５に示すような画面遷移を備えたＷｅｂバンキングシステムを例に取り、本発明の実施例としてのテスト仕様作成方法を説明する。図５は、本発明の実施例としてのＷｅｂバンキングシステムにおける表示画面（その一部）の変化を示す遷移図である。
【００４９】
図５に示すように、これらの画面５０、…、６０は、それぞれ名称が与えられ、かつ矢印のように遷移または上位、下位の関係を有する。このようなＧＵＩとこれに伴う処理（内部仕様に関する処理）とが開発・作成されるべきソフトウエアに相当する。
【００５０】
図６は、図５に示した画面遷移を備えたＷｅｂバンキングシステムの設計仕様を示す仕様書の記述例を表わす図である。この仕様書は、一定の設計テンプレートに従って作成されている。すなわち、図５において、表を構成する行それぞれはユーザからのひとつの動作（ボタンの押下、メニュー選択）によって実施する一塊の処理を示している。実施する処理の細目内容は、表を構成する列で項目ごとに分類して示される。
【００５１】
処理の項目（細目内容）は以下である：
・ユースケース：システムの業務機能。該当行の処理が関連する業務機能名。
・ユースケースシナリオ：該当行の処理が実施される際の状況。
・動作：該当行の処理を実施のトリガ。
・アクタ：該当行の処理を実施する権限のある利用者（または他システム、機能）
・順序：該当行の処理が前後の行の処理と連続する場合に、実行の順序を示す数値。
・入力画面：該当行の処理を開始する際に表示されている画面。
・入力データ：画面などから入力するデータ名。
・テーブル：対象となるテーブル名。
・条件：画面遷移／帳票出力／バッチ処理などの処理を実行する際に前提となる条件。
・メッセージ：該当行の処理実行時に表示するメッセージ内容。
・遷移先画面：該当行の処理の実行後に遷移する画面。
・出力帳票：該当行の処理の実行後に出力する帳票。
・処理種別：該当行の処理の種別（画面系、帳票系、バッチ系を複数選択）。
・タイプ：該当行の処理のタイプ（登録系、検索系、その他のいずれかを選択）。
【００５２】
このような項目はユーザが決定し入力制御部１より入力する。例えば、図６における１行目（Ｎｏ．１）の処理は、次のことを示す。
・当該行の処理は、ユースケース「各種情報を照会する」に関する処理である。・当該行の処理は、ユースケースシナリオ「残高を照会する」場合に実行する処理である。
・当該行の処理は、動作「情報照会」メニューのクリック」により実施する。
・当該行の処理は、アクタ「顧客」の権限を有するものが実施可能である。
・当該行の処理は、後続する一連の処理間において、１番目に実行する処理である。
・当該行の処理は、入力画面「メニュー画面」より開始する。
・当該行の処理は、入力データはない。
・当該行の処理は、対象となるテーブルはない。
・当該行の処理を実施するための条件はない。
・当該行の処理の実施後に、表示するメッセージはない。
・当該行の処理の実施後、遷移先画面「情報照会サブメニュー画面」に遷移する。
・当該行の処理は、出力帳票はない。
・当該行の処理は、処理種別「画面系」の処理である。
・当該行の処理は、タイプ「その他」の処理である。
他の行についても同様である。このような処理内容はユーザが決定し入力制御部１より入力する。
【００５３】
次に、図６に示したような設計仕様を設計仕様ＤＢ８内に蓄積するときの方式について説明する。図７は、図６で説明した設計仕様を設計仕様ＤＢ８に保存するときの方式を説明する図である。
【００５４】
図７において、○（ノード）は、一行分の仕様を示し、矢印および直線はノード間の関係を示す。矢印は、ノード間に連続した関係があることを示す（ノード間の関係は上記説明の項目「順序」より導出されている）。直線で結んだノードの集合は、それらが同一のアプリケーションに関する仕様であることを示している。例えば、図７（ａ）は、ノード１、…、ノード６、ノード９、…、１１が同一アプリケーションに関する仕様であることを示し、図７（ｂ）は、ノード５１、…、ノード５５、ノード５９、ノード６０が別の同一アプリケーションに関する仕様であることを示す。
【００５５】
次に、図７に示した各ノードおよびそれらの関係を記述する記述形式について説明する。各アプリケーションについて記述形式は、リストとして、例えば、［［ＡＰＮ］， ［［Ｓ１， Ｓ２， Ｓ３］， ［Ｓ４， Ｓ５， Ｓ６］，［Ｓ７］，…，［ＳＮ］］］ となる。
ここで、ＡＰＮはアプリケーション名、
Ｓ１， Ｓ２， Ｓ３，…，ＳＮは、それぞれ、一行分の設計仕様、
［Ｓ１， Ｓ２， Ｓ３］は、Ｓ１， Ｓ２， Ｓ３が一連の連続した処理であることを示す。［Ｓ４， Ｓ５，Ｓ６］も同様である。
【００５６】
１行分の設計仕様Ｓｍそれぞれの記述形式は、リストとして、例えば、［Ｎｏ（Ａ）， ユースケース（Ｂ）， ユースケースシナリオ（Ｃ）， 動作（Ｄ）， アクタ（Ｅ）， 順序（Ｆ）， 入力画面（Ｇ）， 入力データ（Ｈ）， テーブル（Ｉ）， 条件（Ｊ）， メッセージ（Ｋ）， 遷移先画面（Ｌ）， 出力帳票（Ｍ）， 処理種別（Ｎ）， タイプ（Ｏ）］ となる。ここで、Ａ〜Ｏは変数。Ｓｍを構成する要素のそれぞれが１階の述語論理に基づく論理式に相当する。
【００５７】
具体的な記述例を挙げると、図６の１行目の設計仕様については以下のようになる。
Ｓ１＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（“残高を照会する”）， 動作（“「情報照会メニュー」をクリック”）， アクタ（“顧客”）， 入力画面（“メニュー画面”）， 順序（“１”）， 入力データ（ｎｕｌｌ）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）， タイプ（“その他”）］
【００５８】
以上説明のように、例えば図６に示すような設計仕様は上記のように方式化、形式化され設計仕様ＤＢ８に蓄積される。すなわち、ユーザは、図６に示す表の形式により設計仕様を入力し、入力された設計仕様は、図７に示す方式により設計仕様ＤＢ８へ蓄積され、かつそれぞれのアプリケーションについて上記のような形式により記述されている。
【００５９】
すでに蓄積済みの設計仕様は、アプリケーション名を選択することにより、該当するアプリケーションとしてリンクづけられた仕様（ノード）を抽出し図６のような一覧表形式によりユーザに表示することができる。
【００６０】
図６のような設計仕様（開発・作成されるべきソフトウエアの設計仕様）が入力されたあと、このソフトウエアをテストするためのシナリオを生成することが、本発明を具体的に適用することにより可能となる。これを以下説明する。
【００６１】
基本的には、このシナリオは、テストの観点および判断基準に関するノウハウをルール形式（条件部→実行部）で表現したデータであるテストシナリオ生成ルールを、上記の設計仕様に適用することによって生成することができる。テストシナリオ生成ルールは、あらかじめ作成しておいたものを用いる。
【００６２】
テストシナリオ生成ルールを作成する手順について説明する。テストシナリオ生成ルールは、テストシナリオ生成メタルール（以下ではメタルールという。）に基づいて、与えられた設計仕様から作成することができる。図８は、メタルールの例を示す図である。
【００６３】
メタルールは、設計仕様がベースとしている設計モデルに沿って、テストシナリオ生成ルールを作成するための上位の知識である。また、設計モデルとテストシナリオ生成ルールとを関連づける役割を持ち、結果として、設計モデルが提示する考え方に沿った形でテストシナリオを生成することを可能にするための知識である。
【００６４】
具体的には、メタルールは、設計仕様の構成要素（項目）と構成要素のとり得る値とを、テストシナリオ生成ルールの条件部に出現する節の候補として与える。図８に示すように、メタルールそれぞれの構成は以下のようになっている。
観点：設計仕様の構成要素（項目）。
基準値：「観点」の持つべき値や検証すべき値。（初期値は有無（１または０）とする。）
ルール：このメタルールにより作成したテストシナリオ生成ルールの識別子。（ルール番号やＩＤなどが相当する。このメタルールによりテストシナリオ生成ルールを作成した後、決定する。）
これにより、メタルールＤＢ１２には、これらのメタルールが、設計仕様にて定義している観点の数分、蓄積されていることになる。
【００６５】
図９は、図６に示す設計仕様を前提としたメタルールの一部を示す図である。具体的には、図９（ａ）、図９（ｂ）は、それぞれ、構成要素「遷移先画面」、「入力データ」に関してメタルールの初期値を定義した結果を示す。図１０は、図９に示すメタルールに対して、テストシナリオ生成ルールの定義（作成）後、これを、関連する「観点」に関連付けた結果を示す図である。
【００６６】
テストシナリオ生成ルールの具体的作成について説明する。まず、作成後のルールがテストシナリオ生成ルールＤＢ９に蓄積・保持されるときの保存方式を図１１を参照して述べる。図１１は、テストシナリオ生成ルールＤＢ９における保存方式を示す図である。図１１において、○（ノード）は、テストシナリオ生成のひとつのルールを示す。ノード間の矢印はルール間の関係（適用順序）を示すものである。
【００６７】
ここで、テストシナリオ生成ルールの記述形式を例えば以下のようにする。
［Ｒｕｌｅｓ， Ｏｒｄｅｒ］
Ｒｕｌｅｓ： ［Ｒ１， Ｒ２， Ｒ３，…， ＲＮ］
Ｒ１， Ｒ２， Ｒ３，…， ＲＮは、それぞれ、一つのテストシナリオ生成ルールを示すルールＩＤ。
Ｏｒｄｅｒ：［Ｏ１， Ｏ２， Ｏ３，…，ＯＮ］
Ｏ１， Ｏ２， Ｏ３，…，ＯＮ における Ｏｉ それぞれは、Ｒｉを実行後に次に実施可能なルールのルールＩＤを示すリスト。
【００６８】
これを用い、図１１に示すテストシナリオ生成ルールは、以下のように記述される。
［［ｒ１， ｒ２， ｒ３， ｒ４， ｒ５， ｒ６， ｒ７， ｒ８， ｒ９， ｒ１０， ｒ１１， ｒ１２］， ［［ｒ３， ｒ４］， ［ｒ３， ｒ４］， ［ｒ５， ｒ６］， ［ｒ５， ｒ６］， ［ｒ７， ｒ８］， ［ｒ７， ｒ８］， ［ｒ９］， ［ｒ９］， ［ｒ１０］， ［ｒ１１］， ［ｒ１２］， ［［］］］
すなわち、１２個のルールがあり、各識別子がｒ１〜ｒ１２となる。ルールｒ１の実行後に次に実施可能なルールは、ルールｒ３またはルールｒ４である。ルールｒ２以下ルールｒ１１まで同様である。ルールｒ１２の実行後の次に実施可能なルールは“［］”、すなわち、実施するルールはなく、ルールｒ１２が定義された最終のルールである。
【００６９】
ここで、テストシナリオ生成ルールＲｉそれぞれの記述形式は、例えば、以下の形式で記述することができる。
”Ｉｆ ＬＨＳ， ｔｈｅｎ ＲＨＳ．”
ここで、ＬＨＳおよびＲＨＳは１階の述語論理式である。
【００７０】
図６に示した設計仕様に対してメタルールを用いると、設計仕様の構成要素（項目）と構成要素のとり得る値とを、テストシナリオ生成ルールの条件部に出現する節の候補として与え、次のようにルールを定義（作成）することができる。
（ルールｒ１）データ入力後の画面遷移の場合： 指定したデータ入力後に指定した遷移先画面に遷移することを確認する。
（ルールｒ２）遷移先画面がある場合： 指定した遷移先に遷移することを確認する。
（ルールｒ３）データ入力後の帳票出力の場合： 指定したデータ入力後に指定した帳票が出力されることを確認する。
（ルールｒ４）出力帳票がある場合： 指定した帳票が出力されることを確認する。
（ルールｒ５）データ入力後のバッチ処理の場合： 指定したデータ入力後に指定したバッチ処理結果がテーブルの内容に反映されていることを確認する。
（ルールｒ６）バッチ処理の場合： バッチ処理結果がテーブルの内容に反映されていることを確認する。
（ルールｒ７）登録系の画面遷移の場合： 登録済みテーブルの内容と入力したデータとが一致することを確認する。
（ルールｒ８）検索系の画面遷移の場合： 登録済みテーブルの内容と表示したデータの内容とが一致することを確認する。
（ルールｒ９）利用者権限がある場合： 指定した利用者の権限にて処理が正しく実行されることを確認する。
（ルールｒ１０）画面遷移／帳票出力／バッチ処理実施のための条件が指定されている場合： 指定された条件にて正しく処理が実行されていることを確認する。
（ルールｒ１１）出力メッセージがある場合： 指定したメッセージが出力されることを確認する。
（ルールｒ１２）画面遷移／帳票出力／バッチ処理に一連の処理順序が設定されている場合： 一連の処理の流れが正しいことを確認する。
【００７１】
以上のルールｒ１〜ｒ１２同士の関係は、図１１に示すような関係になっている。ルールｒ１〜ｒ１２を、上記説明のルールの記述形式に従って表現すると以下のようになる。
【００７２】
（ルールｒ１）遷移先画面有り＆入力データ有
【数１】
（ルールｒ２）遷移先画面有り＆入力データなし
【数２】
（ルールｒ３）出力帳票有り＆入力データ有り
【数３】
（ルールｒ４）出力帳票有り＆入力データなし
【数４】
（ルールｒ５）バッチ処理＆入力データあり
【数５】
（ルールｒ６）バッチ処理＆入力データなし
【数６】
（ルールｒ７）登録系
【数７】
（ルールｒ８）検索系
【数８】
（ルールｒ９）利用者権限有無
【数９】
（ルールｒ１０）条件指定あり
【数１０】
（ルールｒ１１）出力メッセージあり
【数１１】
（ルールｒ１２） 画面に一連の処理の順序がある場合の確認
【数１２】
次に、テストシナリオの具体的生成について説明する。まず、作成後のシナリオがテストシナリオＤＢ１０に蓄積・保持されるときの保存方式を図１２を参照して述べる。図１２は、テストシナリオＤＢ１０における保存方式を示す図である。図１２において、○（ノード）は、ひとつのテストシナリオを示す。ノード間の矢印は、ノード間に連続した関係があることを示す。直線で結んだノードの集合は、それらが同一のアプリケーションに関するテストシナリオ（またはテスト仕様。「テスト仕様」は、テストシナリオをユーザに示す形式に変換したもの）であることを示す。
【００８５】
テストシナリオの記述形式は、例えば次にようにすることができる。
［［ＡＰＮ］， ［［Ｓ１， Ｓ２， Ｓ３］， ［Ｓ４， Ｓ５， Ｓ６］，［Ｓ７］，…，［ＳＮ］］］
ここで、ＡＰＮはアプリケーション名、
Ｓ１， Ｓ２， Ｓ３，…，ＳＮは、それぞれ、一行分のテストシナリオ、
［Ｓ１， Ｓ２， Ｓ３］は、Ｓ１，Ｓ２，Ｓ３が連続した一連のテストシナリオであることを示す。［Ｓ４， Ｓ５， Ｓ６］も同様。
【００８６】
１行分のテストシナリオＳｍそれぞれの記述形式は、リストとして、例えば、［Ｙ］＝［Ｎｏ（Ａ）， ユースケース（Ｂ）， ユースケースシナリオ（Ｃ）， タイプ（Ｏ）， 順序（Ｆ）， 確認項目（Ｐ）， アクタ（Ｅ）， 入力画面（Ｇ）， 入力データ（Ｈ）， 動作（Ｄ）， テーブル（Ｉ）， 条件（Ｊ）， メッセージ（Ｋ）， 遷移先画面（Ｌ）， 出力帳票（Ｍ）， 処理種別（Ｎ）］ となる。ここで、Ａ〜Ｐは変数。Ｓｍを構成する要素のそれぞれが１階の述語論理に基づく論理式に相当する。
【００８７】
図６に示したような、ひとつのアプリケーションの設計仕様と、これに対応する、ひとつのアプリケーションのテストシナリオ（後述する図１６、図１７）との記述上の関係は、次のように表わすことができる。
【数１３】
ひとつ（１行分）のテストシナリオの具体的な記述例は、例えば、Ｙ＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（“残高を照会する”）， タイプ（“単純遷移”）， 順序（“１”）， 確認項目（“アクアの権限のユーザによって、入力画面から動作実行後、遷移先画面への遷移が正しく行われることを確認する。”）， アクタ（“顧客”）， 入力画面（“メニュー画面”）， 入力データ（ｎｕｌｌ）， 動作（“「情報照会メニュー」をクリック”）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）］ となる（図１６の１行目のテスト仕様）。
【００８９】
上記ですでに説明した、ルールの例としてのルールｒ１〜ｒ１２は、図１３に示すような表形式でユーザが入力することができる。図１３は、ルールの入力、表示を行う画面の例を示す図である。入力されたルールはテストシナリオ生成ルールＤＢ９に蓄積される。また、入力・蓄積されているテストシナリオ生成ルールは、図１３に示すような表の形式にてユーザに表示することができる。
【００９０】
以上を前提にテストシナリオの具体的生成を、以下、説明する。まず、設計仕様を入力して設計仕様ＸＸＸＸを得（設計仕様展開部６１）、また、テストシナリオ生成ルール［Ｒｕｌｅｓ， Ｏｒｄｅｒ］をシナリオ生成ルール展開部６２に保持しておく。そして、図１４に示す処理を行なうことによりテストシナリオＹＹＹＹを初期化する。図１４は、テストシナリオを初期化する処理を示す流れ図であり、すでに説明した図４の流れ図におけるステップ３３３に相当する処理を示すものである。この初期化の過程では、設計仕様ＸＸＸＸから、テストシナリオＹＹＹＹとしての項目および順序情報を抽出する処理が含まれる。
【００９１】
図１４を参照するに、ステップ１４１からステップ１４５はこの処理の前処理に相当する。ステップ１４１でテストシナリオＹＹＹＹの空リストを用意し、ステップ１４２でアプリケーション名をテストシナリオＹＹＹＹに定義する。さらにステップ１４３で設計仕様ＸＸＸＸの２番目の要素（１番目の要素を除く全体）をＸＸＸとして、これに相当するテストシナリオの要素ＹＹＹの空リストを用意する。次に、ＸＸＸの長さ（要素の数：既知）をＬとして（ステップ１４４）、ＸＸＸの長さ分のループ処理（ステップ１４６以下）を行なうためのループ変数ｉを初期数に設定する（ステップ１４５）。
【００９２】
ステップ１４６の次に、ＸＸＸのｉ番目の要素を取出してＸＸとし（ステップ１４７）、ＸＸの長さ（既知）をＭとして、ＸＸの長さ分のループ処理（ステップ１４９以下）を行なうためのループ変数ｊを初期数に設定する（ステップ１４８）。
【００９３】
ステップ１４９の次に、ＸＸのｊ番目の要素をＸとし（ステップ１５０）、Ｘの内容をＹに代入する（ステップ１５１）。Ｙには要素として「確認項目」が付加されている。これが生成されるべきテスト仕様としての主要部分に相当する。図１４における処理では、初期化としてこの内容はｎｕｌｌとして出力される。
【００９４】
ステップ１５０の処理後、ワークエリアＺを空リストとして用意し（ステップ１５２）、ＹをＺに追加する（ステップ１５３）。さらに、ｊ値を更新して（ステップ１５４）、ステップ１４９からのループ処理を繰り返す。これで所定数Ｍ回のループ処理が行なわれてＸＸを構成する全部の要素について処理が終わる（ステップ１４９のＹ）。これにより、ステップ１５５でＹＹＹにＺの内容を追加し、ｉ値を更新して（ステップ１５６）、さらにステップ１４６からのループ処理を繰り返す。このループ処理が所定数Ｌ回行なわれるとＸＸＸを構成するすべての要素について処理が終わる（ステップ１４６のＹ）。これにより、ステップ１５７でＹＹＹＹにＹＹＹを追加し、テストシナリオＹＹＹＹの初期化を終了する。
【００９５】
次に、図１５に示す処理を行なう。図１５は、図１４に示す初期化処理に続くテストシナリオの具体的生成の処理手順を示す流れ図であり、すでに説明した図４の流れ図におけるステップ３３４からステップ３３６に相当する処理を示すものである。なお、図１５では、ステップ３３４からステップ３３６の処理に個々には対応する表現にはなっていない。
【００９６】
図１５に示す処理においては、ステップ１６１からステップ１６８、およびステップ１７０、ステップ１７１について、ほぼ、図１４に示したステップ１４３から１５０、およびステップ１５４、ステップ１５６とそれぞれ同様の処理が行なわれる。
【００９７】
図１５のステップ１６９の処理が、テストシナリオの自動生成に関する処理である。ステップ１６９は、ステップ１６８で１行分の設計仕様Ｘを取出すことを前提に開始される。すなわち、その後、まず、ルールを読み込んでかつステップ１６９ｃ以降のルール長さ分のループ処理を行なうためのループ変数ｋを初期数に設定し（ステップ１６９ａ）、実行済みのルールを記入するリストＱを空リスト（［］）に設定する（すなわちＱ＝［］とする（ステップ１６９ａ−１））。また、ルールのリストの長さ（既知）をＬ１とする（ステップ１６９ｂ）。
【００９８】
ステップ１６９ｃの後、ｋ番目のルールを適用する（ステップ１６９ｄ）。具体的には、Ｒｋのルールの条件部が真で、かつ実行済ルールリストＱにＲｋが含まれていない場合（ケース１）には、Ｒｋのルールの実行部を実行し、実行済ルールリストＱにはＲｋを追加する。この場合には、次にステップ１６９ｅに進む。また、Ｒｋのルールの条件部が真で、かつ実行済ルールにＲｋが含まれている場合（ケース２）には、Ｒｋの実行部は実行しない。このまま次にステップ１６９ｅに進む。また、Ｒｋのルールの条件部が偽である場合（ケース３）には、何もせず、次には直接ステップ１６９ｋに進む。
【００９９】
ステップ１６９ｅに進んだ場合には、次に、ステップ１６９ｇ以降の順序リスト長さ分のループ処理を行なうためのループ変数ｌを初期数に設定し（ステップ１６９ｅ）、順序リストの長さ（既知）をＬ２とする（ステップ１６９ｆ）。
【０１００】
次に、ｋ番目のルールの次に適用するルールの順序リストのｌ番目のルールを抽出し（ステップ１６９ｈ）、ルール番号を取得するとともにこのルールの条件部が真になる場合にその実行部を実行する（ステップ１６９ｉ）。そしてｌ値を更新して（ステップ１６９ｊ）、ステップ１６９ｇ以降のループ処理を行う。
【０１０１】
順序リストにあるすべてのルールについて上記処理が終了したら（ステップ１６９ｇのＹ）、ｋ値を更新し（ステップ１６９ｋ）、ステップ１６９ｃからのループ処理を繰り返す。すべてのルールについて処理が終われば（ステップ１６９ｃのＹ）、ｊ値またはｉ値を更新して（ステップ１７０、ステップ１７１）、同様に繰り返すことによりすべての処理を終了する。これによりテストシナリオＸＸＸＸを得ることができる。
【０１０２】
例えば、以下の場合：
【数１４】
【０１０３】
すなわち、この場合には、ルールｒ２、ルールｒ９で条件部が真となり、これらの実行部が適用され、以下のシナリオが生成される。
Ｙ＝［Ｎｏ（“１”）， ユースケース（“各種情報を照会する”）， ユースケースシナリオ（Ｃ）， タイプ（“その他”）， 順序（“１”）， 確認項目（“入力画面から動作実行後、遷移先画面への遷移が正しく行われることを確認する。指定した利用者の権限にて処理が正しく実行されることを確認する。”）， アクタ（“顧客”），入力画面（“メニュー画面”）， 入力データ（ｎｕｌｌ）， 動作（“「情報照会メニュ」をクリック”）， テーブル（［ｎｕｌｌ］）， 条件（ｎｕｌｌ）， メッセージ（ｎｕｌｌ）， 遷移先画面（“情報照会サブメニュー”）， 出力帳票（ｎｕｌｌ）， 処理種別（“画面系”）］
【０１０４】
上記のようにして得られたＹそれぞれを最下位の要素としてテストシナリオＹＹＹＹを得たら、次に、このテストシナリオを、図１６、図１７に示す表形式のテスト仕様書に変換して、ユーザに表示する。図１６、図１７は、図６に示した設計仕様に対応するテスト仕様の生成例を示す図である。ユーザは、表形式の幅・高さ、項目名、列行の追加などの編集を行って、所望のテスト仕様書の形式に整形後、テスト仕様書ＤＢ１１に蓄積する。
【０１０５】
このあと、設計仕様の修正・変更やシナリオ生成ルールなどの追加・変更などがある場合には、図３に示す流れにより、そのステップ３１に戻りテストシナリオ生成の処理を繰り返すことができる。以上により、図５に示すような画面遷移を備えたＷｅｂバンキングシステムにおけるテスト仕様作成方法の流れをひととおり説明した。この実施例の説明で明らかなように、処理機能の種類（例えば登録系／参照系／バッチ処理系などの種類）によりテストの内容や合格の判断基準が異なってもテスト仕様の自動生成が実現する。例えばＧＵＩ等の外部仕様に限らず、内部処理の設計仕様についてもテスト仕様の自動生成が可能になる。
【０１０６】
次に、設計仕様に追加を行い、これに対応してテストシナリオ（テスト仕様）を生成し直す例について以下説明する。図１８は、図６に示した設計仕様情報に仕様の追加を行った設計仕様例を示す図である。この設計仕様では、図示するように「サービス名」の列１８１が追加され、この列に交わる各行において、実行する処理としての関連サービス名が示されている。
【０１０７】
仕様が追加されると、テストシナリオ生成ルール選択・生成部５において、追加仕様に関するメタルールが初期生成される。図１９に、項目「サービス名」に関するメタルールの初期生成結果を示す。メタルールＤＢ１２には、図１０に示したメタルールに加えて図１９に示す「サービス名」に関するメタルールが追加・蓄積される。
【０１０８】
追加されたメタルールに基づいて、テストシナリオ生成ルールを新規追加する作業手順を図２０〜図２７に示す。図２０〜図２７は、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図である。メタルールによるテストシナリオ生成ルールの定義は、メタルール表示ウィンドウ２０１（２０１Ａ〜２０１Ｆ）およびテストシナリオ生成ルール定義ウインドウ２０２（２０２Ａ〜２０２Ｆ）を通して、相互にデータの参照および連携をとりながら進めることができる。
【０１０９】
図２０は、メタルール表示ウインドウ２０１およびテストシナリオ生成ルール定義ウインドウ２０２の初期画面を示している。メタルール表示ウインドウ２０１には、図１０および図１９にて定義したメタルール全体が表示される。テストシナリオ生成ルール定義ウインドウ２０２は、２つのウインドウにさらに分かれる。
【０１１０】
上部は、メタルール表示ウインドウ２０１での定義結果に基づいて、設計仕様に沿った条件式を構築する作業ウインドウ２０２ａ（２０２Ａａ〜２０２Ｆａ）である。下部は、ルールＮｏ．、条件部、実行部、次ルール、説明の項目からなり、テストシナリオ生成ルールを定義する作業ウインドウ２０２ｂ（２０２Ａｂ〜２０２Ｆｂ）である。なお、すでに説明した図１３は、ウインドウ２０２ｂの表示内容の例を拡大して示したものに相当する。
【０１１１】
テストシナリオ生成ルールを作成するには、メタルール表示ウインドウ２０１での定義結果を利用して条件式を定義し（作業ウインドウ２０２ａ）、さらに、ここで定義した条件式を利用して、テストシナリオ生成ルール定義ウインドウ２０２の下部の作業ウインドウ２０２ｂ内のルールＮｏ．、条件部、実行部、次ルール、説明の項目を記載しながら定義して行なう。
【０１１２】
図２１は、メタルール表示ウインドウ２０１Ａで、新規に追加した「観点：サービス名」に関するルールを作成するために、「観点：サービス名」を選択していることを示す。図２２は、マウス（入力制御部１の一部）のドラッグ＆ドロップにより、選択した「観点：サービス名」をテストシナリオ生成ルール定義ウインドウ２０２Ｂの「観点」エリアに配置したことを示す。図示するように、「観点：サービス」の配置により、基準値：有、基準値：無の初期値が表示される。
【０１１３】
図２３は、テストシナリオ生成ルール定義ウインドウ２０２Ｃにおいて、観点および基準値の情報を参照しながら、「条件式」を記載した結果を示している。ここで、ユーザは、必要に応じて、基準値を追加することができる。図２４は、テストシナリオ生成ルール定義ウインドウ２０２Ｄにおいて、ユーザが必要に応じて、新たに「基準値：ログ出力」を定義し、「条件式」を追記したことを示している。
【０１１４】
次に、図２４での観点、基準値、条件式を利用して、テストシナリオ生成ルール定義ウインドウ２０２Ｄの下部において、テストシナリオ生成ルールを定義する。図２５は、「観点：サービス」の追加により、新規に作成されたルールｒ１３およびｒ１４を示している。
【０１１５】
なお、追加のテストシナリオ生成ルールの定義後には、メタルールへその追加・変更を反映させる。図２６は、メタルール表示ウインドウ２０１Ｅに、「基準値：ログ出力」を追加している過程を示している。図２７は、メタルール表示ウインドウに２０１Ｆ、「基準値：ログ出力」が追加されたことを示す。
【０１１６】
また、テストシナリオ生成ルールによるテストシナリオ生成後、「観点：サービス名」に関するメタルールには、ルールｒ１３およびｒ１４を作成した情報が反映される。図２８は、ルールｒ１３およびルールｒ１４の適用後の「観点：サービス名」に関するメタルールを示す図である。
【０１１７】
以上説明のように、テストシナリオ生成ルールを追加することができる。この結果を用い、テストシナリオを再構成しテスト仕様を生成した例を図２９に示す。図２９は、図１６に示した設計仕様を用いてテスト仕様を作成した例を示す図である。図２９においてはサービス名の列２９１の追加がなされ、かつ、確認項目のうち欄２９２および２９３が、ルールｒ１３およびルールｒ１４の適用結果が反映されたものとなる。
【０１１８】
このように、テスト方針の蓄積・再利用を可能にして統一した手順でテスト仕様書を効率的に作成することができる。また、ソフトウェアの内部設計仕様に関する仕様から結合試験のテスト項目を自動生成し、テスト仕様作成の手間を軽減することができる。また、テストシナリオ生成ルールを作成するためのメタルールを備えることにより、設計仕様の拡張や変更に柔軟に対応して、テストシナリオの生成ルールの定義およびテストシナリオの生成を行うことができる。
【０１１９】
【発明の効果】
以上詳述したように、本発明では、テストシナリオ生成ルールを定義する手段を具備する。テストシナリオ生成ルールは、開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したものである。定義されたテストシナリオ生成ルールにより、その条件部および実行部を用い、条件部と設計仕様とのマッチングをとって実行部を実行するという手順が提供される。この手順によれば、テスト方針の蓄積・再利用をテストシナリオ生成ルールの蓄積・再利用という形で可能にし、統一した手順でテスト仕様書を効率的に作成することが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るテスト仕様作成支援装置の構成を示すブロック図。
【図２】図１中に示したテストシナリオ生成部６についての内部構成例を示すブロック図。
【図３】図１に示したテスト仕様作成支援装置におけるテスト仕様書を作成する全体手順を示す流れ図。
【図４】図３中で説明したステップ３３（テストシナリオの生成）内におけるやや詳細な手順の例を示す流れ図。
【図５】本発明の実施例としてのＷｅｂバンキングシステムにおける表示画面（その一部）の変化を示す遷移図。
【図６】図５に示した画面遷移を備えたＷｅｂバンキングシステムの設計仕様を示す仕様書の記述例を表わす図。
【図７】図６で説明した設計仕様を設計仕様ＤＢ８に保存するときの方式を説明する図。
【図８】メタルールの例を示す図。
【図９】図６に示す設計仕様を前提としたメタルールの一部を示す図。
【図１０】図９に示すメタルールに対して、テストシナリオ生成ルールの定義（作成）後、これを、関連する「観点」に関連付けた結果を示す図。
【図１１】テストシナリオ生成ルールＤＢ９における保存方式を示す図。
【図１２】テストシナリオＤＢ１０における保存方式を示す図。
【図１３】ルールの入力、表示を行う画面の例を示す図。
【図１４】テストシナリオを初期化する処理を示す流れ図。
【図１５】図１４に示す初期化処理に続くテストシナリオの具体的生成の処理手順を示す流れ図。
【図１６】図６に示した設計仕様に対応するテスト仕様の生成例を示す図。
【図１７】図１６の続図であって、図６に示した設計仕様に対応するテスト仕様の生成例を示す図。
【図１８】図６に示した設計仕様情報に仕様の追加を行った設計仕様例を示す図。
【図１９】項目「サービス名」に関するメタルールの初期生成結果を示す図。
【図２０】追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２１】図２０の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２２】図２１の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２３】図２２の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２４】図２３の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２５】「観点：サービス」の追加により、新規に作成されたルールｒ１３およびｒ１４を示す図。
【図２６】図２４の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２７】図２６の続図であって、追加されたメタルールに基づいてテストシナリオ生成ルールを新規追加する作業手順を、画面（出力制御部２の一部）に表示されるウインドウを用いて説明する図。
【図２８】ルールｒ１３およびルールｒ１４の適用後の「観点：サービス名」に関するメタルールを示す図。
【図２９】図１６に示した設計仕様を用いてテスト仕様を作成した例を示す図。
【符号の説明】
１…入力制御部 ２…出力制御部 ３…制御部 ４…設計仕様の選択・入力部５…テストシナリオ生成ルール選択・生成部 ６…テストシナリオ生成部 ７…テスト仕様書作成部 ８…設計仕様データベース ９…テストシナリオ生成ルールデータベース １０…テストシナリオデータベース １１…テスト仕様書データベース １２…テストシナリオ生成メタルールデータベース ６１…設計仕様展開部 ６２…シナリオ生成ルール展開部 ６３…シナリオ生成エンジン ６４…テストシナリオ展開部 ２０１、２０１Ａ、２０１Ｂ、２０１Ｃ、２０１Ｄ、２０１Ｅ、２０１Ｆ…メタルール表示ウインドウ ２０２、２０２Ａ、２０２Ｂ、２０２Ｃ、２０２Ｄ、２０２Ｅ、２０２Ｆ…テストシナリオ生成ルール定義ウインドウ ２０２ａ、２０２Ａａ、２０２Ｂａ、２０２Ｃａ、２０２Ｄａ、２０２Ｅａ、２０２Ｆａ…作業ウインドウ ２０２ｂ、２０２Ａｂ、２０２Ｂｂ、２０２Ｃｂ、２０２Ｄｂ、２０２Ｅｂ、２０２Ｆｂ…作業ウインドウ
Claims (13)
- 開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義する手段と、
前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成する手段と
を具備することを特徴とするテスト仕様作成支援装置。 - 前記設計仕様を入力する手段と、
前記入力された設計仕様を蓄積する手段と、
前記蓄積された設計仕様の中から任意のものを取り出す手段と
をさらに具備することを特徴とする請求項１記載のテスト仕様作成支援装置。 - 前記定義されたテストシナリオ生成ルールを蓄積する手段と、
前記蓄積されたテストシナリオ生成ルールの中から任意のものを取り出す手段と
をさらに具備することを特徴とする請求項１記載のテスト仕様作成支援装置。 - 前記定義する手段は、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出する手段と、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義する手段とを含むことを特徴とする請求項１記載のテスト仕様作成支援装置。
- 前記生成されたテストシナリオを蓄積する手段と、
前記蓄積されたテストシナリオの中から任意のものを取り出す手段と
をさらに具備することを特徴とする請求項１記載のテスト仕様作成支援装置。 - 前記生成する手段は、
前記設計仕様を展開保持する設計仕様展開保持部と、
前記テストシナリオ生成ルールを展開保持するテストシナリオ生成ルール展開保持部と、
前記展開保持された設計仕様と前記展開保持されたテストシナリオ生成ルールとからテストシナリオを生成するテストシナリオ生成エンジンと、
前記生成されたテストシナリオを展開保持するテストシナリオ展開保持部と
を含むことを特徴とする請求項１記載のテスト仕様作成支援装置。 - 開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義するステップと、
前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成するステップと
を具備することを特徴とするテスト仕様作成方法。 - 前記定義するステップは、前記ソフトウエアの前記設計仕様からテストの観点および判断基準を抽出するステップと、前記抽出された観点および判断基準に基づいて前記設計仕様から前記テストシナリオ生成ルールを定義するステップとを含むことを特徴とする請求項７記載のテスト仕様作成方法。
- 前記生成するステップは、前記ソフトウエアの前記設計仕様から、生成すべきテストシナリオの項目および順序情報を抽出して前記生成すべきテストシナリオの初期情報を生成するステップを含むことを特徴とする請求項７記載のテスト仕様作成方法。
- 開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールをデータベース化するデータベースの構築方法であって、
前記条件部には前記ソフトウエアのテストの観点が表現され前記実行部には前記条件部が前記ソフトウエアの設計仕様に含まれていた場合に実行する判断基準が表現されている前記テストシナリオ生成ルールの前記条件部と前記実行部とをまとめて個々のテストシナリオ生成ルールごとにノードとしてくくり、
前記ノード間に、該ノードに対応するテストシナリオ生成ルールを適用する順序情報を与える
ことを特徴とするデータベースの構築方法。 - 開発すべきソフトウエアの設計仕様情報をデータベース化するデータベースの構築方法であって、
前記設計仕様に含まれる個々の動作ごとの処理仕様をそれぞれノードとしてくくり、
前記ノード間に、該ノードに対応する処理仕様の流れを示す情報を与え、
前記ノード間に、ひとつのアプリケーションを示す情報を与える
ことを特徴とするデータベースの構築方法。 - 開発すべきソフトウエアのテストシナリオをデータベース化するデータベースの構築方法であって、
前記テストシナリオに含まれる個々のテストごとにノードとしてくくり、
前記ノード間に、該ノードに対応するテストの実施順序を示す情報を与える
ことを特徴とするデータベースの構築方法。 - 開発すべきソウトウエアのテストの観点および判断基準に関するノウハウを条件部および実行部のルール形式により表現したテストシナリオ生成ルールを、前記ソフトウエアの設計仕様から定義するステップと、
前記テストシナリオ生成ルールの条件部と前記ソフトウエアの設計仕様とのマッチングをとって、前記テストシナリオ生成ルールの実行部を実行することによりテストシナリオを生成するステップと
をコンピュータに実行させるテスト仕様作成プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003007024A JP2004220330A (ja) | 2003-01-15 | 2003-01-15 | テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003007024A JP2004220330A (ja) | 2003-01-15 | 2003-01-15 | テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004220330A true JP2004220330A (ja) | 2004-08-05 |
Family
ID=32897240
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003007024A Pending JP2004220330A (ja) | 2003-01-15 | 2003-01-15 | テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004220330A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006139616A (ja) * | 2004-11-12 | 2006-06-01 | Toshiba Corp | 設計情報検証装置および設計情報検証方法 |
| JP2007066204A (ja) * | 2005-09-01 | 2007-03-15 | Hitachi Software Eng Co Ltd | ソフトウエア開発支援システム |
| JP2011204069A (ja) * | 2010-03-26 | 2011-10-13 | Nec Corp | テスト方法およびテスト仕様書テストデータ自動生成装置 |
| WO2014155941A1 (ja) * | 2013-03-29 | 2014-10-02 | 独立行政法人産業技術総合研究所 | テストデータ表示装置 |
| JP2019197288A (ja) * | 2018-05-07 | 2019-11-14 | キヤノンマーケティングジャパン株式会社 | 情報処理装置、その処理方法及びプログラム |
| JP7344521B1 (ja) | 2022-12-05 | 2023-09-14 | 株式会社Shift | プログラム、方法、情報処理装置、及びシステム |
-
2003
- 2003-01-15 JP JP2003007024A patent/JP2004220330A/ja active Pending
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006139616A (ja) * | 2004-11-12 | 2006-06-01 | Toshiba Corp | 設計情報検証装置および設計情報検証方法 |
| JP4630640B2 (ja) * | 2004-11-12 | 2011-02-09 | 株式会社東芝 | 設計情報検証装置および設計情報検証方法 |
| JP2007066204A (ja) * | 2005-09-01 | 2007-03-15 | Hitachi Software Eng Co Ltd | ソフトウエア開発支援システム |
| JP2011204069A (ja) * | 2010-03-26 | 2011-10-13 | Nec Corp | テスト方法およびテスト仕様書テストデータ自動生成装置 |
| WO2014155941A1 (ja) * | 2013-03-29 | 2014-10-02 | 独立行政法人産業技術総合研究所 | テストデータ表示装置 |
| JP2014197276A (ja) * | 2013-03-29 | 2014-10-16 | 独立行政法人産業技術総合研究所 | テストデータ表示装置 |
| JP2019197288A (ja) * | 2018-05-07 | 2019-11-14 | キヤノンマーケティングジャパン株式会社 | 情報処理装置、その処理方法及びプログラム |
| JP7256353B2 (ja) | 2018-05-07 | 2023-04-12 | キヤノンマーケティングジャパン株式会社 | 情報処理システム、その制御方法及びプログラム |
| JP7344521B1 (ja) | 2022-12-05 | 2023-09-14 | 株式会社Shift | プログラム、方法、情報処理装置、及びシステム |
| JP2024080972A (ja) * | 2022-12-05 | 2024-06-17 | 株式会社Shift | プログラム、方法、情報処理装置、及びシステム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5087133B2 (ja) | アプリケーション開発支援装置、プログラム及び記録媒体 | |
| JP5350428B2 (ja) | 自動プログラム生成装置、方法及びコンピュータプログラム | |
| CN106022007A (zh) | 面向生物组学大数据计算的云平台系统及方法 | |
| CN107741950A (zh) | 数据同步任务的处理方法、装置、处理器及服务端 | |
| JP6406890B2 (ja) | 情報処理装置 | |
| US8612440B2 (en) | Computer based method and system for generating custom dynamic templates | |
| US20060235861A1 (en) | Apparatus, system and method for supporting formation of customer-value creating scenario | |
| JP6758167B2 (ja) | データ処理装置、データ処理方法及びデータ処理プログラム | |
| JP5426938B2 (ja) | 情報処理装置、情報処理方法 | |
| CN114912897A (zh) | 工作流执行方法、工作流编排方法及电子设备 | |
| JP2004220330A (ja) | テスト仕様作成支援装置、テスト仕様作成方法、データベースの構築方法、テスト仕様作成プログラム | |
| JP6223628B1 (ja) | 情報管理装置、情報管理方法および情報管理システム | |
| JP2003141173A (ja) | データベース管理システム及びデータベース | |
| CN114968032A (zh) | 业务处理方法、装置、设备及计算机可读存储介质 | |
| JP2009069876A (ja) | ワークフローシステム、ワークフロー制御方法及びプログラム | |
| JP2007299340A (ja) | 階層型ワークフローシステム | |
| CN114115890A (zh) | 微服务开发方法及系统 | |
| JP6730235B2 (ja) | アプリケーション稼働監視装置および監視方法 | |
| JP6590753B2 (ja) | 簡易ＯｐＳ装置、制御方法および制御プログラム | |
| JP2010257327A (ja) | プロジェクト管理支援装置、プロジェクト管理支援方法、およびプロジェクト管理支援プログラム | |
| JP2019175310A (ja) | 情報処理装置、情報処理方法、およびプログラム | |
| JP6256535B2 (ja) | 情報処理装置と、その処理方法及びプログラム | |
| JP4327162B2 (ja) | ３次元形状データから形状情報を取得するシステム、その方法、及びコンピュータソフトウエアプログラム | |
| JP5007609B2 (ja) | 製造指図作成プログラム及び製造指図作成装置 | |
| JP2001273342A (ja) | 製品製造方法と製品製造支援方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060110 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080822 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080924 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081125 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090331 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090529 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090804 |