JP2010224843A - ブラックボックステスト用テストルールの動作確認装置、システム、方法およびプログラム - Google Patents

Abstract

【課題】ネットワークアプリケーション向けブラックボックステスト用テストルールの動作確認をモックアップを用いて行う場合に、クライアント側のみからの操作により実現する。
【解決手段】
クライアント側にモックアップの個々の動作を定義するデータであるモックアップ要素と、当該モックアップ要素を識別するためのデータであるモックアップ要素識別子とを予め対応付けて定義しておく。また、クライアントはそれらをまずサーバに送り、サーバ側でモックアップ要素識別子とモックアップ要素とを対応付けてモックアップを生成する。そのうえで、クライアントは、テストリクエストにモックアップ要素識別子を付加してサーバに送信することで、モックアップ要素をクライアント側から切り替える。
【選択図】図１

Description

本発明はブラックボックステスト用テストルールの動作確認装置、システム、方法およびプログラムに関する。

近年ではインターネットやWorld-Wide Web (Web)の隆盛に伴い、多くのサーバ側アプリケーションがさまざまな用途で広く利用されている。係るアプリケーションの動作に支障が起きないこと、さらには悪意者が異常な入力を行うことで意図的にアプリケーションを誤動作させるような攻撃を防ぐことは重要であり、そのために開発段階や導入・運用段階において動作確認テスト（試験・検査）が行われる。

アプリケーションの動作確認テストの一手段として、ブラックボックステストが知られている。ブラックボックステストとは、対象アプリケーションに対し、アプリケーション内部の構造とは無関係に外部から関与して観測できる情報だけをもとに判断するテストである。ブラックボックステストでは、対象アプリケーション内部でどのような処理が行われているかは一切問題とされない。つまり、外部から適当な入力を与え、それに対する出力が所定の条件を満たしているかを判定することにより、入力に対する出力が、期待されたものであるか否かを判定する。したがって、ブラックボックステストにおけるテストルールは、アプリケーションに与える入力（テスト入力パターン）と、当該入力に対する出力が満たすべき条件（テスト出力判定条件）を含む。

ここで、図１２に基づき、従来行われているWebアプリケーション向けブラックボックステストに用いるテストルールセット（テストルールの集合）の具体例について説明する。各テストルールはテストルール識別子（名前）、前記テスト入力パターン、および、前記テスト出力判定条件を有する。この例では、「Name」ラベルが付された行にはテストルール識別子を記述する。「Send」ラベルが付された行には前記テスト入力パターンを記述する。テスト入力パターンは、後述するテストリクエストの変数に格納される値に相当する文字列である。「Test」ラベルが付された行には前記テスト出力判定条件である条件式を記述する。テスト出力判定条件は'＝'で左辺と右辺に分けることができる。左辺は、判定種別であり、「OK」または「NG」の値をとる。一方、右辺は、テストの合否を決めるための判定パターンを指定する。左辺の判定種別が「OK」であるテスト出力判定条件は、右辺の判定パターンにマッチしたときにテスト結果が合格（OK）となり、マッチしないときはテスト結果は不合格（NG）となる。反対に、左辺の判定種別が「NG」であるテスト出力判定条件は、右辺の判定パターンにマッチしたときに不合格（NG）となり、マッチしなかったときは合格（OK）となる。ここではパターンを、プログラミング言語Perlの正規表現指定の書式で記述しているが、ワイルドカード文字列等を用いて記述してもよい。

例として、図１２における、テストルール「zip-search」について説明する。このテストルールは、郵便番号検索アプリケーションに対して動作テストを行うためのテストルールの一例を表現したものである。テスト入力パターン「100-0014」を郵便番号検索アプリケーションに入力したとき、郵便番号検索アプリケーションの出力に「永田町」の文字列が含まれていれば（判定種別が「OK」のため）、テストは合格となる。反対に、含まれていなければ、テストは不合格となる。また、アプリケーションのセキュリティ対策をチェックするためのセキュリティテストを行うこともできる。例えば、テストルール「script-tag」は、テスト入力パターンにHTMLのscriptタグを混入させ、その出力に当該scriptタグがそのまま含まれていた場合に不合格とするテストルールである。これはサーバ側でHTMLタグのサニタイジング（無害化）が為されていないことを意味しており、クロスサイト・スクリプティング攻撃への耐性をテストするものである。同様に、テストルール「javascript（登録商標）-url」もセキュリティ対策をテストするものであり、JavaScript（登録商標）のサニタイジング対策をテストするためのテストルールの例である。

ブラックボックステストの一般的な説明に戻る。ブラックボックステストを実施する場合、得られたテスト出力に対してテスト出力判定条件を適用するときに誤検出（誤判定）が起きることがある。こうした誤検出はルールの記述を誤ったために発生する。特に、テスト出力判定条件に複雑な正規表現を使う場合等において、頻繁に発生しうる。このようなルール記述の誤りを発見するには、実際にそのルールを使ってテストを行い、意図した検出がされ（検出漏れがないこと）、意図しない検出がされない（過剰検出しないこと）ことを確認するのが有効である。これはいわば、「テストルールのテスト」である。本稿では、このようなテストルールのテストのことを「テストルール動作確認」（または、文脈上自明である場合には単に「動作確認」）と呼ぶこととする。

テストルール動作確認を行うには、単純には実際のテスト対象のアプリケーションに対してテストを実施することも考えられるが、これは望ましくない。テスト対象である、つまり動作確認のされていないアプリケーションを、それをテストするためのテストルールの確認に使っても、テストルールの妥当性を担保できないという論理的不整合の問題があるためである。また、労力の問題もある。すなわち、アプリケーションを実際に動かすためには、動作環境の整備が必要であり、それには多大な工数が必要な場合がある。

一般的に、テストルールの動作確認を行う場合には、実際のアプリケーションの代わりに、モックアップアプリケーション（以下モックアップと略す）が用いられる。モックアップとは、本来のテスト対象のアプリケーションを模倣する動作をするアプリケーションである。ただし、アプリケーションの内部の処理まで模倣はせず、入出力だけが模倣される。テストルール動作確認を行うには、モックアップに対し、確認したいテストルールを用いてテストを実施する。その結果を吟味することで、正しく検出できたこと（検出漏れがないこと）、および検出すべきでないものを正しく見逃したこと（過剰検出しないこと）を確認できる。

一方、アプリケーションは一般に多くの機能から成り立っており、ブラックボックステストはそれら各機能に対して一括して行われるのが普通である。あるいは、複数のアプリケーションからなるシステムに対してブラックボックステストが行われる場合もある。したがって、テストルール動作確認に用いるモックアップでは、複数の動作（機能）を模倣できることが望まれる。本稿では、このようなモックアップの個々の動作を「モックアップ要素」と呼ぶことにする。

ブラックボックステストに関連し、コンピュータにおいて複数の動作の模倣をおこなうエミュレータを構成し、その動作を外部から指定して切り替える発明がある（例えば、特許文献１参照）。
特開２００６−８５６１２号公報 図１１は従来技術に係るテストルール動作確認システムの機能ブロック図である。クライアント１００とサーバ２００がネットワーク接続されており、クライアント１００が「テストをする側」でありサーバ２００が「テストをされる側」である。サーバ２００では、テスト対象であるネットワークアプリケーションを模倣するモックアップ２０１が動作する。モックアップ２０１は、模倣する個々の動作に相当する前記モックアップ要素２０３を一つ以上と、モックアップ要素２０３をモックアップ要素識別子２１１に基づいて選択するモックアップ要素選択部２０２とを備える。

テストルールの動作確認を行うために、事前に、クライアント１００にテストルールセット１１１及びリクエストテンプレート１１２を格納しておく。ここで、テストルールセット１１１は、従来技術の項で説明したもの（図１２）を用いることができる。

図１３に基づき、前記リクエストテンプレート１１２について説明する（なお、この段落においては、記号□を、クエスチョンマーク記号（ＡＳＣＩＩ文字コードの０ｘ３ｆ）に置き換えて読まれたい）。これは、テスト入力を含むHTTPリクエストであるテストリクエストに係るURLの雛形となる文字列データであり、例えば「http://www.example.com/test/mock.jsp（登録商標）□p1=」等である。ここで、'□'以下の文字列「p1=」が、Webアプリケーションへのパラメータに相当する。この例ではパラメータは１個であるが、複数個でもよい。テストリクエストとリクエストテンプレートとの違いは、パラメータに値が格納されているか否かである。すなわち、テストリクエストでは、パラメータに値が格納され、例えば「http://www.example.com/test/mock.jsp（登録商標）□p1=wx<script>yz」等となる。これに対し、リクエストテンプレート１１２は単なる雛形であり、パラメータに値は格納されない。

図１１のテストルール動作確認システムの処理の概要は次の通りである。まずサーバ２００側でモックアップ２０１に含まれるモックアップ要素２０３を切り替えるため、モックアップ要素識別子受付部２０４がモックアップ要素識別子２１１を受け付ける。次に、クライアント１００のルール読込部１０１はテストルールセット１１１を読み込み、リクエスト生成部１０２が、別途読み込んだリクエストテンプレート１１２及び前記読み込んだテストルールセット１１１に含まれるテスト入力パターンとに基づいてテストリクエストを生成する。すなわち、リクエスト生成部１０２は、図１３に示すように、リクエストテンプレート１１２のパラメータに対し、前述したテストルールセット１１１において定義されたテスト入力パターンを格納することで、テストリクエストを生成する。次に、クライアント１００のメッセージ送受信部１０３とサーバ２００のメッセージ送受信部２０５がテストリクエスト１１４を送受信する。サーバ２００のモックアップ実行部２０６は、前記モックアップ２０１を実行する。サーバ２００のモックアップが備えるモックアップ要素選択部２０２は、前記モックアップ要素識別子受付部２０４が受け付けたモックアップ識別子２１１に基づき、モックアップ要素２０３のうち１つを選択する。前記選択されたモックアップ要素２０３は、前記受信したテストリクエスト１１４に基づき、テストレスポンスであるHTMLページを生成する。サーバ２００のメッセージ送受信部２０５とクライアント１００のメッセージ送受信部１０３がテストレスポンス２１２を送受信する。クライアント１００のレスポンス判定部１０４が、前記読み込んだテストルール中のテスト出力判定条件に基づいてテストレスポンスの合否を判定する。クライアント１００の判定結果出力部１０５が前記判定結果１１３をテストルール動作確認の結果として出力する。

従来技術に係るテストルール動作確認システムでは、サーバ２００側のモックアップ２０１に複数のモックアップ要素２０３を組み込んでおき、サーバ側でその都度モックアップの動作を切り替えている。一方、クライアント１００がテストリクエスト１１４を生成してサーバ２００に送信することで、テストルール動作確認は実行される。そして、サーバ２００側のモックアップ要素２０３とクライアント側で生成されるテストリクエスト１１４との間には対応関係があるはずだが、それらの同期は行われていない。そのため、従来技術には、クライアント１００とサーバ２００の両方の制御が必要であるという課題がある。

すなわち、従来技術では、テストルール動作確認を行う際に、予めクライアント１００とサーバ２００の両方で操作が必要になる。このため、複数のテストルールを一括して動作確認することができず、テストルール動作確認が効率的に行えない。一般にテストルール及びモックアップ要素（動作部）は多数となるため、テストルール動作確認の操作が煩雑となり、ミスも生まれやすいという問題が生じる。

開示のテストルール動作確認サーバ装置は、アプリケーションに対するブラックボックステストを行うためのルールであって、アプリケーションへのテスト用入力データであるテスト入力パターンを含むデータであるテストルールに対する動作確認を、当該動作確認を行うために前記アプリケーションの機能を模倣するアプリケーションであるモックアップを用いるとともに、ネットワーク接続したクライアントと連携して行うテストルール動作確認サーバ装置であって、前記モックアップの個々の動作を定義したデータであるモックアップ要素と、当該モックアップ要素の識別子であるモックアップ要素識別子とを対応付けたデータを前記クライアント装置から受信する手段と、前記受信したモックアップ要素とモックアップ要素識別子とを対応づけて記憶手段に格納する手段と、モックアップ要素識別子を付加されたテスト入力パターンを前記クライアント装置から受信する手段と、前記受信したテスト入力パターンに付加されたモックアップ要素識別子に対応付けられた前記モックアップ要素を記憶手段から読み出して、当該モックアップ要素により定義されたモックアップの動作によって、前記受信したテスト入力パターンを処理させることでテスト出力を生成する手段と、前記生成したテスト出力を前記クライアント装置に送信する手段とを備えることを特徴とする。

開示のシステムによれば、サーバ側アプリケーション向けブラックボックステストのテストルール動作確認を、クライアント側のみの操作によりおこなうことが可能となる。これにより、操作が簡単になり、複数のテストルールを一括して動作確認できるようになるため、テストルール動作確認を効率よく行えるようになる。また、動作確認のミスも生まれ難く、より正しい結果を得ることが可能となる。

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

なお、以下の実施例では、テスト対象であるサーバ側アプリケーションがWebアプリケーションである場合を例として説明する。すなわち、WebサーバとWebクライアントが、アプリケーション層の通信プロトコルとしてHypetText Transfer Protocol(HTTP)を用いる例である。クライアントはサーバにHTTPリクエストを送信し、その応答としてサーバはクライアントにHTTPレスポンスを返す。以下では、HTTPリクエストとHTTPレスポンスを、それぞれ単にリクエスト、レスポンスと呼ぶ。

サーバ側アプリケーションがWebアプリケーションなので、モックアップは当該Webアプリケーションの動作を模倣するものとなるが、モックアップそのものもWebアプリケーションとして実現する。Webアプリケーションは通常はHTMLデータを出力するので、モックアップの出力もHTMLデータとなる。本実施形態では、モックアップの実装の基盤としてJava（登録商標）サーブレットコンテナを採用し、モックアップをJavaServer Pages（JSP）（登録商標）コードで記述する。モックアップの動作をJSP（登録商標）コード形式で記述したファイルを、Java（登録商標）サーブレットコンテナがコンパイルして実行することで、モックアップは実行される。

以下では、本発明の第１の実施形態を説明する。
まず、図１に、本発明の第１の実施形態に係るテストルール動作確認システムの機能ブロック図を示す。クライアント１００とサーバ２００がネットワークで接続されている。なお、それぞれの図において、対応する部分については同じ番号を付している。

まず、クライアント１００について説明する。同図に示すクライアント１００は、ルール読込部１０１、リクエスト生成部１０２、メッセージ送受信部１０３、レスポンス判定部１０４、判定結果出力部１０５、ルール送信部１０６、および、モックアップ要素識別子付加部１０７を備える。また、クライアント１００は、データとして、テストルールセット１１１とリクエストテンプレート１１２とを格納する。リクエストテンプレート１１２は、従来技術のリクエストテンプレート（図１３）と同じであるため、ここでは説明しない。

ルール読込部１０１は、テストルールセット１１１を読み込む。ルール送信部１０６は、読み込んだテストルールセット１１１をサーバ２００に送信する。リクエスト生成部１０２は、読み込んだテストルールセット１１１に記述されたテスト入力パターンを、別途読み込んだリクエストテンプレート１１２に格納し、テストリクエスト１１４を生成する。モックアップ要素識別子付加部１０７は、前記読み込んだテストルールセット１１１に基づき、サーバ２００で動作させるモックアップ要素２０３を指定するためのモックアップ要素識別子２１１を生成して、前記生成したテストリクエスト１１４に付加する。メッセージ送受信部１０３は、前記モックアップ要素識別子２１１が付加されたテストリクエスト１１４をサーバ２００に送信するとともに、その応答であるテストレスポンス２１２をサーバ２００から受信する。レスポンス判定部１０４は、前記受信したテストレスポンス２１２が、前記読み込んだテストルールセット１１１において前記テストリクエスト１１４に格納したテスト入力パターンに対応付けられたテスト出力判定条件を満たすか否かを判定する。判定結果出力部１０５は、前記レスポンス判定部１０４が判定した結果である判定結果１１３を出力装置などに出力する。

図２に、本発明の第１の実施形態に係るテストルールセット１１１の例を示す。これは、図１２で示した従来のテストルールセット１１１に、モックアップの個々の動作をJSP（登録商標）コード形式で記述したデータである「モックアップ要素」を追加したものである。本稿では、このようなモックアップが有する個々の動作、あるいは当該個々の動作をJSP（登録商標）コード形式で記述したデータを「モックアップ要素」と呼ぶ。

図２において、先頭に「OK」ラベルまたは「NG」ラベルを付した行において、前記モックアップ要素を記述している。ここで「OK」と「NG」は、モックアップ要素に対して想定される出力判定の結果（想定判定結果）であり、テスト出力判定条件の合格（OK）と不合格（NG）とに対応している。すなわち、モックアップ要素の「OK」は、テスト出力判定が合格（OK）となるべきモックアップ要素を記述する。反対に、モックアップ要素の「NG」は、テスト出力判定が合格（NG）となるべきモックアップ要素を記述する。モックアップ要素は必要に応じて引数（図３の例では“p”）を用いても良く、これによりモックアップがリクエストに応じてレスポンス（HTMLページ）を動的に生成することも可能となる（HTMLページの動的な生成については後述する）。

次に、サーバ２００について説明する。図１に示すサーバ２００は、メッセージ送受信部２０５、モックアップ実行部２０６、ルール受信部２０７、および、モックアップ生成部２０８を備える。また、前記モックアップ生成部２０８が生成するモックアップ２０１は、モックアップ要素選択部２０２、および、１つ以上のモックアップ要素２０３を備える。また、サーバ２００は、モックアップ２０１の生成に用いるデータであるモックアップテンプレート２１３を格納している。

ルール受信部２０７は、クライアント１００からテストルールセット１１２を受信する。モックアップ生成部２０８は、モックアップテンプレート２１３を読み込み、当該モックアップテンプレート２１３に前記受信したテストルールセット１１２から読み出したモックアップ要素２０３を組み込んで、モックアップ２０１を生成する。当該生成されたモックアップ２０１には、モックアップ要素選択部２０２と、１つ以上のモックアップ要素２０３とを含む。メッセージ送受信部２０５は、モックアップ要素識別子２１１が付加されたテストリクエスト１１４をクライアント１００から受信するとともに、テストリクエスト１１４への応答であるテストレスポンス２１２をクライアント１００に送信する。モックアップ実行部２０６は、前記生成したモックアップ２０１を実行する。モックアップ選択部２０２は、前記受信したテストリクエスト１１４に付加されたモックアップ要素識別子２１１に基づき、前記実行されたモックアップ２０１に含まれるモックアップ要素２０３の中から、動作させるモックアップ要素２０３を選択する。モックアップ要素２０３は、テストレスポンス２１２であるHTMLファイルを生成する。

図３に基づき、モックアップテンプレート２１３について説明する。なお、図３では、説明の便宜のために各行の先頭に行番号を付しているが、実際のモックアップテンプレート２１３には行番号は不要である。

モックアップテンプレート２１３とは、モックアップ要素２０３を組み込むための雛形に相当するJSP（登録商標）コードを記述したファイルである。換言すると、モックアップテンプレート２１３に、テストルールセット１１１に記述されたモックアップ要素２０３が埋め込まれることで、モックアップ２０１が生成される。ここで、モックアップ要素２０３を埋め込む箇所を、ブロックタグ「mockup-behavior」によって指定している（図３の１０行目）。また、JSP（登録商標）コード「request.getHeader("x-mock-id")」は、「x-mock-id」というHTTPヘッダの値を取り出す処理を記述している。（図３の７行目）。詳しくは後述するが、これはテストリクエスト１１４に付加されたモックアップ要素識別子２１１を取り出す処理に相当する。また、JSP（登録商標）コード「request.getParameter("p")」は、テストリクエスト１１４のパラメータ「p」を取り出している（図３の８行目）。引数「p」を使用するモックアップ要素２０３では、「p」の値に応じて、テストレスポンス２１２であるHTMLページを動的に生成することができる。

次に、図４に基づき、モックアップ２０１について説明する。前述の通り、モックアップ２０１はサーバ２００に始めから格納されているわけではない。サーバ２００のモックアップ生成部２０８が、サーバ２００に始めから格納されているモックアップテンプレート２１３に、クライアント１００から受信したテストルールセット１１１に記述されたモックアップ要素２０３を埋め込むことで、モックアップ２０１を生成する。

図４に例示するモックアップは、図３に例示したモックアップテンプレート２１３に、図１に例示したテストルールセット１１１に記述されたモックアップ要素２０３を埋め込んだJSP（登録商標）コードに相当する。なお、図４では、説明の便宜のために各行の先頭に行番号を付しているが、実際のモックアップ２０１には行番号は不要である。図４では、モックアップ要素２０３を埋め込む箇所を指定したブロックタグ「mockup-behavior」で指定しており（図４の１０行目）、当該ブロックタグが付されたブロックに、モックアップ要素２０３それぞれがモックアップ要素識別子と対応付けられて埋め込まれている（図４の１１〜３１行目）。図４において、たとえば、モックアップ要素「<span>東京都千代田区永田町</span>」が、モックアップ識別子「zip-search-1」に対応付けられて埋め込まれている（図４の１１〜１３行目）。

図４のモックアップ２０１は、前述したように、動的にHTMLページを生成することができる。すなわち、動的にページを生成するアプリケーションを模倣できる。図４において、JSP（登録商標）のrequest.getParameter関数により、テストリクエストのパラメータpを取り出している（図４の８行目）。そして、モックアップ要素識別子が「script-tag-1」であるモックアップ要素「<%=p%>」では、pに格納された値（文字列）を、そのまま記載したHTMLページを生成する（図４の１４〜１６行目）。また、モックアップ要素識別子が「script-tag-2」であるモックアップ要素「<%=Utility.htmlEscape(p)%>」は、pに格納された値（文字列）にエスケープ処理（JSP（登録商標）のUtility.htmlEscape関数）を施した文字列を記載したHTMLページを生成する（図４の１７〜１９行目）。すなわち、これらのモックアップ要素は、テストリクエストの内容に応じて、テストレスポンス２１２であるHTMLページを動的に生成している。

ちなみに、一般論として、Webアプリケーションは、セキュリティの観点から、HTTPリクエストから与えられたパラメータを、出力であるHTMLページにそのまま含めるべきでなく、エスケープ処理を施すべきである。そうすることで、HTMLページにタグが混入されることがなくなり、いわゆるクロスサイトスクリプティング攻撃を回避できるためである。すなわち、図４のモックアップ要素「script-tag-1」はセキュリティ上問題のあるWebアプリケーションに対応しており、モックアップ要素「script-tag-2」は安全なWebアプリケーションに対応している。

図５に基づき、第１の実施形態の処理フローについて説明する。

まずクライアント１００のルール読込部１０１は、テストルールセット１１１を記述したファイルを読み込む（ステップＳ１０１）。次に、クライアント１００のルール送信部１０６は、読み込んだテストルールセット１１１の全体をサーバ２００に送信する（ステップＳ１０２）。サーバ２００のルール受信部２０６は、前記クライアント１００が送信したテストルールセット１１１を受信する（ステップＳ１０３）。そして、サーバ２００のモックアップ生成部２０８は、まずモックアップテンプレート２１３を読み込み、前記受信したテストルールセット１１１に含まれる各モックアップ要素２０３と各モックアップ要素に対応付けられたモックアップ要素識別子２１１とを対応付けて、モックアップテンプレートに組み込むことでモックアップを生成する（ステップＳ１０４）。ステップＳ１０４の処理の詳細については後述する。

ここで、図４には不図示であるが、クライアント１００は、所定時間（例えば１０秒間）のスリープ処理を行う。サーバ２００においてモックアップが生成されるまでの時間を確保するためである。次にクライアント１００のリクエスト生成部１０２は、リクエストテンプレート１１２を読み込むとともに、当該リクエストテンプレート１１２と前記読み込んだテストルールセット１１１に含まれるテスト入力パターンとを組み合わせてテストリクエスト１１４を生成する（ステップＳ１０５）。テストリクエスト１１４の生成は、前述の通り、図１３に示すように行えばよい。

そしてクライアント１００のモックアップ要素識別子付加部１０７は、前記読み込んだテストルールセット１１１に基づき、モックアップ要素識別子２１１を生成し、前記リクエスト生成部１０２が生成したテストリクエスト１１４に、当該モックアップ要素識別子２１１を付加する（ステップＳ１０６）。これは以下のように行う。まずモックアップ要素識別子付加部１０７は、テストルールセット１１１に定義されたルール識別子にモックアップ要素の番号（記載された順番）を連結することで、モックアップ識別子２１１を生成する。例えば、図２のテストルールセット１１１に基づいて説明すれば、ルール識別子「script-tag」が備える３個のモックアップ要素「<%=p%>」、「<%=Utility.HTMLEscape(p)%>」、「<script>validCode</script>」に対し、モックアップ要素識別子２１１をそれぞれ「script-tag-1」 、「script-tag-2」 、「script-tag-3」と生成できる。そして、モックアップ要素識別子付加部１０７は、前記リクエスト生成部１０２が生成したテストリクエスト１１４に、前記生成したモックアップ要素識別子２１１を付加する。これは、テストリクエスト１１４に付加するHTTPヘッダの１つである「X-Mock-Id」ヘッダに、モックアップ要素識別子２１１を格納することで実現する。

そして、クライアント１００のメッセージ送受信部１０３は、モックアップ要素識別子２１１が付加されたテストリクエスト１１４をサーバ２００に送信する（ステップＳ１０７）。サーバ２００のメッセージ送受信部２０５は、前記クライアント１００が送信したモックアップ要素識別子２１１が付加されたテストリクエスト１１４を受信する（ステップＳ１０８）。サーバ２００のモックアップ実行部２０６は、前記生成したモックアップ２０１を実行する（ステップＳ１０９）。サーバ２００のモックアップ２０１が備えるモックアップ要素選択部２０２は、前記受信したテストリクエスト１１４に付加されたモックアップ要素識別子２１１に基づき、当該モックアップ要素識別子２１１に対応付けられたモックアップ要素２０３を選択する（ステップＳ１１０）。サーバ２００のモックアップ２０１が備えるモックアップ要素２０３のうちで前記選択されたモックアップ要素２０３は、テストリクエスト１１４を処理する動作を行い、動作結果（出力のHTMLページ）であるテストレスポンス２１２を生成する（ステップＳ１１１）。たとえば、図４のモックアップにおいて、モックアップ要素識別子「script-tag-1」が選択されると、モックアップ要素「<%=p%>」が動作し、pに格納された値（文字列）をそのまま記載したHTMLページが生成される。また、モックアップ要素識別子「script-tag-2」が選択されると、モックアップ要素「<%=Utility.htmlEscape(p)%>」が動作し、pに格納された値（文字列）にエスケープ処理を施した文字列を記載したHTMLページが生成される。

次に、サーバ２００のメッセージ送受信部２０５は、前記生成したテストレスポンス２１２を、HTTPレスポンスの形式でクライアント１００に送信する（ステップＳ１１２）。クライアント１００のメッセージ送受信部１０３は、前記サーバ２００が送信したテストレスポンス２１２を受信する（ステップＳ１１３）。

クライアント１００のレスポンス判定部１０４は、前記受信したテストレスポンス２１２が、対応するテスト出力判定条件を満足するかを判定する（ステップＳ１１４）。すなわち、クライアント１００のレスポンス判定部１０４は、前記受信したテストレスポンス２１２に含まれるHTMLページに対し、前記読み込んだテストルールセット１１１において前記送信したテストリクエスト１１４に係るテスト入力パターンに対応付けられた出力判定条件と照合し、テスト出力の合否を判定する。たとえば、図１３におけるルール「script-tag」の場合、テスト入力パターンは「wx<script>yz」であり、それに対応付けられたテスト出力判定条件は「NG=/wx<script>yz/gi」である。判定の仕方についてはテストルールセット１１１の説明の中で述べたとおりであるが、例として、前記のテスト出力判定条件が「NG=/wx<script>yz/gi」である場合を説明する。この判定条件は判定種別が「NG」なので、判定パターンにマッチしたときに、テスト結果は不合格(NG)とする。すなわち、HTMLページに文字列「wx<script>yz」が１つでも含まれている（ただし、大文字小文字は区別しない）ときに、テスト結果は不合格(NG)となる。一方、HTMLページに文字列「wx<script>yz」が１つも含まれていない（ただし、大文字小文字は区別しない）ときに、テスト結果は合格(OK)となる。

クライアント１００の判定結果出力部１０５は、前記ステップＳ１１３で得られたテスト結果に基づき、判定結果１１３を出力装置であるモニタに出力する（ステップＳ１１５）。クライアント１００の判定結果出力部１０５は、以下のようにして、図６に例示するようなテーブルを生成して出力する。クライアント１００の判定結果出力部１０５は、各行につき、ルール識別子、テスト入力パターン、テスト出力判定条件、モックアップ要素、および、想定判定結果を、テストルールセット１１１から読み出して出力する。ここで、想定判定結果とは、テストルールにおいてモックアップ要素に付された「OK」または「NG」のラベルを指す。そして、クライアント１００の判定結果出力部１０５は、各行につき、前記ステップＳ１１４で得られたテスト結果を「実際判定結果」として出力する。さらに、クライアント１００の判定結果出力部１０５は、各行につき、想定判定結果と実際判定結果とを比較した結果を「ルール動作確認結果」として出力する。ここで、想定判定結果と実際判定結果との比較の結果、これらが一致すれば、テストルールは想定通りに記述されていることが検証されたということなので、テストルール動作確認の結果としては「問題なし」となる。反対に、比較の結果、これらが一致しなければ、テストルールは想定通りに記述されていないことが検証されたということなので、テストルール動作確認の結果としては「問題あり」となる。ここでは判定結果をモニタに出力しているが、モニタに出力する代わりに、またはモニタに出力するのと併せて、判定結果を任意の記憶装置に出力してもかまわない（HDDにファイル出力するなど）。

クライアント１００のリクエスト生成部１０２は、直前に送信したテストリクエスト１１４が現在の処理に係るテストルールの最後のモックアップ要素に係るものであるかを判定する（ステップＳ１１６）。もし最後のモックアップ要素でなければ、当該テストルールにおける次のモックアップ要素に対し、ステップＳ１０５に戻って処理を繰り返す。もし最後のモックアップ要素であればステップＳ１１７に進む。クライアント１００のリクエスト生成部１０２は、直前に送信したテストリクエスト１１４がテストルールセット１１１の最後のテストルールに係るものであるかを判定する（ステップＳ１１７）。もし最後のテストルールでなければ、次のテストルールに対し、ステップＳ１０５に戻って処理を繰り返す。もし最後のテストルールであれば処理を終了する。これに対し、サーバ２００は、クライアント１００が次のテストリクエスト１１４を送信した場合には、ステップＳ１０８に戻って処理を繰り返す（ステップＳ１１８）。そうでなければ終了する。

図７の処理フローに基づき、ステップＳ１０４について詳しく説明する。ステップＳ１０４では前述のように、サーバ２００のモックアップ生成部２０８が、図４に例示するようなモックアップ２０１（実体はJSP（登録商標）コードを格納したファイル）を生成する。

図７の処理フローにおいて、まずサーバ２００のモックアップ生成部２０８は、図３に示すモックアップテンプレート２１３を読み込み、データjとする（ステップＳ２０１）。次にモックアップ生成部２０８は、クライアント１００から受信したテストルールセット１１１をデータRとする（ステップＳ２０２）。そしてモックアップ生成部２０８は、テストルールセットRから順次テストルールrを取り出し（ステップＳ２０３）、そのそれぞれについて次の処理を行う。まずモックアップ生成部２０８は、テストルールrの識別子を読み出しnとする（ステップＳ２０４）。ここで、テストルールrの識別子とは、図３における「zip-search」等である。次にモックアップ生成部２０８は、テストルールrのモックアップ要素のセットをＥとする（ステップＳ２０５）。ここで、テストルールrのモックアップ要素のセットをＥとは、テストルールrが備えるモックアップ要素の集合であって、例えばテストルールrが図３の「script-tag」の場合のEは、それぞれ「<%=p%>」、「<%=Utility.htmlEscape(p)%>」、および、「<script>validCode</script>」と定義された３個のモックアップ要素からなる集合である。次にモックアップ生成部２０８は、i=1とする（ステップＳ２０６）。そしてモックアップ生成部２０８は、モックアップ要素のセットＥから順次モックアップ要素eを取り出し、そのそれぞれについて次の処理を行う（ステップＳ２０７）。まずモックアップ生成部２０８は、ルール識別子ｎにiを文字列連結し、eのモックアップ要素識別子mを作る（ステップＳ２０８）。たとえば、モックアップ要素「<%=p%>」のモックアップ要素識別子mは、対応するルール識別子nが「script-tag」にi=1を文字列連結されることで生成され、結局「script-tag-1」となる。次にモックアップ生成部２０８は、HTTPリクエストから得たモックアップ要素識別子がmと一致するならばモックアップ要素eを実行するというコードを、jの埋め込み部分に追加する（ステップＳ２０９）。ここで、埋め込み部分とは、図３においてブロックタグ「mockup-behavior」で指定された領域が該当する。図４に基づいて説明すれば、たとえばモックアップ要素eが「<%=p%>」である場合、モックアップ要素識別子「script-tag-1」及びモックアップ要素「<%=p%>」とに基づき、ブロックタグ「mockup-behavior」で指定された領域に以下の３行のコードを追加する。

<% else if ("script-tag-1".equals(id)) [ %>
<%=p%>
<% ] %>
そしてモックアップ生成部２０８は、iに１を加える（ステップＳ２１０）。モックアップ生成部２０８は、以上の処理を全てのルールの全てのモックアップ要素eに対して行い（ステップＳ２１１、ステップＳ２１２）、最後にモックアップ生成部２０８は、結果のデータjをモックアップ２０１（JSP（登録商標）コードを記述したファイル）として出力する（ステップＳ２１３）。

以上のように、本発明の第１の実施の形態によれば、サーバ側アプリケーション向けブラックボックステストのテストルール動作確認を、クライアント側のみの操作によりおこなうことが可能となる。これにより、操作が簡単になり、複数のテストルールを一括して動作確認できるようになるため、テストルール動作確認を効率よく行えるようになる。また、動作確認のミスも生まれ難く、より正しい結果を得ることが可能となる
以下では本発明の第２の実施形態を説明する。

図８は本発明の第２の実施形態に係るテストルール動作確認システムの機能ブロック図である。第２の実施形態では、クライアント１００がサーバ２００に送信するテストリクエスト１１４において、モックアップ要素識別子２１１ではなく、モックアップ要素１１５そのものを付加する。そのため、第１の実施形態に係る図１の構成と比較して、クライアント１００は、モックアップ要素識別子付加部１０７の代わりにモックアップ要素付加部１０８を備える。一方、サーバ２００は、モックアップ要素選択部２０２を備えず、モックアップ要素２０３が１つのみである。また、テストルールセット１１１の送受信が不要なため、クライアント１００のルール送信部１０６およびサーバ２００のルール受信部２０７は必要ない。なお、図８及び以降の説明において、第１の実施形態に係る機能ブロック図である図１に記載されていると同じ構成要素については、同じ名前及び符号を用いる。

図９は本発明の第２の実施形態に係る処理フローである。基本的には第１の実施形態の処理を踏襲するが、以下の点が異なる。

まず、クライアント１００のテストルール読込部１０１は、テストルールセット１１１を読み込む（ステップＳ３０１）。次に、クライアント１００のテストルール読込部１０１は、テストリクエストを生成する（ステップＳ３０２）。そしてクライアント１００のモックアップ要素付加部１０８は、前記読み込んだテストルールセット１１１に基づき、前記リクエスト生成部１０２が生成したテストリクエストに、モックアップ要素１１５を付加する（ステップＳ３０３）。モックアップ要素は、第１の実施形態におけるモックアップ識別子と同様に、「X-Mock-id」ヘッダに格納する。

そして、クライアント１００のメッセージ送受信部１０３は、モックアップ要素１１５が付加されたテストリクエスト１１４をサーバ２００に送信する（ステップＳ３０４）。サーバ２００のメッセージ送受信部２０５は、前記クライアント１００が送信したモックアップ要素１１５が付加されたテストリクエスト１１４を受信する（ステップＳ３０５）。そして、サーバ２００のモックアップ生成部２０８は、まずモックアップテンプレート２１３を読み込み、前記受信したテストリクエスト１１４に付加されたモックアップ要素１１５を、モックアップテンプレートに組み込むことでモックアップを生成する（ステップＳ３０６）。この処理は、第１の実施形態に係るモックアップ生成処理（図７）とは異なり、図３におけるブロックタグ「mockup-behavior」で指定された領域に、モックアップ要素１１５を埋め込めばよい。

サーバ２００のモックアップ実行部２０６は、前記生成したモックアップ２０１を実行する（ステップＳ３０７）。これにより、サーバ２００のモックアップ２０１に埋め込まれた前記モックアップ要素２０３は、テストリクエスト１１４を処理する動作を行い、動作結果（出力のHTMLページ）であるテストレスポンス２１２を生成する（ステップＳ３０８）。次に、サーバ２００のメッセージ送受信部２０５は、前記生成したテストレスポンス２１２を、HTTPレスポンスの形式でクライアント１００に送信する（ステップ３０９）。クライアント１００のメッセージ送受信部１０３は、前記サーバ２００が送信したテストレスポンス２１２を受信する（ステップＳ３１０）。

以降の処理内容は、第１の実施形態に係る処理フロー中の対応する処理内容と同じであるため、簡単に説明する。クライアント１００のレスポンス判定部１０４は、前記受信したテストレスポンス２１２が、対応するテスト出力判定条件を満足するかを判定する（ステップＳ３１１）。クライアント１００の判定結果出力部１０５は、前記ステップＳ３１１で得られたテスト結果に基づき、判定結果１１３を出力装置であるモニタに出力する（ステップＳ３１２）。クライアント１００のリクエスト生成部１０２は、直前に送信したテストリクエスト１１４が現在の処理に係るテストルールの最後のモックアップ要素に係るものであるかを判定する（ステップＳ３１３）。もし最後のモックアップ要素でなければ、当該テストルールにおける次のモックアップ要素に対し、ステップＳ１０５に戻って処理を繰り返す。もし最後のモックアップ要素であればステップＳ３１４に進む。クライアント１００のリクエスト生成部１０２は、直前に送信したテストリクエスト１１４がテストルールセット１１１の最後のテストルールに係るものであるかを判定する（ステップＳ３１４）。もし最後のテストルールでなければ、次のテストルールに対し、ステップＳ３０２に戻って処理を繰り返す。もし最後のテストルールであれば処理を終了する。これに対し、サーバ２００は、クライアント１００が次のテストリクエスト１１４を送信した場合には、ステップＳ３０５に戻って処理を繰り返す（ステップＳ３１５）。そうでなければ終了する。

第２の実施形態によれば、第１の実施形態と同じ作用・効果を奏する。すなわち、サーバ側アプリケーション向けブラックボックステストのテストルール動作確認を、クライアント側のみの操作によりおこなうことが可能となる。これにより、操作が簡単になり、複数のテストルールを一括して動作確認できるようになるため、テストルール動作確認を効率よく行えるようになる。さらに、第２の実施形態は、第１の実施形態に比べて、事前のテストルールセットの送信が不要なため、ネットワークへの負担及び処理時間が低減される効果を奏する。ただし、HTTPヘッダに長い文字列を格納するのは一般的ではないため、特にサーバにおいて想定外の挙動を示す可能性もある。そのため、第２の実施形態は、HTTPヘッダに格納するモックアップ要素のサイズが十分に小さい場合のみ実施すべきである。

以上、本発明に係るテストルール動作確認システムの実施形態について説明したが、本発明は上記実施形態に限るものではなく、その技術的思想の範囲内で種々の設計変更が可能である。

例えば、上記実施の形態では、テスト対象であるサーバ側アプリケーションがWebアプリケーションであるが、サーバ側アプリケーションはWebアプリケーションに限るものではなく、ネットワークアプリケーションであればなんでも良い。

また、上記実施の形態では、モックアップの基盤としてJava（登録商標）サーブレットコンテナを使用し、モックアップ要素やモックアップをJavaServer Pages（JSP）（登録商標）コードの形式で記述するが、モックアップアプリケーションの基盤及びコード形式（プログラム言語）としては、Perl(Practical Extraction and Report Language)等を用いたCommon Gateway Interface（CGI）、PHP: Hypertext Preprocessor（PHP）、Active Server Pages（ASP）その他の技術を使用しても良い。

また、上記実施の形態では、レスポンス判定及び結果出力に係るステップ（第１の実施形態のステップＳ１１４、Ｓ１１５）をテストルール毎に逐次的に行っているが、これをバッチ処理のように行っても良い。すなわち、クライアントは、全てのテストルールに対してレスポンスを取得してから、それらにまとめて出力判定処理を行うような構成とすることができる。

また、上記実施の形態では、２つの装置をネットワーク接続してそれぞれの装置をクライアント１００とサーバ２００として機能させているが、クライアント１００とサーバ２００を物理的なネットワークを介さずに１つの装置で構成しても良い。また、テストルールセット１１１をクライアント１００に格納する代わりに、サーバ２００に格納しておきクライアント１００に送付する構成、若しくは不図示の第３のホスト上に格納しておきクライアント１００及びサーバ２００に送信する構成を採用しても良い。

また、上記実施の形態では、モックアップ要素識別子２１１或いはモックアップ要素１１５をHTTPヘッダに格納しているが、それ以外の箇所にモックアップ要素識別子２１１或いはモックアップ要素１１５を格納してもよい。ただし、推奨される格納先は、HTTPヘッダである。その理由は、アプリケーションの動作やテストに影響する可能性が低く、テストルールの動作確認時だけ特別にモックアップ要素識別子を付けるのではなく、本来のテスト時に付けてもほとんどの場合問題がないため、テストルールの動作確認作業を透明性の高い形で実現できるというメリットがあるためである。

最後に、以上ではテストルール動作確認システムの構成を説明したが、これらを構成するクライアント１００あるいはサーバ２００は、図１０に示すようなコンピュータ上で動作するプログラムによっても実現することができる。

本願発明に係るプログラムを実行するコンピュータのハードウェア構成の例を図１０に示す。コンピュータ１０のハードウェア構成として、例えば、Central Processing Unit（CPU）１１、主記憶１２、補助記憶装置１３、出力インタフェース１４、入力インタフェース１５、通信インタフェース１６がバス１７で接続されている。

CPU１１は後述する主記憶１２に格納されたプログラムを実行する。主記憶１２としては、通常はRandom Access Memory（RAM）が用いられ、後述する補助記憶装置１３から実行するプログラムや使用するデータを読み込んで一時的に格納する。補助記憶装置１３としては、通常はHard Disk Drive（HDD）が用いられ、プログラムやデータを格納してファイルとして保存する。なお、補助記憶装置１３としては、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリ等の外部記憶媒体を用いることもできる。

出力インタフェース１４には出力装置の一つとして表示装置であるモニタ１８が接続される。プログラムの実行結果などがモニタに出力され表示される。入力インタフェース１５には入力装置としてキーボード１９やマウス２０が接続され、これら入力装置からデータが入力される。通信インタフェース１７はネットワーク２１に接続される。コンピュータはネットワークを介して他のコンピュータとデータをやり取りする。

上記ハードウェア構成を、図１、図８及び図１１の機能ブロックと対応付けると以下のようになる。コンピュータをクライアント１００として機能させるためのプログラム（ルール読込部１０１、リクエスト生成部１０２、メッセージ送受信部１０３、レスポンス判定部１０４、判定結果出力部１０５、ルール送信部１０６、モックアップ要素識別子付加部１０７、および、モックアップ要素付加部１０８）、及びデータ（テストルールセット１１１およびルクエストテンプレート１１２）を予め補助記憶装置１３に格納させておく。プログラムが起動されると、当該プログラムおよびデータはまず主記憶１２に読み込まれ、その後主記憶１２とCPU１１とが連携することでプログラムが実行される。

また、コンピュータをサーバ２００として機能させるためのプログラム（モックアップ要素識別子受付部２０４、メッセージ送受信部２０５、モックアップ実行部２０６、ルール受信部２０７、および、モックアップ生成部２０８）、及びデータ（モックアップテンプレート２１３）を予め補助記憶装置１３に格納させておく。プログラムが起動されると、当該プログラムおよびデータはまず主記憶１２に読み込まれ、その後主記憶１２とCPU１１とが連携することでプログラムが実行される。プログラムであるモックアップ２０１は主記憶１２上で生成され、一旦補助記憶装置１３に保存される。補助記憶装置１３上のモックアップ２０１が実行されると、モックアップ２０１は主記憶１２に読み込まれ、モックアップ要素選択部２０２とモックアップ要素２０３とが実行される。

第１の実施形態に係るWebアプリケーション向けブラックボックステストのテストシステムに係る機能ブロック図である。 第１の実施形態に係るWebアプリケーション向けブラックボックステストのテストルールの一例を示した図である。 モックアップテンプレートの一例を示した図である。 第１の実施形態に係るモックアップを記述したコードの一例を示した図である。 第１の実施形態に係る処理手順を示したフローチャートである。 テスト結果の出力例を示した図である 第１の実施形態に係るモックアップ生成に係る処理手順の詳細を示したフローチャートである。 第２の実施形態に係るWebアプリケーション向けブラックボックステストのテストシステムに係る機能ブロック図である。 第２の実施形態に係る処理手順を示したフローチャートである。 クライアント及びサーバのハードウェア構成を示した図である。 従来技術であるWebアプリケーション向けブラックボックステストのテストシステムに係る機能ブロック図である。 従来技術であるWebアプリケーション向けブラックボックステストのテストルールの一例を示した図である。 従来技術であるWebアプリケーション向けブラックボックステストのリクエストテンプレートを示した図である。

１０ コンピュータ
１１ CPU
１２ 主記憶
１３ 補助記憶装置
１４ 出力インタフェース
１５ 入力インタフェース
１６ 通信インタフェース
１７ バス
１８ モニタ
１９ キーボード
２０ マウス
２１ ネットワーク
１００ クライアント
１０１ ルール読込部
１０２ リクエスト生成部
１０３ メッセージ送受信部
１０４ レスポンス判定部
１０５ 判定結果出力部
１０６ ルール送信部
１０７ モックアップ要素識別子付加部
１０８ モックアップ要素付加部
１１１ テストルールセット
１１２ リクエストテンプレート
１１３ 判定結果
１１４ テストリクエスト
１１５ モックアップ要素
２００ サーバ
２０１ モックアップ
２０２ モックアップ要素選択部
２０３ モックアップ要素
２０４ モックアップ要素識別子受付部
２０５ メッセージ送受信部
２０６ モックアップ実行部
２０７ ルール受信部
２０８ モックアップ生成部
２１１ モックアップ要素識別子
２１２ テストレスポンス
２１３ モックアップテンプレート

Claims (4)

1. アプリケーションに対するブラックボックステストを行うためのルールであって、アプリケーションへのテスト用入力データであるテスト入力パターンを含むデータであるテストルールに対する動作確認を、当該動作確認を行うために前記アプリケーションの機能を模倣するアプリケーションであるモックアップを用いるとともに、ネットワーク接続したクライアントと連携して行うテストルール動作確認サーバ装置であって、
   前記モックアップの個々の動作を定義したデータであるモックアップ要素と、当該モックアップ要素の識別子であるモックアップ要素識別子とを対応付けたデータを前記クライアント装置から受信する手段と、
   前記受信したモックアップ要素とモックアップ要素識別子とを対応づけて記憶手段に格納する手段と、
   モックアップ要素識別子を付加されたテスト入力パターンを前記クライアント装置から受信する手段と、
   前記受信したテスト入力パターンに付加されたモックアップ要素識別子に対応付けられた前記モックアップ要素を記憶手段から読み出して、当該モックアップ要素により定義されたモックアップの動作によって、前記受信したテスト入力パターンを処理させることでテスト出力を生成する手段と、
   前記生成したテスト出力を前記クライアント装置に送信する手段とを備える
   ことを特徴とするテストルール動作確認サーバ装置。
2. アプリケーションに対するブラックボックステストを行うためのテストルールに対する動作確認を、当該動作確認を行うために前記アプリケーションの機能を模倣するアプリケーションであるモックアップを用いて行う、クライアントとサーバとがネットワークで接続されたテストルール動作確認システムであって、
   前記クライアントは、
   アプリケーションへのテスト用入力データであるテスト入力パターンとアプリケーションの出力データの合否を判定するための条件であるテスト出力判定条件とを対応付けたデータである前記テストルールと、当該テストルールの動作確認を行うための前記モックアップの個々の動作を定義したデータであるモックアップ要素と、当該モックアップ要素の識別子であるモックアップ要素識別子とを対応付けて格納した記憶手段と、
   モックアップ要素と当該モックアップ要素に対応付けられたモックアップ要素識別子とを前記記憶手段から読み出して前記サーバに送信する手段と、
   テスト入力パターンと当該テスト入力パターンに対応づけられたモックアップ要素識別子を前記記憶手段から読み出して、当該テスト入力パターンに当該モックアップ要素識別子を付加して前記サーバに送信する手段と、
   前記テスト入力パターンに対するテスト出力をサーバから受信する手段と、
   前記送信したテスト入力パターンに対応づけられたテスト出力判定条件を前記記憶手段から読み出して、前記テスト出力が当該テスト出力判定条件を満たすか否かを判定する手段と、
   前記判定した結果を出力手段に出力する手段とを備え、
   前記サーバは、
   前記クライアントが送信したモックアップ要素と当該モックアップ要素に対応付けられたモックアップ要素識別子とを受信する手段と、
   前記受信したモックアップ要素とモックアップ要素識別子とを対応づけて記憶手段に格納する手段と、
   前記クライアントが送信したモックアップ要素識別子を付加されたテスト入力パターンを受信する手段と、
   前記受信したテスト入力パターンに付加されたモックアップ要素識別子に対応付けられた前記モックアップ要素を記憶手段から読み出して、当該モックアップ要素により定義されたモックアップの動作によって、前記受信したテスト入力パターンを処理させることでテスト出力を生成する手段と、
   前記生成したテスト出力を前記クライアント装置に送信する手段とを備える
   ことを特徴とするテストルール動作確認システム。
3. アプリケーションに対するブラックボックステストを行うためのルールであって、テスト入力パターンを含むデータであるテストルールに対する動作確認を、当該動作確認を行うために前記アプリケーションの機能を模倣するアプリケーションであるモックアップを用いるとともに、ネットワーク接続したクライアントと連携して行うテストルール動作確認サーバ装置であって、
   モックアップ要素を付加されたテスト入力パターンを前記クライアント装置から受信する手段と、
   前記受信したテスト入力パターンに付加されたモックアップ要素により定義されたモックアップの動作によって、前記受信したテスト入力パターンを処理させることでテスト出力を生成する手段と、
   前記生成したテスト出力を前記クライアント装置に送信する手段とを備える
   ことを特徴とするテストルール動作確認サーバ装置。
4. アプリケーションに対するブラックボックステストを行うためのテストルールに対する動作確認を、当該動作確認を行うために前記アプリケーションの機能を模倣するアプリケーションであるモックアップを用いて行う、クライアントとサーバとがネットワークで接続されたテストルール動作確認システムであって、
   前記クライアントは、
   アプリケーションへのテスト用入力データであるテスト入力パターンとアプリケーションの出力データの合否を判定するための条件であるテスト出力判定条件とを対応付けたデータである前記テストルールと当該テストルールの動作確認を行うための前記モックアップの個々の動作を定義したデータであるモックアップ要素を格納した記憶手段と、
   テスト入力パターンと当該テスト入力パターンに対応づけられたモックアップ要素を前記記憶手段から読み出して、当該テスト入力パターンに当該モックアップ要素を付加して前記サーバに送信する手段と、
   前記テスト入力パターンに対するテスト出力をサーバから受信する手段と、
   前記送信したテスト入力パターンに対応づけられたテスト出力判定条件を前記記憶手段から読み出して、前記テスト出力が当該テスト出力判定条件を満たすか否かを判定する手段と、
   前記判定した結果を出力手段に出力する手段とを備え、
   前記サーバは、
   前記クライアントが送信したモックアップ要素を付加されたテスト入力パターンを受信する手段と、
   前記受信したテスト入力パターンに付加されたモックアップ要素により定義されたモックアップの動作によって、前記受信したテスト入力パターンを処理させることでテスト出力を生成する手段と、
   前記生成したテスト出力を前記クライアント装置に送信する手段とを備える
   ことを特徴とするテストルール動作確認システム。

Images