ウェブシステムに対する負荷テストの管理方法及び管理装置
【課題】テスト協力者が予め各テストの実行期間を認識した上で、テスト参加を決定することができるウェブシステムに対する負荷テストの管理方法を、提供する。
【解決手段】テスト管理サーバ３は、各ユーザ端末１に対して、テスト実行期間を提示した負荷テストの告知情報を送信する。ユーザ端末１は、ツールバープログラム１８に従って、当該告知情報をディスプレイ１６上に表示する。表示されている負荷テストをユーザが選択して参加申し込みをすると、テスト管理サーバ３は、参加申込をユーザのＩＤをテスト登録者管理データベース３８に登録する。テスト管理サーバ３は、各負荷テストのテスト実行期間に至ると、テスト負荷登録データベース３７に登録されているＵＲＬを記述したテストスケジュールファイルを、登録されているユーザが操作するユーザ端末１へ送信する。ユーザ端末１は、テストスケジュールが指定したＵＲＬへメッセージを送信する。
【解決手段】テスト管理サーバ３は、各ユーザ端末１に対して、テスト実行期間を提示した負荷テストの告知情報を送信する。ユーザ端末１は、ツールバープログラム１８に従って、当該告知情報をディスプレイ１６上に表示する。表示されている負荷テストをユーザが選択して参加申し込みをすると、テスト管理サーバ３は、参加申込をユーザのＩＤをテスト登録者管理データベース３８に登録する。テスト管理サーバ３は、各負荷テストのテスト実行期間に至ると、テスト負荷登録データベース３７に登録されているＵＲＬを記述したテストスケジュールファイルを、登録されているユーザが操作するユーザ端末１へ送信する。ユーザ端末１は、テストスケジュールが指定したＵＲＬへメッセージを送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じて受信したユーザ端末からのリクエストメッセージに応じて処理を実行するウェブシステムに対して行う負荷テストを、管理するための管理方法及び管理装置に、関する。
【背景技術】
【０００２】
インターネット等のネットワークは、何らかのサービスを提供する多数のサーバとサービスを要求する多数のユーザ端末とを蜘蛛の巣状に接続するネットワークシステムである。そして、サービス提供を行うサーバは、各ユーザ端末からのリクエストメッセージを受信することにより、当該リクエストメッセージに従った処理を実行して、その処理結果をリクエスト元端末へ応答する。かかるサーバによる処理は、ユーザ端末からのリクエストメッセージ毎に実行されるが、同時に実行可能な処理の個数はサーバの処理能力に依存する。その為、多数のユーザ端末からのリクエストメッセージが一度に集中した場合には、サーバに対する処理負荷がサーバの処理能力を超えてしまい、サーバの処理速度が極端に低下したり、サーバがシステムダウンを起こしてしまう等の障害が生じ得る。また、多数のリクエストメッセージが一つの通信経路に集中して、その通信容量を超えてしまうと、通信経路が輻輳を起こしてしまう等の障害が生じ得る。そこで、ネットワーク上で新規のサービスを開始する際には、サービス開始に先立って、当該サービスを提供するサーバに対して、ネットワークを通じて多数（サービスの仕様において想定された最大アクセス数を十分上回る数）のダミーのリクエストメッセージを実際に送信することにより、障害の発生の有無をテストする必要がある。
【０００３】
従来、かかるテスト（以下、「負荷テスト」という）は、負荷テストサービスを提供するサーバ（以下、「負荷テストサーバ」という）によって内部的ないし論理的に生成された多数の仮想クライアントが多数のリクエストメッセージを同時にテスト対象のサーバ（以下、「テスト対象サーバ」という）へ送信するものとして実行されていたが、負荷テストへの協力者を公募し、多数の協力者が夫々所有する端末から実際にリクエストメッセージをテスト対象サーバに対して自動送信させる提案も存在していた（特許文献１）。
【０００４】
上記特許文献記載の方式によると、テスト対象サーバのアドレス及びテスト実行期間の指定情報は、協力者が任意に覗くことができない様に暗号化されたファイル（接続先情報ファイル）に書き込まれた状態で、協力者の端末に提供される。そして、当該接続先情報ファイルには、多数の負荷テストにつき、夫々のアドレス及びテスト実行期間の指定情報が、書き込まれている。そして、端末にインストールされた自動接続プログラムが、接続先情報ファイルを読み込んで、当該ファイルに列挙されたアドレスに対して、各アドレスに対応付けられた実行期間中に、リクエストメッセージを自動的に送信するのである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１３２５３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、協力者としては、如何なる数のテストが如何なるタイミングで実行されるのかの予定を知ることができないので、自己の端末使用の都合に鑑みて、負荷テストへの参加を躊躇してしまうこともあり得る。
【０００７】
そこで、本発明の課題は、協力者が予め各テストの実行期間を認識した上で、テスト参加を決定することができるウェブシステムに対する負荷テストの管理方法及び管理装置を提供することとする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明では、サーバ（テスト管理装置）が、各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を端末へ送信する。すると、負荷テストの告知情報を受信した端末は、告知情報に含まれる各負荷テストのテスト実行期間を操作者に提示し、操作者が、入力装置を用いて各負荷テストのうち何れかを特定すると、特定した負荷テストの識別情報を含む参加申込情報をサーバ（テスト管理装置）へ送信する。すると、参加申込情報を受信したサーバ（テスト管理装置）は、第１データベースを参照し、参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、参加申込情報を送信した端末へ送信する。すると、スケジュール情報を受信した端末は、スケジュール情報により指定されたテスト実行期間に、同スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する。
【０００９】
以上のように構成されることから、端末の操作者に対しては、負荷テストの告知情報を受信した端末によって、負荷テストの実行期間が提示される。従って、端末の操作者は、提示されたテスト実行期間を目安に、各負荷テストに対して参加申込をするかどうかを決定することができる。その結果、操作者が参加申込をすることを決定した負荷テストを入力装置を用いて特定すると、特定した負荷テストの識別情報を含む参加申込情報がサーバ（テスト管理装置）へ送信されるので、サーバ（テスト管理装置）は、参加申込情報を送信してきた端末に対してのみ、参加申込情報に識別情報が含まれた負荷テストについてのスケジュール情報を送信する。その結果、操作者が参加を望まない負荷テストに関して、端末がリクエストメッセージを送信することが防止される。
【発明の効果】
【００１０】
従って、本発明によれば、操作者は、予め各テストの実行期間を認識した上で、テスト参加を決定することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明によるウェブシステムに対する負荷テストの管理方法が実施されたネットワークの概略構成を示すブロック図
【図２】ユーザデータベースのデータ構造を示す表
【図３】テスト負荷登録データベースのデータ構造を示す表
【図４】テスト登録者管理データベースのデータ構造を示す表
【図５】テスト登録時における負荷管理システムの処理内容を示すフローチャート
【図６】負荷テストツールバープログラムによる処理内容を示すフローチャート
【図７】負荷テストツールバープログラムによる処理内容を示すフローチャート
【図８】ユーザ端末からのアクセス時における負荷管理システムの処理内容を示すフローチャート
【図９】ユーザ端末からのアクセス時における負荷管理システムの処理内容を示すフローチャート
【図１０】周期的に実行される負荷管理システムの処理内容を示すフローチャート
【図１１】テスト対象装置の処理内容を示すフローチャート
【図１２】負荷テストツールバーの画面イメージを示す図
【図１３】アップデート許可画面を示す図
【図１４】負荷テストエントリ画面を示す図
【図１５】テストスケジュールファイルのデータ構造を示す表
【発明を実施するための形態】
【００１２】
以下、図面に基づいて、本発明によるウェブシステムに対する負荷テストの管理方法及び管理装置の実施の形態を、説明する。
＜システム構成＞
図１は、かかる負荷テストの管理方法に関与する装置群のハードウェア構成を示す概略ブロック図である。
【００１３】
図１に示すように、当該負荷テストの管理方法に関与する装置には、複数台（図１では、簡略化のために一台のみ表示）のユーザ端末１，複数台のテスト対象装置２（図１では、簡略化のために一台のみ表示），及び、一台のテスト管理サーバ３が、含まれる。これらユーザ端末１，テスト対象装置２及びテスト管理サーバ３は、インターネットＮを通じて相互に接続されており、相互に通信可能とされている。
【００１４】
ユーザ端末１は、個々のユーザに所有ないし占有されている、インターネット接続機能を備えた一般的なパーソナルコンピュータである。従って、ユーザ端末１は、バスＢを通じて相互に接続されたＣＰＵ（Central Processing Unit）１０，ハードディスク１１，
リムーバブルディスク１３，通信装置１４，ＲＡＭ（Random Access Memory）１５，ディスプレイ１６及び入力装置１７を備えている。
【００１５】
これらのうち、ＣＰＵ１０は、このユーザ端末１全体の制御を行う中央処理装置である。
【００１６】
また、ＲＡＭ１５は、ＣＰＵ１０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。
【００１７】
また、通信装置１４は、インターネットＮとのインタフェースであり、インターネットＮに繋がる通信媒体の種類に依り、モデム，ネットワークカード及びルータ，等が用いられる。
【００１８】
また、リムーバブルディスク１３は、フレキシブルディスク等の磁気ディスク及びフレキシブルディスクドライブ，ＤＶＤディスク，ＣＤ−ＲＯＭ等の光学ディスク及び光学ディスクドライブ，若しくは、メモリカード及びカードスロットである。
【００１９】
また、ハードディスク１１は、ＣＰＵ１０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。ハードディスク１１に格納され且つＣＰＵ１０によってＲＡＭ１５上に読み出されて実行される各種プログラムには、一般に流通しているブラウザプログラム１９の他、ユーザ端末１が負荷テストを実行するための負荷テストツールバープログラム１８が、含まれている。負荷テストツールバープログラム１８は、ブラウザプログラム１９の機能に従って通信装置１４及びインターネットＮを通じてテスト管理サーバ２からダウンロードされ、若しくは、リムーバブルディスク１３に格納された形態で配布されて、ハードディスク１１におけるスタートアップフォルダにインストールされる。従って、ユーザ端末１に主電源が投入されると、ツールバープログラム１９が自動的に起動されて、図１２に示すようなツールバーをディスプレイ１６上の片隅に表示するとともに、ユーザ端末１がシャットオフされるまで実行され続ける。なお、負荷テストツールバープログラム１８は、テスト管理者により随時アップデートされ、最新のアップデートを反映したアップデート用モジュール３３は、インターネットＮを通じてテスト管理サーバ１からダウンロード可能となっている。そして、ダウンロードされたアップデート用モジュール３３により、ユーザ端末１のハードディスク１１にインスト
ールされた負荷テストツールバープログラム１８が更新されることにより、ユーザ端末１上においても、負荷テストツールバープログラム１８のアップデートが完遂されるのである。
【００２０】
また、ディスプレイ１６は、ＣＰＵ１０による処理結果である画面を表示する。
【００２１】
また、入力装置１７は、操作者によって操作されることにより、ＣＰＵ１０に対して各種コマンドを入力する装置であり、具体的には、キーボードや、マウス，タッチパネル等のポインティングデバイスである。
【００２２】
以上により、ユーザ端末１は、宛先情報及びテスト実行期間を指定したスケジュール情報を受信すると当該スケジュール情報により指定されたテスト実行期間に当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する端末に、相当する。
【００２３】
テスト対象装置２は、ウェブサービスの提供者によって運用されるウェブサーバ装置であり、運用後においては、何れかの端末１から送信されてきたＨＴＴＰリクエストメッセージに応じて、当該ＨＴＴＰリクエストメッセージの内容に応じた各種処理を実行して、その実行結果をメッセージ送信元端末１に応答する。従って、テスト対象装置２は、互いにバスＢによって接続されたＣＰＵ２０，通信装置２４，ＲＡＭ２５及びハードディスク２１を、ハードウェア構成として有している。
【００２４】
これらのうち、ＣＰＵ２０は、当該テスト対象装置２全体の制御を行う中央処理装置（コンピュータ）である。また、ＲＡＭ２５は、ＣＰＵ２０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。また、通信装置２４は、インターネットＮとのインタフェースである。
【００２５】
ハードディスク２１は、ＣＰＵ２０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。
【００２６】
このハードディスク２１が格納してＣＰＵ２０によってＲＡＭ２５上に読み出される各種プログラムには、上述した各種処理を実行するためのプログラム（ＷＷＷサーバプログラム，及び、幾つかのＣＧＩプログラムないしサーブレット及びバーチャルマシン等のアプリケーションプログラム）が、含まれている。これらプログラムのうち、負荷テスト対象のサービスを提供するためのプログラムがテスト対象システムプログラム２２であり、当該テスト対象システムプログラム２２を実行しているテスト対象装置２が「テスト対象システム（２，２２）」である。さらに、ハードディスク２１に格納されている各種プログラムには、負荷テストの実行結果を記録するための負荷受付システムプログラム２３が含まれている。当該負荷受付システムプログラム２３を実行しているテスト対象装置２が「負荷受付システム（２，２３）」である。
【００２７】
テスト管理サーバ３は、テスト対象装置２の運用者に対して負荷テストの代行サービスを提供する業者（以下、「テスト管理者」という）によって運用される負荷テスト管理装置としてのウェブサーバ装置である。従って、テスト管理サーバ３は、互いにバスＢによって接続されたＣＰＵ３０，通信装置３４，ＲＡＭ３５及びハードディスク３１を、ハードウェア構成として有している。
【００２８】
これらのうち、ＣＰＵ３０は、当該テスト管理サーバ３全体の制御を行う中央処理装置（コンピュータ）である。また、ＲＡＭ３５は、ＣＰＵ５０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。また、通信装置３４は、インターネットＮ
とのインタフェースである。
【００２９】
ハードディスク３１は、ＣＰＵ３０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。
【００３０】
ハードディスク３１が格納してＣＰＵ３０によってＲＡＭ３２上に読み出されて実行される各種プログラムには、上述した負荷テストの代行サービスを実行するためのプログラム（ｗｗｗサーバプログラム、及び、幾つかのＣＧＩプログラムないしサーブレット及びバーチャルマシン等のアプリケーションプログラムからなる負荷管理システムプログラム３６）が、含まれている。当該負荷管理システムプログラム３６を実行しているテスト管理サーバ３が、「負荷管理システム（３，３６）」である。また、ハードディスク３１が可能している各種データには、テスト負荷登録データベース３７，テスト登録者管理データベース３８，及び、ユーザデータベース３９が、含まれている。
【００３１】
図２に示すように、ユーザデータベース３９は、当該テスト管理サーバ３の運用者との間で負荷テストの協力者として登録された各ユーザ毎にその個人情報を登録するレコードを有しており、各レコードは、夫々、一意のユーザＩＤ，本名を示す氏名，現在のセッションにおいて用いられたクッキー，ＩＰアドレス（固定アドレス又はレンタルアドレス），及び、インセンティブの給付先に関する情報（例えば、クレジットカード番号，景品交換用若しくは商品割引用のポイント，等）を夫々格納する各フィールドから、構成されている。なお、或るユーザに付与されたクッキー又はＩＰアドレスが更新されると、当該ユーザに対応したレコードにおけるクッキー及びＩＰアドレスが、夫々、最新のものに上書きされて更新される。
【００３２】
図３に示すように、テスト負荷登録データベース３７は、テスト対象装置２の運用者によりテスト管理者に対して管理依頼された負荷テスト毎にその詳細情報を登録するレコードを有しており、各レコードは、夫々、負荷テストを一意に識別するための識別情報である「テストＩＤ」，負荷テストにおいてテスト対象システム（２，２２）に対して掛けるべき「負荷（単位：ｑｐｓ［秒当りのクエリー数］）」，当該負荷テストのためにユーザ端末１がリクエストメッセージを送信すべきテスト対象システム（２，２２）の宛先情報である「ＵＲＬ」，負荷テストが実行される「テスト実行期間」，テスト協力者に対して当該テストへの参加を募集する「受付期間」，及び，当該負荷テストの実行に必要なユーザ（登録者）数の範囲を示す「登録者数レンジ」を夫々格納する各フィールドから、構成されている。従って、当該テスト負荷登録データベース３７が、各負荷テストにつきその識別情報，リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースに、相当する。
【００３３】
なお、テスト対象装置２の運用者のテスト管理者に対する負荷テストの請負契約の申込みは、オンライン又はオフラインでなされる。このようにして負荷テストの請負契約の申込みを行ったテスト対象装置２の運用者を、「テスト依頼者」という。この申込みに際して、テスト依頼者は、上述した情報のうちＵＲＬ，負荷の値，及びテスト実行期間を特定して、テスト代行者に対して通知する。他方、テストＩＤ，受付期間及び登録者数レンジについては、負荷管理システム（３，３６）が自働生成する。
【００３４】
図４に示すように、テスト登録者管理データベース３８は、テスト管理システム（３，３６）が実行する負荷テスト，及び、各テストに参加することが正式に若しくは補欠として認められた各ユーザ（テスト登録者）の組合せに対応したレコードを有しており、各レコードは、夫々、負荷テストの識別情報である「テストＩＤ」，「負荷」，及び「テスト実行期間」，テスト登録者の個人識別情報である「ユーザＩＤ」，並びに、正式に登録を認められたか補欠であるかの「種別」を夫々格納する各フィールドから、構成されている
。従って、当該テスト登録者管理データベース３８が、参加申込情報を送信した端末に対応した個人識別情報及び同参加申込情報に含まれる負荷テストの識別情報が相互に対応付けて登録された第２データベースに、相当する。
【００３５】
さらに、テスト管理者が負荷テストツールバープログラム１８のアップデートを行った場合には、当該アップデートをユーザ端末１上の負荷テストツールバープログラム１８に反映させるためのアップデート用モジュール３３が、テスト管理者によって、ハードディスク３１に格納され、ユーザ端末１によるダウンロード要求に備えられる。
＜処理フロー＞
以下、負荷テストの実行に関して各装置１，２，３が夫々プログラム（負荷テストツールバープログラム１８，テスト対象システムプログラム２２，負荷受付システムプログラム２３，負荷管理システムプログラム３６）に従って実行する処理を、図５乃至図１０のフローチャートに従って説明する。
［負荷テスト登録時の処理］
図５は、テスト依頼者とテスト管理者との間で個々の負荷テストの代行についての契約（請負契約）が締結された後に負荷管理システム（３，３６）が実行する当該負荷テストのテスト負荷登録データベース３７への登録処理を示すフローチャートである。
【００３６】
この処理を開始して最初のＳ００１では、負荷管理システム（３，３６）は、テスト依頼者から指定された（入力された，若しくは、受信した）登録対象負荷テストにおけるＵＲＬ及び負荷の値に基づき、必要な登録者数のレンジを決定する。具体的には、負荷管理システム（３，３６）は、上記ＵＲＬに基づいて、負荷テストにおいて実行される処理タイプを（ア）閲覧系，（イ）検索系，（ウ）登録系の何れかに分類する。そして、負荷管理システム（３，３６）は、分類された処理タイプ毎に登録者一人当たりの負荷の下限値及び上限値を決定する。即ち、処理タイプが閲覧系であれば下限値を１ｑｐｓ，上限値を５ｑｐｓと決定し、処理タイプが検索系であれば下限値を１ｑｐｓ，上限値を３ｑｐｓと決定し、処理タイプが登録系であれば下限値を１ｑｐｓ，上限値を２ｑｐｓと決定する。このように処理タイプに依り登録者一人当たりの負荷の範囲を相違させるのは、通信負荷（ｑｐｓ）が同じであっても、処理タイプの相違に依って処理負荷に相違があることに拠る。その上で、負荷管理システム（３，３６）は、テスト依頼者から指定された負荷の値を上記登録者一人当たりの負荷の下限値及び上限値により夫々除することにより、必要な登録者数の上限値及び下限値を決定するのである。例えば、指定された負荷の値が５０ｑｐｓであり、指定されたＵＲＬが検索系であった場合、必要な登録者数の下限値は１７人であり上限値は５０人となるので、必要な登録者数レンジは、１７〜５０人と決定される。
【００３７】
次のＳ００２では、負荷管理システム（３，３６）は、登録対象負荷テストの受付期間を決定する。具体的には、テスト依頼者から受け取った（入力された，若しくは、受信した）テスト実行期間に先立つ所定期間を、受付期間として決定する。
【００３８】
次のＳ００３では、負荷管理システム（３，３６）は、登録対象負荷テストのテストＩＤを生成した上で、テスト依頼者から受け取った（入力された，若しくは、受信した）登録対象負荷テストにおける負荷の値，ＵＲＬ，テスト実行期間，並びに、Ｓ００１にて決定した登録者数レンジ，Ｓ００２にて決定した受け付け期間を格納した新規レコードを、テスト負荷登録データベース３７に追加する。Ｓ００３を完了すると、負荷管理システム（３，３６）は、当該負荷テスト登録時の処理を、全て終了する。
［負荷テストへのユーザの参加登録時の処理］
次に、図６及び図７に示す負荷テストツールバープログラム１８に基づくユーザ端末１の処理フローチャートの一部，並びに、図８及び図９に示す負荷管理システム（３，３６）の処理フローチャートに基づいて、負荷テストへの協力者（参加者）を公募し、応募し
てきたユーザを登録者としてテスト登録者管理データベース３８に登録するための処理を、説明する。
【００３９】
図６及び図７に示すように、ツールバープログラム１９を実行しているユーザ端末１（ＣＰＵ１０）は、Ｓ１０１〜Ｓ１０５のループ処理を繰り返し実行する。即ち、ユーザ端末１は、Ｓ１０１においてテスト管理サーバ（負荷管理システム）３にアクセスして、新規の情報を要求するＨＴＴＰリクエストメッセージ（情報要求メッセージ）を送信する。そして、ユーザ端末１は、Ｓ１０２において、テスト管理サーバ（負荷管理システム）３からアップデート案内情報を受信したか否かをチェックし、受信していなければ、Ｓ１０３において、テスト管理サーバ（負荷管理システム）３から負荷テストの告知情報を受信したか否かをチェックし、受信していなければ、Ｓ１０４において、テスト管理サーバ（負荷管理システム）３から最終確認情報を受信したか否かをチェックし、受信していなければ、Ｓ１０５において、テスト管理サーバ（負荷管理システム）３から起動確認要求を受信したか否かをチェックする。
【００４０】
他方、ユーザ端末１からアクセスされて新規情報要求のＨＴＴＰリクエストメッセージを受信する毎に、テスト管理サーバ（負荷管理システム）３は、図８及び図９の処理を実行する。そして、テスト管理サーバ（負荷管理システム）３は、スタート後最初のＳ２０１において、ハードディスク３１にアップデートモジュール３３が存在しているかどうかをチェックする。そして、テスト管理サーバ（負荷管理システム）３は、ハードディスク３１にアップデートモジュール３３が存在していなければ、処理を直ちにＳ２０５へ進める。これに対して、アップデートモジュール３３が存在している場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０２において、アップデート案内情報を格納したレスポンスメッセージを、アクセス元ユーザ端末１へ応答する。その後、テスト管理サーバ（負荷管理システム）３は、Ｓ２０３において、アクセス元ユーザ端末１が、所定時間内にアップデート要求のＨＴＴＰリクエストメッセージ（Ｓ１０７）を送信して来るのを、待つ。
【００４１】
図６のＳ１０２において、テスト管理サーバ（負荷管理システム）３からアップデート案内情報（Ｓ２０２）を受信したと判断した場合には、ユーザ端末１は、処理をＳ１０６へ進める。Ｓ１０６では、ユーザ端末１は、ディスプレイ１６上に図１３に示すアップデート許可画面を表示して、入力装置１７を用いたユーザによる入力内容をチェックする。即ち、当該アップデート許可画面には、アップデートの許可に対応した「ＹＥＳ」ボタン４１と「ＮＯ」ボタン４２とが含まれている。ユーザ端末１は、「ＹＥＳ」ボタン４１が入力装置１７（ポインティングデバイス）によりクリックされた場合には、アップデートが許可されたと認識して、処理をＳ１０７へ進め、「ＮＯ」ボタン４２がクリックされた場合には、アップデートが拒絶されたと判断して、処理をＳ１０８へ進める。Ｓ１０７では、ユーザ端末１は、テスト管理サーバ（負荷管理システム）３に対してアップデート要求のＨＴＴＰリクエストメッセージを送信する。
【００４２】
図８のＳ２０３において、アクセス元ユーザ端末１からのアップデート要求のＨＴＴＰリクエストメッセージ（Ｓ１０７）を受信したと判断した場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０４において、ハードディスク３１内のアップデート用モジュール３３を格納したレスポンスメッセージを、アクセス元ユーザ端末１へ応答する。Ｓ２０４の完了後、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０５へ進める。
【００４３】
これに対して、アップデートが拒絶された場合には、ユーザ端末１は、図６のＳ１０８において、Ｓ１０１の場合と同様にサーバにアクセスし、Ｓ１０９において、Ｓ１０２の場合と同様にアップデート案内情報（Ｓ２０２）を受信したか否かを、チェックする。そ
して、ユーザ端末は、新たなアップデート案内情報を受信しない限り、処理をＳ１０８に戻す。これは、最新のツールバー１８を用いたテスト参加のみを許容する趣旨である。そして、新たなアップデート案内情報を受信すると（Ｓ１０９：Ｙｅｓ）、ユーザ端末１は、処理をＳ１０６に戻し、新たなアップデートを許可するか否かのチェックを行う。
【００４４】
上述のようにしてアップデートが拒絶された場合には、ユーザ端末１からテスト管理サーバ（負荷管理システム）３へアップデート要求（Ｓ１０７）は送信されない。従って、テスト管理サーバ（負荷管理システム）３は、Ｓ２０３において、アップデート要求のＨＴＴＰリクエストメッセージが所定時間受信されないことをもって、処理をタイムアウト終了させる。
【００４５】
図８のＳ２０５では、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース７を参照して、受付期間に入った負荷テストが存在するか否かをチェックする。そして、未だ受付期間に入った負荷テストが存在しなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１５へ進める。これに対して、受付期間に入った負荷テストが一つ以上存在する場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０６において、現在受付期間に入っている全負荷テストについて、負荷テスト告知情報を生成し、アクセス元ユーザ端末１へ送信する。即ち、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース３７を参照し、現在時刻が受付期間に含まれている全レコードを読み出し、読み出した全レコード中の「テストＩＤ」フィールド，「テスト実行期間」フィールド，及び「受付期間」フィールドの値を格納したレスポンスメッセージを、テスト実行期間に先立って、アクセス元ユーザ端末１へ応答する。Ｓ２０６を完了すると、テスト管理サーバ（負荷管理システム）３は、Ｓ２０７において、ユーザ端末１から参加申込みのＨＴＴＰリクエストメッセージ（Ｓ１１１）が送信されて来るのを待つ。
【００４６】
図６のＳ１０３において、テスト管理サーバ（負荷管理システム）３から負荷テスト告知情報（Ｓ２０６）を受信したと判断した場合には、ユーザ端末１は、処理をＳ１１０へ進める。Ｓ１１０では、ユーザ端末１は、受信した負荷テスト告知情報に基づいて、ディスプレイ１６上に、図１４に示す負荷テストエントリ画面を表示する。この負荷テストエントリ画面には、各負荷テストに行を対応させ、「テスト」フィールドの値，「受付期間」フィールドの値，「テスト実行期間」フィールドの値，エントリ用のチェックボックス，及び「種別」（但し、当該処理の実行時点では空欄）に各列を夫々対応させた表４３と「ＯＫ」ボタン４４とが、含まれている。即ち、ユーザ端末１は、告知情報に含まれる各負荷テストのテスト実行期間をユーザに提示する。そして、ユーザ端末１は、ユーザが入力装置１７（ポインティングデバイス）を用いて何れかの負荷テストに対応したチェックボックスにチェックを付した状態で「ＯＫ」ボタン４４をクリックすると、ユーザが何れかの負荷テストに参加する意思であるとして、処理をＳ１１１へ進める。これに対して、何れのチェックボックスにもチェックが付されていない状態で「ＯＫ」ボタン４４がクリックされた場合，若しく、何ら入力がないまま一定時間が経過した場合には、ユーザ端末１は、ユーザが何れの負荷テストにも参加する意思がないとして、処理をＳ１０４へ進める。
【００４７】
Ｓ１１１では、ユーザ端末１は、チェックが付された全チェックボックスに対応した各負荷テストのテストＩＤを格納した参加申込メッセージを、テスト管理サーバ（負荷管理システム）３へ送信する。即ち、ユーザ端末１は、ユーザが入力装置１７を用いて特定した負荷テストの識別情報を含む参加申込情報をテスト管理サーバ（負荷管理システム）３へ送信する。その後、ユーザ端末１は、Ｓ１１２において、テスト管理サーバ（負荷管理システム）３からの応答メッセージ（Ｓ２１４）を待つ。
【００４８】
図８のＳ２０７において、一定時間以上ユーザ端末１からの参加申込メッセージ（Ｓ１１１）が受信されない場合には、テスト管理サーバ（負荷管理システム）３は、タイムアウトにより、処理をＳ２１５へ進める。これに対して、一定時間内にユーザ端末１からの参加申込メッセージ（Ｓ１１１）を受信すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０７からＳ２０８へ進める。
【００４９】
Ｓ２０８では、テスト管理サーバ（負荷管理システム）３は、参加申込メッセージ（Ｓ１１１）に含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、アクセス元ユーザ端末１を操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、Ｓ２０７にて受信した参加申込みメッセージに含まれる各テストＩＤ毎に、当該テストＩＤ，上記ユーザＩＤ，当該テストＩＤに基づきテスト負荷登録データベース３７から読み出したテスト実行期間を含む新規レコード（但し、この処理時点では「種別」フィールド，及び「負荷」フィールドは空欄である）を、テスト登録者管理データベース３８に格納する。
【００５０】
次のＳ２０９では、テスト管理サーバ（負荷管理システム）３は、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤのうちの一つを特定する。
【００５１】
次のＳ２１０では、テスト管理サーバ（負荷管理システム）３は、Ｓ２０９にて特定したテストＩＤを含む全レコード数（登録者数）が、当該テストＩＤについてテスト負荷登録データベース３７に登録されている登録者数レンジの上限を超えたか否かをチェックする。そして、未だ前者が後者を超えていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１１において、当該テストＩＤを含む新規レコード中の「種別」フィールドに、“正式”なる値を登録する。これに対して、登録者数が上限を超えた場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１２において、当該テストＩＤを含む新規レコード中の「種別」フィールドに、“補欠”なる値を登録する。Ｓ２１１又はＳ２１２を完了すると、テスト管理サーバ（負荷管理システム）３は、Ｓ２１３において、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了したかどうかをチェックする。そして、未だ全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了していない場合には、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０９へ戻す。これに対して、既に全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了した場合には、Ｓ２１４にて、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤ毎に、Ｓ２１１又はＳ２１２にて登録した「種別」フィールドの値を格納した受付応答メッセージを、アクセス元ユーザ端末１へ応答する。Ｓ２１４を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１５へ進める。
【００５２】
図６のＳ１１２において、テスト管理サーバ（負荷管理システム）３からの受付応答メッセージ（Ｓ２１４）を受信すると、ユーザ端末１は、Ｓ１１３において、Ｓ１１２にて受信した応答メッセージに含まれる各テストＩＤについての「種別」の値を、負荷エントリ画面（図１４）中の表４３における「種別」欄に、夫々、表示する。Ｓ１１３を完了すると、ユーザ端末１は、処理をＳ０１４へ進める。
【００５３】
図９のＳ２１５では、テスト管理サーバ（負荷管理システム）３は、情報要求メッセージ（Ｓ１１１）に含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、アクセス元ユーザ端末１を操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、読み出したユーザＩＤに対応した全テストＩＤを、テスト登録者管理データベース３８から読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース３７を参照して、読
み出した全テストＩＤに対応した負荷テストのうちに、受付期間を満了した負荷テストが存在するか否かを、チェックする。そして、テスト管理サーバ（負荷管理システム）３は、受付期間を満了した負荷テストが存在しなければ全処理を終了するが、受付期間を満了した負荷テストが一つ以上存在する場合には処理をＳ２１６へ進める。
【００５４】
Ｓ２１６では、テスト管理サーバ（負荷管理システム）３は、Ｓ２１５にて受付期間を満了したと判定した負荷テストに対応した全テストＩＤのうちの一つを特定する。
【００５５】
次のＳ２１７では、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照して、Ｓ２１６にて特定されたテストＩＤを含む全レコード数（登録者数）が当該テストＩＤについてテスト負荷登録データベース３７に登録されている登録者数レンジの下限を満たしているか否かを、チェックする。そして、前者が後者を満たしていれば、テスト管理サーバ（負荷管理システム）３は、Ｓ２１８において、ツールバーの起動時間の最終確認情報，即ち、Ｓ２１６にて特定されたテストＩＤについてテスト負荷登録データベース３７に登録されているテスト実行期間を指定した最終確認情報を、アクセス元ユーザ端末１へ送信する。これに対して、前者が後者を満たしていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１９において、負荷テスト中止を通告する最終確認情報を、アクセス元ユーザ端末１へ送信する。Ｓ２１８又はＳ２１９を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２２０へ進める。
【００５６】
Ｓ２２０では、テスト管理サーバ（負荷管理システム）３は、Ｓ２１５にて受付期間を満了したと判定した負荷テストに対応した全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了したか否かを、チェックする。そして、未だ全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了していなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１６に戻す。これに対して、全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了した場合には、テスト管理サーバ（負荷管理システム）３は、全処理を終了する。
【００５７】
図６のＳ１０４において、何れかの最終確認情報（Ｓ２１８，Ｓ２１９）を受信すると、ユーザ端末１は、Ｓ１１４において、受信した最終確認情報の内容（負荷テスト中止の旨及びツールバーの起動時間）を、ツールバー上に表示する。Ｓ１１４を完了すると、ユーザ端末１は、処理をＳ１０５へ進める。
［負荷テスト実行時の処理］
次に、図７に示す負荷テストツールバープログラム１８に基づくユーザ端末１の処理フローチャートの残部，図１０に示す負荷管理システム（３，３６）の処理フローチャート，並びに、図１１に示す負荷受付システム（２，２３）に基づいて、負荷テストを実行するための処理を、説明する。
【００５８】
図１０の処理は、例えば１時間毎というように、周期的に割込みスタートする。そして、スタート後最初のＳ３０１において、テスト負荷登録データベース３７を参照して、現在実行期間に入っている負荷テストが存在するか否かをチェックする。そして、未だ実行期間に入ったテストがなければ、テスト管理サーバ（負荷管理システム）３は、全処理を終了する。これに対して、実行期間に入ったテストが存在する場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ３０２において、所定の一定期間（例えば１０秒）内に情報要求メッセージ（Ｓ１０１）を送信してきた各ユーザ端末１について、情報要求メッセージに含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照し、読み出したユーザＩＤを含むとともに、「種別」の値が“正式”であり、且つ現在テスト実行期間に入っているレコードが存在していれば、アクセス元ユーザ端末１へ起動確認要求メッセージを送
信する。
【００５９】
図７のＳ１０５において起動確認要求メッセージ（Ｓ３０２）を受信したと判断した場合には、ユーザ端末１は、Ｓ１１５において、応答メッセージを、テスト管理サーバ（負荷管理システム）３へ送信する。その後、ユーザ端末１は、Ｓ１１６において、テスト管理サーバ（負荷管理システム）３からテストスケジュールファイル（Ｓ３０５）を受信するのを待つ。
【００６０】
図１０の３０３において、テスト管理サーバ（負荷管理システム）３は、Ｓ３０２又はＳ３０４の完了後所定の一定時間（例えば１秒）内に受信した応答メッセージの累計数が、Ｓ３０１にて実行期間に入ったと判断した負荷テストについてテスト負荷登録データベース３７に登録されている登録者数レンジを満たしているか否かをチェックする。そして、未だ前者が後者を満たしていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ３０４において、所定の一定期間（例えば１秒）内に情報要求メッセージ（Ｓ１０１）を送信してきた各ユーザ端末１について、情報要求メッセージに含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照し、読み出したユーザＩＤを含むとともに、「種別」の値が“補欠”であり、且つ現在テスト実行期間に入っているレコードが存在していれば、アクセス元ユーザ端末１へ接続確認要求を送信する。Ｓ３０４を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ３０３へ戻す。
【００６１】
以上のＳ３０３及びＳ３０４の処理を繰り返した結果、受信した応答メッセージの累計数が必要なレンジを満たしたと判断した場合（Ｓ３０３：Ｙｅｓ）、テスト管理サーバ（負荷管理システム）３は、Ｓ３０５において、当該負荷テストにつきテスト負荷登録データベース３７に登録された負荷の値を満たすことができるように、Ｓ３０３にて応答が受信された全ての登録者に対して極力均等に負荷を分配して、分配された各登録者別の負荷の値をテスト登録者管理データベース３８に登録する。
【００６２】
具体的には、テスト管理サーバ（負荷管理システム）３は、当該負荷テストにつきテスト負荷登録データベース３７に登録されている負荷の値を登録者数レンジの最大値にて除することにより、当該負荷テストの処理タイプに応じた一人当たりの負荷の下限を算出し、算出された負荷を、Ｓ３０３にて応答が受信された全ての登録者に割り当てる。次に、当該割当の結果としてテスト負荷登録データベース３７に登録された負荷の値に余剰を生じた場合には、所定の順番（例えば、Ｓ３０３にて応答が受信された順番）に従って、各登録者に対して、余剰の負荷から所定単位づつ負荷の値を割り当てる。当該余剰負荷の割当は、剰余の負荷が無くなるまで行われる。
【００６３】
例えば、テスト負荷登録データベース３７に登録された負荷の値が“５０ｑｐｓ”であり、登録者数レンジが“１７〜５０人”である場合、当該負荷テストの処理種別に応じた一人当たりの負荷の下限は“１ｑｐｓ”となる。従って、剰余の負荷の割当単位を“１ｑｐｓ”とした場合、Ｓ３０３にて応答が受信された登録者数が“５０人”であれば剰余負荷を生じないが、当該登録者数が“４０人”なら“１０ｑｐｓ”の剰余負荷を生じるので、１〜１０番目登録者に計“２ｑｐｓ”が割り当てられ、他の３０名の登録者には“１ｑｐｓ”のみが割り当てられる。また、登録者数が“２５人”なら“２５ｑｐｓ”の剰余負荷を生じるので、全員に計“２ｑｐｓ”が割当てられる。また、当該登録者数が“２０人”なら“３０ｑｐｓ”の剰余負荷を生じるので、その全員に“１ｑｐｓ”づつ剰余負荷を割り当てても未だ“１０ｑｐｓ”余り、よって、１〜１０番目登録者に対しては２周目の剰余負荷の割当がなされ、結局、１〜１０番目登録者に計“３ｑｐｓ”が割り当てられ、他の１０名の登録者には“２ｑｐｓ”が割り当てられる。
【００６４】
以上の負荷の割当及び登録を行った上で、テスト管理サーバ（負荷管理システム）３は、各登録者が操作するユーザ端末１から受信した応答メッセージ（Ｓ１１５）に対するレスポンスとして、各登録者に割り当てられた負荷の値，テスト実行期間，テスト対象システム（２，２２）のＵＲＬ，並びにテストＩＤ及び当該登録者のユーザＩＤが記述されたテストスケジュールファイル（図１５参照）を生成し、これを暗号化して、各登録者が操作するユーザ端末１に個別に送信する。即ち、テスト管理サーバ（負荷管理システム）３は、第１データベースを参照し、参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、ユーザ端末１へ送信する。
【００６５】
Ｓ３０５を完了すると、テスト管理サーバ（負荷管理システム）３は、全処理を完了する。
【００６６】
図７のＳ１１６においてテストスケジュールファイル（Ｓ３０５）を受信したユーザ端末１は、Ｓ１１７において、Ｓ１１６にて受信したテストスケジュールファイルを復号化する。なお、テストスケジュールファイルは、最新版のツールバープログラムによってのみ復号化できるように暗号化されているので、これを受信したユーザ端末１の操作者は、テスト対象システム（２，２２）のＵＲＬを盗み見ることができない。よって、公開前のテスト対象システム（２，２２）のＵＲＬの秘匿性が維持される。
【００６７】
次のＳ１１８では、テスト管理サーバ（負荷管理システム）３は、テストスケジュールファイル中で指定された負荷（ｑｐｓ）に応じた頻度にて、同ファイル中で指定されたＵＲＬに対してＨＴＴＰリクエストメッセージを送信し続ける。次のＳ１１９では、テスト管理サーバ（負荷管理システム）３は、Ｓ１１６にて受信したテストスケジュールファイル中で指定されたテスト実行期間が満了したか否かをチェックする。そして、未だテスト実行期間が満了していなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ１１８へ戻す。これに対して、テスト実行期間が満了した場合，若しくは、入力装置１７を用いたユーザによる操作により負荷テストが強制終了された場合、テスト管理サーバ（負荷管理システム）３は、処理をＳ１２０へ進める。Ｓ１２０では、テスト管理サーバ（負荷管理システム）３は、テスト対象装置２からのインセンティブ通知（Ｓ４０５）を待つ。
【００６８】
テスト対象装置２は、テスト対象システム（２，２２）として、図１１のＳ４０１において、ユーザ端末１から負荷テストの為のＨＴＴＰリクエストメッセージ（Ｓ１１８）を受信したか否かをチェックし、何らメッセージを受信していないと、処理をそのままＳ４０３へ進め、メッセージを受信していると、Ｓ４０２において、当該メッセージによりリクエストされた処理を実行するとともに受信ログを録った後に、処理をＳ４０３へ進める。
【００６９】
Ｓ４０３では、テスト対象装置２は、負荷受付システム（２，２３）として、テスト対象システム（２，２２）に対する負荷テストのテスト実行期間が満了したか否かをチェックし、未だテスト実行期間が満了していなければ処理をＳ４０１に戻し、テスト実行期間が満了していれば、処理をＳ４０４へ進める。
【００７０】
Ｓ４０４では、テスト対象装置２は、負荷受付システム（２，２３）として、テスト管理サーバ３との間で通信を行い、テスト登録者管理データベース３８にアクセスする。そして、テスト対象装置２は、テスト登録者管理データベース３８の内容と受信ログとを照合する。
【００７１】
次のＳ４０５では、テスト対象装置２は、Ｓ４０４での照合の結果として、テスト登録者管理データベース３８において予定されていた通りの負荷を送信した登録者に対して、分配された負荷に応じたインセンティブが有る旨の通知を行い、予定されていた通りの負荷を送信しなかった登録者に対して、インセンティブ無しの通知を行う。同時に、テスト対象端末２は、同じ通知をテスト管理サーバ３に対しても行って、インセンティブ有りとした登録者に対するインセンティブの付与を依頼する。Ｓ４０５を完了すると、テスト対象装置２は、全処理を終了する。
【００７２】
図７のＳ１２０においてテスト対象装置２からインセンティブの通知（Ｓ４０５）を受信すると、ユーザ端末１は、Ｓ１２１において、Ｓ１２０にて受信したインセンティブの通知の内容（有り又は無し，及び、インセンティブが有る場合にはその内容）を、負荷テストツールバー上に表示する。Ｓ１２１を完了すると、ユーザ端末１は、処理をＳ１０１に戻す。
【００７３】
以上に説明したように、本実施形態によると、負荷テストツールバープログラム１８を自己の所有又は占有にかかるユーザ端末１上で実行させているとともにユーザデータベース３９に登録されているユーザであっても、自動的に負荷管理システム３６に登録されている全負荷テストに参加を強いられるのではなく、各負荷テストのテスト実行期間を予め認識した上で、これを考慮に容れて、各負荷テストへの参加を主体的に決定することができる（Ｓ１１１）。従って、各ユーザは、自己が参加する負荷テストの実行期間を知ることができるので、負荷テストの実行期間中に、確実に、自己のユーザ端末１及び負荷テストツールバープログラム１８を起動させておくことができる。これにより、実際のテスト実行期間内に必要な台数のユーザ端末１が負荷テストに参加する蓋然性が高まるので、負荷テストが不成立になる可能性が減少し、負荷テストの結果についても信頼性が高まる。
【００７４】
また、本実施形態によると、最新のアップデートがなされた負荷テストツールバープログラム１８のみによって負荷テストへの参加が可能になるので（Ｓ１０６〜Ｓ１０９）、負荷テストツールバープログラム１８の版数の相違に因る誤動作やテスト対象システム（２，２２）のＵＲＬの漏洩を、防止することができる。
【００７５】
また、本実施形態によると、テスト依頼者によって指定された個々の負荷テストに必要な負荷の総量及び処理種別に応じてテスト登録者数レンジが自動的に決定される（Ｓ００１）。そして、テスト参加希望者の総数が受付期間中にテスト登録者数レンジに至らなければ、負荷テストの結果に信頼性が置くことができないので、当該負荷テストは中止される（Ｓ２１９）。また、テスト参加に応募したユーザは先着順に正式に参加登録されるが、登録者の総数が受付期間中にテスト登録者数レンジの上限を超えると、各参加者に有意な量の負荷を分配することができなくなってしまう，若しくは、全参加者に有意な量の負荷を割り当てようとすると負荷総量が必要量を上回ってしまうので、正式な登録の受付は締め切られる（Ｓ２１０）。もっとも、正式に登録されたユーザがテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動するかどうかは、ユーザの良心に任されるので、必ずしも、正式に登録された全ユーザがテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動するとは限らず、実際に負荷テストに参加する登録者数がテスト登録者数レンジを下回ることもありえる。そのため、本実施形態では、正式な参加登録者の受付を締め切った後に参加申し込みをしたユーザは、補欠として登録され（Ｓ２１２）、正式に登録された全ユーザのうちテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動した者の数がテスト登録者数レンジを下回った場合には、補欠の登録者が繰り上げられて（Ｓ３０４）、負荷テストに必要な数の参加者が確保されるのである（Ｓ３０３）。
【００７６】
このようにして各負荷テストの実行期間においてユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動したことが確認されたユーザ（正式な登録者及び繰り上げられた補欠の登録者）に対しては、その人数に応じて、負荷が極力均等に分配される（Ｓ３０５）。その結果、様々な通信経路を経てテスト対象装置（テスト対象システム２，２２）へ送信されるＨＴＴＰリクエストメッセージの量が均等化されるので、特定の通信経路にのみ負荷が集中するという弊害が防止され、よって、実際の負荷の掛かり具合に近似した負荷テストを実施することが可能となる。
【符号の説明】
【００７７】
１ ユーザ端末
２ テスト対象装置
３ テスト管理サーバ
１０ ＣＰＵ
１１ ハードディスク
１４ 通信装置
１６ ディスプレイ
１７ 入力装置
１８ 負荷テストツールバープログラム
２０ ＣＰＵ
２１ ハードディスク
２２ テスト対象システム
２３ 負荷受付システム
２４ 通信装置
３０ ＣＰＵ
３１ ハードディスク
３４ 通信装置
３６ 負荷管理システム
３７ テスト負荷登録データベース
３８ テスト登録者管理データベース
３９ ユーザデータベース
【技術分野】
【０００１】
本発明は、ネットワークを通じて受信したユーザ端末からのリクエストメッセージに応じて処理を実行するウェブシステムに対して行う負荷テストを、管理するための管理方法及び管理装置に、関する。
【背景技術】
【０００２】
インターネット等のネットワークは、何らかのサービスを提供する多数のサーバとサービスを要求する多数のユーザ端末とを蜘蛛の巣状に接続するネットワークシステムである。そして、サービス提供を行うサーバは、各ユーザ端末からのリクエストメッセージを受信することにより、当該リクエストメッセージに従った処理を実行して、その処理結果をリクエスト元端末へ応答する。かかるサーバによる処理は、ユーザ端末からのリクエストメッセージ毎に実行されるが、同時に実行可能な処理の個数はサーバの処理能力に依存する。その為、多数のユーザ端末からのリクエストメッセージが一度に集中した場合には、サーバに対する処理負荷がサーバの処理能力を超えてしまい、サーバの処理速度が極端に低下したり、サーバがシステムダウンを起こしてしまう等の障害が生じ得る。また、多数のリクエストメッセージが一つの通信経路に集中して、その通信容量を超えてしまうと、通信経路が輻輳を起こしてしまう等の障害が生じ得る。そこで、ネットワーク上で新規のサービスを開始する際には、サービス開始に先立って、当該サービスを提供するサーバに対して、ネットワークを通じて多数（サービスの仕様において想定された最大アクセス数を十分上回る数）のダミーのリクエストメッセージを実際に送信することにより、障害の発生の有無をテストする必要がある。
【０００３】
従来、かかるテスト（以下、「負荷テスト」という）は、負荷テストサービスを提供するサーバ（以下、「負荷テストサーバ」という）によって内部的ないし論理的に生成された多数の仮想クライアントが多数のリクエストメッセージを同時にテスト対象のサーバ（以下、「テスト対象サーバ」という）へ送信するものとして実行されていたが、負荷テストへの協力者を公募し、多数の協力者が夫々所有する端末から実際にリクエストメッセージをテスト対象サーバに対して自動送信させる提案も存在していた（特許文献１）。
【０００４】
上記特許文献記載の方式によると、テスト対象サーバのアドレス及びテスト実行期間の指定情報は、協力者が任意に覗くことができない様に暗号化されたファイル（接続先情報ファイル）に書き込まれた状態で、協力者の端末に提供される。そして、当該接続先情報ファイルには、多数の負荷テストにつき、夫々のアドレス及びテスト実行期間の指定情報が、書き込まれている。そして、端末にインストールされた自動接続プログラムが、接続先情報ファイルを読み込んで、当該ファイルに列挙されたアドレスに対して、各アドレスに対応付けられた実行期間中に、リクエストメッセージを自動的に送信するのである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１３２５３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、協力者としては、如何なる数のテストが如何なるタイミングで実行されるのかの予定を知ることができないので、自己の端末使用の都合に鑑みて、負荷テストへの参加を躊躇してしまうこともあり得る。
【０００７】
そこで、本発明の課題は、協力者が予め各テストの実行期間を認識した上で、テスト参加を決定することができるウェブシステムに対する負荷テストの管理方法及び管理装置を提供することとする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明では、サーバ（テスト管理装置）が、各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を端末へ送信する。すると、負荷テストの告知情報を受信した端末は、告知情報に含まれる各負荷テストのテスト実行期間を操作者に提示し、操作者が、入力装置を用いて各負荷テストのうち何れかを特定すると、特定した負荷テストの識別情報を含む参加申込情報をサーバ（テスト管理装置）へ送信する。すると、参加申込情報を受信したサーバ（テスト管理装置）は、第１データベースを参照し、参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、参加申込情報を送信した端末へ送信する。すると、スケジュール情報を受信した端末は、スケジュール情報により指定されたテスト実行期間に、同スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する。
【０００９】
以上のように構成されることから、端末の操作者に対しては、負荷テストの告知情報を受信した端末によって、負荷テストの実行期間が提示される。従って、端末の操作者は、提示されたテスト実行期間を目安に、各負荷テストに対して参加申込をするかどうかを決定することができる。その結果、操作者が参加申込をすることを決定した負荷テストを入力装置を用いて特定すると、特定した負荷テストの識別情報を含む参加申込情報がサーバ（テスト管理装置）へ送信されるので、サーバ（テスト管理装置）は、参加申込情報を送信してきた端末に対してのみ、参加申込情報に識別情報が含まれた負荷テストについてのスケジュール情報を送信する。その結果、操作者が参加を望まない負荷テストに関して、端末がリクエストメッセージを送信することが防止される。
【発明の効果】
【００１０】
従って、本発明によれば、操作者は、予め各テストの実行期間を認識した上で、テスト参加を決定することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明によるウェブシステムに対する負荷テストの管理方法が実施されたネットワークの概略構成を示すブロック図
【図２】ユーザデータベースのデータ構造を示す表
【図３】テスト負荷登録データベースのデータ構造を示す表
【図４】テスト登録者管理データベースのデータ構造を示す表
【図５】テスト登録時における負荷管理システムの処理内容を示すフローチャート
【図６】負荷テストツールバープログラムによる処理内容を示すフローチャート
【図７】負荷テストツールバープログラムによる処理内容を示すフローチャート
【図８】ユーザ端末からのアクセス時における負荷管理システムの処理内容を示すフローチャート
【図９】ユーザ端末からのアクセス時における負荷管理システムの処理内容を示すフローチャート
【図１０】周期的に実行される負荷管理システムの処理内容を示すフローチャート
【図１１】テスト対象装置の処理内容を示すフローチャート
【図１２】負荷テストツールバーの画面イメージを示す図
【図１３】アップデート許可画面を示す図
【図１４】負荷テストエントリ画面を示す図
【図１５】テストスケジュールファイルのデータ構造を示す表
【発明を実施するための形態】
【００１２】
以下、図面に基づいて、本発明によるウェブシステムに対する負荷テストの管理方法及び管理装置の実施の形態を、説明する。
＜システム構成＞
図１は、かかる負荷テストの管理方法に関与する装置群のハードウェア構成を示す概略ブロック図である。
【００１３】
図１に示すように、当該負荷テストの管理方法に関与する装置には、複数台（図１では、簡略化のために一台のみ表示）のユーザ端末１，複数台のテスト対象装置２（図１では、簡略化のために一台のみ表示），及び、一台のテスト管理サーバ３が、含まれる。これらユーザ端末１，テスト対象装置２及びテスト管理サーバ３は、インターネットＮを通じて相互に接続されており、相互に通信可能とされている。
【００１４】
ユーザ端末１は、個々のユーザに所有ないし占有されている、インターネット接続機能を備えた一般的なパーソナルコンピュータである。従って、ユーザ端末１は、バスＢを通じて相互に接続されたＣＰＵ（Central Processing Unit）１０，ハードディスク１１，
リムーバブルディスク１３，通信装置１４，ＲＡＭ（Random Access Memory）１５，ディスプレイ１６及び入力装置１７を備えている。
【００１５】
これらのうち、ＣＰＵ１０は、このユーザ端末１全体の制御を行う中央処理装置である。
【００１６】
また、ＲＡＭ１５は、ＣＰＵ１０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。
【００１７】
また、通信装置１４は、インターネットＮとのインタフェースであり、インターネットＮに繋がる通信媒体の種類に依り、モデム，ネットワークカード及びルータ，等が用いられる。
【００１８】
また、リムーバブルディスク１３は、フレキシブルディスク等の磁気ディスク及びフレキシブルディスクドライブ，ＤＶＤディスク，ＣＤ−ＲＯＭ等の光学ディスク及び光学ディスクドライブ，若しくは、メモリカード及びカードスロットである。
【００１９】
また、ハードディスク１１は、ＣＰＵ１０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。ハードディスク１１に格納され且つＣＰＵ１０によってＲＡＭ１５上に読み出されて実行される各種プログラムには、一般に流通しているブラウザプログラム１９の他、ユーザ端末１が負荷テストを実行するための負荷テストツールバープログラム１８が、含まれている。負荷テストツールバープログラム１８は、ブラウザプログラム１９の機能に従って通信装置１４及びインターネットＮを通じてテスト管理サーバ２からダウンロードされ、若しくは、リムーバブルディスク１３に格納された形態で配布されて、ハードディスク１１におけるスタートアップフォルダにインストールされる。従って、ユーザ端末１に主電源が投入されると、ツールバープログラム１９が自動的に起動されて、図１２に示すようなツールバーをディスプレイ１６上の片隅に表示するとともに、ユーザ端末１がシャットオフされるまで実行され続ける。なお、負荷テストツールバープログラム１８は、テスト管理者により随時アップデートされ、最新のアップデートを反映したアップデート用モジュール３３は、インターネットＮを通じてテスト管理サーバ１からダウンロード可能となっている。そして、ダウンロードされたアップデート用モジュール３３により、ユーザ端末１のハードディスク１１にインスト
ールされた負荷テストツールバープログラム１８が更新されることにより、ユーザ端末１上においても、負荷テストツールバープログラム１８のアップデートが完遂されるのである。
【００２０】
また、ディスプレイ１６は、ＣＰＵ１０による処理結果である画面を表示する。
【００２１】
また、入力装置１７は、操作者によって操作されることにより、ＣＰＵ１０に対して各種コマンドを入力する装置であり、具体的には、キーボードや、マウス，タッチパネル等のポインティングデバイスである。
【００２２】
以上により、ユーザ端末１は、宛先情報及びテスト実行期間を指定したスケジュール情報を受信すると当該スケジュール情報により指定されたテスト実行期間に当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する端末に、相当する。
【００２３】
テスト対象装置２は、ウェブサービスの提供者によって運用されるウェブサーバ装置であり、運用後においては、何れかの端末１から送信されてきたＨＴＴＰリクエストメッセージに応じて、当該ＨＴＴＰリクエストメッセージの内容に応じた各種処理を実行して、その実行結果をメッセージ送信元端末１に応答する。従って、テスト対象装置２は、互いにバスＢによって接続されたＣＰＵ２０，通信装置２４，ＲＡＭ２５及びハードディスク２１を、ハードウェア構成として有している。
【００２４】
これらのうち、ＣＰＵ２０は、当該テスト対象装置２全体の制御を行う中央処理装置（コンピュータ）である。また、ＲＡＭ２５は、ＣＰＵ２０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。また、通信装置２４は、インターネットＮとのインタフェースである。
【００２５】
ハードディスク２１は、ＣＰＵ２０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。
【００２６】
このハードディスク２１が格納してＣＰＵ２０によってＲＡＭ２５上に読み出される各種プログラムには、上述した各種処理を実行するためのプログラム（ＷＷＷサーバプログラム，及び、幾つかのＣＧＩプログラムないしサーブレット及びバーチャルマシン等のアプリケーションプログラム）が、含まれている。これらプログラムのうち、負荷テスト対象のサービスを提供するためのプログラムがテスト対象システムプログラム２２であり、当該テスト対象システムプログラム２２を実行しているテスト対象装置２が「テスト対象システム（２，２２）」である。さらに、ハードディスク２１に格納されている各種プログラムには、負荷テストの実行結果を記録するための負荷受付システムプログラム２３が含まれている。当該負荷受付システムプログラム２３を実行しているテスト対象装置２が「負荷受付システム（２，２３）」である。
【００２７】
テスト管理サーバ３は、テスト対象装置２の運用者に対して負荷テストの代行サービスを提供する業者（以下、「テスト管理者」という）によって運用される負荷テスト管理装置としてのウェブサーバ装置である。従って、テスト管理サーバ３は、互いにバスＢによって接続されたＣＰＵ３０，通信装置３４，ＲＡＭ３５及びハードディスク３１を、ハードウェア構成として有している。
【００２８】
これらのうち、ＣＰＵ３０は、当該テスト管理サーバ３全体の制御を行う中央処理装置（コンピュータ）である。また、ＲＡＭ３５は、ＣＰＵ５０が各種処理を実行するに際しての作業領域が展開される主記憶装置である。また、通信装置３４は、インターネットＮ
とのインタフェースである。
【００２９】
ハードディスク３１は、ＣＰＵ３０によって読み出されて実行される各種プログラム及び各種データを格納している記憶装置である。
【００３０】
ハードディスク３１が格納してＣＰＵ３０によってＲＡＭ３２上に読み出されて実行される各種プログラムには、上述した負荷テストの代行サービスを実行するためのプログラム（ｗｗｗサーバプログラム、及び、幾つかのＣＧＩプログラムないしサーブレット及びバーチャルマシン等のアプリケーションプログラムからなる負荷管理システムプログラム３６）が、含まれている。当該負荷管理システムプログラム３６を実行しているテスト管理サーバ３が、「負荷管理システム（３，３６）」である。また、ハードディスク３１が可能している各種データには、テスト負荷登録データベース３７，テスト登録者管理データベース３８，及び、ユーザデータベース３９が、含まれている。
【００３１】
図２に示すように、ユーザデータベース３９は、当該テスト管理サーバ３の運用者との間で負荷テストの協力者として登録された各ユーザ毎にその個人情報を登録するレコードを有しており、各レコードは、夫々、一意のユーザＩＤ，本名を示す氏名，現在のセッションにおいて用いられたクッキー，ＩＰアドレス（固定アドレス又はレンタルアドレス），及び、インセンティブの給付先に関する情報（例えば、クレジットカード番号，景品交換用若しくは商品割引用のポイント，等）を夫々格納する各フィールドから、構成されている。なお、或るユーザに付与されたクッキー又はＩＰアドレスが更新されると、当該ユーザに対応したレコードにおけるクッキー及びＩＰアドレスが、夫々、最新のものに上書きされて更新される。
【００３２】
図３に示すように、テスト負荷登録データベース３７は、テスト対象装置２の運用者によりテスト管理者に対して管理依頼された負荷テスト毎にその詳細情報を登録するレコードを有しており、各レコードは、夫々、負荷テストを一意に識別するための識別情報である「テストＩＤ」，負荷テストにおいてテスト対象システム（２，２２）に対して掛けるべき「負荷（単位：ｑｐｓ［秒当りのクエリー数］）」，当該負荷テストのためにユーザ端末１がリクエストメッセージを送信すべきテスト対象システム（２，２２）の宛先情報である「ＵＲＬ」，負荷テストが実行される「テスト実行期間」，テスト協力者に対して当該テストへの参加を募集する「受付期間」，及び，当該負荷テストの実行に必要なユーザ（登録者）数の範囲を示す「登録者数レンジ」を夫々格納する各フィールドから、構成されている。従って、当該テスト負荷登録データベース３７が、各負荷テストにつきその識別情報，リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースに、相当する。
【００３３】
なお、テスト対象装置２の運用者のテスト管理者に対する負荷テストの請負契約の申込みは、オンライン又はオフラインでなされる。このようにして負荷テストの請負契約の申込みを行ったテスト対象装置２の運用者を、「テスト依頼者」という。この申込みに際して、テスト依頼者は、上述した情報のうちＵＲＬ，負荷の値，及びテスト実行期間を特定して、テスト代行者に対して通知する。他方、テストＩＤ，受付期間及び登録者数レンジについては、負荷管理システム（３，３６）が自働生成する。
【００３４】
図４に示すように、テスト登録者管理データベース３８は、テスト管理システム（３，３６）が実行する負荷テスト，及び、各テストに参加することが正式に若しくは補欠として認められた各ユーザ（テスト登録者）の組合せに対応したレコードを有しており、各レコードは、夫々、負荷テストの識別情報である「テストＩＤ」，「負荷」，及び「テスト実行期間」，テスト登録者の個人識別情報である「ユーザＩＤ」，並びに、正式に登録を認められたか補欠であるかの「種別」を夫々格納する各フィールドから、構成されている
。従って、当該テスト登録者管理データベース３８が、参加申込情報を送信した端末に対応した個人識別情報及び同参加申込情報に含まれる負荷テストの識別情報が相互に対応付けて登録された第２データベースに、相当する。
【００３５】
さらに、テスト管理者が負荷テストツールバープログラム１８のアップデートを行った場合には、当該アップデートをユーザ端末１上の負荷テストツールバープログラム１８に反映させるためのアップデート用モジュール３３が、テスト管理者によって、ハードディスク３１に格納され、ユーザ端末１によるダウンロード要求に備えられる。
＜処理フロー＞
以下、負荷テストの実行に関して各装置１，２，３が夫々プログラム（負荷テストツールバープログラム１８，テスト対象システムプログラム２２，負荷受付システムプログラム２３，負荷管理システムプログラム３６）に従って実行する処理を、図５乃至図１０のフローチャートに従って説明する。
［負荷テスト登録時の処理］
図５は、テスト依頼者とテスト管理者との間で個々の負荷テストの代行についての契約（請負契約）が締結された後に負荷管理システム（３，３６）が実行する当該負荷テストのテスト負荷登録データベース３７への登録処理を示すフローチャートである。
【００３６】
この処理を開始して最初のＳ００１では、負荷管理システム（３，３６）は、テスト依頼者から指定された（入力された，若しくは、受信した）登録対象負荷テストにおけるＵＲＬ及び負荷の値に基づき、必要な登録者数のレンジを決定する。具体的には、負荷管理システム（３，３６）は、上記ＵＲＬに基づいて、負荷テストにおいて実行される処理タイプを（ア）閲覧系，（イ）検索系，（ウ）登録系の何れかに分類する。そして、負荷管理システム（３，３６）は、分類された処理タイプ毎に登録者一人当たりの負荷の下限値及び上限値を決定する。即ち、処理タイプが閲覧系であれば下限値を１ｑｐｓ，上限値を５ｑｐｓと決定し、処理タイプが検索系であれば下限値を１ｑｐｓ，上限値を３ｑｐｓと決定し、処理タイプが登録系であれば下限値を１ｑｐｓ，上限値を２ｑｐｓと決定する。このように処理タイプに依り登録者一人当たりの負荷の範囲を相違させるのは、通信負荷（ｑｐｓ）が同じであっても、処理タイプの相違に依って処理負荷に相違があることに拠る。その上で、負荷管理システム（３，３６）は、テスト依頼者から指定された負荷の値を上記登録者一人当たりの負荷の下限値及び上限値により夫々除することにより、必要な登録者数の上限値及び下限値を決定するのである。例えば、指定された負荷の値が５０ｑｐｓであり、指定されたＵＲＬが検索系であった場合、必要な登録者数の下限値は１７人であり上限値は５０人となるので、必要な登録者数レンジは、１７〜５０人と決定される。
【００３７】
次のＳ００２では、負荷管理システム（３，３６）は、登録対象負荷テストの受付期間を決定する。具体的には、テスト依頼者から受け取った（入力された，若しくは、受信した）テスト実行期間に先立つ所定期間を、受付期間として決定する。
【００３８】
次のＳ００３では、負荷管理システム（３，３６）は、登録対象負荷テストのテストＩＤを生成した上で、テスト依頼者から受け取った（入力された，若しくは、受信した）登録対象負荷テストにおける負荷の値，ＵＲＬ，テスト実行期間，並びに、Ｓ００１にて決定した登録者数レンジ，Ｓ００２にて決定した受け付け期間を格納した新規レコードを、テスト負荷登録データベース３７に追加する。Ｓ００３を完了すると、負荷管理システム（３，３６）は、当該負荷テスト登録時の処理を、全て終了する。
［負荷テストへのユーザの参加登録時の処理］
次に、図６及び図７に示す負荷テストツールバープログラム１８に基づくユーザ端末１の処理フローチャートの一部，並びに、図８及び図９に示す負荷管理システム（３，３６）の処理フローチャートに基づいて、負荷テストへの協力者（参加者）を公募し、応募し
てきたユーザを登録者としてテスト登録者管理データベース３８に登録するための処理を、説明する。
【００３９】
図６及び図７に示すように、ツールバープログラム１９を実行しているユーザ端末１（ＣＰＵ１０）は、Ｓ１０１〜Ｓ１０５のループ処理を繰り返し実行する。即ち、ユーザ端末１は、Ｓ１０１においてテスト管理サーバ（負荷管理システム）３にアクセスして、新規の情報を要求するＨＴＴＰリクエストメッセージ（情報要求メッセージ）を送信する。そして、ユーザ端末１は、Ｓ１０２において、テスト管理サーバ（負荷管理システム）３からアップデート案内情報を受信したか否かをチェックし、受信していなければ、Ｓ１０３において、テスト管理サーバ（負荷管理システム）３から負荷テストの告知情報を受信したか否かをチェックし、受信していなければ、Ｓ１０４において、テスト管理サーバ（負荷管理システム）３から最終確認情報を受信したか否かをチェックし、受信していなければ、Ｓ１０５において、テスト管理サーバ（負荷管理システム）３から起動確認要求を受信したか否かをチェックする。
【００４０】
他方、ユーザ端末１からアクセスされて新規情報要求のＨＴＴＰリクエストメッセージを受信する毎に、テスト管理サーバ（負荷管理システム）３は、図８及び図９の処理を実行する。そして、テスト管理サーバ（負荷管理システム）３は、スタート後最初のＳ２０１において、ハードディスク３１にアップデートモジュール３３が存在しているかどうかをチェックする。そして、テスト管理サーバ（負荷管理システム）３は、ハードディスク３１にアップデートモジュール３３が存在していなければ、処理を直ちにＳ２０５へ進める。これに対して、アップデートモジュール３３が存在している場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０２において、アップデート案内情報を格納したレスポンスメッセージを、アクセス元ユーザ端末１へ応答する。その後、テスト管理サーバ（負荷管理システム）３は、Ｓ２０３において、アクセス元ユーザ端末１が、所定時間内にアップデート要求のＨＴＴＰリクエストメッセージ（Ｓ１０７）を送信して来るのを、待つ。
【００４１】
図６のＳ１０２において、テスト管理サーバ（負荷管理システム）３からアップデート案内情報（Ｓ２０２）を受信したと判断した場合には、ユーザ端末１は、処理をＳ１０６へ進める。Ｓ１０６では、ユーザ端末１は、ディスプレイ１６上に図１３に示すアップデート許可画面を表示して、入力装置１７を用いたユーザによる入力内容をチェックする。即ち、当該アップデート許可画面には、アップデートの許可に対応した「ＹＥＳ」ボタン４１と「ＮＯ」ボタン４２とが含まれている。ユーザ端末１は、「ＹＥＳ」ボタン４１が入力装置１７（ポインティングデバイス）によりクリックされた場合には、アップデートが許可されたと認識して、処理をＳ１０７へ進め、「ＮＯ」ボタン４２がクリックされた場合には、アップデートが拒絶されたと判断して、処理をＳ１０８へ進める。Ｓ１０７では、ユーザ端末１は、テスト管理サーバ（負荷管理システム）３に対してアップデート要求のＨＴＴＰリクエストメッセージを送信する。
【００４２】
図８のＳ２０３において、アクセス元ユーザ端末１からのアップデート要求のＨＴＴＰリクエストメッセージ（Ｓ１０７）を受信したと判断した場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０４において、ハードディスク３１内のアップデート用モジュール３３を格納したレスポンスメッセージを、アクセス元ユーザ端末１へ応答する。Ｓ２０４の完了後、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０５へ進める。
【００４３】
これに対して、アップデートが拒絶された場合には、ユーザ端末１は、図６のＳ１０８において、Ｓ１０１の場合と同様にサーバにアクセスし、Ｓ１０９において、Ｓ１０２の場合と同様にアップデート案内情報（Ｓ２０２）を受信したか否かを、チェックする。そ
して、ユーザ端末は、新たなアップデート案内情報を受信しない限り、処理をＳ１０８に戻す。これは、最新のツールバー１８を用いたテスト参加のみを許容する趣旨である。そして、新たなアップデート案内情報を受信すると（Ｓ１０９：Ｙｅｓ）、ユーザ端末１は、処理をＳ１０６に戻し、新たなアップデートを許可するか否かのチェックを行う。
【００４４】
上述のようにしてアップデートが拒絶された場合には、ユーザ端末１からテスト管理サーバ（負荷管理システム）３へアップデート要求（Ｓ１０７）は送信されない。従って、テスト管理サーバ（負荷管理システム）３は、Ｓ２０３において、アップデート要求のＨＴＴＰリクエストメッセージが所定時間受信されないことをもって、処理をタイムアウト終了させる。
【００４５】
図８のＳ２０５では、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース７を参照して、受付期間に入った負荷テストが存在するか否かをチェックする。そして、未だ受付期間に入った負荷テストが存在しなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１５へ進める。これに対して、受付期間に入った負荷テストが一つ以上存在する場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２０６において、現在受付期間に入っている全負荷テストについて、負荷テスト告知情報を生成し、アクセス元ユーザ端末１へ送信する。即ち、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース３７を参照し、現在時刻が受付期間に含まれている全レコードを読み出し、読み出した全レコード中の「テストＩＤ」フィールド，「テスト実行期間」フィールド，及び「受付期間」フィールドの値を格納したレスポンスメッセージを、テスト実行期間に先立って、アクセス元ユーザ端末１へ応答する。Ｓ２０６を完了すると、テスト管理サーバ（負荷管理システム）３は、Ｓ２０７において、ユーザ端末１から参加申込みのＨＴＴＰリクエストメッセージ（Ｓ１１１）が送信されて来るのを待つ。
【００４６】
図６のＳ１０３において、テスト管理サーバ（負荷管理システム）３から負荷テスト告知情報（Ｓ２０６）を受信したと判断した場合には、ユーザ端末１は、処理をＳ１１０へ進める。Ｓ１１０では、ユーザ端末１は、受信した負荷テスト告知情報に基づいて、ディスプレイ１６上に、図１４に示す負荷テストエントリ画面を表示する。この負荷テストエントリ画面には、各負荷テストに行を対応させ、「テスト」フィールドの値，「受付期間」フィールドの値，「テスト実行期間」フィールドの値，エントリ用のチェックボックス，及び「種別」（但し、当該処理の実行時点では空欄）に各列を夫々対応させた表４３と「ＯＫ」ボタン４４とが、含まれている。即ち、ユーザ端末１は、告知情報に含まれる各負荷テストのテスト実行期間をユーザに提示する。そして、ユーザ端末１は、ユーザが入力装置１７（ポインティングデバイス）を用いて何れかの負荷テストに対応したチェックボックスにチェックを付した状態で「ＯＫ」ボタン４４をクリックすると、ユーザが何れかの負荷テストに参加する意思であるとして、処理をＳ１１１へ進める。これに対して、何れのチェックボックスにもチェックが付されていない状態で「ＯＫ」ボタン４４がクリックされた場合，若しく、何ら入力がないまま一定時間が経過した場合には、ユーザ端末１は、ユーザが何れの負荷テストにも参加する意思がないとして、処理をＳ１０４へ進める。
【００４７】
Ｓ１１１では、ユーザ端末１は、チェックが付された全チェックボックスに対応した各負荷テストのテストＩＤを格納した参加申込メッセージを、テスト管理サーバ（負荷管理システム）３へ送信する。即ち、ユーザ端末１は、ユーザが入力装置１７を用いて特定した負荷テストの識別情報を含む参加申込情報をテスト管理サーバ（負荷管理システム）３へ送信する。その後、ユーザ端末１は、Ｓ１１２において、テスト管理サーバ（負荷管理システム）３からの応答メッセージ（Ｓ２１４）を待つ。
【００４８】
図８のＳ２０７において、一定時間以上ユーザ端末１からの参加申込メッセージ（Ｓ１１１）が受信されない場合には、テスト管理サーバ（負荷管理システム）３は、タイムアウトにより、処理をＳ２１５へ進める。これに対して、一定時間内にユーザ端末１からの参加申込メッセージ（Ｓ１１１）を受信すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０７からＳ２０８へ進める。
【００４９】
Ｓ２０８では、テスト管理サーバ（負荷管理システム）３は、参加申込メッセージ（Ｓ１１１）に含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、アクセス元ユーザ端末１を操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、Ｓ２０７にて受信した参加申込みメッセージに含まれる各テストＩＤ毎に、当該テストＩＤ，上記ユーザＩＤ，当該テストＩＤに基づきテスト負荷登録データベース３７から読み出したテスト実行期間を含む新規レコード（但し、この処理時点では「種別」フィールド，及び「負荷」フィールドは空欄である）を、テスト登録者管理データベース３８に格納する。
【００５０】
次のＳ２０９では、テスト管理サーバ（負荷管理システム）３は、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤのうちの一つを特定する。
【００５１】
次のＳ２１０では、テスト管理サーバ（負荷管理システム）３は、Ｓ２０９にて特定したテストＩＤを含む全レコード数（登録者数）が、当該テストＩＤについてテスト負荷登録データベース３７に登録されている登録者数レンジの上限を超えたか否かをチェックする。そして、未だ前者が後者を超えていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１１において、当該テストＩＤを含む新規レコード中の「種別」フィールドに、“正式”なる値を登録する。これに対して、登録者数が上限を超えた場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１２において、当該テストＩＤを含む新規レコード中の「種別」フィールドに、“補欠”なる値を登録する。Ｓ２１１又はＳ２１２を完了すると、テスト管理サーバ（負荷管理システム）３は、Ｓ２１３において、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了したかどうかをチェックする。そして、未だ全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了していない場合には、テスト管理サーバ（負荷管理システム）３は、処理をＳ２０９へ戻す。これに対して、既に全新規レコード中のテストＩＤについてＳ２１０〜Ｓ２１２の処理を終了した場合には、Ｓ２１４にて、Ｓ２０８にてテスト登録者管理データベース３８に登録した全新規レコード中のテストＩＤ毎に、Ｓ２１１又はＳ２１２にて登録した「種別」フィールドの値を格納した受付応答メッセージを、アクセス元ユーザ端末１へ応答する。Ｓ２１４を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１５へ進める。
【００５２】
図６のＳ１１２において、テスト管理サーバ（負荷管理システム）３からの受付応答メッセージ（Ｓ２１４）を受信すると、ユーザ端末１は、Ｓ１１３において、Ｓ１１２にて受信した応答メッセージに含まれる各テストＩＤについての「種別」の値を、負荷エントリ画面（図１４）中の表４３における「種別」欄に、夫々、表示する。Ｓ１１３を完了すると、ユーザ端末１は、処理をＳ０１４へ進める。
【００５３】
図９のＳ２１５では、テスト管理サーバ（負荷管理システム）３は、情報要求メッセージ（Ｓ１１１）に含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、アクセス元ユーザ端末１を操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、読み出したユーザＩＤに対応した全テストＩＤを、テスト登録者管理データベース３８から読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト負荷登録データベース３７を参照して、読
み出した全テストＩＤに対応した負荷テストのうちに、受付期間を満了した負荷テストが存在するか否かを、チェックする。そして、テスト管理サーバ（負荷管理システム）３は、受付期間を満了した負荷テストが存在しなければ全処理を終了するが、受付期間を満了した負荷テストが一つ以上存在する場合には処理をＳ２１６へ進める。
【００５４】
Ｓ２１６では、テスト管理サーバ（負荷管理システム）３は、Ｓ２１５にて受付期間を満了したと判定した負荷テストに対応した全テストＩＤのうちの一つを特定する。
【００５５】
次のＳ２１７では、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照して、Ｓ２１６にて特定されたテストＩＤを含む全レコード数（登録者数）が当該テストＩＤについてテスト負荷登録データベース３７に登録されている登録者数レンジの下限を満たしているか否かを、チェックする。そして、前者が後者を満たしていれば、テスト管理サーバ（負荷管理システム）３は、Ｓ２１８において、ツールバーの起動時間の最終確認情報，即ち、Ｓ２１６にて特定されたテストＩＤについてテスト負荷登録データベース３７に登録されているテスト実行期間を指定した最終確認情報を、アクセス元ユーザ端末１へ送信する。これに対して、前者が後者を満たしていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ２１９において、負荷テスト中止を通告する最終確認情報を、アクセス元ユーザ端末１へ送信する。Ｓ２１８又はＳ２１９を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ２２０へ進める。
【００５６】
Ｓ２２０では、テスト管理サーバ（負荷管理システム）３は、Ｓ２１５にて受付期間を満了したと判定した負荷テストに対応した全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了したか否かを、チェックする。そして、未だ全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了していなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ２１６に戻す。これに対して、全テストＩＤについてＳ２１６乃至Ｓ２１９の処理を完了した場合には、テスト管理サーバ（負荷管理システム）３は、全処理を終了する。
【００５７】
図６のＳ１０４において、何れかの最終確認情報（Ｓ２１８，Ｓ２１９）を受信すると、ユーザ端末１は、Ｓ１１４において、受信した最終確認情報の内容（負荷テスト中止の旨及びツールバーの起動時間）を、ツールバー上に表示する。Ｓ１１４を完了すると、ユーザ端末１は、処理をＳ１０５へ進める。
［負荷テスト実行時の処理］
次に、図７に示す負荷テストツールバープログラム１８に基づくユーザ端末１の処理フローチャートの残部，図１０に示す負荷管理システム（３，３６）の処理フローチャート，並びに、図１１に示す負荷受付システム（２，２３）に基づいて、負荷テストを実行するための処理を、説明する。
【００５８】
図１０の処理は、例えば１時間毎というように、周期的に割込みスタートする。そして、スタート後最初のＳ３０１において、テスト負荷登録データベース３７を参照して、現在実行期間に入っている負荷テストが存在するか否かをチェックする。そして、未だ実行期間に入ったテストがなければ、テスト管理サーバ（負荷管理システム）３は、全処理を終了する。これに対して、実行期間に入ったテストが存在する場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ３０２において、所定の一定期間（例えば１０秒）内に情報要求メッセージ（Ｓ１０１）を送信してきた各ユーザ端末１について、情報要求メッセージに含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照し、読み出したユーザＩＤを含むとともに、「種別」の値が“正式”であり、且つ現在テスト実行期間に入っているレコードが存在していれば、アクセス元ユーザ端末１へ起動確認要求メッセージを送
信する。
【００５９】
図７のＳ１０５において起動確認要求メッセージ（Ｓ３０２）を受信したと判断した場合には、ユーザ端末１は、Ｓ１１５において、応答メッセージを、テスト管理サーバ（負荷管理システム）３へ送信する。その後、ユーザ端末１は、Ｓ１１６において、テスト管理サーバ（負荷管理システム）３からテストスケジュールファイル（Ｓ３０５）を受信するのを待つ。
【００６０】
図１０の３０３において、テスト管理サーバ（負荷管理システム）３は、Ｓ３０２又はＳ３０４の完了後所定の一定時間（例えば１秒）内に受信した応答メッセージの累計数が、Ｓ３０１にて実行期間に入ったと判断した負荷テストについてテスト負荷登録データベース３７に登録されている登録者数レンジを満たしているか否かをチェックする。そして、未だ前者が後者を満たしていない場合には、テスト管理サーバ（負荷管理システム）３は、Ｓ３０４において、所定の一定期間（例えば１秒）内に情報要求メッセージ（Ｓ１０１）を送信してきた各ユーザ端末１について、情報要求メッセージに含まれるクッキー又は送信元ＩＰアドレスに基づいてユーザデータベース３９を検索して、操作しているユーザのユーザＩＤを読み出す。そして、テスト管理サーバ（負荷管理システム）３は、テスト登録者管理データベース３８を参照し、読み出したユーザＩＤを含むとともに、「種別」の値が“補欠”であり、且つ現在テスト実行期間に入っているレコードが存在していれば、アクセス元ユーザ端末１へ接続確認要求を送信する。Ｓ３０４を完了すると、テスト管理サーバ（負荷管理システム）３は、処理をＳ３０３へ戻す。
【００６１】
以上のＳ３０３及びＳ３０４の処理を繰り返した結果、受信した応答メッセージの累計数が必要なレンジを満たしたと判断した場合（Ｓ３０３：Ｙｅｓ）、テスト管理サーバ（負荷管理システム）３は、Ｓ３０５において、当該負荷テストにつきテスト負荷登録データベース３７に登録された負荷の値を満たすことができるように、Ｓ３０３にて応答が受信された全ての登録者に対して極力均等に負荷を分配して、分配された各登録者別の負荷の値をテスト登録者管理データベース３８に登録する。
【００６２】
具体的には、テスト管理サーバ（負荷管理システム）３は、当該負荷テストにつきテスト負荷登録データベース３７に登録されている負荷の値を登録者数レンジの最大値にて除することにより、当該負荷テストの処理タイプに応じた一人当たりの負荷の下限を算出し、算出された負荷を、Ｓ３０３にて応答が受信された全ての登録者に割り当てる。次に、当該割当の結果としてテスト負荷登録データベース３７に登録された負荷の値に余剰を生じた場合には、所定の順番（例えば、Ｓ３０３にて応答が受信された順番）に従って、各登録者に対して、余剰の負荷から所定単位づつ負荷の値を割り当てる。当該余剰負荷の割当は、剰余の負荷が無くなるまで行われる。
【００６３】
例えば、テスト負荷登録データベース３７に登録された負荷の値が“５０ｑｐｓ”であり、登録者数レンジが“１７〜５０人”である場合、当該負荷テストの処理種別に応じた一人当たりの負荷の下限は“１ｑｐｓ”となる。従って、剰余の負荷の割当単位を“１ｑｐｓ”とした場合、Ｓ３０３にて応答が受信された登録者数が“５０人”であれば剰余負荷を生じないが、当該登録者数が“４０人”なら“１０ｑｐｓ”の剰余負荷を生じるので、１〜１０番目登録者に計“２ｑｐｓ”が割り当てられ、他の３０名の登録者には“１ｑｐｓ”のみが割り当てられる。また、登録者数が“２５人”なら“２５ｑｐｓ”の剰余負荷を生じるので、全員に計“２ｑｐｓ”が割当てられる。また、当該登録者数が“２０人”なら“３０ｑｐｓ”の剰余負荷を生じるので、その全員に“１ｑｐｓ”づつ剰余負荷を割り当てても未だ“１０ｑｐｓ”余り、よって、１〜１０番目登録者に対しては２周目の剰余負荷の割当がなされ、結局、１〜１０番目登録者に計“３ｑｐｓ”が割り当てられ、他の１０名の登録者には“２ｑｐｓ”が割り当てられる。
【００６４】
以上の負荷の割当及び登録を行った上で、テスト管理サーバ（負荷管理システム）３は、各登録者が操作するユーザ端末１から受信した応答メッセージ（Ｓ１１５）に対するレスポンスとして、各登録者に割り当てられた負荷の値，テスト実行期間，テスト対象システム（２，２２）のＵＲＬ，並びにテストＩＤ及び当該登録者のユーザＩＤが記述されたテストスケジュールファイル（図１５参照）を生成し、これを暗号化して、各登録者が操作するユーザ端末１に個別に送信する。即ち、テスト管理サーバ（負荷管理システム）３は、第１データベースを参照し、参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、ユーザ端末１へ送信する。
【００６５】
Ｓ３０５を完了すると、テスト管理サーバ（負荷管理システム）３は、全処理を完了する。
【００６６】
図７のＳ１１６においてテストスケジュールファイル（Ｓ３０５）を受信したユーザ端末１は、Ｓ１１７において、Ｓ１１６にて受信したテストスケジュールファイルを復号化する。なお、テストスケジュールファイルは、最新版のツールバープログラムによってのみ復号化できるように暗号化されているので、これを受信したユーザ端末１の操作者は、テスト対象システム（２，２２）のＵＲＬを盗み見ることができない。よって、公開前のテスト対象システム（２，２２）のＵＲＬの秘匿性が維持される。
【００６７】
次のＳ１１８では、テスト管理サーバ（負荷管理システム）３は、テストスケジュールファイル中で指定された負荷（ｑｐｓ）に応じた頻度にて、同ファイル中で指定されたＵＲＬに対してＨＴＴＰリクエストメッセージを送信し続ける。次のＳ１１９では、テスト管理サーバ（負荷管理システム）３は、Ｓ１１６にて受信したテストスケジュールファイル中で指定されたテスト実行期間が満了したか否かをチェックする。そして、未だテスト実行期間が満了していなければ、テスト管理サーバ（負荷管理システム）３は、処理をＳ１１８へ戻す。これに対して、テスト実行期間が満了した場合，若しくは、入力装置１７を用いたユーザによる操作により負荷テストが強制終了された場合、テスト管理サーバ（負荷管理システム）３は、処理をＳ１２０へ進める。Ｓ１２０では、テスト管理サーバ（負荷管理システム）３は、テスト対象装置２からのインセンティブ通知（Ｓ４０５）を待つ。
【００６８】
テスト対象装置２は、テスト対象システム（２，２２）として、図１１のＳ４０１において、ユーザ端末１から負荷テストの為のＨＴＴＰリクエストメッセージ（Ｓ１１８）を受信したか否かをチェックし、何らメッセージを受信していないと、処理をそのままＳ４０３へ進め、メッセージを受信していると、Ｓ４０２において、当該メッセージによりリクエストされた処理を実行するとともに受信ログを録った後に、処理をＳ４０３へ進める。
【００６９】
Ｓ４０３では、テスト対象装置２は、負荷受付システム（２，２３）として、テスト対象システム（２，２２）に対する負荷テストのテスト実行期間が満了したか否かをチェックし、未だテスト実行期間が満了していなければ処理をＳ４０１に戻し、テスト実行期間が満了していれば、処理をＳ４０４へ進める。
【００７０】
Ｓ４０４では、テスト対象装置２は、負荷受付システム（２，２３）として、テスト管理サーバ３との間で通信を行い、テスト登録者管理データベース３８にアクセスする。そして、テスト対象装置２は、テスト登録者管理データベース３８の内容と受信ログとを照合する。
【００７１】
次のＳ４０５では、テスト対象装置２は、Ｓ４０４での照合の結果として、テスト登録者管理データベース３８において予定されていた通りの負荷を送信した登録者に対して、分配された負荷に応じたインセンティブが有る旨の通知を行い、予定されていた通りの負荷を送信しなかった登録者に対して、インセンティブ無しの通知を行う。同時に、テスト対象端末２は、同じ通知をテスト管理サーバ３に対しても行って、インセンティブ有りとした登録者に対するインセンティブの付与を依頼する。Ｓ４０５を完了すると、テスト対象装置２は、全処理を終了する。
【００７２】
図７のＳ１２０においてテスト対象装置２からインセンティブの通知（Ｓ４０５）を受信すると、ユーザ端末１は、Ｓ１２１において、Ｓ１２０にて受信したインセンティブの通知の内容（有り又は無し，及び、インセンティブが有る場合にはその内容）を、負荷テストツールバー上に表示する。Ｓ１２１を完了すると、ユーザ端末１は、処理をＳ１０１に戻す。
【００７３】
以上に説明したように、本実施形態によると、負荷テストツールバープログラム１８を自己の所有又は占有にかかるユーザ端末１上で実行させているとともにユーザデータベース３９に登録されているユーザであっても、自動的に負荷管理システム３６に登録されている全負荷テストに参加を強いられるのではなく、各負荷テストのテスト実行期間を予め認識した上で、これを考慮に容れて、各負荷テストへの参加を主体的に決定することができる（Ｓ１１１）。従って、各ユーザは、自己が参加する負荷テストの実行期間を知ることができるので、負荷テストの実行期間中に、確実に、自己のユーザ端末１及び負荷テストツールバープログラム１８を起動させておくことができる。これにより、実際のテスト実行期間内に必要な台数のユーザ端末１が負荷テストに参加する蓋然性が高まるので、負荷テストが不成立になる可能性が減少し、負荷テストの結果についても信頼性が高まる。
【００７４】
また、本実施形態によると、最新のアップデートがなされた負荷テストツールバープログラム１８のみによって負荷テストへの参加が可能になるので（Ｓ１０６〜Ｓ１０９）、負荷テストツールバープログラム１８の版数の相違に因る誤動作やテスト対象システム（２，２２）のＵＲＬの漏洩を、防止することができる。
【００７５】
また、本実施形態によると、テスト依頼者によって指定された個々の負荷テストに必要な負荷の総量及び処理種別に応じてテスト登録者数レンジが自動的に決定される（Ｓ００１）。そして、テスト参加希望者の総数が受付期間中にテスト登録者数レンジに至らなければ、負荷テストの結果に信頼性が置くことができないので、当該負荷テストは中止される（Ｓ２１９）。また、テスト参加に応募したユーザは先着順に正式に参加登録されるが、登録者の総数が受付期間中にテスト登録者数レンジの上限を超えると、各参加者に有意な量の負荷を分配することができなくなってしまう，若しくは、全参加者に有意な量の負荷を割り当てようとすると負荷総量が必要量を上回ってしまうので、正式な登録の受付は締め切られる（Ｓ２１０）。もっとも、正式に登録されたユーザがテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動するかどうかは、ユーザの良心に任されるので、必ずしも、正式に登録された全ユーザがテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動するとは限らず、実際に負荷テストに参加する登録者数がテスト登録者数レンジを下回ることもありえる。そのため、本実施形態では、正式な参加登録者の受付を締め切った後に参加申し込みをしたユーザは、補欠として登録され（Ｓ２１２）、正式に登録された全ユーザのうちテスト実行期間中にユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動した者の数がテスト登録者数レンジを下回った場合には、補欠の登録者が繰り上げられて（Ｓ３０４）、負荷テストに必要な数の参加者が確保されるのである（Ｓ３０３）。
【００７６】
このようにして各負荷テストの実行期間においてユーザ端末１に主電源を投入して負荷テストツールバープログラム１８を起動したことが確認されたユーザ（正式な登録者及び繰り上げられた補欠の登録者）に対しては、その人数に応じて、負荷が極力均等に分配される（Ｓ３０５）。その結果、様々な通信経路を経てテスト対象装置（テスト対象システム２，２２）へ送信されるＨＴＴＰリクエストメッセージの量が均等化されるので、特定の通信経路にのみ負荷が集中するという弊害が防止され、よって、実際の負荷の掛かり具合に近似した負荷テストを実施することが可能となる。
【符号の説明】
【００７７】
１ ユーザ端末
２ テスト対象装置
３ テスト管理サーバ
１０ ＣＰＵ
１１ ハードディスク
１４ 通信装置
１６ ディスプレイ
１７ 入力装置
１８ 負荷テストツールバープログラム
２０ ＣＰＵ
２１ ハードディスク
２２ テスト対象システム
２３ 負荷受付システム
２４ 通信装置
３０ ＣＰＵ
３１ ハードディスク
３４ 通信装置
３６ 負荷管理システム
３７ テスト負荷登録データベース
３８ テスト登録者管理データベース
３９ ユーザデータベース
【特許請求の範囲】
【請求項１】
ネットワークを通じて端末から受信したリクエストメッセージに応じて所定の処理を実行するウェブシステムに対して端末からリクエストメッセージを自動送信させることにより前記ウェブシステムの動作を試す負荷テストの、管理方法であって、
サーバが、各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を端末へ送信し、
前記負荷テストの告知情報を受信した端末が、当該告知情報に含まれる各負荷テストのテスト実行期間を操作者に提示し、当該負荷テストのうち当該操作者が入力装置を用いて特定した負荷テストの識別情報を含む参加申込情報を前記サーバへ送信し、
前記参加申込情報を受信した前記サーバが、前記第１データベースを参照し、前記参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、前記参加申込情報を送信した端末へ送信し、
前記スケジュール情報を受信した端末が、当該スケジュール情報により指定されたテスト実行期間に、当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する
ことを特徴とするウェブシステムに対する負荷テストの管理方法。
【請求項２】
前記テスト管理サーバは、各負荷テストにつき、前記第１データベースに登録されているテスト実行期間に先立って、前記負荷テストの告知情報を端末へ送信する
ことを特徴とする請求項１記載のウェブシステムに対する負荷テストの管理方法。
【請求項３】
前記参加申込情報を受信した前記テスト管理サーバは、当該参加申込情報を送信した端末に対応した個人識別情報，及び当該参加申込情報に含まれる負荷テストの識別情報を、相互に対応付けて第２データベースに登録し、前記第１データベースに登録されている各負荷テストの実行期間に至ると、前記第２データベースを参照し、当該負荷テストの識別情報に対応した個人識別情報に対応した端末へ、前記スケジュール情報を送信する
ことを特徴とする請求項２記載のウェブシステムに対する負荷テストの管理方法。
【請求項４】
ネットワークを通じて端末から受信したリクエストメッセージに応じて所定の処理を実行するウェブシステムに対して端末からリクエストメッセージを自動送信させることにより前記ウェブシステムの動作を試す負荷テストの、管理装置であって、
各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを記憶した記憶装置と、
ネットワークを通じて、宛先情報及びテスト実行期間を指定したスケジュール情報を受信すると当該スケジュール情報により指定されたテスト実行期間に当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する端末に接続された通信装置と、
前記第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を生成し、生成した負荷テストの告知情報を前記通信装置を通じて前記端末へ送信し、当該告知情報により告知された負荷テストのうち操作者によって特定された負荷テストの識別情報を含む参加申込情報を前記通信装置を通じて前記端末から受信すると、前記第１データベースを参照し、前記参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を前記通信装置を通じて前記端末へ送信する処理装置と
を備えたことを特徴とするウェブシステムに対する負荷テストの管理装置。
【請求項１】
ネットワークを通じて端末から受信したリクエストメッセージに応じて所定の処理を実行するウェブシステムに対して端末からリクエストメッセージを自動送信させることにより前記ウェブシステムの動作を試す負荷テストの、管理方法であって、
サーバが、各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を端末へ送信し、
前記負荷テストの告知情報を受信した端末が、当該告知情報に含まれる各負荷テストのテスト実行期間を操作者に提示し、当該負荷テストのうち当該操作者が入力装置を用いて特定した負荷テストの識別情報を含む参加申込情報を前記サーバへ送信し、
前記参加申込情報を受信した前記サーバが、前記第１データベースを参照し、前記参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を、前記参加申込情報を送信した端末へ送信し、
前記スケジュール情報を受信した端末が、当該スケジュール情報により指定されたテスト実行期間に、当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する
ことを特徴とするウェブシステムに対する負荷テストの管理方法。
【請求項２】
前記テスト管理サーバは、各負荷テストにつき、前記第１データベースに登録されているテスト実行期間に先立って、前記負荷テストの告知情報を端末へ送信する
ことを特徴とする請求項１記載のウェブシステムに対する負荷テストの管理方法。
【請求項３】
前記参加申込情報を受信した前記テスト管理サーバは、当該参加申込情報を送信した端末に対応した個人識別情報，及び当該参加申込情報に含まれる負荷テストの識別情報を、相互に対応付けて第２データベースに登録し、前記第１データベースに登録されている各負荷テストの実行期間に至ると、前記第２データベースを参照し、当該負荷テストの識別情報に対応した個人識別情報に対応した端末へ、前記スケジュール情報を送信する
ことを特徴とする請求項２記載のウェブシステムに対する負荷テストの管理方法。
【請求項４】
ネットワークを通じて端末から受信したリクエストメッセージに応じて所定の処理を実行するウェブシステムに対して端末からリクエストメッセージを自動送信させることにより前記ウェブシステムの動作を試す負荷テストの、管理装置であって、
各負荷テストにつきその識別情報，上記リクエストメッセージの宛先情報及びテスト実行期間が相互に対応付けて登録された第１データベースを記憶した記憶装置と、
ネットワークを通じて、宛先情報及びテスト実行期間を指定したスケジュール情報を受信すると当該スケジュール情報により指定されたテスト実行期間に当該スケジュール情報により指定された宛先情報を含むリクエストメッセージを送信する端末に接続された通信装置と、
前記第１データベースを参照し、テスト実行期間を提示した各負荷テストの告知情報を生成し、生成した負荷テストの告知情報を前記通信装置を通じて前記端末へ送信し、当該告知情報により告知された負荷テストのうち操作者によって特定された負荷テストの識別情報を含む参加申込情報を前記通信装置を通じて前記端末から受信すると、前記第１データベースを参照し、前記参加申込情報に含まれる負荷テストの識別情報に対応した宛先情報及びテスト実行期間を指定したスケジュール情報を前記通信装置を通じて前記端末へ送信する処理装置と
を備えたことを特徴とするウェブシステムに対する負荷テストの管理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−４８６６８（Ｐ２０１２−４８６６８Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１９２７８５（Ｐ２０１０−１９２７８５）
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（５９１１１７１９２）ニフティ株式会社 (144)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（５９１１１７１９２）ニフティ株式会社 (144)
【Ｆターム（参考）】
[ Back to top ]