JP7311740B2 - 情報処理システム、その制御方法、及びプログラム - Google Patents

Description

本発明は、アプリケーションを構築するための情報処理システム、その制御方法、及びプログラムに関する。

従来、設定された定義に基づきアプリケーションを構築（生成）するツールやサービスが存在する。このようなツールやサービスを利用して構築したアプリケーションであっても、定義の設定ミス等により予想外の動作をすることがあるため、テスト工程を省略することはできない。

特許文献１には、アプリケーションの操作に応じて、当該アプリケーションをテストするために当該操作を再現するテストプログラムを生成する仕組みが開示されている。

特開２０１０－２３７８４１号公報

しかし、特許文献１のテストは、構築済のアプリケーションが予想通りに動作するかのテストであって、アプリケーションを構築するために設定した定義情報が予想通りに設定されているかのテストではない。

そのため、特許文献１の仕組みを用いたとしても、アプリケーション構築するツールやサービスにおいて、アプリケーションを構築するための定義情報に係るテストケースを容易に生成することができないという課題がある。

そこで、本発明の目的は、所望するテストケースを容易に生成する仕組みを提供することである。

アプリケーションを構築するための定義情報を取得する第１の取得手段と、
前記定義情報により構築された前記アプリケーションのテストケースを生成するために、該アプリケーションを実行し、該アプリケーションに対して行われた操作情報を取得する第２の取得手段と、
前記定義情報により設定されるテストケースで実行する操作情報に係る命令の選択を受け付ける選択受付手段と、
前記第２の取得手段により取得した操作情報のうち、前記選択受付手段により選択を受け付けた命令に対応する操作情報に係るテストを含むテストケースを生成するように制御する制御手段と
を備えることを特徴とする。

本発明によれば、所望するテストケースを容易に生成する仕組みを提供することができる。

本発明に係るシステムの構成図の一例である。 情報処理装置、アプリケーションサーバ、データベースサーバ、アプリケーションクライアントとして適用可能な各ハードウェア構成の一例を示すブロック図である。 ソフトウェア構成を示すブロック図の一例である。 本発明に係るシステムの構成図である。 アプリケーション生成のフローチャートの一例を示す図である。 アプリケーションの入出力定義画面及びアプリケーションの実行画面の一例を示す図である。 テストケース定義生成のフローチャートの一例を示す図である。 テスト実行のフローチャートの一例を示す図である。 テスト実行のフローチャートの一例を示す図である。 テスト実行のフローチャートの一例を示す図である。 テストケース作成メニューの一例を示す図である。 テストケース手順入力画面の一例を示す図である。 テストケース作成画面の一例を示す図である。 テスト実行画面の一例を示す図である。 テスト結果画面の一例を示す図である。 テストケース定義情報の一例を示す図である。 アプリケーションに対して行われた操作内容に基づきテストケースを生成する画面の一例を示す図である。 プロキシサーバが受信するリクエスト情報の一例を示す図である。 アプリケーションに対して行われた操作内容に基づき生成したテストケース定義情報の一例を示す図である。 第２の実施形態のソフトウェア構成を示すブロック図の一例である。 第２の実施形態に係るシステムの構成図である。 第２の実施形態のテストケース定義生成のフローチャートの一例を示す図である。 第２の実施形態のテストケース生成に係る設定をする画面の一例を示す図である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。
〔第１の実施形態〕
図１は、本発明に係るシステムの構成図の一例である。

情報処理装置１０１は、開発者の操作に従って画面レイアウト及びデータベース検索指示などを定義する。情報処理装置１０１は、アプリケーションのプログラム生成を行う。

なお、本実施形態においては、情報処理装置１０１で生成するアプリケーションはＷｅｂアプリケーションとしたが、これに限定するものではなく、携帯電話・スマートフォン・タブレットなどの情報処理装置で動作するアプリケーションや組込みソフトウェアなど、Ｗｅｂ技術による通信を利用するアプリケーションでなくてもよい。

また、本実施形態においては、情報処理装置１０１はアプリケーションのプログラムを生成するとしたが、この方法に限定するものではなく、プログラムを生成することなく、アプリケーションサーバ１０２やクラウド環境等でアプリケーションが動作する様にデータやファイル等を生成することにより、アプリケーション（の動作環境）を構築する等であってもよい。

アプリケーションサーバ１０２は、情報処理装置１０１で生成され配置されたアプリケーションを実行する。また、アプリケーションサーバ１０２は、データベースサーバ１０３に接続し、データベースのデータを操作することができる。

データベースサーバ１０３は、生成されたアプリケーションが利用するデータベースである。なお、開発時にも動作確認などのために利用してもよい。また、データベースサーバ１０３は、情報処理装置１０１や、アプリケーションサーバ１０２と同一の装置で構成されていてもよいし、ＬＡＮなどのネットワーク１０５内に配置されてもよい。

アプリケーションクライアント１０４は、アプリケーションサーバ１０２と協調して情報処理装置１０１で開発したアプリケーションプログラムを動作させる、エンドユーザの操作端末である。この、アプリケーションクライアント１０４は、携帯端末などの情報処理装置であってもよい。

クラウド環境１０６は、動的にスケーラブルかつ仮想化されたリソースを供給することが可能な環境である。

クラウド環境１０６内の仮想アプリケーションサーバ１０７は、情報処理装置１０１で生成され配置されたアプリケーションを実行する。また、仮想アプリケーションサーバ１０７は、仮想データベースサーバ１０８に接続し、データベースのデータを操作することができる。

クラウド環境１０６内の仮想データベースサーバ１０８は、生成されたアプリケーションが利用するデータベースである。なお、開発時にも動作確認などのために利用してもよい。

なお、クラウド環境１０６は動的にスケーラブルかつ仮想化されたリソースを供給することが可能な環境であるとしたが、本実施形態においては、この特徴を備えている必要はなく、クラウド環境１０６が仮想アプリケーションサーバ１０７及び仮想データベースサーバ１０８の動作を提供するのであれば、動的にスケーラブルでなくても、仮想化されたリソースを供給できなくてもよい。

図２は、本発明に係わる情報処理装置１０１、アプリケーションサーバ１０２、データベースサーバ１０３、アプリケーションクライアント１０４として適用可能な各ハードウェア構成の一例を示すブロック図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバ、クライアント、装置など情報処理装置の後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、情報処理装置では、キーボード、マウス等のポインティングデバイス、タッチパネルが挙げられる。

なお、入力部２０９がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。

また、タッチパネルは、マルチタッチスクリーン等の、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。また、プロジェクタであってもよいこととする。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。外部メモリ２１１には、各サーバ、クライアント、装置等の各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォント展開（ラスタライズ）処理を実行することにより、出力部２１０上での表示を可能としている。また、ＣＰＵ２０１は、出力部２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

図３は、本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。

情報処理装置１０１は、以下の機能部を備える。

定義情報取得部３０１は、アプリケーションを構築するための定義情報を取得する機能部である。
アプリケーション構築部３０２は、定義情報取得部３０１により取得された定義情報に基づき、アプリケーションを構築する機能部である。

アプリケーション実行部３０３は、アプリケーション構築部３０２により構築されたアプリケーションを実行する機能部である。

操作情報取得部３０４は、アプリケーション実行部３０３によりアプリケーションに対して行われた操作情報を取得する機能部である。

操作内容取得部３０５は、操作情報取得部３０４により取得された操作情報から、アプリケーションを構築するために用いられた定義情報及び当該定義情報に対する操作内容を取得する機能部である。

テストケース生成部３０６は、アプリケーションに係るテストをするテストケースであって、操作内容取得部３０５により取得された定義情報に対して、操作内容取得部３０５により取得された当該定義情報に対する操作内容を実行するテストケースを生成する機能部である。

テスト実行部３０７は、テストケース生成部３０６により生成されたテストケースに基づき、テストを実行する機能部である。

以上で、図３の説明を終了する。

図４は、情報処理装置１０１、アプリケーションサーバ１０２及びアプリケーションクライアント１０４の構成図である。

情報処理装置１０１は、リポジトリ定義部４０１及びアプリケーション生成部４１０を備える。

情報処理装置１０１は、アプリケーションを構築するために開発者により設定されたリポジトリ定義部４０１の各定義情報を用いて、アプリケーション生成部４１０によりアプリケーションを生成する。

リポジトリ定義部４０１には、アプリケーション定義４０２、入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５、データベース定義４０６が記憶されている。これら４０２～４０６の定義は、アプリケーション構築ツールを介して、開発者によって入力設定または配置される。

入出力定義４０３は、アプリケーション画面に配置される各種項目のレイアウトの定義情報を保持する。入出力定義４０３は、入力項目定義情報及び出力項目定義情報を含む。入力項目定義情報は、生成されたアプリケーションの画面を介して当該アプリケーションのエンドユーザが入力する入力項目を定義した情報である。出力項目定義情報は、生成されたアプリケーションの画面に出力する出力項目を定義した情報である。以降、「入力項目定義情報」及び「出力項目定義情報」をまとめて「入出力項目定義情報」と呼ぶ。

なお、本実施形態においては、「入力項目定義情報は、生成されたアプリケーションの画面を介して当該アプリケーションのエンドユーザが入力する入力項目を定義した情報」「出力項目定義情報は、生成されたアプリケーションの画面に出力する出力項目を定義した情報」としたが、これらに限定するものではなく、例えば、画面を有さないバッチやＷｅｂサービス等のように、「入力項目定義情報は、生成されたアプリケーションに入力される入力項目を定義した情報」「出力項目定義情報は、生成されたアプリケーションが出力する出力項目を定義した情報」であってもよい。

データモデル定義４０４は、データベースのテーブルの項目の定義情報を保持する。入出力定義４０３の各項目には、データモデル定義４０４の項目を対応づけることができる。

ビジネスプロセス定義４０５は、アプリケーションにおけるデータを処理するためのロジックの定義情報を保持する。

データベース定義４０６は、アプリケーションが接続するデータベースに係る情報（データベースサーバ１０３のＩＰアドレス、接続ユーザ、接続パスワード等）を定義する。

アプリケーション生成部４１０は、アプリケーション生成用のリポジトリ定義解析部４１１を用いてリポジトリ定義部４０１に記憶されている各定義を解析し、アプリケーションコード生成部４１２及びソースコードコンパイル部４１３を介し、コンパイル済Ｊａｖａ（登録商標）コード４４１及びＨＴＭＬ／ＪＳＰ／ＪａｖａＳｃｒｉｐｔ（登録商標）４４２を含むアプリケーションを生成する。すなわち、アプリケーション生成部４１０は、設定された定義を用いて、アプリケーションとして用いられるプログラムを生成する手段の一例である。

リポジトリ定義エディタ部４２０は、リポジトリ定義参照部４２１によってリポジトリ定義部４０１を解析し、テストケース定義４０７の場合は、テストケース定義エディタ部４６０を用いて、それ以外の定義の時はそれぞれに対応したその他定義エディタ部４２２を用いてリポジトリ定義を作成、変更又は参照する。

テスト実行部４３０は、テストケース定義受信部４３１によってテストケース定義４０７を取得し、テストケース定義解釈部４３３を用いてその内容を解析する。テスト実行部（インタープリタ）４３４は、テストケース定義解釈部４３３を用いて、アプリケーションコードアクセス部４３６から、アプリケーションコードをテスト実行する。

テスト実行部（インタープリタ）４３４は、テストケース定義解釈部４３３を用いて解釈した内容からテスト実行準備部を用いてテストの事前処理を行い、アプリケーションコードアクセス部４３６を用いてアプリケーションコードをテスト実行する。

テストがすべて完了すると、テスト実行部（インタープリタ）４３５はテスト終了処理部４３７を用いてテスト終了処理を行う。

テスト結果取得部４３５を用いて、テスト実行の結果を取得し、テスト結果表示部４３８に表示する。

プロキシサーバ部４８０は、リクエスト受信部４８３を介し、アプリケーションの操作を行うアプリケーションクライアント１０４からのリクエスト情報を仲介するようにして受信する。受信したリクエスト情報は、記録管理部４８４で外部メモリに記録し、アプリケーションサーバ１０２に転送する。

プロキシサーバ部４８０は、レスポンス受信部４８１を介し、アプリケーション４４６から送信されるレスポンス情報を仲介するようにして受信する。受信したレスポンス情報は、記録管理部４８４で外部メモリに記録し、アプリケーションクライアント１０４に転送する。

プロキシサーバ部４８０は、データ解析・変換部４８２を介し、リクエスト情報及びレスポンス情報を解析し、テストケース定義データ登録部４７０へ引き渡す。

プロキシサーバ部４８０は、起動・停止処理部４８５を介し、プロキシサーバ部４８０を起動・停止する。

テストケース定義エディタ部４６０は、リポジトリ参照部４６１、対象画面入力部４６２、値入力部４６３、アクション入力部４６４、対象項目入力部４６５及び期待値入力部４６６を備え、各入力部から入力された値を保存し、テストケース定義４０７を作成する。

テストケース定義データ登録部４７０は、データ受信部４７３を介し、プロキシサーバ部４８０から解析されたリクエスト情報又はレスポンス情報を受信する。

テストケース定義データ登録部４７０は、テストケース定義生成部４７２を介し、解析されたリクエスト情報又はレスポンス情報に基づき、テストケース定義データ４７１を生成する。

テストケース定義データ登録部４７０は、テストケース定義エディタ部４６０を介し、テストケース定義データ４７１をテストケース定義４０７として保存する。

なお、本実施形態においては、プロキシサーバ部４８０及びテストケース定義データ登録部４７０は、情報処理装置１０１が備えるとしたが、この構成に限定するものではなく、アプリケーションサーバ１０２やアプリケーションクライアント１０４等が備え、アプリケーションサーバ１０２やアプリケーションクライアント１０４が情報処理装置１０１に対してテストケース定義データ４７１をテストケース定義４０７として記憶させる指示を送信するとしてもよい。

以上で、図４の説明を終了する。

図５は、アプリケーション生成のフローチャートの一例を示す図である。

情報処理装置１０１は、ディレクトリ構造を用いて、リポジトリ定義部４０１の各定義をファイルとして管理する。なお、本実施形態においては、ディレクトリ構造を用いて、リポジトリ定義部４０１の各定義をファイルとして管理するとしたが、これに限定するものではなく、例えば、データベースを用いてリポジトリ定義部４０１の各定義を管理してもよいし、クラウドなどネットワーク上の記憶装置を用いて管理する等としてもよい。

アプリケーション生成のフローチャートについて説明する。

ステップＳ５０１において、情報処理装置１０１は、アプリケーション定義４０２の設定を受け付ける。具体的には、アプリケーション構築ツールの画面を介して、アプリケーション開発者から入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５及びデータベース定義４０６の設定を受け付ける。

ステップＳ５０１にて、受け付けたアプリケーション定義４０２、入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５及びデータベース定義４０６の設定は、リポジトリ定義部４０１にＸＭＬファイル形式で記憶する。

ステップＳ５０２において、情報処理装置１０１は、アプリケーション生成の指示を受け付ける。

ステップＳ５０３において、情報処理装置１０１は、リポジトリ定義部４０１からアプリケーション定義４０２を取得する。リポジトリ定義解析部４１１は、読み込んだ定義を解析したうえでＲＯＭ２０３に記憶しておき、解析された定義は各生成部から適宜参照される。

ステップＳ５０４において、情報処理装置１０１は、リポジトリ定義部４０１からデータモデル定義４０４を取得する。

ステップＳ５０５において、情報処理装置１０１は、リポジトリ定義部４０１から入出力定義４０３を取得する。

ステップＳ５０６において、情報処理装置１０１は、リポジトリ定義部４０１からビジネスプロセス定義４０５を取得する。

ステップＳ５０７において、情報処理装置１０１は、リポジトリ定義部４０１からデータベース定義４０６を取得する。すなわち、ステップＳ５０１～Ｓ５０７は、アプリケーションを構築するための定義情報を取得する処理の一例を示すステップである。

ステップＳ５０８において、情報処理装置１０１は、アプリケーション生成部４１０を用いて、Ｗｅｂアプリケーションに用いるプログラムを生成する。すなわち、ステップＳ５０８は、アプリケーションのプログラムを生成する処理の一例を示すステップである。また、ステップＳ５０８は、アプリケーションを構築する処理の一例を示すステップである。

ステップＳ５０９において、情報処理装置１０１は、テストケース定義を生成する（詳細は、図７の説明にて後述する）。すなわち、ステップＳ５０９は、取得された定義情報を用いて、テストケースを生成する処理の一例を示すステップである。また、ステップＳ５０９は、受け付けた定義に基づき、テストケースを生成する処理の一例を示すステップである。

ステップＳ５１０において、情報処理装置１０１は、ステップＳ５０９にて生成したテストケース定義に用いてテストを実行する（詳細は、図８の説明にて後述する）。すなわち、ステップＳ５１０は、定義情報を用いて生成されたテストケースに基づき、アプリケーションに係るテストを実行する処理の一例を示すステップである。また、ステップＳ５１０は、定義情報を用いて生成されたテストケースに基づき、定義情報が正しく定義されているか否かテストを実行する処理の一例を示すステップである。

この段階ではアプリケーションをアプリケーションサーバ１０２に配置（デプロイ）していないため、以上により、アプリケーションサーバ１０２を用意することなく、テストを実行することができる。

また、以上により、アプリケーションアーカイブファイルの生成、アプリケーションサーバ１０２への転送、デプロイをすることなく、テストを実行することができるため、テストにかかる時間を削減することができ、開発とテストをシームレスに何度も繰り返すことができる。

また、以上により、情報処理装置１０１だけでアプリケーションサーバ１０２にて動作するアプリケーションのテストを実行することができるため、複数人の開発者が同時に並行してテストを行うことができる。

ステップＳ５１１において、情報処理装置１０１は、ステップＳ５１０にて実行したテストにおける失敗したテストケースの有無を判定し、有る場合は本フローチャートを終了し、無い場合はステップＳ５１２に進む。すなわち、ステップＳ５１１は、テストの結果に従って、アプリケーションの構築をする／しないを制御する処理の一例を示すステップである。

ステップＳ５１２において、情報処理装置１０１は、ステップＳ５０８にて生成したプログラムをアプリケーションサーバ１０２に配置（デプロイ）する。

これにより、失敗テストが無い状態のアプリケーションをサーバに構築する仕組みを提供することができる。よって、テストに時間がかかってしまう場合、夜間にテストを実行させ、テストが成功した場合は、続けてアプリケーションサーバ１０２にデプロイさせておくことができるため、アプリケーション管理者や運用者の手間を軽減することができる。

また、失敗テストが有る状態のアプリケーションはサーバに構築することが無くなるため、不具合を含んだアプリケーションをリリースすることがなくなり、アプリケーションが不整合なデータを出力することもなくなるため、結果として、信頼性の高いアプリケーションを運用することができ、エンドユーザの満足度も向上させることができる。

以上で、図５の説明を終了する。

以上により、アプリケーションプログラム生成、テスト実行、デプロイ等の処理を１つの指示で行うことができる。よって、アプリケーション構築ツールにおいて、テストを効率的に行う仕組みを提供することができる。

図７は、テストケース定義生成のフローチャートの一例を示す図である。

ステップＳ７０１において、情報処理装置１０１は、ユーザからのテストケース定義生成の指示を受け付ける。具体的には、新規テストケース作成メニュー１１０１（図１１）の押下を受け付ける。

ステップＳ７０２において、情報処理装置１０１は、外部メモリ２１１にアプリケーション定義４０２が作成済か否かを判定する。作成済の場合はステップＳ７０３に進み、未作成の場合は本フローチャートを終了する。

ステップＳ７０３において、情報処理装置１０１は、新規テストケース作成ダイアログ１１０２（図１１）を表示し、新規のテストケースの生成に必要な「コード名」「名前」「対象アプリケーション１１０３」の入力を受け付け、受け付けた情報に基づき、外部メモリ２１１にテストケース定義４０７を新規に作成する。

ステップＳ７０４において、情報処理装置１０１は、ステップＳ７０３にて作成されたテストケースのテスト手順を入力するためのテスト手順入力画面１２０１（図１２）表示する。この時点では、テストケースにテスト手順が登録されていない状態であるため、テスト手順入力画面１２０１の「テスト手順」タブを選択した場合、テスト手順を設定するエディタ部には何も表示されていない。

ステップＳ７０５において、情報処理装置１０１は、ステップＳ７０３にて入力を受け付けた「対象アプリケーション１１０３」に属す入出力定義４０３を外部メモリ２１１から取得する。すなわち、ステップＳ７０５は、アプリケーションを構築するための定義情報を取得する処理の一例を示すステップである。

ステップＳ７０６において、情報処理装置１０１は、プロキシサーバ設定情報１７０１（図１７）の入力を受け付ける。具体的には、プロキシサーバのＵＲＬ及びポート番号の入力を受け付ける。

ステップＳ７０７において、情報処理装置１０１は、プロキシサーバの動作開始ボタン１７０２（図１７）の押下を受け付ける。

ステップＳ７０８において、情報処理装置１０１は、リクエスト情報・レスポンス情報の記録開始ボタン１７０４（図１７）の押下を受け付け、リクエスト情報・レスポンス情報の外部メモリ２１１への記録を開始する。

ステップＳ７０９において、情報処理装置１０１は、記録停止ボタン１７０５（図１７）の押下を受け付けるまで、ステップＳ７１０～Ｓ７１７を繰り返す。

ステップＳ７１０において、情報処理装置１０１は、リクエスト受信部４８３を介し、アプリケーションの操作を行うアプリケーションクライアント１０４からのリクエスト情報を仲介するようにして受信する。ここでは、リクエスト情報１８１０（図１８）又はリクエスト情報１８２０（図１８）のようなリクエストを受信したとする。

すなわち、ステップＳ７１０は、実行されるテストに用いる情報を受け付ける処理の一例を示すステップである。また、ステップＳ７１０は、定義情報に含まれる項目に対して代入する値を受け付ける処理の一例を示すステップである。また、ステップＳ７１０は、アプリケーションに対して行われた操作情報を取得する処理の一例を示すステップである。

ステップＳ７１１において、情報処理装置１０１は、データ解析・変換部４８２を介し、ステップＳ７１０にて受信したリクエスト情報を解析・変換する。

例えば、画面表示要求の操作（例：画面遷移するためのリンクのクリック操作等）を受け付けた場合は、リクエスト情報１８１０（図１８）のようなリクエストが受信されるため、１８１１内の“＿ｌｉｎｋ．ｄｏ？ｉ＝”の後の文字列から、「ｉｏ００１」という画面への遷移要求によって送信されたリクエストであることがわかる。つまり、これにより、どの画面を表示するために送信されたリクエストかを解析することができる。

また、画面内のアクション操作（例：更新ボタンのクリック操作等）を受け付けた場合は、リクエスト情報１８２０（図１８）のようなリクエストが受信されるため、リクエスト情報１８２０（図１８）のＰＯＳＴ情報１８２１内の“．ｄｏ？＿Ａｃｔｉｏｎ＿＝”の前後の文字列から、「ｉｏ００１」という画面の「ｕｐｄａｔｅＡｃｔｉｏｎ」というアクションによって送信されたリクエストであることがわかる。また、１８２２（図１８）から、アクション時にアプリケーションクライアント１０４から送信されたパラメータ及びそれらの値（引数）も知ることができる。つまり、これらによって、どの画面からどのアクションによりどのような引数を伴って送信されたリクエストかを解析することができる。

なお、本実施形態においては、「引数」の例として「入出力項目の値」を挙げたが、「入出力項目の値」に限定するものではなく、「引数」は、例えば、画面の入出力に係る位置、色、大きさ又は内容等に係る情報であってもよい。また、表示、認証、検索、追加、更新若しくは削除等の処理に対して与える情報、又は、カメラ等の周辺機器に対して送信する情報等、テスト実行のために用いる情報であれば、その他の情報であってもよい。

すなわち、ステップＳ７１１は、操作情報から、アプリケーションを構築するために用いられた定義情報及び当該定義情報に対する操作内容を取得する処理の一例を示すステップである。

ステップＳ７１２において、情報処理装置１０１は、遷移先の入出力定義（画面定義）がこれまでの入出力定義と異なる場合（アクション後に異なる入出力定義へ遷移する場合も含む）は）保存先テストケース定義を変更すべくステップＳ７１３に進み、同じ場合はステップＳ７１７へ進む。

ステップＳ７１３において、情報処理装置１０１は、保存先テストケース定義を検索する。例えば、保存先テストケース定義の名称は、入出力定義ファイル名＋日付とする。

ステップＳ７１４において、情報処理装置１０１は、ステップＳ７１３で検索したテストケース定義ファイルが存在しない場合はステップＳ７１５へ進む、存在する場合はステップＳ７１６へ進む。具体的には、テストケース定義ファイルが存在しない場合とは、例えば、リクエスト情報の取得開始後、途中でテスト対象の入出力定義が変わった（画面が遷移した）際、遷移後の入出力定義名＋日付のファイル名を持つテストケース定義が定義リポジトリに内に存在しない場合等が考えられる。

ステップＳ７１５において、情報処理装置１０１は、新たなテスト対象である入出力定義用のテストケース定義ファイルを作成する。

ステップＳ７１６において、情報処理装置１０１は、対象のテストケース定義ファイルに、ステップＳ７１１にて解析したリクエスト情報の解析結果に基づき、テストケース定義情報を生成する。具体的には、ステップＳ７１１にて解析した結果、リクエスト情報が「画面表示要求の操作」であると判定した場合は、当該画面を表示する「画面表示」命令を生成する。また、ステップＳ７１１にて解析した結果、リクエスト情報が「アクション操作」であると判定した場合は、パラメータに対応する入出力定義の項目に引数の値を入力する「項目値入力」命令を生成し、当該アクションを実行する「アクション実行」命令を生成する。

なお、本実施形態においては、ステップＳ７１６にて「画面表示」「項目値入力」「アクション実行」命令を生成するとしたが、これらの命令に限定するものではなく、ステップＳ７１０にてその他の命令（例：キーボード・マウス・タッチパネル等の入力装置による操作、カメラ等の周辺機器の操作、音声入力、ブラウザ操作、ｎ秒待機、不正な操作等）を含むリクエスト情報を取得し、ステップＳ７１１にてそれらの命令を解析し、ステップＳ７１６にてそれらの命令に対応するテストケース定義を生成できるとしてもよい。

ステップＳ７１７において、情報処理装置１０１は、ステップＳ７１０～Ｓ７１７を繰り返すことによって作成されたテストケース定義に基づき、図１９のようなテストケース定義４０７を生成し、外部メモリ２１１に記憶する。

具体的には、ステップＳ７１１にて解析したリクエスト情報を、テストケース定義４０７の要素＜ａｕｔｏｔｅｓｔ－ｓｔｅｐ＞に変換することにより、テストケース定義４０７を生成する。同様に、テストケース手順の「命令」はテストケース定義４０７の要素＜ｃｏｍｍａｎｄ＞に、「入出力」は＜ｏｂｊｅｃｔ＿０１＞に、「入出力項目」は＜ｏｂｊｅｃｔ＿０２＞に、「行番号」は＜ｏｂｊｅｃｔ＿０３＞に、「引数」は＜ａｒｇｕｍｅｎｔ＞にそれぞれ変換する。

なお、本実施形態においては、テストケース定義４０７を図１６のようなＸＭＬファイルとしたが、ＸＭＬファイルに限定するものではなく、その他の形式のファイルとして生成したり、データベースに記憶させたり、ファイルやデータベース以外の情報として生成したりしてもよい。

すなわち、ステップＳ７１７は、アプリケーションに係るテストをするテストケースであって、取得された定義情報に対して、取得された当該定義情報に対する操作内容を実行するテストケースを生成する処理の一例を示すステップである。
なお、アプリケーションの操作によらずにテストケース定義を作成する場合、テストケース手順入力画面（図１２）を用いて作成する。

例えば、図１２では、グループ項目「Ｇ ユーザマスタ」の入出力項目「ＩＤ」「パスワード」「名前」への引数を入力する。グループ項目とは、入出力項目を複数持つ表である（例：図６の６０２）。この命令に、行番号と引数を入力したものを１３０２（図１３）に示す。１３０２（図１３）は、グループ項目における明細「１」行目の入出力項目「ＩＤ」「パスワード」「名前」にそれぞれ「１」「ｙａｍａｄａ」「山田」を入力するという意味である。

また、命令が「項目値検証」の場合の引数は、その「入出力項目」の値が、テスト実行時にその「引数」の値と等しいか否かを判定するという意味である（図１３の１３０３）。ここでは、１３０２にて「項目値入力」を行い、「アクション実行」でＵＰＤＡＴＥ（更新）処理を行った後において、「ＩＤ」の値が「１」と等しいか否かを判定する。つまり、その時点で「ＩＤ」＝１の場合は、そのテスト手順＝成功と判定し、「ＩＤ」≠１の場合は、そのテスト手順＝失敗と判定する（詳細は、図９のステップＳ９１１にて後述する）。
以上で、図７の説明を終了する。

以上により、アプリケーション構築ツールにおいて生成したアプリケーションを操作することによってテストケースを生成することができるため、アプリケーション構築ツールにおいて、アプリケーションを構築するための定義情報に係るテストケースを容易に生成する仕組みを提供することができる。これにより、アプリケーションを構築するための定義情報が正しく定義されているか否かテストするためのテストケースを容易に生成することができる。

つまり、アプリケーション開発者は、テストを実行するプログラム（テストスクリプト）を記述する必要がないため、テストに係る工数を削減することができ、テストを効率的に行うことができる。よって、プログラミング知識のないアプリケーション開発者や単なるテスターであっても、アプリケーションの操作内容及びその手順さえ理解できれば、アプリケーションに係るテストケースを容易に生成することができる。

図８、図９及び図１０は、テスト実行のフローチャートの一例を示す図である。

ステップＳ８０１において、情報処理装置１０１は、テスト実行指示を受け付ける。具体的には、実行メニュー１４０１（図１４）の押下を受け付ける。

ステップＳ８０２において、情報処理装置１０１は、テスト実行対象のテストケース定義に係るアプリケーション１１０３（図１１）のアプリケーションコード４４０が作成済か否かを判定する。作成済の場合はステップＳ８０３に進み、未作成の場合は本フローチャートを終了する。

ステップＳ８０３において、情報処理装置１０１は、テスト実行部（インタープリタ）４３４とテストケース定義解釈部４３３を用いて、ステップＳ８０１で実行メニュー１４０１の押下時に選択されていたテストケースに対応するテストケース定義４０７を外部メモリ２１１から取得する。

ステップＳ８０４において、情報処理装置１０１は、テスト実行部（インタープリタ）４３４とテストケース定義解釈部４３３を用いて、ステップＳ８０３にて取得したテストケース定義４０７に含まれるテストケース数及びテスト手順数をカウントする。

ステップＳ８０５において、情報処理装置１０１は、テストビュー１４０３（図１４）を表示する。

ステップＳ８０６において、情報処理装置１０１は、テスト進捗バー１４０４（図１４）を空の状態で表示する。

ステップＳ８０７において、情報処理装置１０１は、テスト情報のテストツリーペイン１４０６（図１４）に、ステップＳ８０３及びステップＳ８０４でテスト対象としたテストケース名（例：ユーザ登録フォームチェック、商品登録フォームチェック）及びテスト手順（１．画面表示、２．行追加、３．…）を表示する。

ステップＳ８０８において、情報処理装置１０１は、テスト情報の詳細ペイン１４０７（図１４）にメッセージ「実行中…」を表示する。

ステップＳ８０９において、情報処理装置１０１は、テスト実行準備部４３２を用いて、テスト実行前準備を行う。具体的には、テスト実行前準備では、セッション、クッキー及びスレッド等の生成を行い、ユーザが実際にブラウザを用いてアプリケーションを実行した場合と同様のアプリケーションデータを生成する。これにより、ブラウザ、エンドユーザ操作及びアプリケーションサーバ等を用いなくても、アプリケーション構築ツールにおいて、テストを効率的に行うことができる。

ステップＳ９０１において、情報処理装置１０１は、テスト実行対象のテストケースの分だけ、ステップＳ９０２～Ｓ１００１を繰り返す。

ステップＳ９０２において、情報処理装置１０１は、テスト実行対象のテストケースのテスト手順の分だけ、ステップＳ９０３～Ｓ９１５、Ｓ９２１又はＳ９２５を繰り返す。

ステップＳ９０３において、情報処理装置１０１は、強制終了ボタン１４０５（図１４）の押下を受け付けたか否かを判断し、押下された場合はステップＳ９０４へ進み、押下されていない場合はステップＳ９０５へ進む。

ステップＳ９０４において、情報処理装置１０１は、テスト進捗バー１４０４を灰色１００％で更新し、未実行のテストケース又はテスト手順がある場合であっても中断し、本フローチャートを終了する。

ステップＳ９０５において、情報処理装置１０１は、テストケース定義解釈部４３３を用いて、テスト手順情報１２０３を取得する。

ステップＳ９０６において、情報処理装置１０１は、テスト手順情報のテスト命令が入力系か否かを判定し、入力系の場合はステップＳ９０７へ進み、入力系でない場合はステップＳ９０８へ進む。

ステップＳ９０７において、情報処理装置１０１は、アプリケーションコードアクセス部４３６を用いて、生成済のアプリケーションコード４４０へ疑似的に値の入力を実行する。その後、アプリケーションコードアクセス部を用いて、アプリケーションコード４４０から実行結果を受け取り、テスト結果取得部４３５を用いてテスト結果を得る。すなわち、ステップＳ９０７は、ステップＳ７１２にて受け付けた情報を用いて、テストを実行する処理の一例を示すステップである。また、ステップＳ９０７は、生成されたテストケースに基づき、テストを実行する処理の一例を示すステップである。

ステップＳ９０８において、情報処理装置１０１は、テスト手順情報のテスト命令が実行系か否かを判定し、実行系の場合はステップＳ９０９へ進み、実行系でない場合はステップＳ９１０へ進む。

ステップＳ９０９において、情報処理装置１０１は、アプリケーションコードアクセス部４３６を用いて、生成済のアプリケーションコード４４０へ疑似的にアクションを実行するリクエストを送る。その後、アプリケーションコードアクセス部４３６を用いて、アプリケーションコード４４０から実行結果を受け取り、テスト結果取得部４３５を用いてテスト結果を得る。

ステップＳ９１０において、情報処理装置１０１は、アプリケーションコードアクセス部４３６を用いて、生成済のアプリケーションコード４４０から検証対象の情報を取得する。

ステップＳ９１１において、情報処理装置１０１は、検証対象の情報（検証対象が定義情報に含まれる項目である場合、当該項目に係る情報（例；当該項目が持つ値や属性値））が条件（例；ステップＳ７１２にて入力を受け付けた引数の値）に合致するか否かを判定し、検証が成功（条件に合致する）の場合はステップＳ９１６へ進み、失敗（条件に合致しない）の場合はステップＳ９１２へ進む。

例えば、図１３の１３０３の場合、１３０２にて「項目値入力」を行い、「アクション実行」でＵＰＤＡＴＥ（更新）を行った後において、「ＩＤ」の値が「１」と等しいか否かを判定する。つまり、その時点で「ＩＤ」＝１の場合は、そのテスト手順＝“成功”と判定し、「ＩＤ」≠１の場合は、そのテスト手順＝“失敗”と判定する。

なお、本実施形態においては、検証系の例として「項目値検証」を挙げたが、項目値に限定するものではなく、例えば、表示するオブジェクトやメッセージの表示位置、色、大きさ又は表示内容等の検証であってもよい。また、表示、認証、検索、追加、更新若しくは削除等の処理にかかった時間、ＣＰＵの使用率、記憶領域の空き容量、又は、カメラ等の周辺機器から取得可能な情報等、テスト実行時に取得可能な情報に係る検証であれば、その他の検証であってもよい。

すなわち、ステップＳ９１１は、ステップＳ７１２にて受け付けた情報を用いて、テストを実行する処理の一例を示すステップである。また、ステップＳ９１１は、受け付けた値と項目が持つ値とを比較した結果に基づいて、実行されるテストの成否を判定する処理の一例を示すステップである。

ステップＳ９１２において、情報処理装置１０１は、テスト手順のステータスを“失敗”としてＲＡＭ２０２に記憶する。

ステップＳ９１３において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、検証失敗数を更新する（図１５の１５０３）。

ステップＳ９１４において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、テスト手順数を更新する（図１５の１５０２）。

ステップＳ９１５において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、進捗バーを赤色で更新する（図１５の１５０５）。

ステップＳ９１６において、情報処理装置１０１は、アプリケーションエラーが発生していないことを確認する。発生していなければステップＳ９２２へ進み、エラーが発生している場合は、ステップＳ９１７へ進む。

ステップＳ９１７において、情報処理装置１０１は、テスト手順のステータスを“テスト失敗”としてＲＡＭ２０２に記憶する。

ステップＳ９１８において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、テスト失敗数を更新する（図１５の１５０４）。

ステップＳ９１９において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、テスト手順数を更新する（図１５の１５０２）。

ステップＳ９２０において、情報処理装置１０１は、テスト結果取得部４３５及びテスト結果表示部４３８を用いて、進捗バーを赤色で更新する（図１５の１５０５）。

ステップＳ９２１において、情報処理装置１０１は、テスト結果表示部４３８を用いて、テストケース数を更新する（図１５の１５０１）。その後、未実施のテスト手順が実行中のテストケースに含まれている場合であっても、それらの実行はせず、次に実行予定のテストケースを実行する。ステップＳ９０２に戻る。

ステップＳ９２２において、情報処理装置１０１は、テスト手順のステータスを“成功”として登録する（図１５の１５０７）。

ステップＳ９２３において、情報処理装置１０１は、テスト結果表示部４３８を用いて、テスト手順数を更新する（図１５の１５０２）。

ステップＳ９２４において、情報処理装置１０１は、これまでのテスト手順のステータスにテスト失敗及び検証失敗の両方が０件であるか否かを判定し、正の場合はステップＳ９２５に進み、偽の場合はステップＳ９２５を行わない。

ステップＳ１００１において、情報処理装置１０１は、テスト結果表示部４３８を用いて、テストケース数を更新する（図１５の１５０１）。

ステップＳ１００２において、情報処理装置１０１は、テスト終了処理部４３７を用いて、テスト実行を終了する。具体的には、テスト実行終了処理では、ステップＳ８０９にて生成したセッション、クッキー及びスレッド等をクローズする。

ステップＳ１００３において、情報処理装置１０１は、テスト結果表示部４３８を用いて、テスト実行時間を更新する（図１５の１５０６）。

ステップＳ１００４において、情報処理装置１０１は、テスト結果取得部４３５とテスト結果表示部４３８を用いて、テスト中に出力されるログをアプリケーションログビューに表示する（図１５の１５０９）。

以上により、テスト対象の画面や処理に到達するまでに必要な画面や処理（例えば、ログイン処理やメニュー画面等）がテストできる程度に構築されていない状態であっても、アプリケーション構築ツールにおいて、テスト対象の定義についてのみテストを行うことができるため、テストを効率的に行うことができる。つまり、早い段階でテスト工程を開始することができるため、高品質なアプリケーションを構築することができる。

以上で、図８、図９及び図１０の説明を終了する。

なお、本実施形態のようなアプリケーション構築ツールにおいては、構築されたアプリケーション又は生成されたそのプログラムが正しく動作するかのテストよりも、アプリケーションを構築するために設定した定義情報が予想通りに設定されているかのテストをすべきである。

つまり、アプリケーション構築ツールによるアプリケーション構築又はプログラム生成そのものは信頼すべきであり、構築又は生成の基となった（アプリケーション開発者が設定した）定義情報についての正否についてテストすべきである。そのため、本発明が有効である。

以上により、アプリケーション構築ツールにおいて、アプリケーションを構築する又はプログラムを生成するために設定した定義情報が正しく定義されているかについて、テストを行うことができる。つまり、これにより、アプリケーション構築ツールにおいて、テスト対象を定義情報に絞ったテスト行うことができるため、テストを効率的に行うことができる。

勿論、本実施形態により生成したテストケースを用いて、テスト対象を定義情報に絞ったテストを行うだけでなく、構築又は生成したアプリケーションを動作させてテストを行うことで、アプリケーション全体までテスト対象を広げたテスト（総合テスト）を行うとしてもよい。

〔第２の実施形態〕
第１の実施形態は、アプリケーション構築ツールにおいて生成したアプリケーションを操作することによって、アプリケーション構築ツールにおいて、アプリケーションを構築するための定義情報に係るテストケースを容易に生成する仕組みであり、第２の実施形態は、テストケースを生成する設定に基づきテストケースを生成することで、必要なテストケースだけを容易に生成する仕組みである。

図２０は、第２の実施形態のソフトウェア構成を示すブロック図の一例である。第２の実施形態では、第１の実施形態における図３のブロック図を図２０に置き換え、第１の実施形態と同じ機能については、同じ番号を付与し説明を省略する。

情報処理装置１０１は、以下の機能部を備える。

検証設定取得部２００１は、テストケースの生成対象とする検証に係る設定を取得する機能部である。

トリガー設定取得部２００２は、検証に用いるテストケースを生成するトリガーの設定を取得する機能部である。

定義情報対象設定取得部２００３は、テストケースの生成対象とする定義情報の設定を取得する機能部である。

以上で、図２０の説明を終了する。

図２１は、情報処理装置１０１、アプリケーションサーバ１０２及びアプリケーションクライアント１０４の構成図である。第２の実施形態では、第１の実施形態における図４の構成図を図２１に置き換え、第１の実施形態と同じ構成については、同じ番号を付与し説明を省略する。

プロキシサーバ部４８０は、リクエスト受信部４８３を介し、アプリケーションの操作を行うアプリケーションクライアント１０４からのリクエスト情報を仲介するようにして受信する。受信したリクエスト情報は、記録管理部４８４で外部メモリに記録し、アプリケーションサーバ１０２に転送する。

プロキシサーバ部４８０は、フィルタ処理部４７４（図２１）を介し、アプリケーションの操作を行うアプリケーションクライアント１０４からのリクエスト情報のうち、テストケース定義情報（テストケース定義データ４７１）の生成の対象となる操作のみについて、テストケース定義情報の生成を行うべく、フィルタリングを行う。

テスト操作記録出力設定部４５０は、生成されたアプリケーションにおいてどのような操作又は処理が行われた場合に、その操作又は処理をテストケース定義情報（操作命令）（例：図１３の１３０２）として生成するかの設定である「記録する操作命令情報４５１」を外部メモリ２１１に記憶する。

テスト操作記録出力設定部４５０は、生成されたアプリケーションにおいてどのような検証を行うか、検証するために生成するテストケース定義情報（検証命令）（例：図１３の１３０３）の設定である「記録する検証命令情報４５２」を外部メモリ２１１に記憶する。

以上で、図２１の説明を終了する。

図２２は、第２の実施形態のテストケース定義生成のフローチャートの一例を示す図である。第２の実施形態では、第１の実施形態における図７のフローチャートを図２２に置き換え、第１の実施形態と同じ処理については、同じ番号を付与し説明を省略する。

ステップＳ２２０１において、情報処理装置１０１は、テストケースを生成する設定情報を取得する。すなわち、ステップＳ２２０１は、テストケースの生成対象とする検証に係る設定を取得する処理の一例を示すステップである。また、ステップＳ２２０１は、検証に用いるテストケースを生成するトリガーの設定を取得する処理の一例を示すステップである。また、ステップＳ２２０１は、テストケースの生成対象とする定義情報の設定を取得する処理の一例を示すステップである。

具体的には、外部メモリ２１１に記憶されているテスト操作記録出力設定部４５０の「記録する操作命令情報４５１」及び「記録する検証命令情報４５２」を取得する。テスト操作記録出力設定部４５０は、テスト操作記録出力設定画面２３００（図２３）であり、この画面で設定されたテストケース生成に係る設定が、「記録する操作命令情報４５１」及び「記録する検証命令情報４５２」として外部メモリ２１１に記憶される。

ここで、図２３について説明しておく。図２３は、第２の実施形態のテストケース生成に係る設定をする画面の一例を示す図である。

２３１０は、「全ての命令を出力する」「命令をフィルタリングする」のどちらかを選択するラジオボタンである。

２３２０は、生成されたアプリケーションにおいて、どのような操作又は処理が行われた場合に、その操作又は処理をテストケース定義情報（操作命令）として生成するかの設定である。２３２０の設定情報は、「記録する操作命令情報４５１」として外部メモリ２１１に記憶される。

例えば、画面表示２３２１（図２３）がチェックされた状態であれば、生成されたアプリケーションにおいて、「画面表示」の処理が行われた場合に、「画面表示」の処理を行うテストケース定義情報（操作命令）として生成する。

同様に、アクション実行２３２２（図２３）がチェックされた状態であれば、生成されたアプリケーションにおいて、「アクション実行」の操作が行われた場合に、「アクション実行」の操作を行うテストケース定義情報（操作命令）として生成する。「ページ」「ソート」「行追加」「行削除」「行選択」等の操作が行われた場合も同様である。

２３３０は、生成されたアプリケーションにおいて、どのような検証を行うか、検証するために生成するテストケース定義情報（検証命令）の設定である。２３３０の設定情報は、「記録する検証命令情報４５２」として外部メモリ２１１に記憶される。

例えば、画面検証２３３１（図２３）がチェックされた状態であれば、どのような画面が表示されているかを検証するテストケース定義情報（検証命令）を生成する。

同様に、項目値検証２３３２（図２３）がチェックされた状態であれば、生成されたアプリケーションにおける項目にどのような値が出力されているかを検証するテストケース定義情報（検証命令）を生成する。「メッセージ」「選択肢」「フィールドスタイル」「（ユーザの）ロール」等を検証する設定についても同様である。

２３４０は、テストケース定義情報（検証命令）を生成するためのトリガーの設定である。２３４０の設定情報も、２３３０と同様に「記録する検証命令情報４５２」として外部メモリ２１１に記憶される。

例えば、画面表示２３４１（図２３）がチェックされた状態であれば、生成されたアプリケーションにおいて、「画面表示」の処理が行われた場合に、テストケース定義情報（検証命令）を生成する。

同様に、アクション実行２３２２（図２３）がチェックされた状態であれば、生成されたアプリケーションにおいて、「アクション実行」の操作が行われた場合に、テストケース定義情報（検証命令）を生成する。「ページ」「ソート」「行追加」等の操作が行われた場合も同様である。

２３２０、２３３０、２３４０の選択肢は、図２３の選択肢に限定するものではなく、アプリケーションに係るその他の選択肢があってもよい。

以上で、図２３の説明を終了する。

図２２の説明に戻る。

ステップＳ２２０２において、情報処理装置１０１は、ステップＳ７１１にて解析したリクエスト情報に、テストケース定義情報（検証命令）を生成するためのトリガー（記録する検証命令情報４５２のトリガー情報）が含まれるかを判定する。トリガーが含まれる（つまり、アプリケーションの操作を行うアプリケーションクライアント１０４での操作がトリガー操作であった）場合はステップＳ２２０３に進み、トリガーが含まれない（つまり、アプリケーションの操作を行うアプリケーションクライアント１０４での操作がトリガー操作ではなかった）場合はステップＳ２２０４に進む。

ステップＳ２２０３において、情報処理装置１０１は、「記録する検証命令情報４５２」として記憶されている検証命令（図２３の２３３０）を、テストケース定義情報（検証命令）（図４の４７１）として生成する。

すなわち、ステップＳ２２０３は、テストが実行されたとき、実行されているアプリケーションに係る値を検証するテストケースを生成する処理の一例を示すステップである。また、ステップＳ２２０３は、テストが実行されたとき、実行されているアプリケーションに係る値であって、取得された設定に基づく値を検証するテストケースを生成する処理の一例を示すステップである。また、ステップＳ２２０３は、取得された設定に基づき、取得された定義情報がトリガーであると判断した場合、検証に用いるテストケースを生成する処理の一例を示すステップである。

これにより、所望する操作がされたときにのみ、所望するテストケースのみを容易に生成する仕組みを提供することができる。

ステップＳ２２０４において、情報処理装置１０１は、ステップＳ７１１にて解析したリクエスト情報に、テストケース定義情報（操作命令）を生成する対象の操作が含まれるかを判定する。対象の操作が含まれる（つまり、アプリケーションの操作を行うアプリケーションクライアント１０４での操作がテストケース定義情報（操作命令）を生成する対象の操作であった）場合はステップＳ２２０５に進み、対象の操作が含まれない（つまり、アプリケーションの操作を行うアプリケーションクライアント１０４での操作がテストケース定義情報（操作命令）を生成する対象の操作ではなかった）場合はステップＳ７１７に進む。

ステップＳ２２０５において、情報処理装置１０１は、ステップＳ７１１にて解析したリクエスト情報に含まれる操作をテストケース定義情報（操作命令）（図２１の４７１）として生成する。すなわち、ステップＳ２２０５は、取得された設定に基づき、取得された定義情報がテストケースの生成対象であると判断した場合、当該定義情報に対して、取得された当該定義情報に対する操作内容を実行するテストケースを生成する処理の一例を示すステップである。

これにより、所望するテストケースのみを容易に生成する仕組みを提供することができる。

以上で、図２２の説明を終了する。

以上により、テストケースを生成する設定に基づきテストケースを生成することで、所望する場合にのみ、所望するテストケースを容易に生成する仕組みを提供することができる。これにより、アプリケーションを構築するための定義情報が正しく定義されているか否かテストするためのテストケースを容易に生成することができる。

つまり、本発明により、必要なテストケースを効率的に生成することができるようになる。また、不要なテストケースが出力されないため、テストに要する時間を短縮することができるようになる。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ－ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ 情報処理装置
１０２ アプリケーションサーバ
１０３ データベースサーバ
１０４ アプリケーションクライアント
１０５ ネットワーク

Claims (14)

1. アプリケーションを構築するための定義情報を取得する第１の取得手段と、
   前記定義情報により構築された前記アプリケーションのテストケースを生成するために、該アプリケーションを実行し、該アプリケーションに対して行われた操作情報を取得する第２の取得手段と、
   前記定義情報により設定されるテストケースで実行する操作情報に係る命令の選択を受け付ける選択受付手段と、
   前記第２の取得手段により取得した操作情報のうち、前記選択受付手段により選択を受け付けた命令に対応する操作情報に係るテストを含むテストケースを生成するように制御する制御手段と
   を備えることを特徴とする情報処理システム。
2. 前記制御手段は、前記第２の取得手段により取得した操作情報のうち、前記選択受付手段により選択を受け付けた命令に対応しない操作情報に基づくテストを含まない前記テストケースを生成するように制御すること
   を特徴とする請求項１に記載の情報処理システム。
3. 前記選択受付手段により選択を受け付けた命令に基づいて前記テストケースを生成するか否かを設定する設定手段をさらに有すること
   を特徴とする請求項１又は２に記載の情報処理システム。
4. 前記選択受付手段は、選択可能な複数の命令を表示制御し、前記表示制御された複数の命令のうちいずれかの選択を受け付けること
   を特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記テストケースで実行する操作情報に係る命令には、前記第２の取得手段で取得した操作情報により生成される操作命令と、前記テストケースの実行結果を検証する検証命令とを含むこと
   を特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記検証命令を生成するトリガーの設定を取得するトリガー取得手段をさらに備え、
   前記制御手段は、前記第２の取得手段により取得された操作情報に前記トリガー取得手段により取得された設定されたトリガーが含まれる場合に前記検証命令を含むテストケースを生成するよう制御すること
   を特徴とする請求項５に記載の情報処理システム。
7. 前記トリガー取得手段により取得されるトリガーの設定は、前記操作命令の少なくとも１つであり、
   前記制御手段は、該操作命令のあとで、前記検証命令を実行するようにテストケースを生成するよう制御すること
   を特徴とする請求項６に記載の情報処理システム。
8. 前記第１の取得手段により取得した定義情報に基づき、前記アプリケーションを構築する構築手段をさらに備えることを特徴とする請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 前記制御手段により生成されたテストケースに基づき、テストを実行する実行手段をさらに備えることを特徴とする請求項１乃至８のいずれか１項に記載の情報処理システム。
10. アプリケーションを構築するための定義情報を取得する第１の取得手段と、
    前記定義情報により構築された前記アプリケーションのテストケースを生成するために、該アプリケーションを実行し、該アプリケーションに対して行われた操作情報を取得する第２の取得手段と、
    前記定義情報により設定されるテストケースで実行する命令を選択する選択手段と、
    前記選択手段により選択された命令と、前記第２の取得手段で取得した操作情報とにより、前記テストケースを生成するように制御する制御手段とを有し、
    前記テストケースで実行する命令には、前記第２の取得手段で取得した操作情報により生成される操作命令と、前記テストケースの実行結果を検証する検証命令とを含み、
    前記検証命令を生成するトリガーの設定を取得するトリガー取得手段をさらに備え、
    前記制御手段は、前記第２の取得手段により取得された操作情報に前記トリガー取得手段により取得された設定されたトリガーが含まれる場合に前記検証命令を含むテストケースを生成するよう制御すること
    を特徴とする情報処理システム。
11. 前記トリガー取得手段により取得されるトリガーの設定は、前記操作命令の少なくとも１つであり、
    前記制御手段は、該操作命令のあとで、前記検証命令を実行するようにテストケースを生成するよう制御すること
    を特徴とする請求項１０に記載の情報処理システム。
12. 情報処理システムが、
    アプリケーションを構築するための定義情報を取得する第１の取得ステップと、
    前記定義情報により構築された前記アプリケーションのテストケースを生成するために、該アプリケーションを実行し、該アプリケーションに対して行われた操作情報を取得する第２の取得ステップと、
    前記定義情報により設定されるテストケースで実行する操作情報に係る命令の選択を受け付ける選択受付ステップと、
    前記第２の取得手段により取得した操作情報のうち、前記選択受付ステップにより選択を受け付けた命令に対応する操作情報に係るテストを含むテストケースを生成するように制御する制御ステップと
    を実行することを特徴とする制御方法。
13. 情報処理システムが、
    アプリケーションを構築するための定義情報を取得する第１の取得ステップと、
    前記定義情報により構築された前記アプリケーションのテストケースを生成するために、該アプリケーションを実行し、該アプリケーションに対して行われた操作情報を取得する第２の取得ステップと、
    前記定義情報により設定されるテストケースで実行する命令を選択する選択ステップと、
    前記選択ステップにより選択された命令と、前記第２の取得ステップで取得した操作情報とにより、前記テストケースを生成するように制御する制御ステップとを実行し、
    前記テストケースで実行する命令には、前記第２の取得ステップで取得した操作情報により生成される操作命令と、前記テストケースの実行結果を検証する検証命令とを含み、
    前記検証命令を生成するトリガーの設定を取得するトリガー取得ステップをさらに実行し、
    前記制御ステップは、前記第２の取得ステップにより取得された操作情報に前記トリガー取得ステップにより取得された設定されたトリガーが含まれる場合に前記検証命令を含むテストケースを生成するよう制御すること
    を特徴とする制御方法。
14. 少なくとも１つのコンピュータを請求項１乃至１１のいずれか１項に記載の情報処理システムとして機能させるためのプログラム。
    

Images