JP2016071396A - テスト実行装置、テスト実行方法およびコンピュータプログラム - Google Patents

Abstract

【課題】定期的に実行されるバッチ処理の完了をオンライン処理の開始条件とするシステムを自動テストする場合に、テストの失敗を回避しつつテスト効率の低下を抑制する。
【解決手段】テスト対象システム１２は、入力された業務イベントの処理を、複数の工程に亘る処理を経て完了するシステムであり、業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行するバッチ処理が終了した場合に、業務イベントに対する第２工程のオンライン処理を許可する。テスト実行装置１０は、業務イベントに対する第１工程のオンライン処理をテスト対象システム１２に実行させる。テスト実行装置１０は、テスト対象システム１２の所定の記憶領域に上記バッチ処理の終了を示す情報が記録されたことを検出した場合に、業務イベントに対する第２工程のオンライン処理をテスト対象システム１２に実行させる。
【選択図】図１３

Description

本発明はデータ処理技術に関し、特に情報システムをテストする技術に関する。

情報システムの品質を保証する上で、サービス開始前の動作テストは不可欠である。例えば、情報システムの開発者が情報システムのユーザインタフェースを手動操作し、その操作結果を確認することにより動作テストを実行することが多い。しかし、操作のバリエーションが豊富な近年の情報システムでは、手動による動作テストには限界がある。

本出願人は、情報システムの動作テストを自動化し、効率的な動作テストを実現するための技術を提案している（例えば特許文献１参照）。

国際公開第２０１０／１１６５８６号

情報システムが様々な業務を支援する現在、テスト対象となる情報システムが、機能が異なる工程が連なって業務フローを形成する情報システムである場合がある。このような情報システムの中には、定期的に実行されるバッチ処理（以下「定期バッチ」とも呼ぶ。）が完了したことを条件として、クライアントからのオンライン処理を許可するものもある。

このような情報システムのオンライン処理をテストする場合に、定期バッチが未完了であると、情報システムがオンライン処理を受け付けず、テストが異常終了してしまう。また、定期バッチが完了することが見込まれる一定時間、オンライン処理のテスト開始を留保することも考えられるが、定期バッチ終了後の余分な時間まで待機することになりテスト効率が低下してしまう。また、指定された一定時間以内に定期バッチが完了しないと、やはりテストが異常終了してしまう。

本発明は発明者の上記課題認識にもとづきなされたものであり、その主な目的は、定期的に実行されるバッチ処理の完了をオンライン処理の開始条件とするシステムを自動テストする場合に、テストの失敗を回避しつつテスト効率の低下を抑制するための技術を提供することにある。

上記課題を解決するために、本発明のある態様のテスト実行装置は、入力された業務イベントの処理を複数の工程を経て完了するシステムをテストする装置であって、業務イベントに関して予め定められた情報を第１工程の画面へ自動入力し、業務イベントに対する第１工程のオンライン処理をシステムに実行させるテスト実行部と、システムが、業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行すべき所定のバッチ処理を実行し、そのバッチ処理の終了を示す情報を所定の記憶領域へ格納した場合に、その事実を検出する検出部と、を備える。テスト実行部は、事実が検出された場合に、業務イベントに関して予め定められた情報を第１工程の次の第２工程の画面へ自動入力し、業務イベントに対する第２工程のオンライン処理をシステムに実行させる。

本発明の別の態様は、テスト実行方法である。この方法は、入力された業務イベントの処理を複数の工程を経て完了するシステムをテストする装置が、業務イベントに関して予め定められた情報を第１工程の画面へ自動入力し、業務イベントに対する第１工程のオンライン処理をシステムに実行させるステップと、システムが、業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行すべき所定のバッチ処理を実行し、そのバッチ処理の終了を示す情報を所定の記憶領域へ格納した場合に、その事実を検出するステップと、事実が検出された場合に、業務イベントに関して予め定められた情報を第１工程の次の第２工程の画面へ自動入力し、業務イベントに対する第２工程のオンライン処理をシステムに実行させるステップと、を実行する。

なお、以上の構成要素の任意の組合せ、本発明の表現を、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、定期的に実行されるバッチ処理の完了をオンライン処理の開始条件とするシステムを自動テストする場合に、テストの失敗を回避しつつテスト効率の低下を抑制することができる。

情報システムのテストの流れを模式的に示す図である。 テストの証跡の取得方法を模式的に示す図である。 第１の実施の形態における総合テストのシステム構成を示す図である。 図３のテスト実行装置の構成を示すブロック図である。 テスト対象システムが提供する画面例を示す図である。 図５の画面に対して作成されたアクションシートを示す図である。 図６のアクションシートに対して作成されたデータシートを示す図である。 テストシナリオの種類を示す図である。 工程別シナリオシートの例を示す図である。 工程別複数シナリオ実行シートの例を示す図である。 複数工程テスト実行シートの例を示す図である。 テスト対象システムの総合テストの実施例を示す図である。 第２の実施の形態における総合テストのシステム構成を示す図である。 業務イベント工程状況テーブルの構成を示す図である。 図１３のテスト実行装置の構成を示すブロック図である。 図１５の業務イベント工程ＩＤ保持部が保持するデータを示す図である。 テスト対象システムが提供する画面例を示す図である。 第３の実施の形態のテスト実行装置の機能構成を示すブロック図である。 アクションシートを示す図である。 データシートを示す図である。 シナリオシートを示す図である。

（第１の実施の形態）
まず、第１の実施の形態のテスト実行装置について、その主な特徴を説明する。
（特徴１）
図１の（ａ）で示すように、開発責任者が異なる複数の工程が連なって業務フローを形成する情報システムの総合テストにおいては、１つのテストケース（例えば特定の業務イベントデータ）を複数の工程に跨って消化することが一般的であった。言い換えれば、複数の開発責任者の責任範囲に跨る業務フロー全体を単位としたテストを実施し、そのテスト結果にもとづいて情報システムの正常性を判断し、例えば仕様通りの挙動か否かを判断することが一般的であった。

しかし、現実のシステム開発の中で、図１の（ａ）に示す方式では、各工程のどの機能をテストすればよいか、工程毎のテスト対象とする機能の組み合わせをどうするか、等のテスト実行範囲が不明確になるという問題点があった。また、テストを実行した結果として取得した証跡のうち、どの証跡がどの工程のテストの証跡かが不明瞭になるという問題点もあった。証跡は、情報システムのテストの結果、生成されたデータを含み、例えばデータベースやログに記録されたデータを含む。この結果、開発責任者毎の証跡の分割に手間がかかり、また、障害の発生原因の切り分けが容易でなく、障害対応に時間を要することもあった。

このような問題認識を踏まえ、本発明者は、開発責任者が異なる複数の工程が連なって業務フローを形成する情報システムの総合テストにおける好適な方式として図１の（ｂ）に示す方式へ標準化することに想到した。実施の形態のテスト実行装置によるテストでは、１つのテストケースに対するテストシナリオを開発責任者の単位で作成し、言い換えれば、１単位の開発責任者の責任範囲である工程毎に作成する。そして、工程毎のテストシナリオにしたがって複数の工程に亘り業務イベントを処理させていき、情報システムのテストを自動実行する。テストでエラーが発生した場合は、そのエラーが発生した工程のテストシナリオの情報を記録する。テストシナリオは、例えば、テストケースのＩＤやテスト対象の機能、入力データ等を定めたものである。

このように、複数の機能を有するテスト対象の情報システムについて、開発責任者を単位としてテストシナリオを用意することにより、誰が作ったテストシナリオでエラーが発生したかが明確になり、エラー対応における責任分解点が明確になる。例えば、開発責任者が異なる複数の工程が連なって業務フローを形成するシステムについて、総合テストにおけるエラー発生箇所に対する責任者（例えばエラーの解析・改修の責任が存在するチーム）の特定が容易になり、障害対応の効率化を支援できる。なお実施の形態の開発責任者は、複数人からなる開発チームや企業を含む。また、実施の形態の業務イベントは、情報システムで処理すべき１単位の事柄（注文、購入等）を示す。

（特徴２）
現実の情報システムではセキュリティ基準の遵守が要求されることが多く、総合テストの際にもこのセキュリティ基準を遵守する必要がある。実施の形態のセキュリティ基準は、クライアント装置はファイアウォールを経由してサーバへアクセスすべきことを定める。また、ファイアウォールは、ユーザ単位・ポート番号単位で認証を実行し、ユーザのログイン時間やユーザが発行したコマンドをログに残すことを定める。

これまでのテスト実行装置では、以下の２つの方法による証跡取得が可能であった。図２に示す従来方法１は、テスト実行装置がサーバに直接アクセスし、サーバからテストの証跡を取得する。この方法では、ファイアウォールを経由しないため、誰が何のコマンドを発行したかが記録されない。したがって、テストの証跡を高速に取得できるもののセキュリティ基準を満たさない。

また図２に示す従来方法２は、テスト実行装置がサーバ接続ツール（例えばサードパーティが提供する無償ソフトウェア）と連動し、証跡の内容を標準出力へ表示し、表示内容をファイルに変換する方法である。具体的には、テスト実行装置がサーバ接続ツールによってサーバにログインするために、まずファイアウォールを介してＳＳＨ通信を実行する。サーバへのログインが成功すると、サーバが保持する証跡取得用シェルを実行し、証跡物の内容をサーバ接続ツールの標準出力へ表示する。テスト実行装置は、標準出力に表示された内容をファイルに保存する。

この方法では、サーバへのアクセスにファイアウォールを経由するため、誰がどのコマンドを実行したかを記録でき、セキュリティ基準を満たす。しかし、サーバ接続ツールは対話形式でサーバとデータを送受するため、通信の無駄が多い。さらに、証跡取得のために、証跡物の内容をサーバ接続ツールの標準出力に一旦表示させる必要があり、低速である。これらの理由により証跡取得に長時間を要してしまう。

そこで実施の形態のテスト実行装置は、図２で示すように、目的に特化したプロトコル（具体的にはデータベースアクセスのためのＪＤＢＣポート）での認証をファイアウォールに実行させる。ファイアウォールは、テスト実行装置がファイアウォールの特定ポートに対して発行したリクエストを、ポートフォワーディングしてサーバへ転送する。またサーバからのレスポンスを、ポートフォワーディングしてテスト実行装置へ転送する。ファイアウォールは、リクエストを中継する際に、ユーザ名やリクエスト内容をログに記録する。

実施の形態のサーバアクセス方法では、従来方法１と異なり、ファイアウォールによる認証とログ記録がなされるため、セキュリティ基準を満たすことができる。また従来方法２と異なり、テスト実行装置とデータベースサーバ間の通信をファイアウォールがポートフォワーディングで中継し、無駄なデータのやり取りを排除することで、証跡取得を高速化することができる。また、証跡物の内容を標準出力に表示させる必要もなく、証跡取得を高速化することができる。

図３は、第１の実施の形態における総合テストのシステム構成を示す。テスト対象システム１２は、総合テストの対象となるシステムであり、ウェブアプリケーションサーバ１４とデータベースサーバ１６を備える。テスト対象システム１２は、不図示の帳票サーバ等、種々のサーバや装置をさらに備えてもよく、これらの装置が連携することにより各種の情報処理サービスを実現してもよい。

ウェブアプリケーションサーバ１４は、テスト対象システムによる各種の情報処理サービスをクライアント装置へ提供する。ウェブアプリケーションサーバ１４が提供する情報処理サービスの業務フローは複数の工程を含む。複数の工程は、例えば業務イベントを登録するエントリー工程や、エントリーされた業務イベントの内容をチェックする工程、チェック済の業務イベントに対する請求処理を実行する工程を含んでもよい。実施の形態では、複数の工程を、工程Ａ、工程Ｂ、工程Ｃ、工程Ｄと称し、典型的には１つの業務イベントの処理を工程Ａから開始し、工程Ｄで完了する。

ウェブアプリケーションサーバ１４は、工程Ａ〜工程Ｄそれぞれの機能、言い換えれば、情報処理のロジックを実装した複数のアプリケーションを保持する。これらのアプリケーションは、互いに異なる開発責任者により実装される。例えば、アプリケーションＡは、工程Ａの機能を実装し、開発責任者はＡ社である。その一方、アプリケーションＢは、工程Ｂの機能を実装し、開発責任者はＢ社である。また、工程Ａ〜工程Ｄのそれぞれに対応するアプリケーションは、工程毎に異なる画面をクライアント装置へ提供する。例えば、工程Ａのアプリケーションは業務イベント登録のためのウェブページを提供し、工程Ｂのアプリケーションは登録された業務イベント内容にミスがないかどうかを確認するためのウェブページを提供する。

ウェブアプリケーションサーバ１４は、エントリーされた業務イベントを複数の工程に亘り処理する際に、工程間でバッチ処理を定期的に実行する。言い換えれば、ある工程の処理を完了した業務イベントについて、定期的なバッチ処理が完了したことを条件として、それらの業務イベントに対する次の工程の処理を開始する。バッチ処理の実行間隔は任意でよいが、実施の形態では５分とする。例えば、工程Ａを完了した業務イベントについて、工程Ａでの出力データに対するバッチ処理を実行後、工程Ａを完了した業務イベントに対する工程Ｂの処理を開始する。同様に、工程Ｂを完了した業務イベントについて、工程Ｂでの出力データに対するバッチ処理を実行後、工程Ｂを完了した業務イベントに対する工程Ｃの処理を開始する。

ウェブアプリケーションサーバ１４は、エントリーされた業務イベントに対する各工程の処理結果を示す情報、例えば処理日時やエラー有無、業務イベント情報等をデータベースサーバ１６に記録する。具体的には工程毎に予め定められたテーブルの予め定められたカラムに格納する。データベースサーバ１６は、各工程の処理結果を示す情報が記録されるテーブルを保持する。データベースサーバ１６は、特定のポート番号においてリスナーを起動させ、接続要求や、テーブルに対する更新要求・参照要求を含むＤＢ操作コマンドを受け付ける。

実施の形態では、ウェブアプリケーションサーバ１４は、クライアント装置に対してウェブページを提供し、そのウェブページに対して入力された情報をクライアント装置から取得して業務処理を実行する。変形例として、ウェブページに限らず、クライアント装置が専用のクライアント画面を表示させ、その画面への入力情報をクライアント装置がテスト対象システム１２へ送信し、テスト対象システム１２が業務処理を実行してもよい。

テスト実行装置１０は、テスト対象システム１２の総合テストを実行する情報処理装置である。具体的には、テスト実行装置１０は、テスト対象システム１２のクライアント装置として動作し、ＬＡＮ・ＷＡＮ・インターネット等の通信網を介して、業務イベント情報をテスト対象システム１２へ入力することによりテスト対象システム１２の動作を検証する。

テスト実行装置１０は、ウェブアプリケーションサーバ１４からウェブページを取得し、そのウェブページに対して予め定められた操作を再現することでウェブアプリケーションサーバ１４における業務イベント処理を進めさせる。またテスト実行装置１０は、テストの証跡情報をデータベースサーバ１６から取得し、テスト対象システム１２の動作が正常か否かを判定する。なお図３では、データベースサーバ１６へアクセスする際にのみファイアウォール１８を介するよう描いているが、ウェブアプリケーションサーバ１４へアクセスする際にもファイアウォールを介してよいことはもちろんである。

図４は、図３のテスト実行装置１０の構成を示すブロック図である。テスト実行装置１０は、制御部３０とデータ記録部２０を備える。制御部３０は、テスト実行装置１０の動作を制御し、また、テスト対象システム１２のテストに係る各種データ処理を実行する。データ記録部２０は、制御部３０によるデータ処理において参照、更新される各種データを記憶する記憶領域である。図４には不図示だが、テスト実行装置１０には、所定のウェブブラウザプログラムがインストールされている。

本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、制御部３０の各機能ブロックに対応するソフトウェアモジュールを備えるテスト自動実行アプリケーションがテスト実行装置１０にインストールされてもよい。そして、テスト実行装置１０のＣＰＵが、各ソフトウェアモジュールをメモリに読み出して実行することにより、制御部３０の各機能ブロックの機能が発揮されてもよい。また、データ記録部２０の各機能ブロックは、ストレージやメモリ等の記憶装置がデータを記憶することにより実現されてもよい。

データ記録部２０は、シナリオ保持部２２、アクションシート保持部２４、データシート保持部２６、照合データ保持部２７、テスト結果保持部２８を含む。

アクションシート保持部２４は、テスト対象システム１２が提供する情報処理サービスの複数の工程に対応する複数のアクションシートを保持する。アクションシートは、テスト対象システム１２が提供する１画面につき１つ作成する文書である。既に述べたように、少なくとも工程毎に画面が異なるため、少なくとも工程毎に異なるアクションシートが作成される。アクションシートには、画面で入力されうる操作を列挙した画面操作情報が記録される。画面操作情報は、例えば、ある工程の１つのウェブページで入力可能な操作の一覧を示す情報と言え、また、１つのウェブページに配置されたボタンやテキストフィールド等の各画面要素に対して入力可能な操作を網羅的に示す情報と言える。

図５は、テスト対象システム１２が提供する画面例を示す。テストにおいて操作入力対象となる画面を以下「操作対象画面」とも呼ぶ。図５は、操作対象画面であるウェブページを示しており、エレメントロケータは、ウェブページに配置された各画面要素（フォーム）に付与されたＩＤを示している。ボタンＭｅｎｕ１〜４のＩＤは、それぞれ「menu1」「menu2」「menu3」「menu4」である。

図６は、図５の画面に対して作成されたアクションシートを示す。アクションシートの１レコードは、画面上で入力可能な１種類の操作に対応する。具体的には、図６のＮｏ１〜４、８、９は、図５のＭｅｎｕ１〜４のボタン、新規登録ボタン、変更ボタンに対する操作を示す。また、図６のＮｏ５〜７は、図５のＵＳＥＲテキストフィールド、ＰＡＳＳテキストフィールド、ＰＡＳＳ再入力テキストフィールドに対する操作を示す。アクションシートでは、関数に渡すパラメータの値として、図７で示すデータシートに格納されたデータを参照することを記述できる。例えば図６では、Ｎｏ１・パラメータ２の値（クリック対象のエレメントロケータ）として、データシートの「menu1」欄の値を設定することが記述されている。したがって、データシートの「menu1」欄に「dom=document.getElementById('menu1')」が記述されると、テスト実行時に図５のＭｅｎｕ１ボタンを押下する。また図６では、Ｎｏ５・パラメータ３の値（入力フィールドにセットする値）として、データシートの「user」欄の値を設定することが記述されている。したがって、データシートの「user」欄にセットすべき値が記述されると、テスト実行時に図５のＵＳＥＲテキストフィールドにその値を設定する。

アクションシート保持部２４は、複数のアクションシートのそれぞれと、各アクションシートが対象とする画面の識別情報を対応付けて保持する。例えば、図６のアクションシートと対応付けて、図５のウェブページのＵＲＬを保持する。

図４に戻り、データシート保持部２６は、アクションシート保持部２４が保持する複数のアクションシートに対応する複数のデータシートを保持する。データシートは、１アクションシートにつき１つ作成する文書であり、すなわち、テスト対象システム１２が提供する１画面あたり１つ作成する文書である。データシートには、テストにおいて実際に画面へ入力すべき操作を指定し、また、操作の内容を定めたテスト操作情報が記録される。

図７は、図６のアクションシートに対して作成されたデータシートを示す。図７（ｂ）は、図７（ａ）の続きを示している。データシートには、操作対象画面において操作可能な各画面要素に対応する列が設けられる（図６の「menu1」〜「update」）。また、データシートの１レコードは、テストにおける１回の操作に対応する。具体的には、図７の行１は、図５のＭｅｎｕ１ボタンを押下し、他の画面要素の操作は実行しないことを定めたテスト操作情報を示す。

図７の行２は、図５のＵＳＥＲテキストフィールドに「nomura」、ＰＡＳＳテキストフィールドに「abcdef」、ＰＡＳＳ再入力テキストフィールドに「abcdef」を入力し、新規登録（insert）ボタンを押下することを定めたテスト操作情報を示す。図７の行３は、図５のＵＳＥＲテキストフィールドに「nomura」、ＰＡＳＳテキストフィールドに「efghij」、ＰＡＳＳ再入力テキストフィールドに「efghij」を入力し、変更（update）ボタンを押下することを定めたテスト操作情報を示す。アクションシートに記述された操作を実行するか否かは、データシートにおいて対応する操作欄に値を設定するか否かにより制御する。後述のテスト実行部３４は、データシートでパラメータが未指定の列の操作はテスト時に実行しない。

図４に戻り、シナリオ保持部２２は、総合テストの内容を規定したテストシナリオを保持する。図８で示すように、実施の形態のテスト実行装置１０では、（１）工程別シナリオシート、（２）工程別複数シナリオ実行シート、（３）複数工程テスト実行シートの３種類の文書によりテストシナリオを構成する。シナリオ保持部２２は、（１）〜（３）の文書をテストシナリオとして保持する。

（１）工程別シナリオシートは１つの工程に閉じた業務フローを規定し、１工程１業務イベントのテスト毎に１つの工程別シナリオシートが作成される。図９は工程別シナリオシートの例を示す。工程別シナリオシートの１レコードでは、特定の工程において提供される１画面に対する操作内容を規定する。具体的には、工程別シナリオシートの識別情報であるテストケースＩＤ（業務イベントＩＤとも言える）と、特定の工程で提供される１画面に対して作成されたアクションシートと、そのアクションシートに対応するデータシートと、テスト対象の操作が記述されたデータシートの行番号を指定する。例えば、図９のレコード２で指定されたアクションシートは図６のアクションシートであり、同レコードで指定されたデータシートは図７のデータシートである。同レコードでは行番号２が指定されているため、図７のデータシートの行２で指定されたユーザ登録操作をテストする。

図８に戻り、（２）工程別複数シナリオ実行シートは、複数の工程別シナリオシートの実行態様を規定する。特定の１工程についての複数の工程別シナリオシートをバッチ実行するための文書と言える。図１０は工程別複数シナリオ実行シートの例を示す。同図の工程別複数シナリオ実行シートは、テストケースＩＤ「Ａ−００１」のシナリオシート（図９）が規定する工程Ａのテストから、テストケースＩＤ「Ａ−１００」のシナリオシートが規定する工程Ａのテストを順次実行することを定めている。すなわち、テスト対象システム１２の工程Ａに対する１００件分のテストシナリオを順次実行することを定めている。

図８に戻り、（３）複数工程テスト実行シートは、複数の工程に亘るテストの実行態様を規定する。複数の工程に亘る複数の工程別複数シナリオ実行シートをバッチ実行するための文書と言える。図１１は複数工程テスト実行シートの例を示す。同図の複数工程テスト実行シートは、工程Ａの複数シナリオ実行シート（図１０に示したＡ＿複数シナリオ実行シート）から、工程Ｄの複数シナリオ実行シート（Ｄ＿複数シナリオ実行シート）を順次実行することを定めている。また、テストに用いるウェブブラウザの種類や、エラーハンドリングの態様も規定する。

照合データ保持部２７は、テスト対象システム１２に対するテストの結果が正常か否かを判定するためのデータであり、テスト対象システム１２から取得されるテスト証跡と比較するための照合データを保持する。照合データは、テスト対象システム１２の仕様やテストの入力データにもとづく、テストの出力データの期待値を定めたものでもよい。テスト対象システム１２がテストへの応答でウェブページを返す場合、照合データは、応答として期待されるウェブページのデータ（画像データを含む）であってもよい。実施の形態では、工程別シナリオシート毎に照合データが作成され、照合データ保持部２７は、工程別シナリオシートに設定されるテストケースＩＤと対応付けて各照合データを保持する。

テスト結果保持部２８は、テスト対象システム１２による自動テストの結果を示す情報を保持する。テスト結果保持部２８は、自動テストにおいて検出されたエラー情報として、エラー発生日時、エラー内容、エラー発生のテストに関連するシナリオシート、アクションシート、データシートを示す情報を対応付けて保持する。

図４に戻り、制御部３０は、操作検出部３２、テスト実行部３４、証跡取得部３６、テスト結果判定部３８、テスト結果記録部４０、テスト結果表示部４２を含む。操作検出部３２は、キーボードやマウス等の入力装置に対してユーザが入力した操作を検出する。

テスト実行部３４は、テストの実行を指示する操作が入力された場合に、テスト対象システム１２に対する自動テストを開始する。実施の形態では、テストの実行を指示する操作において特定の複数工程テスト実行シートが指定される。テスト実行部３４は、複数工程テスト実行シートのレコード順に実行対象とする工程別複数シナリオ実行シートを識別し、その工程別複数シナリオ実行シートのレコード順に実行対象とする工程別シナリオシートを識別する。そして、工程別シナリオシートのレコード順に実行対象とするアクションシート、データシート、データシート行番号を識別する。

テスト実行部３４は、アクションシート保持部２４において実行対象アクションシートに対応付けられたＵＲＬをウェブブラウザに渡す。ウェブブラウザは、そのＵＲＬで特定される操作対象のウェブページをウェブアプリケーションサーバ１４から取得し、ディスプレイに表示させる。テスト実行部３４は、実行対象アクションシートに規定された操作のうち、実行対象データシートの実行対象行番号のレコードで指定された操作を、ウェブブラウザが表示するウェブページに対して実行する。

ウェブページに対する操作は、先行技術文献１に示す方法等、公知の方法を使用してよい。例えば、アクションシートまたはデータシートに定められたフレームロケータやエレメントロケータの値、入力文字列等を引数として、ウェブブラウザプログラムが公開する公知のＡＰＩを呼び出すことにより、ウェブページに対する操作をウェブブラウザに実行させてもよい。ウェブブラウザは、ウェブページのフォーム操作に伴いＨＴＴＰ−ＰＯＳＴリクエスト等をウェブアプリケーションサーバ１４へ送信し、別のウェブページを取得して表示させる。典型的にはテスト実行部３４は、ウェブページが切り替わると、工程別シナリオシートの次のレコードへ進み、次のレコードが規定する別のアクションシートとデータシートを実行対象として識別する。

テスト実行部３４は、複数工程テスト実行シートのレコード順、工程別複数シナリオ実行シートのレコード順、工程別シナリオシートのレコード順に、実行対象のアクションシートとデータシートを順次識別し、複数の工程に亘るテスト対象システム１２のテストを進行させる。例えば、図１１の複数工程テスト実行シートが指定された場合、複数業務イベントのテストを工程Ａ→工程Ｂ→工程Ｃ→工程Ｄの順に進行させる。

テスト実行部３４は、複数工程テスト実行シートの１レコード（例えば工程Ａの１００業務イベント分）の処理が完了すると、定期実行されるバッチ処理が完了するまでの期間待機した後、次のレコード（例えば工程Ｂの１００業務イベント分）の処理を開始する。バッチ処理の完了を待つ期間は、バッチ処理の実行間隔（例えば５分）に応じてその間隔以上に定められた一定期間（例えば１０分）でもよい。また、テスト対象システム１２の所定の記憶領域にバッチ処理の完了を示す情報が記録される場合、テスト実行部３４は、当該情報の記録有無を監視し、当該情報が記録されたことを検出した場合に、複数工程テスト実行シートの次のレコードによる業務イベント処理（例えば次の工程の業務イベント処理）を開始してもよい。

証跡取得部３６は、テスト実行部３４が１つの工程別シナリオシートの処理、すなわち１つの工程内における１業務イベント分のテストを完了したことを検出すると、データベースサーバ１６からテストの証跡情報を取得する。証跡情報は、ウェブページの操作によってウェブアプリケーションサーバ１４に業務イベント処理を実行させた結果、ウェブアプリケーションサーバ１４がデータベースサーバ１６に記録した情報である。例えば、テスト対象の工程における業務イベント処理結果の記録先となる所定のテーブル・カラムに格納された、テスト対象のテストケースＩＤに対応付けられたデータを証跡情報として取得してもよい。

証跡取得部３６は、テスト実行装置１０にインストールされたＪＤＢＣドライバを介して、ファイアウォール１８に対してデータベース（ＤＢ）接続要求を送信する。ＤＢ接続要求では、（１）送信元ＩＰアドレスとしてテスト実行装置１０のＩＰアドレス、（２）宛先ＩＰアドレスとしてファイアウォール１８のＩＰアドレス、（３）送信元ポート番号としてＪＤＢＣドライバが使用する所定のポート番号を指定する。さらに、（４）宛先ポート番号としてＤＢ接続用の予め定められたポート番号、（５）ＤＢ接続用の予め定められたアカウント情報（例えばユーザ名とパスワード）を指定する。

ファイアウォール１８は、ＤＢ接続用のポート番号とＤＢアクセスを許可すべきアカウント情報の組み合わせを保持する。ファイアウォール１８は、ＤＢ接続用のポート番号を指定するＤＢ接続要求を受け付けた場合に、そのＤＢ接続要求で指定されたアカウント情報が、ＤＢアクセスを許可すべきアカウント情報と整合するか否かを判定する。そして整合する場合、テスト実行装置１０からファイアウォール１８へのアクセスを許可する。

ファイアウォール１８は、テスト実行装置１０からファイアウォール１８へのアクセスを許可した場合に、ＤＢ接続要求をポートフォワーディングによりファイアウォール１８へ転送する。具体的には、（１）送信元ＩＰアドレスをファイアウォール１８のアドレスに変換し、（２）宛先ＩＰアドレスをデータベースサーバ１６のＩＰアドレスに変換し、（３）送信元ポート番号をファイアウォール１８の所定のポート番号に変換し、（４）宛先ポート番号をデータベースサーバ１６のＤＢリスナーが起動している所定のポート番号に変換したＤＢ接続要求をデータベースサーバ１６へ転送する。

データベースサーバ１６は、ファイアウォール１８から送信されたＤＢ接続要求に応じて、データベースに接続した旨を示すＤＢ接続応答をファイアウォール１８へ送信する。具体的には、（１）送信元ＩＰアドレスとしてデータベースサーバ１６のＩＰアドレス、（２）宛先ＩＰアドレスとしてファイアウォール１８のＩＰアドレス、（３）送信元ポート番号としてＤＢリスナーが起動している所定のポート番号、（４）ＤＢ接続要求で指定されたファイアウォール１８の所定のポート番号、を指定したＤＢ接続応答を送信する。

ファイアウォール１８は、データベースサーバ１６から送信されたＤＢ接続応答をポートフォワーディングによりテスト実行装置１０へ転送する。具体的には、（１）送信元ＩＰアドレスをファイアウォール１８のアドレスに変換し、（２）宛先ＩＰアドレスをテスト実行装置１０のＩＰアドレスに変換し、（３）送信元ポート番号をＤＢ接続用の予め定められたポート番号に変換し、（４）宛先ポート番号をテスト実行装置１０のＪＤＢＣドライバが使用する所定のポート番号に変換したＤＢ接続応答をテスト実行装置１０へ転送する。

証跡取得部３６は、ＤＢ接続応答を受信後、ＤＢ接続要求と同様に（１）〜（４）を設定したＤＢ操作コマンド（例えばＳＱＬクエリ）をファイアウォール１８へ送信する。ファイアウォール１８は、ＤＢ接続要求と同様に、ＤＢ操作コマンドをポートフォワーディングによりデータベースサーバ１６へ転送する。データベースサーバ１６は、ＤＢ操作コマンドを受信後、ＤＢ接続応答と同様に（１）〜（４）を設定したコマンド実行結果（クエリ応答）をファイアウォール１８へ送信する。ファイアウォール１８は、データベースサーバ１６から送信されたコマンド実行結果を、ＤＢ接続応答と同様に、ポートフォワーディングによりテスト実行装置１０へ転送する。

ファイアウォール１８は、ＤＢ接続用のポート番号において受信されたＤＢ接続要求とＤＢ操作コマンドの内容を、アカウント情報、受信日時とともに所定のログファイルへ逐次記録する。認証結果や、その他セキュリティ基準で要求される事項をさらにログファイルへ記録してもよい。

テスト結果判定部３８は、証跡取得部３６により取得されたテスト証跡情報と、照合データ保持部２７に予め保持された照合データとを比較して、各テストケースにおけるエラーの有無を判定する。具体的には、特定の工程別シナリオシートによるテスト完了時に取得されたテスト証跡情報と、その工程別シナリオシートに設定されたテストケースＩＤに対応付けられた照合データを比較する。両者が一致する場合、テスト結果が正常と判定し、すなわちテスト対象システム１２の動作が正常と判定する。その一方、両者が不一致の場合、テスト結果が異常と判定し、すなわちテスト対象システム１２の動作のエラーを検出する。なお、テスト対象システム１２がウェブページを提供し、テスト実行部３４がそのウェブページへのデータ入力を自動実行して、テスト対象システム１２の動作をテストする場合、テスト結果判定部３８は、ウェブページへの入力データをテスト対象システム１２へ送信後、テスト対象システム１２からの応答データ（応答のウェブページ等）が期待通りのものか否かを、応答データと照合データとを比較して判定してもよい。

テスト結果記録部４０は、テスト対象システム１２に対する総合テストの結果を示す情報をテスト結果保持部２８へ記録する。具体的には、テスト対象システム１２に対する特定のテストケースについて、そのテストケースＩＤと、テスト証跡情報と、テスト結果判定部３８による正常・異常の判定結果と、判定対象のテストを規定したテストシナリオの情報をテスト結果情報として記録する。このテストシナリオの情報は、エラー発生箇所の責任者、すなわちエラーの解析と改修に責任を負うべき開発担当者を明確にするために、少なくとも工程別シナリオシートの識別情報（パス名、ファイル名等）を含む。さらに、その工程別シナリオシートで規定されたアクションシートおよびデータシートの識別情報を含む。

テスト結果表示部４２は、テスト結果の表示を指示する操作が入力された場合に、テスト結果保持部２８に保持されたテスト結果情報をディスプレイに表示させる。例えば、テスト結果がエラーである場合、そのエラーの事実と、エラーが発生した工程別シナリオシート、アクションシート、データシートの情報を対応付けて表示させる。

以上の構成によるテスト時の動作を以下説明する。
テスト対象システム１２の情報処理サービスにおける複数の工程それぞれの開発責任者は、各自が責任を負う工程のアクションシート、データシート、工程別シナリオシート、工程別複数シナリオ実行シート、照合データを作成する。またテスト対象システム１２全体の開発、試験の責任者は複数工程テスト実行シートを作成する。作成された各種シートはテスト実行装置１０のデータ記録部２０に格納される。

試験担当者は、特定の複数工程テスト実行シートを指定したテスト開始指示をテスト実行装置１０へ入力する。テスト実行部３４は、複数工程テスト実行シート、工程別複数シナリオ実行シート、工程別シナリオシートの順にドリルダウンし、実行対象のアクションシート、データシート、操作対象ウェブページを特定する。テスト実行部３４は、ウェブブラウザに表示させた操作対象のウェブページに対して実行対象のアクションシートとデータシートで規定された操作を実行する。テスト実行部３４は、複数工程テスト実行シート、工程別複数シナリオ実行シート、工程別シナリオシートにしたがって、ウェブページ、アクションシート、データシートを順次切り替えていき、複数の工程に亘って業務イベント処理を進めていくことにより、テスト対象システム１２の総合テストを自動実行する。

図１、図８、図１１で示すように、実施の形態では、単一の工程において複数業務イベントの動作テストを一括して実行する。具体的には、工程Ａにおける１００業務イベント分の動作テストを順次実行し、それらの業務イベントのうち最後の業務イベントに対する工程Ａの動作テストが完了するまでは、工程Ａの動作テストが完了済の業務イベントであっても工程Ｂの動作テストの開始を抑制する。そして、工程Ａにおける１００業務イベント分の動作テストが完了し、定時のバッチ処理が完了したことを条件に、工程Ｂに対する同じ１００業務イベント分の動作テストを開始する。工程Ｂ以降も、単一の工程において１００業務イベント分の動作テスト完了後に次の工程へ進む。

テスト実行部３４は、１つの工程別シナリオシートによるテストが完了すると、テストを完了した工程の識別情報とテストケースＩＤを証跡取得部３６に渡す。証跡取得部３６は、ファイアウォール１８の認証を経てデータベースサーバ１６へアクセスする。証跡取得部３６は、ファイアウォール１８のポートフォワーディングを介して、工程とテストケースＩＤにより識別されるテスト証跡情報をデータベースサーバ１６から取得する。ファイアウォール１８は、データベース接続用の特定のポート番号を宛先ポート番号として指定する電文をテスト実行装置１０から受け付けると、認証の結果に応じて当該電文をデータベースサーバ１６へ転送しつつ、電文で指定されたユーザ名および操作内容（コマンド等）をログに記録する。テスト結果判定部３８は、テスト証跡情報と照合データを比較し、特定のテストケースについてテスト対象システム１２の動作が正常か否かを判定する。

テスト結果記録部４０は、テスト証跡情報と、テスト対象システム１２の動作についての正常性判定結果とを含むテスト結果をテスト結果保持部２８へ格納する。テスト結果表示部４２は、ユーザの要求に応じて、テスト結果を表示装置に表示させる。テスト対象システム１２の動作にエラーが検出された場合、テスト結果記録部４０は、エラーが発生したテストケースに対応する工程別シナリオシート、アクションシート、データシートを対応付けてテスト結果保持部２８へ格納する。テスト結果表示部４２は、エラーが発生したテストケースに対応する工程別シナリオシート、アクションシート、データシートを対応付けて表示装置に表示させる。

図１２は、テスト対象システム１２の総合テストの実施例を示す。同図の「工程Ａ〜工程Ｄテスト実行シート１」、「工程Ａ〜工程Ｄテスト実行シート２」、・・・のそれぞれは、１つの複数工程テスト実行シートに対応する。実施の形態では、工程Ａ〜工程Ｄの１サイクルにつき１つの複数工程テスト実行シートを作成する。

例えば、工程Ａ→Ｂ→Ｃ→Ｂ→Ｃ→Ｄのような手戻りが発生するテストケース（業務イベント）の場合、まず、シート５０の実行において工程Ａ→Ｂ→Ｃのテスト（実際には工程毎の３つの工程別シナリオシートにもとづくテスト）を実行する。そして次に、シート５２の実行において工程Ｂ→Ｃ→Ｄテストを実行する。

また、何度も業務フローを繰り返すサイクルテストも複数工程テスト実行シートを複数回実行することで実現できる。具体例として、工程Ａ→Ｂ→Ｃ→Ｄを５回繰り返すサイクルテストは、例えば１００業務イベント×４工程分の４００枚の工程別シナリオシートによるテストをそれぞれ含むシート５０、シート５２、シート５４、シート５６、シート５８を順次実行することで実現できる。

テストの中でテスト対象システム１２のエラーが検出された場合、エラー発生箇所の開発責任者の責任で再度テストを実施する。既に述べたように、エラー情報として工程別シナリオシートの情報を提示する。再テストでは、先のテストでエラーが発生したテストケースに係る工程別シナリオシートであり、エラー情報で提示された工程別シナリオシートを使用することで、問題の特定と改修を効率的に実施できる。

実施の形態のテスト実行装置１０によると、入力された業務イベントの処理を、開発責任者が異なる複数の工程に亘る処理を経て完了するテスト対象システム１２の特性を踏まえ、総合テストのシナリオを工程毎に分割して個々のシナリオ単位にテストを実行する。そして、個々のシナリオにもとづくテストでエラーを検出した場合に、そのエラーが発生した工程のシナリオを記録し、シナリオの情報を含むエラー情報を開示する。このように工程毎のシナリオ単位で証跡や正常性判定結果を記録することで、開発責任者毎の証跡の分割や、障害の発生原因の切り分けに時間を要してしまうことを回避でき、テストの効率化を実現できる。また、エラー発生箇所に対する責任者の特定が容易になり、障害対応の効率化を支援できる。

またテスト実行装置１０によると、異なる工程の業務イベント処理の間に定時のバッチ処理を実行すべきテスト対象システム１２の特性を踏まえ、１つの業務イベントを単位として工程Ａの開始から工程Ｄの終了まで継続するテストではなく、１つの工程を単位として１つの工程内で複数業務イベントのテストを一括して実行する。これにより、複数業務イベントのテストに要する時間を低減することができる。例えば、１つの業務イベントを単位として工程Ａの開始から工程Ｄの終了まで継続するテストの場合、１業務イベントのテストにつき、各工程の処理時間に加えて、工程Ａ〜工程Ｂ間のバッチ処理待ち時間５分、工程Ｂ〜工程Ｃ間のバッチ処理待ち時間５分、工程Ｃ〜工程Ｄ間のバッチ処理待ち時間５分がかかることになる。これに対し、実施の形態の方式では、１００業務イベントのテストにおいて上記のバッチ処理待ち時間が１回ずつ発生するだけであり、バッチ処理待ち時間を削減して効率的なテストを実現できる。

またテスト実行装置１０によると、アクションシートとデータシートの役割分担が明確になり、１画面につき１枚のアクションシートを作成し、テストで実際に実行する操作はデータシートにおいて規定するよう標準化できる。例えば、テキストフィールド、ラジオボタン、ボタンＡ、ボタンＢを含むウェブページの操作として、（１）テキストを入力してボタンＡ押下、（２）ラジオボタンを選択してボタンＢ押下、という異なる操作についても、アクションシートは共通で、データシートのデータ（指定する行番号）を変更するだけで（１）（２）それぞれの操作を再現できる。このような標準化により、複数の機能が複数の開発責任者により分散開発されるテスト対象システム１２において、アクションシートやデータシート、工程別シナリオシート等、総合テストの成果物の均質化を実現できる。また、成果物の均質化によりメンテナンス性の向上を実現できる。

以上、本発明を第１の実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

（第２の実施の形態）
第２の実施の形態では、リクエストに対してリアルタイムに実行されるオンライン処理と、リクエストとは独立して所定時間間隔で実行される定期バッチとの間に依存関係がある情報システムを自動テストするための技術を説明する。実施の形態でのオンライン処理は、ウェブページへ入力されたデータがテスト実行装置からテスト対象システムへ送信されたことに伴い、テスト対象システムがリアルタイムに実行する処理を意味する。

第２の実施の形態におけるテスト対象システムは、定期的に実行される定期バッチが完了しないと、オンラインの操作を許可せず、言い換えれば、ウェブページを介して入力されたオンライン処理の要求を受け付けない。従来のテスト実行装置は、テスト対象システムがオンライン処理の受け付け状態になる前に、ウェブページを自動操作してオンライン処理を要求してしまい、テストが異常終了していた。この結果、本来のテスト項目が確認できないことがあった。また、テスト対象システムがオンライン処理を許可する状態になるまでテスト実行装置を一定時間待機させることも考えられるが、その状態になるまでの所要時間は必ずしも一定ではなく、本来不要な待機時間が生じてしまう。また、待機する場合であっても、指定された待機時間内にオンライン処理を許可する状態にならなければ、やはりテストが異常終了してしまう。

そこで第２の実施の形態のテスト実行装置は、ある工程のオンライン処理が終了後、テスト対象システムにおける定期バッチの実行結果が保存されるテーブルを監視し、テスト対象システムが次の工程のオンライン処理を許可する状態になったかを判断する。これにより、定期的に実行されるバッチ処理の完了をオンライン処理の開始条件とする情報システムを自動テストする場合に、テストの異常終了を回避しつつ、テスト効率の低下を抑制することを実現する。

以下、図面を参照しつつ、第２の実施の形態の構成を詳細に説明するが、第１の実施の形態における装置・機能と同一もしくは対応するものには同一の符号を付している。以下では、第１の実施の形態と重複する説明は適宜省略する。なお、第１の実施の形態の構成と第２の実施の形態の構成を適宜組み合わせ、また置き換えることが可能であることはもちろんである。

図１３は、第２の実施の形態における総合テストのシステム構成を示す図であり、図３に対応する。第２の実施の形態のテスト対象システム１２は、ウェブアプリケーションサーバ１４、データベースサーバ１６に加えて、バッチ処理サーバ１３、外部接続サーバ１５を含む。

バッチ処理サーバ１３は、ウェブアプリケーションサーバ１４へ入力された業務イベント情報を処理するためのオンラインバッチ６０と定期バッチ６２を保持する。オンラインバッチ６０は、各工程のウェブページに対してクライアントが入力したデータをリアルタイムに処理するバッチ処理機能（バッチファイル）である。実施の形態では、テスト実行装置１０が各工程のウェブページに自動入力したデータをウェブアプリケーションサーバ１４へ送信して、ウェブアプリケーションサーバ１４がオンライン処理をバッチ処理サーバ１３に要求したことに伴い、バッチ処理サーバ１３がオンラインバッチ６０を実行する。オンラインバッチ６０は、例えば、各工程のウェブページに入力された業務イベント情報に対するチェック処理や、データベースへの登録処理を実行する。

定期バッチ６２は、外部接続サーバ１５が利用可能な時間内（例えば９時から１８時）に、予め定められた時間間隔で定期実行されるバッチ処理機能である。定期バッチ６２は、オンラインバッチ６０とは独立して、言い換えれば、テスト実行装置１０が各工程のウェブページを操作したかどうかに依存せず、定期的に繰り返し実行される。定期バッチ６２の実行間隔は典型的には数分である。定期バッチ６２は、例えば、各工程のウェブページに入力された業務イベント情報を外部接続サーバ１５に渡し、外部接続サーバ１５による各種処理を実行させる。

ウェブアプリケーションサーバ１４は、１つの業務イベントについて、ある工程のオンライン処理を実行後、その業務イベントのデータに対して定期バッチが未実行の間は、次の工程のオンライン処理要求を受け付けない。具体的には、業務イベントに関する情報を入力するためのある工程のウェブページを、その工程の前提となる定期バッチが完了していることを条件として、クライアント装置（総合テストにおいてはテスト実行装置１０）へ提供する。

データベースサーバ１６は、バッチ処理サーバ１３における業務イベント単位のバッチ処理状況が格納される業務イベント工程状況テーブル６４を保持する。図１４は、業務イベント工程状況テーブル６４の構成を示す。業務イベント工程状況テーブル６４には、業務イベント工程ＩＤ、業務イベント番号、定期バッチ完了日時が対応付けて格納される。業務イベント工程状況テーブル６４は、テスト対象システム１２における業務イベント処理の進行状況の変更履歴を保持するテーブルとも言える。

業務イベント工程ＩＤは、テスト対象システム１２における処理の識別情報であり、業務イベント単位かつオンラインバッチ６０単位にユニークに採番される。ある工程における１つの業務イベント処理において複数のオンラインバッチ６０が実行される場合、業務イベント工程状況テーブル６４には、最後に実行されたオンラインバッチ６０の業務イベント工程ＩＤが格納される。図１４では、業務イベント番号「００３」の業務イベントと業務イベント番号「４５５」の業務イベントには、同じ工程の同じオンラインバッチ６０を実行済であることとし、同じ業務イベント工程ＩＤが対応付けられた状況を示している。

業務イベント番号は、テスト対象システム１２で処理対象となる業務イベント単位にユニークな識別番号である。同一の業務イベントであれば工程Ａから工程Ｄまで同一の番号が付与される。業務イベント番号は、図９の工程別シナリオシートにおけるテストケースＩＤに相当し、以下、シナリオシートにおけるテストケースＩＤについても業務イベント番号と呼ぶこととする。定期バッチ完了日時は、業務イベントに対する定期バッチの完了日時であり、初期値は特定の初期値である。定期バッチ完了日時カラムが特定の初期値でなければ、定期バッチが完了済であり、すなわち、次の工程のオンライン処理を受け付け可能であると見なされる。

図１５は、図１３のテスト実行装置の構成を示すブロック図であり、図４に対応する。第２の実施の形態のテスト実行装置１０は、業務イベント工程ＩＤ保持部２９と業務イベント状態監視部３３をさらに備える。他の構成は第１の実施の形態と同様である。

業務イベント工程ＩＤ保持部２９は、テスト対象システム１２における業務イベント処理の工程毎の業務イベント工程ＩＤを保持する。具体的には図１６で示すように、業務イベント工程ＩＤ保持部２９は、各工程の識別情報と、各工程のオンライン処理において最後に実行されるオンラインバッチ６０に対して予め割当てられた業務イベント工程ＩＤを対応付けて保持する。

図１５に戻り、業務イベント状態監視部３３は、テスト実行部３４が、テスト業務イベントについて、ある工程のオンライン処理を要求する前に、前工程のオンライン処理後に実行されるべき定期バッチが実行済か否かを判定する。オンライン処理を要求する前とは、ウェブアプリケーションサーバ１４が定期バッチの終了を条件として許可する処理を要求する前であり、例えば、ウェブページの取得処理前、ウェブページへのデータ入力処理前、または入力データの送信処理前でもよい。テスト業務イベントは、例えば、図９の工程別シナリオシートで同一の業務イベント番号（テストケースＩＤ）が付与されたものである。テスト実行部３４は、テスト業務イベントについて、前工程のオンライン処理後に定期バッチが実行済と判定されたことを条件として、次工程（上記の「ある工程」）のオンライン処理を要求する操作を入力する。

具体的には、業務イベント状態監視部３３は、業務イベント工程ＩＤ保持部２９において前工程と対応付けられた業務イベント工程ＩＤを読み出す。そしてテスト業務イベントの業務イベント番号（工程別シナリオシートに記載された業務イベント番号）と、業務イベント工程ＩＤの組み合わせをキーとして、データベースサーバ１６の業務イベント工程状況テーブル６４を検索する。業務イベント状態監視部３３は、業務イベント工程状況テーブル６４に、指定した業務イベント番号と業務イベント工程ＩＤの組み合わせに一致するレコードが存在し、かつ、そのレコードの定期バッチ完了日時カラムに日時が設定されていた場合、実施の形態では特定の初期値でなかった場合に、前工程のオンライン処理後の定期バッチが実行済と判定する。

業務イベント状態監視部３３は、データベースサーバ１６の業務イベント工程状況テーブル６４に対して３秒に１回、合計２０回のポーリングを実行してもよい。ポーリングの間隔や実行回数は、バッチ処理サーバ１３における定期バッチの実行間隔に応じて適切な値が設定されればよい。例えば、定期バッチの実行間隔が長いほど、多くのポーリング回数を設定してもよい。また、無駄なポーリングを抑制する目的で、定期バッチの実行間隔が長いほど、長いポーリング間隔を設定してもよく、定期的なポーリングの開始前に、定期バッチの実行間隔以下の待ち時間を設けてもよい。

業務イベント状態監視部３３は、予め定められた回数、ポーリングを実行しても、業務イベント工程状況テーブル６４に、指定した業務イベント番号と業務イベント工程ＩＤの組み合わせに一致するレコードが存在せず、または、そのレコードの定期バッチ完了日時カラムが特定の初期値であった場合に、テスト業務イベントのテスト開始に失敗した旨のエラーメッセージをログに記録する。それとともに、テスト実行部３４による以降のテスト実行を中止させ、例えば、ウェブアプリケーションサーバ１４から次工程のウェブページを取得する処理を中止させる。

具体的な実装として、テスト実行装置１０では、業務イベント状態監視部３３による業務イベント工程状況テーブル６４の監視処理を開始させるための関数（ここでは「監視メソッド」と呼ぶ。）が設けられてよい。そして、監視メソッドが各工程のテストの最初に呼び出されるよう、テスト担当者は、各工程の最初の画面操作用のアクションシートに対してその先頭に監視メソッドを記載してもよい。またテスト担当者は、ポーリングの間隔や回数をデータシートに記載してもよい。

テスト実行部３４は、監視メソッドの実行時に、データシートに記載されたポーリング間隔と回数、シナリオシートに記載された工程（もしくはその工程から定まる前工程）の名称とテスト業務イベントの業務イベント番号をテスト実行部３４に渡してもよい。業務イベント状態監視部３３は、業務イベント状態監視部３３から渡された各パラメータに応じて、業務イベント工程状況テーブル６４の監視処理を開始し、テスト業務イベントについて定期バッチ処理が完了済か否かを判定してもよい。

以上の構成によるテスト時の動作を以下説明する。以下では、複数工程に亘るテストを規定した複数の工程別シナリオシートに共通する１つのテストケースをテスト業務イベントと呼び、そのテスト業務イベントをテストする場合の動作を説明する。

テスト実行装置１０のテスト実行部３４は、テスト業務イベントの業務イベント番号が設定された工程Ａ用の工程別シナリオシート、アクションシート、データシートにしたがってテストを実行する。具体的には、ウェブブラウザのＡＰＩを適宜コールして、工程Ａのウェブページをウェブアプリケーションサーバ１４から取得してウェブブラウザに表示させ、そのウェブページにテスト業務イベントに関する情報を自動入力し、ウェブページのボタン等のフォームを操作する。そしてウェブブラウザを介して、テスト業務イベントの業務イベント番号とウェブページへの入力情報を含むオンライン処理要求をウェブアプリケーションサーバ１４へ送信する。

ウェブアプリケーションサーバ１４は、テスト実行装置１０からオンライン処理要求を受信すると、テスト業務イベントの情報（業務イベント番号を含む）をバッチ処理サーバ１３へ送信し、工程Ａ用のオンラインバッチ６０を実行するようバッチ処理サーバ１３に指示する。バッチ処理サーバ１３のバッチ実行部（不図示）は、テスト業務イベントに対する工程Ａ用のオンラインバッチ６０を実行する。バッチ実行部は、工程Ａ用のオンラインバッチ６０を実行後、テスト業務イベントの業務イベント番号と、実行したオンラインバッチ６０の業務イベント工程ＩＤの組み合わせをローカルの記憶領域に格納し、データベースサーバ１６の業務イベント工程状況テーブル６４にも格納する。このとき定期バッチ完了日時カラムを特定の初期値に設定する。

バッチ処理サーバ１３のバッチ実行部は、定期バッチ６２の先の実行から所定時間が経過したことを検出すると、定期バッチ６２を再度実行する。テスト業務イベントに対しては工程Ａ用の定期バッチ６２の処理を実行する。典型的にはバッチ処理部は、オンライン処理済の複数の業務イベントがあれば、それらの業務イベントを１回の定期バッチ６２の実行で一括して処理する。バッチ実行部は、テスト業務イベントに対する工程Ａ用の定期バッチ６２の処理を完了すると、所定の記憶領域に格納しておいたテスト業務イベントに関する業務イベント番号と業務イベント工程ＩＤの組み合わせを読み出す。そして、その組み合わせに一致する業務イベント工程状況テーブル６４のレコードに定期バッチ完了日時を格納する。

テスト実行装置１０のテスト実行部３４は、テスト業務イベントの業務イベント番号が設定された工程Ｂ用の工程別シナリオシートとアクションシート、データシートにしたがってテストを実行する。このとき、テスト実行部３４はまず、テスト業務イベントに対する定期バッチ処理の完了確認を業務イベント状態監視部３３に指示する。業務イベント状態監視部３３は、データベースサーバ１６へアクセスし、テスト業務イベントの業務イベント番号と、業務イベント工程ＩＤ保持部２９に保持された工程Ａの業務イベント工程ＩＤの組み合わせをキーとして業務イベント工程状況テーブル６４を検索する。業務イベント状態監視部３３は、データシートで指定された間隔および回数、検索処理を繰り返す。

業務イベント工程状況テーブル６４に、検索キーとして指定した業務イベント番号と業務イベント工程ＩＤの組み合わせに一致し、かつ、定期バッチ完了日時カラムが所定値以外（例えば特定の初期値以外）のレコードが存在すれば、業務イベント状態監視部３３は、テスト業務イベントに対する工程Ａの定期バッチ処理が完了したと判定し、その旨をテスト実行部３４へ通知する。例えば、業務イベント工程状況テーブル６４が図１４に示す状態の場合、業務イベント番号「００３」については定期バッチ処理が完了済と判定し、業務イベント番号「４５５」については定期バッチ処理が未完了と判定する。業務イベント状態監視部３３は、データシートで指定された回数の検索処理を実行しても上記レコードが存在しなければエラーを記録し、テスト業務イベントに対する工程Ｂのテストを中止させる。変形例として、業務イベント工程状況テーブル６４に上記レコードが記録されるまで検索処理を繰り返してもよい。

テスト実行部３４は、テスト業務イベントに対する工程Ａの定期バッチ処理が完了した旨が業務イベント状態監視部３３から通知されると、テスト業務イベントの業務イベント番号が設定された工程Ｂ用の工程別シナリオシートとアクションシート、データシートにしたがってテストを実行する。以降、工程別複数シナリオ実行シート、複数工程テスト実行シートの設定にしたがって、工程Ｂ、工程Ｃ、工程Ｄのテストを同様に実行していく。

なお総合テストにおいて、工程毎に複数のテスト業務イベントを一括して処理するのではなく、１つのテスト業務イベントについて工程Ａ〜工程Ｄのテストをできるだけ迅速に実施したい場合にも、第２の実施の形態のテスト実行装置１０は有用である。この場合、テスト実行部３４がウェブブラウザを制御して、テスト業務イベントに関する工程Ａのオンライン処理要求をウェブアプリケーションサーバ１４へ送信すると、業務イベント状態監視部３３は、業務イベント工程状況テーブル６４に対するポーリング処理を即時開始してもよい。業務イベント状態監視部３３が、テスト業務イベントに対する定期バッチ処理の終了を検出すると、テスト実行部３４は、テスト業務イベントに関する工程Ｂのオンライン処理要求をウェブアプリケーションサーバ１４へ即時送信してもよい。このように、第２の実施の形態のテスト実行装置１０によると、定期的に実行されるバッチ処理の完了をオンライン処理の開始条件とする情報システムを自動テストする場合に、テストの異常終了を回避しつつテスト効率の低下を抑制できる。

以上、本発明を第２の実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば、業務イベント状態監視部３３は、証跡取得部３６と同様に、ファイアウォール１８による認証とポートフォワーディングを介して、データベースサーバ１６へアクセスし、業務イベント工程状況テーブル６４に記録された各業務イベントのバッチ処理状況を監視してもよい。これにより、セキュリティ基準の遵守と、データベースアクセス性能を両立することができる。

この構成は以下のように表現することもできる。業務イベント状態監視部３３は、データベースサーバ１６へ接続するための予め定められたポート番号とアカウント情報を指定するデータベース接続要求をファイアウォール１８へ送信してもよい。これにより、データベース接続用のポート番号を指定するデータベース接続要求内のアカウント情報が、予め定められたデータベース接続を許可すべきアカウント情報と整合する場合に、データベースサーバ１６に対する各種のコマンドをデータベースサーバ１６へ転送する処理をファイアウォール１８に実行させてもよい。

（第３の実施の形態）
第３の実施の形態では、電子的に情報が記述された文書を提供するシステムに対するテストの自動化範囲を拡張するための技術を説明する。実施の形態では、電子的に情報が記述された文書の例としてウェブページを示す。しかし実施の形態に記載の技術は、ウェブページには制限されず、特定のアプリケーションで表示される専用画面やプレーンテキスト等、様々な態様の文書に適用可能である。また、文書に限らず、画面に表示される様々な画像や映像等を含むデジタルコンテンツにも適用可能である。

第３の実施の形態の説明では、ウェブページを構成する要素を総称して「エレメント」と呼ぶ。エレメントは、ウェブページの画面を構成する要素であり、ボタンやテキストフィールド、ラジオボタン等、様々なオブジェクトを含む。また、エレメントの中でも、ＨＴＭＬ以外で表現されるオブジェクト（例えばＪＡＶＡアプレットやＰＤＦのデータ）を特に「コンテンツ」と呼ぶ（ＪＡＶＡは登録商標）。実際のコンテンツのデータは、ＨＴＭＬファイル等のウェブページのデータ中で、所定のタグに囲まれたバイナリデータ（例えばＪＡＶＡアプレットやＰＤＦのデータ）であってもよい。以下、特に断らない限り、単にエレメントと呼ぶ場合、コンテンツを含む。第３の実施の形態のテスト対象システム１２におけるウェブアプリケーションサーバ１４は、ＨＴＭＬコードとＪａｖａＳｃｒｉｐｔ（登録商標）（以下「ＪＡＶＡスクリプト」とも称する）コードにより描画されるエレメントに加えて、Ｊａｖａアプレットにより描画されるコンテンツを含むウェブページをクライアント装置へ送信して表示させる。

図１７は、第３の実施の形態のテスト対象システム１２が提供するウェブページの例を示す。ＵＳＥＲのテキストフィールドおよびログインボタンは、ＨＴＭＬコードとＪａｖａスクリプトコードにより記述され、ウェブブラウザの画面に描画されたエレメントである。これまでのテスト自動実行アプリケーションは、これらのエレメントに対する画面上での操作内容を各エレメントのＩＤに対応付けて記録し、その記録データを利用して自動テストを実行していた。

その一方、図１７のＰＡＳＳＷＯＲＤのテキストフィールドは、Ｊａｖａアプレットコードにより記述され、ウェブブラウザの画面に描画されたコンテンツである。これまでのテスト自動実行アプリケーションは、Ｊａｖａアプレットにより描画されたコンテンツのＩＤを取得できず、その結果、当該コンテンツに対する自動テストを実行することができなかった。

そこで第３の実施の形態のテスト実行装置は、エレメントのレベルでの操作記録を試行するとともに、より低レベル、具体的には、ウェブブラウザの画面における操作位置のレベルで操作を記録する。これにより、少なくとも操作位置のレベルでの操作記録を確保する。テスト実行装置は、２つのレベルでの操作記録を選択的に使い分けて、ウェブページに対する操作を再現する。これにより、ウェブページに対する操作の再現性を高め、自動テストの範囲を拡張する。

以下、図面を参照しつつ、第３の実施の形態の構成を詳細に説明するが、他の実施の形態における装置・機能と同一もしくは対応するものには同一の符号を付している。以下では、他の実施の形態と重複する説明は適宜省略する。なお、第３の実施の形態の構成と他の実施の形態の構成を適宜組み合わせ、また置き換えることが可能であることはもちろんである。

図１８は、第３の実施の形態のテスト実行装置１０の機能構成を示すブロック図であり、図１５に対応する。第３の実施の形態のテスト実行装置１０は、操作記録部４４をさらに備える。他の構成は第１および第２の実施の形態と同様である。なお、第１および第２の実施の形態では明示的に言及していないが、テスト実行装置１０には、キーボード・マウス入力や画面出力といった入出力機能やディスクやメモリの管理等、多くのアプリケーションソフトから共通して利用される基本的な機能を提供し、コンピュータ全体を管理するオペレーティングシステム（ＯＳ）がインストールされている。

操作記録部４４は、ウェブページに対する試験担当者の操作に応じてアクションシートを自動生成する。自動テストの準備として、試験担当者は、ウェブブラウザの画面（ディスプレイに表示されたウェブブラウザのウィンドウとも言え、以下「ブラウザウィンドウ」と呼ぶ。）にテスト対象のウェブページを表示させる。そしてブラウザウィンドウに表示されたウェブページのエレメントに対して、マウスやキーボード等の入力装置を介した各種操作を入力する。例えば、テキストフィールドに対する文字入力操作や、ボタンオブジェクトに対するクリック操作、アイコンに対するドラッグ操作を入力する。操作記録部４４は、ブラウザウィンドウに表示されたウェブページに対する試験担当者の操作内容を示すデータを格納したアクションシートを生成する。

操作記録部４４は、高レベル記録部４５と低レベル記録部４６を含む。高レベル記録部４５は、ブラウザウィンドウのウェブページへ入力された操作の識別情報に対応付けて、そのウェブページに配置されたエレメントであり、試験対象者が操作したエレメントの識別情報であるエレメントロケータをアクションシートへ記録する。以下、高レベル記録部４５がアクションシートへ記録するエレメントＩＤを含むエレメントロケータの情報を高レベル操作情報とも呼ぶ。

具体的には、高レベル記録部４５は、ＣＯＭ（Component Object Model）が提供する公知のＡＰＩを呼び出すことにより、ブラウザウィンドウにおける操作種類と、操作対象エレメントのＩＤを取得する。高レベル記録部４５がＪａｖａ言語により実装される場合、ＣＯＭで予め定められた操作対象エレメントのＩＤを取得するための公知のメソッドをｃｏｍ４ｊを介して呼び出してもよい。また、ブラウザウィンドウをターゲットとしてイベントリスナやアクションリスナを登録し、エレメント操作時にＣＯＭコンポーネント側からコールバック関数を呼び出させることで、操作種類と操作対象エレメントのＩＤを取得してもよい。

低レベル記録部４６は、ブラウザウィンドウのウェブページへ入力された操作の識別情報に対応付けて、当該ブラウザウィンドウにおける操作位置を示す座標情報をアクションシートへ記録する。座標情報は、ブラウザウィンドウのクライアント領域における左上端を原点とした座標系でのＸ座標とＹ座標の組み合わせであってもよい。以下、低レベル記録部４６がアクションシートへ記録する座標情報を低レベル操作情報とも呼ぶ。

具体的には、低レベル記録部４６は、ＯＳが提供する公知のＡＰＩ（ＯＳがＷｉｎｄｏｗｓ（登録商標）であればＷｉｎｄｏｗｓＡＰＩ）を呼び出すことにより、ブラウザウィンドウにおける操作種類と、操作位置を示す座標を取得する。低レベル記録部４６がＪａｖａ言語で実装される場合、ＪＮＩ（Java Native Interface）を介してＯＳのネイティブコードを呼び出してもよい。また、ブラウザウィンドウに対する操作種類と操作位置の座標を取得するコールバック関数をＯＳ側から呼び出させることで、操作種類と操作位置の座標を取得してもよい。

なお操作記録部４４は、試験担当者が事前に操作するテスト対象ウェブページのコードに、操作種類および操作位置の座標を取得するＪａｖａスクリプトコードを追加した後、テスト対象ウェブページをウェブブラウザに表示させてもよい。低レベル記録部４６は、上記のＪａｖａスクリプトコードが出力する操作種類と操作位置の座標を取得してアクションシートへ記録してもよい。

テスト実行部３４は、第１および第２の実施の形態と同様に、アクションシート、データシート、シナリオシートにしたがって、テスト対象システム１２に対する自動テストを実行する。第３の実施の形態のアクションシートには、低レベル記録部４６による低レベル操作情報は常に格納されるが、操作対象がＪａｖａアプレットのコンテンツである場合等、高レベル記録部４５による高レベル操作情報は格納されない場合がある。テスト実行部３４は、テスト対象のウェブページをブラウザウィンドウに表示させ、高レベル操作情報と低レベル操作情報を選択的に使用して、ウェブページに対して入力された操作を再現する。

テスト実行部３４は、ウェブページに対する１つの操作を示すアクションシートの１レコードに、高レベル操作情報と低レベル操作情報の両方が格納されている場合、高レベル操作情報を選択する。このときテスト実行部３４は、高レベル操作情報が示す操作対象エレメントに対して、その高レベル操作情報と対応付けられた操作を入力する。例えば、操作内容を指定する情報と操作対象エレメントのＩＤを引数として、ＣＯＭが提供するエレメント操作用の公知のＡＰＩを呼び出すことにより、ブラウザウィンドウに表示されたウェブページ内のエレメントを操作してもよい。

テスト実行部３４は、ウェブページに対する１つの操作を示すアクションシートの１レコードに、低レベル操作情報のみが格納されている場合、または、高レベル操作情報にもとづくエレメント操作に失敗した場合、低レベル操作情報を選択する。このときテスト実行部３４は、ブラウザウィンドウにおける低レベル操作情報が示す座標位置に、その低レベル操作情報と対応付けられた操作を入力する。例えば、操作内容を指定する情報と操作位置の座標を引数として、ＯＳが提供する入力操作用の公知のＡＰＩを呼び出すことにより、ブラウザウィンドウに表示されたウェブページの特定の位置において操作を入力してもよい。

なおテスト実行部３４は、高レベル操作情報に基づくエレメント操作時に、ＣＯＭのＡＰＩ呼び出し後、所定の待機時間が経過しても、予め定められた応答を受け付けないことをもって、エレメント操作の失敗を検出してもよい。また、ＣＯＭのＡＰＩ呼び出し後、呼び出し先のＣＯＭコンポーネントから所定のエラーが返された場合に、エレメント操作の失敗を検出してもよい。

テスト実行部３４は、低レベル操作情報を選択した場合に、その旨を高レベル記録部４５へ通知する。高レベル記録部４５は、テスト実行部３４が低レベル操作情報に基づいてウェブページを操作することを検出すると、操作対象エレメントの情報取得を試行する。例えば、テスト実行部３４によるテスト実行時にコールバック関数がＣＯＭ側から呼び出された場合に、操作内容と操作対象エレメントのＩＤを取得する。高レベル記録部４５は、操作内容に対応付けて操作対象エレメントのＩＤをアクションシートへ追加記録する。

以上の構成によるテスト時の動作を以下説明する。以下では、図１７に示すウェブページに対する操作を記録し、またその操作を再現する場合の動作を説明する。

試験担当者は、テスト対象システム１２の自動テストを開始させる前に、そのテストで実行させるべきウェブページに対する操作を記録したアクションシートをテスト実行装置１０に自動生成させる。具体的には、試験担当者は、テスト実行装置１０にインストールされたテスト自動実行アプリケーションを起動し、ブラウザウィンドウにテスト対象ウェブページを表示させる。このとき操作記録部４４は、図１９に示すアクションシートの番号１のレコード（以下「レコード１」と呼ぶ、他のレコードも同様）を記録する。

試験担当者は、ＨＴＭＬコードにより描画されたＵＳＥＲのテキストフィールドへ文字列を入力する。このとき低レベル記録部４６は、ＯＳのＡＰＩを介して、文字列入力を示す操作種類情報と操作位置の座標を取得し、アクションシートのレコード２に記録する。
操作位置の座標は、文字入力操作のために試験担当者がクリックした画面上の位置であり、文字入力の開始位置とも言え、ここでは（３００，６００）である。

並行して高レベル記録部４５は、ＣＯＭのＡＰＩを介して、文字列入力を示す操作種類情報と操作対象コンポーネントのＩＤ（ここではｕｓｅｒ）を取得し、アクションシートのレコード２に記録する。図１９の例では、パラメータ２において、高レベル操作情報｜｜低レベル操作情報の形式で記録する。高レベル操作情報は、高レベル記録部４５が取得したエレメントのＩＤを含むエレメントロケータであり、低レベル操作情報は、低レベル記録部４６が取得した座標情報である。

なお低レベル記録部４６は、ＯＳのＡＰＩを介して取得する操作種類情報と、テスト自動実行アプリケーションが予め定める関数との対応関係を保持する。例えば、ＯＳのＡＰＩを介して文字列入力を示す操作種類情報を取得した場合、その操作種類に対応付けられた関数「ｔｙｐｅＴｅｘｔ」をアクションシートに記録する。同様に高レベル記録部４５は、ＣＯＭのＡＰＩを介して取得する操作種類情報と、テスト自動実行アプリケーションが予め定める関数との対応関係を保持する。例えば、ＣＯＭのＡＰＩを介して文字列入力を示す操作種類情報を取得した場合、その操作種類に対応付けられた関数「ｔｙｐｅＴｅｘｔ」をアクションシートに記録する。

試験担当者は、Ｊａｖａアプレットで描画されたＰＡＳＳＷＯＲＤのテキストフィールドへ文字列を入力する。このとき低レベル記録部４６は、ＯＳのＡＰＩを介して、文字列入力を示す操作種類情報と操作位置の座標（ここでは３００，８００）を取得し、アクションシートのレコード３に記録する。ＰＡＳＳＷＯＲＤのテキストフィールドはＪａｖａアプレットコードで描画されているため、高レベル記録部４５は、ＣＯＭのＡＰＩを介して、文字列入力を示す操作種類情報と操作対象コンポーネントのＩＤを取得することはできない。したがって高レベル操作情報は記録されない。

試験担当者は、ＨＴＭＬコードにより描画されたログインボタンをクリックすることにより、ＵＳＥＲテキストフィールドおよびＰＡＳＳＷＯＲＤテキストフィールドへの入力データをウェブアプリケーションサーバ１４へＰＯＳＴさせる。これにより、ウェブアプリケーションサーバ１４（もしくは不図示の認証サーバ）が実行するユーザ認証処理をテストする。

このとき低レベル記録部４６は、ＯＳのＡＰＩを介して、クリック操作を示す操作種類情報と操作位置の座標（クリック位置であり、ここでは６００，９００）を取得し、アクションシートのレコード４に記録する。また低レベル記録部４６は、ＯＳのＡＰＩが返す操作種類情報「クリック操作」に予め対応付けられた関数「ｃｌｉｃｋＢｕｔｔｏｎ」をアクションシートへ記録する。

並行して高レベル記録部４５は、ＣＯＭのＡＰＩを介して、クリック操作を示す操作種類情報と操作対象コンポーネントのＩＤ（ここではｌｏｇｉｎ）を取得し、アクションシートのレコード４に記録する。また高レベル記録部４５は、ＣＯＭのＡＰＩが返す操作種類情報「クリック操作」に予め対応付けられた関数「ｃｌｉｃｋＢｕｔｔｏｎ」をアクションシートへ記録する。以上のステップにより、試験担当者の操作を再現するための図１９のアクションシートが自動生成される。

なお、図１９のパラメータ２「エレメントロケータ」の値は、第１の実施の形態で示したようにデータシートへ設定し、データシートにおける値の設定有無によりテストの実行有無を規定してもよい。この場合、高レベル記録部４５および低レベル記録部４６は、エレメントロケータと座標をデータシートへ格納する。そして、アクションシートのパラメータ２のデータシート列名カラムに、エレメントロケータと座標を格納したデータシートのカラム名を設定する。

また、図１９のパラメータ３は、テキストフィールドへの入力データをデータシートで定めることを規定している。パラメータ３は、試験担当者がデータシートの列名を勘案して手動で設定してもよいが、操作記録部４４が自動で設定してもよい。例えば操作記録部４４は、文字入力等の所定操作を示す関数をアクションシートに記録した場合に、その関数が予め定めるパラメータのうち入力データを設定すべきパラメータについてはデータシートで値を定めるようデータシート列名カラムに所定値（高レベル記録部４５が取得したエレメントＩＤ等）を設定してもよい。

続いて試験担当者はデータシートを作成する。図２０はデータシートを示す。データシートの列名「ｕｓｅｒ」「ｐａｓｓｗｏｒｄ」は、図１９のアクションシートにおけるパラメータ３のデータシート列名に対応する。試験担当者は、図１７のＵＳＥＲテキストフィールドに設定すべき値を、データシートのｕｓｅｒカラムに設定し、図１７のＰＡＳＳＷＯＲＤテキストフィールドに設定すべき値を、データシートのｐａｓｓｗｏｒｄカラムに設定する。

続いて試験担当者はシナリオシートを作成する。図２１はシナリオシートを示す。同図では、図１９のアクションシートのファイル名と、図２０のデータシートのファイル名を指定している。行カラムの「１−３」は、データシートの行１〜行３に格納されたデータを順次使用することを指定するものである。この例では３ユーザのログイン認証を連続してテストするシナリオとなる。なお、第１の実施の形態の図９で示したように、ログイン後に他のアクションを実行すべき場合は、シナリオシートのレコード２以降にアクションシートとデータシートの組み合わせをさらに指定する。

試験担当者は、図２１のシナリオシートを指定したテスト開始指示をテスト自動実行アプリケーションへ入力する。テスト実行部３４は、図１９のアクションシートと図２０のデータシートにしたがってウェブページの自動操作を開始する。テスト実行部３４は、アクションシートのレコード１にしたがってテスト対象ウェブページをウェブアプリケーションサーバ１４から取得し、ブラウザウィンドウに表示させる。

アクションシートのレコード２には、高レベル操作情報と低レベル操作情報の両方が格納されているが、テスト実行部３４は高レベル操作情報を選択する。テスト実行部３４は、アクションシートのレコード２に設定された高レベル操作情報のエレメントロケータと、データシートの行１に設定されたｕｓｅｒ文字列を引数としてｔｙｐｅＴｅｘｔ関数を呼び出す。パラメータ２として高レベル操作情報（すなわちエレメントロケータ）を指定した場合、ｔｙｐｅＴｅｘｔ関数の処理として、（１）エレメントロケータが示すＵＳＥＲテキストフィールドをフォーカスし、（２）当該テキストフィールドへｕｓｅｒ文字列を設定し、（３）ＵＳＥＲテキストフィールドのフォーカスを解除する（フォーカスアウト）操作をブラウザウィンドウへ入力する。

アクションシートのレコード３には、低レベル操作情報のみ格納されているため、テスト実行部３４は低レベル操作情報を選択する。テスト実行部３４は、アクションシートのレコード３に設定された低レベル操作情報の座標と、データシートの行１に設定されたｐａｓｓｗｏｒｄ文字列を引数としてｔｙｐｅＴｅｘｔ関数を呼び出す。パラメータ２として低レベル操作情報（すなわち座標）を指定した場合、ｔｙｐｅＴｅｘｔ関数の処理として、（１）指定された座標をクリックし、（２）ｐａｓｓｗｏｒｄ文字列を設定し、（３）フォーカスアウトする操作をブラウザウィンドウへ入力する。

このようなｔｙｐｅＴｅｘｔ関数による複数種類の処理は、オーバーロード（Ｊａｖａ言語の場合等）により実現してもよい。また、ｔｙｐｅＴｅｘｔ関数内部で引数が高レベル操作情報か低レベル操作情報かを識別し、その識別結果に応じて異なる処理を実行するようｔｙｐｅＴｅｘｔ関数を実装してもよい。

テスト実行部３４が低レベル操作情報に基づくウェブページ操作を実行する際、高レベル記録部４５は、ＣＯＭのＡＰＩを介して、操作対象エレメントの情報取得を試行する。操作対象エレメントのＩＤを取得した場合、高レベル記録部４５は、実行された操作に対応づけて高レベル操作情報をアクションシートへ記録する。この例では、アクションシートのレコード３に対して、高レベル操作情報であるエレメントロケータを追加的に格納する。高レベル操作情報が記録された場合、次回以降のテスト実行時には高レベル操作情報に基づくウェブページ操作が実行される。

アクションシートのレコード４には、高レベル操作情報と低レベル操作情報の両方が格納されているが、テスト実行部３４は高レベル操作情報を選択する。テスト実行部３４は、アクションシートのレコード４に設定された高レベル操作情報のエレメントロケータを引数としてｃｌｉｃｋＢｕｔｔｏｎ関数を呼び出す。パラメータ２として高レベル操作情報（すなわちエレメントロケータ）を指定した場合、ｃｌｉｃｋＢｕｔｔｏｎ関数の処理として、指定されたエレメントロケータをクリックする操作をブラウザウィンドウへ入力する。なお、パラメータ２として低レベル操作情報（すなわち座標）を指定した場合は、ｃｌｉｃｋＢｕｔｔｏｎ関数の処理として、指定された座標をクリックする操作をブラウザウィンドウへ入力する。

テスト実行部３４は、高レベル操作情報に基づくウェブページ操作の失敗を検出した場合、低レベル操作情報に基づくウェブページ操作を実行する。以上の処理を、データシートの行２、行３の分繰り返す。このように、アクションシートに記録された試験担当者によるウェブページの操作を、データシートとシナリオシートの設定に応じて複数回繰り返すことにより、様々なバリエーションの動作テストを効率的に実現できる。

なお、ウェブページに対する操作として、ここでは文字入力とボタンクリックを示したが、他の種類の操作も記録し、再現可能なことはもちろんである。例えば試験担当者がエレメント（アイコン等）のドラッグ操作を実施した場合、高レベル記録部４５は、ドラッグ操作とエレメントロケータを対応付けた高レベル操作情報を記録する。低レベル記録部４６は、ドラッグ操作と、ドラッグ開始位置のＸ座標およびＹ座標、ドラッグ終了位置のＸ座標およびＹ座標を対応付けた低レベル操作情報を記録する。テスト実行部３４は、高レベル操作情報に基づいてＣＯＭのＡＰＩを呼び出し、または、低レベル操作情報に基づいてＯＳのＡＰＩを呼び出すことによりドラッグ操作を再現する。

第３の実施の形態のテスト実行装置１０によると、ウェブページ等の電子文書に対する操作を操作対象のエレメントのレベル（高レベル）で記録するとともに、画面上での操作位置のレベル（低レベル）で記録する。そして、高低それぞれのレベルでの操作記録を選択的に使用して文書に対する操作を再現する。これにより、Ｊａｖａアプレットにより描画されたコンテンツが操作された場合等、高レベル操作情報を記録できない場合も低レベル操作情報を確保し、自動テストでの再現が可能になる。実施の形態では、Ｊａｖａアプレットの例を示したが、高レベル操作情報を記録できない他の種類のエレメント、例えばＰＤＦやＦｌａｓｈ（商標または登録商標）により描画されたオブジェクトが文書に含まれる場合も同様の効果を奏し、自動テストが可能な範囲を拡張することができる。

またテスト実行装置１０によると、文書に対する操作再現時に、低レベル操作情報より高レベル操作情報を優先して使用する。低レベル操作情報は、ディスプレイ上の座標を記録したものであるため、ディスプレイの種類や解像度が変更された場合に再現性が低くなる可能性がある。高レベル操作情報は、ディスプレイの種類や解像度等、ユーザインタフェース環境への依存度が低いため、高レベルの操作記録を優先して使用することで、操作の再現性を高めることができる。

またテスト実行装置１０によると、高レベル操作情報に基づく文書操作に失敗した場合に、低レベル操作情報に基づく文書操作を試行する。これにより、仮に文書内のエレメントＩＤが変更された場合も操作の再現性を高め、動作テストの失敗を回避しやすくなる。また、アクションシートを再生成するための試験担当者の負担も軽減できる。

またテスト実行装置１０によると、低レベル操作情報に基づく文書操作時に、操作対象エレメント（コンテンツ）の情報を取得可能であれば高レベル操作情報を新たに記録する。これにより、文書が変更された場合や、テスト自動実行アプリケーションの機能が拡張された場合に、高レベル操作情報を追加的に記録でき、アクションシートの最適化を自動的に図ることができる。

文書が変更された場合とは、例えば、低レベル操作情報しか記録できないエレメントが、高レベル操作情報を記録できるエレメントに置き換えられた場合である。また、テスト自動実行アプリケーションの機能が拡張された場合とは、例えば、当該アプリケーションがＪａｖａアプレットに対応し、すなわちＪａｖａアプレットのオブジェクトの識別情報を取得可能になり、Ｊａｖａアプレットのオブジェクトを指定した操作が可能になった場合である。また例えば、テスト自動実行アプリケーションがＦｌａｓｈに対応し、すなわち、ＡｃｔｉｏｎＳｃｒｉｐｔのオブジェクトの識別情報を取得可能になり、ＡｃｔｉｏｎＳｃｒｉｐｔのオブジェクトを指定した操作が可能になった場合である。

以上、本発明を第３の実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記第３の実施の形態では、高レベル操作情報の取得有無にかかわらず低レベル操作情報をアクションシートへ記録することとしたが、高レベル操作情報が取得できた場合は低レベル操作情報の取得と記録をスキップしてもよい。また上記第３の実施の形態では、高レベル操作情報の取得方法として、ＣＯＭを介してエレメントＩＤを取得することを示したが、テスト自動実行アプリケーションの機能拡張により、高レベル操作情報の別の取得方法が追加されることもあり得る。その場合、それぞれの方法で高レベル操作情報が取得できるか否かを判定してもよい。例えば以下のような処理を実行してもよい。

（１）高レベル操作情報取得１：ＣＯＭを介してエレメントＩＤを取得する、情報が取得できなければ（２）へ進む。
（２）高レベル操作情報取得２：機能拡張により追加された手法Ａで高レベル操作情報を取得する、取得できなければ（３）へ進む。
（３）高レベル操作情報取得３：機能拡張により追加された手法Ｂで高レベル操作情報を取得する、取得できなければ（４）へ進む。
（４）低レベル操作情報取得：高レベル操作情報が取得できないため、低レベル操作情報を取得する。実施の形態のように高レベル操作情報の取得可否にかかわらず常に低レベル操作情報を取得してもよい。
これにより、高レベル操作情報を取得する確実性を一層高めることができる。

また、上記第３の実施の形態では言及していないが、図１９に示すようにアクションシートに「レベル」のカラムを設けてもよい。「レベル」のカラムの値（以下「レベル値」と呼ぶ。）として高または低を設定可能であってよく、そのデフォルト値は高であってもよい。テスト実行部３４は、レベル値に一致する高レベル操作情報または低レベル操作情報に基づいてウェブページを操作してもよい。例えば、レベル値が高であれば実施の形態と同様に操作する一方、レベル値が低であれば、アクションシートに高レベル操作情報が記録されていても、低レベル操作情報に基づいてウェブページを操作してもよい。この構成によると、試験担当者が必要に応じて任意に、低レベル操作情報を使用してテストするよう指示することができる。

高レベル記録部４５は、テスト実行部３４が低レベル操作情報に基づいてウェブページを操作する際に、レベル値が高であれば、実施の形態で示したように高レベル操作情報の取得と記録を試行してもよい。その一方、レベル値が低であれば、高レベル操作情報の取得と記録の試行をスキップしてもよい。これにより、試験担当者が不要と判断する高レベル操作情報の取得と記録を任意にスキップさせることができる。

また、上記第３の実施の形態では言及していないが、テスト実行装置１０は、高レベル操作情報に基づく文書操作が失敗した場合に、その高レベル操作情報をアクションシートから削除する操作記録削除部をさらに備えてもよい。これにより、テストの都度、言い換えれば、当該高レベル操作情報に対応付けられた操作を実行する都度、操作に失敗し、またエラーが発生することを回避できる。また、一旦高レベル操作情報を削除しても、低レベル操作情報に基づく文書操作時に、高レベル記録部４５は、高レベル操作情報の取得と記録を試行する。したがって、エレメントＩＤが変更された場合等、それまでの高レベル操作情報が無効になった場合でも、最新の高レベル操作情報をアクションシートへ自動で反映させ、次回のテストでは最新の高レベル操作情報に基づくテストを再開させることができる。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０ テスト実行装置、 １２ テスト対象システム、 １８ ファイアウォール、 ２２ シナリオ保持部、 ２４ アクションシート保持部、 ２６ データシート保持部、 ２８ テスト結果保持部、 ３３ 業務イベント状態監視部、 ３４ テスト実行部、 ３６ 証跡取得部、 ３８ テスト結果判定部、 ４０ テスト結果記録部、 ４４ 操作記録部、 ４５ 高レベル記録部、 ４６ 低レベル記録部。

Claims (3)

1. 入力された業務イベントの処理を複数の工程を経て完了するシステムをテストする装置であって、
   前記業務イベントに関して予め定められた情報を第１工程の画面へ自動入力し、前記業務イベントに対する第１工程のオンライン処理を前記システムに実行させるテスト実行部と、
   前記システムが、前記業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行すべき所定のバッチ処理を実行し、そのバッチ処理の終了を示す情報を所定の記憶領域へ格納した場合に、その事実を検出する検出部と、
   を備え、
   前記テスト実行部は、前記事実が検出された場合に、前記業務イベントに関して予め定められた情報を第１工程の次の第２工程の画面へ自動入力し、前記業務イベントに対する第２工程のオンライン処理を前記システムに実行させることを特徴とするテスト実行装置。
2. 入力された業務イベントの処理を複数の工程を経て完了するシステムをテストする装置が、
   前記業務イベントに関して予め定められた情報を第１工程の画面へ自動入力し、前記業務イベントに対する第１工程のオンライン処理を前記システムに実行させるステップと、
   前記システムが、前記業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行すべき所定のバッチ処理を実行し、そのバッチ処理の終了を示す情報を所定の記憶領域へ格納した場合に、その事実を検出するステップと、
   前記事実が検出された場合に、前記業務イベントに関して予め定められた情報を第１工程の次の第２工程の画面へ自動入力し、前記業務イベントに対する第２工程のオンライン処理を前記システムに実行させるステップと、
   を実行することを特徴とするテスト実行方法。
3. 入力された業務イベントの処理を複数の工程を経て完了するシステムをテストする装置に、
   前記業務イベントに関して予め定められた情報を第１工程の画面へ自動入力し、前記業務イベントに対する第１工程のオンライン処理を前記システムに実行させるテスト実行機能と、
   前記システムが、前記業務イベントに対する第１工程のオンライン処理を終了後、定期間隔で実行すべき所定のバッチ処理を実行し、そのバッチ処理の終了を示す情報を所定の記憶領域へ格納した場合に、その事実を検出する機能と、
   を実現させ、
   前記テスト実行機能は、前記事実が検出された場合に、前記業務イベントに関して予め定められた情報を第１工程の次の第２工程の画面へ自動入力し、前記業務イベントに対する第２工程のオンライン処理を前記システムに実行させることを特徴とするコンピュータプログラム。

Images