以下、本発明の実施の形態を、図面を参照して詳細に説明する。
図1は、本発明に係るシステムの構成図の一例である。
情報処理装置101は、開発者の操作に従って画面レイアウト及びデータベース検索指示などを定義する。情報処理装置101は、アプリケーションのプログラム生成を行う。
なお、本実施形態においては、情報処理装置101で生成するアプリケーションはWebアプリケーションとしたが、これに限定するものではなく、携帯電話・スマートフォン・タブレットなどの情報処理装置で動作するアプリケーションや組込みソフトウェアなど、Web技術による通信を利用するアプリケーションでなくてもよい。
また、本実施形態においては、情報処理装置101はアプリケーションのプログラムを生成するとしたが、この方法に限定するものではなく、プログラムを生成することなく、アプリケーションサーバ102やクラウド環境等でアプリケーションが動作する様にデータやファイル等を生成することにより、アプリケーション(の動作環境)を構築する等であってもよい。
アプリケーションサーバ102は、情報処理装置101で生成され配置されたアプリケーションを実行する。また、アプリケーションサーバ102は、データベースサーバ103に接続し、データベースのデータを操作することができる。
データベースサーバ103は、生成されたアプリケーションが利用するデータベースである。なお、開発時にも動作確認などのために利用してもよい。また、データベースサーバ103は、情報処理装置101や、アプリケーションサーバ102と同一の装置で構成されていてもよいし、LANなどのネットワーク105内に配置されてもよい。
アプリケーションクライアント104は、アプリケーションサーバ102と協調して情報処理装置101で開発したアプリケーションプログラムを動作させる、エンドユーザの操作端末である。この、アプリケーションクライアント104は、携帯端末などの情報処理装置であってもよい。
クラウド環境106は、動的にスケーラブルかつ仮想化されたリソースを供給することが可能な環境である。
クラウド環境106内の仮想アプリケーションサーバ107は、情報処理装置101で生成され配置されたアプリケーションを実行する。また、仮想アプリケーションサーバ107は、仮想データベースサーバ108に接続し、データベースのデータを操作することができる。
クラウド環境106内の仮想データベースサーバ108は、生成されたアプリケーションが利用するデータベースである。なお、開発時にも動作確認などのために利用してもよい。
なお、クラウド環境106は動的にスケーラブルかつ仮想化されたリソースを供給することが可能な環境であるとしたが、本実施形態においては、この特徴を備えている必要はなく、クラウド環境106が仮想アプリケーションサーバ107及び仮想データベースサーバ108の動作を提供するのであれば、動的にスケーラブルでなくても、仮想化されたリソースを供給できなくてもよい。
図2は、本発明に係わる情報処理装置101、アプリケーションサーバ102、データベースサーバ103、アプリケーションクライアント104として適用可能な各ハードウェア構成の一例を示すブロック図である。
図2において、CPU201は、システムバス204に接続される各デバイスを統括的に制御する。
また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるオペレーティングシステム(OS)や、各サーバ、クライアント、装置など情報処理装置の後述する各種機能を実現するためのプログラムが記憶されている。
RAM202は、CPU201の主メモリ、ワークエリア、一時待避領域等として機能する。
入力コントローラ205は、入力部209からの入力を制御する。この入力部209としては、情報処理装置では、キーボード、マウス等のポインティングデバイス、タッチパネルが挙げられる。
なお、入力部209がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下(指等でタッチ)することにより、各種の指示を行うことができることとする。
また、タッチパネルは、マルチタッチスクリーン等の、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
出力コントローラ206は、出力部210の表示を制御する。この出力部210としては、例えば、CRTや液晶ディスプレイ等が挙げられる。尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。また、プロジェクタであってもよいこととする。
外部メモリコントローラ207は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ211へのアクセスを制御する。外部メモリ211には、各サーバ、クライアント、装置等の各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ211としては、ハードディスク(HD)やフレキシブルディスク(FD)、PCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)、スマートメディア等が挙げられる。
なお、CPU201は、例えばRAM202内の表示情報用領域へアウトラインフォント展開(ラスタライズ)処理を実行することにより、出力部210上での表示を可能としている。また、CPU201は、出力部210上の不図示のマウスカーソル等でのユーザ指示を可能とする。
通信I/Fコントローラ208は、ネットワークを介して外部機器との通信制御処理を実行する。例えば、TCP/IPを用いた通信等が可能である。
本発明を実現するためのプログラム212は外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。
図3は、本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。
情報処理装置101は、以下の機能部を備える。
定義情報取得部301は、アプリケーションを構築するための定義情報及び当該定義情報の属性を取得する機能部である。
テストケース雛型作成部302は、定義情報取得部301により取得された定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する機能部である。
指示受付部303は、定義情報を選択する指示を受け付ける機能部である。
テストケース雛型作成部302は、指示受付部303により指示を受け付けた定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する機能部である。
以上で、図3の説明を終了する。
図4は、情報処理装置101、アプリケーションサーバ102及びアプリケーションクライアント104の構成図である。
情報処理装置101は、リポジトリ定義部401及びアプリケーション生成部410を備える。
情報処理装置101は、アプリケーションを開発する開発者により設定されたリポジトリ定義部401の各定義を用いて、アプリケーション生成部410によりアプリケーションを生成する。
リポジトリ定義部401には、アプリケーション定義402、入出力定義403、データモデル定義404、ビジネスプロセス定義405、データベース定義406が記憶されている。これら402~406の定義は、アプリケーション構築ツールを介して、開発者によって入力設定または配置される。
入出力定義403は、アプリケーション画面に配置される各種項目のレイアウトの定義情報を保持する。入出力定義403は、入力項目定義情報及び出力項目定義情報を含む。入力項目定義情報は、生成されたアプリケーションの画面を介して当該アプリケーションのエンドユーザが入力する入力項目を定義した情報である。出力項目定義情報は、生成されたアプリケーションの画面に出力する出力項目を定義した情報である。以降、「入力項目定義情報」及び「出力項目定義情報」をまとめて「入出力項目定義情報」と呼ぶ。
なお、本実施形態においては、「入力項目定義情報は、生成されたアプリケーションの画面を介して当該アプリケーションのエンドユーザが入力する入力項目を定義した情報」「出力項目定義情報は、生成されたアプリケーションの画面に出力する出力項目を定義した情報」としたが、これらに限定するものではなく、例えば、画面を有さないバッチやWebサービス等のように、「入力項目定義情報は、生成されたアプリケーションに入力される入力項目を定義した情報」「出力項目定義情報は、生成されたアプリケーションが出力する出力項目を定義した情報」であってもよい。
データモデル定義404は、データベースのテーブルの項目の定義情報を保持する。入出力定義403の各項目には、データモデル定義404の項目を対応づけることができる。
ビジネスプロセス定義405は、アプリケーションにおけるデータを処理するためのロジックの定義情報を保持する。
データベース定義406は、アプリケーションが接続するデータベースに係る情報(データベースサーバ103のIPアドレス、接続ユーザ、接続パスワード等)を定義する。
アプリケーション生成部410は、アプリケーション生成用のリポジトリ定義解析部411を用いてリポジトリ定義部401に記憶されている各定義を解析し、アプリケーションコード生成部412及びソースコードコンパイル部413を介し、コンパイル済Java(登録商標)コード441及びHTML/JSP/JavaScript(登録商標)442を含むアプリケーションを生成する。すなわち、アプリケーション生成部410は、設定された定義を用いて、アプリケーションとして用いられるプログラムを生成する手段の一例である。
リポジトリ定義エディタ部420は、リポジトリ定義参照部421によってリポジトリ定義部401を解析し、テストケース定義407の場合は、テストケース定義エディタ部422を用いて、それ以外の定義の時はそれぞれに対応したその他定義エディタ部423を用いてリポジトリ定義を変更及び参照する。
テスト実行部430は、テストケース定義受信部431によってテストケース定義407を取得し、テストケース定義解釈部433を用いてその内容を解析する。テスト実行部(インタープリタ)434は、テストケース定義解釈部433を用いて、アプリケーションコードアクセス部436から、アプリケーションコードをテスト実行する。
テスト実行部(インタープリタ)434は、テストケース定義解釈部433を用いて解釈した内容からテスト実行準備部を用いてテストの事前処理を行い、アプリケーションコードアクセス部436を用いてアプリケーションコードをテスト実行する。
テストがすべて完了すると、テスト実行部(インタープリタ)435はテスト終了処理部437を用いてテスト終了処理を行う。
最後に、テスト結果取得部435を用いて、テスト実行の結果を取得し、テスト結果表示部438に表示する。
以上で、図4の説明を終了する。
図5は、アプリケーション生成のフローチャートの一例を示す図である。
情報処理装置101は、ディレクトリ構造を用いて、リポジトリ定義部401の各定義をファイルとして管理する。なお、本実施形態においては、ディレクトリ構造を用いて、リポジトリ定義部401の各定義をファイルとして管理するとしたが、これに限定するものではなく、例えば、データベースを用いてリポジトリ定義部401の各定義を管理してもよいし、クラウドなどネットワーク上の記憶装置を用いて管理する等としてもよい。
アプリケーション生成のフローチャートについて説明する。
ステップS501において、情報処理装置101は、アプリケーション定義402の設定を受け付ける。具体的には、アプリケーション構築ツールの画面を介して、アプリケーション開発者から入出力定義403、データモデル定義404、ビジネスプロセス定義405及びデータベース定義406の設定を受け付ける。
ステップS501にて、受け付けたアプリケーション定義402、入出力定義403、データモデル定義404、ビジネスプロセス定義405及びデータベース定義406の設定は、リポジトリ定義部401にXMLファイル形式で記憶する。
ステップS502において、情報処理装置101は、アプリケーション生成の指示を受け付ける。
ステップS503において、情報処理装置101は、リポジトリ定義部401からアプリケーション定義402を取得する。リポジトリ定義解析部411は、読み込んだ定義を解析したうえでROM203に記憶しておき、解析された定義は各生成部から適宜参照される。
ステップS504において、情報処理装置101は、リポジトリ定義部401からデータモデル定義404を取得する。
ステップS505において、情報処理装置101は、リポジトリ定義部401から入出力定義403を取得する。
ステップS506において、情報処理装置101は、リポジトリ定義部401からビジネスプロセス定義405を取得する。
ステップS507において、情報処理装置101は、リポジトリ定義部401からデータベース定義406を取得する。すなわち、ステップS501~S507は、アプリケーションを構築するための定義情報を取得する処理の一例を示すステップである。
ステップS508において、情報処理装置101は、アプリケーション生成部410を用いて、Webアプリケーションに用いるプログラムを生成する。すなわち、ステップS508は、アプリケーションのプログラムを生成する処理の一例を示すステップである。また、ステップS508は、アプリケーションを構築する処理の一例を示すステップである。
ステップS509において、情報処理装置101は、テストケース定義を生成する(詳細は、図7の説明にて後述する)。すなわち、ステップS509は、取得された定義情報を用いて、テストケースを生成する処理の一例を示すステップである。また、ステップS509は、受け付けた定義に基づき、テストケースを生成する処理の一例を示すステップである。
ステップS510において、情報処理装置101は、ステップS509にて生成したテストケース定義に用いてテストを実行する(詳細は、図8の説明にて後述する)。すなわち、ステップS510は、定義情報を用いて生成されたテストケースに基づき、アプリケーションに係るテストを実行する処理の一例を示すステップである。また、ステップS510は、定義情報を用いて生成されたテストケースに基づき、定義情報が正しく定義されているか否かテストを実行する処理の一例を示すステップである。また、ステップS510は、定義情報を用いて生成されたテストケースに基づき、定義情報に係るテストを実行する処理の一例を示すステップである。
この段階ではアプリケーションをアプリケーションサーバ102に配置(デプロイ)していないため、以上により、アプリケーションサーバ102を用意することなく、テストを実行することができる。
また、以上により、アプリケーションアーカイブファイルの生成、アプリケーションサーバ102への転送、デプロイをすることなく、テストを実行することができるため、テストにかかる時間を削減することができ、開発とテストをシームレスに何度も繰り返すことができる。
また、以上により、情報処理装置101だけでアプリケーションサーバ102にて動作するアプリケーションのテストを実行することができるため、複数人の開発者が同時に並行してテストを行うことができる。
ステップS511において、情報処理装置101は、ステップS510にて実行したテストにおける失敗したテストケースの有無を判定し、有る場合は本フローチャートを終了し、無い場合はステップS512に進む。すなわち、ステップS511は、テストの結果に従って、アプリケーションの構築をする/しないを制御する処理の一例を示すステップである。
ステップS512において、情報処理装置101は、ステップS508にて生成したプログラムをアプリケーションサーバ102に配置(デプロイ)する。
これにより、失敗テストが無い状態のアプリケーションをサーバに構築する仕組みを提供することができる。よって、テストに時間がかかってしまう場合、夜間にテストを実行させ、テストが成功した場合は、続けてアプリケーションサーバ102にデプロイさせておくことができるため、アプリケーション管理者や運用者の手間を軽減することができる。
また、失敗テストが有る状態のアプリケーションはサーバに構築することが無くなるため、不具合を含んだアプリケーションをリリースすることがなくなり、アプリケーションが不整合なデータを出力することもなくなるため、結果として、信頼性の高いアプリケーションを運用することができ、エンドユーザの満足度も向上させることができる。
以上で、図5の説明を終了する。
以上により、アプリケーションプログラム生成、テスト実行、デプロイ等の処理を1つの指示で行うことができる。よって、アプリケーション構築ツールにおいて、テストを効率的に行う仕組みを提供することができる。
図7は、テストケース定義生成のフローチャートの一例を示す図である。
ステップS701において、情報処理装置101は、ユーザからのテストケース定義生成の指示を受け付ける。具体的には、新規テストケース作成メニュー1101(図11)の押下を受け付ける。
ステップS702において、情報処理装置101は、外部メモリ211にアプリケーション定義402が作成済か否かを判定する。作成済の場合はステップS703に進み、未作成の場合は本フローチャートを終了する。
ステップS703において、情報処理装置101は、新規テストケース作成ダイアログ1102(図11)を表示し、新規のテストケースの生成に必要な「コード名」「名前」「対象アプリケーション1103」の入力を受け付け、受け付けた情報に基づき、外部メモリ211にテストケース定義407を新規に作成する。
ステップS704において、情報処理装置101は、ステップS703にて作成されたテストケースのテスト手順を入力するためのテスト手順入力画面1201(図12)表示する。この時点では、テストケースにテスト手順が登録されていない状態であるため、テスト手順入力画面1201の「テスト手順」タブを選択した場合、テスト手順を設定するエディタ部には何も表示されていない。
ステップS705において、情報処理装置101は、ステップS703にて入力を受け付けた「対象アプリケーション1103」に属す入出力定義403を外部メモリ211から取得する。すなわち、ステップS705は、アプリケーションを構築するための定義情報を取得する処理の一例を示すステップである。
ステップS706において、情報処理装置101は、登録するテスト手順の数だけステップS707~S712を繰り返す。
ステップS707において、情報処理装置101は、テスト実行時に疑似的に行う命令の選択を受け付ける。命令の種類は、例えば、「画面表示」「行追加」「項目値入力」「項目値検証」等がある。
通常、スクラッチ開発によって構築されたアプリケーションのテストは、テスト要員による「画面表示」「行追加」「項目値入力」等の操作及び目視による「項目値検証」を必要とするが、本実施形態におけるテストは、テスト要員が行う操作及び目視をステップS707にて「命令」として手順化しておき、構築又は生成されたアプリケーションプログラムに対して(テスト要員が操作を行ったかのように疑似的に)「命令」を実行することで、テストの実行及び検証が自動でできる。
なお、本実施形態においては、命令の種類は上記4種類の中から選択を受け付けるとしたが、この4種類に限定するものではなく、その他の命令(例:キーボード・マウス・タッチパネル等の入力装置による操作、カメラ等の周辺機器の操作、音声入力、ブラウザ操作、n秒待機、不正な操作等)を選択できるとしてもよい。
ステップS708において、情報処理装置101は、ステップS705にて取得した入出力定義403に基づき、「対象アプリケーション1103」に属す入出力定義403を選択肢として表示する(図12の1203)。
ステップS709において、情報処理装置101は、ステップS708にて表示した選択肢から、テスト実行に用いる入出力定義403の選択を受け付ける。
ステップS710において、情報処理装置101は、ステップS709にて選択を受け付けた入出力定義403に属す入出力項目を選択肢として表示する(図12の1204)。例えば、ステップS707にて、命令に「項目値入力」が選択された場合は、入出力項目のうち値を入力できる項目だけに絞った選択肢を表示する。
ステップS711において、情報処理装置101は、ステップS710にて表示した選択肢から、テスト実行に用いる入出力項目の選択を受け付ける。
ステップS712において、情報処理装置101は、テストの命令実行時に用いる入出力項目への引数の入力を受け付ける。なお、「引数」とは、テスト手順を実行するときに、入出力定義などの定義情報に対して設定するテストデータのことである。
例えば、図12では、グループ項目「G ユーザマスタ」の入出力項目「ID」「パスワード」「名前」への引数を入力する。グループ項目とは、入出力項目を複数持つ表である(例:図6の602)。この命令に、行番号と引数を入力したものを1302(図13)に示す。1302(図13)は、グループ項目における明細「1」行目の入出力項目「ID」「パスワード」「名前」にそれぞれ「1」「yamada」「山田」を入力するという意味である。
また、命令が「項目値検証」の場合の引数は、その「入出力項目」の値が、テスト実行時にその「引数」の値と等しいか否かを判定するという意味である(図13の1303)。ここでは、1302にて「項目値入力」を行い、「アクション実行」でUPDATE(更新)処理を行った後において、「ID」の値が「1」と等しいか否かを判定する。つまり、その時点で「ID」=1の場合は、そのテスト手順=成功と判定し、「ID」≠1の場合は、そのテスト手順=失敗と判定する(詳細は、図9のステップS911にて後述する)。
なお、本実施形態においては、「引数」の例として「入出力項目の値」を挙げたが、「入出力項目の値」に限定するものではなく、「引数」は、例えば、画面の入出力に係る位置、色、大きさ又は内容等に係る情報であってもよい。また、表示、認証、検索、追加、更新若しくは削除等の処理に対して与える情報、又は、カメラ等の周辺機器に対して送信する情報等、テスト実行のために用いる情報であれば、その他の情報であってもよい。
すなわち、ステップS712は、実行されるテストに用いる情報を受け付ける処理の一例を示すステップである。また、ステップS712は、取得された定義情報に含まれる項目に対して代入する値の入力を受け付ける処理の一例を示すステップである。また、ステップS712は、取得された定義情報に含まれる項目が持つと予想される値の入力を受け付ける処理の一例を示すステップである。
すなわち、ステップS706~S712は、テストケースの定義を受け付ける処理の一例を示すステップである。
ステップS713において、情報処理装置101は、ステップS706~S712を繰り返すことによって作成されたテストケース手順(例:図13の1301)に基づき、図21のようなテストケース定義407を生成し、外部メモリ211に記憶する。
具体的には、テストケース手順1301を1つずつ、テストケース定義407の要素<autotest-step>に変換することにより、テストケース定義407を生成する。同様に、テストケース手順1301の「命令」はテストケース定義407の要素<command>に、「入出力」は<object_01>に、「入出力項目」は<object_02>に、「行番号」は<object_03>に、「引数」は<argument>にそれぞれ変換する。
なお、本実施形態においては、テストケース定義407を図21のようなXMLファイルとしたが、XMLファイルに限定するものではなく、その他の形式のファイルとして生成したり、データベースに記憶させたり、ファイルやデータベース以外の情報として生成したりしてもよい。
すなわち、ステップS713は、取得された定義情報を用いて、テストケースを生成する処理の一例を示すステップである。また、ステップS713は、受け付けた定義に基づき、テストケースを生成する処理の一例を示すステップである。また、ステップS713は、受け付けた値を項目に対して代入することを含むテストケースを生成する処理の一例を示すステップである。また、すなわち、ステップS713は、受け付けた値と項目が持つ値とを比較することを含むテストケースを生成する処理の一例を示すステップである。
以上で、図7の説明を終了する。
以上により、アプリケーションを構築するための定義情報を用いて、アプリケーションに係るテストケースを容易に生成することができる。また、アプリケーションを構築するための定義情報を用いて、定義情報が正しく定義されているか否かテストするためのテストケースを容易に生成することができる。
つまり、アプリケーション開発者は、テストを実行するプログラム(テストスクリプト)を記述する必要がないため、テストに係る工数を削減することができ、テストを効率的に行うことができる。よって、プログラミング知識のないアプリケーション開発者であっても、定義情報さえ理解できれば、アプリケーションに係るテストケースを容易に生成することができる。
図8、図9及び図10は、テスト実行のフローチャートの一例を示す図である。
ステップS800において、情報処理装置101は、ブレークポイントを設定する指示を受け付ける。具体的には、ブレークポイントを設定するボタン1601(図16)の押下を受け付け、受け付けた「命令1602」(例:アクション実行)に対しブレークポイントを設定したブレークポイント定義461をRAM202に記憶する。すなわち、ステップS800は、生成されたテストケースに対して、ブレークポイントの設定を受け付ける処理の一例を示すステップである。
ステップS801において、情報処理装置101は、テスト実行指示又はデバッグ実行指示を受け付ける。具体的には、実行メニュー1401(図14)又はデバッグ実行メニュー1408(図14)の押下を受け付ける。
ステップS802において、情報処理装置101は、テスト実行対象のテストケース定義に係るアプリケーション1103(図11)のアプリケーションコード440が作成済か否かを判定する。作成済の場合はステップS803に進み、未作成の場合は本フローチャートを終了する。
ステップS803において、情報処理装置101は、テスト実行部(インタープリタ)434とテストケース定義解釈部433を用いて、ステップS801で実行メニュー1401の押下時に選択されていたテストケースに対応するテストケース定義407を外部メモリ211から取得する。
ステップS804において、情報処理装置101は、テスト実行部(インタープリタ)434とテストケース定義解釈部433を用いて、ステップS803にて取得したテストケース定義407に含まれるテストケース数及びテスト手順数をカウントする。
ステップS805において、情報処理装置101は、テストビュー1403(図14)を表示する。
ステップS806において、情報処理装置101は、テスト進捗バー1404(図14)を空の状態で表示する。
ステップS807において、情報処理装置101は、テスト情報のテストツリーペイン1406(図14)に、ステップS803及びステップS804でテスト対象としたテストケース名(例:ユーザ登録フォームチェック、商品登録フォームチェック)及びテスト手順(1.画面表示、2.行追加、3.…)を表示する。
ステップS808において、情報処理装置101は、テスト情報の詳細ペイン1407(図14)にメッセージ「実行中…」を表示する。
ステップS809において、情報処理装置101は、テスト実行準備部432を用いて、テスト実行前準備を行う。具体的には、テスト実行前準備では、セッション、クッキー及びスレッド等の生成を行い、ユーザが実際にブラウザを用いてアプリケーションを実行した場合と同様のアプリケーションデータを生成する。これにより、ブラウザ、エンドユーザ操作及びアプリケーションサーバ等を用いなくても、アプリケーション構築ツールにおいて、テストを効率的に行うことができる。
ステップS901において、情報処理装置101は、テスト実行対象のテストケースの分だけ、ステップS902~S1001を繰り返す。
ステップS902において、情報処理装置101は、テスト実行対象のテストケースのテスト手順の分だけ、ステップS903~S915、S921又はS925を繰り返す。
ステップS903において、情報処理装置101は、強制終了ボタン1405(図14)の押下を受け付けたか否かを判断し、押下された場合はステップS904へ進み、押下されていない場合はステップS905へ進む。
ステップS904において、情報処理装置101は、テスト進捗バー1404を灰色100%で更新し、未実行のテストケース又はテスト手順がある場合であっても中断し、本フローチャートを終了する。
ステップS905において、情報処理装置101は、テストケース定義解釈部433を用いて、テスト手順情報1203を取得する。
ステップS906において、情報処理装置101は、テスト手順情報のテスト命令が入力系か否かを判定し、入力系の場合はステップS907へ進み、入力系でない場合はステップS908へ進む。
ステップS907において、情報処理装置101は、アプリケーションコードアクセス部436を用いて、生成済のアプリケーションコード440へ疑似的に値の入力を実行する。その後、アプリケーションコードアクセス部を用いて、アプリケーションコード440から実行結果を受け取り、テスト結果取得部435を用いてテスト結果を得る。すなわち、ステップS907は、ステップS712にて受け付けた情報を用いて、テストを実行する処理の一例を示すステップである。
ステップS908において、情報処理装置101は、テスト手順情報のテスト命令が実行系か否かを判定し、実行系の場合はステップS909へ進み、実行系でない場合はステップS910へ進む。
ステップS909において、情報処理装置101は、アプリケーションコードアクセス部436を用いて、生成済のアプリケーションコード440へ疑似的にアクションを実行するリクエストを送る。その後、アプリケーションコードアクセス部436を用いて、アプリケーションコード440から実行結果を受け取り、テスト結果取得部435を用いてテスト結果を得る。
ステップS910において、情報処理装置101は、アプリケーションコードアクセス部436を用いて、生成済のアプリケーションコード440から検証対象の情報を取得する。
ステップS911において、情報処理装置101は、検証対象の情報(検証対象が定義情報に含まれる項目である場合、当該項目に係る情報(例;当該項目が持つ値や属性値))が条件(例;ステップS712にて入力を受け付けた引数の値)に合致するか否かを判定し、検証が成功(条件に合致する)の場合はステップS916へ進み、失敗(条件に合致しない)の場合はステップS912へ進む。
例えば、図13の1303の場合、1302にて「項目値入力」を行い、「アクション実行」でUPDATE(更新)を行った後において、「ID」の値が「1」と等しいか否かを判定する。つまり、その時点で「ID」=1の場合は、そのテスト手順=“成功”と判定し、「ID」≠1の場合は、そのテスト手順=“失敗”と判定する。
なお、本実施形態においては、検証系の例として「項目値検証」を挙げたが、項目値に限定するものではなく、例えば、表示するオブジェクトやメッセージの表示位置、色、大きさ又は表示内容等の検証であってもよい。また、表示、認証、検索、追加、更新若しくは削除等の処理にかかった時間、CPUの使用率、記憶領域の空き容量、又は、カメラ等の周辺機器から取得可能な情報等、テスト実行時に取得可能な情報に係る検証であれば、その他の検証であってもよい。
すなわち、ステップS911は、ステップS712にて受け付けた情報を用いて、テストを実行する処理の一例を示すステップである。また、ステップS911は、受け付けた値と項目が持つ値とを比較した結果に基づいて、実行されるテストの成否を判定する処理の一例を示すステップである。
ステップS912において、情報処理装置101は、テスト手順のステータスを“失敗”としてRAM202に記憶する。
ステップS913において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、検証失敗数を更新する(図15の1503)。
ステップS914において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、テスト手順数を更新する(図15の1502)。
ステップS915において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、進捗バーを赤色で更新する(図15の1505)。
ステップS916において、情報処理装置101は、アプリケーションエラーが発生していないことを確認する。発生していなければステップS922へ進み、エラーが発生している場合は、ステップS917へ進む。
ステップS917において、情報処理装置101は、テスト手順のステータスを“テスト失敗”としてRAM202に記憶する。
ステップS918において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、テスト失敗数を更新する(図15の1504)。
ステップS919において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、テスト手順数を更新する(図15の1502)。
ステップS920において、情報処理装置101は、テスト結果取得部435及びテスト結果表示部438を用いて、進捗バーを赤色で更新する(図15の1505)。
ステップS921において、情報処理装置101は、テスト結果表示部438を用いて、テストケース数を更新する(図15の1501)。その後、未実施のテスト手順が実行中のテストケースに含まれている場合であっても、それらの実行はせず、次に実行予定のテストケースを実行する。ステップS902に戻る。
ステップS922において、情報処理装置101は、テスト手順のステータスを“成功”として登録する(図15の1507)。
ステップS923において、情報処理装置101は、テスト結果表示部438を用いて、テスト手順数を更新する(図15の1502)。
ステップS924において、情報処理装置101は、これまでのテスト手順のステータスにテスト失敗及び検証失敗の両方が0件であるか否かを判定し、正の場合はステップS925に進み、偽の場合はステップS925を行わない。
ステップS1001において、情報処理装置101は、テスト結果表示部438を用いて、テストケース数を更新する(図15の1501)。
ステップS1002において、情報処理装置101は、テスト終了処理部437を用いて、テスト実行を終了する。具体的には、テスト実行終了処理では、ステップS809にて生成したセッション、クッキー及びスレッド等をクローズする。
ステップS1003において、情報処理装置101は、テスト結果表示部438を用いて、テスト実行時間を更新する(図15の1506)。
ステップS1004において、情報処理装置101は、テスト結果取得部435とテスト結果表示部438を用いて、テスト中に出力されるログをアプリケーションログビューに表示する(図15の1509)。
以上により、テスト対象の画面や処理に到達するまでに必要な画面や処理(例えば、ログイン処理やメニュー画面等)がテストできる程度に構築されていない状態であっても、アプリケーション構築ツールにおいて、テスト対象の定義についてのみテストを行うことができるため、テストを効率的に行うことができる。つまり、早い段階でテスト工程を開始することができるため、高品質なアプリケーションを構築することができる。
以上で、図8、図9及び図10の説明を終了する。
図19は、入出力定義及びアプリケーション画面の一例を示す図である。
入出力定義1910は、テストケース定義407のテスト手順を作成するために用いる入出力定義403の一例である。この入出力定義1910を用いて出力される画面がアプリケーション画面1920である。
ここで、入出力定義1910の「項目タイプ」について説明しておく。
・I(入力)…値を表示せず、入力を受け取るのみの項目。データモデルに結びついていれば、データベースの値は表示しないが、入力値でデータベースを更新することができる。
・O(出力)…値を表示するが、変更できない項目。データモデルに結びついていれば、データベースの値を表示するが、更新することはできない。
・IO(入出力)…値を表示し、変更を受け取ることができる項目。データモデルに結びついていれば、データベースの値を表示し、入力値でデータベースを更新することができる。
・G(グループ)…一覧画面作成やグラフ作成のため、I(入力)・O(出力)・IO(入出力)等の項目のグルーピングを行う概念的な項目。
・A(アクション)…ビジネスプロセス起動、画面遷移などを定義する項目。画面には、ボタン、リンク、タブとして表示される。
図16は、テストケース雛型のフローチャートの一例を示す図である。
ステップS1601において、情報処理装置101は、テスト手順追加ダイアログを表示する。具体的には、テストケース定義画面2010(図20)において右クリック操作を受け付けると、ポップアップメニュー2011を表示し、入出力からテスト手順を追加ボタン2012の押下を受け付けると、入出力定義情報に基づきテストケースの雛型を生成するための追加ダイアログ2013を表示する。
ステップS1602において、情報処理装置101は、入出力定義及び追加命令の選択を受け付ける。具体的には、ステップS1601にて表示された入出力からテスト手順を追加ダイアログ2013において、テスト手順を追加するためのベースとなる入出力定義403(以下、「対象入出力2014」と記す)の選択、テスト手順として追加する命令(以下、「追加命令2015」と記す)の選択及びOKボタン2016の押下を受け付ける。すなわち、ステップS1602は、定義情報を選択する指示を受け付ける処理の一例を示すステップである。これにより、テストケース作成者が所望するテストケースの雛型を容易に作成することができる。
ステップS1603において、情報処理装置101は、ステップS1602にて受け付けた「対象入出力2014」の入出力定義403をリポジトリ定義部401から取得し、RAM202に記憶する。すなわち、ステップS1603は、アプリケーションを構築するための定義情報及び当該定義情報の属性を取得する処理の一例を示すステップである。
ステップS1604において、情報処理装置101は、ステップS1602にて受け付けた「追加命令2015」のうち、「画面表示」が選択されているか判定する。選択されている場合はステップS1605に進み、選択されていない場合はステップS1606に進む。
ステップS1605において、情報処理装置101は、テストケース定義407のテスト手順として、「対象入出力2014」を表示する画面表示命令を追加する。具体的には、テストケース定義407にテスト手順{「命令」=“画面表示”、「入出力」=対象入出力2014}を追加する(図20の2021)。すなわち、ステップS1605は、取得された定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する処理の一例を示すステップである。
ステップS1606において、情報処理装置101は、ステップS1602にて受け付けた「追加命令2015」のうち、「項目値入力」が選択されているか判定する。選択されている場合はステップS1607に進み、選択されていない場合はステップS1608に進む。
ステップS1607において、情報処理装置101は、項目値入力命令作成(図17)を行う。すなわち、ステップS1607は、取得された定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する処理の一例を示すステップである。
ステップS1608において、情報処理装置101は、ステップS1602にて受け付けた「追加命令2015」のうち、「アクション実行」が選択されているか判定する。選択されている場合はステップS1609に進み、選択されていない場合はステップS1610に進む。
ステップS1609において、情報処理装置101は、アクション実行命令作成(図18左)を行う。すなわち、ステップS1609は、取得された定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する処理の一例を示すステップである。
ステップS1610において、情報処理装置101は、ステップS1602にて受け付けた「追加命令2015」のうち、「項目値検証」が選択されているか判定する。選択されている場合はステップS1611に進み、選択されていない場合は本フローチャートを終了する。
ステップS1611において、情報処理装置101は、項目値検証命令作成(図18右)を行う。すなわち、ステップS1611は、取得された定義情報及び当該定義情報の属性に基づき、テストケースの雛型を作成する処理の一例を示すステップである。
以上で、図16の説明を終了する。
以上により、アプリケーション構築ツールにおいて、テストケースを容易に作成することができる。また、テストケース作成者が所望するテストケースの雛型を、定義情報及び当該定義情報の属性に基づき、容易に作成することができる。
図17は、項目値入力命令作成のフローチャートの一例を示す図である。
ステップS1701において、情報処理装置101は、対象入出力2014の入出力定義403の項目の数だけ、ステップS1702~ステップS1707の処理を繰り返す。
ステップS1702において、情報処理装置101は、対象項目の項目タイプがG(グループ項目)か否かを判定する。項目タイプがGの場合はステップS1703に進み、項目タイプがGでない場合はステップS1704に進む。
ステップS1703において、情報処理装置101は、対象項目がグループ項目であり、グループ項目は“行”という概念を持つため、テストケース定義407のテスト手順として、行追加命令を追加する。具体的には、テストケース定義407にテスト手順{「命令」=“行追加”、「入出力」=対象入出力2014、「入出力項目」=対象項目名(グループ名)}を追加する(図20の2023)。これにより、テスト手順内でアプリケーション画面1920が明細行を持つ一覧画面であっても、明細行を追加する操作(図19の+ボタン1921の押下)を自動に行い、テストを実行することができる。
ステップS1704において、情報処理装置101は、対象項目の項目タイプがI又はIOか否かを判定する。項目タイプがI又はIOの場合はステップS1705に進み、項目タイプがI又はIOのどちらでもない場合はステップS1706に進む。
ステップS1705において、情報処理装置101は、テストケース定義407のテスト手順として、対象項目の項目値入力命令を追加する。具体的には、テストケース定義407にテスト手順{「命令」=“値項目入力”、「入出力」=対象入出力2014、「入出力項目」=対象項目名}を追加する(図20の2022)。これにより、テスト手順内でアプリケーション画面1920の入力項目について値入力の操作を自動に行い、テストを実行することができる。
ステップS1706において、情報処理装置101は、対象項目が一覧項目か否かを判定する。一覧項目の場合はS1707に進み、一覧項目でない場合はS1708に進む。
ステップS1707において、情報処理装置101は、一覧項目の明細1行目のテストデータとするために、行番号に1を設定する。具体的には、ステップS1705にて追加したテスト手順の「行番号」=“1”を設定する(図20の2024)。これにより、テスト手順内でアプリケーション画面1920に明細行がある場合であっても、明細項目の入力項目について値入力の操作を自動に行い、テストを実行することができる。
以上で、図17の説明を終了する。
図18は、アクション実行命令作成及び項目値検証命令作成のフローチャートの一例を示す図である。
アクション実行命令作成のフローチャートについて説明する。
ステップS1811において、情報処理装置101は、対象入出力2014の入出力定義403の項目の数だけ、ステップS1812~ステップS1815の処理を繰り返す。
ステップS1812において、情報処理装置101は、対象項目の項目タイプがA(アクション)か否かを判定する。項目タイプがAの場合はステップS1812に進み、項目タイプがGでない場合はステップS1814に進む。
ステップS1813において、情報処理装置101は、テストケース定義407のテスト手順として、対象項目のアクション実行命令を追加する。具体的には、テストケース定義407にテスト手順{「命令」=“アクション実行”、「入出力」=対象入出力2014、「入出力項目」=対象項目名}を追加する(図20の2025)。これにより、テスト手順内でアプリケーション画面1920のアクション(ボタン、リンク、タブ等)の操作を自動に行い、テストを実行することができる。
ステップS1814において、情報処理装置101は、対象項目が一覧項目か否かを判定する。項目が一覧項目の場合はステップS1815に進み、項目タイプが一覧項目でない場合はステップS1816に進む。
ステップS1815において、情報処理装置101は、一覧項目の明細1行目のテストデータとするために、行番号に1を設定する。具体的には、ステップS1814にて追加したテスト手順の「行番号」=“1”を設定する(不図示)。これにより、アプリケーション画面1920に明細行にアクション(ボタン、リンク、タブ等)がある場合であっても、テスト手順内で明細行のアクションの操作を自動に行い、テストを実行することができる。
以上で、アクション実行命令作成のフローチャートの説明を終了する。
項目値検証命令作成のフローチャートについて説明する。
ステップS1821において、情報処理装置101は、対象入出力2014の入出力定義403の項目の数だけ、ステップS1822~ステップS1825の処理を繰り返す。
ステップS1822において、情報処理装置101は、対象項目の項目タイプがI、O又はIOか否かを判定する。項目タイプがI、O又はIOの場合はステップS1822に進み、項目タイプがI、O又はIOのいずれでもない場合はステップS1824に進む。
ステップS1823において、情報処理装置101は、テストケース定義407のテスト手順として、対象項目の項目値検証命令を追加する。具体的には、テストケース定義407にテスト手順{「命令」=“項目値検証”、「入出力」=対象入出力2014、「入出力項目」=対象項目名}を追加する(図20の2026)。これにより、アプリケーション画面1920の入出力項目について値検証のテストを行うことができる。
ステップS1824において、情報処理装置101は、対象項目が一覧項目か否かを判定する。項目が一覧項目の場合はステップS1825に進み、項目タイプが一覧項目でない場合はステップS1826に進む。
ステップS1825において、情報処理装置101は、一覧項目の明細1行目の値を検証するために、行番号に1を設定する。具体的には、ステップS1824にて追加したテスト手順の「行番号」=“1”を設定する(図20の2027)。これにより、アプリケーション画面1920に明細行がある場合であっても、明細項目の入出力項目について値検証のテストを自動で行うことができる。
以上で、項目値検証命令作成のフローチャートの説明を終了する。
以上で、図18の説明を終了する。
以上により、アプリケーション構築ツールにおいて、テストケースを作成するために、当該プログラムの外部仕様を改めて入力することなく、テストケースを容易に作成することができる。また、テストケースを新規に作成する場合であっても、テストケース作成者が命令やテスト対象項目を選択することなく、テスト手順を作成できるため、テストケース作成にかかる時間を大幅に削減することができ、更にテスト項目の漏れを低減させることもできる。
なお、本実施形態のようなアプリケーション構築ツールにおいては、構築されたアプリケーション又は生成されたそのプログラムが正しく動作するかのテストよりも、アプリケーションを構築するために設定した定義情報が予想通りに設定されているかのテストをすべきである。
つまり、アプリケーション構築ツールによるアプリケーション構築又はプログラム生成そのものは信頼すべきであり、構築又は生成の基となった(アプリケーション開発者が設定した)定義情報についての正否についてテストすべきである。そのため、本発明が有効である。
以上により、アプリケーション構築ツールにおいて、アプリケーションを構築する又はプログラムを生成するために設定した定義情報が正しく定義されているかについて、テストを行うことができる。つまり、これにより、アプリケーション構築ツールにおいて、テスト対象を定義情報に絞ったテスト行うことができるため、テストを効率的に行うことができる。
勿論、本実施形態により生成したテストケースを用いて、テスト対象を定義情報に絞ったテストを行うだけでなく、構築又は生成したアプリケーションを動作させてテストを行うことで、アプリケーション全体までテスト対象を広げたテスト(総合テスト)を行うとしてもよい。
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(又はCPUやMPU)が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD-ROM、CD-R、DVD-ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク等を用いることが出来る。
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、OS(オペレーティングシステム)に供給されるスクリプトデータ等の形態から成ってもよい。
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。