JP2019197259A - 情報処理装置、その制御方法及びプログラム - Google Patents

Abstract

【課題】複数のテスト工程を並行して行うための仕組みを提供すること。【解決手段】アプリケーションを構築する情報処理装置であって、アプリケーションを構築するためのデータベース定義からデータベースの選択を受け付けるデータベース選択受付手段と、データベース選択受付手段で選択されたデータベースであって、互いに異なるデータベースを接続先とする複数のテストスイートを生成するテストスイート生成手段と、テストスイート生成手段により生成された複数のテストスイートに基づいて、接続先のデータベースのデータを用いてアプリケーションに係るテストを実行するテスト実行手段を備えることを特徴とする。【選択図】 図１７

Description

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

従来、設定された定義に基づきアプリケーションを構築（生成）するツールやサービスが存在する。このようなツールやサービスを利用して構築したアプリケーションであっても、アプリケーション定義の設定ミスにより予想外の動作をすることがあるため、テスト工程を省略することはできない。また、アプリケーションが大規模になるに従い、テスト工程の数は肥大化する傾向となる。特に、大規模なアプリケーションの場合、複数のテスト工程を並列して同時に実行することによりテストにかかる時間を低減できることが好ましい。

特許文献１には、登録されたテストケースに基づきテスト用のプログラムを生成する仕組みが開示されている。

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

しかしながら、特許文献１に記載の技術では、複数のテストを並列に同時実行する場合について何ら考慮されていない。特に、複数のテストを行う際に同一のデータベースに接続すると、１のテストの実行中にデータが書き換えられてしまい、正確なテスト結果が得られないおそれがあった。

そこで本発明は、上記の課題に鑑みてなされたものであり、複数のテスト工程を並行して行うための仕組みを提供することを目的とする。

本発明の目的を達成するために、例えば、本発明の情報処理装置は、以下の構成を有する。すなわち、アプリケーションを構築する情報処理装置であって、前記アプリケーションを構築するためのデータベース定義からデータベースの選択を受け付けるデータベース選択受付手段と、前記データベース選択受付手段で選択されたデータベースを接続先とするテストスイートを生成するテストスイート生成手段と、前記テストスイート生成手段により生成されたテストスイートに基づいて、前記接続先のデータベースのデータを用いて前記アプリケーションに係るテストを実行するテスト実行手段を備えることを特徴とする。

本発明によれば、複数のテスト工程を並行して行うための仕組みを提供することが可能となる。

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

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明の一実施形態に係るシステムの構成図の一例である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

定義情報取得部３０１は、アプリケーションを構築するための定義情報を取得する機能部である。ここで、定義情報は、リポジトリ定義部４０１に設定された、アプリケーション定義４０２、入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５、データベース定義４０６（図４参照）を含む。

テスト実行部３０２は、定義情報取得部３０１により取得された定義情報を用いて生成されたテストケースに基づき、アプリケーションに係るテストを実行する機能部である。言い換えると、テスト実行部３０２は、定義情報取得部３０１により取得された定義情報を用いて生成されたテストケースに基づき、定義情報が正しく定義されているか否かのテストを実行する機能部であるともいえる。また、テスト実行部３０２は、情報受付部３０３により受け付けた情報を用いて、テストを実行する機能部である。

また、テスト実行部３０２は、生成されたテストスイートに基づき、接続先のデータベースのデータを用いてアプリケーションに係るテストを実行する機能部である。なお、テスト実行部３０２は、複数のテストスイートを並列に実行させ、テストを行うことが可能である。

情報受付部３０３は、テスト実行部３０２により実行されるテストに用いる情報を受け付ける機能部である。情報受付部３０３は、一態様として、表示制御部３１０により出力部２１０で選択可能に表示された各種情報の選択を受け付ける。具体的には、情報受付部３０３は、テストに用いるテストケースの選択を受け付ける。また、情報受付部３０３は、テストに用いるテストスイートに設定するテストケースの選択を受け付ける。さらに、情報受付部３０３は、設定されたテストケースあるいは、テストスイートに基づきアプリケーションに係るテストの開始を受け付ける。そして、情報受付部３０３は、図２１における実行ボタン２１０５が選択されたか否かを受け付ける。つまり、情報受付部３０３は、テストの開始を受け付ける機能を備える（テスト開始受付部）。また、情報受付部３０３は、データベース定義からデータベースの選択を受け付ける機能を備える（データベース選択受付手段）。

テストケース定義受付部３０４は、テストケースの定義を受け付ける機能部である。

テストケース生成部３０５は、テストケース定義受付部３０４により受け付けた定義に基づき、テストケースを生成する機能部である。テストケース生成部３０５は、代入値入力受付部３０６により受け付けた値を項目に対して代入することを含むテストケースを生成する機能部である。テストケース生成部３０５は、予想値入力受付部３０７により受け付けた値と項目が持つ値とを比較することを含むテストケースを生成する機能部である。

代入値入力受付部３０６は、定義情報取得部３０１により取得された定義情報に含まれる項目に対して代入する値の入力を受け付ける機能部である。

予想値入力受付部３０７は、定義情報取得部３０１により取得された定義情報に含まれる項目が持つと予想される値の入力を受け付ける機能部である。

テスト成否判定部３０８は、予想値入力受付部３０７により受け付けた値と項目が持つ値とを比較した結果に基づいて、テスト実行部３０２により実行されるテストの成否を判定する機能部である。

アプリケーション構築制御部３０９は、テスト成否判定部３０８によりテストの結果に従って、アプリケーションの構築をする／しないを制御する機能部である。

表示制御部３１０は、出力部２１０（例えば、ディスプレイの画面上の表示）へ表示される内容を制御する機能部である。本実施形態において、表示制御部３１０は、後述する、図６、図１１〜１５、図１９、図２１〜２３等のテストケース、およびテストスイートの生成から実行に係る各画面の表示を制御する。つまり、表示制御部３１０は、図４で説明する各エディタ部により生成される画面を表示する機能を備える。また、テストスイートを用いてテストする場合に、表示制御部３１０は、テストスイート生成部３１１で生成された複数のテストケースのうち所定の条件に対応するテストケースを選択可能に表示するように制御する。ここで、所定の条件とは、ユーザにより選択されたテストケースの表示内容を絞り込むための条件であり、例えば、定義情報単位、あるいは、生成した日時に基づいて決定される条件である。なお、具体的な処理については、図１７〜２３を用いて後述する。

テストスイート生成部３１１は、テストスイートを生成する機能部である。また、テストスイート生成部３１１は、ユーザの操作に応じて、テストケース生成部３０５で生成されたテストケースをテストスイートに設定する機能を備える。テストスイートは、１または複数のテストケースを１単位としたファイルである。テストスイートは、目的別に設定された複数のテストケースをまとめて管理をすることが可能となる。そのため、ユーザは、大規模なアプリケーションを構築する場合でも、目的単位のテストスイートを生成しておくことで、テストの内容を容易に管理することができる。

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

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

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

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

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

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

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

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

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

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

テストケース定義４０７は、テストケースの定義情報を保持する。

プレビューデータ４０８は、リポジトリ定義部４０１をプレビューする際のデータを保持する。

テストスイート定義４０９は、テストスイートの定義情報を保持する。

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

リポジトリ定義エディタ部４２０は、リポジトリ定義参照部４２１によってリポジトリ定義部４０１を解析する。

テストケース定義エディタ部４６０は、テストケース定義参照部４６１と、対象画面入力部４６２と、値入力部４６３と、アクション入力部４６４と、対象項目入力部４６５と、期待値入力部４６６を有する。それぞれの入力部から入力された値を保存することでテストケース定義４０７が作成される。

テストスイート定義エディタ部４７０は、テストケース定義選択部４７１と、入出力定義選択部４７２と、ビジネスプロセス定義選択部４７３と、データモデル定義選択部４７４と、関連テストケース抽出部４７５と、定義ファイル変更時間条件部４７６と、選択済みテストケース定義４７７を有する。テストスイート定義エディタ部４７０は、これらの各部より選択、あるいは抽出された値に基づきテストスイート定義４０９を作成・編集する。

テストケース定義選択部４７１は、リポジトリ定義部４０１に含まれる任意のテストケース定義４０７の選択を受け付ける。

入出力定義選択部４７２は、リポジトリ定義部４０１に含まれる任意の入出力定義４０３の選択を受け付ける。

ビジネスプロセス定義選択部４７３は、リポジトリ定義部４０１に含まれる任意のビジネスプロセス定義４０５の選択を受け付ける。

データモデル定義選択部４７４は、リポジトリ定義部４０１に含まれる任意のデータモデル定義４０４の選択を受け付ける。

関連テストケース抽出部４７５は、入出力定義選択部４７２、ビジネスプロセス定義選択部４７３、データモデル定義選択部４７４で選択された定義を参照するテストケースを抽出する。

定義ファイル変更時間条件部４７６は、関連テストケース抽出部４７５がテストケース定義４０７を抽出する際に定義ファイルの変更時間を条件として抽出をする。

選択済みテストケース定義４７７は、テストスイートに含まれるテストケースとしてテストスイート定義４０９に保存される。

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

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

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

次に、テストスイート定義エディタ部４７０について説明する。テストスイート定義エディタ部４７０は、テストケース定義選択部４７１と、入出力定義選択部４７２と、ビジネスプロセス定義選択部４７３と、データモデル定義選択部４７４と、関連テストケース抽出部４７５と、定義ファイル変更時間条件部４７６と、選択済みテストケース定義４７７と、接続先ＤＢ設定部４７８を有する。テストスイート定義エディタ部４７０は、テストスイート定義４０９を作成・編集する機能を備える。

テストケース定義選択部４７１は、リポジトリ定義部４０１に含まれる任意のテストケース定義４０７の選択を受け付ける。

入出力定義選択部４７２は、リポジトリ定義部４０１に含まれる任意の入出力定義４０３の選択を受け付ける。

ビジネスプロセス定義選択部４７３は、リポジトリ定義部４０１に含まれる任意のビジネスプロセス定義４０５の選択を受け付ける。

データモデル定義選択部４７４は、リポジトリ定義部４０１に含まれる任意のデータモデル定義４０４の選択を受け付ける。

関連テストケース抽出部４７５は、入出力定義選択部４７２、ビジネスプロセス定義選択部４７３、データモデル定義選択部４７４で選択された定義を参照するテストケースを抽出する。

定義ファイル変更時間条件部４７６は、関連テストケース抽出部４７５がテストケース定義４０７を抽出する際に定義ファイルの変更時間を条件として抽出をかけることができる。

選択済みテストケース定義４７７は、テストスイートに含まれるテストケースとしてテストスイート定義４０９に保存される。

接続先ＤＢ設定部４７８は、テストをどのデータベース定義４０６で動かすかを設定する。設定された内容はテストスイート定義４０９に保存される。また、接続先ＤＢ設定部４７８は、初期設定の接続先も記憶する（データベース記憶手段）。

次に、テストスイート実行部４８０について説明する。テストスイート実行部４８０は、テストスイート定義受信部４８１と、接続先ＤＢ４８２と、テストケース定義取得部４８３と、スレッド生成部４８４を有する。

テストスイート定義受信部４８１は、テストスイート定義４０９を受信し、接続先ＤＢ４８２を取得する。テストケース定義取得部４８３は、テストスイートに設定されたテストケース定義４０７を取得する。接続先ＤＢ４８２は、データベース定義４０６で保存されるデータベースのうちテストの際に接続するデータベースである。

テストスイート実行部４８０は、スレッド生成部４８４を介して、テスト実行部３０２へテストケース定義取得部４８３で取得したテストケース定義４０７と接続先ＤＢ４８２を送信する。テスト実行部３０２はそれらをもとにテストを実行する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップＳ５１０において、情報処理装置１０１は、ステップＳ５０９にて生成したテストケース定義を用いてテストスイート定義４０９を作成する（詳細は、図１７の説明にて後述する）。

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

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

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

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

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

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

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

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

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

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

図６は、アプリケーションの入出力定義画面及びアプリケーションの実行画面の一例を示す図である。入出力定義画面６０１は、１つのアプリケーションに設定される入出力定義を一覧で表示する画面である。

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

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

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

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

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

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

ステップＳ７０６において、情報処理装置１０１は、登録するテスト手順の数だけステップＳ７０７〜Ｓ７１２を繰り返す。

ステップＳ７０７において、情報処理装置１０１は、テスト実行時に疑似的に行う命令の選択を受け付ける。命令の種類は、例えば、「画面表示」「行追加」「項目値入力」「項目値検証」等がある。

通常、スクラッチ開発によって構築されたアプリケーションのテストは、テスト要員による「画面表示」「行追加」「項目値入力」等の操作及び目視による「項目値検証」を必要とするが、本実施形態におけるテストは、テスト要員が行う操作及び目視をステップＳ７０７にて「命令」として手順化しておき、構築されたアプリケーション又は生成されたアプリケーションプログラムに対して（テスト要員が操作を行ったかのように疑似的に）「命令」を実行することで、テストの実行及び検証が自動でできるようになる。

なお、本実施形態においては、命令の種類は上記４種類の中から選択を受け付けるとしたが、この４種類に限定するものではなく、その他の命令（例：キーボード・マウス・タッチパネル等の入力装置による操作、カメラ等の周辺機器の操作、音声入力、ブラウザ操作、ｎ秒待機、不正な操作等）を選択できるとしてもよい。

ステップＳ７０８において、情報処理装置１０１は、ステップＳ７０５にて取得した入出力定義４０３に基づき、「対象アプリケーション１１０３」に属す入出力定義４０３を選択肢として表示する（図１２の１２０３）。

ステップＳ７０９において、情報処理装置１０１は、ステップＳ７０８にて表示した選択肢から、テスト実行に用いる入出力定義４０３の選択を受け付ける。

ステップＳ７１０において、情報処理装置１０１は、ステップＳ７０９にて選択を受け付けた入出力定義４０３に属す入出力項目を選択肢として表示する（図１２の１２０４）。例えば、ステップＳ７０７にて、命令に「項目値入力」が選択された場合は、入出力項目のうち値を入力できる項目だけに絞った選択肢を表示する。

ステップＳ７１１において、情報処理装置１０１は、ステップＳ７１０にて表示した選択肢から、テスト実行に用いる入出力項目の選択を受け付ける。

ステップＳ７１２において、情報処理装置１０１は、テストの命令実行時に用いる入出力項目への引数の入力を受け付ける。

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

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

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

すなわち、ステップＳ７１２は、実行されるテストに用いる情報を受け付ける処理の一例を示すステップである。また、ステップＳ７１２は、取得された定義情報に含まれる項目に対して代入する値の入力を受け付ける処理の一例を示すステップである。また、ステップＳ７１２は、取得された定義情報に含まれる項目が持つと予想される値の入力を受け付ける処理の一例を示すステップである。

すなわち、ステップＳ７０６〜Ｓ７１２は、テストケースの定義を受け付ける処理の一例を示すステップである。

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

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

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

すなわち、ステップＳ７１３は、取得された定義情報を用いて、テストケースを生成する処理の一例を示すステップである。また、ステップＳ７１３は、受け付けた定義に基づき、テストケースを生成する処理の一例を示すステップである。また、ステップＳ７１３は、受け付けた値を項目に対して代入することを含むテストケースを生成する処理の一例を示すステップである。また、すなわち、ステップＳ７１３は、受け付けた値と項目が持つ値とを比較することを含むテストケースを生成する処理の一例を示すステップである。

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

以上により、アプリケーションを構築するための定義情報を用いて、アプリケーションに係るテストケースを容易に生成することができるようになる。また、アプリケーションを構築するための定義情報を用いて、定義情報が正しく定義されているか否かテストするためのテストケースを容易に生成することができるようになる。

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

ステップＳ８０１において、情報処理装置１０１は、接続先ＤＢ受信部４３９を介して、テストスイート定義４０９に接続先ＤＢ４８２があるか否かを確認する。情報処理装置１０１は、確認した結果、接続先ＤＢがある場合はステップＳ８０３へ進み、ない場合はステップＳ８０２へ進む。

ステップＳ８０２において、情報処理装置１０１は、テスト対象のＷｅｂアプリケーションコードが生成済みであるか否かを確認する。情報処理装置１０１は、該当するＷｅｂアプリケーションコードが生成されていればステップＳ８０４へ進み、なければテスト実行を終了する。

ステップＳ８０３において、情報処理装置１０１は、接続先ＤＢが同じかつテスト対象のＷｅｂアプリケーションコードが生成済みであることを確認する。情報処理装置１０１は、該当するＷｅｂアプリケーションコードが生成されていればステップＳ８０４へ進み、なければテスト実行を終了する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上により、テスト対象のアプリケーションが動作可能な状態でなくても、アプリケーション構築ツールにおいて、テスト対象の定義についてのみテストを行うことができるため、テストを効率的に行うことができるようになる。

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

次に、図１７を用いて、テストスイート定義の作成フローについて説明する。

ステップＳ１７０１において、情報処理装置１０１は、ユーザからのテストケース定義作成の指示を受け付ける。具体的には、新規テストスイート生成受付表示１９０１（図１９）の選択を受け付ける。ここで、図１９のテストスイート作成メニュー画面の一例について説明する。情報処理装置１０１は、新規テストスイート生成受付表示１９０１が選択されたことに従い、ユーザによるテストスイート定義の作成指示を受け付ける。

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

ステップＳ１７０３において、情報処理装置１０１は、新規テストスイート生成メニュー画面１９０２（図１９）を表示し、接続先ＤＢコード１９０３の選択（図１９）を受け付ける。接続先ＤＢコード１９０３は、リポジトリ定義部４０１内のデータベース定義４０６の中から選択される。ここで、情報処理装置１０１は、データベースが選択されなかった場合に、初期設定の接続先のデータベース設定２３０３（図２３）に接続し、テストを実行する。また、情報処理装置１０１は、すでに他のテストスイートで接続先として設定されているデータベースを選択できないように制御してもよい。例えば、情報処理装置１０１は、接続先ＤＢコード１９０３のドロップダウンリストで表示させないようにしてもよい。あるいは、情報処理装置１０１は、他のテストスイートで接続先として設定されているデータベースを選択した場合に、新規テストスイート生成メニュー画面１９０２を遷移できないように制御してもよい。このように、情報処理装置１０１は、複数のテストスイートで互いに異なるデータベースに接続させるように、ユーザの操作を支援することができる。
また、情報処理装置１０１は、データベース設定画面２３０２を表示して接続先データベースを選択させてもよい。ユーザは、データベース設定画面２３０２上で、データベースを選択することにより、テストスイートに用いるデータベースを選択することができる。この場合、データベース設定画面２３０２は、デフォルトで接続するデータベースを示す表示アイテム２３０４を表示する。なお、情報処理装置１０１は、他のテストスイートの設定でユーザにより任意に設定されたデータベースを示す表示アイテム２３０５をデータベース設定画面２３０２に表示させてもよい。後述するように、本実施形態において、情報処理装置１０１は、複数のテストスイートを並列に実行する。そのため、情報処理装置１０１は、当該テストスイートで接続するデータベースを他のテストスイートで選択されていないデータベースに設定する。

ステップＳ１７０４において、情報処理装置１０１は、新規テストスイート生成メニュー画面１９０２（図１９）の入力欄１９０５、接続先ＤＢコード１９０３、対象テストケース１９０４で入力された内容に基づいてテストスイート定義が生成される。

ステップＳ１７０５において、情報処理装置１０１は、リポジトリ定義部４０１に記憶されるテストケース定義４０７を選択可能なテストスイート設定画面２１００（図２１）を表示する。図２１におけるテストスイート設定画面２１００は、テストスイート定義に記憶された複数のテストケースからテストスイートに設定するものを選択することができる。

また、テストスイート設定画面２１００は、対象テストケース１９０４で選択されたテストケース２１０１をすでに選択された状態で表示される（図２１）。ユーザは、テストスイート設定画面２１００から、テストスイート定義に含めたいテストケースを任意に選択する。そして、情報処理装置１０１は、当該選択されたテストケースをテストスイート定義４０９に保存する。言い換えると、情報処理装置１０１は、テストケースの選択情報をテストスイート定義に設定しているとも言える。

ステップＳ１７０６において、情報処理装置１０１は、ユーザからのテストケース定義の絞り込みの指示を受け付ける。具体的には、情報処理装置１０１は、リポジトリ定義を示すタブ２１０２が選択されているか判定する。

ステップＳ１７０７において、情報処理装置１０１は、選択されたタブ２１０２が示すリポジトリ定義に対応するテストスイートを表示する。テストスイート設定画面２１００を例に説明すると、情報処理装置１０１は、「ＩＯ」のタブ２１０２が選択されることにより、リポジトリ定義部４０１内の入出力定義４０３をテストに含むテストケースを一覧で表示する。情報処理装置１０１は、表示されたテストケースへの選択を受け付ける。また、情報処理装置１０１は、「DM」のタブ２１０２が選択されることにより、リポジトリ定義部４０１内のデータモデル定義４０４をテストに含むテストケースを一覧で表示する。また、情報処理装置１０１は、「ＢＰ」のタブ２１０２が選択されることにより、リポジトリ定義部４０１内のビジネスプロセス定義４０５をテストに含むテストケースを一覧で表示する。

ステップＳ１７０８において、情報処理装置１０１は、ユーザからの定義ファイル変更時間条件部４７６によるテストケース定義の絞り込みの指示を受け付ける。具体的には、情報処理装置１０１は、定義ファイル変更時間条件部４７６で記憶される変更情報を基に表示を制御する。情報処理装置１０１は、変更時間条件２１０４（図２１）の入力を受け付け、当該入力された条件と定義ファイル変更時間条件部４７６で記憶する条件を比較する。情報処理装置１０１は、当該比較した結果を用いて、変更時間条件２１０４以降に記憶されたテストケース定義を表示する。
ステップＳ１７０９において、情報処理装置１０１は、入力された時間以降に更新されたリポジトリ情報を含むテストケースを表示する。具体的には、情報処理装置１０１は、定義ファイル変更時間条件部４７６に記憶された、後に更新されたリポジトリ情報を含むテストケース定義４０７をソートして表示する。

ステップＳ１７１０において、情報処理装置１０１は、所定の条件により表示されたテストケース定義４０７の選択を受け付ける。具体的には、情報処理装置１０１は、チェックボックス２１０９で、選択または解除することができる。情報処理装置１０１は、選択を受けつけたテストケース定義をテストスイートとして設定済みとし、テストスイート定義４０９を更新する。情報処理装置１０１は、選択結果２１０２（図２１）で示すように、選択されたテストケースを、テストスイート定義を親とした階層構造で表示する。

次に図１８を用いて、ＤＢ別テストスイート用アプリケーションプログラム生成フローについて説明する。

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

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

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

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

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

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

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

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

ステップＳ１８０８において、情報処理装置１０１は、ユーザからのテストスイート選択を受け付ける。具体的には、情報処理装置１０１は、アプリケーション生成画面２３００（図２３）で選択を受け付ける。情報処理装置１０１は、テストスイート選択部２３０１で選択されたテストスイートを生成対象として受け付ける。

ステップＳ１８０９において、情報処理装置１０１は、選択したテストスイートに接続先ＤＢ４８２がある場合は、ステップＳ１８１０へ進み、接続先ＤＢ４８２がない場合はステップＳ１８１２へ進む。

ステップＳ１８１０において、情報処理装置１０１は、接続先ＤＢコードの情報がある場合、データベース定義４０６から該当する接続先ＤＢコードと一致するデータベース情報を参照する。

ステップＳ１８１１において、情報処理装置１０１は、アプリケーション名をアプリケーション名とテストスイート名からなるものへ変更する。

ステップＳ１８１２において、情報処理装置１０１は、データベース定義４０６からデフォルトのデータベース設定を参照する。データベース設定画面２３０２は、データベース定義４０６に記憶されるデータベース定義を一覧で表示する画面である。当該データベース定義は、リポジトリ定義エディタ部４２０で参照され、表示制御部３１０で表示される。情報処理装置１０１は、データベース設定画面２３０２で表示されるデータベース定義のうち、いずれのデータベースをデフォルトで使用するかを記憶している。また、情報処理装置１０１は、いずれのデータベースをデフォルトの接続先とするかを識別可能に表示することが可能である。一例として、情報処理装置１０１は、データベース設定画面２３０２上で表示アイテム２３０4を表示することによりデフォルトの接続先を識別可能に表示する。

ステップＳ１８１３において、情報処理装置１０１は、上述の各設定に基づいてアプリケーションプログラムを生成する。

次に図２０、図２１、図２２を用いてテストスイートの実行のフロー、各フローにおける画面の表示について説明する。なお、本実施形態においては、図１７を用いて説明したテストスイート生成のフローにおいて、複数のテストスイートが生成されているとする。そのため、以下では、情報処理装置１０１は、複数のテストスイートのテストを並列して同時に実行する場合について説明する。

ステップＳ２００１において、情報処理装置１０１は、テストの実行の開始の指示を受け付ける。具体的には、情報処理装置１０１は、実行ボタン２１０５（図２１）が選択されたことに従い指示を受け付ける。なお、実行されるテストスイートは複数であってもよい。複数のテストスイートを並列に実行することで、１つずつテストする場合よりもテストにかかる工数が短縮される。本実施形態では、情報処理装置１０１は、テスト全体ビュー２１０６（図２１）に表示されたテストスイートを同時に実行するとする。また、情報処理装置１０１は、テスト全体ビュー２１０６に表示されるテストスイート定義のうち、チェックボックス２１１０で選択されたテストスイート定義のみを実行ボタンの選択に従って実行することとしてもよい。

ステップＳ２００２において、情報処理装置１０１は、テスト全体ビュー２１０６（図２１）を表示する。テスト全体ビュー２１０６は、設定されたテストスイート定義４０９の一覧を表示する。そして、テスト全体ビュー２１０６は、実行されたテストの結果を、テストスイート単位で識別可能に表示することが可能である。また、テスト全体ビュー２１０６は、テスト進捗バー２１０７とテスト情報表示部２１０８とを表示する。テスト進捗バー２１０７は、必ずしもバー状のインジケータでなくてもよい。テスト進捗バー２１０７は、例えば、円状のものであってもよい。つまり。テスト進捗バー２１０７は、少なくとも、実行中のテストスイート定義４０９の全工程における進捗の割合を視認可能な情報であればよい。テスト情報表示部２１０８は、実行中のテストスイート定義４０９の進捗および結果をテキストにて表示する。テスト情報表示部２１０８は、例えば、「実行中」、「実行完了」、「エラー」等の表示を含む。

ステップＳ２００３において、情報処理装置１０１は、テスト進捗バー２１０７を空の状態で表示する。つまり、情報処理装置１０１は、テストスイート定義４０９によるテストの進捗が「０」であることを示している。

ステップＳ２００４において、情報処理装置１０１は、テスト情報表示部２１０８にテストは実行中であることを示すための表示をする。本実施形態では、情報処理装置１０１は、テスト情報表示部２１０８に「実行中…」という文字を表示する。

ステップＳ２００５において、情報処理装置１０１は、対象であるテストスイートがなくなるまで以下のステップを繰り返す。

ステップＳ２００６において、情報処理装置１０１は、対象テストスイートのテストスイート定義４０９を読み込む。

ステップＳ２００７において、情報処理装置１０１は、対象テストスイートの数だけスレッドを作成する。複数のテストスイートが実行されるとき、スレッドは複数作成され並列に実行される。情報処理装置１０１は、作成されたスレッドをテスト全体ビュー２１０６に表示する。

ステップＳ２００８において、情報処理装置１０１は、対象テストスイートに含まれるテストケース定義を読み込む。
ステップＳ２００９において、情報処理装置１０１は、ステップＳ２００８で読み込んだテストケースがなくなるまで以下のステップを繰りかえす。

ステップＳ２０１０において、情報処理装置１０１は、読み込んだテスト定義に基づいてテストを実行する。

ステップＳ２０１１において、情報処理装置１０１は、テストの実行状況に応じてテスト進捗バー２１０７を更新する。一つのテスト進捗バーは１つのテストスイートに対してどれだけ作業が完了したかを表す。

ステップＳ２０１２において、情報処理装置１０１は、テストスイート設定画面２２００でテスト結果を表示する。ここで、図２２を用いて、テストスイート定義を用いたテスト結果の表示方法について説明する。テストスイート設定画面２２００は、テストスイート設定画面２１５０でテストの実行の開始がされたテストスイートが終了した際の画面の一例である。図２２において、テスト進捗バー２２０１は、テストが完了したことを示している。本実施形態において、「Suite１.ｗｐｔｘ」のテスト進捗バーは、エラーが発生せずにテストが完了したことを示す。一方、「Suite２.ｗｐｔｘ」のテスト進捗バーは、はエラーが発生してテストが完了したことを示す。テストスイート設定画面２２００に示す通り、それぞれのテストスイート定義の進捗バーは、異なる色で表示されるため、ユーザは、エラーが発生せずにテストが完了したか否かを視認することができる。また、それぞれのテストスイート定義の進捗バーの横に、結果が識別可能なアイコン２２０３が表示される。ユーザは、アイコン２２０３を目視することにより、いずれのテストスイートでエラーが発生したのかを認識することができる。また、それぞれのテストスイート定義に含まれるテストの横に、結果が識別可能なアイコン２２０４が表示される。ユーザは、アイコン２２０４を目視することにより、テストスイートに含まれるテストケースのうちいずれのテストケースでエラーが発生したのかを認識することができる。それぞれのテストケースのステップごとに、テスト結果を識別可能なアイコン２２０５が表示される。ユーザは、アイコン２２０５を目視することにより、テストケースのうちいずれのステップでエラーが発生したのかを認識することができる。

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

以上、上述の実施形態によれば、情報処理装置は、データベース定義からデータベースの選択を受け付け、互いに異なるデータベースを接続先とする複数のテストスイートを生成し、生成された複数のテストスイートに基づいて、選択された接続先のデータベースのデータを用いてアプリケーションに係るテストを実行する。そのため、ユーザがテストスイートごとに接続すべきデータベースを選択可能となる。従って、テストの過程でデータベースのデータの値を変更する場合であっても、複数のテストスイートを並行して同時に実行することができる。つまり、大規模なアプリケーションのテスト工程であっても、正確かつ迅速にテストを実行することができる。

上述の実施形態による効果についてより具体的に説明する。情報処理装置は、複数のテストスイートを並行して同時に実行することでトータルのテスト時間が短縮される。例えば、情報処理装置は、１００００個のテストケースを実行する場合、直列に実行すれば１０時間かかる場合に、１０台の装置で並行して実行すれば、理論上は１時間で完了することができる。ただし、１０台の装置で同じデータベースを利用した場合は、データベース同士のデータの衝突（他のテストの実行によりデータベースが上書きされる等）による問題が発生する。この考え方を適用すると、情報処理装置は、テストスイートごとに接続するデータベースを分けるために、どのテストをどのデータベースに接続するのかを設定することは有用である。また、複数のテストケースのそれぞれに接続先データベースを設定することは煩雑である。そのため、複数のテストケースを目的ごとにまとめたテストスイート定義を用いて、テストスイート単位ごとデータベースの接続先を設定することはより有用である。特に、本件のようなリポジトリ定義をベースとしたアプリケーション開発ツールを用いる場合と異なり、既存のスクラッチ開発で使われるテストスイートクラスは単にテストケースをまとめただけである。したがって、上述の実施形態のように、テストスイート定義に追加の条件を加えられることは効果的である。本実施形態のアプリケーション開発ツールは、テストスイート定義とともにデータベース定義を有しているため、当該データベース定義の中のどのデータベースに接続するのかを選択するだけで容易に設定が可能となる。

また、情報処理装置は、ユーザにより任意のデータベースの選択を受け付けていない場合には、データベース定義のうち初期設定のデータベースを用いてアプリケーションに係るテストを実行する。このため、情報処理装置は、必要に応じて、選択をせずともデータベースを用いたテストスイートの実行が可能となる。そのため、テスト工程におけるユーザの利便性を向上させることができる。

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

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

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

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

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

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

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

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

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

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

Claims (6)

1. アプリケーションを構築する情報処理装置であって、
   前記アプリケーションを構築するためのデータベース定義からデータベースの選択を受け付けるデータベース選択受付手段と、
   前記データベース選択受付手段で選択されたデータベースであって、互いに異なるデータベースを接続先とする複数のテストスイートを生成するテストスイート生成手段と、
   前記テストスイート生成手段により生成された複数のテストスイートに基づいて、前記接続先のデータベースのデータを用いて前記アプリケーションに係るテストを実行するテスト実行手段
   を備えることを特徴とする情報処理装置。
2. 前記アプリケーションを構築するためのデータベース定義のうち初期設定の接続先を記憶するデータベース記憶手段を更に備え、
   前記テスト実行手段は、前記データベース選択受付手段により選択を受け付けていない場合に、前記データベース記憶手段で記憶される初期設定のデータベースのデータを用いて前記アプリケーションに係るテストを実行することを特徴とする請求項１に記載の情報処理装置。
3. 前記テストスイート生成手段により生成されたテストスイートに基づいて、アプリケーションプログラムを生成するアプリケーションプログラム生成手段を更に備えることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記テスト実行手段は、複数の前記テストスイートに基づいて、それぞれ異なる接続先のデータベースのデータを用いて前記アプリケーションに係るテストを実行するテスト実行手段を備えることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. アプリケーションを構築する情報処理装置の制御方法であって、
   前記アプリケーションを構築するためのデータベース定義からデータベースの選択を受け付けるデータベース選択受付工程と、
   前記データベース選択受付工程で選択されたデータベースであって、互いに異なるデータベースを接続先とする複数のテストスイートを生成するテストスイート生成工程と、
   前記テストスイート生成工程により生成された複数のテストスイートに基づいて、前記接続先のデータベースのデータを用いて前記アプリケーションに係るテストを実行するテスト実行工程
   を備えることを特徴とする情報処理装置の制御方法。
6. コンピュータを請求項１乃至４のいずれか１項に記載の情報処理装置として機能させるためのプログラム。
   

Images