JP2006260390A - テストケース生成プログラム及び方法 - Google Patents

Abstract

【課題】 Ｗｅｂアプリケーションに関するテストケース及びテストデータを自動的に生成する。
【解決手段】 テストケース及びテストデータを生成するためにコンピュータを、画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、データ定義情報から、テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、テスト対象カラムに対する制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能させる。
【選択図】 図２

Description

本発明は、Ｗｅｂアプリケーションに必要な各種定義情報を用いて自動的にテストケースを生成可能なプログラム及び方法に関する。

ソフトウェア・プログラムの自動テストに関する従来技術は、おおよそ以下の６領域に分類することができる。１．テスト項目の自動生成技術、２．テスト手順の自動生成技術、３．テストデータの自動生成技術、４．テスト・スクリプトの自動生成技術、５．自動テスト実行技術、６．テスト結果の自動出力技術。そして、上記４．のテスト・スクリプトの自動生成技術に関連する公知文献が存在する（例えば、特許文献１参照）。

また、ＷｅｂアプリケーションをModel（ロジック）、View（プレゼンテーション）、Controller（制御）の3つの部分に分割して、それぞれを別個に作成することによって、機能分離を明確化し、各機能の独立性を確保して、プログラミングの分業を効率的に進めることができる。また、コンポーネント間の依存性を最小限に抑えることによって、他の部分が変更されたことによる影響を受けにくくすることもできる。こうすることでコンポーネントの再利用性が高まる。また、他のコンポーネントが変更されたことによるメンテナンスも最小限に抑えることができ、保守性も高まる。

このようなMVCモデルは、Webサイト上の決済サービスや、統合認証、バックエンド接続、セッション管理など、Webアプリケーション構築の開発生産性向上を目的に、広く活用されている。

具体的には、Java（登録商標）言語、COBOL言語又はC言語などによって業務ロジックを記述する部分(Model)、HTML(HyperText Markup Language)やJSP(Java（登録商標）Server Pages)によるWeb画面の構成を記述する部分(View)、Servletによる業務処理とWeb画面表示の連携制御を記述する部分(Controller)というように分割して、それぞれを別個に作成する。
特開２００２−１４８４５号公報

しかし、従来技術を用いてＷｅｂアプリケーションに関するテストケースを生成するためには、ＭＶＣモデルにおいて一般的とは言えない定義情報（アプリケーションを開発する過程では不要な画面遷移配列情報）をテストケース生成のために別途作成する必要がある。

また、ＨＴＭＬなどによって記述される画面構成情報は、以下の理由によりテストケースを作成するための「画面定義情報」を独自に作成することは困難である。

理由１：ＨＴＭＬの表現力は非常に高く、また多様な作成ツールが存在するため、独自の画面定義情報からＨＴＭＬファイルを生成するという方法は非効率である。

理由２：ＨＴＭＬファイルの記述内容の変更はデザイナーが行うことが多く、デザイナーが独自の画面定義情報を作成することは非現実的である。

さらに、テストケースの絞り込みが自動では難しく、ケース数が非常に多くなってしまうという問題もある。

そこで、本発明は、Ｗｅｂアプリケーション開発において一般的に作成される画面遷移定義情報、データ定義情報、及びＨＴＭＬ、ＪＳＰなどで記述された画面構成情報のみを利用してテストケースを生成可能なプログラム及び方法を提供することを目的とする。

本発明の第１の特徴は、テストケース及びテストデータを生成するためにコンピュータを、画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、データ定義情報から、テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、テスト対象カラムに対する制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能させることにある。

画面遷移定義情報及びデータ定義情報はＸＭＬ(eXtensible Markup Language)によって記述され、画面構成情報はＨＴＭＬのみによって記述され又はＨＴＭＬ記述中にJava（登録商標）コードが埋め込まれていることが好ましい。

本発明の第１の特徴によれば、Ｗｅｂアプリケーション開発において一般的に作成される画面遷移定義情報、データ定義情報、及びＨＴＭＬ、ＪＳＰなどで記述された画面構成情報のみを利用してテストケースを生成することができる。

画面構成情報は頻繁に変更される。また、画面構成情報は、Ｗｅｂアプリケーション全体の開発の担当者とは別のデザイナーが行うことが一般的であるが、デザイナーは一般的に画面構成情報の他にテストケース生成用の定義情報を作成することは不得意である。よって、画面構成情報の記述内容の変更を自動的にテストケースに取り入れ可能であることの効果は大きい。

また、実行可能な設計情報を元にテストケースを生成するので、ケース数を抑えることができる。

以下に図面に基づいて、本発明を実施するための最良の形態を説明する。なお、以下の説明は、単なる例示に過ぎず、本発明の技術的範囲は以下の説明に限定されるものではない。

図１は、実施例１におけるWebアプリケーションサーバ２０の概略構成を示す。図１に示すように、サーバ２０はクライアント１０のWebブラウザからリクエストを受け取り、レスポンスを返す。具体的には、サーバ２０は、画面遷移定義XMLファイル２１ａ、データ定義XMLファイル２１ｂと、これら定義ファイルを読み込んで動作するコントローラ２２と、コントローラから処理要求を受け取り、所定のデータなどを返すJava（登録商標）BL（ビジネスロジックを構築するJava（登録商標）アプリケーション）２３と、コントローラからページ表示要求を受け取り、ページ表示をレスポンスとしてクライアントへ返すJSP２４とを記憶部（図示せず）に記憶する。

図２は、実施例１におけるテストケース生成装置の構成を示すブロック図である。図２に示すように、テストケース生成装置３０は、中央処理装置（ＣＰＵ）３１と、メインメモリ３２と、入力装置３３と、ファイル装置３４と、出力装置３６とを備え、それら各装置がバス３７を介してデータをやり取りすることができる。

中央処理装置（ＣＰＵ）３１は、テストケース及びテストデータを生成するために、画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、データ定義情報から、テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、テスト対象カラムに対する制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能する。

メインメモリ３２は、テストケース生成プログラム４０のワークエリアとして使用される。出力装置３６には、液晶ディスプレイ、ＣＲＴディスプレイ等が含まれる。生成されたテストケースの内容などが出力装置３６に出力される。

入力装置３３にはキーボードや、ＦＤドライブやネットワークインターフェースカードなどが含まれる。この入力装置を用いて各種ファイルを作成又は読み込む。

ファイル装置３４には、ハードディスクドライブが含まれる。入力装置３３を用いて作成又は読み込まれた画面遷移定義XMLファイル２１ａ、データ定義ＸＭＬファイル２１ｂ、Java（登録商標）BLソースファイル２３、JSPソースファイル２４等がファイル装置３４ａに格納され、テストケース生成プログラム４０を構成する対象画面取得モジュール４２、画面内カラム取得モジュール４３、カラムチェック情報取得モジュール４４、テストケースデータ生成モジュール４５、JSP情報取得モジュール４６等はファイル装置３４ｂに格納されるものとする。

対象画面取得モジュール４２は、画面遷移定義XMLファイル２１ａを読み込み、テストケース生成の対象となる画面を取得する。画面遷移定義XMLファイル２１ａは、あるページで、あるアクションが要求されたら、どのJava（登録商標）BLを実行し、その返値に応じてどのページへ遷移するか等を定義する。

JSPソースファイル２４は、JSPパーサによって構文解析される。構文解析方法は、Java（登録商標）言語の構造定義を例えば大きく３つの部分に分けて行う。１つ目の部分は、プログラム、ファイル、ファイル中の関数宣言や大域変数宣言等の宣言文により表現されるプログラムの全体構造である。２つ目の部分は、制御文、ブロック又は式等のプログラムの基本構造である。３つ目の部分は、変数や関数の名前や型、定数、演算子及びそれらの宣言等のプログラムの基本要素である。

構文解析結果は、XMLファイルとしてJSPリポジトリ（不図示）に格納される。そして、JSPリポジトリから低レベルなAPIを介してJSP情報が取得され、取得されたJSP情報は画面内カラム取得モジュール４３へ出力される。

JSPパーサ（解析器）、JSPリポジトリ用の低レベルAPIとしては名古屋大学大学院情報科学研究科（阿草研究室）開発のWapidが使用可能である。

画面内カラム取得モジュール４３は、テストケース生成対象画面からテストケース生成対象カラムを取得する。

カラムチェック情報取得モジュール４４は、データ定義XMLファイル２１ｂを読み込み、テストケース生成対象カラムのチェック情報を取得する。データ定義XMLファイル２１ｂは、カラムID、カラムIDに対応するカラム日本語名、データチェック情報等を定義する。

テストケースデータ生成モジュール４５は、テストケース生成対象カラムに対する制約とテストケーステンプレート２５とをマッチングさせ、テストケースとテストデータとを生成する。

図３は、実施例１におけるテストケース生成処理の流れを示すフローチャートである。図３に示すように、ステップＳ１１で、画面遷移定義XMLファイル２１ａを読み込み、
ステップＳ１２で、テストケース生成の対象となる画面を取得し、
ステップＳ２１で、JSPソースファイルを読み込み、
ステップＳ２２で、JSPソースファイルの構文を解析し、
ステップＳ２３で、JSP構文解析結果をJSPリポジトリに登録し、
ステップＳ４１で、JSPリポジトリからテストケース生成の対象となるカラムを取得し、
ステップＳ４２で、データ定義XMLファイル２１ｂを読み込み、
ステップＳ４３で、カラムチェック情報を取得し、
ステップＳ４４で、テストケーステンプレートを読み込み、
ステップＳ４５で、テストケース及びテストデータを生成する。

図４は画面遷移定義ＸＭＬファイルの一例を、図５はＪＳＰソースファイルの一例を、図６はデータ定義ＸＭＬファイルの一例を、図７はテストケーステンプレートの一例を、図８及び図９は生成されたテストケースの一例をそれぞれ示す。これら具体的なファイルに基づいて実施例をより具体的に説明する。

図４に示すように、画面遷移定義ＸＭＬファイル２１ａには遷移先として、９行目にquery.jspが、１８行目にSysError.jspが、２９行目にsearchOk.jspなどが記載されている。

ステップＳ１１で、対象画面取得モジュール４２はこれらquery.jsp等を遷移先として抽出する。

図５に示すように、ＪＳＰソースファイル２４にはデータが入力されるカラムとして、１５行目に”kaiin_no”が、２２行目に”kounyuu_bu”などが記載されている。

ステップＳ４１で、画面内カラム取得モジュール４３はこれら”kaiin_no”等をチェックの対象となるカラム（データ項目）として抽出する。

図６に示すように、データ定義ＸＭＬファイル２１ｂにはカラムに対する制約が記載されている。具体的には、３〜２１行目はＩＤが”kaiin_no”であるカラムに関し、そのうちの６行目はタイプがStringであること、９行目の
<chkTyp>IS_NOT_NULL</chkTyp>
は必須データ項目である（Nullが許容されない）こと、１３行目の<chkTyp>IS_ALNUM</chkTyp>
は入力されるデータが全て数値でなければならないこと、１７〜１８行目の
<chkTyp>IS_IN_MAX_SIZE</chkTyp>
<opt>8</opt>
は入力されるデータが最大８桁であることを示す。また、２２〜３５行目はＩＤが”kounyuu_bi”であるカラムに関し、そのうちの２５行目はタイプがStringであること、２８行目は必須データ項目である（Nullが許容されない）こと、３２行目の
<chkTyp>IS_DATE</chkTyp>
はチェックタイプが日付タイプであることを示す。

ステップＳ４３で、カラムチェック情報取得モジュール４４は、このようなデータ型、必須データ項目かなどの各カラムの制約を抽出する。

図７に示すように、テストケーステンプレート２５には、５〜８行目にテスト対象となるカラムのチェックタイプが、１２〜１５行目にはテストケース生成クラスの指定が記載されている。図６の３２行目に示したように、”kounyuu_bi”カラムのチェックタイプは”IS_DATE”であり、図７の７行目に示したようにチェックタイプが”IS_DATE”であるカラムは、図７の１４行目に示したテストケース生成クラスによってテストケースを生成される。つまり、ステップＳ４５で、”kounyuu_bi”カラムについて図７の１４行目に示したテストケース生成クラスによってテストケース及びテストデータが生成される。

図８に示すように、生成された第１のテストケースは、３行目に記述されているように日付正常系チェックという名前であって、１０行目に記述されているようにテスト対象カラムが”kounyuu_bi”であって、１３行目に記述されているようにテストデータが”20040430”である。

また、図９に示すように、生成された第２のテストケースは、３行目に記述されているように日付異常系チェックという名前であって、９行目に記述されているようにテスト対象カラムが”kounyuu_bi”であって、１２行目に記述されているようにテストデータが”20040431”であって、１５〜２２行目に記述されているようにテスト実行スクリプトが
P:\home\webapps\shopping\test\script\SHOPPING00003.rsp
又は
P:\home\webapps\shopping\test\script\SHOPPING00004.rsp
であって、２８〜２９行目に記述されているようにテスト結果が表示した画面イメージがビットマップファイルとして出力される。

前記の如く、実施例１によれば、Ｗｅｂアプリケーション開発で一般的に作成される画面遷移定義情報（ＸＭＬ）、データ定義情報（ＸＭＬ）、画面構成情報（ＨＴＭＬ、ＪＳＰ）のみを利用してテストケースを生成することができる。

実施例１におけるWebアプリケーションサーバ２０の概略構成を示す図である。 実施例１におけるテストケース生成装置の構成を示すブロック図である。 実施例１におけるテストケース生成処理の流れを示すフローチャートである。 実施例１における画面遷移定義ＸＭＬファイルの一例を示す図である。 実施例１におけるＪＳＰソースファイルの一例を示す図である。 実施例１におけるデータ定義ＸＭＬファイルの一例を示す図である。 実施例１におけるテストケーステンプレートの一例を示す図である。 実施例１において生成された第１のテストケースの一例を示す図である。 実施例１において生成された第２のテストケースの一例を示す図である。

符号の説明

２１ａ…画面遷移定義ＸＭＬファイル、 ２１ｂ…データ定義ＸＭＬファイル、
２３…Java（登録商標）BLソースファイル、 ２４…JSPソースファイル、
２５…テストケーステンプレート、
３０…テストケース生成装置、 ３１…中央処理装置、
３２…メインメモリ、 ３３…入力装置、
３４…ファイル装置、 ３６…出力装置、
３７…バス、 ４０…テストケース生成プログラム、
４２…対象画面取得モジュール、 ４３…画面内カラム取得モジュール、
４４…カラムチェック情報取得モジュール、
４５…テストケースデータ生成モジュール、
４６…ＪＳＰ情報取得モジュール

Claims (4)

1. テストケース及びテストデータを生成するためにコンピュータを、
   画面遷移定義情報からテストケース生成の対象画面を取得する対象画面取得手段、
   前記対象画面を構成する画面構成情報からテスト対象カラムを取得する画面内カラム取得手段、
   データ定義情報から、前記テスト対象カラムに対する制約を取得するカラムチェック情報取得手段、
   前記テスト対象カラムに対する前記制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成するテストケースデータ生成手段、として機能させることを特徴とするテストケース生成プログラム。
2. 前記画面遷移定義情報及び前記データ定義情報がＸＭＬファイルであって、前記画面構成情報がＪＳＰファイル又はＨＴＭＬファイルである請求項１記載のテストケース生成プログラム。
3. テストケース及びテストデータを生成するためにコンピュータが、
   画面遷移定義情報からテストケース生成の対象画面を取得する手順、
   前記対象画面を構成する画面構成情報からテスト対象カラムを取得する手順、
   データ定義情報から、前記テスト対象カラムに対する制約を取得する手順、
   前記テスト対象カラムに対する前記制約とテストケーステンプレートをマッチングさせ、テストケースとテストデータを生成する手順を実行することを特徴とするテストケース生成方法。
4. 前記画面遷移定義情報及び前記データ定義情報がＸＭＬファイルであって、前記画面構成情報がＪＳＰファイル又はＨＴＭＬファイルである請求項３記載のテストケース生成方法。
   
   

Images