JP2015170203A - 検証方法、検証プログラムおよび検証装置 - Google Patents

Abstract

【課題】パケットの順序を考慮した検証処理を実行することを課題とする。
【解決手段】検証装置は、検証対象装置からパケットを受信する。検証装置は、受信された前記パケットに対する応答を検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、応答を検証対象装置に送信可能かを判定する。検証装置は、送信可能と判定した場合は、応答を検証対象装置に送信し、送信不可能と判断した場合は、応答が送信可能になるまで待機してから検証対象装置に送信する。
【選択図】図２

Description

本発明は、検証方法、検証プログラムおよび検証装置に関する。

従来から、稼働しているシステムにおいて、システムで動作するプログラムを更新またはシステムに新たなプログラムを追加する場合に、検証システムを用いて事前に検証することが行われている。例えば、Ｗｅｂサーバ、ＤＢ（DataBase）サーバ、クライアント装置で構成される３階層システムにおいて、Ｗｅｂサーバのプログラムをアップデートする場合に、同じ階層で構成された検証システムを用いてアップデートで異常が発生しないかを検証する。

検証システムとしては、キャプチャデータを利用した検証システムが知られている。例えば、検証システムは、実動システムからパケットをキャプチャして記録し、更新したプログラムを搭載した検証対象のサーバ装置に、キャプチャしたパケットを出力する。そして、検証システムは、検証対象のサーバ装置から受信した応答データと、キャプチャした応答データとを比較して、実動システムと同じ動きができているかを検証する。

特開２０１２−１９５６９９号公報 特開２０１０−２８２２６６号公報

しかしながら、上記技術では、所定のリクエストに対して応答があるか否かの検証しかできないので、検証環境でパケットの順序変更が発生した場合に、検証処理を維持することが困難であり、順序を考慮した検証を実行することができない。

例えば、３階層システムを例にして説明すると、検証システムにおいて、検証用Ｗｅｂサーバから検証用ＤＢサーバへ発行されるリクエストの順番が何らかの要因で実動環境と変わる場合がある。この場合、検証用ＤＢサーバは、キャプチャデータと異なる順序でリクエストを受信することになる。検証用ＤＢサーバは、キャプチャしたデータ順序にしたがって応答を送信するので、リクエストの受信順序が異なると、応答を送信することができない。

また、検証用ＤＢサーバが、リクエストの受信順に関係なく応答したとしても、応答されたデータが正しいデータか否かを判定できないので、検証処理そのものの信頼性が低下する。

１つの側面では、パケットの順序を考慮した検証処理を実行できる検証方法、検証プログラムおよび検証装置を提供することを目的とする。

第１の案では、検証方法は、検証対象装置からパケットを受信する処理を実行する。検証方法は、受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定する処理を実行する。検証方法は、送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する処理を実行する。

１実施形態によれば、パケットの順序を考慮した検証処理を実行できる。

図１は、実施例１に係るシステムの全体構成の例を示す図である。 図２は、実施例１に係る検証装置の機能構成を示す機能ブロック図である。 図３は、パケットキャプチャテーブルに記憶される情報の例を示す図である。 図４は、クエリ分析テーブルに記憶される情報の例を示す図である。 図５は、キュー管理テーブルに記憶される情報の例を示す図である。 図６は、検証結果テーブルに記憶される情報の例を示す図である。 図７は、クライアント擬似動作処理の流れを示すフローチャートである。 図８は、ＤＢサーバ擬似動作処理の流れを示すフローチャートである。 図９は、観測時と検証時のパケット到着順を説明する図である。 図１０は、実施例１に係る検証装置の処理を説明する図である。 図１１は、実施例２に係るＤＢサーバ擬似動作処理の流れを示すフローチャートである。 図１２は、実施例２に係る検証装置の処理を説明する図である。 図１３は、デットロックの回避手法を説明する図である。 図１４は、ハードウェア構成例を示す図である。

以下に、本願の開示する検証方法、検証プログラムおよび検証装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１に係るシステムの全体構成の例を示す図である。図１に示すように、このシステムは、複数のクライアント端末１と実動ＡＰ（Application）サーバ２と実動ＤＢサーバ３とスイッチ５とを有する実動環境と、検証装置１０と検証ＡＰサーバ５０とを有する検証環境とを有して構成される。なお、各環境が有する装置の数は一例であり、図示したものに限定されない。

実動環境は、検証環境とは別のネットワークで形成され、各クライアント端末１に対してＷｅｂサービス等の各種サービスを提供するシステムである。検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するための検証システムである。

各クライアント端末１は、Ｗｅｂブラウザ等を用いて実動ＡＰサーバ２にアクセスして各サービスを利用するコンピュータであり、例えば実動ＡＰサーバ２を介して実動ＤＢサーバ３が保持するデータベースを更新する。

実動ＡＰサーバ２は、クライアント端末１から要求を受信して、実動ＤＢサーバ３へのトランザクションを実行するサーバであり、ＨＴＭＬ文書などを蓄積してＷｅｂサービスを提供するＷｅｂアプリケーションサーバとしての機能を有していてもよい。

例えば、実動ＡＰサーバ２は、クライアント端末１から受信した要求に対応したアプリケーションを実行して、実動ＤＢサーバ３へリクエストを送信する。そして、実動ＡＰサーバ２は、当該リクエストに対するレスポンスを実動ＤＢサーバ３から受信して、クライアント端末１に送信する。

実動ＤＢサーバ３は、データベースを有し、実動ＡＰサーバ２から受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動ＡＰサーバ２に送信する。なお、実動ＤＢサーバ３が有するデータベースは、関係データベース、オブジェクトデータベース、ＫＶＳ（キーバリューストア）など様々なデータベースを利用できる。

スイッチ５は、実動ＡＰサーバ２、実動ＤＢサーバ３、各クライアント端末１の各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ５としては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ５は、ポートミラーリングを実行しており、実動ＡＰサーバ２、実動ＤＢサーバ３、クライアント端末１の各々から受信したデータを検証装置１０に送信する。

検証環境は、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして検証装置１０に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、実動ＡＰサーバ２だけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、検証装置１０は、実動ＡＰサーバ２と同様の機能を有する検証ＡＰサーバ５０に対して検証を実行する。

ここでは、一例として、実動ＡＰサーバ２を検証することとするので、検証環境は検証ＡＰサーバ５０を有するものとする。検証ＡＰサーバ５０は、実動ＡＰサーバ２と同様の機能を実装した検証対象のサーバであり、検証装置１０と接続される。この検証ＡＰサーバ５０には、検証ＡＰサーバ５０が直接通信する検証対象外の装置である、実動ＤＢサーバ３とクライアント端末１各々のアドレスとして、検証装置１０のＩＰ（Internet Protocol）アドレスを設定しておく。

すなわち、検証環境は、検証装置１０がクライアント端末１および実動ＤＢサーバ３の動作を擬似して、実動ＡＰサーバ２の動作を検証する。なお、クライアント端末１の動作を擬似する検証装置と、実動ＤＢサーバ３の動作を擬似する検証装置とを別々の筐体で実行してもよい。

検証ＡＰサーバ５０は、実動環境の実動ＡＰサーバ２が処理する実トランザクションと同様のトランザクションを実行して、データを検証装置１０に送信する。また、検証ＡＰサーバ５０は、検証装置１０からパケットを受信した場合に、当該データに対応する応答データを検証装置１０に送信する。

検証装置１０は、検証対象装置である検証ＡＰサーバ５０からパケットを受信する。そして、検証装置１０は、受信したパケットに対する応答を検証ＡＰサーバ５０に送信する順序に関する情報を含んだ制御リストに基づいて、検証ＡＰサーバ５０に送信可能かを判定する。その後、検証装置１０は、送信可能と判定した場合は、応答を検証ＡＰサーバ５０に送信し、送信不可能と判断した場合は、受信したパケットに対する応答が送信可能になるまで待機してから検証ＡＰサーバ５０に送信する。

例えば、検証装置１０は、スイッチ５のポートミラーリング等を利用して、実動環境のパケットをキャプチャして保持する。そして、検証装置１０は、検証ＡＰサーバ５０の検証時に、検証環境で検証ＡＰサーバ５０から受信したリクエストの到着順ではなく、実動環境で観測されたリクエストの到着順で、レスポンスを応答する。この結果、検証装置１０は、パケットの順序を考慮した検証ができる。

［検証装置の機能構成］
図２は、実施例１に係る検証装置の機能構成を示す機能ブロック図である。図２に示すように、検証装置１０は、通信処理部１１、記憶部１２、制御部２０を有する。

通信処理部１１は、少なくとも１つのポートを有し、検証装置１０と検証ＡＰサーバ５０との間の通信を制御する。また、通信処理部１１は、検証装置１０とスイッチ５との間の通信も制御する。

この通信処理部１１の各ポートには、実動環境で使用するＩＰアドレスと、検証対象外装置のＩＰアドレスが設定される。図１の場合、通信処理部１１の第１ポートには、実動環境用のＩＰアドレスが設定される。そして、通信処理部１１の第２ポートには、実動ＤＢサーバ３宛として使用されるＩＰアドレスが設定される。さらに、通信処理部１１の第３ポートには、クライアント端末１宛として使用されるＩＰアドレスが設定される。

記憶部１２は、メモリやハードディスクなどの記憶装置であり、パケットキャプチャテーブル１３、クエリ分析テーブル１４、キュー管理テーブル１５、検証結果テーブル１６を記憶する。

パケットキャプチャテーブル１３は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持するテーブルである。すなわち、パケットキャプチャテーブル１３は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。パケットキャプチャテーブル１３には、後述するパケットキャプチャ部２１によって、１日や１週間など所定間隔でキャプチャされたキャプチャデータが格納される。

図３は、パケットキャプチャテーブルに記憶される情報の例を示す図である。図３に示すように、パケットキャプチャテーブル１３は、「シーケンシャル番号、送信元、宛先、送信パケット、送信時間」などを対応付けて記憶する。

ここで記憶される「シーケンシャル番号」は、パケットキャプチャリングされた順番を示し、「送信元」は、キャプチャされたパケットの送信元を示す。「宛先」は、キャプチャされたパケットの宛先を示し、「送信パケット」は、キャプチャされたパケットの情報を示す。「送信時間」は、キャプチャされたパケットの送信時間を示す。なお、パケットキャプチャテーブル１３は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。また、パケットキャプチャテーブル１３は、上記情報以外の情報として、例えばパケットの種別、処理の成否などを記憶してもよい。

図３の例の場合、１番目に、クライアント端末１から実動ＡＰサーバ２に対して、時刻Ｔ０に送信されたＨＴＴＰ：ｒｅｑ１がキャプチャされたことを示す。２番目に、クライアント端末１から実動ＡＰサーバ２に対して、時刻Ｔ１に送信されたＨＴＴＰ：ｒｅｑ２がキャプチャされたことを示す。３番目に、実動ＡＰサーバ２から実動ＤＢサーバ３に送信されたＳＱＬ：ｒｅｑ１がキャプチャされたことを示す。４番目に、実動ＤＢサーバ３から実動ＡＰサーバ２に送信されたＳＱＬ：ｒｅｓ１がキャプチャされたことを示す。なお、Ｒｅｑは、Ｒｅｑｕｅｓｔの略であり、Ｒｅｓは、Ｒｅｓｐｏｎｓｅの略である。

クエリ分析テーブル１４は、実動ＤＢサーバ３に送信されたパケットの情報を記憶するテーブルである。すなわち、クエリ分析テーブル１４は、実動環境で実動ＤＢサーバ３へ発行されたＳＱＬ（Structured Query Language）文に関する情報を記憶する。

図４は、クエリ分析テーブルに記憶される情報の例を示す図である。図４に示すように、クエリ分析テーブル１４は、「応答、クエリ番号、クエリ、要求種別、参照テーブル、成否、送信時間」を対応付けて記憶する。この情報は、後述するキャプチャ分析部２２によって生成される。

ここで記憶される「応答」は、検証環境で応答として送信されたか否かを示す情報であり、送信された場合にはチェックされる。「クエリ番号」は、実動環境で発生したクエリの順番を示す番号である。「クエリ」は、実動環境で発生したクエリであり、例えばＳＱＬ文の詳細が設定される。「要求種別」は、発行されたＳＱＬ文の種別であり、ＲｅａｄやＷｒｉｔｅが設定される。「参照テーブル」は、発行されたＳＱＬ文の実行対象のテーブルを示す情報である。「成否」は、発行されたＳＱＬ文の成否であり、成功した場合は「成」、失敗した場合は「否」が設定される。「送信時間」は、実動環境においてＳＱＬが発行された時間である。

図４の例は、いずれもまだ検証環境で実行されていない例である。また、図４の例は、クエリ番号１、２、３の順に、クエリ「ＳＱＬ：ｒｅｑ１」、「ＳＱＬ：ｒｅｑ２」、「ＳＱＬ：ｒｅｑ３」を発行して検証することを示している。そして、「ＳＱＬ：ｒｅｑ１」は、テーブルＡをＲｅａｄするクエリであり、実動環境では時刻Ｔ２に実行されて成功したことを示す。

キュー管理テーブル１５は、検証環境で検証ＡＰサーバ５０に送信するパケットを保持するキューの状態を管理するテーブルである。図５は、キュー管理テーブルに記憶される情報の例を示す図である。ここで記憶される情報は、随時更新される。図５に示すように、キュー管理テーブル１５は、「先行クエリ待ちキュー、待ちクエリ」を対応付けて記憶する。

ここで記憶される「先行クエリ待ちキュー」は、検証環境で未到着のクエリの列を示し、「待ちクエリ」は、検証環境で現在到着を待っている、次に届くべきクエリを示す。図５の場合、検証環境で未到着のクエリはなく、クエリ名が「ＳＱＬ：ｒｅｑ１」であるクエリが次に送信すべきクエリであることを示している。

検証結果テーブル１６は、検証ＡＰサーバ５０に対して実行した検証処理の検証結果を記憶するテーブルである。図６は、検証結果テーブルに記憶される情報の例を示す図である。図６に示すように、検証結果テーブル１６は、「検証対象装置、シーケンシャル番号、送信パケット、受信パケット、検証結果」を対応付けて記憶する。

ここで記憶される「検証対象装置」は、検証処理の対象を示し、本実施例では検証ＡＰサーバ５０である。「シーケンシャル番号」は、検証したパケットの順番であり、パケットキャプチャテーブル１３のシーケンシャル番号と同じである。「送信パケット」は、検証処理で送信したパケットを示し、「受信パケット」は、検証処理で受信したパケットを示す。「検証結果」は、検証結果を示し、実動環境と同じパケットが送受信された場合は「成功」が設定され、それ以外は「失敗」が設定される。

図６は、検証ＡＰサーバ５０への検証結果を示している。この検証処理は、まず「ＨＴＴＰ：ｒｅｑ１」が送信され、次に「ＨＴＴＰ：ｒｅｑ２」が送信され、その後「ＳＱＬ：ｒｅｑ１」が受信され、いずれも実動環境と同じ順番であり、成功したことを示す。

制御部２０は、プロセッサなどであり、パケットキャプチャ部２１、キャプチャ分析部２２、クライアント擬似部２３、ＤＢサーバ擬似部２４、検証部２５を有する。なお、各処理部は、電子回路やプロセッサが実行するプロセスの一例である。

パケットキャプチャ部２１は、スイッチ５を介して、実動環境で実際に送受信されたパケットをキャプチャして、パケットキャプチャテーブル１３に格納する処理部である。例えば、クライアント端末１が、実動ＡＰサーバ２にアクセスしてアプリケーションを実行し、実動ＡＰサーバ２が、アプリケーションの実行によって実動ＤＢサーバ３に対してＤＢアクセスを実行したとする。

この場合、はじめに、パケットキャプチャ部２１は、クライアント端末１から実動ＡＰサーバ２へのＤＢ処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部２１は、実動ＡＰサーバ２から実動ＤＢサーバ３へ送信されたＤＢリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部２１は、実動ＤＢサーバ３から実動ＡＰサーバ２へ送信されたＤＢレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部２１は、実動ＡＰサーバ２からクライアント端末１へ送信されたＤＢ処理要求に対する応答を示すパケットをキャプチャする。

つまり、パケットキャプチャ部２１は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、パケットキャプチャテーブル１３に格納する。なお、パケットキャプチャ部２１は、キャプチャしたパケットそのものをパケットキャプチャテーブル１３に格納してもよい。

キャプチャ分析部２２は、キャプチャされたパケットの情報から実動ＤＢサーバ３へ発行されたパケットを抽出する処理部である。具体的には、キャプチャ分析部２２は、パケットキャプチャテーブル１３に記憶される情報を参照し、実動ＡＰサーバ２から実動ＤＢサーバ３へ発行されたＳＱＬ文を抽出する。そして、キャプチャ分析部２２は、抽出したＳＱＬ文について、参照先のテーブル、要求種別、成否、送信時間等を抽出する。その後、キャプチャ分析部２２は、抽出した情報をクエリ分析テーブル１４に格納する。

なお、キャプチャ分析部２２が処理を実行するタイミングは、検証部２５によって検証処理の開始を指示されたタイミングでもよく、パケットキャプチャテーブル１３に情報が格納されたタイミングでもよく、任意に設定できる。検証処理の開始を指示されたタイミングで実行する場合、キャプチャ分析部２２は、分析が完了したことをクライアント擬似部２３およびＤＢサーバ擬似部２４に通知する。

クライアント擬似部２３は、実動環境におけるクライアント端末１の動作を擬似する処理部である。具体的には、クライアント擬似部２３は、検証処理が開始されると、パケットキャプチャテーブル１３を参照して、クライアント端末１が送信したＨＴＴＰ：ｒｅｑを検証ＡＰサーバ５０に送信する。また、クライアント擬似部２３は、検証ＡＰサーバ５０からＨＴＴＰ：ｒｅｓを受信する。

そして、クライアント擬似部２３は、ＨＴＴＰ：ｒｅｑを送信したことおよび送信時間と、ＨＴＴＰ：ｒｅｓを受信したことおよびＨＴＴＰ：ｒｅｓの受信時間とを検証部２５に出力する。

例えば、図３の場合、クライアント擬似部２３は、検証ＡＰサーバ５０にＨＴＴＰ：ｒｅｑ１を送信した後、「Ｔ１−Ｔ０」時間経過後に、検証ＡＰサーバ５０にＨＴＴＰ：ｒｅｑ２を送信する。

ＤＢサーバ擬似部２４は、判定部２４ａと送信部２４ｂとを有し、これらによって実動環境における実動ＤＢサーバ３の動作を擬似する処理部である。

判定部２４ａは、検証対象の検証ＡＰサーバ５０からパケットを受信すると、当該パケットに対する応答が送信可能か否かを判定する処理部である。具体的には、判定部２４ａは、検証対象の検証ＡＰサーバ５０からＳＱＬ文を受信した場合、受信したＳＱＬ文の実行結果を検証ＡＰサーバ５０に送信する順序に関する情報を含んだクエリ分析テーブル１４やキュー管理テーブル１５を参照する。そして、ＤＢサーバ擬似部２４は、応答を検証ＡＰサーバ５０に送信可能かを判定する。

例えば、判定部２４ａは、検証処理が開始されると、クエリ分析テーブル１４を参照して、応答を返信していない未受信のクエリのうち、最もクエリ番号が若いクエリを特定する。そして、判定部２４ａは、特定したクエリ番号に対応するクエリの名称等をキュー管理テーブル１５の待ちクエリに格納して、キューの状態を管理する。

この状態で、判定部２４ａは、検証ＡＰサーバ５０から新たなクエリを受信すると、新たなクエリがキュー管理テーブル１５の待ちクエリと一致するかを判定する。そして、判定部２４ａは、新たなクエリが待ちクエリと一致する場合、応答を送信可能と判定し、新たなクエリの情報を送信部２４ｂに出力する。また、判定部２４ａは、上記手法と同様の手法で、次の待ちクエリを特定して、キュー管理テーブル１５の待ちクエリに格納する。

一方、判定部２４ａは、新たなクエリが待ちクエリと一致しない場合、応答を送信不可能と判定する。そして、判定部２４ａは、受信した新たなクエリの名称等を、キュー管理テーブル１５の先行クエリ待ちキューに格納する。

その後、判定部２４ａは、検証ＡＰサーバ５０からクエリをさらに受信すると、受信クエリがキュー管理テーブル１５の待ちクエリと一致するかを判定する。そして、判定部２４ａは、受信クエリが待ちクエリと一致する場合、応答を送信可能と判定し、受信クエリの情報を送信部２４ｂに出力する。続いて、判定部２４ａは、キュー管理テーブル１５の先行クエリ待ちキューに格納されているクエリのうち先頭のクエリの情報を、待ちクエリに格納する。

一方、判定部２４ａは、受信クエリが待ちクエリと一致しない場合、応答を送信不可能と判定する。そして、判定部２４ａは、格納順になるように、先行クエリ待ちキューに格納されている最後のクエリの後ろに、受信クエリの情報を格納する。

このようにして、判定部２４ａは、キュー管理テーブル１５を使用して待ちクエリの状態を管理し、検証ＡＰサーバ５０から受信したクエリが実動環境で受信された順番と同じか否かを判定する。このようにして、判定部２４ａは、検証時も実動環境と同じ順番でパケットを送受信して、検証処理を実行する。

送信部２４ｂは、判定部２４ａによって送信可能と判定されたクエリの応答を検証ＡＰサーバ５０に送信する処理部である。具体的には、送信部２４ｂは、判定部２４ａから送信可能と判定されたクエリの情報を受信すると、パケットキャプチャテーブル１３を参照して、当該クエリの応答を特定する。その後、送信部２４ｂは、特定したクエリの応答を検証ＡＰサーバ５０に送信する。また、送信部２４ｂは、クエリが受信されたこと、受信したクエリの情報、送信した応答クエリの情報などを検証部２５に出力する。

検証部２５は、ユーザの指示操作にしたがって検証処理を開始し、各処理部から検証結果を受信して検証結果テーブル１６を作成する処理部である。具体的には、検証部２５は、検証開始の指示を受け付けると、キャプチャ分析部２２、クライアント擬似部２３、ＤＢサーバ擬似部２４等に検証開始を指示する。

その後、検証部２５は、クライアント擬似部２３から、クライアント擬似部２３が送信したＨＴＴＰリクエストとクライアント擬似部２３が受信したＨＴＴＰレスポンスとに関する情報を受信する。同様に、検証部２５は、ＤＢサーバ擬似部２４から、ＤＢサーバ擬似部２４が受信したＳＱＬリクエストとＤＢサーバ擬似部２４が送信したＳＱＬレスポンスとに関する情報を受信する。

そして、検証部２５は、受信したこれらの情報を検証結果テーブル１６に格納するとともに、実動環境と同じ情報を送受信したかを判定する。検証部２５は、実動環境と同じ情報を送受信した場合、検証結果に「成功」を格納し、実動環境と異なる情報を送受信した場合、検証結果に「失敗」を格納する。このようにして、検証部２５は、検証環境で送受信された情報が実動環境と同じか否かを判定し、その結果を検証結果テーブル１６に格納する。

［クライアント擬似処理の流れ］
図７は、クライアント擬似動作処理の流れを示すフローチャートである。図７に示すように、クライアント擬似部２３は、検証部２５によって検証処理の開始が指示されると（Ｓ１０１：Ｙｅｓ）、パケットキャプチャリングした全パケットの送信が完了しているかを判定する（Ｓ１０２）。

そして、クライアント擬似部２３は、全パケットの送信が完了している場合（Ｓ１０２：Ｙｅｓ）、処理を終了する。

一方で、クライアント擬似部２３は、全パケットの送信が完了していない場合（Ｓ１０２：Ｎｏ）、パケットキャプチャテーブル１３を参照して、送信待ちのパケットがあるかを判定する（Ｓ１０３）。

そして、クライアント擬似部２３は、送信待ちのパケットがある場合（Ｓ１０３：Ｙｅｓ）、クライアント端末１の動作を擬似的に実行して、検証対象の検証ＡＰサーバ５０に対してパケットを送信する（Ｓ１０４）。つまり、クライアント擬似部２３は、検証環境に、実動環境と同様のトランザクションを発生させる。

そして、クライアント擬似部２３は、検証ＡＰサーバ５０に対してパケットを送信したことで、パケットキャプチャテーブル１３の全パケットに対して処理を実行した場合には（Ｓ１０２：Ｙｅｓ）、処理を終了する。

なお、Ｓ１０３において、クライアント擬似部２３は、パケットキャプチャテーブル１３に送信待ちのパケットが存在しないと判定した場合には（Ｓ１０３：Ｎｏ）、Ｓ１０２以降の処理を繰り返す。

［ＤＢサーバ擬似処理の流れ］
図８は、ＤＢサーバ擬似動作処理の流れを示すフローチャートである。図８に示すように、ＤＢサーバ擬似部２４の判定部２４ａは、検証ＡＰサーバ５０からリクエストを受信すると（Ｓ２０１：Ｙｅｓ）、受信したリクエストがキュー管理テーブル１５の待ちクエリと同一かを判定する（Ｓ２０２）。

そして、判定部２４ａによって受信クエリが待ちクエリと同一であると判定された場合（Ｓ２０２：Ｙｅｓ）、送信部２４ｂは、受信クエリに対応するレスポンスをパケットキャプチャテーブル１３から特定して、検証ＡＰサーバ５０に応答する（Ｓ２０３）。

その後、判定部２４ａは、送信部２４ｂによってリクエストが送信されると、キュー管理テーブル１５の待ちクエリを更新する（Ｓ２０４）。例えば、判定部２４ａは、クエリ分析テーブル１４において、送信したリクエストに対応するクエリの「応答」にチェックする。さらに、判定部２４ａは、クエリ分析テーブル１４に記憶される分析結果にしたがって次の受信対象のクエリを特定して、キュー管理テーブル１５の待ちクエリに格納する。

ここで、判定部２４ａは、キュー管理テーブル１５の先行クエリ待ちキューが空である場合（Ｓ２０５：Ｙｅｓ）、処理中フラグを真に設定する（Ｓ２０６）。すなわち、判定部２４ａは、実動環境と同じ順番でリクエスト（ＳＱＬ文）を受信していると判定する。なお、処理中フラグは、メモリ等に格納されており、判定部２４ａによって随時更新される。

一方、判定部２４ａは、キュー管理テーブル１５の先行クエリ待ちキューにクエリが格納されている場合（Ｓ２０５：Ｎｏ）、先行クエリ待ちキューに格納されているクエリの先頭を削除して新たな待ちクエリとして登録する（Ｓ２０７）。

また、Ｓ２０２において、判定部２４ａが、受信クエリが待ちクエリと同一ではないと判定した場合（Ｓ２０２：Ｎｏ）、受信クエリをキュー管理テーブル１５の先行クエリ待ちキューに格納する（Ｓ２０８）。続いて、判定部２４ａは、処理中フラグを偽に設定する（Ｓ２０９）、処理を終了する。

［パケットの到着順序の説明］
ここでは、パケットの到着順が観測時と検証時とで異なる場合の例を説明する。図９は、観測時と検証時のパケット到着順を説明する図である。なお、図９では、クライアント端末をＣＬ、ＡＰサーバをＡＰ、ＤＢサーバをＤＢと記憶する場合がある。

図９に示すように、観測時すなわちパケットキャプチャリング時は、クライアント端末１から実動ＡＰサーバ２にＨＴＴＰ：ｒｅｑ１が送信された後、ＨＴＴＰ：ｒｅｑ２が送信される。

実動ＡＰサーバ２は、上記２つのＨＴＴＰリクエストを受信した後、実動ＤＢサーバ３にＳＱＬ：ｒｅｑ１を送信し、実動ＤＢサーバ３は、ＳＱＬ：ｒｅｓ１を実動ＡＰサーバ２に応答する。続いて、実動ＡＰサーバ２は、実動ＤＢサーバ３にＳＱＬ：ｒｅｑ２を送信し、実動ＤＢサーバ３は、ＳＱＬ：ｒｅｓ２を実動ＡＰサーバ２に応答する。

その後、実動ＡＰサーバ２は、上記２つのＳＱＬリクエストに対する応答を受信すると、ＨＴＴＰ：ｒｅｑ１に対する応答としてＨＴＴＰ：ｒｅｓ１をクライアント端末１に応答する。さらにその後、実動ＡＰサーバ２は、ＨＴＴＰ：ｒｅｑ２に対する応答としてＨＴＴＰ：ｒｅｓ２をクライアント端末１に応答する。

これに対して、検証時、クライアント端末１の動作を擬似する検証装置１０から検証ＡＰサーバ５０にＨＴＴＰ：ｒｅｑ１が送信された後、ＨＴＴＰ：ｒｅｑ２が送信される。

検証ＡＰサーバ５０は、上記２つのＨＴＴＰリクエストを受信した後、実動ＤＢサーバ３の動作を擬似する検証装置１０にＳＱＬ：ｒｅｑ２を送信し、検証装置１０は、ＳＱＬ：ｒｅｓ２を検証ＡＰサーバ５０に応答する。続いて、検証ＡＰサーバ５０は、検証装置１０にＳＱＬ：ｒｅｑ１を送信し、検証装置１０は、ＳＱＬ：ｒｅｓ１を検証ＡＰサーバ５０に応答する。

その後、検証ＡＰサーバ５０は、上記２つのＳＱＬリクエストに対する応答を受信すると、ＨＴＴＰ：ｒｅｓ２、ＨＴＴＰ：ｒｅｓ１を、クライアント端末１の動作を擬似する検証装置１０に順次応答する。

両方を比較すると、クライアント端末１からＡＰサーバへのＨＴＴＰリクエストの順は、観測時と検証時とで順番が同じである。しかし、ＡＰサーバからＤＢサーバへのＳＱＬリクエストは、観測時と検証時とで順番が異なる。このため、ＤＢサーバからＡＰサーバへのＳＱＬレスポンスも、観測時と検証時とで順番が異なる。さらに、ＡＰサーバからクライアント端末１へのＨＴＴＰレスポンスも異なる。

つまり、図９のような検証結果が得られた場合、検証装置１０は、各リクエストに対する各レスポンスを受信しているが、受信順序が異なるところがある。この場合、検証装置１０は、検証ＡＰサーバ５０の内部処理等が原因か、検証装置１０と検証ＡＰサーバ５０間のネットワークが原因か、それ以外の原因があるのか判断できないので、検証処理の結果を判定することができない。

したがって、実施例１に係る検証装置１０は、検証ＡＰサーバ５０から受信したリクエストの順番が観測時と異なる場合でも、観測時と異なる順序になってから、レスポンスを応答する。つまり、検証装置１０は、到着パケットの順番が変わった場合でも、意味的に正しい動作で、観測した結果との比較による単純なテストが可能な検証処理を再現する。

［処理の説明（具体例）］
次に、検証装置１０がリクエストの到着順が観測時と異なる場合の処理の具体例を説明する。図１０は、実施例１に係る検証装置の処理を説明する図である。なお、キュー管理テーブル１５には、クエリ名等が登録されるが、ここでは説明上、クエリと記載する。しかし、クエリそのものではなくクエリ名と同一であるとする。

図１０に示すように、検証装置１０は、クエリ分析テーブル１４を参照して、キュー管理テーブル１５の待ちクエリに「ＳＱＬ：ｒｅｑ１」を格納する。この状態で、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ２」を受信する（Ｓ１）。

すると、検証装置１０は、キュー管理テーブル１５の待ちクエリ「ＳＱＬ：ｒｅｑ１」と、受信クエリ「ＳＱＬ：ｒｅｑ２」とが一致しないので、キュー管理テーブル１５の先行クエリ待ちキューに受信クエリ「ＳＱＬ：ｒｅｑ２」を格納する（Ｓ２）。つまり、検証装置１０は、受信クエリと待ちクエリとが一致しないので、到着順が変更されたと判断して、クエリに対する応答を抑制する。

その後、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ１」を受信する（Ｓ３）。すると、検証装置１０は、キュー管理テーブル１５の待ちクエリ「ＳＱＬ：ｒｅｑ１」と、受信クエリ「ＳＱＬ：ｒｅｑ１」とが一致するので、受信クエリ「ＳＱＬ：ｒｅｑ１」に対する応答「ＳＱＬ：ｒｅｓ１」を検証ＡＰサーバ５０に送信する（Ｓ４）。そして、検証装置１０は、クエリ分析テーブル１４のクエリ「ＳＱＬ：ｒｅｑ１」の「応答」にフラグを立てる。

さらに、検証装置１０は、先行クエリ待ちキューの「ＳＱＬ：ｒｅｑ２」を待ちクエリに移動させるが、「ＳＱＬ：ｒｅｑ２」はすでに受信済みなので、続けて、「ＳＱＬ：ｒｅｑ２」に対する応答「ＳＱＬ：ｒｅｓ２」を検証ＡＰサーバ５０に送信する（Ｓ５）。そして、検証装置１０は、クエリ分析テーブル１４のクエリ「ＳＱＬ：ｒｅｑ２」の「応答」にフラグを立てる。

その後、検証装置１０は、クエリ分析テーブル１４を参照して、次の待ちクエリに「ＳＱＬ：ｒｅｑ３」を格納する（Ｓ６）。この状態で、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ３」を受信する（Ｓ７）。

すると、検証装置１０は、キュー管理テーブル１５の待ちクエリ「ＳＱＬ：ｒｅｑ３」と、受信クエリ「ＳＱＬ：ｒｅｑ３」とが一致するので、受信クエリ「ＳＱＬ：ｒｅｑ３」に対する応答「ＳＱＬ：ｒｅｓ３」を検証ＡＰサーバ５０に送信する（Ｓ８）。そして、検証装置１０は、クエリ分析テーブル１４のクエリ「ＳＱＬ：ｒｅｑ３」の「応答」にフラグを立てる。

［効果］
このように、検証装置１０は、キュー管理テーブル１５とクエリ分析テーブル１４とを用いて、次の受信対象であるクエリを管理することで、受信クエリが応答可能なクエリかを判断し、観測時と同じ順序で応答することができる。したがって、検証装置１０は、到着パケットの順番が変わった場合でも、意味的に正しい動作で、観測した結果との比較による単純なテストが可能な検証処理を再現することができ、順序を考慮した検証を実行することができる。

実施例１では、検証時のリクエストの到着が観測時と異なる場合は、観測時と応答順が同じになるように、リクエストの到着を待って応答する例を説明したが、これに限定されるものではない。例えば、検証装置１０は、未受信の先行クエリが後続のクエリに影響を与えないクエリの場合は、先行クエリを待たずに受信済みの後続クエリに対して応答することもできる。

そこで、実施例２では、検証装置１０が、未受信の先行クエリが後続のクエリに影響を与えないクエリか否かを判定して、先行クエリを待たずに受信済みの後続クエリに対して応答する例を説明する。なお、検証装置１０の機能構成は、実施例１と同様なので詳細な説明は省略する。

［処理の流れ］
図１１は、実施例２に係るＤＢサーバ擬似動作処理の流れを示すフローチャートである。図１１に示すように、ＤＢサーバ擬似部２４の判定部２４ａは、検証ＡＰサーバ５０からリクエストを受信すると（Ｓ３０１：Ｙｅｓ）、受信したリクエストがキュー管理テーブル１５の待ちクエリと同一かを判定する（Ｓ３０２）。

続いて、判定部２４ａによって受信クエリが待ちクエリと同一であると判定された場合（Ｓ３０２：Ｙｅｓ）、送信部２４ｂは、処理中フラグが偽か否かを判定する（Ｓ３０３）。

そして、送信部２４ｂは、処理中フラグが偽であると判定した場合（Ｓ３０３：Ｙｅｓ）、リクエストの到着順が観測時と同じ状態に戻ったことを示す到着順序復帰通知を検証ＡＰサーバ５０に送信する（Ｓ３０４）。さらに、送信部２４ｂは、受信クエリに対応するレスポンスをパケットキャプチャテーブル１３から特定して検証ＡＰサーバ５０に応答する（Ｓ３０５）。なお、Ｓ３０４とＳ３０５は、どちらが先に実行されてもよい。

一方で、送信部２４ｂは、処理中フラグが偽ではないと判定した場合（Ｓ３０３：Ｎｏ）、受信クエリに対応するレスポンスをパケットキャプチャテーブル１３から特定して検証ＡＰサーバ５０に応答する（Ｓ３０６）。

Ｓ３０５またはＳ３０６の後、判定部２４ａは、送信部２４ｂによってリクエストが送信されると、キュー管理テーブル１５の待ちクエリを更新する（Ｓ３０７）。続いて、判定部２４ａは、キュー管理テーブル１５の先行クエリ待ちキューが空である場合（Ｓ３０８：Ｙｅｓ）、処理中フラグを真に設定する（Ｓ３０９）。つまり、判定部２４ａは、リクエストの到着順が観測時とは異なっていたが、観測時と同じ状態に戻ったと判定する。

一方、判定部２４ａは、キュー管理テーブル１５の先行クエリ待ちキューにクエリが格納されている場合（Ｓ３０８：Ｎｏ）、先行クエリ待ちキューに格納されているクエリの先頭を削除して新たな待ちクエリとして登録する（Ｓ３１０）。

また、Ｓ３０２において、判定部２４ａは、受信クエリが待ちクエリと同一ではないと判定した場合（Ｓ３０２：Ｎｏ）、受信クエリがｒｅａｄ命令であるか否かを判定する（Ｓ３１１）。すなわち、判定部２４ａは、受信クエリに記述されるＳＱＬ文がテーブルをｒｅａｄするＳＱＬ文か否かを判定する。

続いて、判定部２４ａは、受信クエリがｒｅａｄ命令であると判定した場合（Ｓ３１１：Ｙｅｓ）、受信クエリが先行クエリを待たずに送信可能な条件を満たすか否かを判定する（Ｓ３１２）。例えば、判定部２４ａは、待ちクエリから受信クエリまで間の各クエリで受信クエリが参照するテーブルと共通のテーブル参照し、ｗｒｉｔｅ命令かつ成功したクエリがあるかを、クエリ分析テーブル１４等を用いて判定する。

そして、判定部２４ａは、受信クエリが先行クエリを待たずに送信可能な条件を満たすと判定した場合（Ｓ３１２：Ｙｅｓ）、処理中フラグを偽に設定する（Ｓ３１３）。つまり、判定部２４ａは、実動環境と異なる順番でリクエストを受信していると判定する。

送信部２４ｂは、リクエストの到着順が観測時と異なることを示す到着順序変更通知を検証ＡＰサーバ５０に送信する（Ｓ３１４）。さらに、送信部２４ｂは、受信クエリに対応するレスポンスをパケットキャプチャテーブル１３から特定して、検証ＡＰサーバ５０に応答する（Ｓ３１５）。その後、判定部２４ａがＳ３０８以降を実行する。なお、Ｓ３１４とＳ３１５は、どちらが先に実行されてもよい。

一方、Ｓ３１２において、判定部２４ａは、受信クエリが先行クエリを待たずに送信可能な条件を満たないと判定した場合（Ｓ３１２：Ｎｏ）、受信クエリをキュー管理テーブル１５の先行クエリ待ちキューに格納する（Ｓ３１６）。続いて、判定部２４ａは、処理中フラグを偽に設定して（Ｓ３１７）、処理を終了する。

また、Ｓ３１１において、判定部２４ａは、受信クエリがｒｅａｄ命令ではないと判定した場合（Ｓ３１１：Ｎｏ）、Ｓ３１２を実行することなく、Ｓ３１６を実行する。

［処理の説明（具体例）］
次に、実施例２に係る検証装置１０がリクエストの到着順が観測時と異なる場合の処理の具体例を説明する。図１２は、実施例２に係る検証装置の処理を説明する図である。なお、キュー管理テーブル１５には、クエリ名が登録されるが、ここでは説明上、クエリと記載するがクエリそのものではなくクエリ名と同一であるとする。

図１２に示すように、検証装置１０は、クエリ分析テーブル１４を参照して、キュー管理テーブル１５の待ちクエリに「ＳＱＬ：ｒｅｑ１」を格納する。この状態で、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ２」を受信する（Ｓ１０）。

すると、検証装置１０は、キュー管理テーブル１５の待ちクエリ「ＳＱＬ：ｒｅｑ１」と、受信クエリ「ＳＱＬ：ｒｅｑ２」とが一致しないので、到着順序変更通知を検証ＡＰサーバ５０およびクライアント擬似部２３に送信する（Ｓ１１）。

続いて、検証装置１０は、受信クエリが先行クエリを待たずに送信可能な条件を満たすか否かを判定する。

具体的には、検証装置１０は、クエリ分析テーブル１４を参照して、受信クエリ「ＳＱＬ：ｒｅｑ２」がｒｅａｄ命令であることを特定する。さらに、検証装置１０は、クエリ分析テーブル１４を参照して、受信クエリ「ＳＱＬ：ｒｅｑ２」の参照テーブルがＴであることと、待ちクエリ「ＳＱＬ：ｒｅｑ１」の参照テーブルもＴであることを特定する。そして、検証装置１０は、クエリ分析テーブル１４を参照して、待ちクエリ「ＳＱＬ：ｒｅｑ１」がｒｅａｄ命令かつ成功しているクエリであると特定する。

この結果、検証装置１０は、受信クエリがｒｅａｄ命令であり、待ちクエリに登録される先行クエリが受信クエリと同じテーブルを参照するｒｅａｄ命令かつ成功クエリであると判定し、先行クエリを待たずに受信クエリを応答可能と判定する。

したがって、検証装置１０は、受信クエリ「ＳＱＬ：ｒｅｑ２」に対する応答「ＳＱＬ：ｒｅｓ２」を検証ＡＰサーバ５０に送信する（Ｓ１２）。そして、検証装置１０は、クエリ分析テーブル１４のクエリ「ＳＱＬ：ｒｅｑ２」の「応答」にフラグを立てる（Ｓ１３）。

その後、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ１」を受信する（Ｓ１４）。すると、検証装置１０は、キュー管理テーブル１５の待ちクエリ「ＳＱＬ：ｒｅｑ１」と、受信クエリ「ＳＱＬ：ｒｅｑ１」とが一致するので、受信クエリ「ＳＱＬ：ｒｅｑ１」に対する応答「ＳＱＬ：ｒｅｓ１」を検証ＡＰサーバ５０に送信する（Ｓ１５）。

続いて、検証装置１０は、到着順序復帰通知およびクライアント擬似部２３を検証ＡＰサーバ５０に送信し（Ｓ１６）クエリ分析テーブル１４のクエリ「ＳＱＬ：ｒｅｑ１」の「応答」にフラグを立てる（Ｓ１７）。

その後、検証装置１０は、クエリ分析テーブル１４を参照して、次のクエリが「ＳＱＬ：ｒｅｑ２」と判定するが、すでに受信済みおよび応答済みなので、さらに次の「ＳＱＬ：ｒｅｑ３」を待ちクエリに格納する（Ｓ１８）。

この状態で、検証装置１０は、検証ＡＰサーバ５０から「ＳＱＬ：ｒｅｑ３」を受信し、待ちクエリ「ＳＱＬ：ｒｅｑ３」と受信クエリ「ＳＱＬ：ｒｅｑ３」とが一致するので、応答「ＳＱＬ：ｒｅｓ３」を検証ＡＰサーバ５０に送信する。

［効果］
このように、検証装置１０は、検証時のリクエスト順が観測時と異なる場合であっても、順序に関係なく応答可能な場合は、応答を送信することができる。したがって、観測時を同一順序になるまで待つ場合と比べて、検証処理の時間が短縮できる。さらに、時間が短縮できるにも関わらず、到着順による検証処理の不具合の発生を抑制できる。

また、検証装置１０は、クライアントの擬似動作によってＨＴＴＰリクエストの発行の再現を観測通りに行うので、入力に対するレスポンスの順序が変わったときに、ＤＢクエリの順序が変わったことによるものが原因と推測することができる。つまり、検証装置１０は、リクエストの到着順が変更になった原因がネットワークの状態やサーバの状態というプログラムの変更に関連しない可能性が高いと判断できる。

また、検証装置１０は、到着順が異なるリクエストの応答を送信する前に、到着順序変更通知を送信することができる。この結果、検証者は、どのリクエストの順序がどのタイミングで変更になったかを簡単に特定でき、原因究明にかかる時間の短縮が図れる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［デットロックの回避］
例えば、実施例１に係る検証装置１０は、待ちクエリが到着するまで、それまでに受信した他のクエリに対して応答することができない。この場合、待ちクエリが、検証ＡＰサーバ５０のプログラムミス等により、送信までに相当な時間がかかるクエリになったり、送信されなくなったクエリになったりすることも考えられる。このような場合、実施例１に係る検証装置１０では、待ちクエリの到着を待ち続けることになり、検証処理が遅延するどころか検証処理そのものを終了できない。

そこで、検証装置１０は、図１３に示す手法で、このようなデットロック状態を回避することができる。図１３は、デットロックの回避手法を説明する図である。例えば、検証装置１０は、イベントの関連性からＳＱＬリクエストを待つ上限時間を算出し、その上限時間を経過するまでにＳＱＬリクエストを受信しない場合は、上限時間経過後に応答を送信する。ここで、検証装置１０は、受信できなかったＳＱＬリクエストに対する応答と受信できなかったことを示す通知とを送信してもよく、エラー通知を送信してもよい。

図１３の例において、検証環境で、検証装置１０が「ＳＱＬ:ｒｅｑ１」を受信できない状態とする。この場合、検証装置１０は、観測時の情報から「ＳＱＬ:ｒｅｑ１」の前に送信されたＨＴＴＰリクエストが「ＨＴＴＰ:ｒｅｑ１」と「ＨＴＴＰ:ｒｅｑ２」であることを特定する。この結果、検証装置１０は、「ＳＱＬ:ｒｅｑ１」と「ＨＴＴＰ:ｒｅｑ１」および「ＨＴＴＰ:ｒｅｑ２」について、イベントに関連性がある可能性が高いと判定する。

そして、検証装置１０は、パケットキャプチャテーブル１３を参照して、観測時の「ＨＴＴＰ:ｒｅｑ１の送信時間−ＨＴＴＰ:ｒｅｓ１の送信時間」と「ＨＴＴＰ:ｒｅｑ２の送信時間−ＨＴＴＰ:ｒｅｓ２の送信時間」のうち長い方の時間を算出する。続いて、検証装置１０は、算出した長い方の時間（ＴＴＴ）の定数倍を上記上限時間として算出する。

この結果、検証装置１０は、デットロック状態を回避して、検証処理を続けることができる。また、検証装置１０は、定数倍を乗算することにより、上記上限時間が短すぎになることを抑制し、本来成功するはずのものが失敗になる危険性を抑制できる。

［判定条件］
実施例２では、検証装置１０は、待ちクエリから受信クエリまで間の各クエリにおいて、受信クエリが参照するテーブルと共通のテーブルを参照し、ｗｒｉｔｅ命令かつ成功したクエリがあるかを判定する例を説明したが、判定条件はこれに限定されるものではない。

例えば、検証装置１０は、受信クエリが参照するテーブルと同じテーブルを参照する待ちクエリが存在しない場合は、待ちクエリを待たずに、受信クエリの応答を送信可能と判断することもできる。このように、検証装置１０は、未受信の先行クエリが後続のクエリに影響を与えない範囲で任意に条件を設定することができる。

なお、検証装置１０は、複数のＤＢを統合して一つのＤＢにみせるデータウェアハウスを用いたアプリケーションや、複数の問い合わせをして最初に帰ってきた結果を返すアプリケーションについては、実施例１と同様に先行クエリを待ってから応答することもできる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（ハードウェア）
図１４は、ハードウェア構成例を示す図である。図１４に示すように、検証装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、ＣＰＵ（Central Processing Unit）１０ｄを有する。また、図１４に示した各部は、バス等で相互に接続される。

通信インタフェース１０ａは、他の装置との通信を制御するインタフェースであり、例えばネットワークインタフェースカードである。ＨＤＤ１０ｂは、図２等に示した機能を動作させるプログラムやＤＢを記憶する。

ＣＰＵ１０ｄは、図２等に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０ｂ等から読み出してメモリ１０ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。

すなわち、このプロセスは、検証装置１０が有する各処理部と同様の機能を実行する。具体的には、ＣＰＵ１０ｄは、パケットキャプチャ部２１、キャプチャ分析部２２、クライアント擬似部２３、ＤＢサーバ擬似部２４、検証部２５等と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、ＣＰＵ１０ｄは、パケットキャプチャ部２１、キャプチャ分析部２２、クライアント擬似部２３、ＤＢサーバ擬似部２４、検証部２５と同様の処理を実行するプロセスを実行する。

このように検証装置１０は、プログラムを読み出して実行することで検証作成方法を実行する情報処理装置として動作する。また、検証装置１０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、検証装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１ クライアント端末
２ 実動ＡＰサーバ
３ 実動ＤＢサーバ
５ スイッチ
１０ 検証装置
１１ 通信処理部
１２ 記憶部
１３ パケットキャプチャテーブル
１４ クエリ分析テーブル
１５ キュー管理テーブル
１６ 検証結果テーブル
２０ 制御部
２１ パケットキャプチャ部
２２ キャプチャ分析部
２３ クライアント擬似部
２４ ＤＢサーバ擬似部
２４ａ 判定部
２４ｂ 送信部
２５ 検証部
５０ 検証ＡＰサーバ

Claims (8)

1. コンピュータが、
   検証対象装置からパケットを受信し、
   受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定し、
   送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する
   処理を実行することを特徴とする検証方法。
2. 前記受信する処理は、前記検証対象装置がクライアント装置から受信したリクエストに基づいて送信したデータアクセス要求を前記パケットとして受信し、
   前記判定する処理は、前記制御リストに基づいて、前記データアクセス要求に先行する先行データアクセス要求が受信されたか否かを判定し、前記先行データアクセス要求が受信されていない場合に、前記データアクセス要求に対するアクセス応答を送信不可能と判定することを特徴とする請求項１に記載の検証方法。
3. 前記判定する処理は、前記データアクセス要求に先行する前記先行データアクセス要求が未受信の場合であっても、前記制御リストに基づいて前記先行データアクセス要求がデータの読み出し要求と判定した場合、前記データアクセス要求に対する前記アクセス応答を前記検証対象装置に送信可能と判定することを特徴とする請求項２に記載の検証方法。
4. 前記送信する処理は、前記データアクセス要求に対する前記アクセス応答を前記先行データアクセス要求に対するアクセス応答よりも先に送信する場合、データアクセス要求の受信順序が変更されたことを通知する順序変更通知を、前記クライアント装置に送信することを特徴とする請求項３に記載の検証方法。
5. 前記送信する処理は、前記順序変更通知の送信後に受信されたデータアクセス要求が前記制御リストに基づいて順序通りと判定された場合、当該データアクセス要求に対するアクセス応答を送信する際に、データアクセス要求の受信順序が復帰したことを通知する順序復帰通知を前記クライアント装置に送信することを特徴とする請求項４に記載の検証方法。
6. 前記送信する処理は、前記データアクセス要求に対する前記アクセス応答が送信不可能と判定された場合、前記クライアント装置が前記リクエストを送信してからレスポンスを受信するまでにかかる応答時間を前記制御リストに基づいて算出し、前記応答時間を用いて算出された所定時間が経過した後に、前記アクセス応答を前記検証対象装置に送信することを特徴とする請求項１に記載の検証方法。
7. コンピュータに、
   検証対象装置からパケットを受信し、
   受信した前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定し、
   送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する
   処理を実行させることを特徴とする検証プログラム。
8. 検証対象装置からパケットを受信する受信部と、
   前記受信部によって受信された前記パケットに対する応答を前記検証対象装置に送信する順序に関する情報を含んだ制御リストに基づいて、前記応答を前記検証対象装置に送信可能かを判定する判定部と、
   前記判定部が送信可能と判定した場合は、前記応答を前記検証対象装置に送信し、前記判定部が送信不可能と判断した場合は、前記応答が送信可能になるまで待機してから前記検証対象装置に送信する送信部と
   を有することを特徴とする検証装置。

Images