(57)【要約】【課題】実動系の動作を適切に再現して検証する。【解決手段】検証プログラムにおいて、実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析し、前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信し、前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する、処理をコンピュータに実行させる。【選択図】図１
2014131212.tif 000002
【特許請求の範囲】
【請求項１】
実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析し、
前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、
前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信し、
前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する、処理をコンピュータに実行させる検証プログラム。
【請求項２】
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のＲＴＴを解析し、解析したＲＴＴ品質に基づいて、前記送信データを前記ＲＴＴ遅らせて送信するか、又は、前記ＲＴＴ遡った時点の情報で前記送信データの送信可否を判断することを特徴とする請求項１に記載の検証プログラム。
【請求項３】
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のデータロス品質を解析し、解析したデータロス品質に基づいて、前記送信データの送信の要否を判断することを特徴とする請求項１又は２に記載の検証プログラム。
【請求項４】
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のジッタ品質を解析し、解析したジッタ品質に基づいて、前記送信データを前記検証対象装置に送信することを特徴とする請求項１乃至３の何れか１項に記載の検証プログラム。
【請求項５】
前記品質解析対象は、拠点毎、サブネットワーク毎、クライアント毎、コネクション毎、及びシーケンス毎のうち、少なくとも１つを含むことを特徴とする請求項１乃至４の何れか１項に記載の検証プログラム。
【請求項６】
前記実動系キャプチャデータを用いて解析された品質特性に基づいて、前記品質解析対象を動的判断することを特徴とする請求項１乃至５に記載の検証プログラム。
【請求項７】
実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析する実動系品質解析手段と、
前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信するパケット送信手段と、
前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する検証系解析手段と、を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、実動系の動作を再現して検証するための検証プログラム及び情報処理装置に関する。
【背景技術】
【０００２】
従来では、サーバ等に対するパッチの適用やファームの更新、ウィルス定義の更新等の作業を行った後に、そのサーバが作業前と同様に動作するか（例えば、機能面又は性能面の退化（デグレード）がないか等）を短時間で試験して検証する技術が求められている。また、稼働中のシステム動作のキャプチャデータ（以下、単に「実動系キャプチャデータ」という）から、所定期間（例えば、障害期間等）のデータを抜き出して、再現動作の確認を可能とする技術が求められている。更に、サーバシステムの移行（例えば、物理サーバから仮想サーバへのサーバ統合やクラウドサーバへの移行等）を行う場合に、現在稼働中の実動系サーバを止めずに、移行後のサーバで現状と同様に動作するかを短時間で試験する技術が求められている。
【０００３】
そこで、要求メッセージ受信時の受信時刻データを取得して保持しておき、通信シミュレートの際に、保持していた受信時刻データから通信データの送信時間を決定し、通信データを時間情報に基づいてシミュレートする手法が存在する。また、Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（ＨＳＤＰＡ）機能を有する基地局に回線交換とパケット交換の要素を含むことで、両面の負荷試験を可能とした負荷試験システムが存在する（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−２３１０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、上述したような従来手法の場合には、例えば特許文献１に示すように、実動系キャプチャデータから要求メッセージレベル（例えば、Ｌ７）で通信データを抽出し、受信時刻情報に基づく送信を行っている。しかしながら、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）レベル（例えば、Ｌ４）以下では、検証装置と対象サーバとの間での要求シーケンスや応答シーケンスに基づく送信を行う必要がある。その理由は、上述した条件を満たさない場合には、応答データサイズや応答タイミングに差異が生じ、再現検証動作ができなくなるためである。そのため、特許文献１の手法では、再現検証動作が適切に行えない。
【０００６】
１つの側面では、実動系の動作を適切に再現して検証することを目的とする。
【課題を解決するための手段】
【０００７】
一態様における検証プログラムは、検証プログラムにおいて、実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析し、前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信し、前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する、処理をコンピュータに実行させる。
【発明の効果】
【０００８】
実動系の動作を適切に再現して検証することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態における検証システムの概略構成の一例を示す図である。
【図２】本実施形態における検証処理が実現可能なハードウェア構成の一例を示す図である。
【図３】実動系キャプチャによる品質特性解析処理の一例を示すフローチャートである。
【図４】第１の再現検証処理の一例を示すフローチャートである。
【図５】第２の再現検証処理の一例を示すフローチャートである。
【図６】本実施形態における検証システムの概略例を説明するための図である。
【図７】検証系再現シーケンスの第１実施例を説明するための図である。
【図８】第１実施例におけるＡｃｋ送信処理の一例を示すフローチャートである。
【図９】第１実施例におけるデータ送信処理の一例を示すフローチャートである。
【図１０】検証系再現シーケンスの第２実施例を説明するための図である。
【図１１】第２実施例における下り方向のパケットロス再現処理の一例を示すフローチャートである。
【図１２】第２実施例における上り方向のパケットロス再現処理の一例を示すフローチャートである。
【図１３】検証再現シーケンスの第３実施例を説明するための図である。
【図１４】第３実施例におけるＡｃｋ送信処理の一例を示すフローチャートである。
【図１５】第３実施例におけるデータ送信処理の一例を示すフローチャートである。
【図１６】実動系キャプチャデータの一例を示す図である。
【図１７】実動系品質特性情報の一例を示す図である。
【図１８】拠点管理情報の一例を示す図である。
【図１９】サブネット管理情報の例を示す図である。
【図２０】品質解析対象の動的判断を説明するための図である。
【図２１】品質解析対象の動的判断処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照しながら実施例について詳細に説明する。
【００１１】
＜検証システムの概略構成例＞
図１は、本実施形態における検証システムの概略構成の一例を示す図である。図１に示す検証システム１０は、情報処理装置の一例としての検証装置１１と、検証対象装置１２と、１又は複数のクライアント端末１３−１〜１３−ｎ（以下、必要に応じて「クライアント端末１３」と総称する）とを有する。図１に示す検証システム１０において、クライアント端末１３と、検証対象装置１２とは、通信ネットワーク１４によりデータの送受信が可能な状態で接続されている。図１に示す検証システム１０には、クライアント端末１３と検証対象装置１２との間で送受信されている通信データをキャプチャするための分岐装置１５等が接続されている。
【００１２】
検証装置１１は、予め設定された検証対象装置１２に対して実環境の通信データ（例えば、実動系パケット等）をキャプチャする。また、検証装置１１は、そのキャプチャデータの中から、クライアント端末１３が設置されている拠点毎やクライアント端末１３毎等の所定の抽出条件に基づいて、該当するキャプチャデータを抽出する。
【００１３】
検証装置１１は、抽出したデータから、例えば通信上の品質特性を解析し、解析した品質特性情報に基づいて、検証系シーケンスにおいて、実動系シーケンスと同様の品質を再現する。検証系シーケンスとは、例えば実動系キャプチャデータに基づき再現動作を検証させたときの一連の送受信メッセージである。
【００１４】
また、検証装置１１は、再現したデータを用いて所定の検証対象装置１２にパケットの送受信を行い、その結果に対する検証対象装置１２やシステム全体の動作（振る舞い）等の検証を行う。検証系で実動系を再現して検証を行う場合、検証装置１１は、所定の検証対象装置１２と分岐手段１５を介してアクセスせずに、直接アクセスしてデータの送受信による動作等の検証を行ってもよい。
【００１５】
検証対象装置１２は、例えば実際の業務等においてクライアント端末１３とデータの送受信を行う実動系サーバである。また、検証対象装置１２は、例えば検証装置１１による動作検証等を行う検証系サーバである。また、検証対象装置１２は、上述した実動系サーバと検証系サーバとを両方備えていてもよい。検証対象装置１２は、例えば上述した実動系サーバと検証系サーバとが別装置であってもよく、同一装置であってもよい。
【００１６】
検証対象装置１２は、例えば複数のサーバ群（例えば、図１に示す検証対象装置１２−１〜１２−ｎ）を有していてもよい。検証対象装置１２は、例えば各クライアントを管理する管理サーバや、各クライアント端末からの情報をデータベースとして管理するデータベースサーバ、各種の演算処理を行う演算処理サーバ等であるが、これに限定されるものではない。また、検証対象装置１２は、上述した各種サーバを選択的に統合したクラウドサーバであってもよく、サーバ以外の装置であってもよい。
【００１７】
クライアント端末１３は、実動系のシステム動作において、通信ネットワーク１４を介して検証対象装置１２（例えば、実動系サーバ）等とのデータの送受信を行う装置である。クライアント端末１３は、一台に限定されるものではなく、複数のクライアント端末１３−１〜１３−ｎが接続されていてもよい。この場合、各クライアント端末１３−１〜１３−ｎは、予め設定された１又は複数の拠点毎に設置された１又は複数の装置とすることができる。拠点とは、例えば通信品質（環境）の異なる地点（場所）を示すが、これに限定されるものではない。クライアント端末１３は、例えば１拠点毎に所定の単位（例えば、部署毎、フロア毎）で１又は複数のサブネットワーク（以下、「サブネット」という）を構成していてもよい。
【００１８】
クライアント端末１３は、例えばＰｅｒｓｏｎａｌ  Ｃｏｍｐｕｔａｒ（ＰＣ）等の汎用型の装置でもサーバでもよく、更にはタブレット装置等の通信端末等であってもよい。
【００１９】
通信ネットワーク１４は、例えばインターネットやＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ）等に代表されるネットワーク形態である。通信ネットワーク１４は、有線でも無線でもよく、両方を含んでいてもよい。
【００２０】
分岐装置１５は、クライアント端末１３と検証対象装置１２との間の通信データを分岐し、通信データをキャプチャする。分岐装置１５は、検証対象装置１２と各拠点等に設置された複数のクライアント端末１３−１〜１３−ｎからの通信データがキャプチャしやすいように、通信データが集約される検証対象装置１２側に設置されることが好ましいが、これに限定されるものではない。分岐装置１５が設置された位置が、キャプチャポイントとなる。
【００２１】
分岐装置１５としては、例えばタップ（ＴＡＰ）等やスイッチ（ＳＷ）等があるが、これに限定されるものではない。
【００２２】
ここで、本実施形態では、実動系での通信データの送受信は、例えば各拠点にあるクライアント端末１３により行うが、検証系での通信データの送受信は、検証装置１１で行うことができる。その場合、検証システム１０は、まず実動系キャプチャデータから所定の条件に基づく通信上の品質等を解析する。検証システム１０は、検証系での送信データを検証系シーケンスに基づいて生成し、送信方法や送信タイミングを解析された実動系品質に擬似させることで、実動系の同じ環境を再現することができる。
【００２３】
なお、検証系での送信データ生成では、実動系と検証系とで、システムやセッションで固有となる情報を、静的変換したり、受信応答データの情報から動的変換して生成する。変換対象のデータ例としては、例えばＭｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＩＰ）アドレス（固定変換）等がある。また、変換対象の他のデータ例としては、例えばＴＣＰシーケンス番号（動的変換）、ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）ヘッダ、Ｃｏｏｋｉｅ情報（動的変換）等があるが、これに限定されるものではない。
【００２４】
また、実動系キャプチャデータの品質解析対象は、例えばクライアント端末１３（アドレス）毎や、拠点（アドレス）毎、サブネット（アドレス）毎、各クライアント端末１３におけるコネクション毎、シーケンス毎があるが、これに限定されるものではない。これにより、本実施形態では、例えば「拠点アドレス」→「サブネットアドレス」→「クライアントアドレス」→「コネクション」→「シーケンス」の順に集約することで、段階的にきめ細かな品質再現や再現した環境に基づく検証等を実現することができる。
【００２５】
本実施形態では、実動系キャプチャデータの品質解析のタイミングや集計内容について、様々なバリエーションが考えられるが、特に限定されるものではない。例えば、本実施形態では、最初に所定時間分（例えば、１日分）の実動系キャプチャデータを全て解析し、所定の品質解析対象毎の平均品質（例えば、平均Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ（ＲＴＴ）や平均ロス率）を保持しておく。そして、検証動作時に品質解析対象毎に保持した平均品質を読み出しながら再現検証する手法を用いることができる。平均品質は、例えば最悪品質（最大ＲＴＴや最大ロス率、最大ジッタ）や最善品質（最小ＲＴＴや最小ロス率、最小ジッタ）等を用いることができるが、これに限定されるものではない。また、本実施形態では、検証動作時に実動系キャプチャデータをリアルタイムに読み出しながら同時に品質解析を行い、その時点の品質で再現検証する手法を用いることができるが、これに限定されるものではない。
【００２６】
＜検証装置１１の機能構成例＞
ここで、図１に示す検証装置１１の機能構成例について説明する。図１に示す検証装置１１は、試験実施手段２１と、試験情報取得手段２２と、記憶手段２３と、表示手段２４とを有する。試験実施手段２１は、実動系品質解析手段３１と、パケット送信手段３２と、パケット受信手段３３と、検証系解析手段３４とを有する。パケット送信手段３２は、送信データ生成手段４１と、送信方法決定手段４２と、送信タイミング決定手段４３とを有する。試験情報取得手段２２は、パケットキャプチャ手段５１を有する。記憶手段２３は、実動系パケット記憶手段６１と、実動系品質特性記憶手段６２と、検証系パケット記憶手段６３と、試験結果記憶手段６４とを有する。
【００２７】
試験実施手段２１は、検証装置１１の使用者（ユーザ）等からの指示により、実動系キャプチャデータやキャプチャデータから得られる解析結果の品質特性を再現して、検証対象装置１２やシステム全体に対する負荷試験等の予め設定された各種の検証試験を実施する。
【００２８】
実動系品質解析手段３１は、実動系パケット記憶手段６１に記憶された実動系キャプチャデータ（実動系の通信パケットデータ）の品質特性（例えば、ＲＴＴやロス率、ジッタ等）を解析する。このとき、実動系品質解析手段３１は、所定の品質解析対象（レベル）毎に解析を行うことができる。所定の品質解析対象とは、例えばクライアント端末１３が設置されている拠点毎や、拠点毎に設定されるサブネット毎、クライアント端末１３毎、各クライアント端末１３におけるコネクション毎、コネクションに対するシーケンス毎のデータ等があるが、これに限定されるものではない。上述した実動系キャプチャデータの詳細については、後述する。
【００２９】
パケット送信手段３２は、検証系での再現処理として、送信データ自身は検証系シーケンス等に基づいて生成し、送信方法や送信タイミングは、解析した実動系品質等を擬似するように動作させる。パケット送信手段３２は、実動系パケット記憶手段６１に記憶されている実動系キャプチャデータを、所定の検証対象装置１２に対して送信する。パケット送信手段３２は、例えば図１に示す検証対象装置１２−１〜１２−ｎの全てに対して実動系キャプチャデータを送信してもよく、検証対象装置１２−１〜１２−ｎのうち、少なくとも１つの所定の検証対象装置１２−１〜１２−ｎに送信してもよい。
【００３０】
パケット送信手段３２において、送信データ生成手段４１は、検証対象装置１２に送信するデータを生成する。送信データ生成手段４１は、例えば検証系シーケンス(これまでの受信パケット)情報等から、検証系の検証対象装置１２が応答できるデータ形式（フォーマット）に変換したり、各ヘッダ（宛て先情報）等を一部変換した送信データを生成する。
【００３１】
送信方法決定手段４２は、例えば実動系品質解析情報から検証用データを送信する方法を決定する。送信方法は、所定のクライアント端末１３と検証対象装置１２とにおける実動系の環境と同様の送信方法を適用することができるが、これに限定されるものではない。送信方法とは、例えば通信レベル（例えば、Ｌ４、Ｌ７等）や通信規格、パケットデータ毎に対する送信の要否の決定（送信するパケットデータの選択）等のうち、少なくとも１つであるが、これに限定されるものではない。
【００３２】
送信タイミング決定手段４３は、実動系品質解析情報から送信するタイミングを決定する。送信タイミング決定手段４３は、所定のクライアント端末１３に対する実動系キャプチャデータから解析された品質解析情報に基づいて、実動系の環境と同様の送信タイミングを設定することができるが、これに限定されるものではない。
【００３３】
上述したように、パケット送信手段３２は、検証系での再現処理として、送信データ自身は検証系シーケンスに基づいて生成し、送信方法や送信タイミングは、解析した実動系品質を擬似するように動作させる。
【００３４】
パケット受信手段３３は、検証対象装置（例えば、検証系サーバ等）１２から、パケット送信手段３２により送信された検証用の送信パケットに対する応答パケットを受信する。受信したパケットは、例えば検証系パケット記憶手段６３に記憶される。
【００３５】
検証系解析手段３４は、検証系の送受信データに対して所定の条件に基づく解析を行う。検証系解析手段３４は、例えば検証系における所定のデータの送受信が実動系における同一データの送受信よりも遅れた場合に、検証対象装置１２やシステム全体等に何らかの負荷がかかっているため、レスポンスが遅れた等といった各種の解析を行うことができる。
【００３６】
試験情報取得手段２２は、各クライアント端末１３と検証対象装置（例えば、実動系サーバ等）１２との間の通信データを取得する。試験情報取得手段２２のパケットキャプチャ手段５１は、各クライアント端末１３と実動系サーバ間の通信パケットをキャプチャする。なお、試験情報取得手段２２は、所定時間に区切って全てのキャプチャデータを取得してもよく、通信パケットに含まれるアドレス情報に基づいて、所定の拠点毎、サブネット毎、コネクション毎、検証対象装置１２毎にキャプチャデータを取得してもよい。取得したパケットは、例えば実動系パケット記憶手段６１に記憶される。
【００３７】
記憶手段２３において、実動系パケット記憶手段６１は、実動系サーバとして動作する検証対象装置１２からのキャプチャ結果を記憶する。実動系パケット記憶手段６１は、例えば実動系キャプチャデータとしてクライアント端末１３と検証対象装置１２との間の全通信シーケンスを保持させてもよい。また、実動系パケット記憶手段６１は、例えば所定の拠点毎、サブネット毎、コネクション毎に対する実動系キャプチャデータであってもよく、所定の時間毎（例えば、一時間毎）のデータであってもよい。
【００３８】
実動系品質特性記憶手段６２は、実動系品質解析手段３１により得られる実動系キャプチャ品質解析情報を記憶する。検証系パケット記憶手段６３は、パケット受信手段３３により得られる検証を行う対象のパケットデータを記憶する。試験結果記憶手段６４は、例えば本実施形態における品質特性の検証試験結果を記憶する。
【００３９】
表示手段２４は、検証対象装置１２への検証処理に対する各設定情報を設定するための画面や検証結果等を表示する。表示手段２４は、例えばディスプレイ画面に、カーソル、アイコン或いはツールボックス、文書、画像、機能情報等のデータを表示し、これは、例えばマウス等の入力装置により操作する。表示手段２４は、例えばＣａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ（ＣＲＴ）ディスプレイやＴｈｉｎ  Ｆｉｌｍ  Ｔｒａｎｓｉｓｔｏｒ（ＴＦＴ）液晶ディスプレイ、プラズマディスプレイ等を採用することができる。
【００４０】
ここで、本実施形態における検証対象装置１２において、上述した試験情報取得手段５１は、図１に示すように、検証装置１１と同一装置内にあってもよく、別装置であってもよい。その場合、試験情報取得手段５１におけるパケットデータは、通信ネットワーク１４等を介して検証装置１１に送信される。
【００４１】
＜検証装置１１のハードウェア構成例＞
各機能をコンピュータに実行させることができる実行プログラム（検証プログラム）を、例えば汎用のＰＣやサーバ等にインストールすることにより、本実施形態における検証処理を実現することができる。ここで、本実施形態における検証処理が実現可能なコンピュータのハードウェア構成例について図を用いて説明する。
【００４２】
図２は、本実施形態における検証処理が実現可能なハードウェア構成の一例を示す図である。図２におけるコンピュータ本体には、入力装置７１と、出力装置７２と、ドライブ装置７３と、補助記憶装置７４と、主記憶装置７５と、各種制御を行うＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）７６と、ネットワーク接続装置７７とを有するよう構成されており、これらはシステムバスＢで相互に接続されている。
【００４３】
入力装置７１は、ユーザ等が操作するキーボード及びマウス等のポインティングデバイスや、マイクロフォン等の音声入力デバイスを有しており、ユーザ等からのプログラムの実行指示、各種操作情報等の入力を受け付ける。
【００４４】
出力装置７２は、本実施形態における処理を行うためのコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、ＣＰＵ７６が有する制御プログラムによりプログラムの実行経過や結果等を表示することができる。また、出力装置７２は、上述の処理結果等を紙等の印刷媒体に印刷して、ユーザ等に提示することができる。
【００４５】
ここで、本実施形態においてコンピュータ本体にインストールされる実行プログラムは、例えば、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）メモリやＣＤ−ＲＯＭ、ＤＶＤ等の可搬型の記録媒体７８等により提供される。プログラムを記録した記録媒体７８は、ドライブ装置７３にセット可能であり、ＣＰＵ７６からの制御信号に基づき、記録媒体７８に含まれる実行プログラムが、記録媒体７８からドライブ装置７３を介して補助記憶装置７４にインストールされる。
【００４６】
補助記憶装置７４は、ハードディスク等のストレージ手段であり、ＣＰＵ７６からの制御信号に基づき、本実施形態における実行プログラムや、コンピュータに設けられた制御プログラム等を蓄積し、必要に応じて各種データの入出力を行うことができる。なお、補助記憶装置７４は、例えば上述した記憶手段２３に対応しており、上述した試験結果や検証系パケット、実動系品質特性、実動系パケット等が記憶される。補助記憶装置７４は、ＣＰＵ７６からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込んだりすることができる。
【００４７】
主記憶装置７５は、ＣＰＵ７６により補助記憶装置７４から読み出された実行プログラム等を格納する。主記憶装置７５は、例えばＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）やＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）等であるがこれに限定されるものではない。
【００４８】
ＣＰＵ７６は、オペレーティングシステム等の制御プログラム、及び主記憶装置７５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して各処理を実現することができる。プログラムの実行中に必要な各種情報等は、補助記憶装置７４から取得することができ、また実行結果等を格納することもできる。
【００４９】
つまり、主記憶装置７５は、ＣＰＵ７６のワークエリアとして使用され、主記憶装置７５内で検証プログラムが動作する。具体的には、ＣＰＵ７６は、例えば入力装置７１から得られるプログラムの実行指示等に基づき、補助記憶装置７４にインストールされた検証プログラムを実行させることにより、主記憶装置７５上でプログラムに対応する処理を行う。また、ＣＰＵ７６により実行された内容は、必要に応じて補助記憶装置７４等に記憶させることができる。
【００５０】
ネットワーク接続装置７７は、ＣＰＵ７６からの制御信号に基づき、通信ネットワーク１４等と接続することにより、実行プログラムやソフトウェア、実動系キャプチャデータや検証系パケットデータ等の情報等を取得する。ネットワーク接続装置７７は、プログラムを実行することで得られた実行結果又は本実施形態における実行プログラム自体を外部装置等に提供することができる。ネットワーク接続装置７７は、例えばＬＡＮアダプタやモデム等であるがこれに限定されるものではない。
【００５１】
上述したようなハードウェア構成により、本実施形態における検証処理を実行することができる。また、プログラムをインストールすることにより、汎用のＰＣ等で本実施形態における検証処理を容易に実現することができる。
【００５２】
＜検証処理＞
ここで、本実施形態における検証処理について、フローチャートを用いて説明する。なお、本実施形態では、検証処理として、大きく分けて実動系キャプチャの品質特性解析処理と、検証系における再現検証処理とを含むため、それぞれの処理内容を分けて説明する。
【００５３】
＜実動系キャプチャの品質特性解析処理＞
図３は、実動系キャプチャによる品質特性解析処理の一例を示すフローチャートである。図３に示す実動系キャプチャによる品質特性解析処理は、検証系において実動系の品質特性を再現するために、実動系キャプチャデータからパケット読み込む（Ｓ０１）。
【００５４】
次に、品質特性解析処理は、例えばクライアント端末１３のＩＰアドレス等を基準としてクライアント毎に通信上等の品質特性を解析し（Ｓ０２）、解析した品質特性情報を記憶手段２３（実動系品質特性記憶手段６２）に保持する（Ｓ０３）。
【００５５】
次に、品質特性解析処理は、品質特性解析を行う次のパケットがあるか否かを判断し（Ｓ０４）、次のパケットがある場合（Ｓ０４において、ＹＥＳ）、実動系キャプチャデータから次のパケットを読み込み（Ｓ０５）、Ｓ０１の処理に戻る。
【００５６】
また、品質特性解析処理は、Ｓ０４の処理において、品質特性解析を行う次のパケットがない場合（Ｓ０４において、ＮＯ）、処理対象の最後のパケットまで処理されたことになるため、実動系キャプチャの品質特性解析処理を終了する。
【００５７】
＜検証系における再現検証処理＞
次に、検証系における再現検証処理の例について説明するが、再現検証処理は、具体的には、実動系キャプチャを読み込み、検証対象装置１２へ要求パケットの送信を行う第１の再現検証処理と、検証対象装置１２からの応答パケットを受信し、対応する制御信号を送信する第２の再現検証処理とに分けることができる。そのため、以下の説明では、第１の再現検証処理と第２の再現検証処理とを分けて説明する。
【００５８】
＜第１の再現検証処理例＞
図４は、第１の再現検証処理の一例を示すフローチャートである。図４に示す第１の再現検証処理は、実動系キャプチャデータから解析された品質特性情報に基づき、実務系のシステム動作を再現して、所定の時間間隔を保持して要求パケットを読み込む（Ｓ１１）。つまり、Ｓ１１の再現検証処理では、実動系のパケット送信間隔と同様の時間間隔を保持してパケットを読み込む。例えば、パケットに含まれる時間情報（例えば、分岐手段１５による実動系のパケット取得時刻）から得られる時間間隔に合わせてパケットを読み込んでもよいが、これに限定されるものではない。
【００５９】
次に、第１の再現検証処理は、読み込んだパケットが、目的の検証対象装置１２宛てのパケットであるか否かを判断する（Ｓ１２）。第１の再現検証処理は、目的の検証対象装置１２宛てのパケットである場合（Ｓ１２において、ＹＥＳ）、検証系シーケンスから送信パケットを変換する（Ｓ１３）。変換とは、例えば検証対象装置１２が応答できるフォーマットに変換したり、検証装置１１と目的の検証対象装置１２との間でパケットの送受信が行えるように、宛て先等の各ヘッダ等を一部変換することを意味するが、これに限定されるものではない。
【００６０】
次に、第１の再現検証処理は、要求パケットを送信するクライアント端末１３を検証系（例えば、検証装置１１）において再現するために、上記のクライアント端末１３に対応する品質特性情報を抽出する（Ｓ１４）。第１の再現検証処理は、抽出した品質特性情報に基づいて、要求パケット毎の送信の要否（送信方法等も含む）やタイミング等を決定し（Ｓ１５）、決定した内容に基づいて変換した要求パケットを送信する（Ｓ１６）。
【００６１】
ここで、第１の再現検証処理は、Ｓ１６の処理後、次のパケットを送信するか否かを判断する（Ｓ１７）。第１の再現検証処理は、Ｓ１２の処理において、読み込んだ要求パケットが目的の検証対象装置１２宛てのパケットでない場合（Ｓ１２において、ＮＯ）、その要求パケットは、何もせずに次のパケットを送信するか否かを判断する（Ｓ１７）。
【００６２】
第１の再現検証処理は、次のパケットを送信する場合（Ｓ１７において、ＹＥＳ）、次のパケットをＳ１１の処理と同様に、実動系のパケット送信間隔と同様の時間間隔を保持してパケットを読み込み（Ｓ１８）、Ｓ１１の処理に戻る。第１の再現検証処理は、全てのパケットを読み込んだり、ユーザからの終了指示等により、次のパケットを読み込まない場合（Ｓ１７において、ＮＯ）、第１の再現検証処理を終了する。
【００６３】
＜第２の再現検証処理例＞
図５は、第２の再現検証処理の一例を示すフローチャートである。図５に示す第２の再現検証処理は、上述した第１の再現検証処理で予め設定された検証対象装置１２に送信した要求パケットに対して、検証対象装置１２からの応答パケットを受信したか否かを判断する（Ｓ２１）。
【００６４】
第２の再現検証処理は、Ｓ２１の処理において、応答パケットを受信していない場合（Ｓ２１において、ＮＯ）、受信するまで待機する。第２の再現検証処理は、Ｓ２１の処理において、応答パケットを受信した場合（Ｓ２１において、ＹＥＳ）、検証系シーケンス（これまで送受信した１又は複数のパケット）から送信パケット（例えば、制御信号等）を変換する（Ｓ２２）。なお、Ｓ２２の処理では、上述したＳ１３における処理と同様に、検証対象装置１２が応答できる形に変換する等の処理を行うが、これに限定されるものではない。
【００６５】
次に、第２の再現検証処理は、パケットに対応するクライアント端末１３の品質特性情報を抽出し（Ｓ２３）、送信の要否（送信方法等も含む）やタイミング等を決定する（Ｓ２４）。第２の再現検証処理は、上述したＳ２２の処理により変換されたパケット（制御信号等も含む）を送信する（Ｓ２５）。なお、上述した第１の再現検証処理と第２の再現検証処理は、例えば検証対象装置１２からの応答パケットを受信する受信用スレッドを起動することで、並行して処理させることができる。
【００６６】
上述したように、本実施形態は、大別すると実動系キャプチャの品質特性解析処理と、検証系再現検証処理とから構成される。実動系キャプチャの品質特性解析処理は、実動系キャプチャデータから順次パケットを読み込み、例えばクライアント（アドレス）毎に品質特性を解析し、解析した品質特性情報を保持しておく。また、検証系再現検証処理は、実動系キャプチャデータから時間間隔を保持して要求パケットを読み込み、検証サーバから応答パケットを受信すると、検証系シーケンス情報から送信パケットを生成する。また、検証系再現検証処理は、本パケットに対応するクライアント品質特性情報を抽出して、送信要否やタイミングを決定し、その決定内容に従ってパケット送信を行う。
【００６７】
＜概略例＞
ここで、上述した本実施形態における検証システム１０の概略例について説明する。図６は、本実施形態における検証システムの概略例を説明するための図である。図６の例では、概略的な実動系環境８１と検証系環境８２とを有している。また、図６の例では、検証対象装置１２の一例として、実動系サーバ１２−１と検証系サーバ１２−２とを有しているが、これに限定されるものではなく、実動系サーバ１２−１と検証系サーバ１２−２とが一体であってもよい。
【００６８】
図６に示す実動系環境８１では、福岡、大阪、横浜、東京の各地域に拠点を有し、東京をデータセンタとした全体のシステムが存在する。また、図６の例では、各拠点に１又は複数のクライアント端末１３を有している。このような実動系環境８１においては、拠点毎に伝送時のデータのロス率やＲＴＴ、ジッタ等による通信上の品質特性の値が異なる。図６の例では、品質特性の一例であるロス率、ＲＴＴの大きさをそれぞれ「大」、「中」、「小」で表している。例えば、福岡の拠点（例えば、クライアント端末１３−１）の場合には、ロス率が「中」でＲＴＴが「大」である。また、大阪の拠点（例えば、クライアント端末１３−２）の場合には、ロス率が「大」でＲＴＴが「小」である。また、横浜の拠点（例えば、クライアント端末１３−３）の場合には、ロス率が「小」でＲＴＴが「小」である。また、東京の拠点（例えば、クライアント端末１３−４）の場合には、実動系サーバ（検証対象装置１２）を有する本部（データセンタ）であるため、ロス率やＲＴＴはない。このように、実動系環境８１では、クライアント端末１３の設置される場所（環境）に応じて通信上の品質特性等が異なることになる。
【００６９】
そこで、本実施形態における検証系環境８２では、まず実動系環境８１において取得される実動系キャプチャデータ（例えば、パケットキャプチャ）から所定の条件（例えば、拠点毎、サブネット毎、コネクション毎、シーケンス毎）に基づく品質特性を解析する。  また、検証系環境８２では、解析した品質特性情報等を用いて、検証系シーケンスから各拠点等に対するデータ伝送時の実動系の品質と同様の品質を与えた送信データを生成する。更に、検証系環境８２では、図６に示すように、送信方法や送信タイミングについても実動系環境８１の品質と同様になるように設定した送信データを用いて検証を行う。これにより、本実施形態では、検証装置１１を配置する１箇所から、多拠点クライアント（例えば、大阪Ｃ、福岡Ｃ等）からの通信キャプチャデータの品質特性を適切に再現する。そして、本実施形態では、再現したデータを用いて検証サーバ１２−２やシステム全体等の動作（振る舞い）の適切な検証が可能となる。
【００７０】
＜第１実施例＞
次に、上述した検証システム１０における検証系再現シーケンスの具体例について説明する。図７は、検証系再現シーケンスの第１実施例を説明するための図である。検証系再現シーケンスとは、上述した検証系シーケンスと同様に、例えば実動系キャプチャデータに基づき再現動作を検証させたときの一連の送受信メッセージである。
【００７１】
第１実施例では、再現する品質特性として、実動系環境のＲＴＴを検証系にて再現して検証する例を示す。また、図７の例では、説明の便宜上、１クライアント（クライアント端末１３−１）と検証対象装置１２（実動系サーバ１２−１、検証系サーバ１２−２）との間の通信シーケンスを用いて説明するが、複数クライアントの場合には同様の処理が複数繰り返されることになる。
【００７２】
図７の左側には、実動系キャプチャデータのシーケンスからＲＴＴ品質を解析する例を示している。第１実施例では、クライアント端末１３毎にＲＴＴ品質を最初に解析し、その解析結果を保持しておく。第１実施例では、例えばクライアント端末１３−１から実動系サーバ１２−１に要求データ（Ｒｅｑ）を送信し、その応答データ（Ｒｓｐ）が実動系サーバ１２−１からクライアント端末１３−１に送信される。また、クライアント端末１３−１や実動系サーバ１２−１は、正常に受信した要求データや応答データに対する肯定応答（Ａｃｋ）を送信する。
【００７３】
そこで、第１実施例では、例えば上述した分岐手段１５が設置されたキャプチャポイントによって得られる応答データの受信時刻から、肯定応答（Ａｃｋ）の受信時刻までの間隔をＲＴＴとする。具体的には、図７の例では、「Ｒｓｐ−１＿２パケットの受信時刻からＡｃｋ−１＿２パケットの受信時刻までの時間」や「Ｒｓｐ−１＿４パケットの受信時刻からＡｃｋ１−４パケットの受信時刻までの時間」等をＲＴＴとする。また、第１実施例では、複数取得されたＲＴＴに対して、その平均を取得する（この平均を、以下「ＲＴＴ＿ａ」という）。なお、第１実施例におけるＲＴＴの例としては、上述した内容に限定されるものではなく、例えばＴＣＰ＿３Ｗａｙハンドシェイク時のＳｙｎ−ＡｃｋとＡｃｋとの時間間隔をＲＴＴとすることもできる。
【００７４】
また、図７の右側には、上述した処理により取得した実動系のＲＴＴを用いて検証系のＲＴＴを再現する例（検証系再現シーケンスの例）を示している。実動系のＲＴＴを品質として再現する場合には、検証装置１１において、通信パケットがあたかも実際の通信区間を通ってクライアント端末１３−１に到達したかのように処理する必要がある。更に、検証装置１１は、検証系サーバ１２−２に送信する通信パケットが、あたかもクライアント端末１３−１から実際の通信区間を通って到達したかのように処理する必要がある。そのため、検証装置１１は、例えば通信区間に対応するＲＴＴ分を遅らせて送信するか、又はＲＴＴ遡った情報（Ａｃｋ）を用いてパケット送信可否を判断する処理を行う。
【００７５】
ここで、検証装置１１からのパケット送信は、図７の（１）に示す応答パケット受信時のＡｃｋ送信処理と、図７の（２）に示す実動系キャプチャの時間間隔に従うデータ送信処理に大別できる。以下に、それぞれの場合について説明する。
【００７６】
図８は、第１実施例におけるＡｃｋ送信処理の一例を示すフローチャートである。図８の例は、図７の（１）の処理に対応している。Ａｃｋ送信処理は、検証系シーケンスにおいて、目的とする実動系のクライアント端末１３−１宛てに対応する応答パケット（例えば、Ｒｓｐ−１＿２'）を受信する（Ｓ３１）。次に、Ａｃｋ送信処理は、応答パケットの受信を契機として、検証系シーケンスに基づき、対応するＡｃｋ（肯定応答）パケット（例えば、Ａｃｋ−１＿２'）を生成する（Ｓ３２）。なお、生成されるＡｃｋパケットは、例えば検証系のＴＣＰシーケンス番号等に従って生成される。
【００７７】
次に、Ａｃｋ送信処理は、Ｓ３２の処理により生成されたＡｃｋパケットをすぐに検証系サーバ１２−２に送信せずに、検証系シーケンスにおいて、応答パケット（例えば、Ｒｓｐ−１＿２'）を受信したタイミングから、クライアント端末１３−１の実動系ＲＴＴ品質（例えば、ＲＴＴ＿ａ）だけ遅らせたタイミングで検証系サーバ１２−２へ送信する（Ｓ３３）。つまり、検証系シーケンスにおいて、各応答パケット受信時刻に対して、実動系ＲＴＴ品質の時間を加算して生成されたＡｃｋパケット送信時刻を決定し、決定した送信時刻に従ってＡｃｋパケットを送信する。これにより、第１実施例では、Ａｃｋパケット（Ａｃｋ−１＿２'）の送信タイミングを、実動系のＲＴＴに対応させたタイミングで送信することができる。
【００７８】
また、図９は、第１実施例におけるデータ送信処理の一例を示すフローチャートである。図９の例は、図７の（２）の処理に対応している。データ送信処理は、検証系シーケンスにおいて、実動系キャプチャデータの時間間隔に対応するクライアント端末１３−１が送信した要求パケット発信時刻に到達すると（Ｓ４１）、送信データシーケンス番号が所定の条件を満たすか否かを判断する（Ｓ４２）。
【００７９】
ここで、上述した所定の条件としては、例えば現時刻からクライアント端末１３−１の実動系ＲＴＴ品質であるＲＴＴ＿ａだけ遡った時点のＡｃｋシーケンス番号や、ＴＣＰ＿Ｗｉｎｄｏｗサイズ等を用いることができるが、これに限定されるものではない。Ｓ４２の処理では、例えば上述した現時刻からＲＴＴ＿ａだけ遡った時点（現時刻−（ＲＴＴ＿ａ））までに受信したＡｃｋシーケンス番号と、ＴＣＰ＿Ｗｉｎｄｏｗサイズとを加算する。そして、加算した値が、現時点の送信データシーケンス番号より大きい場合に、送信データシーケンス番号が所定の条件を満たすと判断する。ＴＣＰ＿Ｗｉｎｄｏｗサイズは、所定値（例えば、３パケット分（Ａｃｋを待たずに３パケットまでしか送信できない））とすることができるが、これに限定されるものではない。
【００８０】
データ送信処理は、Ｓ４２の処理において、送信データシーケンス番号が所定の条件を満たさない場合（Ｓ４２において、ＮＯ）、所定の時間分だけ待機し（Ｓ４３）、Ｓ４２の処理に戻る。第１実施例では、所定の時間待機することにより、その時間にＡｃｋパケットを受信し、その分のＡｃｋシーケンス番号が増加するため、時間の経過により所定の条件を満たすことになる。
【００８１】
また、データ送信処理は、送信データシーケンス番号が所定の条件を満たす場合（Ｓ４２において、ＹＥＳ）、検証系シーケンスに基づいて、対応する要求パケットを生成し（Ｓ４４）、生成した要求パケットを送信する（Ｓ４５）。
【００８２】
つまり、第１実施例における所定のデータの送信タイミングは、検証系シーケンスにおいて、本タイミングよりもＲＴＴ遡ったＡｃｋで送信可否を判断し、所定の送信条件を満たしていれば所定のデータを送信している。言い換えれば、検証系シーケンスにおいて、各要求パケット送信可否判断時刻に対して、実動系ＲＴＴ品質の時間を減算した時点におけるＡｃｋで送信可否を判断し、所定の送信条件を満たすまで送信を遅らせる処理を行う。図７の（２）の例では、実動系キャプチャの時間間隔に従って、検証系シーケンスとして複数の要求パケットＲｅｑ−２＿１'〜Ｒｅｑ−２＿３'の送信後に、要求パケットＲｅｑ−２＿４'を送信している。要求パケットＲｅｑ−２＿４'の送信可否については、送信可否判断タイミングからクライアント端末１３−１の実動系ＲＴＴ品質であるＲＴＴ＿ａだけ遡った時点のＡｃｋシーケンス番号で判断する。
【００８３】
ここで、図７の例では、Ｗｉｎｄｏｗサイズが３パケット分であり、検証系シーケンスにおいて、検証系サーバ１２−２のＡｃｋパケット（Ａｃｋ−２＿２'）が実動系のＡｃｋパケット（Ａｃｋ−２＿２'）よりも少し遅れている。したがって、実動系と同じ時間間隔のタイミングでは、ＲＴＴ＿ａ遡った時点でＡｃｋパケット（Ａｃｋ−２＿２'）が到達しておらずに送信ができない。
【００８４】
そこで、本実施形態では、結果的にはＡｃｋパケット（Ａｃｋ−２＿２'）の受信時刻からＲＴＴ＿ａだけ遅らせたタイミングで、検証系シーケンスの情報から検証系のＴＣＰシーケンス番号に従って要求パケットＲｅｑ−２＿４'を生成し、送信することになる。これにより、検証系において、実動同様の品質特性を再現することができ、更に検証系において適切なタイミングでデータを送信することができる。
【００８５】
＜第２実施例＞
次に、第２実施例について説明する。図１０は、検証系再現シーケンスの第２実施例を説明するための図である。第２実施例では、再現する品質特性として、通信上のデータロス（例えば、パケットロス）を再現して検証する例を示す。また、図１０の例では、説明の便宜上、１クライアント（クライアント端末１３−１）と検証対象装置１２（実動系サーバ１２−１、検証系サーバ１２−２）との間の通信シーケンスを用いて説明するが、複数クライアントの場合には同様の処理が複数繰り返されることになる。
【００８６】
図１０の左側には、実動系キャプチャデータのシーケンスからロス品質（ロス率）を解析する例を示している。第２実施例では、クライアント端末１３毎にロス品質（ロス率）を最初に解析し、解析した結果を保持しておく。
【００８７】
なお、ロス解析は、例えばキャプチャポイントで得られる実動系キャプチャデータから、ＴＣＰシーケンス番号抜けや重複Ａｃｋ、再送パケット等を検出することでロスが発生した位置等を取得することができるが、解析手法はこれに限定されるものではない。また、ロス率は、例えばクライアント端末１３毎に方向別（上り／下り別）にロス数を解析して保持しておき、保持したロス数を最終的に全パケット数で除算することでロス率を算出することができるが、算出手法はこれに限定されるものではない。また、方向別（上り／下り別）の算出でなく、例えば両方向共通（上り／下り共通）の算出でもよい。この場合、上り方向と下り方向のロス率は、同じ値を利用することになる。
【００８８】
これにより、第２実施例では、クライアント端末１３−１における上り方向（Ｃ（クライアント端末１３−１）→Ｓ（実動系サーバ１２−１））のロス率Ｌ＿ｕｐ、下り方向（Ｓ→Ｃ）のロス率Ｌ＿ｄｏｗｎを保持することができる。
【００８９】
次に、第２実施例では、取得した実動系のロス率の品質特性を用いて、検証系における品質特性を再現し、検証系サーバ１２−２やシステム全体における動作の検証等を行う。  図１０の右側には、検証系の再現シーケンスを示している。実動系ロス率を品質として再現する場合は、あたかもクライアント端末１３−１とキャプチャポイント間でパケットロスが発生したかのように送信するか、又は、送信しないか（ロス扱いするか）を方向別に決定し、パケットロスを擬似的に再現する。
【００９０】
ここで、検証装置１１におけるパケットロスの再現処理は、図１０の（１）に示す下り方向（Ｓ→Ｃ）のロス疑似再現処理と、図１０の（２）に示す上り方向（Ｃ→Ｓ）のロス疑似再現処理に大別できる。以下に、それぞれの場合について説明する。
【００９１】
図１１は、第２実施例における下り方向のパケットロス再現処理の一例を示すフローチャートである。図１１に示す下り方向のパケットロス再現処理は、検証系シーケンスにおいて、目的とする実動系のクライアント端末１３−１宛てに対応する応答パケットを受信する（Ｓ５１）。また、下り方向のパケットロス再現処理は、Ｓ→Ｃロス率（Ｌ＿ｄｏｗｎ）の確率で、受信パケットがロス扱いとなったか否かを判断する（Ｓ５２）。下り方向のパケットロス再現処理は、受信パケットがロス扱いとなっていない場合（Ｓ５２において、ＮＯ）、受信データに基づき、受信ＴＣＰシーケンス番号を更新する（Ｓ５３）。また、下り方向のパケットロス再現処理は、Ａｃｋ送信のタイミングであれば、対応するＡｃｋパケットを生成して送信する（Ｓ５４）。
【００９２】
また、下り方向のパケットロス再現処理は、Ｓ５２の処理において、受信パケットがロス扱いとなった場合（Ｓ５２において、ＹＥＳ）、受信パケットはロスしたものとみなし、何も処理を行わない（Ｓ５５）。
【００９３】
つまり、図１１の処理において、検証装置１１は、検証系サーバ１２−２からの応答パケットの受信に対し、下りの実動系ロス率の確率に基づいてＡｃｋ送信するか、しないかを決定する。また、検証装置１１は、その決定に対応したＡｃｋパケットを生成して検証系サーバ１２−２に送信する。
【００９４】
ここで、図１０の（１）において、検証装置１１は、応答パケットＲｓｐ−１＿１'，Ｒｓｐ−１＿２'，Ｒｓｐ−１＿３'，Ｒｓｐ−１＿４'を受信している。このとき、検証装置１１は、それぞれの応答パケットを受信したタイミングで、Ｓ→Ｃロス率（Ｌ＿ｄｏｗｎ）の確率をもって応答パケットＲｓｐ−１＿１'，Ｒｓｐ−１＿２'を正常に受信したものと判断し、応答パケットＲｓｐ−１＿３'をロス扱いと判断している。そこで、第２実施例では、検証装置１１において、Ｒｓｐ−１−４'を正常に受信したものと判断した時点で、応答パケットＲｓｐ−１＿３'がロスした場合に送信するＡｃｋ（肯定応答）パケットＡｃｋ−１＿２'を生成する。Ａｃｋ−１＿２'は、例えばＲｓｐ−１＿２'まで受信完了したことを示す制御メッセージである。検証装置１１は、生成されたＡｃｋパケット（Ａｃｋ１＿２'）を検証系サーバ１２−２に送信する。
【００９５】
図１２は、第２実施例における上り方向のパケットロス再現処理の一例を示すフローチャートである。図１２に示す上り方向のパケットロス再現処理は、検証系シーケンスにおいて、実動系キャプチャデータの時間間隔や再送タイミングに従うクライアント端末１３−１が送信した要求パケット送信時刻に到達する（Ｓ６１）。そのとき、上り方向のパケットロス再現処理は、Ｃ→Ｓロス率（Ｌ＿ｕｐ）の確率で送信パケットがロス扱いとなったか否かを判断する（Ｓ６２）。上り方向のパケットロス再現処理は、送信パケットがロス扱いとなっていない場合（Ｓ６２において、ＮＯ）、要求パケットを送信ＴＣＰシーケンス番号に基づき生成して送信する（Ｓ６３）。上り方向のパケットロス再現処理は、送信ＴＣＰシーケンス番号を更新する（Ｓ６４）。
【００９６】
また、上り方向のパケットロス再現処理は、Ｓ６２の処理において、送信パケットがロス扱いとなった場合（Ｓ６２において、ＹＥＳ）、送信パケットはロスしたものとみなし、送信しない（Ｓ６５）。
【００９７】
つまり、図１２の処理において、検証装置１１は、検証系サーバ１２−２に対して、上りの実動系ロス率の確率に基づいて要求パケットを送信するか、しないかを決定する。検証装置１１は、その決定に対応した要求パケットを生成して検証系サーバ１２−２に送信する。
【００９８】
ここで、図１０の（２）において、実動系キャプチャのシーケンスには、要求パケットＲｅｑ−２＿１'，Ｒｅｑ−２＿２'，Ｒｅｑ−２＿３'を含んでいる。検証装置１１は、検証系シーケンスにおいて、それぞれの要求パケットを送信するタイミングで、Ｃ→Ｓロス率（Ｌ＿ｕｐ）の確率をもって要求パケットＲｅｑ−２＿１'を送信扱いとしてデータの生成及び送信を行い、要求パケットＲｅｑ−２＿２'をロス扱いと判断してデータの生成や送信は行わないようにしている。更に、検証装置１１は、続く要求パケットＲｅｑ−２＿３'を送信扱いとしてデータの生成や送信を行う。その後、検証装置１１は、要求パケットＲｅｑ−２＿２'を受信していないとして検証系サーバ１２−２から送信された応答肯定パケットＡｃｋ−２＿１'を受信した後、上述した検証系再現シーケンスにおける同様の確率処理をもって再送用の要求パケットＲｅｑ−２＿２'，Ｒｅｑ−２＿３'を送信扱いとしてデータを生成する。また、検証装置１１は、生成した再送用の要求パケットＲｅｑ−２＿２'，Ｒｅｑ−２＿３'を検証系サーバ１２−２に送信する。
【００９９】
なお、上述した第１実施例及び第２実施例において、ＲＴＴ及びロスを再現品質とした場合を、それぞれ個別に説明したが、ＲＴＴ及びロスの両方を再現品質とした場合は、上述した第１実施例及び第２実施例を組み合わせた再現シーケンスとなる。
【０１００】
＜実施例３＞
次に、第３実施例について説明する。図１３は、検証再現シーケンスの第３実施例を説明するための図である。第３実施例では、再現品質としてジッタ（ゆらぎ）を再現して検証する例を示す。また、図１３の例では、説明の便宜上、１クライアント（クライアント端末１３−１）と検証対象装置１２（実動系サーバ１２−１、検証系サーバ１２−２）との間の通信シーケンスを用いて説明するが、複数クライアントの場合は同様の処理を複数繰り返されることになる。
【０１０１】
第３実施例では、ジッタをＲＴＴのゆらぎとして捉え、実施例１の（平均等の）ＲＴＴにゆらぎを考慮した例について説明する。したがって、第３実施例では、最初に実動系キャプチャデータからＲＴＴ品質を解析する例を示す。
【０１０２】
図１３の左側は、上述した図７の左側と同様の実動系キャプチャデータのシーケンスを示している。第３実施例では、クライアント端末１３毎にＲＴＴ品質を最初に解析し、解析結果を保持しておく。
【０１０３】
第３実施例では、上述したように、例えばＲｓｐ−１＿２パケットの受信時刻からＡｃｋ−１−２パケットの受信時刻までの時間や、Ｒｓｐ−１＿４パケットの受信時刻からＡｃｋ−１−４パケットの受信時刻までの時間をＲＴＴとすることができる。また、第３実施例では、複数取得されたＲＴＴに対して、その平均（ＲＴＴ＿ａ）と標準偏差（この標準偏差を、以下「σ＿ａ」という）とを取得する。なお、第３実施例におけるＲＴＴの例としては、上述した内容に限定されるものではなく、例えばＴＣＰ＿３Ｗａｙハンドシェイク時のＳｙｎ−ＡｃｋとＡｃｋとの時間間隔をＲＴＴとすることもできる。
【０１０４】
図１３の右側は、上述した処理により取得した実動系のＲＴＴと、そのゆらぎ（ジッタ）とを用いて検証系のＲＴＴとゆらぎを再現する例を示している。
【０１０５】
基本的な処理動作は、上述した第１実施例に示すＲＴＴを用いた場合と同様であるが、基準となる値を、平均ＲＴＴ＿ａ及び標準偏差σ＿ａからの統計確率から算出される値（以下、「ＲＴＴ＿ａ＿σ」という）としている点が異なる。第３実施例では、平均μ、標準偏差σの正規分布「ｆ（ｘ）＝１／（√（２π）σ）ｅｘｐ｛−（ｘ−μ）２／（２σ２）｝」において、μ＝ＲＴＴ＿ａ、σ＝σ＿ａとした場合に従う正規乱数値を、ＲＴＴ＿ａ＿σとして算出する。また、第３実施例では、算出されたＲＴＴ＿ａ＿σを利用して検証系における品質特性を再現する。
【０１０６】
第３実施例において、検証装置１１からのパケット送信は、図１３の（１）に示すＡｃｋ送信処理、図１３の（２）に示すデータ送信処理に大別できる点も第１実施例と同様であり、それぞれの場合で、ＲＴＴ＿ａの代わりに、上述したＲＴＴ＿ａ＿σを利用することとなる。以下に、それぞれの場合について説明する。
【０１０７】
図１４は、第３実施例におけるＡｃｋ送信処理の一例を示すフローチャートである。なお、図１４の例は、図１３の（１）の処理に対応している。Ａｃｋ送信処理は、検証系シーケンスにおいて、目的とする実動系のクライアント端末１３−１宛てに対応する応答パケット（例えば、Ｒｓｐ−１＿２'）を受信する（Ｓ７１）。次に、Ａｃｋ送信処理は、応答パケットの受信を契機として、検証系シーケンスに基づき、対応するＡｃｋパケット（例えば、Ａｃｋ−１＿２'）を生成する（Ｓ７２）。なお、生成されるＡｃｋパケットは、例えば検証系のＴＣＰシーケンス番号等に従って生成される。
【０１０８】
次に、Ａｃｋ送信処理は、クライアント端末１３−１の実動系ＲＴＴ品質（平均＝ＲＴＴ＿ａ，標準偏差＝σ＿ａ）に従う正規乱数値（ＲＴＴ＿ａ＿σ）を算出する（Ｓ７３）。その後、Ａｃｋ送信処理は、クライアント端末１３−１の実動系ＲＴＴ品質（例えば、ＲＴＴ＿ａ＿σ）だけ遅らせて検証系サーバ１２−２へ送信する（Ｓ３３）。これにより、第３実施例では、Ａｃｋパケット（Ａｃｋ−１＿２'）の送信タイミングを、実動系のＲＴＴに対応させたタイミングで送信することができる。
【０１０９】
また、図１５は、第３実施例におけるデータ送信処理の一例を示すフローチャートである。なお、図１５の例は、図７の（２）の処理に対応している。データ送信処理は、検証系シーケンスにおいて、実動系キャプチャデータの時間間隔に対応するクライアント端末１３−１が送信した要求パケット発信時刻に到達すると（Ｓ８１）、クライアント端末１３−１の実動系ＲＴＴ品質（平均＝ＲＴＴ＿ａ，標準偏差＝σ＿ａ）に従う正規乱数値（ＲＴＴ＿ａ＿σ）を算出する（Ｓ８２）。その後、データ送信処理は、送信データシーケンス番号が所定の条件を満たすか否かを判断する（Ｓ８３）。
【０１１０】
ここで、上述した所定の条件としては、例えば上述した第１実施例と同様に現時刻からクライアント端末１３−１の実動系ＲＴＴ品質であるＲＴＴ＿ａ＿σだけ遡った時点のＡｃｋシーケンス番号や、ＴＣＰ＿Ｗｉｎｄｏｗサイズ等を用いることができるが、これに限定されるものではない。Ｓ８３の処理では、例えば上述した現時刻からＲＴＴ＿ａ＿σだけ遡った時点（現時刻−（ＲＴＴ＿ａ＿σ））までに受信したＡｃｋシーケンス番号と、ＴＣＰ＿Ｗｉｎｄｏｗサイズとを加算する。そして、加算した値が、現時点の送信データシーケンス番号より大きい場合に、送信データシーケンス番号が所定の条件を満たすと判断する。ＴＣＰ＿Ｗｉｎｄｏｗサイズは、所定値（例えば、３パケット分）とすることができるが、これに限定されるものではない。
【０１１１】
データ送信処理は、Ｓ８３の処理において、送信データシーケンス番号が所定の条件を満たさない場合（Ｓ８３において、ＮＯ）、所定の時間分だけ待機し（Ｓ８４）、Ｓ８３の処理に戻る。第３実施例では、所定の時間待機することにより、その時間にＡｃｋパケットを受信し、その分のＡｃｋシーケンス番号が増加するため、時間の経過により所定の条件を満たすことになる。
【０１１２】
また、データ送信処理は、送信データシーケンス番号が所定の条件を満たす場合（Ｓ８３において、ＹＥＳ）、検証系シーケンスに基づいて、対応する要求パケットを生成し（Ｓ８５）、生成した要求パケットを送信する（Ｓ８６）。
【０１１３】
つまり、第３実施例における所定のデータの送信タイミングは、実動系ＲＴＴ品質（平均＝ＲＴＴ＿ａ，標準偏差＝σ＿ａ）に従う正規乱数値（ＲＴＴ＿ａ＿σ）に基づいて遡ったＡｃｋで送信可否を判断し、所定の送信条件を満たしていれば所定のデータを送信している。図１３の（２）の例では、実動系キャプチャの時間間隔に従って、検証系シーケンスとして複数の要求パケットＲｅｑ−２＿１'〜Ｒｅｑ−２＿３'の送信後に、要求パケットＲｅｑ−２＿４'を送信している。要求パケットＲｅｑ−２＿４'の送信可否については、送信可否判断タイミングからクライアント端末１３−１の実動系ＲＴＴ品質であるＲＴＴ＿ａ＿σだけ遡った時点のＡｃｋシーケンス番号で判断する。
【０１１４】
ここで、図１３の例では、第１実施例と同様に、Ｗｉｎｄｏｗサイズが３パケット分であり、検証系シーケンスにおいて、検証系サーバ１２−２のＡｃｋパケット（Ａｃｋ−２＿２'）が実動系のＡｃｋパケット（Ａｃｋ−２＿２'）よりも少し遅れている。したがって、実動系と同じ時間間隔のタイミングでは、ＲＴＴ＿ａ＿σ遡った時点でＡｃｋパケット（Ａｃｋ−２＿２'）が到達しておらずに送信ができない。
【０１１５】
そこで、本実施形態では、結果的にはＡｃｋパケット（Ａｃｋ−２＿２'）の受信時刻からＲＴＴ＿ａ＿σだけ遅らせたタイミングで、検証系シーケンスの情報から検証系のＴＣＰシーケンス番号に従って要求パケットＲｅｑ−２＿４'を生成し、送信することになる。これにより、検証系において、実動同様の品質特性を再現することができ、更に検証系において適切なタイミングでデータを送信することができる。
【０１１６】
なお、本実施形態では、品質解析対象毎に上述した第１〜第３の実施例に示すように、ＲＴＴとパケットロスとジッタ（ゆらぎ）の品質特性のうち、２つ以上組み合わせて品質特性を再現し、再現した内容で適切にサーバやシステム全体の動作を検証することができる。
【０１１７】
＜各種データ例＞
ここで、本実施形態における各種データ例について説明する。図１６は、実動系キャプチャデータの一例を示す図である。図１６に示す実動系キャプチャデータの項目は、例えば「シーケンス（パケット）番号（Ｎｏ．）」、「パケット取得時刻」、「パケット情報」等であるが、これに限定されるものではない。また、パケット情報の一例としては、「発信元アドレス」、「発信先アドレス」、「発信元ポート番号」、「発信先ポート番号」、「ペイロード情報」等であるが、これに限定されるものではない。本実施形態における実動系キャプチャデータは、上述した「パケット取得時刻」、「パケット情報」の各データが送信された順番に実動系パケット記憶手段６１に記憶される。
【０１１８】
例えば、シーケンス（パケット）番号が１番目のキャプチャデータには、パケット取得時刻「１３：００：００．００００００」、発信元アドレス「１０．２．１．１００」、発信先アドレス「１０．１．１．１」、発信元ポート番号「１０００１」、発信先ポート番号「８０」、ペイロード情報「Ｓｙｎ」が記憶されている。ペイロード情報とは、信号に含まれるデータ情報である。
【０１１９】
つまり、図１６の例では、分岐手段１５（キャプチャポイント）で取得したパケット情報をパケット取得時刻と共にキャプチャデータとして記憶する。基本的には、パケット内に含まれる情報を全て記憶することになるが、例えばＷｉｒｅｓｈａｒｋ（ｔｓｈａｒｋ）やｔｃｐｄｕｍｐ等のフリーのツール等を用いて必要な情報のみを抽出して記憶してもよい。
【０１２０】
図１７は、実動系品質特性情報の一例を示す図である。図１７に示す実動系品質特性情報は、例えば上述した実動系品質特性記憶手段６２に記憶される。実動系品質特性情報の項目は、例えば各クライアント端末１３−１〜１３−ｎを識別し、所定のクライアント端末と通信するための「クライアントアドレス」等である。また、実動系品質特性情報の項目は、例えばクライアント端末毎に設定された「実動系ＲＴＴ品質（ｍｓｅｃ）」、「実動系ロス品質（ロス率上り／下り）（％）」、及び「実動系ジッタ品質（標準偏差）（ｍｓｅｃ）」等であるが、これに限定されるものではない。
【０１２１】
図１７の例では、例えばクライアントアドレス「Ｃ１」、実動系ＲＴＴ品質「１０（ｍｓｅｃ）」、実動系ロス品質（ロス率上り／下り）「１．０／１．５（％）」、実動系ジッタ品質（標準偏差）「２．０（ｍｓｅｃ）」が記憶される。クライアントアドレスは、例えばＩＰアドレス等のクライアント端末１３が一意に特定できる情報であればよい。上述した各品質特性情報は、実動系品質解析手段３１により解析される。
【０１２２】
図１７に示す例では、クライアントアドレス毎に品質特性情報を記憶しているが、品質解析対象はこれに限定されるものではなく、例えば拠点毎やサブネット（アドレス）毎、コネクション毎、シーケンス毎等であってもよい。また、品質解析対象は、拠点毎、サブネット（アドレス）毎、クライアント端末１３のコネクション毎、及びシーケンス毎のうち、複数を組み合わせた品質特性情報であってもよい。また、上述した検証装置１１における品質解析タイミングとしては、例えば１日分や１週間、１月分の実動系キャプチャデータを先に全て読み込んで解析を行い、品質特性情報を実動系品質特性記憶手段６２に記憶した後に検証処理を行ってもよい。また、検証装置１１は、その他の品質解析タイミングとして、例えば実動系キャプチャを取得して品質を解析しながら、平行してその品質解析結果を用いて品質を再現したデータ送信を行い、リアルタイムに検証処理を行ってもよい。これにより、実動系の環境により近い環境を検証系で再現でき、より適切な検証を実現することができる。
【０１２３】
図１８は、拠点管理情報の一例を示す図である。図１８に示す拠点管理情報の項目は、例えば「拠点名」、「拠点アドレス」等であるが、これに限定されるものではない。拠点管理情報は、例えば検証装置１１の実動系品質解析手段３１において、クライアント端末１３が設置される拠点毎に品質特性を解析する場合に利用される。図１８の例では、拠点名に対して、その拠点に属するアドレスを、「アドレス」及び「集約マスク長」で管理しているがその拠点に属するアドレスの管理方法はこれに限定されるものではなく、例えばその拠点に属する複数のサブネットをリストで管理してもよい。拠点管理情報は、実動系品質解析手段３１が管理していてもよく、記憶手段２３に記憶させてもよい。
【０１２４】
図１９は、サブネット管理情報の例を示す図である。図１９に示すサブネット管理情報の項目は、例えば「サブネット名」、「サブネットアドレス」、「サブネットマスク長」等であるが、これに限定されるものではない。
【０１２５】
本実施形態では、例えば実動系品質解析手段３１において、ある拠点（例えば、東京）のサブネット（例えば、部署）毎に品質特性を解析する場合には、例えば図１９に示すようなサブネット名とアドレスとを対応付けた拠点管理情報等を利用する。図１９の例では、拠点毎の部署を基準としたサブネット名に対して、その部署の属するアドレスをサブネットアドレスとサブネットマスク長とで管理しているが、管理方法としてはこれに限定されるものではない。上述した拠点管理情報は、例えばデフォルトのサブネットマスク長を規定しておき、デフォルト以外のサブネットのみを管理してもよい。また、上述した図１８に示す拠点管理情報がサブネット単位で管理されている場合には、図１８に示す拠点管理情報と図１９に示すサブネット管理情報とを１つに集約して管理することができる。サブネット管理情報は、実動系品質解析手段３１が管理していてもよく、記憶手段２３に記憶させてもよい。
【０１２６】
＜品質特性を所定の条件で集約して解析する場合の具体例＞
ここで、本実施形態における実動系の品質解析は、上述したようにクライアント端末毎だけでなく、例えば拠点毎やサブネット（アドレス）毎、各クライアント端末におけるコネクション毎、シーケンス毎に解析することができる。以下に、品質特性を所定の条件で集約して解析する場合の具体例について説明する。
【０１２７】
なお、クライアント端末が設置された各拠点の拠点アドレスや、サブネットアドレスの関係については、上述した拠点管理情報と同様に、例えば東京、大阪、福岡等の拠点毎に分割してアドレス付けがされているものとしている。
【０１２８】
＜品質特性の集約対象＞
本実施形態において、例えば拠点毎に品質特性を解析する場合には、図１６に示す実動系キャプチャデータから「パケットＮｏ．１〜６，１１〜１９」を大阪拠点とし、「パケットＮｏ．７〜１０」を福岡拠点として、それぞれ集約させることができる。サブネット毎に計測する場合には、図１８に示す実動系キャプチャデータから、例えば「パケットＮｏ．１〜６，１１〜１３，１７〜１９」、「パケットＮｏ．７〜１０」、「パケットＮｏ．１４〜１６」の３つのサブネットに分割して集約させることができる。更に、クライアント端末１３毎に品質特性を解析する場合には、例えば「パケットＮｏ．１〜６，１７〜１９」、「パケットＮｏ．７〜１０」、「パケットＮｏ．１１〜１３」、「パケットＮｏ．１４〜１６」の４つのクライアントに分割して集約させることができる。上述した各条件による集約は、例えば図１６に示す実動系キャプチャデータに含まれる「発信元アドレス」や「発信先アドレス」を用いて集約することができる。
【０１２９】
また、各クライアント端末のコネクション毎に品質特性を解析する場合には、例えば「パケットＮｏ．１〜６」、「パケットＮｏ．７〜１０」、「パケットＮｏ．１１〜１３」、「パケットＮｏ．１４〜１６」、「パケットＮｏ．１７〜１９」の５つのコネクションに分割して集約させることができる。上述したコネクション毎の集約は、例えば図１６に示す実動系キャプチャデータに含まれる「発信元アドレス」や「発信先アドレス」だけでなく、「発信元ポート番号」や「発信先ポート番号」を用いて集約することができる。
【０１３０】
更に、シーケンス毎に品質特性を解析する場合には、図１６に示す実動系キャプチャデータから例えば「パケットＮｏ．１〜１９」の各シーケンスで品質特性が解析される。つまり、シーケンス毎に品質特性を解析する場合には、集約処理されない。なお、集約処理は、予め設定された集約条件に基づいて実動系品質解析手段３１において行われる。
【０１３１】
＜品質解析の具体例＞
ここで、本実施形態におけるＲＴＴ品質やジッタ品質等の解析は、例えばＴＣＰの３Ｗａｙハンドシェイク時のＳｙｎ−ＡｃｋとＡｃｋとの時間間隔（例えば、図１６のパケットＮｏ．２を取得（受信）してからパケットＮｏ．３を取得するまでの時間）を用いることができる。
【０１３２】
また、本実施形態では、応答データに対するＡｃｋの間隔等を用いることができる。例えば、図１６におけるパケットＮｏ．５とＮｏ．６間（２０ｍｓｅｃ）、Ｎｏ．９とＮｏ．１０間（５０ｍｓｅｃ）、Ｎｏ．１２とＮｏ．１３間（２２ｍｓｅｃ）、Ｎｏ．１５とＮｏ．１６間（２４ｍｓｅｃ）、Ｎｏ．１８とＮｏ．１９間（２２ｍｓｅｃ）等を用いることができる。また、上述した複数の結果を集約する場合には、集約処理対象毎に平均（最大／最小）や標準偏差を算出してもよい。
【０１３３】
例えば、ロス品質の解析は、パケット送信回数とパケットロス回数から、「ロス率（％）＝｛パケットロス回数／（パケット送信回数＋パケットロス回数）｝＊１００．０」として算出することができる。パケットロスは、例えば、同一シーケンス番号のパケット再送（例えば、図１６のパケットＮｏ．８に対するパケットＮｏ．９）等を解析することで判断することができる。パケットロスについては、上述したように、再送を解析する方法の他、ＴＣＰシーケンス番号の抜けや重複するＡｃｋシーケンス番号等の解析を利用する方法等でもよく、特に限定されるものではない。
【０１３４】
なお、上述した品質特性の集約は、予めユーザにより集約条件を設定してもよく、実動系キャプチャデータから動的に集約条件設定してもよい。ここで、品質解析対象の動的判断の例を第４実施例として以下に説明する。
【０１３５】
＜第４実施例＞
第４実施例は、品質特性を集約する対象を、実動系キャプチャデータの解析結果から動的に判断する例を示す。図２０は、品質解析対象の動的判断を説明するための図である。図２０の例では、「動的判断の結果として採用する品質集約対象」と、「ＲＴＴ品質（ｍｓｅｃ）」とが対応して記憶されている。また、「ＲＴＴ品質」の項目は、例えば「拠点ＩＤと集約品質」、「サブネットＩＤと集約品質」、「クライアントＩＤと集約品質」、「コネクションＩＤと集約品質」等であるがこれに限定されるものではない。
【０１３６】
図２０の例では、例えば実動系キャプチャデータからＲＴＴ品質を各集約対象レベル（例えば、拠点レベル、サブネットレベル、クライアントレベル、コネクションレベル）で解析した結果を示している。
【０１３７】
第４実施例において、各レベルでの解析は、実動系品質解析手段３１により行われる。第４実施例では、どの集約レベルの品質を再現対象とすべきかを動的に判断して決定する。なお、第４実施例では、ＲＴＴ品質を例に説明しているがこれに限定されるものではなく、例えばパケットロスやジッタ（ゆらぎ）でも同様に処理される。
【０１３８】
第４実施例では、例えばある上位レベルの集約品質と、その下位レベルの集約品質に大きな違い（例えば、予め設定された閾値以上の差）がなければ、上位レベルの集約品質を採用する。なお、第４実施例では、上位から順に「拠点レベル」→「サブネットレベル」→「クライアントレベル」→「コネクションレベル」としてレベルの階層を設定しているが、これに限定されるものではない。
【０１３９】
例えば、図２０の例には、拠点ＩＤがＰ１のＲＴＴ品質と、Ｐ１に対応するサブネットＩＤがＳ１，Ｓ２，Ｓ３のＲＴＴ品質が解析されている。ここで、Ｓ１の品質「１９ｍｓｅｃ」及びＳ２の品質「２０ｍｓｅｃ」については、「拠点ＩＤと集約品質」で示されたＰ１の品質「２０ｍｓｅｃ」に近いため、拠点Ｐ１の品質「２０ｍｓｅｃ」を採用する。しかしながら、Ｓ３の品質「３０ｍｓｅｃ」については、拠点Ｐ１の品質「２０ｍｓｅｃ」とは大きく異なる。そのため、第４実施例では、更に下位レベルの集約が利用できるかを調べる。
【０１４０】
サブネットＳ３内には、クライアントＩＤがＴ７，Ｔ８，Ｔ９，Ｔ１０のＲＴＴ品質が解析されている。Ｔ７，Ｔ８の品質については、サブネットＳ３の品質「３０ｍｓｅｃ」に近いため、サブネットＳ３の品質「３０ｍｓｅｃ」を採用する。しかしながら、Ｔ９の品質「４０ｍｓｅｃ」及びＴ１０の品質「２０ｍｓｅｃ」については、サブネットＳ３の品質「３０ｍｓｅｃ」とは大きく異なる。そのため、第４実施例では、更に下位レベルの集約が利用できるかを調べる。Ｔ９，Ｔ１０は、それぞれに対応する下位レベルであるコネクションＩＤがＣ１１，Ｃ１２と近いため、それぞれクライアントＴ９，Ｔ１０の品質を採用する。このように、品質解析することで、実動系の品質解析の集約位置を動的に判断して適切な品質を取得することができる。
【０１４１】
ここで、図２１は、品質解析対象の動的判断処理の一例を示すフローチャートである。各レベル間の品質比較は、例えば上位レベルの平均と標準偏差とから導かれる統計的範囲（例えば、９０％範囲（平均±１．６５σ））に、下位レベルの平均が収まっているかどうか等の所定の閾値を基準に判断することができる。
【０１４２】
なお、図２１の動的判断処理の前提として、品質解析対象のレベルを広域（上位）から「拠点」→「サブネット」→「クライアント」→「コネクション」→「シーケンス」とするが、これに限定されるものではない。また、上述した図２０に示すような各レベル毎の品質は、キャプチャ解析により予め抽出しておく。
【０１４３】
図２１に示す動的判断処理は、一例として最上位である拠点毎を初期レベルとし（Ｓ９１）、その拠点に今回の解析対象があるか否かを判断する（Ｓ９２）。動的判断処理は、解析対象がある場合（Ｓ９２において、ＹＥＳ）、１つ下のレベル（下位レベル）がないか否かを判断する（Ｓ９３）。動的判断処理は、１つ下のレベルがない場合（Ｓ９３において、ＹＥＳ）、現在のレベルの品質を集約品質として採用し（Ｓ９４）、Ｓ９２の処理に戻り、次の解析対象に対して上述の処理を行う。
【０１４４】
また、動的判断処理は、Ｓ９３の処理において、１つ下のレベルがある場合（Ｓ９３において、ＮＯ）、現在のレベルの品質と、１つ下のレベルの品質とを比較し、大きな差がないか否かを判断する（Ｓ９５）。ここで、大きな差とは、例えば比較する品質間の差が所定の範囲内であるか否かを判断することをいうが、これに限定されるものではない。動的判断処理は、大きな差がある場合（Ｓ９５において、ＮＯ）、現在の比較対象の品質レベルを１つ下のレベルに下げ（Ｓ９６）、Ｓ９３の処理に戻る。また、動的判断処理は、Ｓ９５の処理において、大きな差がない場合（Ｓ９５において、ＹＥＳ）、現在のレベルを品質解析対象とし（Ｓ９７）、Ｓ９２の処理に戻り、次の解析対象に対して上述の処理を行う。
【０１４５】
また、動的判断処理は、Ｓ９２の処理において、解析対象がない場合（Ｓ９２において、ＮＯ）、処理を終了する。上述した第４実施例により、対象となる品質集約データを下位レベルに下げることを最小限に留めることができる。つまり、第４実施例では、データ量が多くなることによるメモリ等のリソース量の圧迫や処理速度の低下を抑えながら、より適切な再現品質で検証することができる。
【０１４６】
上述した実施形態によれば、実動系の品質特性を適切に再現し、再現した品質等に基づいて検証系におけるサーバやシステム全体の動作（振る舞い）を適切に検証することができる。
【０１４７】
例えば、従来では、各クライアントとキャプチャポイントとの間のネットワーク品質等が再現できていないため、各クライアントが設置された箇所で本来計測されるべき値が計測できず、その計測値を用いても実動系と検証系の適切な比較ができなかった。また、実動系サーバや検証系サーバにかかる負荷パターンやタイミング等も異なってくるため、同一条件でのサーバ検証にならなかった。しかしながら、本実施形態によれば、例えばサーバ等の検証対象装置に対する多拠点クライアントとの通信キャプチャデータを、検証装置を配置する１箇所で品質特性まで適切に再現して、再現動作を検証することができる。つまり、本実施形態によれば、多拠点クライアントでの品質性能（レスポンス時間等）を１箇所から計測することができるため、コストや時間を大幅に短縮することができる。また、本実施形態によれば、キャプチャ結果と検証結果を、そのまま比較することができ、結果比較にかかるコストや時間を大幅に短縮することができる。
【０１４８】
また、本実施形態によれば、例えばサーバやシステム検証試験分野において、例えば実際のアクセスや負荷パターン等を適切に再現した検証を実現することができる。
【０１４９】
以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、上記変形例以外にも種々の変形及び変更が可能である。
【０１５０】
なお、以上の実施例に関し、更に以下の付記を開示する。
（付記１）
実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析し、
前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、
前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信し、
前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する、処理をコンピュータに実行させる検証プログラム。
（付記２）
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のＲＴＴを解析し、解析したＲＴＴ品質に基づいて、前記送信データを前記ＲＴＴ遅らせて送信するか、又は、前記ＲＴＴ遡った時点の情報で前記送信データの送信可否を判断することを特徴とする付記１に記載の検証プログラム。
（付記３）
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のデータロス品質を解析し、解析したデータロス品質に基づいて、前記送信データの送信の要否を判断することを特徴とする付記１又は２に記載の検証プログラム。
（付記４）
前記品質特性として、前記実動系キャプチャデータから品質解析対象毎のジッタ品質を解析し、解析したジッタ品質に基づいて、前記送信データを前記検証対象装置に送信することを特徴とする付記１乃至３の何れか１項に記載の検証プログラム。
（付記５）
前記実動系キャプチャデータからの品質特性を解析しながら、前記品質特性に基づく前記送信データの検証対象装置への送信を行うことを特徴とする付記１乃至４の何れか１項に記載の検証プログラム。
（付記６）
前記品質解析対象は、拠点毎、サブネットワーク毎、クライアント毎、コネクション毎、及びシーケンス毎のうち、少なくとも１つを含むことを特徴とする付記１乃至５の何れか１項に記載の検証プログラム。
（付記７）
前記実動系キャプチャデータを用いて解析された品質特性に基づいて、前記品質解析対象を動的判断することを特徴とする付記１乃至６に記載の検証プログラム。
（付記８）
実動系キャプチャデータから所定の品質解析対象毎の通信上の品質特性を解析する実動系品質解析手段と、
前記実動系キャプチャデータと、前記実動系キャプチャデータに基づき再現動作を検証させたときの送受信メッセージとに基づいて送信データを生成し、前記品質特性に基づく送信タイミングで、前記送信データを検証対象装置に送信するパケット送信手段と、
前記検証対象装置からの応答データを受信して、前記検証対象装置の動作を検証する検証系解析手段と、を有することを特徴とする情報処理装置。
【符号の説明】
【０１５１】
１０  検証システム
１１  検証装置
１２  検証対象装置
１３  クライアント端末
１４  通信ネットワーク
１５  分岐手段
２１  試験実施手段
２２  試験情報取得手段
２３  記憶手段
２４  表示手段
３１  実動系品質解析手段
３２  パケット送信手段
３３  パケット受信手段
３４  検証系解析手段
４１  送信データ生成手段
４２  送信方法決定手段
４３  送信タイミング決定手段
５１  パケットキャプチャ手段
６１  実動系パケット記憶手段
６２  実動系品質特性記憶手段
６３  検証系パケット記憶手段
６４  試験結果記憶手段
７１  入力装置
７２  出力装置
７３  ドライブ装置
７４  補助記憶装置
７５  主記憶装置
７６  ＣＰＵ
７７  ネットワーク接続装置
７８  記録媒体
８１  実動系環境
８２  検証系環境
【図１】
2014131212.tif 000003
【図２】
2014131212.tif 000004
【図３】
2014131212.tif 000005
【図４】
2014131212.tif 000006
【図５】
2014131212.tif 000007
【図６】
2014131212.tif 000008
【図７】
2014131212.tif 000009
【図８】
2014131212.tif 000010
【図９】
2014131212.tif 000011
【図１０】
2014131212.tif 000012
【図１１】
2014131212.tif 000013
【図１２】
2014131212.tif 000014
【図１３】
2014131212.tif 000015
【図１４】
2014131212.tif 000016
【図１５】
2014131212.tif 000017
【図１６】
2014131212.tif 000018
【図１７】
2014131212.tif 000019
【図１８】
2014131212.tif 000020
【図１９】
2014131212.tif 000021
【図２０】
2014131212.tif 000022
【図２１】
2014131212.tif 000023