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

Abstract

【課題】テストパラメータを調整する時間を短縮する。
【解決手段】負荷モデル作成部（１−１）は、認証サーバ装置（６０）におけるリクエストの受信履歴が、ＵＲＬとリクエストの受信時刻との対により示される認証システムリクエストログ（８）を入力し、認証システムリクエストログ（８）の各ＵＲＬを解析して各リクエストを複数のリクエスト種別のうちのいずれかに分類し、所定の単位時間ごとにリクエスト種別の単位で認証サーバ装置（６０）におけるリクエスト受信数を集計する。負荷パラメータ算出部（１−２）は、テストツール（負荷テストコントローラ（４）及び負荷テストエージェント（５））のリクエスト送信性能と、認証システムリクエストログ（８）の集計結果とに基づき、テストパラメータとして、各テストツールが認証サーバ装置（６０）に送信するリクエストの数とリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定する。
【選択図】図１

Description

本発明は、サーバ装置のテストを行う技術に関する。

従来、サーバ装置（例えば、認証サーバ装置）に対するテスト（例えば、負荷テスト）は、クライアント装置の動作をエミュレートする負荷テストツールを使用して実施する。
テスト要件にあった負荷をかけるために、従来技術では、負荷テストツールの外部からパラメータを与えて、さまざまな負荷テストを実施する（例えば、特許文献１、特許文献２）。
特許文献１では、外部からのパラメータを変化させることでコンピュータシステムにかける負荷を変化させることが示唆されている。
また、特許文献２では、負荷試験において、外部からの条件を入力することで計算機に対して過負荷状態を発生させることが示唆されている。

特開２００５−１８２８１３号公報 特開２００８−２３４４０７号公報

従来の負荷テスト方式では、認証サーバ装置へ送信するリクエスト数に関するパラメータや、リクエストの送信タイミングに関するパラメータを外部から負荷テストツールに与えてテストを行っている。
テスト要件にあった負荷テストを実施するためには、各種パラメータを調整する必要がある。
従来の負荷テスト方式では、テスト実施者の経験や過去の試験実績をもとに、幾度となくテストを繰り返して、適切なパラメータを導き出している。
大規模な負荷テストを実施する際には、実際の負荷を発生させる負荷テストエージェントが多数必要であり、また、負荷テストエージェントを制御する負荷テストコントローラも複数必要となる。
テスト実施者は、負荷テストコントローラごとにパラメータ調整を行うが、パラメータ調整の複雑度は、個々の負荷テストコントローラが制御する負荷テストエージェントの数に比例する（負荷テストエージェントの数、負荷テストコントローラが動作するＰＣ・サーバにより微調整が必要）。
このため、多数の負荷テストエージェント、複数の負荷テストコントローラを用いる大規模な負荷テストでは、パラメータ調整のために多大な時間が費やされる。

この発明は上記のような課題を解決することを主な目的としており、パラメータ調整のための時間を短縮することを目的とする。

本発明に係るテスト装置は、
それぞれがクライアント装置をエミュレートする複数のテストツールから複数のリクエストをテスト対象サーバ装置に送信させて、前記テスト対象サーバ装置のテストを行うテスト装置であって、
各テストツールのリクエスト送信性能が示される性能情報を記憶する性能情報記憶部と、
クライアント装置から複数のリクエストを受信する稼動中サーバ装置で収集され、前記稼動中サーバ装置におけるリクエストの受信履歴が、リクエストを分類するための識別子であるリクエスト分類識別子とリクエストの受信時刻との対により示されるログデータを入力するログデータ入力部と、
前記ログデータに示される各リクエスト分類識別子を解析して複数のリクエスト種別のうちのいずれかに分類し、所定の単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数を集計し、単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数が示されるログ集約データを生成するログ集約部と、
前記ログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、テストパラメータとして、各テストツールが前記テスト対象サーバ装置に送信するリクエストの数とリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定するテストパラメータ指定部とを有することを特徴とする。

本発明では、実際のリクエスト受信履歴に各テストツールのリクエスト送信性能を照合して、テストツールごとのテストパラメータを生成するため、現実のシステム環境に適合するテストパラメータを短時間で得ることができる。

実施の形態１に係る負荷テストコントロールシステムを含むシステム構成例を示す図。 実施の形態１に係るリクエスト種別情報の例を示す図。 実施の形態１に係る負荷モデル情報の例を示す図。 実施の形態１に係る負荷パラメータ情報の例を示す図。 実施の形態１に係るコントローラ情報の例を示す図。 実施の形態１に係るエージェント情報の例を示す図。 実施の形態１に係る負荷モデル生成処理の例を示すフローチャート図。 実施の形態１に係る負荷パラメータ生成処理の例を示すフローチャート図。 実施の形態１に係るテストサンプルの例を示す図。 実施の形態２に係る負荷分散定義テーブルの例を示す図。 実施の形態２に係る負荷モデル生成処理の例を示すフローチャート図。 実施の形態３に係る負荷テストコントロールシステムを含むシステム構成例を示す図。 実施の形態３に係るフィードバック調整ポリシー情報の例を示す図。 実施の形態３に係るフィードバック調整処理の例を示すフローチャート図。 実施の形態３に係るフィードバック調整処理の概要を示す図。 実施の形態５に係るフィードバック負荷モデル情報の例を示す図。 実施の形態５に係るフィードバック調整ポリシー情報の例を示す図。 実施の形態５に係る負荷モデル、試行結果、調整結果の関係例を示す図。 実施の形態１に係る認証システムリクエストログの例を示す図。 実施の形態１〜６に係るテスト装置のハードウェア構成例を示す図。

実施の形態１．
本実施の形態では、大規模な負荷テスト実施の際の負荷テストの調整のための時間を短縮する構成を説明する。

図１は、本実施の形態に係る負荷テストコントロールシステムを含むシステム構成例を示す。

負荷テストコントロールシステム（１）は、認証システム（６）内の認証サーバ装置（６０−１）、（６０−２）、（６０−３）のテストを行う。
認証サーバ装置（６０−１）、（６０−２）、（６０−３）は、それぞれテスト対象サーバ装置の例に相当する。
認証システム（６）は、業務システムＡ（７−１）、業務システムＢ（７−２）の認証・認可機能を統合している。
なお、認証サーバ装置（６０−１）、（６０−２）、（６０−３）のそれぞれを区別する必要がない場合は、単に認証サーバ装置（６０）と表記する。
各認証サーバ装置（６０）は、クライアント装置から複数種のＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを受信し、受信したＨＴＴＰリクエストに応じた処理を行う。
図１では、認証システム（６）を構成する認証サーバ装置（６０）は３台であるが、構成により、何台でもよい。
また、認証システム（６）を構成する要素として、認証するためのユーザ情報を管理する認証リポジトリ（６１）、複数の認証サーバ装置（６０）に対してＨＴＴＰリクエストの負荷分散を行う負荷分散装置（６２）も備えている。

負荷テストコントロールシステム（１）は、負荷テストコントローラ１（４−１）及び負荷テストコントローラ２（４−２）を有する。
負荷テストコントローラ１（４−１）は、負荷テストエージェント１（５−１）、負荷テストエージェント２（５−２）を制御する。
負荷テストコントローラ２（４−２）は、負荷テストエージェント３（５−３）、負荷テストエージェント４（５−４）を制御する。
負荷テストコントローラ１（４−１）、負荷テストコントローラ２（４−２）は一般的な負荷テストツールのうちテストをコントロールするコンポーネントであり、ここでは、２台であるが、必要に応じて増やすことは可能であり、上限はない。
負荷テストエージェント１（５−１）、負荷テストエージェント２（５−２）、負荷テストエージェント３（５−３）、負荷テストエージェント４（５−４）も負荷テストツールのうち、実際に認証システムにＨＴＴＰリクエストの負荷をかけるコンポーネントであり、ここでは、４台であるが、必要に応じて増やすことができる。
負荷テストコントローラ１（４−１）、負荷テストエージェント１（５−１）、負荷テストエージェント２（５−２）は、クライアント装置をエミュレートし、認証サーバ装置（６０）にＨＴＴＰリクエストを送信する。
負荷テストコントローラ１（４−１）、負荷テストエージェント１（５−１）、負荷テストエージェント２（５−２）で１つのテストツールを構成する。
同様に、負荷テストコントローラ２（４−２）、負荷テストエージェント３（５−３）、負荷テストエージェント４（５−４）も、クライアント装置をエミュレートし、認証サーバ装置（６０）にＨＴＴＰリクエストを送信する。
負荷テストコントローラ２（４−２）、負荷テストエージェント３（５−３）、負荷テストエージェント４（５−４）で１つのテストツールを構成する。
なお、負荷テストコントローラ１（４−１）及び負荷テストコントローラ２（４−２）を区別する必要がない場合は、単に負荷テストコントローラ（４）と表記する。
同様に、負荷テストエージェント１（５−１）、負荷テストエージェント２（５−２）、負荷テストエージェント３（５−３）、負荷テストエージェント４（５−４）を区別する必要がない場合は、単に、負荷テストエージェント（５）と表記する。

負荷テストコントロールシステム（１）において、負荷モデル作成部（１−１）は、認証システムリクエストログ（８）を入力する。
また、負荷モデル作成部（１−１）は、入力した認証システムリクエストログ（８）を加工して、負荷モデル情報（３−３）を生成する。
認証システムリクエストログ（８）は、認証システム（６）の各認証サーバ装置（６０）で収集されたログデータである。
認証システムリクエストログ（８）は、例えば、図１９に例示するデータであり、認証サーバ装置（６０）におけるＨＴＴＰリクエストの受信履歴がリクエスト受信時刻と各リクエストが対象とするＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）との対により示されている。
なお、図１９では、図示を省略しているが、認証システムリクエストログ（８）では、各行にＨＴＴＰリクエストの送信元のクライアント装置のアドレス情報や中継装置のアドレス情報が含まれていてもよい。
また、図１９で示している「認証画面」、「認証要求（Ｉ／Ｄパスワード）」、「ポータル画面」は説明のための記述であり、実際の認証システムリクエストログ（８）に記述されているものではない。
後述するリクエスト種別情報（３−１）（図２）に示されるように、認証システムリクエストログ（８）の各ＵＲＬは、ＨＴＴＰリクエストを分類するための識別子でもあり、リクエスト分類識別子の例に相当する。
負荷モデル作成部（１−１）は、認証システムリクエストログ（８）の受信履歴を所定の単位時間（例えば、５分）ごとにリクエスト種別の単位で集計し、単位時間ごとにリクエスト種別の単位で認証サーバ装置（６０）におけるリクエスト受信数が表される負荷モデル情報（３−３）を生成する。
生成された負荷モデル情報（３−３）は、負荷テスト制御情報ＤＢ（３）で保持される。
負荷モデル情報（３−３）は、図３に例示する情報である。
負荷モデル情報（３−３）の詳細は、後述する。
なお、認証システムリクエストログ（８）はログデータの例に相当し、負荷モデル情報（３−３）はログ集約データの例に相当する。
また、負荷モデル作成部（１−１）はログデータ入力部及びログ集約部の例に相当する。

なお、本実施の形態では、実際に稼働し、クライアント装置からＨＴＴＰリクエストを受信している認証サーバ装置（６０）に対して負荷テストを行う場合を想定している。
例えば、新たなソフトウェアがインストールされた認証サーバ装置（６０）が想定通りに動作するかを検証するために負荷テストを行う場合を想定している。
このため、本実施の形態では、認証サーバ装置（６０）から認証システムリクエストログ（８）を取得することとしている。
しかし、認証システムリクエストログ（８）の取得先は、テスト対象の認証サーバ装置（６０）でなくてもよい。
認証サーバ装置（６０）と同様の動作をする、稼動中の他のサーバ装置から認証システムリクエストログ（８）を取得するようにしてもよい。

負荷パラメータ算出部（１−２）は、負荷ツール情報ＤＢ（２）からコントローラ情報（２−１）及びエージェント情報（２−２）を取得し、更に、負荷テスト制御情報ＤＢ（３）から負荷モデル情報（３−３）を取得して、負荷テストのテストパラメータである負荷パラメータ情報（３−４）を生成する。
コントローラ情報（２−１）は、図５に例示する情報であり、エージェント情報（２−２）は、図６に例示する情報である。
コントローラ情報（２−１）及びエージェント情報（２−２）の詳細は後述するが、コントローラ情報（２−１）及びエージェント情報（２−２）は、テストツール（負荷テストコントローラ（４）、負荷テストエージェント（５））のＨＴＴＰリクエスト送信性能を示す情報であり、性能情報の例に相当する。
負荷パラメータ算出部（１−２）は、負荷モデル情報（３−３）に示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、コントローラ情報（２−１）及びエージェント情報（２−２）に示される各テストツールのリクエスト送信性能とに基づき、負荷パラメータ情報（３−４）を生成する。
負荷パラメータ情報（３−４）は、図４に例示する情報である。
負荷パラメータ情報（３−４）の詳細は後述するが、テストパラメータとして、各テストツールが認証サーバ装置（６０）に送信するＨＴＴＰリクエストの数とＨＴＴＰリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定する情報である。
生成された負荷パラメータ情報（３−４）は、負荷テスト制御情報ＤＢ（３）で保持される。
なお、負荷パラメータ算出部（１−２）はテストパラメータ指定部の例に相当する。

負荷テスト実行部（１−３）は、負荷パラメータ情報（３−４）に示されるパラメータに基づいて、負荷テストコントローラ（４）を制御して、認証サーバ装置（６０）に対する負荷テストを実行する。

負荷ツール情報ＤＢ（２）は、コントローラ情報（２−１）とエージェント情報（２−２）を記憶している。
負荷ツール情報ＤＢ（２）は、性能情報記憶部の例に相当する。

コントローラ情報（２−１）は、図５に例示する情報である。
コントローラ情報（２−１）では、１つのレコードに１台の負荷テストコントローラ（４）の情報が記述されている。
「負荷テストコントローラＮｏ」の欄には、負荷テストコントローラ（４）の識別番号が記述されている。
「コントローラホスト名」の欄には、負荷テストコントローラ（４）の名称が記述されている。
「エージェント台数」の欄には、負荷テストコントローラ（４）が使用できる負荷テストエージェント（５）の台数が記述されている。
また、「最大ユーザ実行数」の欄は、負荷テストコントローラ（４）が負荷テストエージェント（５）を用いて模擬できる最大のユーザ（クライアント装置）数が記述されている。
「最大ユーザ実行数」は、エージェント台数×１台あたりのユーザ実行数である。
１台あたりのユーザ実行数は、エージェントの動作するホストの性能による。
エージェント情報（２−２）は、図６に例示する情報である。
エージェント情報（２−２）でも、１つのレコードに１台の負荷テストエージェント（５）の情報が記述されている。
「負荷テストコントローラＮｏ」の欄には、負荷テストエージェント（５）を管理する負荷テストコントローラ（４）の識別番号が記述されている。
「ホスト名」の欄には、負荷テストエージェント（５）の名称が記述されている。
「マルチＩＰ」の欄には、負荷テストエージェント（５）が複数のユーザ（クライアント）を模擬することが可能か否かが記述されている。
「ＩＰ数」の欄には、負荷テストエージェント（５）が模擬できるユーザ（クライアント装置）数が記述されている。
換言すれば、「ＩＰ数」は、エージェントの動作するホストに割り当てたＩＰアドレスの数である。
「ＯＳ」の欄には、負荷テストエージェント（５）が利用するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の種別が記述されている。
「多重度」の欄には、負荷テストエージェント（５）が同時並行して模擬可能な１秒あたりのユーザ（クライアント装置）数が記述されている。
なお、本実施の形態では、１ユーザ（クライアント装置）につき所定数（例えば、２００個）のＨＴＴＰリクエストを送信することとしている。
このため、コントローラ情報（２−１）の「最大ユーザ実行数」及びエージェント情報（２−２）の「ＩＰ数」、「多重度」は、テストツールにおけるＨＴＴＰリクエストの送信性能を表している。
また、コントローラ情報（２−１）及びエージェント情報（２−２）は、負荷モデル作成部（１−１）が認証システムリクエストログ（８）を入力する前から負荷ツール情報ＤＢ（２）に存在している。

負荷テスト制御情報ＤＢ（３）は、リクエスト種別情報（３−１）、負荷要件情報（３−２）、負荷モデル情報（３−３）、負荷パラメータ情報（３−４）を記憶している。

リクエスト種別情報（３−１）は、図２に例示する情報であり、各ＵＲＬを含むＨＴＴＰリクエストがどのような目的のリクエストであるかを分類するための情報である。
「リクエスト種別」の欄には、ＵＲＬが関係しているアプリケーションの種類が示される。
図２の例では、「共通」アプリケーション、「業務」アプリケーション、「認証」アプリケーションが示されている。
負荷モデル作成部（１−１）は、入力した認証システムリクエストログ（８）に示されるＵＲＬとリクエスト種別情報（３−１）を照合して、認証システムリクエストログ（８）の各ＨＴＴＰリクエストがどのリクエスト種別（アプリケーション）を対象としているのかを判断することができる。
例えば、図２の１行目のＵＲＬが含まれるＨＴＴＰリクエストが認証システムリクエストログ（８）に記述されている場合は、負荷モデル作成部（１−１）は、当該ＨＴＴＰリクエストが「共通」アプリケーションの実行のためのリクエストであると判断することができる。
リクエスト種別情報（３−１）は、負荷モデル作成部（１−１）が認証システムリクエストログ（８）を入力する前から負荷テスト制御情報ＤＢ（３）に存在している。

負荷要件情報（３−２）には、ＨＴＴＰリクエスト数、利用ユーザ数、利用端末数（利用ＩＰアドレス数）が記載されている。
ＨＴＴＰリクエスト数とは、ピークの負荷を継続的に発生させる場合の１秒あたりのＨＴＴＰリクエストの数である。
また、利用ユーザ数は、負荷テストで模擬されるユーザ数である。
なお、負荷要件情報（３−２）の図示は省略している。
また、負荷要件情報（３−２）も、負荷モデル作成部（１−１）が認証システムリクエストログ（８）を入力する前から負荷テスト制御情報ＤＢ（３）に存在している。

負荷モデル情報（３−３）は、負荷モデル作成部（１−１）が生成する情報であり、図３に例示する情報である。
「モデル名」の欄には、負荷モデルの種別を一意に決める値が記述される。
「時刻（分）」の欄には、テストの単位時間が記述される。
「モデル名：ＰＥＡＫ」の場合は、１時間（００−６０）が単位時間であり、「モデル名：ＲＥＡＬ」では、５分（００−０５等）が単位時間である
「ＨＴＴＰ数／秒」の欄には、単位時間において認証サーバ装置（６０）に送信する毎秒当たりのＨＴＴＰリクエストの数が記述される。
「認証（％）」、「共通（％）」及び「業務（％）」は、リクエスト種別情報（３−１）（図２）の「リクエスト種別」に対応しており、「ＨＴＴＰ数／秒」に示すリクエスト数の内訳をパーセンテージで表している。
例えば、図３の２行目では、「ＨＴＴＰ数／秒」１００個のうち、「認証」は５％を占め、「共通」は９０％を占め、「業務」は５％を占めることが示されている。

「モデル名：ＰＥＡＫ」はピークの負荷を継続的に流す負荷モデルである。
すなわち、１時間（００−６０分）の間、毎秒５０００個のＨＴＴＰリクエストを認証サーバ装置（６０）に送信するという負荷テストのモデルである。
そして、毎秒５０００個のＨＴＴＰリクエストのうち０．３％を「認証」についてのＨＴＴＰリクエストとし、７０％を「共通」についてのＨＴＴＰリクエストとし、２９．７％を「業務」についてのＨＴＴＰリクエストとすることが指定されている。
「モデル名：ＲＥＡＬ」は実際に近い負荷モデルである。
すなわち、最初の５分間は毎秒１００個のＨＴＴＰリクエストを認証サーバ装置（６０）に送信し、次の５分間は毎秒５００個のＨＴＴＰリクエストを認証サーバ装置（６０）に送信し、以降も、５分ごとに、対応する「ＨＴＴＰ数／秒」分のＨＴＴＰリクエストを認証サーバ装置（６０）に送信するという負荷テストのモデルである。
そして、最初の５分間は毎秒１００個のＨＴＴＰリクエストのうち５％を「認証」についてのＨＴＴＰリクエストとし、９０％を「共通」についてのＨＴＴＰリクエストとし、５％を「業務」についてのＨＴＴＰリクエストとし、次の５分間は毎秒５００個のＨＴＴＰリクエストのうち３％を「認証」についてのＨＴＴＰリクエストとし、８５％を「共通」についてのＨＴＴＰリクエストとし、１２％を「業務」についてのＨＴＴＰリクエストとし、以降も、５分ごとに、「認証（％）」、「共通（％）」及び「業務（％）」の比率に従うことが指定されている。
「モデル名：ＲＥＡＬ」については、負荷モデル作成部（１−１）が認証システムリクエストログ（８）に示される受信履歴を単位時間（５分）ごとに解析し、単位時間ごとにリクエスト受信数を集計して、負荷モデル情報（３−３）の各レコードを生成する。
図３では、認証サーバ装置（６０）における総リクエスト受信数が「ＨＴＴＰ数／秒」の欄に記述され、総リクエスト受信数のリクエスト種別ごとの内訳がパーセントにて示されているが、実質的には、リクエスト種別ごとに認証サーバ装置（６０）におけるリクエスト受信数を示していると言える。
なお、以下では、「モデル名：ＲＥＡＬ」に基づく負荷テストについて主に説明を行う。

負荷パラメータ情報（３−４）は、負荷パラメータ算出部（１−２）が生成する情報であり、図４に例示する情報である。
「シナリオＮｏ」及び「枝番」は、レコードを一意に定めるためのキーである。
なお、共通の「シナリオＮｏ」が設定されている複数のレコードは、負荷モデル情報（３−３）（図３）内の共通の単位時間のレコードから生成されている。
「シナリオＮｏ：Ｓ１」が設定されている４つのレコードは、例えば、負荷モデル情報（３−３）の２行目のレコード（モデル名：ＲＥＡＬ、時刻（分）：００―０５）から生成されている。
「負荷テストコントローラＮｏ」の欄には、各レコードが対象としている負荷テストコントローラ（４）の識別番号が記述される。
図４の例では、負荷テストコントローラ（４）が設置されていることを前提としている。
「ユーザ実行間隔」の欄には、負荷テストエージェント（５）においてユーザの処理を実行する間隔（単位はミリ秒）が記述されている。
つまり、「ユーザ実行間隔」は、負荷テストエージェント（５）がｉ番目のユーザ（クライアント装置）のリクエスト送信を開始してから、（ｉ＋１）番目のユーザのリクエスト送信を開始するまでの間隔であり、ＨＴＴＰリクエストの送信タイミングが規定されている。
「ユーザ実行数」の欄には、負荷テストコントローラ（４）が該当する単位時間において模擬するユーザ（クライアント装置）数が記述されている。
前述のように、１ユーザが送信するＨＴＴＰリクエスト数は決まっているので、「ユーザ実行数」により単位時間内に送信するＨＴＴＰリクエストの個数が規定されている。
「エージェントリスト」の欄には、負荷テストコントローラ（４）の配下にある、認証サーバ装置（６０）にＨＴＴＰリクエストを送信する負荷テストエージェント（５）の識別子（ホスト名）が列挙される。
なお、本実施の形態では、リクエスト種別ごとに、ＨＴＴＰリクエストの送信を制御する負荷テストコントローラ（４）が決められているものとする。
例えば、リクエスト種別「共通」に分類されるＨＴＴＰリクエストの送信を制御するのは、図５の「ｃｔｒｌｈｏｓｔ０１」及び「ｃｔｒｌｈｏｓｔ０２」、リクエスト種別「業務」に分類されるＨＴＴＰリクエストの送信を制御するのは「ｃｔｒｌｈｏｓｔ０３」、リクエスト種別「認証」に分類されるＨＴＴＰリクエストの送信を制御するのは「ｃｔｒｌｈｏｓｔ０４」というように、リクエスト種別ごとに分担が予め決められているものとする。
このため、「ｃｔｒｌｈｏｓｔ０１」（負荷テストコントローラＮｏ：１）が対象である１行目のレコードには、リクエスト種別「共通」に分類されるＨＴＴＰリクエストの送信数（「ユーザ実行数」）と、送信タイミング（「ユーザ実行間隔」）が記述されている。
２行目以降のレコードにおいても、同様に、対応するリクエスト種別のＨＴＴＰリクエストの送信数（「ユーザ実行数」）と、送信タイミング（「ユーザ実行間隔」）が記述されている。

なお、図１において、破線で囲んだ範囲、すなわち、負荷モデル作成部（１−１）、負荷パラメータ算出部（１−２）及び負荷ツール情報ＤＢ（２）がテスト装置の例に相当する。
以降、このテスト装置に言及する際には、「テスト装置１００」と表記する。
なお、図１では、テスト装置１００を構成する負荷モデル作成部（１−１）、負荷パラメータ算出部（１−２）及び負荷ツール情報ＤＢ（２）が、負荷テスト実行部（１−３）、負荷テスト制御情報ＤＢ（３）及び負荷テストコントローラ（４）と同じコンピュータに実装されている例を示しているが、負荷モデル作成部（１−１）、負荷パラメータ算出部（１−２）及び負荷ツール情報ＤＢ（２）と、負荷テスト実行部（１−３）、負荷テスト制御情報ＤＢ（３）及び負荷テストコントローラ（４）とが、別のコンピュータに実装され、相互に通信を行って、以下に示す処理を行うようにしてもよい。

次に動作について説明する。
まず、負荷モデル作成部（１−１）による負荷モデル生成の動作について説明する（図７）。
図７では、負荷モデル作成部（１−１）は、認証システムリクエストログ（８）に示されるＵＲＬを解析して、ＨＴＴＰリクエストをリクエスト種別に分類し、単位時間ごとにリクエスト種別の単位で認証サーバ装置（６０）におけるリクエスト受信数を集計する。
そして、負荷モデル作成部（１−１）は、単位時間ごとにリクエスト種別の単位で認証サーバ装置（６０）におけるリクエスト受信数が示される負荷モデル情報（３−３）（図３）を生成している

負荷モデル作成部（１−１）は、負荷モデルの元とする認証システムリクエストログ（８）を認証システム（６）上の全ての認証サーバ装置（６０）から事前に収集しておく（Ｓ１）。
次に、負荷モデル作成部（１−１）は、リクエスト種別情報（３−１）（図２）のデータをメモリ上に格納する（Ｓ２）。
次に、負荷モデル作成部（１−１）は、認証システムリクエストログ（８）を１つずつ読み込む（Ｓ３）。
つまり、複数の認証サーバ装置（６０）の認証システムリクエストログ（８）の中から１つの認証サーバ装置（６０）の認証システムリクエストログ（８）を読み込む。
次に、負荷モデル作成部（１−１）は、負荷モデル生成のためのパラメータとして、起点時刻（例えば８時）と集計するための時間間隔（例えば５分）をパラメータファイル（図１には不図示）から読み込む（Ｓ４）。
パラメータファイルには、例えば、「起点時刻＝０８：００」、「時間間隔＝５」という形式でパラメータが記述されている。
次に、負荷モデル作成部（１−１）は、集計時刻に起点時刻＋時間間隔を代入する（Ｓ５）。
次に、負荷モデル作成部（１−１）は、リクエストログを１件ずつ読込む（Ｓ６）。
負荷モデル作成部（１−１）は、集計時刻とリクエストログの時刻を比較（Ｓ７）し、リクエストログの時刻が集計時刻より早い場合にはＳ９へ進む。
一方、リクエストログの時刻が集計時刻より遅い場合には集計時刻に時間間隔を加算し（Ｓ８）、メモリ上の集計テーブルのデータを負荷モデル情報（３−３）に記録（Ｓ８−１）して、Ｓ１０へ進む。
集計テーブルとは、負荷モデル情報（３−３）の各レコードを生成するために、単位時間ごとに、ＨＴＴＰリクエスト受信数、リクエスト種別の比率を集計するためのテーブルである。
なお、集計テーブルでは、単位時間（５分）でのＨＴＴＰリクエスト受信数が集計されるため、負荷モデル情報（３−３）の形式に合わせて、負荷モデル作成部（１−１）は集計テーブル上のＨＴＴＰリクエスト受信数を３００（秒）で除算して、秒単位のＨＴＴＰ受信数に変換して、負荷モデル情報（３−３）に記述する。

Ｓ９では、負荷モデル作成部（１−１）は、Ｓ６で読み込んだリクエストログのＵＲＬをリクエスト種別情報（３−１）と照合して、リクエスト種別を判定し、メモリ上の集計テーブルに集計リクエスト数とリクエスト種別の比率を加算する。

Ｓ１０では、負荷モデル作成部（１−１）は、リクエストログの最終行まで処理したかを確認し、最終行まで処理していればＳ１１に進み、最終行までの処理が終了していなければＳ６へ戻り、Ｓ６〜Ｓ１０を繰り返す。
また、負荷モデル作成部（１−１）は、認証システムリクエストログ（８）の全ファイルの処理が終了したかを確認し（Ｓ１１）、終了していれば、動作を終了する。

次に、負荷パラメータ算出部（１−２）が負荷モデル情報（３−３）から負荷パラメータ情報（３−４）を生成し、負荷テスト実行部（１−３）が負荷パラメータ情報（３−４）に基づいてテストを実施する動作について説明する（図８）。

まず、負荷パラメータ算出部（１−２）は、算出するモデルを指定（ここでは、現実モデルのため、「ＲＥＡＬ」とする）する（Ｓ１３）。
また、負荷パラメータ算出部（１−２）は、基本情報として、負荷ツール情報ＤＢ（２）のコントローラ情報（２−１）、エージェント情報（２−２）を読み込む（Ｓ１４）。
次に、負荷パラメータ算出部（１−２）は、負荷モデル情報（３−３）のレコードを１レコードずつ読み込む（Ｓ１５）。

次に、負荷パラメータ算出部（１−２）は、Ｓ１５で読み込んだレコードに記載のＨＴＴＰリクエスト数とコントローラごとの最大ユーザ実行数から必要なコントローラ台数を算出する（Ｓ１６）。
この処理は、リクエスト種別ごとに行われる。
つまり、Ｓ１５で読み込んだレコードに記載の「ＨＴＴＰ数／秒」にリクエスト種別ごとのパーセンテージ（「共通（％）」等）を乗算し、リクエスト種別ごとの「ＨＴＴＰ数／秒」と、当該リクエスト種別に対応する負荷テストコントローラ（４）の最大ユーザ実行数（図５）とを照合する。
例えば、「ＨＴＴＰ数／秒」が１台の負荷テストエージェント（５）の最大ユーザ実行数の範囲内であれば、必要なコントローラ台数は１台である。
また、「ＨＴＴＰ数／秒」が１台の負荷テストエージェント（５）の最大ユーザ実行数ではカバーできない場合は、「ＨＴＴＰ数／秒」の残数が２台目の負荷テストエージェント（５）の最大ユーザ実行数の範囲内であれば、必要なコントローラ台数は２台である。
このようにして、負荷パラメータ算出部（１−２）は、リクエスト種別ごとに、必要なコントローラ台数を算出する。

次に、負荷パラメータ算出部（１−２）は、１秒当たり、１コントローラあたりの実行ユーザ数を、「リクエスト数÷必要コントローラ台数」で算出する（Ｓ１７）。
この処理も、リクエスト種別ごとに行われる。
つまり、Ｓ１６で求めたリクエスト種別ごとの「ＨＴＴＰ数／秒」を、Ｓ１６で求めた当該リクエスト種別の「必要なコントローラ台数」で除算して、１秒当たり、１コントローラあたりの実行ユーザ数を求める。

次に、負荷パラメータ算出部（１−２）は、１テストあたりの必要時間を、「（１テストあたりのリクエスト数）×（１秒当たり、１コントローラあたりの実行ユーザ数）÷（リクエスト数）」で算出する（Ｓ１８）。
この処理も、リクエスト種別ごとに行われる。
上式の「１テスト当たりのリクエスト数」は、予め指定されており、例えば、２００個である。
上式の「１秒当たり、１コントローラあたりの実行ユーザ数」は、Ｓ１７で求めた値である。
上式の「リクエスト数」は、Ｓ１６で求めた、リクエスト種別ごとの「ＨＴＴＰ数／秒」である。

次に、負荷パラメータ算出部（１−２）は、ユーザの実行間隔を、「（１テストあたりの必要時間）÷（エージェント１台あたりの多重度）」で算出する（Ｓ１９）。
この処理は、負荷テストコントローラ（４）ごとに行われる。
上式の「１テストあたりの必要時間」は、Ｓ１８で求めた値である。
上式の「エージェント１台あたりの多重度」は、エージェント情報（２−２）（図６）の「多重度」の値の平均値である。
例えば、「ｃｔｒｌｈｏｓｔ０１」（負荷テストコントローラＮｏ：１）について計算では、「ｃｔｒｌｈｏｓｔ０１」の配下の負荷テストエージェント（５）である「ｈｏｓｔ００１」、「ｈｏｓｔ００２」、「ｈｏｓｔ００３」等における平均の多重度である。

次に、負荷パラメータ算出部（１−２）は、算出したパラメータを、負荷テストコントローラ（４）ごとに負荷パラメータ情報（３−４）に書き込む（Ｓ２０）。
具体的には、Ｓ１９で算出した「ユーザ実行間隔」の値を、負荷パラメータ情報（３−４）の「ユーザ実行間隔」の欄に、Ｓ１７で算出した「１秒当たり、１コントローラあたりの実行ユーザ数」の値を、負荷パラメータ情報（３−４）の「ユーザ実行数」の欄に書き込む。
更に、図６のエージェント情報（２−２）から、負荷テストコントローラ（４）が制御する負荷テストエージェント（５）のホスト名を抽出して、負荷パラメータ情報（３−４）の「エージェントリスト」の欄に書き込む。

次に、負荷パラメータ算出部（１−２）は、負荷モデル情報（３−３）の全てのレコードを処理したか否かを確認し（Ｓ２１）、全てのレコードを処理していればＳ２２へ進み、処理していないレコードが残っていればＳ１５へ戻り、次のレコード（次の単位時間）に対してＳ１５〜Ｓ２１を繰り返す。

次に、負荷テスト実行部（１−３）が、負荷パラメータ情報（３−４）を負荷テストツールの各負荷テストコントローラ（４）用のシナリオに変換する。
具体的には、負荷テスト実行部（１−３）が負荷パラメータ情報（３−４）のレコードを読込む（Ｓ２２）。
次に、負荷テスト実行部（１−３）は、起動時刻から起動遅延時間を算出し、各負荷テストコントローラ（４）に負荷パラメータ情報（３−４）の「ユーザ実行間隔」の値、「ユーザ実行数」の値、「エージェントリスト」の値を負荷テストの実行シナリオとして書き込む（Ｓ２３）。
例えば、「ｃｔｒｌｈｏｓｔ０１」（負荷テストコントローラＮｏ：１）に対しては、負荷パラメータ情報（３−４）（図４）の１行目の「ユーザ実行間隔」の値（１５０）、「ユーザ実行数」の値（１４００）、「エージェントリスト」の値（ｈｏｓｔ００１，．．．）、５行目の「ユーザ実行間隔」の値（２００）、「ユーザ実行数」の値（１０００）、「エージェントリスト」の値（ｈｏｓｔ００１，．．．）等を書き込む。
その後、負荷テスト実行部（１−３）は、負荷パラメータ情報（３−４）の全てのレコードを処理したか否かを確認し（Ｓ２４）、全てのレコードを処理していればＳ２５へ進み、処理していないレコードが残っていればＳ２２へ戻る。
負荷パラメータ情報（３−４）の全てのレコードを処理していれば、負荷テスト実行部（１−３）は、各負荷テストコントローラ（４）に負荷テストの実行を指示する（Ｓ２５）。
そして、負荷テスト実行部（１−３）は、負荷テストの完了を待ち（Ｓ２６）、テストが完了すると動作を終了する。
なお、負荷テストにおいては、各負荷テストエージェント（５）から図９の各ＵＲＬが記述されたＨＴＴＰリクエストが送信される。
ＨＴＴＰリクエストを送信する際に設定されたＩＰ数や利用ユーザ数に応じてＩＰアドレスを模擬する。
また、図９で示している「認証画面」、「認証要求（Ｉ／Ｄパスワード）」、「ポータル画面」は説明のための記述であり、実際の負荷テストにおいてこのような記述がなされているわけではない。

以上のように、本実施の形態では、負荷モデルの自動生成および負荷パラメータを自動算出するようにしているので、負荷テスト実施期間を短縮できる効果がある。
また、算出結果を記録しておくことが可能であるため、類似の負荷要件に対するパラメータ算出の短縮や負荷を掛けるパターンごとに負荷モデルを定義することができることでも負荷テストの時間短縮の効果がある。

以上、本実施の形態では、
実環境の認証システムのログを元に、負荷モデルを生成する負荷モデル作成部と生成した負荷モデルと負荷ツール構成情報を合わせて負荷ツール実行パラメータを自動的に算出するための負荷パラメータ算出ツール、負荷ツールを制御・実行するための負荷テスト実行部を備える負荷テストコントロール方式を説明した。

実施の形態２．
以上の実施の形態１では、認証システムに対するＨＴＴＰリクエスト負荷を掛けるためのモデルを実環境の全てのログから生成するようにしたものであるが、次に全サーバのログから生成すると非常に時間がかかってしまう場合に対して、１つの認証サーバ装置のログから負荷モデルを生成する実施の形態を示す。
すなわち、本実施の形態では、負荷モデル作成部（１−１）は、認証システム（６）内の全ての認証サーバ装置（６０）の認証システムリクエストログ（８）から負荷モデル情報（３−３）を生成するのではなく、代表の認証サーバ装置（６０）の認証システムリクエストログ（８）に基づいて、全ての認証サーバ装置（６０）におけるＨＴＴＰリクエストの受信数の推定値を導出し、導出した推定値から負荷モデル情報（３−３）を生成する。

本実施の形態に係るシステム構成は、図１と同様である。
図１に示す負荷分散装置（６２）は図１０に示す負荷分散定義テーブルにて各認証サーバ装置（６０−１）（６０−２）（６０−３）にＨＴＴＰリクエストを割り振る割合を管理し、各認証サーバ装置（６０−１）（６０−２）（６０−３）にＨＴＴＰリクエストを割り振り、認証サーバ装置への負荷を均等にする。
図１０に示す負荷分散定義テーブルでは、割合は全て積算すると１になるように定義されているものとする。

図１１は、本実施の形態に係る動作のフローを示した図である。
以下では、実施の形態１との違いについて述べる。

負荷モデル作成部（１−１）は、あらかじめ認証システムリクエストログ（８）を読み込む代表の認証サーバ装置（６０）を決めておき、また、負荷分散定義テーブル（図１０）を記録しておく。
そして、負荷モデル作成部（１−１）は、代表の認証サーバ装置（６０）の認証システムリクエストログ（８）を入力し、実施の形態１と同様に、入力した認証システムリクエストログ（８）におけるリクエスト数を単位時間ごとに集計し、また、リクエスト種別ごとの比率も集計し、集計結果を集計テーブルに書き込む。
集計テーブルからリクエスト数を負荷モデル情報（３−３）に記録する際に、負荷モデル作成部（１−１）は、集計テーブル上のリクエスト数を図１０の分散割合で除算した値を負荷モデル情報（３−３）に記録する（Ｓ８−２）。
例えば、代表の認証サーバ装置が図１０の認証サーバ装置１であれば、集計テーブルのリクエスト数を「０．３」で割って、全ての認証サーバ装置（６０）におけるリクエスト受信数の推定値を算出する。
そして、推定値を負荷モデル情報（３−３）に記録する。
リクエスト種別ごとの比率は集計テーブルの値のまま、負荷モデル情報（３−３）に記録する。
Ｓ８−２以外の処理は、図７に示したものと同様である。

以上のように、本実施の形態によれば、負荷モデルを生成する際に１台の認証サーバ装置のログから生成することを可能にすることで、更なる時間短縮の効果が得られる。

以上、本実施の形態では、認証サーバ１台のログから負荷モデル作成を行うことを可能とする負荷テストコントロール方式を説明した。

実施の形態３．
以上の実施の形態１では、負荷テストを実施後、想定どおりの負荷がかからなかった場合、手動で調整する必要がある。
本実施の形態では、これに対し、負荷テスト試行時の認証サーバ装置のログを使用して負荷モデルを調整する実施の形態を示す。

図１２は、実施の形態３に係るシステム構成図である。
図１２では、図１と比較して、負荷モデルフィードバック部（１−４）とフィードバックＤＢ（９）が負荷テストコントロールシステム（１）の要素として追加されている。
また、負荷テスト試行時の認証サーバ装置（６０）のＨＴＴＰリクエストの受信についてのログデータが負荷テスト試行時認証システムリクエストログ（８０）として負荷モデルフィードバック部（１−４）に入力される。
認証システムリクエストログ（８）は通常稼働時のＨＴＴＰリクエストの受信履歴を示すのに対して、負荷テスト試行時認証システムリクエストログ（８０）は負荷テスト試行時のＨＴＴＰリクエストの受信履歴を示す。
負荷テスト試行時認証システムリクエストログ（８０）の形式は、認証システムリクエストログ（８）と同様であり、例えば、図１９に示す通りである。
なお、負荷モデルフィードバック部（１−４）は、フィードバックログデータ入力部、フィードバックログ集約部及びログ集約データ変更部の例に相当する。
また、本実施の形態では、負荷モデル作成部（１−１）、負荷パラメータ算出部（１−２）、負荷ツール情報ＤＢ（２）及び負荷モデルフィードバック部（１−４）がテスト装置の例に相当する。

フィードバックＤＢ（９）では、フィードバック負荷モデル情報（９−１）とフィードバック調整ポリシー情報（９−２）が記憶されている。
フィードバック負荷モデル情報（９−１）のテーブル構成は、負荷モデル情報（３−３）（図３）と同様である。
また、フィードバック調整ポリシー情報（９−２）のテーブル構成は、図１３となる。
負荷モデルフィードバック部（１−４）は、単位時間ごと、リクエスト種別ごとに、フィードバック調整ポリシー情報（９−２）の差分条件が成立するか否かを判断し、差分条件が成立する場合は、適用ポリシーに従って、負荷モデル情報（３−３）の該当する内容を変更する。
フィードバック調整ポリシー情報（９−２）の１行目は、負荷モデル情報（３−３）で規定されている「ＨＴＴＰ数／秒」の値が、負荷テスト試行時認証システムリクエストログ（８０）から集計されたフィードバック負荷モデル情報（９−１）で規定されている「ＨＴＴＰ数／秒」の１．１倍よりも大きいことを差分条件としている。
すなわち、負荷テストにおいて実際に認証サーバ装置（６０）に送信されたＨＴＴＰリクエストの数が、負荷モデル情報（３−３）で規定されている「ＨＴＴＰ数／秒」よりも１０％以上少なかったことを差分条件としている。
そして、この差分条件が成立する場合には、現在の負荷モデル情報（３−３）に規定されている「ＨＴＴＰ数／秒」の１．５倍の値が規定される新たな負荷モデル情報（３−３）を生成することを適用ポリシーとする。
また、フィードバック調整ポリシー情報（９−２）の３行目は、負荷モデル情報（３−３）で規定されている「業務（％）」の値と、負荷テスト試行時認証システムリクエストログ（８０）から集計されたフィードバック負荷モデル情報（９−１）ので規定されている「業務（％）」の値とが一致しないことを差分条件としている。
そして、この差分条件が成立する場合には、フィードバック負荷モデル情報（９−１）で規定されている「業務（％）」の値と「共通（％）」の値と同じ値が規定される新たな負荷モデル情報（３−３）を生成することを適用ポリシーとする。

次に、本実施の形態での動作の流れを示す。
負荷モデル生成（図７）から負荷パラメータ算出（図８）、負荷テスト実施（図８）までは実施の形態１と同じである。
図１４が負荷モデルフィードバック部（１−４）のフローである。
フィードバック負荷モデル情報（９−１）の生成は、インプットとなる情報が、負荷テスト試行時の認証システム（６）のログである負荷テスト試行時認証システムリクエストログ（８０）となる点を除けば、図７と同じである。
したがって、フィードバック負荷モデル情報（９−１）と負荷モデル情報（３−３）の差分を比較するところから記述する。

負荷モデルフィードバック部（１−４）は、フィードバック調整ポリシー情報（９−２）をメモリ上に読込み（Ｓ２７）、比較時刻を初期化する（Ｓ２８）。
また、負荷モデルフィードバック部（１−４）は、該当時刻の負荷モデル情報（３−３）のレコードを読み込み（Ｓ２９）、該当時刻のフィードバック負荷モデル情報（９−１）のレコードを読み込む（Ｓ３０）。
次に、負荷モデルフィードバック部（１−４）は、両レコードの内容を比較し（Ｓ３１）、差分があればＳ３２へ、差分がなければＳ３５へ進む。
差分があった場合には、負荷モデルフィードバック部（１−４）は、差分をフィードバック調整ポリシー情報（９−２）の差分条件とつき合わせて適用ポリシーを抽出する（Ｓ３２）。
つまり、負荷モデルフィードバック部（１−４）は、抽出した差分が合致する差分条件があれば、その差分条件に対応する適用ポリシーを採用する。
そして、負荷モデルフィードバック部（１−４）は、Ｓ３２にて抽出した適用ポリシーを元の負荷モデル情報（３−３）の値に適用して再計算する（Ｓ３３）。
そして、負荷モデルフィードバック部（１−４）は、再計算した値を負荷モデル情報（３−３）に反映する（Ｓ３４）。

Ｓ３２で差分がなかった場合又はＳ３４で負荷モデル情報（３−３）を更新した後は、負荷モデルフィードバック部（１−４）は、比較時刻に時間間隔を加算する（Ｓ３５）。
また、負荷モデルフィードバック部（１−４）は、全データの比較処理が完了したかチェックし（Ｓ３６）、完了していれば、動作を終了する。
完了していなければＳ２９からＳ３５までを繰り返す。

この後、負荷テスト実行部（１−３）が、新たな負荷モデル情報（３−３）を用いて、実施の形態１と同様の手順にて負荷テストを行う。
負荷テストの試行と負荷テストフィードバックを繰り返すことで、要件に合った負荷パラメータに収束される。
なお、２回目以降の負荷テスト試行時認証システムリクエストログ（８０）から生成されたフィードバック負荷モデル情報（９−１）については、オリジナルの負荷モデル情報（３−３）との差分を抽出してもよいし、変更後の負荷モデル情報（３−３）との差分を抽出してもよい。

図１５は、本実施の形態のフィードバック調整処理の概要を示す。
図１５（ａ）は、認証システムリクエストログ（８）に基づいて生成された負荷モデル情報（３−３）の単位時間ごとの「ＨＴＴＰ数／秒」の値をグラフ化した状態を示す。
図１５（ｂ）は、負荷テスト試行時認証システムリクエストログ（８０）に基づいて生成されたフィードバック負荷モデル情報（９−１）の単位時間ごとの「ＨＴＴＰ数／秒」の値をグラフ化した状態を示す。
図１５（ｃ）は、負荷モデルフィードバック部（１−４）によって負荷モデル情報（３−３）とフィードバック負荷モデル情報（９−１）の差分が調整された後の「ＨＴＴＰ数／秒」の値をグラフ化した状態を示す。
つまり、図１５（ｃ）は、図１４のＳ３３の再計算により得られた「ＨＴＴＰ数／秒」の値のグラフである。
図１５（ｃ）にあるように、図１４のＳ３３では、実際の差分よりも大きく調整を行って、当初の負荷モデル情報（３−３）に記載の「ＨＴＴＰ数／秒」分のリクエストが認証サーバ装置（６０）に送信されるようにする。

以上のように、本実施の形態によれば、生成した負荷モデルを元にした負荷テストの実施結果が負荷モデルと差異がある場合に、負荷モデルを自動的に調整することが可能となり、負荷テストの時間短縮の効果が得られる。

以上、本実施の形態では、負荷テストの試行結果を負荷モデルにフィードバックする負荷テストコントロール方式を説明した。

実施の形態４．
以上の実施の形態２と実施の形態３とを組み合わせてもよい。
実施の形態２及び３よりも更に負荷テスト実施の時間短縮の効果が得られる。

実施の形態５．
以上の実施の形態３では、フィードバックを繰り返すことで負荷要件に合った負荷テストパラメータを算出していたが、これでは、なかなか負荷モデルが収束されない可能性が考えられる。
そこで、本実施の形態では、適用するフィードバック調整ポリシー情報を１度目と２度目とで変え、フィードバック回数を２回で完了させる実施の形態を示す。

本実施の形態に係るシステム構成は、図１２と同じである。
本実施の形態では、フィードバック負荷モデル情報（９−１）にはラベルカラムをキーの一つとして追加し、「試行」および「調整」の回数と負荷モデルを記録する（図１６）。
「試行」とは、負荷テストの実施を意味し、図１６において「試行」が設定されているレコードには、負荷テスト試行時認証システムリクエストログ（８０）を集計して得られた値が記述されている。
「調整」とは、負荷テスト後の新たなパラメータの設定を意味し、図１６において「調整」が設定されているレコードには、図１４のＳ３３の再計算により得られた値が記述されている。
また、本実施の形態に係るフィードバック調整ポリシー情報（９−２）では、差分条件に試行の回数の情報も追加されている（図１７）。
図１７の１行目は、１回目の負荷テスト試行時認証システムリクエストログ（８０）を集計して得られたフィードバック負荷モデル情報（９−１）とオリジナルの負荷モデル情報（３−３）との間の差分について規定している。
一方、図１７の２行目は、２回目の負荷テスト試行時認証システムリクエストログ（８０）を集計して得られたフィードバック負荷モデル情報（９−１）とオリジナルの負荷モデル情報（３−３）との間の差分について規定している。
このように、本実施の形態では、負荷モデルフィードバック部（１−４）は、１回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時と２回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時で適用ポリシーを変えている。

なお、負荷モデルフィードバック部（１−４）の動作フローは、実施の形態３と同様に図１４に従う。
本実施の形態と実施の形態３では、Ｓ３２、Ｓ３３で使用する差分条件、適用ポリシーが図１７のものを使用する点のみが異なる。

負荷モデルと試行結果と調整結果との関係を図１８に示す。
図１８において、負荷モデルはオリジナルの負荷モデル情報（３−３）の負荷モデルである。
試行結果（１回目）は、オリジナルの負荷モデル情報（３−３）に基づいて負荷テストが行われた後に出力された１回目の負荷テスト試行時認証システムリクエストログ（８０）から生成された１回目のフィードバック負荷モデル情報（９−１）の負荷モデルである。
また、調整結果（１回目）は、オリジナルの負荷モデル情報（３−３）と１回目のフィードバック負荷モデル情報（９−１）との差分を調整した、変更後の負荷モデル情報（３−３）の負荷モデルである。
試行結果（２回目）は、変更後の負荷モデル情報（３−３）に基づいて負荷テストが行われた後に出力された２回目の負荷テスト試行時認証システムリクエストログ（８０）から生成された２回目のフィードバック負荷モデル情報（９−１）の負荷モデルである。
調整結果（２回目）は、オリジナルの負荷モデル情報（３−３）と２回目のフィードバック負荷モデル情報（９−１）との差分を調整した、更なる変更後の負荷モデル情報（３−３）の負荷モデルである。

なお、上記では、１回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時と２回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時とで異なる差分条件と適用ポリシーを用いたが、どのようなタイミングで差分条件と適用ポリシーを変更するようにしてもよい。
つまり、フィードバック回数を２回に限定しなければ、ｎ（ｎは１以上の整数）回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時と（ｎ＋ｍ）（ｍは１以上の整数）回目の負荷テスト試行時認証システムリクエストログ（８０）の入力時とで異なる差分条件と適用ポリシーを用いるようにすることができる。

以上のように、本実施の形態によれば、フィードバック調整ポリシー情報を調整することで、短時間で適切な負荷モデルを生成することが可能となり、負荷テストの時間短縮の効果が得られる。

以上、本実施の形態では、負荷テストの試行結果のフィードバック回数を最大２回で負荷モデルの調整を完了させる負荷コントロール方式を説明した。

実施の形態６．
以上の実施の形態２と実施の形態５とを組み合わせてもよい。
実施の形態２と実施の形態５よりもさらに負荷テスト実施の時間短縮の効果が得られる。

最後に、実施の形態１〜５に示したテスト装置（１００）のハードウェア構成例について説明する。
図２０は、実施の形態１〜５に示すテスト装置（１００）のハードウェア資源の一例を示す図である。
なお、図２０の構成は、あくまでもテスト装置（１００）のハードウェア構成の一例を示すものであり、テスト装置（１００）のハードウェア構成は図２０に記載の構成に限らず、他の構成であってもよい。

図２０において、テスト装置（１００）は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜５で説明した「負荷ツール情報ＤＢ（２）」、「負荷テスト制御情報ＤＢ（３）」及び「フィードバックＤＢ（９）」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。

また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。

また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
テスト装置（１００）の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。

上記プログラム群９２３には、実施の形態１〜５の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。

ファイル群９２４には、実施の形態１〜５の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の集計」、「〜の生成」、「〜の指定」、「〜の変更」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が、ディスクやメモリなどの記憶媒体にファイルとして記憶されている。
また、暗号鍵・復号鍵や乱数値やパラメータが、ディスクやメモリなどの記憶媒体にファイルとして記憶されてもよい。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記憶媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜５で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の記憶媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１〜５の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜５で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「テスト方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の記憶媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜５の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜５の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１〜５に示すテスト装置（１００）は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

１ 負荷テストコントロールシステム、１−１ 負荷モデル作成部、１−２ 負荷パラメータ算出部、１−３ 負荷テスト実行部、１−４ 負荷モデルフィードバック部、２ 負荷ツール情報ＤＢ、２−１ コントローラ情報、２−２ エージェント情報、３ 負荷テスト制御情報ＤＢ、３−１ リクエスト種別情報、３−２ 負荷要件情報、３−３ 負荷モデル情報、３−４ 負荷パラメータ情報、４ 負荷テストコントローラ、５ 負荷テストエージェント、６ 認証システム、７ 業務システム、８ 認証システムリクエストログ、９ フィードバックＤＢ、９−１ フィードバック負荷モデル情報、９−２ フィードバック調整ポリシー情報、６０ 認証サーバ装置、６１ 認証リポジトリ、６２ 負荷分散装置、８０ 負荷テスト試行時認証システムリクエストログ、１００ テスト装置。

Claims (11)

1. それぞれがクライアント装置をエミュレートする複数のテストツールから複数のリクエストをテスト対象サーバ装置に送信させて、前記テスト対象サーバ装置のテストを行うテスト装置であって、
   各テストツールのリクエスト送信性能が示される性能情報を記憶する性能情報記憶部と、
   クライアント装置から複数のリクエストを受信する稼動中の稼動中サーバ装置で収集され、前記稼動中サーバ装置におけるリクエストの受信履歴が、リクエストを分類するための識別子であるリクエスト分類識別子とリクエストの受信時刻との対により示されるログデータを入力するログデータ入力部と、
   前記ログデータに示される各リクエスト分類識別子を解析して複数のリクエスト種別のうちのいずれかに分類し、所定の単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数を集計し、単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数が示されるログ集約データを生成するログ集約部と、
   前記ログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、テストパラメータとして、各テストツールが前記テスト対象サーバ装置に送信するリクエストの数とリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定するテストパラメータ指定部とを有することを特徴とするテスト装置。
2. 前記テストパラメータ指定部は、
   前記ログ集約データに示されるリクエスト受信数分のリクエストが各単位時間で全てのリクエスト種別について送信されるように、テストツールごとにリクエストの送信数とリクエストの送信タイミングを指定することを特徴とする請求項１に記載のテスト装置。
3. 前記テスト装置は、更に、
   前記テストパラメータ指定部により指定されたテストパラメータに従って各テストツールから送信されたリクエストの前記テスト対象サーバ装置における受信履歴が、リクエスト分類識別子とリクエストの受信時刻との対により示されるフィードバックログデータを入力するフィードバックログデータ入力部と、
   前記フィードバックログデータに示される各リクエスト分類識別子を解析して複数のリクエスト種別のうちのいずれかに分類し、単位時間ごとにリクエスト種別の単位で前記テスト対象サーバ装置におけるリクエスト受信数を集計し、単位時間ごとにリクエスト種別の単位で前記テスト対象サーバ装置におけるリクエスト受信数が示されるフィードバックログ集約データを生成するフィードバックログ集約部と、
   前記フィードバックログ集約データに示されるリクエスト受信数と、前記テストパラメータを指定するために用いられたログ集約データに示されるリクエスト受信数とを、単位時間ごとにリクエスト種別の単位で比較し、比較結果に基づき、前記ログ集約データのリクエスト受信数を変更するログ集約データ変更部とを有し、
   前記テストパラメータ指定部は、
   前記ログ集約データ変更部による変更後のログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、新たなテストパラメータを指定することを特徴とする請求項１又は２に記載のテスト装置。
4. 前記フィードバックログデータ入力部は、
   前記テストパラメータ指定部により新たなテストパラメータが指定され、新たなテストパラメータに従って各テストツールから前記テスト対象サーバ装置にリクエストが送信される度に、フィードバックログデータを入力し、
   前記フィードバックログ集約部は、
   前記フィードバックログデータ入力部によりフィードバックログデータが入力される度に、フィードバックログ集約データを生成し、
   前記ログ集約データ変更部は、
   前記フィードバックログ集約部によりフィードバックログ集約データが生成される度に、生成されたフィードバックログ集約データに示されるリクエスト受信数と、過去のいずれかのログ集約データに示されるリクエスト受信数とを、単位時間ごとにリクエスト種別の単位で比較し、比較結果に基づき、過去のいずれかのログ集約データのリクエスト受信数を変更し、
   前記テストパラメータ指定部は、
   前記ログ集約データ変更部によりログ集約データが変更される度に、変更後のログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、新たなテストパラメータを指定することを特徴とする請求項３に記載のテスト装置。
5. 前記ログ集約データ変更部は、
   ｎ（ｎは１以上の整数）回目のフィードバックログデータの入力の際に、第１の基準に従ってログ集約データのリクエスト受信数を変更し、
   （ｎ＋ｍ）（ｍは１以上の整数）回目のフィードバックログデータの入力の際に、第１の基準と異なる第２の基準に従ってログ集約データのリクエスト受信数を変更することを特徴とする請求項４に記載のテスト装置。
6. 前記ログデータ入力部は、
   前記稼動中サーバ装置のログデータとして、稼動中の前記テスト対象サーバ装置で収集され、前記テスト対象サーバ装置におけるリクエストの受信履歴がリクエスト分類識別子とリクエストの受信時刻との対により示されるログデータを入力することを特徴とする請求項１〜５のいずれかに記載のテスト装置。
7. 前記ログデータ入力部は、
   テスト対象サーバ装置が複数ある場合に、複数のテスト対象サーバ装置のログデータを入力し、
   前記ログ集約部は、
   前記ログデータ入力部により入力された前記複数のテスト対象サーバ装置のログデータを用いて、単位時間ごとにリクエスト種別の単位で前記複数のテスト対象サーバ装置におけるリクエスト受信数を集計し、
   単位時間ごとにリクエスト種別の単位で前記複数のテスト対象サーバ装置におけるリクエスト受信数が示されるログ集約データを生成することを特徴とする請求項６に記載のテスト装置。
8. 前記ログデータ入力部は、
   テスト対象サーバ装置が複数ある場合に、複数のテスト対象サーバ装置のうちの代表のテスト対象サーバ装置のログデータのみを入力し、
   前記ログ集約部は、
   前記ログデータ入力部により入力された代表のテスト対象サーバ装置のログデータを用いて、単位時間ごとにリクエスト種別の単位で代表のテスト対象サーバ装置におけるリクエスト受信数を集計し、
   集計結果に基づき、単位時間ごとにリクエスト種別の単位で前記複数のテスト対象サーバ装置におけるリクエスト受信数の推定値が示されるログ集約データを生成することを特徴とする請求項６に記載のテスト装置。
9. 前記テストパラメータ指定部は、
   前記テスト対象サーバ装置に対する負荷テストのテストパラメータを指定することを特徴とする請求項１〜８のいずれかに記載のテスト装置。
10. それぞれがクライアント装置をエミュレートする複数のテストツールから複数のリクエストをテスト対象サーバ装置に送信させて、前記テスト対象サーバ装置のテストを行うコンピュータによるテスト方法であって、
    前記コンピュータが、各テストツールのリクエスト送信性能が示される性能情報を所定の記憶領域から読み出す性能情報読み出しステップと、
    クライアント装置から複数のリクエストを受信する稼動中の稼動中サーバ装置で収集され、前記稼動中サーバ装置におけるリクエストの受信履歴が、リクエストを分類するための識別子であるリクエスト分類識別子とリクエストの受信時刻との対により示されるログデータを、前記コンピュータが入力するログデータ入力ステップと、
    前記コンピュータが、前記ログデータに示される各リクエスト分類識別子を解析して複数のリクエスト種別のうちのいずれかに分類し、所定の単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数を集計し、単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数が示されるログ集約データを生成するログ集約ステップと、
    前記コンピュータが、前記ログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、テストパラメータとして、各テストツールが前記テスト対象サーバ装置に送信するリクエストの数とリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定するテストパラメータ指定ステップとを有することを特徴とするテスト方法。
11. それぞれがクライアント装置をエミュレートする複数のテストツールから複数のリクエストをテスト対象サーバ装置に送信させて、前記テスト対象サーバ装置のテストを行うコンピュータに、
    各テストツールのリクエスト送信性能が示される性能情報を所定の記憶領域から読み出す性能情報読み出しステップと、
    クライアント装置から複数のリクエストを受信する稼動中の稼動中サーバ装置で収集され、前記稼動中サーバ装置におけるリクエストの受信履歴が、リクエストを分類するための識別子であるリクエスト分類識別子とリクエストの受信時刻との対により示されるログデータを入力するログデータ入力ステップと、
    前記ログデータに示される各リクエスト分類識別子を解析して複数のリクエスト種別のうちのいずれかに分類し、所定の単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数を集計し、単位時間ごとにリクエスト種別の単位で前記稼動中サーバ装置におけるリクエスト受信数が示されるログ集約データを生成するログ集約ステップと、
    前記ログ集約データに示される単位時間ごとのリクエスト種別単位のリクエスト受信数と、前記性能情報に示される各テストツールのリクエスト送信性能とに基づき、テストパラメータとして、各テストツールが前記テスト対象サーバ装置に送信するリクエストの数とリクエストの送信タイミングを単位時間ごとにリクエスト種別の単位で指定するテストパラメータ指定ステップとを実行させることを特徴とするプログラム。

Images