JP2014010581A - テスト装置、テストシステム、テスト方法、及びプログラム - Google Patents

Abstract

【課題】
複数のクライアントアプリアプリケーションを用いたテストの効率化を可能とするテスト装置を実現する。
【解決手段】
実施形態は、複数のクライアントアプリケーションを用いてアプリケーションのテストを実行するテスト装置であって、ユーザ操作を検出するユーザ操作検出部と、ユーザ操作に基づいて発生するイベントデータを取得するイベント取得部と、ユーザ操作結果の第１データを取得する操作結果取得部と、イベントデータと第１データとをそれぞれ複数のクライアントアプリケーションの共通書式に変換する書式変換部と、イベントデータと第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、共通書式に変換されたテストシナリオをクライアントアプリケーションに配信するテストシナリオ配信部と、配信されたテストシナリオに基づいてアプリケーションのテストを実行するテストナリオ実行部と、を備える。
【選択図】図２

Description

本発明の実施形態は、テスト装置、テストシステム、テスト方法、及びプログラムに関する。

通信を行うアプリケーションプログラム（以下、アプリケーションという）をテストするためのテスト装置がある。このテスト装置は、テスト対象のアプリケーションにユーザ端末（以下、クライアント端末という）からアクセスし、クライアント端末の画面に表示されたボタンや入力フォーム等を操作して、その操作の実行結果を確認する。このときクライアント端末は、アプリケーションの操作を行なうクライアント向けアプリケーション（以下、クライアントアプリという）を備える。クライアントアプリは、例えばブラウザやアプリケーションの開発ツールである。

クライアント端末におけるクライアントアプリの操作やクライアントアプリからの処理要求をイベントといい、テストで実行するすべてのイベントのデータ（以下、イベントデータという）とその実行結果を、テストを実行する順に並べた集合体をテストシナリオという。

従来のテスト装置は、イベントデータだけでなくクライアントアプリを用いてアプリケーションを操作することによってクライアント端末の画面に描画されたボタン等の画像データそのものをテストシナリオに導入しテストを実行する場合であって、１つのアプリケーションへのテストを複数のクライアントアプリで実行する場合、１つのテストシナリオをそれぞれのクライアントアプリで実行し、全クライアントアプリに関するテスト結果にて問題がないかを確かめることも可能である。

しかしながら、上記のようなテスト装置では、画像データそのものをテストシナリオに導入する場合に、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：以下、ＯＳという）などの環境や、クライアントアプリが異なる場合はテストシナリオを再利用することができない。

これは、テスト装置は画面に表示された画像そのものを認識して動作するため、異なる環境下では、同じ部品画像で構成された画像データあっても表示された画像のレイアウト、文字のサイズ、もしくは背景色が異なってしまうためである。

したがって、画像データそのものをテストシナリオに導入する場合、クライアントアプリ毎にテストシナリオを作成する必要があるため、テストを実行する際の効率が悪いという問題がある。

一方、イベントデータのみをテストシナリオとするテスト装置では、異なるブラウザでテストシナリオを再利用することが可能である。しかしながら、テスト担当者（ユーザ）はそれぞれのブラウザにテストシナリオを手動で配置しなければならない。そのためテストシナリオ自体は１つでよいが、テストの事前準備は、テスト対象となるブラウザの数に比例して時間がかかってしまうという問題がある。また、ブラウザ以外のクライアントアプリではテストシナリオを再利用することができないため、複数のクライアントアプリにおけるイベントを組み合わせたテストの実行ができず、クライアント毎にテストを分けて実行しなければならず効率が悪いという問題もある。

特開２００９−１４０１５５号公報

本発明が解決しようとする課題は、複数のクライアントアプリケーションを用いるテストの効率化を可能とするテスト装置を実現することである。

実施形態は、複数のクライアントアプリケーションを用いてアプリケーションのテストを実行するテスト装置であって、ユーザ操作を検出するユーザ操作検出部と、ユーザ操作に基づいて発生するイベントデータを取得するイベント取得部と、ユーザ操作部による操作結果である第１データを取得する操作結果取得部と、イベントデータと第１データとをそれぞれ複数のクライアントアプリケーションの共通書式に変換するルールに基づいてイベントデータと第１データとをそれぞれ共通書式に変換する書式変換部と、イベントデータと第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、共通書式に変換されたテストシナリオをクライアントアプリケーションに配信するテストシナリオ配信部と、配信されたテストシナリオに基づいて複数のクライアントアプリケーションのテストを実行するテストナリオ実行部と、を備える。

本実施形態に係るテスト装置のハードウェア構成の一例を示すブロック図 本実施形態に係るテスト装置の機能構成の一例を示すブロック図。 本実施形態に係るテスト装置のステップ情報の一例を示す図。 本実施形態に係るテスト装置の動作の一例を示すフローチャート。 本実施形態に係るテスト装置のステップ情報作成処理の一例を示すフローチャート。 本実施形態に係るテスト装置のユーザ操作の概念図。 本実施形態に係るテスト装置のクライアント端末の画面の一例を示す図。 本実施形態に係るテスト装置のステップ情報の一例を示す図。 本実施形態に係るテスト装置の変換ルールの概念図。 本実施形態に係るテスト装置の操作結果画面の一例を示す図。 本実施形態に係るテスト装置のステップ情報の一例を示す図。 本実施形態に係るテスト装置の動作の一例を示すフローチャート。 本実施形態に係るテスト装置の動作の一例を示すフローチャート。 本実施形態に係るテスト装置のテストシナリオ記憶部に登録されたテストシナリオの一例を示す図。 本実施形態に係るテスト装置。 本実施形態に係るテスト装置のテスト結果記憶部に登録されたテスト結果合否定結果の一例を示す図。

以下、図面を参照して本発明の実施形態に係るテスト装置について説明する。

（本実施形態）
以下、図１乃至図１６を参照して本実施形態のテスト装置１００について説明する。

図１に示すように、本実施形態のテスト装置１００は、アプリケーションプログラムのテストを実行する３つのクライアントアプリケーション（クライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１）を１つずつ備える３台のクライアント端末（クライアント端末１１０、クライアント端末１２０、およびクライアント端末１３０）とサーバコンピュータ（以下、サーバという）２００とが、ネットワーク３００を介して接続された構成である。

クライアント端末１１０はクライアントアプリ１１１を備える端末であり、例えば一般的なパーソナルコンピュータ（以下、ＰＣという）や、タブレットＰＣ、スマートフォンなどである。

クライアント端末１１０と同様に、クライアント端末１２０はクライアントアプリ１２１を備える端末であり、クライアント端末１３０はクライアントアプリ１３１を備える端末である。

クライアント端末１１０、クライアント端末１２０、クライアント端末１３０は、それぞれが備えるクライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１で実施したテストの手順とこのテストの動作結果の情報とを用いてテストシナリオを作成し、作成したテストシナリオをサーバ２００に送信する機能を有する。また、クライアント端末１１０、クライアント端末１２０、クライアント端末１３０は、サーバ２００から配信されたテストシナリオに基づいてそれぞれが備えるクライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１を動作させ、アプリケーションのテストを実行する機能も有する。

クライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１は、例えばテスト対象のアプリケーションのブラウザやアプリケーション開発ツール、もしくはアプリケーションプログラミングインタフェース（以下、ＡＰＩという）である。本実施形態では３つのクライアントアプリ（クライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１）は異なる種類であるとする。

なお、１つのクライアント端末１１０が複数の異なるクライアントアプリを備える構成も可能である。また、各クライアント端末１１０が、異なる個数のクライアントアプリを備えることも可能である。

サーバ２００はコンピュータ２１０と記憶装置２２０を備える。コンピュータ２１０は、ハードディスクドライブなどの記憶装置２２０と接続されている。この記憶装置２２０は、コンピュータ２１０によって実行されるアプリケーションプログラムであるプログラム２３０を記憶している。すなわち、記憶装置２２０は、プログラム２３０を記憶する記憶媒体として機能する。このプログラム２３０によってテスト装置１００の各機能が実現される。なお、記憶装置２２０がテスト対象のクライアントアプリを記憶してテストしてもよい。もしくは、サーバ２００から外部にあるテスト対象のクライアントアプリにネットワーク経由でアクセスしてテストしてもよい。

サーバ２００は、クライアント端末１１０、１２０、１３０のいずれかに１台において作成されたテストシナリオやクライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１で実行されたテストの結果を記憶する。また、サーバ２００はこのテストシナリオを、テストを実行するクライアントアプリ１１１、クライアントアプリ１２１、クライアントアプリ１３１に配信する。サーバ２００は、例えば、一般的なＰＣで実現される。

ネットワーク３００は、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であり、クライアント端末１１０、１２０、１３０とサーバ２００との間でデータの通信を行なう。

すなわち、テスト装置１００はクライアント端末１１０、１２０、１３０とサーバ２００とで構成されるテストシステム１００といえる。なお、テスト装置１００に含まれるクライアント端末は３台に限らない。

また、テスト装置１００を１台のＰＣで構成することも可能である。１台のＰＣでテスト装置１００を構成する場合、例えばサーバ２００の機能を備えるＰＣ上で複数のクライアントアプリが実行される。また、クライアント端末１１０、１２０、１３０とサーバ２００はネットワーク３００を介さず接続することも可能である。

ここで、図２を参照して、本実施形態のテスト装置１００の機能構成について説明する。

なお、本実施形態ではクライアント端末１１０で動作するクライアントアプリ１１１においてテストシナリオが作成されるとし、図２にはクライアント端末１１０の機能構成のみを示す。テスト装置１００が備える他の２台のクライアント端末１２０、１３０は、クライアント端末１１０とクライアントアプリの種類のみが異なり、他の機能構成は同一であるため説明は省略する。

図２に示すように、クライアント端末１１０は、クライアントアプリ１１１、クライアントアプリ登録部１１２、ユーザ操作検出部１１３、イベント取得部１１４、操作結果画面取得部１１５、テストシナリオ実行部１１６、書式変換部１１７、変換ルール記憶部１１８、及びテスト結果合否判定部１１９を備える。

クライアントアプリ登録部１１２は、アプリケーション上でテストを実行するクライアントアプリ１１１の情報（以下、クライアントアプリ情報という）をサーバ２００に登録するため、サーバ２００にクライアントアプリ情報を送信する。クライアントアプリ情報は、例えばクライアントアプリの種類と、当該クライアントアプリを有するクライアント端末１１０を示す識別子とを対応付けたデータである。送信されたクライアントアプリ情報は後述するクライアントアプリ情報記憶部２０２に登録される。

クライアントアプリ登録部１１２は、例えばクライアント端末１１０に備えられるプラグインによって実現される。本実施形態のテスト装置１００では、テストを実行する事前に各クライアント端末１１１のクライアントアプリ登録部１１２によってクライアントアプリ１、クライアントアプリ２、及びクライアントアプリ３がサーバ２００に登録される。

ユーザ操作検出部１１３は、ユーザがクライアントアプリ１１１に対して行なった操作を検出し、検出結果をイベント取得部１１４と操作結果画面取得部１１５に通知する。検出結果である操作情報（以下、ユーザ操作情報という）は、クライアントアプリ１１１のＧｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅの部品（以下、ＧＵＩ部品という）上でのマウスクリックやキーボードの入力等の情報を指す。ＧＵＩ部品とは、ＧＵＩにおけるユーザが操作するためのボタンなどのことである。

イベント取得部１１４は、ユーザ操作検出部１１３によって検出されたユーザ操作情報を受信し、当該ユーザ操作情報に基づいて検出したクライアントアプリ１１１に発生したイベントの情報（以下、イベントデータという）を取得する。イベントは、例えば「ＩＤがＸＸＸのボタンが押された」「ＩＤがＹＹＹのフォームに文字列「ａｂｃ」が入力された」等、ユーザによるクライアントアプリ１１１の操作によって発生する。

操作結果画面取得部１１５は、ユーザ操作検出部１１３によって検出されたユーザ操作情報の検出通知を受けて、その操作の結果としてクライアントアプリ１１１に表示された画面の情報（以下、第１データもしくは操作結果画面情報という）を取得する。操作結果画面情報とはソースコードを指す。例えば、クライアントアプリ１１１がインターネットブラウザの場合は、画面の情報はＨＴＭＬ形式の文書となる。

テストシナリオ実行部１１６は、ユーザ操作検出部１１３が検出したユーザ操作に基づいて、イベント取得部１１４が取得したイベントデータと、操作結果画面検出部１１５が検出した操作結果画面情報とを関連づけてテストの手順の１つであるステップ情報を作成する。また、テストシナリオ実行部１１６は、後述するテストシナリオ配信部２０４から配信されるテストシナリオに基づいて、クライアントアプリ１１１のテストを実行する。

ここで、図３を参照して本実施形態におけるステップ情報の一例について説明する。図３に示すように、ステップ情報１２０ａは、ステップＩＤ１２０ａＡ、クライアントアプリＩＤ１２０ａＢ、イベントデータ１２０ａＣ、入力データ１２０ａＤ、操作結果画面情報１２０ａＥ、及び結果比較フラグ１２０ａＦを含む。

ステップＩＤ１２０ａＡは、当該ステップ情報１２０ａを一意に定めるための識別子であり、例えば、本実施形態ではステップ情報１２０ａが作成された順に番号が付与される。

クライアントアプリＩＤ１２０ａＢは、当該ステップ情報１２０ａが作成されたクライアントアプリを一意に定める識別子である。例えばクライアントアプリ１１１において作成されたステップ情報１２０ａのクライアントアプリＩＤ１２０ａＢは「１１１」とする。このクライアントアプリＩＤ１２０ａＢによって、ユーザ操作検出部１１３がどのクライアントアプリ上のユーザ操作を検出したのかを判定する。

イベントデータ１２０ａＣは、イベント取得部１１４が取得したイベントデータであり、例えばユーザ操作情報や操作対象のＧＵＩ部品を含む。

入力データ１２０ａＤは、入力テキストの情報であり、イベントデータ１２０ａＣに含まれるＧＵＩ部品がフォームの場合などに取得される。

操作結果画面情報１２０ａＥは、操作結果画面取得部１１５が取得した結果画面情報（ソースコード）である。

結果比較フラグ１２０ａＦは、後述するテスト結果合否判定部１１９がテスト結果合否判定処理を行うか否かを指定するフラグである。このフラグが「ｔｒｕｅ」の場合は、テスト結果合否判定処理を行い、「ｆａｌｓｅ」の場合は判定を行なわない。結果比較フラグ１２０ａＦはあらかじめ「ｔｒｕｅ」で設定されており、例えばステップ情報１２０ａに含まれるイベントデータ１２０ａＣがテストの途中の操作で発生した場合、この結果だけではテストの合否を判定できないため、後述するテストシナリオ編集処理においてこのフラグは「ｆａｌｓｅ」と編集する。

上述の項目が含まれる１つのステップ情報１２０ａは１つのユーザ操作に相当する。本実施形態ではユーザがクライアントアプリ１１１の操作を１回実施する毎に、テストシナリオ実行部１１６はステップ情報１２０ａを１つ作成する。ユーザがクライアントアプリ１１１に操作完了を入力すると、テストシナリオ実行部１１６が作成したステップ情報１２０ａが書式変換部１１７によって共通書式に変換されサーバ２００に送信される。

書式変換部１１７は、クライアント端末１１０とサーバ２００とのテストシナリオの送受信において、後述する変換ルール記憶部１１８に記憶された変換ルールに基づいて、テストシナリオ作成対象のクライアントアプリ１１１ごとに固有の書式を、クライアントアプリ間の共通の書式（以下、共通書式という）に変換する共通書式化処理を行い、共通書式化処理後のテストシナリオをサーバ２００に送信する。すなわち、共通書式化処理においては各ステップ情報１２０ａが共通書式に変換される。サーバ２００は、共通書式化後のテストシナリオデータを受信する。

変換ルール記憶部１１８は、書式変換部１１７に参照される変換ルールが記憶されている。変換ルールは、テストシナリオを共通書式に変換するためのルールである。

テスト結果合否判定部１１９は、サーバ２００から配信されたテストシナリオに基づいて各クライアントアプリ１１１、１２１、１３１がテストを実行した結果、各クライアントアプリ１１１、１２１、１３１に表示される画面情報（第２データ）と、当該テストシナリオに含まれる操作結果画面情報１２０ａＥ（第１データ）とを比較し、テスト結果が合格か否かを判定する。なお、画面の比較は、例えば画面の一部、あるいは全体を比較し、ほぼ一致すれば合格、そうでなければ不合格であると判定する。

クライアント端末１１０が接続されるサーバ２００は、テストシナリオ配信部２０１、クライアントアプリ情報記憶部２０２、テストシナリオ登録部２０３、テストシナリオ記憶部２０４、テストシナリオ編集部２０５、及びテスト結果記憶部２０６を備える。

テストシナリオ配信部２０１は、クライアント端末１１０から送信されたクライアントアプリ情報と、ステップ情報１１６ａと、テスト結果と、テスト結果の合否判定結果を受信する。

具体的には、テストシナリオ配信部２０１は、クライアント端末１１０のクライアント登録部１１２からクライアントアプリ情報を受信すると、このクライアントアプリ情報をクライアントアプリ情報記憶部２０２に登録する。また、テストシナリオ配信部２０１が、書式変換部１１７からステップ情報１１６ａを受信すると、テストシナリオ登録部２０３がこのステップ情報１１６ａをテストシナリオ記憶部２０４に登録する。また、テストシナリオ配信部２０１はテスト結果もしくはテスト結果の合否判定結果を受信すると、テスト結果記憶部２０６に登録する。

また、テストシナリオ配信部２０１は、テストシナリオ記憶部２０４に記憶されたテストシナリオを、テストを実行するクライアントアプリに配信する。このとき、テストシナリオ配信部２０１は、クライアント情報記憶部２０２に記憶されたクライアントアプリ情報に基づいて配信先のクライアントアプリを示す配信先クライアントデータを作成し、この配信先クライアントデータに基づいてテストシナリオを配信する。なお、本実施形態のテストシナリオ配信部２０１は、テストシナリオに含まれるステップ情報１２０ａ毎にクライアントアプリへ配信する。

テストシナリオ登録部２０３は、テストシナリオ配信部２０１がクライアント端末１１０から受信したステップ情報１２０ａをテストシナリオとしてテストシナリオ記憶部２０４に登録する。

テストシナリオ編集部２０５は、テストシナリオ記憶部２０４に記憶されたテストシナリオやテストシナリオ配信部２０２によるテストシナリオの配信先を編集するテストシナリオ編集処理を行う。テストシナリオ編集処理は、例えばテストを実行するクライアントアプリ毎に異なる操作が必要な場合や、配信先のクライアントアプリにおけるテストの実行結果がテストシナリオに含まれる操作結果画面情報と必ず異なるものになることが事前に把握できている場合等に行なわれる。

なお、テスト装置１００の各機能は、サーバ２００の記憶装置２２０が記憶しているプログラム２３０をコンピュータ２１０が実行することによって実現する。

ここで、本実施形態におけるテスト装置１００の動作について図４乃至図１６を参照して説明する。図４は、本実施形態のテスト装置１００における動作の一例を示すフローチャートである。以下、「クライアントアプリ１１１において表示される入力フォームに『ａｂｃ』と入力し（以下、この操作をユーザ操作Ａという）、その後送信ボタンを押す（以下、この操作をユーザ操作Ｂという）」というテストシナリオをクライアントアプリ１１１において作成してサーバ２００に作成したテストシナリオを登録し、このテストシナリオをクライアント１１１、１２１、１３１に配信する場合のテスト装置１００の動作について具体的に説明する。

図４に示すように、まず、テストの担当者（以下、ユーザという）が、テストを実行するクライアントアプリのうち、テストシナリオ作成対象であるクライアントアプリ１１１においてテストを実行するために必要な操作を順次実施すると、クライアントアプリ１１１を備えるクライアント端末１１０はユーザ操作ごとにステップ情報１２０ａを作成し、作成したステップ情報１２０ａをサーバに送信するステップ情報作成処理を行う（ステップＳ１０）。

ここで、図５乃至図１１を参照して、本実施形態のテスト装置１００におけるステップ情報作成処理について説明する。図５は、本実施形態のテスト装置１００におけるステップ情報作成処理の一例を示すフローチャートである。ここでは、クライアントアプリ１１１においてステップ情報１２０ａが作成される。

ユーザがテスト装置１００においてテストシナリオを作成するために必要な全てのユーザ操作を実行していない場合（ステップＳ１１がＮｏ）、ユーザがクライアント端末１１０上のクライアントアプリ１１１を操作すると、ユーザ操作検出部１１３がこのユーザ操作を検出する（ステップＳ１２）。なお、ステップＳ１１においてユーザがテスト装置１００においてテストを実行するために必要な全てのユーザ操作を実行したかの判定は、前回のユーザ操作から所定以上の時間が経過したか、終了ボタン（図示しない）をクリックしたか、などで判定する。

ユーザ操作について、図６及び図７を参照して説明する。図６はクライアントアプリ１１１をユーザが操作するためのＧＵＩであるクライアント端末１１０の画面１４０（以下、クライアント画面１４０という）の一例である。図６に示すように、クライアント画面１４０は入力フォーム１４１と送信ボタン１４２をＧＵＩ部品として備える。図７は本実施形態におけるユーザ操作Ａにおけるクライアント画面１４０−Ａの一例である。図７に示すようにクライアント画面１４０−Ａは、クライアント画面１４０の入力フォーム１４１に「ａｂｃ」が表示された画面である。すなわち、ステップＳ１２では、ユーザ操作検出部１１３は入力フォーム１４１に「ａｂｃ」が入力されたことを検出する。

続いて、イベント取得部１１４が、ユーザ操作検出部１１３が検出したユーザ操作Ａによってクライアントアプリ１１１上に発生したイベントデータ１２０ａＣを取得する（ステップＳ１３）。
また、操作結果画面取得部１１５は、ユーザ操作検出部１１３が検出したユーザ操作Ａの結果の入力データ１２０ａＤと操作結果画面情報１２０ａＥを取得する（ステップＳ１４）。ユーザ操作Ａの結果、画面は変化していないため、ここで検出される操作結果画面情報１２０ａＥは「ｎｕｌｌ」であり、入力データ１２０ａＤが取得される。

テストシナリオ実行部１１６は、イベント取得部１１４によって取得されたイベントデータ１２０ａＣと、操作結果画面取得部１１５によって取得された入力データ１２０ａＤと操作結果画面情報１２０ａＥとに基づいてステップ情報１２０ａを作成する（ステップＳ１５）。

図８に、ユーザ操作Ａに対するステップ情報１２０ａ（以下、ステップ情報１２０ａ−Ａと記載する）の具体例を示す。図８に示すように、ステップ情報１２０ａ−Ａは、ステップＩＤ１２０ａＡが「ｓｔｅｐ１」、クライアントアプリＩＤ１２０ａＢが「クライアントアプリ１」、イベントデータ１２０ａＣが、
「ｆｕｎｃｔｉｏｎ ｔｅｓｔ（ ） ｛
ｄｏｃｕｍｅｎｔ．ｇｅｔＥｌｅｍｅｎｔＢｙＩｄ（"ｕｓｅｒＩｄ"）．ｖａｌｕｅ ＝ "ａｂｃ"；
｝」、
入力データ１２０ａＤが、「ａｂｃ」、操作結果画面情報１２０ａＥが「ｎｕｌｌ」、結果比較フラグ１２０ａＦが「ｔｒｕｅ」である。

続いて、書式変換部１１７が、作成されたステップ情報１２０ａを取得し、変換ルール記憶部１１８に記憶された変換ルールに基づいて、このステップ情報１２０ａの書式を共通書式に変換する共通書式化処理を行う（ステップＳ１６）。なお、ここでは、書式変換部１１７がステップ情報１２０ａを取得するタイミングは、ステップ情報１２０ａが作成される都度とするが、例えば作成されたステップ情報１２０ａを記憶装置に保存し、あらかじめ設定された所定の周期が到来した場合に書式変換部１１７が保存されたステップ情報１２０ａを取得してもよい。

イベント取得部１１４が取得するイベントデータ１２０ａＣや操作結果画面取得部１１５が取得する入力データ１２０ａＤ、操作結果画面情報１２０ａＥは、クライアントアプリ１１１の種類に応じて異なる固有の書式で作成される。例えば、本実施形態ではクライアントアプリ１１１がＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ（登録商標：以下、ＩＥと記載する）であり、クライアントアプリ１２１がＦｌｅｘであり、クライアントアプリ１３１がＷｉｎｄｏｗｓ（登録商標）Ｆｏｒｍであるとすると、クライアントアプリ１１１、１２１、１３１で同じユーザ操作が行なわれたとしてもイベントデータ１２０ａＣや入力データ１２０ａＤ、操作結果画面情報１２０ａＥの書式は異なる。本実施形態の共通書式化処理では、クライアントアプリの種類ごとに固有の書式を共通書式に変換してサーバ２００に送信する。共通書式化することで、後述するテストシナリオ編集処理を一括して行なうことが可能になる。このとき変換する共通書式はあらかじめ設定されており、例えば、最も数が多いクライアントアプリの書式とする。

なお、クライアントアプリ１１１、１２１、１３１毎の固有書式から共通書式への変換する共通書式化処理は、変換ルール記憶部１１８に記憶された変換ルールに基づいて実施される。この変換ルールは、あらかじめクライアント端末１１０に配置された変換ルール記述ファイルから取得する。変換ルールはテストを実行するクライアントアプリの種類が共通書式と異なるものの数だけ必要である。本実施形態のテスト装置１００におけるクライアント１１１、１２１、１３１の書式は、それぞれ、クライアントアプリ１１１がＪａｖａＳｃｒｉｐｔ（登録商標）であり、クライアントアプリ１２１がＡｃｔｉｏｎＳｃｒｉｐｔであり、クライアントアプリ１３１がＣ＋＋であるとし、共通書式をＪａｖａＳｃｒｉｐｔ（登録商標）とする。この場合本実施形態の変換ルールは２種類である。

図９を参照して本実施形態に変換ルール概念について説明する。図９は、本実施形態のクライアントアプリ１１１、１２１、１３１においてユーザ操作Ａが行なわれた場合にイベント取得部１１４が取得するイベントデータ１２０ａＣを比較するテーブルである。図９に示すように、クライアントアプリ１１１、１２１、１３１で生成されるそれぞれのイベントデータ１２０ａＡは、「第１固定文字列１２０ａＣ−１」、「部品ＩＤ１２０ａＣ−２」、「第２固定文字列１２０ａＣ−３」、「入力データ１２０ａＣ−４」、「第３固定文字列１２０ａＣ−５」という項目で構成される。

部品ＩＤ１２０ａＣ−２及び入力データ１２０ａＣ−４は、ユーザ操作Ａから取得する共通の変数であるため変換は必要ない。これら以外の第１固定文字列１１２０ａＣ−１、第２固定文字列１２０ａＣ−３、第３固定文字列１２０ａＣ−５についてはクライアントアプリの種類に応じて異なるため、共通書式に置き換えることで、クライアントアプリ間のデータ変換が可能となる。変換ルールは、例えば、上述のようにイベントデータ１２０ａＣの共通書式への変換が必要な部分と、変換が不要な部分とを判別するためのルールである。ここでは、入力フォームへの入力についての記述を一例としてあげているが、画面部品の操作についても同様にして書式変換を行なうことが可能である。

なお、本実施形態では共通書式をＪａｖａＳｃｒｉｐｔ（登録商標）とするため、クライアントアプリ１１１でテストシナリオを作成する場合は共通書式化処理を省略してステップＳ１７に進んでもよい。

ステップＳ１７では、書式変換部１１７は、共通書式化処理後のステップ情報１２０ａをサーバ２００に送信する（ステップＳ１７）。その後、テスト装置１００は、ステップＳ１１に戻り処理を繰り返す。

続いて、ユーザ操作Ｂをユーザ操作検出部１１３が検出し（ステップＳ１２）、以下ステップＳ１３〜ステップＳ１７の処理が実行される。図１０にユーザ操作Ｂが実行された場合の操作結果画面１４０（以下、操作結果画面１４０−Ｂとする）の一例を示す。図１０に示すように操作結果画面１４０−Ｂには「ｈｅｌｌｏ ａｂｃ！」という文字列が表示されている。

また、図１１にクライアントアプリ１１１においてユーザ操作Ｂが実行された場合に作成されるステップ情報１２０ａ−Ｂの一例を示す。

ユーザがテスト装置１００においてテストを実行するために必要な全ての操作を実行した場合（ステップＳ１１がＹｅｓ）、テスト装置１００はステップ情報作成処理を終了する。

ステップ情報作成処理が終了すると、サーバ２００は受信したステップ情報１２０ａに基づいてテストシナリオ登録処理を行う（図４のステップＳ２０）。ここで、図１２を参照して、テストシナリオ登録処理について説明する。

サーバ２００のテストシナリオ配信部２０１は、書式変換部１１７から送信された共通書式のステップ情報１２０ａを受信する（ステップＳ２１）。テストシナリオ配信部２０１がステップ情報１２０ａを受信すると、テストシナリオ登録部２０３は当該ステップ情報１２０ａをテストシナリオとしてテストシナリオ記憶部２０４に登録する（ステップＳ２２）。

すなわち、本実施形態のテストシナリオは、クライアントアプリ１１１において作成されたステップ情報１２０ａをテストシナリオ配信部２０１が受信した順に並べたデータである。もしくは、クライアントアプリ１１１において作成された順にステップ情報１２０ａを並べてもよい。これにより、テストシナリオ登録処理は終了する。

図４の説明に戻る。テストシナリオ登録処理が終了すると、テストシナリオ編集部２０５がテストシナリオ編集処理を行う（ステップＳ３０）。

ここで、図１３乃至図１６を参照して、本実施形態のテストシナリオ編集処理について説明する。図１３はテストシナリオ編集部２０５によるテストシナリオ編集処理の一例を示すフローチャートである。

まず、テストシナリオ編集部２０５は、テストシナリオ記憶部２０４からテストシナリオを取得し（ステップＳ３１）、取得したテストシナリオをユーザからの入力に基づいて編集する（ステップＳ３２）。なお、ユーザからの入力はクライアント端末１１０が備える入力部（図示しない）から行なわれる。もしくは、サーバ２００が入力部（図示しない）を備える構成としてもよい。

テストシナリオの編集は、例えばテストシナリオに含まれる各ステップ情報１２０ａの編集である。

例えば入力データ１２０ａＤは、入力値を別のものに変えてテストを実行したい場合に編集される。入力値を別のものに変えてテストを実行したい場合とは、例えば、「テキストボックスにユーザ名を入力する場合に、最初のテストと違うユーザ名でテストしたい場合などである。

操作結果画面情報１２０ａＥの編集は、例えば、最初の試験とは異なる結果になることが予測できる場合に行なわれる。例えば、ログイン日時を画面に出力するようなクライアントアプリにおいてテストを実行する場合、同じテストでも異なる画面が出力されることが予測できるため、あらかじめ日時を表示する部分の画面ソースコードに関しては操作結果画面情報１２０ａＥから除外し、テスト結果の判定根拠に含めないこととする。

結果比較フラグ１２０ａＦの編集は、後述するテスト結果合否判定処理を実行するか否かを変更したい場合に編集される。例えば、３回のユーザ操作で３画面遷移するようなテストシナリオデータにおいて、最後の画面だけにテスト結果合否判定処理を行いたい場合は３番目のステップ情報における結果比較のフラグのみ「ｔｒｕｅ」のままとし、残り２つの結果比較フラグ１２０ａＦを「ｆａｌｓｅ」に変更する。

テストシナリオ編集部２０５によって編集されたステップ情報１２０ａは、ステップＩＤ１２０ａＡが新しいＩＤに更新される。例えば、ステップＩＤ１２０ａＡ「１」のステップ情報１２０ａを編集した場合、新しいステップＩＤａＡを「１−１」とする。

もしくは、ユーザがテストシナリオ編集部２０５を用いてステップＩＤ１２０ａＡを編集することも可能である。ステップＩＤ１２０ａＡの編集は、クライアントアプリへ配信する順番を編集したい場合に行なわれる。

図１４に、テスト編集部２０５が編集したテストシナリオ２０３ａの一例を示す。テストシナリオ２０３ａはステップ情報１２０ａ−Ａをクライアントアプリ１２１、及びクライアントアプリ１３１用に編集したステップ情報を含む。ステップ情報１２０ａ−Ａをクライアントアプリ１２１用に編集したステップ情報１２０ａ−Ａ−２は、図１４に示す「ステップＩＤ＝ｓｔｅｐ１−２」を含むステップ情報であり、クライアントアプリ１３１用に編集したステップ情報１２０ａ−Ａ−３は、図１４に示す「ステップＩＤ＝ｓｔｅｐ１−３」を含むステップ情報である。なお、図１４に示すように、クライアントアプリ１２１用に編集したステップ情報１２０ａ−Ａ−２は、入力データを「ｄｅｆ」に、画面情報を「ｈｅｌｌｏ ｄｅｆ」に編集されている。クライアントアプリ１３１用に編集したステップ情報１２０ａ−Ａ−３は、結果比較フラグを「ｆａｌｓｅ」に編集されている。

テストシナリオ編集部２０５がテストシナリオを編集すると、テストシナリオ登録部２０３は、編集後のテストシナリオにテストシナリオ記憶部２０４に登録するテストシナリオ更新処理を行う（ステップＳ３３）。これにより、テストシナリオ編集処理は終了する。

テストシナリオ編集処理が終了すると、テストシナリオ配信部２０１がテストシナリオ記憶部２０５に登録されたテストシナリオをクライアント情報記憶部２０２に記憶されたクライアント情報に基づいてテストを実行するクライアントアプリに配信する。

まず、クライアント配信部２０２は、テストシナリオ記憶部２０４に記憶されたテストシナリオに含まれるすべてのステップ情報１２０ａがクライアントアプリで実行されたか否かを判定する（ステップＳ４０）。

テストシナリオに含まれる全てのステップ情報１２０ａがクライアントアプリ１１１で実行済みであるか否かは、テスト結果記憶部２０６に全てのステップ情報１２０ａに対するテスト結果が記憶されているかによって判定する。

テストシナリオに含まれる全てのステップ情報１２０ａがクライアントアプリ１１１において実行済みでない場合（ステップＳ４０がＮｏ）、テストシナリオ配信部２０１は、テストシナリオに含まれる未実行のステップ情報１２０ａから最もステップＩＤ１２０ａＡが小さいステップ情報１２０ａを取得する（ステップＳ５０）。すなわち、テストシナリオ配信部２０１はステップＩＤ１２０ａＡが小さい順にクライアント１１１に配信する。

テストシナリオ配信部２０１は、取得したステップ情報１０２ａをテストを実行するクライアントアプリへ配信する（ステップＳ６０）。

テストシナリオ配信部２０１が配信するクライアントアプリは、基本的にはクライアントアプリ情報記憶部２０２に記憶された全てのクライアントアプリであり、例えばクライアントアプリＩＤ１２０ａＢが小さいクライアントアプリへ順に配信する。

なお、テストシナリオ編集部２０５がテストシナリオの配信先クライアントアプリを編集することも可能である。配信先クライアントアプリの編集は例えば、図１５に示すような配信先クライアントテーブル２０７を用いて行なわれる。配信先クライアントテーブル２０７は、各テストシナリオに含まれるステップ情報１２０ａの配信順２０８と配信先のクライアントアプリ２０９とを管理するためのテーブルである。配信順２０８は、すなわちテストを実行する手順を示す。

ユーザは、この配信先クライアントテーブル２０７を確認し、配信するステップ情報の変更や削除や追加、もしくは配信順の編集を行う。本実施形態では、１番目にクライアントアプリ１１１にステップＩＤ１２０ａＡが「ｓｔｅｐ１」のステップ情報１２０ａを配信し、クライアントアプリ１３１にステップＩＤ１２０ａＡが「ｓｔｅｐ１−３」のステップ情報１２０ａを配信する。同様に、３番目までテストシナリオの配信が行なわれる。

クライアントアプリが、テストシナリオ配信部２０１からステップ情報１２０ａを受信すると、書式変換部１１７が当該ステップ情報１２０ａの固有書式化処理を行う（ステップＳ７０）。本実施形態の固有書式化処理は、図５のステップＳ１６におけるステップ情報１２０ａの共通書式化と同様に、変換ルール記憶部１１８に記憶された変換ルールに基づいてクライアントアプリの種類に基づく書式に変換される。

固有書式に変換されたテストシナリオに基づいてクライアントアプリ１１１のクライアント実行部１１６はテストを実行する（ステップＳ８０）。クライアント実行部１１６がテストを実行し終えると、テスト結果合否判定部１１９は、実行されたテスト結果の画面情報と、当該テストシナリオに含まれた結果比較フラグ１２０ａＦ及び操作結果画面情報１２０ａＥとに基づいてテスト結果合否判定処理を行う（ステップＳ９０）。

具体的には、テスト結果合否判定部１１９は、クライアントアプリが受信したテストシナリオのステップ情報１２０ａに含まれる結果比較フラグ１２０ａＦを確認し、当該結果比較フラグ１２０ａＦが「ｔｒｕｅ」の場合にテスト結果合否判定処理を実行する。当該結果比較フラグ１２０ａＦが「ｆａｌｓｅ」の場合、テスト結果合否判定処理と、続くステップＳ１００におけるテスト結果登録処理は省略され、ステップＳ４０に戻って処理を繰り返す。

当該結果比較フラグ１２０ａＦが「ｔｒｕｅ」の場合、テスト結果合否判定部１１９は、実行されたテスト結果の画面情報と、配信されたステップ情報１２０ａの操作結果画面情報１２０ａＥを比較する。操作結果画面情報１２０ａＥと実行されたテスト結果の画面情報が一致する場合、テスト結果合否判定部１１９は当該ステップ情報１２０ａに基づいて実行されたテスト結果を「合格」と判定する。

配信されたステップ情報１２０ａの操作結果画面情報１２０ａＥと実行されたテスト結果の画面情報が一致しない場合、テスト結果合否判定部１１９は当該テスト結果を「不合格」と判定する。あるいはテスト実行においてエラーが発生した場合、例えば指定したＩＤのＧＵＩ部品が画面上に存在しない場合等は、「不合格」と判定する。

判定結果は、テスト結果合否判定部１１９によってサーバ２００に送信される。サーバ２００のテストシナリオ配信部２０１は、当該判定結果を受信するとテスト結果記憶部２０６に登録するテスト結果登録処理を行う（ステップＳ１００）。図１６は、テスト結果記憶部２０６に登録されたテスト結果合否判定処理部１１９の合否判定結果の一例を示す図である。

図１６に示すようにテスト結果記憶部２０６には、テストシナリオ配信部２０１が受信した合否判定結果がステップ情報毎に保存される。なお、図１６における「−」はテスト結果合否判定処理が実行されていないことを示す。図１５の配信クライアントテーブル２０７に示すようにクライアントアプリ１３１には手順１において「ＳＴＥＰ１−３」がステップＩＤａＡであるステップ情報１２０ａＡが配信されている。しかし、このステップ情報１２０ａＡは、図１４に示すように「結果比較フラグ＝ｆａｌｓｅ」であるため、テスト結果合否判定処理が実行されていない。

ユーザは、全てのテストが完了した時点で、テスト結果記憶部２０６に保存された合否判定結果を確認することで、テストを実行する全てのクライアントアプリにおけるテスト結果を確認できる。

テスト結果登録処理が終了すると、テスト装置１００は、ステップＳ４０に戻り処理を繰り返す。本実施形態では配信先クライアントテーブル２０７に手順が３つ格納されているため、３回繰り返される。

テストシナリオデータに含まれる全てのステップ情報が実行された場合（ステップＳ４０がＹｅｓ）、テスト装置１００は動作を終了する。

上述のように、本実施形態のテスト装置１００によると、あるクライアントアプリで実施したテストの手順とその動作結果を含むテストシナリオを複数のクライアントアプリに共通の書式にした後にテストシナリオ記憶部２０４に保存し、このテストシナリオを複数のクライアントアプリに配布してテストを実行することで、複数種類のクライアントアプリにおけるテストの効率的な実行及びテストの並列化を可能とする。また、異なるクライアントアプリの互換性のテストを効率的に行なうことができる。

また、試験シナリオを一元管理しているため、複数のアクセスに対する排他制御のテスト等の複雑なテスト試験も可能である。

また、本実施形態のテスト装置１００においては、テストの担当者は、任意のクライアントアプリで一度だけ試験を実施して配布先を決定するだけでよい。

また、配布先となるクライアントアプリの種類はインターネットブラウザに限らず、あらゆるクライアントを選択できる。

以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００…テスト装置、１１０，１２０，１３０…クライアント端末、１１１，１２１，１３１…クライアントアプリケーション、１１２…クライアントアプリ登録部、１１３…ユーザ操作検出部、１１４…イベント取得部、１１５…操作結果画面取得部、１１６…テストシナリオ実行部、１１７…書式変換部、１１８…変換ルール記憶部、１１９テスト結果合否判定部、１２０ａ…ステップ情報、１２０ａＡ…ステップＩＤ、１２０ａＢ…クライアントアプリＩＤ、１２０ａＣ…イベントデータ、１２０ａＤ…入力データ、１２０ａＥ…操作結果画面情報、１２０ａＦ…結果比較フラグ、２００…サーバ、２０１…テストシナリオ配信部、２０２…クライアントアプリ情報記憶部、２０３…テストシナリオ登録部、２０４…テストシナリオ記憶部、２０５…テストシナリオ編集部、２０６…テスト結果記憶部、２１０…コンピュータ、２２０…記憶装置、２３０…プログラム、３００…ネットワーク

本発明が解決しようとする課題は、複数のクライアントアプリケーションを用いるテストの効率化を可能とするテスト装置およびその方法、プログラムとシステムを実現することである。

実施形態は、複数のクライアントアプリケーションを用いてアプリケーションのテストを実行するテスト装置であって、ユーザ操作を検出するユーザ操作検出部と、ユーザ操作に基づいて発生するイベントデータを取得するイベント取得部と、前記ユーザ操作検出部による前記ユーザ操作の検出結果である第１データを取得する操作結果取得部と、イベントデータと第１データとをそれぞれ複数のクライアントアプリケーションの共通書式に変換するルールに基づいてイベントデータと第１データとをそれぞれ共通書式に変換する書式変換部と、イベントデータと第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、共通書式に変換されたテストシナリオをクライアントアプリケーションに配信するテストシナリオ配信部と、配信されたテストシナリオに基づいて複数のクライアントアプリケーションのテストを実行するテストシナリオ実行部と、を備えるテスト装置およびその方法、プログラムとシステムである。

Claims (8)

1. 複数のクライアントアプリケーションを用いてアプリケーションのテストを実行するテスト装置であって、
   前記クライアントアプリケーション上のユーザ操作を検出するユーザ操作検出部と、
   前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得するイベント取得部と、
   前記ユーザ操作部による操作検出結果である第１データを取得する操作結果取得部と、
   前記イベントデータ及び前記第１データを前記複数のクライアントアプリケーションの共通書式に変換する書式変換部と、
   前記イベントデータと前記第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、
   共通書式に変換された前記テストシナリオを前記クライアントアプリケーションに配信するテストシナリオ配信部と、
   配信された前記テストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行するテストナリオ実行部と、
   を備えるテスト装置。
2. 前記テストシナリオを編集するテストシナリオ編集部を備え、
   前記テストシナリオ実行部は、前記テストシナリオ編集部によって編集されたテストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行する請求項１に記載のテスト装置。
3. 前記テストシナリオ編集部は、前記テストシナリオの配信先、前記テストシナリオに含まれる前記第１データ、もしくは前記テストの手順を編集する請求項１及び請求項２のいずれか１項に記載のテスト装置。
4. 前記テストシナリオに含まれる前記第１データと前記テストシナリオ実行部が前記テストシナリオに基づいて実行したテスト結果である第２データとに基づいてテスト結果の合否を判定するテスト結果合否判定部を備える請求項１乃至請求項３のいずれか１項に記載のテスト装置。
5. 前記テスト結果合否判定部の判定結果を記憶する合否判定結果記憶部を備える請求項４に記載のテスト装置。
6. アプリケーションのテストを実行する際に用いる複数のクライアントアプリケーションと、前記クライアントアプリケーション上のユーザ操作を検出するユーザ操作検出部と、前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得するイベント取得部と、前記ユーザ操作部による操作検出結果である第１データを取得する操作結果取得部と、前記イベントデータ及び前記第１データを前記複数のクライアントアプリケーションの共通書式に変換する書式変換部と、前記イベントデータと前記第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、共通書式に変換された前記テストシナリオを前記クライアントアプリケーションに配信するテストシナリオ配信部と、配信された前記テストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行するテストナリオ実行部と、を備えるテスト装置におけるテスト方法であって、
   前記ユーザ操作検出部が前記クライアントアプリケーション上のユーザ操作を検出するステップと、
   前記イベント取得部が前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得するステップと、
   前記操作結果取得部が前記ユーザ操作の検出結果である第１データを取得するステップと、
   前記書式変換部が前記イベントデータと前記第１データを前記複数のクライアントアプリケーションの共通書式に変換するステップと、
   前記テストシナリオ記憶部が前記イベントデータと前記第１データとを含む前記テストシナリオを前記テストシナリオ記憶部に記憶するステップと、
   前記テストシナリオ配信部が共通書式に変換された前記テストシナリオを前記クライアントアプリケーションに配信するステップと、
   前記テストナリオ実行部が配信された前記テストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行するステップと、
   を備えるテスト方法。
7. アプリケーションのテストを実行する複数のクライアントアプリケーションと、前記クライアントアプリケーション上のユーザ操作を検出するユーザ操作検出部と、前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得するイベント取得部と、前記ユーザ操作部による操作検出結果である第１データを取得する操作結果取得部と、前記イベントデータ及び前記第１データを前記複数のクライアントアプリケーションの共通書式に変換する書式変換部と、前記イベントデータと前記第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、共通書式に変換された前記テストシナリオを前記クライアントアプリケーションに配信するテストシナリオ配信部と、配信された前記テストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行するテストナリオ実行部と、を備えるテスト装置のプログラムであって、
   コンピュータに、
   前記クライアントアプリケーション上のユーザ操作を検出する機能と、
   前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得する機能と、
   前記ユーザ操作の検出結果である第１データを取得する機能と、
   前記イベントデータと前記第１データを前記複数のクライアントアプリケーションの共通書式に変換する変換する機能と、
   前記イベントデータと前記第１データとを含む前記テストシナリオを前記テストシナリオ記憶部に記憶する機能と、
   共通書式に変換された前記テストシナリオを前記クライアントアプリケーションに配信する機能と、
   配信された前記テストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行する機能と、
   を実現させるプログラム。
8. アプリケーションのテストを実行する複数のクライアントアプリケーションと、前記複数のクライアントアプリケーションが動作する少なくとも１つのクライアント端末と、前記複数のクライアントアプリケーションがテストを実行する手順と各手順における動作結果とを含むテストシナリオを配信するサーバとを備えるテストシステムであって、
   前記クライアント端末は、
   前記クライアントアプリケーション上のユーザ操作を検出するユーザ操作検出部と、
   前記ユーザ操作に基づいて前記クライアントアプリケーションに発生するイベントデータを取得するイベント取得部と、
   前記ユーザ操作検出部による操作検出結果である第１データを取得する操作結果取得部と、
   前記イベントデータと前記第１データを前記複数のクライアントアプリケーションの共通書式に変換する書式変換部と、
   共通書式に変換された前記テストシナリオを前記サーバに送信するテストシナリオ送信部と、
   前記サーバから配信されたテストシナリオに基づいて前記複数のクライアントアプリケーションのテストを実行するテストシナリオ実行部と、
   を備え、
   前記サーバは、
   前記イベントデータと前記第１データとを含み、テストの手順を示すテストシナリオを記憶するテストシナリオ記憶部と、
   共通書式に変換された前記テストシナリオを前記複数クライアントアプリケーションに配信するテストシナリオ配信部と、
   を備えるテストシステム。

Images