(57)【要約】【課題】  負荷を適用することによってコンピュータシステムをテストする。【解決手段】  本発明にかかる負荷を適用することによってコンピュータシステムをテストする方法は、負荷仕様を受け取ることであって、当該負荷仕様が、システムの少なくとも１つの資源を特定し、かつ、当該資源に適用される負荷を指定する、負荷仕様を受け取ることと、および負荷仕様で特定された各資源について、対応する指定された負荷を当該資源に適用することとを含む。【選択図】図１
2005182813.tif 000002
【特許請求の範囲】
【請求項１】
負荷を適用することによってコンピュータシステムをテストする方法であって、
負荷仕様を受け取る（１０４）ことであって、前記負荷仕様が、前記システムの少なくとも１つの資源を特定し、かつ、前記資源に適用される負荷を指定することと、
前記負荷仕様で特定された各資源について、前記対応する指定された負荷を前記資源に適用する（１１０）ことと
を含む方法。
【請求項２】
前記指定された負荷は、
特定された各資源の負荷の大きさおよび負荷の継続時間の表示、
前記負荷の継続時間の開始および終了の表示、および、
前記負荷の継続時間にわたる前記負荷の大きさの変動、または、
これらのいずれか
の１つ以上を含み、
前記負荷の大きさの表示は、前記システムの前記対応する資源の最大負荷の百分率を表す値である
請求項１に記載の方法。
【請求項３】
前記負荷仕様は、指定された各負荷を適用する少なくとも１つの資源テストを指定し、
前記負荷仕様を受け取って正当性を確認する（１０６）ことと、
特定された各資源のテストドライバを起動する（１０８）ことと、
前記テストドライバが指定された資源テストを実行する（１１０）ことであって、それによって、指定された負荷を対応するシステム資源に適用する、前記テストドライバが指定された資源テストを実行する（１１０）ことと
を含む請求項２に記載の方法。
【請求項４】
特定された各資源について、異なるテストドライバが起動される
請求項３に記載の方法。
【請求項５】
前記テストドライバが、前記コンピュータシステムを監視する（１１２）ことであって、指定された資源テストにより、特定されたコンピュータシステム資源に適用される前記負荷の大きさを決定することと、
前記テストドライバが前記決定された負荷の大きさを前記指定された負荷の大きさと比較する（１１４）ことと、
前記テストドライバが前記比較に基づいて前記指定された資源テストの実行を制御する（１１６）ことと
を含む請求項３に記載の方法。
【請求項６】
プロセスが、前記受け取り、前記正当性の確認および前記起動を実行し、
前記プロセスは、デーモンである
請求項３に記載の方法。
【請求項７】
前記負荷は、揮発性メモリの負荷、スタティックメモリの負荷、ディスクドライブ入出力の負荷、ネットワーク入出力の負荷および中央処理装置の負荷のいずれかである
請求項１に記載の方法。
【請求項８】
前記負荷仕様は、実行されると、指定された負荷を対応する資源に適用するテストを示す
請求項１に記載の方法。
【請求項９】
負荷を適用することによってコンピュータシステムをテストする方法であって、負荷仕様を受け取る（１０４）ことであって、前記負荷仕様が、前記システムの少なくとも１つの資源を特定し、かつ、前記資源に適用される負荷を指定することと、前記負荷仕様で特定された各資源について、前記対応する指定された負荷を前記資源に適用する（１１０）こととを含む方法に従って、コンピュータシステムをテストするデバイスであって、
前記コンピュータシステムにインストールされたソフトウェア（３０４１，３１４１，３１８１）であって、前記負荷仕様を受け取るように構成され、前記負荷仕様で特定された各資源について、前記ソフトウェアが前記対応する指定された負荷を前記資源に適用するように構成されるソフトウェアと、
前記少なくとも１つの資源の負荷を監視する手段（３０４、３１４、３１８）と、
前記監視された負荷および前記負荷仕様の少なくとも１つを表示する表示装置（３０２、３０６、３１６）と
を備えるデバイス。
【請求項１０】
負荷を適用することによってコンピュータシステムをテストするプログラムであって、
負荷仕様を受け取る（１０４）ことであって、前記負荷仕様が、前記システムの少なくとも１つの資源を特定し、かつ、前記資源に適用される負荷を指定するステップと、
前記負荷仕様で特定された各資源について、前記対応する指定された負荷を前記資源に適用する（１１０）ステップと
を実行するコンピュータプログラム
を含むマシン可読媒体。
【請求項１１】
負荷を適用することによってコンピュータシステムをテストする方法であって、負荷仕様を受け取る（１０４）ことであって、前記負荷仕様が、前記システムの少なくとも１つの資源を特定し、かつ、前記資源に適用される負荷を指定することと、前記負荷仕様で特定された各資源について、前記対応する指定された負荷を前記資源に適用する（１１０）こととを含む方法の実行に使用されるテストシステムであって、
負荷仕様で特定された少なくとも１つのコンピュータシステム資源に、前記負荷仕様で指定された対応する負荷を適用する手段（３０４１，３１４１，３１８１）であって、前記負荷仕様が前記負荷の大きさを指定する手段と、
前記少なくとも１つの資源が受ける負荷を監視する手段（３０４，３１４，３１８）と
を備えるテストシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷の適用によるコンピュータシステムのテスト方法およびテストシステムに関する。
【背景技術】
【０００２】
Akin等に付与された米国特許第６，１８２，２４５号は、ソフトウェアプログラムのテストに使用されるテストケースデータの中央リポジトリへの選択的なアクセスを提供するソフトウェアテストケースクライアント／サーバシステムを対象としている。
テストケースサーバは、中央リポジトリのテストケースデータを記憶して管理する。
テストクライアントは、テストプログラムとテストサーバとの間で通信を行い、ソフトウェアプログラムのテストに必要な所望の読み出し／書き込みステータスを有するテストケースデータおよびこのようなデータのバージョンを特定する。
テストプログラムは、テストケースデータの選択、ソフトウェアプログラムのテストの実行、およびソフトウェアプログラムの結果の検証を自動化する。
例示の実施の形態では、テストケースデータのシンボリックリンクおよびコピーが、テスト対象ソフトウェアプログラムによりアクセス可能な宛先ディレクトリ構造体に記録される。
代替的な実施の形態では、リビジョン管理システム（ＲＣＳ（revision control system））が、中央リポジトリにアクセスするのに使用され、テスト対象ソフトウェアプログラムによりアクセス可能な宛先ディレクトリ構造体の選択されたテストケースデータのコピーを提供するのに使用される。
所望のテストケースのアクセスを通信して実施する方法は、テストクライアントによって起動されてテストサーバによって受信される命令を含む。
中央リポジトリ管理アプリケーションは、テストケースデータおよびこのようなデータのバージョンの編成、補完、およびそれ以外の管理をユーザに可能にする。
クライアント／サーバ構成は、さらに、共有中央リポジトリのテストケースデータを破損することなく、テストケースデータの共有中央リポジトリへの複数のユーザによるアクセスを容易にする。
【０００３】
Weinberg等に付与された米国特許第５，９７４，５７２号は、視覚ウェブサイト解析プログラムを対象としている。
このプログラムは、ソフトウェアコンポーネントの集合として実施され、ウェブサイトの解析、管理、および負荷テストを円滑にするさまざまな機能を提供するものである。
マッピングコンポーネントが、ネットワーク接続を介してウェブサイトをスキャンし、サイトのＵＲＬおよびリンクを図表で描写するサイトマップを構築する。
サイトマップは、固有のレイアウトを使用して生成され、ユーザがウェブサイトの全体的なアーキテクチャを視覚化することを可能にする方法論を表示する。
見つからないＵＲＬへのリンク等のよくあるウェブサイトの問題を特定して修復するタスクを円滑にするために、さまざまなマップナビゲーション機能およびＵＲＬフィルタリング機能が提供される。
動的なページスキャン機能によって、ユーザは、動的に生成されたウェブページをサイトマップ内に含めることができる。
これは、フォームがユーザによってサブミットされた時に標準的なウェブブラウザの出力を取り込み、次いで、その後のサイトのマッピング中にこの出力を自動的に再サブミットすることによって行われる。
アクショントラッカ（Action Tracker）モジュールが、ユーザのアクティビティおよび行動データ（リンクアクティビティレベル、共通のサイト入口点およびサイト出口点等）をサーバログファイルから検出し、次いで、このようなデータをサイトマップ上に重ね合わせる。
ロードウィザード（Load Wizard）モジュールが、このアクティビティデータを使用して、ウェブサイトの負荷テスト用のテストシナリオを生成する。
【０００４】
Gilに付与された米国特許第５，５００，９４１号は、大規模電子システム上でのソフトウェアの正当性確認テストを実行する方法を対象としている。
この方法は、マルコフ連鎖として特別にモデル化された使用コンセプト（Usage Concept）を適用して、システムの予想される使用を事前に実現し、システムの挙動を定義し、統計的測定値を導入するものである。
このソフトウェアシステムの機能要件は、ソフトウェアシステムがこの機能要件を実行する際に遷移する複数の状態を特定することにより、マルコフ連鎖において定義される。
ソフトウェアシステムを或る状態から別の状態へ遷移させる刺激および応答が特定され、各状態遷移の確率が計算される。
ソフトウェアシステムの起動状態で開始して終了状態で終了する使用ケースが定義され、使用プロファイル（Usage Profile）に発生確率の降順で列挙される。
使用プロファイル、刺激、および応答は、自動化テストプログラム内に自動的にコンパイルされ、関連したテスト機器が、自動的にプログラムされて、１組のテストケースを生成する。
この１組のテストケースは、その後、ソフトウェアシステム上で実行される。
１組のテストケースの終了が決定され、この方法は、ソフトウェアシステムの品質を分析して報告する。
【特許文献１】米国特許第６，１８２，２４５号
【特許文献２】米国特許第５，９７４，５７２号
【特許文献３】米国特許第５，５００，９４１号
【発明の開示】
【課題を解決するための手段】
【０００５】
負荷を適用することによってコンピュータシステムをテストする方法は、負荷仕様を受け取ることであって、当該負荷仕様が、システムの少なくとも１つの資源を特定し、かつ、当該資源に適用される負荷を指定する、負荷仕様を受け取ること、および負荷仕様で特定された各資源について、対応する指定された負荷を当該資源に適用すること、を含む。
マシン可読媒体は、この例示の方法を計算デバイスに実行させるソフトウェアまたはコンピュータプログラムもしくは複数のコンピュータプログラムを含むことができる。
【０００６】
負荷を適用することによってコンピュータシステムをテストするデバイスは、ａ）コンピュータシステムにインストールされたソフトウェアであって、当該ソフトウェアが負荷仕様を受け取るように構成され、当該負荷仕様が、システムの少なくとも１つの資源を特定し、かつ、当該資源に適用される負荷を指定するものであり、負荷仕様で特定された各資源について、当該ソフトウェアが対応する指定された負荷を資源に適用するように構成される、コンピュータシステムにインストールされたソフトウェアと、ｂ）少なくとも１つの資源の負荷を監視する手段と、監視された負荷および負荷仕様の少なくとも１つを表示する表示装置と、を備える。
【０００７】
コンピュータシステムをテストするテストシステムは、負荷仕様で特定された少なくとも１つのコンピュータシステム資源に、負荷仕様で指定された対応する負荷を適用する手段であって、当該負荷仕様が当該負荷の大きさを指定する、手段と、少なくとも１つの資源が受ける負荷を監視する手段と、を備える。
【０００８】
添付図面は、本明細書で開示された代表的な実施の形態をより十分に説明するのに使用され、かつ、当業者が代表的な実施の形態およびその固有の利点をより良く理解するのに使用できる視覚表現を提供する。
これらの図面において、同様の参照符号は、対応する要素を特定する。
【発明を実施するための最良の形態】
【０００９】
図１に示すように、最初のブロック１０２において、プロセスが開始し、次いで、次のブロック１０４において、負荷仕様が受け取られる。
この負荷仕様は、コンピュータシステムの資源を特定し、特定した各資源に適用される負荷を指定するものである。
例示のコンピュータシステムの資源には、揮発性メモリ、スタティックメモリまたは不揮発性メモリ、１つまたは２つ以上のハードディスクドライブ、光ドライブ、ネットワーク入出力（Ｉ／Ｏ）、およびＣＰＵ（中央処理装置）が含まれるが、これらに限定されるものではない。
【００１０】
負荷仕様は、ユーザによって提供されるファイル、ストレージから取り出されたファイル、および／またはＧＵＩ（グラフィカルユーザインタフェース）を介してユーザが入力した情報とすることができる。
負荷仕様は、ユーザが提供した情報、例えばユーザが提供した一般的なパラメータに基づいて自動的に生成することができる。
【００１１】
次のブロック１０６において、負荷仕様の正当性が確認される。
例えば、負荷仕様をレビューまたは構文解析して、適切なシンタックス、値、完全性等をチェックするように解析することができる。
この正当性確認は、プロセス、例えばデーモンによって行うことができる。
このプロセスは、ブロック１０４において負荷仕様を受け取るように構成することができる。
ブロックステップ１０８において、テストドライバが、負荷仕様で特定された資源ごとに起動される。
本明細書で上述したデーモンは、例えば、負荷仕様で特定されたシステム資源に対応するテストドライバを起動することができる。
次のブロック１１０において、資源テストが実行され、指定された負荷が特定されたシステム資源に適用される。
資源テストは、その資源に対応するテストドライバが実行もしくは駆動、またはスーパーバイズすることができる。
同じ資源に対する異なる資源テストは、例えばテストドライバが指示するように、逐次かつ／または同時に実行することができる。
また、例えば資源テストの異なるインスタンスを同時または異なる時に実行できるように、資源テストを複数回インスタンス化することもできる。
【００１２】
次のブロック１１２において、テスト対象コンピュータシステムが監視され、指定された資源テストによってコンピュータシステムの特定された資源に適用される負荷の大きさが決定される。
この監視は、本明細書で上述したデーモン等のプロセスが実行することもできるし、さまざまな尺度およびパラメータに従ってコンピュータシステムの性能およびステータスを監視する個別のソフトウェアが実行することもできる。
換言すると、この監視ソフトウェアまたは監視メカニズムは、コンピュータシステム資源が受けた実際の負荷を監視することができる。
監視ソフトウェアは、例えばHewlett-Packard社またはComputer Associates International社から入手できる既存の既製ソフトウェア製品とすることができる。
換言すると、監視は、特定されたシステム資源に適用される実際の負荷の尺度を提供する。
監視ソフトウェアは、モジュールまたはエージェントとして実施したり、例えばテスト対象システムおよび／またはテスト対象システムに接続されたコンピュータ（複数可）上で実行したり、分散形式で実施したり等することができる。
【００１３】
次のブロック１１４において、ブロック１１２で決定された負荷の大きさが、負荷仕様で指定された負荷の大きさと比較される。
この比較は、例えばテストドライバが実行することができる。
次のブロック１１６において、指定された資源テストの実行が、ブロック１１４からの比較結果に基づいて制御される。
例えば、比較によって、測定または決定された負荷が指定された負荷よりも小さいことが示されている場合には、測定または決定された負荷を増加させるように資源テストのオペレーションを調整することができる。
逆に、測定または決定された負荷が指定された負荷よりも大きい場合には、測定された負荷を減少させ、したがって、実際のもしくは測定された負荷を所望のもしくは指定された負荷と一致させるか、または、それらを互いにより一貫したものとするように、資源テストのオペレーションを調整することができる。
この資源テストの制御および調整は、例えば、対応するテストドライバが実行することができる。
次のブロック１１８において、このプロセスは終了する。
【００１４】
図１で説明したプロセスをさまざまな実施の形態と一貫させて変更できることが、当業者には理解されよう。
例えば、制御がブロック１１６からブロック１１２へ戻って、プロセスまたはサブプロセスを継続できることが、当業者には理解されよう。
さらに別の例では、負荷仕様は、負荷の大きさの指示、負荷の継続時間の指示、負荷の継続時間の開始時刻の指示、負荷の継続時間の終了時刻の指示、負荷の継続時間にわたる負荷の大きさの変動の指示等を含むことができる。
例えば、変動は、各時点で所望の値を有する任意の時間の関数（連続または不連続）によって表すことができる。
負荷の大きさの指示は、例えば、対応するシステム資源の最大負荷の百分率を表す値等として表現することができ、例として、最大負荷の９０％を表す「９０」または「０．９０」等として表現することができる。
さらに別の例では、資源テストがシステム資源に適用されている間に、ユーザが負荷仕様の１つまたは２つ以上のパラメータを変更できるように、図１に示すプロセスを適合させることができる。
これらの変更は、直ちに適用することもできるし、現在実行されている資源テストが終了した後の次のテストサイクルにおいて適用することもできる。
例えば、デーモンは、新たな負荷仕様を受け取ることができ、かつ／または、既存の負荷仕様を変更することができ、この新たに受け取った情報の正当性を確認することができ、資源テストを介して実施される適切なテストドライバにこの情報を渡す（必要に応じてテストドライバを起動し、かつ／または、動作を停止させる）ことができる。
１つのテストドライバが１つだけのシステム資源に対応するように、テストドライバを構成することができ、かつ／または、複数のシステム資源に対応するように、テストドライバを選択して構成することができる。
例えば、例示の実施の形態では、テストドライバは、揮発性メモリや不揮発性メモリ等のメモリをテストする資源テストを実行または駆動することができ、また、ＣＰＵをテストする資源テストも実行または駆動することができる。
さらに別の例として、複数の資源に影響を与えるように資源テストを設計することもできる。
例えば、集中的な計算および大量のデータの双方を伴うテストは、ＣＰＵおよびメモリの双方を同時に実行してテストすることができる。
また、負荷仕様は、適用される特定の資源テストを示すこともでき、テストが特定のシステム資源に順次適用されるのか、それとも同時に適用されるのかを示すこともできる。
【００１５】
図２は、別の例示のプロセスを示している。
このプロセスは、テスト対象コンピュータシステムの資源に負荷を適用する資源テストと、資源テストの実行、スーパーバイズ、および調整を行うテストドライバと、テストドライバを管理し、負荷仕様情報を受け取るデーモンとを使用する。
図２に示すように、最初の開始ブロック２０２の後に、制御はブロック２０４に進み、ブロック２０４において、デーモンが実行中であるかどうかの判断が行われる。
ｙｅｓ（はい）の場合には、制御はブロック２０８に進む。
ｙｅｓでない場合には、制御はブロック２０６に進み、ブロック２０６において、新たなデーモンが起動される。
制御はブロック２０６からブロック２０８に進む。
ブロック２０８において、負荷仕様が、例えばデーモンによって受け取られる。
制御はブロック２０８からブロック２１０に進み、ブロック２１０において、負荷仕様が検証され、その正当性が確認される。
これは、例えば、デーモンが負荷仕様をレビューまたは構文解析して、適切なシンタックス、値、完全性等をチェックするように解析することを含むことができる。
負荷仕様が正当でない場合には、制御はブロック２１２に進み、ブロック２１２において、エラーメッセージ等の警告が生成されて、ユーザおよび／またはスーパーバイズプログラムに警告が行われ、次いで、制御はブロック２２４に進み、ブロック２２４において、プロセスは終了する。
別法では、負荷仕様が正当でない場合には、制御はブロック２１２からブロック２０８に戻ることができる。
【００１６】
負荷仕様が正当である場合には、制御はブロック２１０からブロック２１４に進み、ブロック２１４において、負荷仕様で特定された資源に関連した資源テストドライバが始動される。
制御はブロック２１４からブロック２１６に進み、ブロック２１６において、資源テストが、例えば始動された資源テストドライバの指示によって、または、指示の下で起動される。
制御はブロック２１６からブロック２１８に進み、ブロック２１８において、負荷仕様で指定された負荷要求が解析され、その要求で指定された負荷と一致するように現時点の負荷を調整するかどうかの判断が行われる。
調整しない場合には、制御はブロック２２２に進む。
ｙｅｓの場合には、制御はブロック２２０に進み、ブロック２２０において、資源テストは、停止され、開始され、かつ／またはブロック２１８の判断に基づいて調整される。
制御はブロック２２０からブロック２２２に進み、ブロック２２２において、期間が満了したかどうかの判断が行われる。
満了していない場合には、制御はブロック２１８に戻る。
ｙｅｓの場合には、制御はブロック２２４に進み、ブロック２２４において、プロセスは終了する。
この期間は、例えば、負荷仕様で指定されたテスト期間とすることができる。
ブロック２１８の解析は、例えば負荷仕様で指定された特定の資源テストまたは資源に関する特定の継続時間または他の時間に関係した情報も考慮することができ、それに応じて調整を行うことができる。
例えば、資源テストが特定の時点で停止するか、もしくは、開始時点で開始したり、あるいは、指定された期間で終了したりするようにスケジューリングされる場合、その停止または開始は、ブロック２２０で実行することができる。
【００１７】
図３は、例示の実施の形態を示している。
特に、図３は、テスト対象コンピュータシステムＳＵＴ１（３１４）を示している。
このＳＵＴ１は、ネットワークリンク３２７、３２９、３３１をそれぞれ介してコンピュータ３２６、３２８、３３０に接続されている。
また、ＳＵＴ１は、ハードディスクドライブ３０８、メモリ３１０、ＣＰＵ３１２、ネットワークインタフェースカード３１３、およびテストソフトウェア３１４１も含み、表示装置３０６に接続されている。
メモリ３１０は、ランダムアクセスメモリ（ＲＡＭ）、揮発性メモリ、およびスタティックメモリの１つまたは２つ以上を含むこともできるし、これらのメモリで実施することもできる。
図３は、１つのデータストレージドライブ（ハードディスクドライブ３０８）を含むＳＵＴ１を示しているだけであるが、ＳＵＴ１は、複数のディスクドライブを含むことができ、ドライブ（複数可）は、ハードドライブ、光ドライブ、フロッピィディスクドライブ、テープドライブ等を含む１つまたは２つ以上のタイプのものとすることができる。
さらに、図３は、１つのネットワークインタフェースカード３１３のみを有するＳＵＴ１を示しているが、ＳＵＴ１は、複数のネットワークインタフェースカードを含むことができ、各ネットワークインタフェースカードは、複数のポートを含むことができる。
【００１８】
例示の実施の形態では、例えば図１〜図２に関して本明細書で説明したテストプロセスは、ＳＵＴ１上で実行されているテストソフトウェア３１４１によって実行される。
コンピュータ３２６、３２８、および３３０上で適用されたネットワークテスト構成情報３２６１、３２８１、３３０１によって、コンピュータ３２６、３２８、３３０は、ＳＵＴ１とやり取りを行うことが可能になり、それによって、ネットワークＩ／Ｏ負荷を適用することによりネットワークリンク３２７、３２９、３３１をテストすることが可能になる。
ネットワークリンク３２７、３２９、３３１の１つまたは２つ以上をテスト用に選択することができ、それによって、テストデータは、選択されたネットワークリンク（複数可）を通じて送信される。
ネットワークテスト構成情報によって、例えば、コンピュータ３２６、３２８、３３０は、ネットワークリンク３２７、３２９、３３１を介してテストデータを送受信し、例えばＳＵＴ１上で実行されているテストソフトウェア３１４１から受け取った特定のコマンドまたは問い合わせに応答して、トラフィック負荷を適用してネットワークリンクをテストすることができる。
ネットワークテスト構成情報は、コンピュータ３２６、３２８、３３０に、実行されている負荷仕様に従ってＳＵＴ１に接続した指定されたネットワークリンクにトラフィック負荷を適用させる任意のデータ、ソフトウェア、または他のメカニズムとすることができる。
【００１９】
テストソフトウェア３０４１を実行し、かつ、ＳＵＴ１に接続された別個のコンピュータ３０４は、ＳＵＴ１にさまざまな負荷を提供することができ、かつ／または、ＳＵＴ１上で実行されているテストソフトウェア３１４１のオペレーションの制御、調整、および／または監視を行うことができる。
別個のコンピュータ３０４は、負荷仕様、および、ＳＵＴ１上で実行されているテストソフトウェア３１４１に対する更新や変更等の関連情報を提供することができ、それによって、ＳＵＴ１に負荷を行使または適用することができる。
テストソフトウェア３０４１は、例えばテストソフトウェア３１４１および３１８１と同等なフルパッケージとすることもできるし、監視機能および制御機能のみを含むこともできる。
テストソフトウェア３０４１、３１４１、３１８１は、それぞれ、例えば図１〜図２に関して本明細書で説明したテストプロセスおよびテスト機能の一部またはすべてを実行するように構成することができる。
【００２０】
別個のコンピュータ３０４は、要求に応じて、順次または同時に複数のテスト対象システム上でテストオペレーションを調整または実行できるように、１つまたは２つ以上の追加されたテスト対象システム、例えば図３に示すＳＵＴ２に接続することもできる。
本明細書で説明したテストオペレーションは、図３に示すコンピュータ上のテストソフトウェアユニットまたはテストソフトウェアモジュール間において集中形式または分散形式で、個別にさまざまに実行することができる。
例えば、ユーザは、コンピュータ３１４、３０４、および３１８のいずれか１つに負荷仕様を作成またはアップロードして、それ以外のコンピュータの１つに送信して実行することができ、いくつかの資源テストは、テスト対象コンピュータシステム上で実行することができ、他の資源テストは、テスト対象システムとは別個のシステムまたはデバイス上で（例えば、図３に示すコンピュータの１つまたは２つ以上で）実行することができ、或る場所で実行された資源テストは、例えば、別のシステム上で実行されているネットワークドライバおよび／またはデーモンによって、別の場所から監視または制御することができる。
【００２１】
例示の実施の形態では、ＳＵＴ１またはＳＵＴ２に接続されたコンピュータ３０４、３１４、３１８もしくは他の任意のコンピュータは、ＳＵＴ１およびＳＵＴ２のさまざまな負荷を監視することができ、ＳＵＴ１のテストソフトウェア３１４１、ＳＵＴ２のテストソフトウェア３１８１、およびコンピュータ３０４のテストソフトウェア３０４１の１つまたは２つ以上に、図示したリンクまたは他の通信リンクを介して、監視した負荷の表示を提供することができる。
監視ソフトウェアは、テストソフトウェア３１４１、３１８１、３０４１の一部とすることもできるし、個別のソフトウェア（例えば、本明細書で上述した既製の監視ソフトウェア）とすることもでき、例えば、ＳＵＴ１またはＳＵＴ２に接続された任意のコンピュータ上で実施することができ、例えば、コンピュータ３２６、３２８、３３０、３３２、３３４、３３６の１つまたは２つ以上で実施することができる。
表示装置３０２、３０６、３１６は、ユーザから負荷仕様情報を受け取り、ステータス情報および制御オプション、例えば、監視した負荷レベルおよび選択可能な負荷レベルをユーザに提示するグラフィカルユーザインタフェースを形成することができる。
【００２２】
ＳＵＴ２は、ＳＵＴ１の構成と同様の構成で示されており、ハードディスクドライブ３２０、メモリ３２２、ＣＰＵ３２４、ネットワークインタフェースカード３１９、およびテストソフトウェア３１８１を含む。
図３に示すように、ＳＵＴ２は、表示装置３１６（例えば、陰極線管、液晶表示装置等）にも接続され、ネットワークリンク３３３、３３５、３３７を介してコンピュータ３３２、３３４、および３３６に接続されている。
ＳＵＴ１と同様に、ＳＵＴ２は、複数のデータストレージデバイスまたはドライブ、複数のネットワークインタフェースカード等を含むことができる。
コンピュータ３３２、３３４、３３６は、コンピュータ３２６、３２８、３３０のネットワークテスト構成情報と同様の機能を実行するネットワークテスト構成情報３３２１、３３４１、および３３６１を含むことができる。
当業者は、図３に示すコンピュータのそれぞれが、本明細書で開示した方法を介してテストを行うことができる他のデバイスまたは資源、例えば光ドライブ、フロッピィディスクドライブ等を含むこともできるということを理解するであろう。
【００２３】
図４は、ユーザが負荷仕様を定義または変更するのに使用できる一例のＧＵＩを示している。
図４に示すように、ＧＵＩは、テストされる資源、例えばメモリ、ＣＰＵ、ディスク、およびネットワークを表すラベルおよび／または画像のリストを含むことができる。
また、ＧＵＩは、各資源の可能なまたは利用可能な負荷の範囲、および各資源の選択された負荷レベルの表示を含むこともできる。
図４に示すように、範囲はバーによって表すことができ、バーのポインタまたはマークが、その範囲の選択された値を表すことができる。
例えば、図４は、メモリに対応するバーが０％〜１００％の範囲を示す場合に、当該バーが、選択された値である７５％にマーカを有することを示している。
図４は、ＣＰＵ、ディスク、およびネットワークの資源の同様の機能を示しており、ここでは、選択された負荷値は、それぞれ４０％、７０％、および５０％である。
また、図４のＧＵＩには、負荷仕様を定義する、選択した１組の負荷値の実行の開始または停止をユーザが選択できる「開始」ボタンおよび「リセット」ボタンも含まれる。
ＧＵＩには、他の特徴を含めることができ、他のグラフィカル技法またはメカニズムを使用して、情報を表現し、受け取ることができる。
【００２４】
次に、「ＬＯＡＤＧＥＮ」と呼ばれる例示の実施の形態について、資源テスト、テストドライバ、および関連した問題をより詳細に説明する。
このＬＯＡＤＧＥＮは、テストデーモン、１組のテストドライバ、および資源テストを含む。
ＬＯＡＤＧＥＮは、コンピュータシステム、例えばＨＰ−ＵＸシステムにおいて、制御される集中した資源負荷をユーザが生成するようにするツールである。
ＬＯＡＤＧＥＮは、実世界のようなアプリケーションと共に使用されて、コンピュータシステムを実行する所望の負荷の組み合わせおよびパターンを生成する。
【００２５】
テストエリアは、一般的なテストカテゴリーである。
各テストエリア内には、特定のテストエリアを実行する１つまたは２つ以上のテストが存在する。
テストエリアのほとんどは、メモリテストエリア、ＣＰＵテストエリア、ネットワークテストエリア、ディスクテストエリア等の資源を指すことができる。
【００２６】
資源テストは、特定の資源またはテストエリアにストレスを加える実際のテストである。
テストエリアごとに２つ以上の資源テストが存在し得る。
すべてのテストエリアが資源構成ファイルを必要とするとは限らない。
例えば、ディスクテストの場合、テスト用としてどのディスクおよび／またはどのファイルシステムかを資源構成ファイルで指定することができ、したがって、ディスクテストは、どのデバイスがテストで使用されるかを知る。
しかし、メモリテストの場合、メモリの仕様は必要とされない。
【００２７】
テストドライバは、１つのテストエリアの資源テスト、テストスケジュール、およびテストレベルを管理することができる。
テストエリアごとにテストドライバが存在し得る。
サブテストは、別の資源テストと同じ負荷集中を有する資源テストであり、同じテストドライバによって管理される。
テストエリアが、同じテストドライバによって管理される２つまたは３つ以上の資源テストを有する場合には、それらの資源テストは、サブテストとして知られる。
【００２８】
「ｌｏａｄｇｅｎｄ」は、ユーザのテスト要求の管理を担当するプログラムである負荷生成デーモンを指す。
【００２９】
ＬＯＡＤＧＥＮは、制御可能な集中した資源テストを使用することができる。
これらのテストは、集中させることができ、かつ、人工的なものとすることができる。
人工的なテストは、実世界のようなアプリケーションと共に使用することができる。
例えば、実世界のアプリケーションがテスト対象システム上で実行されているのと同時に、人工的なテストを適用して、システムがハンドリングしなければならない追加されたまたは「バックグラウンド」の負荷を提供することができる。
本明細書で説明したように、追加された負荷は、ネットワーク接続を介したテスト対象システムへの膨大なデータ転送の形、例えばＦＴＰ（ファイル転送プロトコル）トラフィック、ディスクアクセス、テスト対象システムのＣＰＵ資源を必要とするタスク等の形を取ることができる。
例えば、人工的なテストは、システムのサーバが、テスト対象システムの顧客またはオペレータに受け入れることができる性能レベルを提供すると同時に、指定された負荷をハンドリングするために、どれだけの規模または能力を有するべきかを決定するのに役立つことができる。
【００３０】
ＬＯＡＤＧＥＮが多くの異なる状況で実世界のアプリケーションをテストする能力をユーザに提供することを可能にするように、資源テストを注意深く設計することができる。
具体的には、ユーザは、目標とする負荷の生成を制御する。
例えば、ＬＯＡＤＧＥＮによって、ユーザは、システム資源スケジュールキューを生成することによりシステム資源の使用をスケジューリングすることが可能になる。
ユーザは、彼／彼女がこの資源テストのスケジュールをどのように作成するかを完全に制御することができる。
また、ユーザは、特にテストの継続時間および資源使用レベルの特徴について、資源テストがどのように振舞うかを指定または選択する際に大きな柔軟性も有する。
これらの能力によって、ユーザは、さまざまな方法でシステムをテストすることが可能になる。
例えば、ユーザは、資源スパイク（resource spike）、すなわち、指定された資源の大きな割合が或る期間使用され、かつ、使用の割合の変化の比率が大きい状況を作成することができる。
また、ユーザは、例えば、資源のユーザ指定部分が取得されて、比較的長い期間保持される時に発生する、持続した資源の使用を作成することもできる。
【００３１】
図６は、例示の負荷パターンを示している。
図６において、負荷レベルはｙ軸に沿った０％〜１００％の負荷範囲の百分率の点で表され、時間はｘ軸に沿って表される。
時間の単位は秒、分、またはそれより長いもしくは短い時間単位とすることができる。
図６に示すように、同じ負荷パターンが３回繰り返し、負荷レベルが急激に変化する「スパイク」負荷を含む。
テスト対象システムの資源のいずれにも、この負荷パターンだけでなく、他の負荷パターンも適用することができる。
【００３２】
ＬＯＡＤＧＥＮツールは、３つの主要なコンポーネントを含むことができる。
第１のコンポーネントは、デーモン「ｌｏａｄｇｅｎｄ」である。
このデーモンプログラムは、ユーザのテスト要求を管理して、テストドライバ（複数可）と通信し、テストドライバに適切なテストスケジュールを送信する。
第２のコンポーネントは、テストドライバによって形成されるものである。
各テストドライバは、１つのテスト資源エリアのテストスケジュールおよび資源テスト負荷または使用レベルを管理する。
テストドライバは、ｌｏａｄｇｅｎｄが起動および停止させることができる。
第３のコンポーネントは、資源テストを含む。
各資源テストは、１つの資源エリアにストレスを加えることに集中することができる。
資源テストは、その資源エリアのテストドライバが管理することができる。
２つまたは３つ以上の資源テスト（同じテストエリア内に存在する）が同じ負荷の集中を有し、同じテストドライバが管理するものである場合、各テストは、「サブテスト」として知られることができる。
【００３３】
ＬＯＡＤＧＥＮツールは、任意の個数のテストエリアまたは資源をサポートするように増大させることができる。
例示のテストエリアまたは資源には、メモリ、ＣＰＵ、ディスクＩ／Ｏ、およびネットワーク（例えば、ネットワークＩ／Ｏ）が含まれるが、これらに限定されるものではない。
【００３４】
ＬＯＡＤＧＥＮは、構成ファイルモードおよび対話モードの２つの異なるモードをサポートすることができる。
構成ファイルモードでは、このツールは、負荷仕様、例えば完全なまたは十分な負荷仕様を含むファイルを受け取る。
対話モードでは、ユーザが、負荷仕様を作成し、かつ／または、既存の負荷仕様を変更して、直ちにまたは後に使用することができる。
例えば、対話モードでユーザが作成した負荷仕様を、後に、構成ファイルモードの負荷仕様として使用することができる。
【００３５】
ファイルレイアウトに関して、ＬＯＡＤＧＥＮは、専用のファイルシステムにインストールすることができる。
環境変数ＬＯＡＤＧＥＮ＿ＨＯＭＥは、ＬＯＡＤＧＥＮをインストールできるＬＯＡＤＧＥＮ用のディレクトリを指定することができる。
ユーザがＬＯＡＤＧＥＮ＿ＨＯＭＥを明示的に設定しない場合には、システムが、デフォルトで／ｖａｒ／ｏｐｔ／ｌｏａｄｇｅｎにすることができる。
ユーザは、／ｖａｒ／ｏｐｔ／ｌｏａｄｇｅｎ以外のディレクトリにＬＯＡＤＧＥＮをインストールする場合に、ＬＯＡＤＧＥＮ＿ＨＯＭＥを正確に設定しなければならないことに留意されたい。
図５は、ＬＯＡＤＧＥＮ＿ＨＯＭＥから分岐する例示のファイルレイアウトを示している。
このファイルレイアウトは、「ｂｉｎ」、「ｌｏａｄｇｅｎｄ」、「ｅｔｃ．」、「ｃｏｎｆｉｇ＿ｆｉｌｅ」、「ｒｓ＿ｃｏｎｆ」、「ｓｃｈｅｄｕｌｅｓ」、「ｌｏｇｓ」、「ｒｓ＿ｔｅｓｔｓ」、「ｓｕｐｐｏｒｔ」、および「ｖａｌｉｄ＿ｔｅｓｔｓ」を含む。
【００３６】
ｂｉｎディレクトリは、ＬＯＡＤＧＥＮデーモンｌｏａｄｇｅｎｄを含む。
また、ｂｉｎディレクトリは、ユーザが必要とすることがある任意のＬＯＡＤＧＥＮツールも含む。
このようなツールには、テスト結果解析ツール、報告生成ツール等が含まれ得るが、これらに限定されるものではない。
ｅｔｃディレクトリは、構成ファイルテンプレート、さまざまな資源構成ファイル用のディレクトリ（ｒｓ＿ｃｏｎｆ）、および、テストスケジュール用のディレクトリ（ｓｃｈｅｄｕｌｅｓ）を含む。
【００３７】
ｌｏｇｓディレクトリは、各テストエリア用のログディレクトリに加えて、ＬＯＡＤＧＥＮデーモンｌｏａｄｇｅｎｄ用のログファイル（ｌｏａｄｇｅｎ．ｌｏｇ）も含む。
すなわち、各テストエリアまたは資源は、自身のログファイルが記憶されるそれ自身のログディレクトリを有する。
例えば、ユーザがメモリテストをスケジューリングすると、ログディレクトリは、ｍｅｍｏｒｙと呼ばれるディレクトリを含み、そのディレクトリには、ｍｅｍｏｒｙ．ｌｏｇと呼ばれる少なくとも１つのファイルが存在する。
テストエリアは、必要とするのと同数のログファイルを有することができる。
ｒｓ＿ｔｅｓｔｓディレクトリは、各資源テストエリア用のディレクトリを含む。
それらのディレクトリは、実際の資源テストを含む。
例えば、ｒｓ＿ｔｅｓｔｓは、ｍｅｍｏｒｙと呼ばれるディレクトリを含むことができ、ｍｅｍｏｒｙは、ｍｅｍｏｒｙ＿ｔｅｓｔと呼ばれるファイルを含む。
サポートディレクトリは、ＬＯＡＤＧＥＮが必要とするあらゆるファイルまたはデータを含む。
【００３８】
構成ファイルモードでサポートされる４つのコマンド呼び出しがある。
すなわち、
１）ｌｏａｄｇｅｎｄ  −ｆ  ＜ｃｏｎｆｉｇ＿ｆｉｌｅ（構成ファイル）＞、
２）ｌｏａｄｇｅｎｄ−ｒ  ｔｅｓｔ＿ｎａｍｅ（テスト名）  ＜ｔｅｓｔ＿ｎａｍｅ＞、
３）ｌｏａｄｇｅｎｄ  −ｉ、および、
４）ｌｏａｄｇｅｎｄ  −ｋ  ＜ｔｅｓｔ＿ｎａｍｅ  ｔｅｓｔ＿ｎａｍｅ＞がある。
１）は、＜ｃｏｎｆｉｇ＿ｆｉｌｅ＞で指定されたテストを実行するものである。
２）は、テストスケジュールを再読み出しすることによってテスト（複数可）を再起動するものである。
３）は、現時点の実行中のプロファイルを表示するものである。
４）は、すべてのテスト（実行中のものおよびスケジューリングされたもの）に加えてｌｏａｄｇｅｎデーモン（ｌｏａｄｇｅｎｄ）をキル（kill）するか、または、指定されたテストのみをキルするものである。
ユーザが−ｆを指定するものの、構成ファイルを含まない場合、ｌｏａｄｇｅｎｄは、＄ＬＯＡＤＧＥＮ＿ＨＯＭＥ／ｅｔｃ／ｃｏｎｆｉｇ＿ｆｉｌｅのデフォルトの構成ファイルを使用することができる。
【００３９】
構成ファイルモードでは、ユーザは、３つのタイプのファイルでテストを制御することができる。
すなわち、
１）実行されるテストを指定する単一の構成ファイル、
２）テストスケジュール、例えば、テストエリアごとに１つのテストスケジュール、および、
３）資源テスト構成ファイル、例えば、テストエリアごとに１つの資源テスト構成ファイル
でテストを制御することができる。
【００４０】
例示の構成ファイルシンタックスでは、構成ファイルは、ラインごとに１つのエントリのさまざまなエントリを含む。
各エントリは、コメントまたはテスト指定子でなければならない。
具体的には、コメントは「＃」で開始するあらゆるラインであり、オペレーション中は無視される。
テスト指定子は、ユーザがどのテストを実行したいかを示すものである。
テスト指定子は、以下の例示のシンタックス、すなわちＴｅｓｔ  ＜Ｔｅｓｔ  Ｎａｍｅ＞  ＜Ｔｅｓｔ  Ｓｃｈｅｄｕｌｅ＞を有することができる。
ここで、＜Ｔｅｓｔ  Ｎａｍｅ＞は、任意の正当なテストとすることができ、例えば、正当なテストのリストにおける任意のテストとすることができる。
【００４１】
例示のテストスケジュールシンタックスでは、テストスケジュールは、４つの可能なフォーマット、すなわち、１．ｔｅｓｔ＿ｄｕｒａｔｉｏｎ（テスト継続時間）およびｌｏａｄ＿ｌｅｖｅｌ（負荷レベル）；２．Ｌｏｏｐ（ループ）；３．Ｓｔｏｐ（停止）；および４．Ｆｏｒｅｖｅｒ  ｌｏａｄ＿ｌｅｖｅｌ（絶えず、負荷レベル）を有する一連のエントリを含む。
【００４２】
具体的には、ｔｅｓｔ＿ｄｕｒａｔｉｏｎは、要求されたテストが、指定された負荷レベルで実行される期間を指定する値である。
ｔｅｓｔ＿ｄｕｒａｔｉｏｎは、フォーマットｈｈｈｈｈ：ｍｍ：ｓｓを有する。
ここで、ｈｈｈｈｈは０００００〜９９９９９の範囲の時間数であり、ｍｍは００〜５９の範囲の分数であり、ｓｓは００〜５９の範囲の秒数である。
ｌｏａｄ＿ｌｅｖｅｌ値は、指定された資源の消費すべき量を記述し、０〜１００の値とすることができる。
ここで、値０は、資源が全く消費されないことを意味し、値１００は、システム資源のすべて（または、より現実的には可能な限り多く）が消費されることを意味する。
値０は、テスト呼び出しの間のギャップを生成するのに使用することができる。
大きなｌｏａｄ＿ｌｅｖｅｌを指定する際には、システムがこのような高い負荷で応答しない可能性があるので、ユーザは慎重になる必要がある場合がある。
例えば、システムの物理メモリの（ｌｏａｄ＿ｌｅｖｅｌ）％を消費するように試みることによってメモリをテストする際に、ｌｏａｄ＿ｌｅｖｅｌ値を使用することができる。
また、例えば、時間の（ｌｏａｄ＿ｌｅｖｅｌ）％を実行し、残りの時間をスリープするように試みることによってＣＰＵをテストする際にも、ｌｏａｄ＿ｌｅｖｅｌ値を使用することができる。
【００４３】
各資源テストについて、対応する資源構成ファイルが、＄ＬＯＡＤＧＥＮ＿ＨＯＭＥ／ｅｔｃ／ｒｓ＿ｃｏｎｆ／＜ｔｅｓｔ＿ｎａｍｅ＞に存在し得る。
資源構成ファイルは、それ自身のテストドライバが使用することができ、そのフォーマットおよび内容は、各テストエリアについて一意とすることができる。
【００４４】
構成ファイルの使用を実証するために、以下の例示の構成ファイルを考察することにする。
# Configuration File Example（構成ファイル例）: $LOADGEN_HOME/etc/config_file
# Test Memory, Network and CPU but not Disk（テストメモリ、ネットワーク、およびＣＰＵ。ただし、ディスクを除く）
Test Memory /var/opt/loadgen/etc/schedules/mem_variable
Test CPU cpu_spikes
Test Network $LOADGEN_HOME/etc/schedules/network_consistent
Test Disk
# Memory Test Schedule example（メモリテストスケジュール例）: $LOADGEN_HOME/etc/schedules/mem_variable
# do a variable test in a 4-hour cycle（４時間のサイクルで可変テストを行う）
01:00:00 30
00:30:00 60
00:30:00 20
00:30:00 0
00:30:00 40
00:30:00 20
00:30:00 50
Loop
#CPU Test Schedule（ＣＰＵテストスケジュール）:$LOADGEN_HOME/etc/schedules/cpu_spikes
# Do some different spikes in a 2-hour cycle（２時間のサイクルでいくつかの異なるスパイクを行う）
00:01:00 25
00:01:00 30
00:01:00 35
00:01:00 40
00:01:00 45
00:01:00 50
00:01:00 55
00:01:00 60
00:01:00 65
00:01:00 70
00:20:00 0
00:05:00 80
00:25:00 0
00:05:00 50
00:05:00 80
00:05:00 50
00:30:00 0
00:05:00 80
00:10:00 0
Loop
# Network Test Schedule（ネットワークテストスケジュール）: $LOADGEN_HOME/etc/schedules/network_consistent
# Run a medium load of network test all the time（常時、中間負荷のネットワークテストを実行する）
Forever 50
3.2 LOADGEN Commands（ＬＯＡＤＧＥＮコマンド）
3.2.1 loadgend -f
To start loadgend, you must use the -f option: （ｌｏａｄｇｅｎｄを起動するには、−ｆオプションを使用しなければならない）
loadgend -f <config_file>
【００４５】
ユーザが正当な−ｆコマンドを入力し、ｌｏａｄｇｅｎｄがまだ実行されていない（ファイル／ｖａｒ／ｒｕｎ／ｌｏａｄｇｅｎｄ．ｐｉｄが存在しないか、または、このファイルが正当なｐｉｄを有しない）場合には、ｌｏａｄｇｅｎｄは以下のことを行うことができる。
１．ｌｏａｄｇｅｎｄは起動され、そのｐｉｄはファイル／ｖａｒ／ｒｕｎ／ｌｏａｄｇｅｎｄ．ｐｉｄに保存される。
２．構成ファイル名を保存する。
３．ユーザが指定した（またはデフォルトの）構成ファイルを読み出し、構成ファイルおよびテストスケジュールのシンタックスチェックを行う。
４．或るパラメータ、すなわち完全に適格なスケジュールファイル用パス名で、（テスト名によってマッピングされた）テストドライバを呼び出す。ｌｏａｄｇｅｎｄは、呼び出すすべてのテストドライバのｐｉｄを記憶している。
５．ユーザが−ｆコマンドを入力した時に、ｌｏａｄｇｅｎｄがすでに実行されている場合には、ｌｏａｄｇｅｎｄのこの新たな呼び出しによって、エラーメッセージが表示され、この新たな呼び出しは終了する。
この新たな呼び出しは、現在実行されているｌｏａｄｇｅｎｄに影響を与えない。
【００４６】
ｌｏａｄｇｅｎｄは、例えば、フォーマット：ｌｏａｄｇｅｎｄ  −ｋ  ＜ｔｅｓｔ＿ｎａｍｅ  ｔｅｓｔ＿ｎａｍｅ  …＞を有する「ｌｏａｄｇｅｎｄ  −ｋ」を使用してキルすることができる。
ｌｏａｄｇｅｎデーモンが実行されていない場合には、パラメータ＜ｔｅｓｔ＿ｎａｍｅ  ｔｅｓｔ＿ｎａｍｅ  …＞は無視される。
コマンド「ｌｏａｄｇｅｎｄ  −ｋ」は、システムに対して何も行わないが、ｌｏａｄｇｅｎデーモンが実行されていないことを告げるエラーメッセージを返すことができる。
コマンドにパラメータ＜ｔｅｓｔ＿ｎａｍｅ  ｔｅｓｔ＿ｎａｍｅ  …＞がなく、ｌｏａｄｇｅｎデーモンが実行されている場合には、ｌｏａｄｇｅｎデーモンは、ｌｏａｄｇｅｎデーモンが実行されていることをユーザに通知し、ユーザがｌｏａｄｇｅｎデーモンを本当にキルしたいのかどうかをユーザに尋ねる。
ユーザが肯定的に答えると、ｌｏａｄｇｅｎデーモンは、実行中のすべてのテストドライバにＳＩＧＴＥＲＭ信号を送信することができる。
すべてのテストドライバは、この信号を受信すると、自身のすべてのテストを終わらせ、そして終了する。
すべてのテストドライバが終了すると、ｌｏａｄｇｅｎデーモンは、／ｖａｒ／ｒｕｎ／ｌｏａｄｇｅｎｄ．ｐｉｄを削除して終了する。
少なくとも１つのｔｅｓｔ＿ｎａｍｅがコマンドラインに指定されると、ｌｏａｄｇｅｎｄは、すべてのｔｅｓｔ＿ｎａｍｅ（複数可）が実行されていることを保証する。
いずれのテストも実行されていない場合には、ｌｏａｄｇｅｎｄは、指定されたテスト（複数可）が実行されていないことをユーザに通知して終了する。
指定されたすべてのテストが実行されている場合には、ｌｏａｄｇｅｎｄは、ユーザが、指定したテスト（複数可）をキルしたいかどうかをユーザに問い合わせることができる。
ユーザが肯定的に答えると、ｌｏａｄｇｅｎｄは、適切なテストドライバ（複数可）にＳＩＧＴＥＲＭ信号を送信する。
テストドライバ（複数可）は、この信号を受信すると、自身のすべてのテストを終わらせ、そして終了する。
この場合、ｌｏａｄｇｅｎデーモンはキルされない。
【００４７】
テストの実行および現時点のテストのスケジュールは、フォーマット
ｌｏａｄｇｅｎｄ  −ｒ  ｔｅｓｔ＿ｎａｍｅ  ＜ｔｅｓｔ＿ｎａｍｅ＞…
を有する「ｌｏａｄｇｅｎｄ  −ｒ」コマンドを使用して変更することができる。
「ｔｅｓｔ＿ｎａｍｅ」は、正当なテストを列挙するファイルｖａｌｉｄ＿ｔｅｓｔｓのエントリの１つであるべきである。
このコマンドには、最低限１つのｔｅｓｔ＿ｎａｍｅが必要とされる。
ユーザは、サポートされているテスト数までの任意の個数のテストを指定することができる。
ｌｏａｄｇｅｎデーモンが実行されていない場合には、コマンド「ｌｏａｄｇｅｎｄ  −ｒ」は、システムに対して何も行わず、ｌｏａｄｇｅｎデーモンが実行されていないことを示すエラーメッセージを返すことができる。
ｌｏａｄｇｅｎデーモン実行されており、指定されたテストも実行されている場合には、ｌｏａｄｇｅｎデーモンは、ｌｏａｄｇｅｎデーモンが実行されており、テストが実行されていることをユーザに通知することができ、ユーザが＜ｔｅｓｔ＿ｎａｍｅ  …＞のテストを本当に再起動したいかどうかをユーザに尋ねることができる。
ユーザが肯定的に答えると、ｌｏａｄｇｅｎデーモンは、ｔｅｓｔ＿ｎａｍｅ（複数可）の実行スケジュールのシンタックスチェックを行う。
シンタックスチェックが通過すると、ｌｏａｄｇｅｎデーモンは、対応するテストドライバに「ＳＩＧＨＵＰ」信号を送信する。
テストドライバは、この信号を受信すると、現時点のスケジュールを停止し、テストスケジュールファイルおよび資源構成ファイルを再読み出しし、次いで、現時点の実行されているテストを変更する。
テストの特定の設計または実施に応じて、テストを再調整または停止して、再起動することができる。
ｌｏａｄｇｅｎデーモンは実行されているが、指定されたテストが実行されていない場合には、ｌｏａｄｇｅｎデーモンは、現時点の実行されている構成ファイルを再オープンして、指定されたテストのテストスケジュールを見つける。
指定されたテストのテストスケジュールファイルが突き止められると、ｌｏａｄｇｅｎデーモンは、そのテストスケジュールファイルで、指定されたテストのテストドライバを始動する。
指定されたテストのテストスケジュールファイルが、構成ファイルに指定されていない場合には、ｌｏａｄｇｅｎデーモンは、エラーメッセージを表示して終了する。
【００４８】
「ｌｏａｄｇｅｎｄ  −ｒ」は、新たなスケジュールファイルを取り込むことはできないが、テストドライバは、テストスケジュールファイルおよび資源構成ファイルを再オープンし、それに応じてテストを再起動することに留意されたい。
したがって、ユーザが資源構成ファイルを変更する必要があり、かつ／または、現時点のテストスケジュールを変更する必要がある場合に、コマンド「ｌｏａｄｇｅｎｄ  −ｒ」を使用することができる。
ユーザが真新しいテストスケジュールを起動したい場合には、以下の手順を使用することができる。
１．新しいテストスケジュールを生成する。
２．必要に応じて、資源構成ファイルを変更する。
３．「ｌｏａｄｇｅｎｄ  −ｋ  ｔｅｓｔ＿ｎａｍｅ」を実行して、現時点のスケジュールを停止する。
４．現時点の構成ファイルの旧スケジュールを新しいスケジュールファイル名に置き換える。
５．「ｌｏａｄｇｅｎｄ  −ｒ  ｔｅｓｔ＿ｎａｍｅ」を実行して、テストスケジュールを再起動する。
【００４９】
現時点の実行プロファイルに関する情報を得るには、フォーマットｌｏａｄｇｅｎｄ  −ｉを有するコマンド「ｌｏａｄｇｅｎｄ  −ｉ」を使用することができる。
このコマンドは、現時点で実行されているいずれのテストも変更せず、ｌｏａｄｇｅｎデーモンを変更しない。
このコマンドは、実行されている構成ファイル名および現時点で実行されているテストのリストを表示する。
【００５０】
テストドライバに関して、ファイルｖａｌｉｄ＿ｔｅｓｔｓで指定されるようなサポートされた各テストエリアは、概念的には、＄ＬＯＡＤＧＧＥＮＨＯＭＥ／ｒｓ＿ｔｅｓｔｓ／＜ｔｅｓｔ＿ｎａｍｅ＞／＜ｔｅｓｔ＿ｎａｍｅ＞＿ｔｅｓｔの下の名前＜ｔｅｓｔ＿ｎａｍｅ＞＿ｔｅｓｔを備えた資源テストドライバを有することができる。
テストドライバは、テストスケジュールの管理ならびに実際の資源テストの起動および停止を担当する。
テストドライバは、ｌｏａｄｇｅｎデーモンからの少なくとも２つの信号、すなわち、
１）ＳＩＧＴＥＲＭ、および、
２）ＳＩＧＨＵＰをハンドリングする。
１）は、すべてのテストを終わらせて終了するものである。
２）は、現時点のスケジュールを停止して、テストスケジュールファイルおよび資源構成ファイルを再オープンし、現時点の実行されているテストを変更するものである。
テストドライバの主要なタスクは、テストのｌｏａｄ＿ｌｅｖｅｌをハンドリングすることである。
テストドライバは、ｌｏａｄ＿ｌｅｖｅｌの増減を制御できるように、テスト呼び出しを管理可能なサイズに分割しなければならない。
この概念をさらに説明するために、メモリテストおよびメモリテストドライバを考察することにする。
メモリテストは、指定された量の物理メモリを消費する単純なプログラムとすることができる。
ユーザが、３０のｌｏａｄ＿ｌｅｖｅｌを要求した場合、メモリテストドライバは、物理メモリの３０％を計算し、消費する必要のあるメモリ量を決定する。
各資源テストプロセスが実際のメモリの１％を占める場合、メモリテストを１回コールする代わりに、メモリテストドライバがメモリテストを３０回呼び出して、３０のｌｏａｄ＿ｌｅｖｅｌを適用することになる。
これは、物理メモリの使用に対してはるかに多くの制御をユーザに与えることができる。
この例を続けて、次に、ユーザは、ｌｏａｄ＿ｌｅｖｅｌ２０でメモリテストを実行したいものとする。
メモリテストドライバは、メモリテストの３０個のコピーが現時点で実行されていることを理解する。
そして、２０％の物理メモリの使用に到達するには、メモリテストドライバは、メモリテストの３０個のコピーのうちの１０個をキルする必要がある。
１％とは異なる負荷の増加、例えば、これより小さいか、または、大きな増加を適用するように資源テストを設計または構成することができる。
また、資源テストドライバおよび資源テストを別個のものとする必要がないことにも留意されたい。
ドライバおよび資源テストの双方の任務または機能を実行する資源テストを有することも全く可能である。
【００５１】
資源テストは、或る定量的な方法で制御できるように設計または構成しなければならない。
例えば、メモリ資源テストは、ユーザが指定した量の物理メモリを割り当ててロックできるように構成することができる。
例示の実施の形態では、各資源テストは、１つの資源にのみ影響を与えるように集中する。
また、資源テストは、主として、１つまたは２つ以上の指定された資源にのみ影響を与え、他の資源には最小限の影響しか与えないように設計または構成することもできる。
【００５２】
メモリテストエリアにおいて、例示のメモリテストは以下のことを行うことができる。
すなわち、システムに存在する物理メモリの量を計算すること；現在使用されている物理メモリの量を計算すること；ｌｏａｄ＿ｌｅｖｅｌに基づきメモリテストが消費すべき物理メモリの量（例えばページで）、および、利用可能なメモリおよび使用中のメモリの２つの値を計算すること；ならびに、その後、この値をｌｏａｄ＿ｌｅｖｅｌによって分割し、新たな値ｍｅｍを生成すること；を行うことができる。
ｌｏａｄ＿ｌｅｖｅｌの各百分率の点について、メモリのｍｅｍの量を消費するプログラムを実行することができる。
すなわち、ユーザが３０％のｌｏａｄ＿ｌｅｖｅｌを要求すると、メモリテストは、メモリの約１％をそれぞれ割り当ててロックする３０個の個別のプロセスを呼び出す。
テストドライバが生成する各子プロセスは、全システムメモリの１％を単に割り当て、ｍｌｏｃｋ（）を使用してそのメモリをＲＡＭにロックするように試み、次いで、永久にスリープする。
ユーザはシステムのＲＡＭの１００％をロックできないので、ｍｌｏｃｋ（）の失敗はエラーとみなされないことに留意されたい。
【００５３】
スケジュールファイルのエントリが完了し、新たなスケジュールファイルのエントリが実行されると、新たなレベルと一致するために、子プロセスが生成されるか、または、キルされる。
例えば、スケジュールが５０％、次いで８０％、次いで６０％のレベルのエントリを含んでいた場合、メモリテストは、５０個の子プロセス（５０％）を生成し、指定された量の時間を待機し、次いで、さらに３０個を生成し（８０％）、その指定された量の時間を待機し、次いで、２０個の子プロセスをキルする（６０％）。
【００５４】
ＣＰＵテストエリアにおいて、例示のＣＰＵテストは、ビットシフト、整数算術演算および浮動小数点算術演算、ＡＮＤ／ＯＲ／ＸＯＲ演算、条件分岐、タイプキャスティング、他のＣＰＵ命令等のＣＰＵ集中オペレーションを実行することができる。
ＣＰＵテストは、Ｉ／Ｏコールおよび他のブロックシステムコールをできるだけ回避することができる。
例示の実施の形態では、テストドライバの親プロセスは、プロセッサごとに１つの子プロセスを生成して、作業を実行する。
負荷レベルは、ＣＰＵテストの子プロセスの実行時間のスリープ時間に対する百分率を表す。
これは、プログラム「ｔｏｐ」が表示する％ＣＰＵフィールドに対応することができる（例えば、負荷レベルが１００である場合、ＣＰＵテストは決してスリープすることはない。負荷レベルが０である場合、ＣＰＵテストは、ほとんどすべての時間、スリープしている。負荷レベル５０である場合、５０クロックサイクルごとに、ＣＰＵテストは５０クロックサイクルの間実行し、また、５０クロックサイクルの間スリープする）。
ＣＰＵテストは、子プロセスが自身のすべてのＣＰＵオペレーションを行うのに使用するルーチンを有することができる。
テストが最初に起動すると、テストドライバプロセスは、このルーチンをループで実行して、このルーチンが要するクロックチック数を決定する。
したがって、テストが最初に起動すると、ＣＰＵ負荷にはスパイクが存在することになる。
このスパイクは約１秒間持続することができ、その間、ＣＰＵテストは、目下の特定のテスト対象システムの時間を計測する。
このルーチンが使用するクロックチックは、このルーチンを実行するのに要する実際の時間と同じではなく、テストが起動する際にシステムがすでにビジーであるかどうかは重要でないことに留意されたい。
ＣＰＵテストは、そのＣＰＵルーチンが使用するクロックチック数が分かると、所望のレベルを達成するために、このルーチンのコール間のスリープのクロックチック数が分かる。
ＣＰＵルーチンのコール間のこれらのスリープは、ｎａｎｏｓｌｅｅｐ（）等の関数を使用して達成することができる。
各スケジュールファイルのエントリが完了すると、すべての子プロセスはキルされる。
次のスケジュールファイルのエントリによって、新たなレベルで実行される、プロセッサごとに１つの新たな子プロセスが生成される。
【００５５】
ディスクテストエリアにおいて、例示のディスク資源テストは、２つのマルチスレッドのサブテストを含むことができる。
第１のサブテストは、ブロックバッファリングされたか、または、「クックされた（cooked）」ファイルシステムにおけるユーザが指定したファイルに対してディスクオペレーション（例えば、ｏｐｅｎ（）、ｗｒｉｔｅ（）、ｆｓｙｎｃ（）、ｐｒｅａｄ（）、ｌｓｅｅｋ（）、およびｃｌｏｓｅ（））を実行する読み出し／書き込みテストとすることができる。
ｆｓｙｎｃ（）コールは、ディスクへの物理的な書き込みを強制する。
ファイルシステムがクックされた状況では、ｐｒｅａｄ（）は、物理的なディスクからではなく、バッファキャッシュからのものとなる。
第２のサブテストは、同様のディスクオペレーション（例えば、ｏｐｅｎ（）、ｐｒｅａｄ（）、ｌｓｅｅｋ（）、ｃｌｏｓｅ（））を実行するが、クックされていない、すなわち「生の」ファイルシステムに対して実行する読み出し専用テストとすることができる。
第１のサブテストと異なり、ファイルシステムは生であるので、物理的な読み出しオペレーションが実行される。
【００５６】
これらのディスク資源テストの負荷レベルは、数組のディスクオペレーションの間にｎａｎｏｓｌｅｅｐ（）を挿入することによって管理することができる。
システム応答時間を注意深く監視することによって、ディスク資源テストは、或る期間のＸ％の間作業を実行し、その期間の（１００−Ｘ）％の間スリープするように試みる。
例えば、５０の負荷レベルの場合、テストは、１組のディスクオペレーションに要した（１００回の繰り返しにわたって平均された）同じ量の時間の間、１組のディスクオペレーションを実行し、次いで、スリープすることができる。
この結果、５０％が作業となり、５０％がスリープとなる。
【００５７】
ディスク資源構成ファイルに関して、２つの個別の資源構成をディスク資源テストに使用することができる。
すなわち、１つは、読み出し・書き込みテストに使用でき、１つは、読み出し専用テストに使用できる。
以下のように、ｄｉｓｋ＿ｒｗ．ｃｏｎｆファイルの個々のラインに、完全に適格なパス名を指定することができる。
##############################################################
# ｄｉｓｋ＿ｒｗは４ｋファイルの書き込み、読み出し、およびアンリンクを行う。
# 各「テスト」ファイルは、ここに明示的に列挙しなければならない。
# 完全に適格なパス名／ファイル名を使用する。
#
# 例：
# /tmp/disk_test.tmp
# /mnt/d001/disk_test.tmp
#
# 注意：ディレクトリおよびファイル名はアクセス可能でなければならない。
# このテストは、サブディレクトリを生成しない。
# あなたが提供したパス／ファイルでｏｐｅｎ（）が失敗すると、
# そのファイル用のテストスレッドは実行されないことになる。
##############################################################
##############################################################
#ここにファイル名を挿入する。
##############################################################
/tmp/disk_test.tmp
/mount1/tmp/disk_test.tmp
/mount2/tmp/disk_test.tmp
【００５８】
読み出し専用テスト用のｄｉｓｋ＿ｒｅａｄ．ｃｏｎｆファイルでは、例えば以下のフォーマットで、完全に適格な生のデバイスファイルを指定することができる。
##############################################################
# これは、ディスクテストの読み出し専用バージョンである。
# （バッファキャッシュからの読み出しに対して）物理的な読み出しを強制するために、
# 我々は生のディスクデバイスファイルをオープンする。
# デバイスはユーザによって指定され、
# したがって、確実に正しい生のデバイスファイルを使用されたい。
#
# 例:
# /dev/rdsk/c1t6d0
# /dev/rdsk/c2t6d0
#
# 注意：デバイスファイルでｏｐｅｎ（）が失敗すると、
# そのファイル用のテストスレッドは実行されないことになる。
#
# 注意２：読み出しテストを実行させたくない場合には、
# 以下のどの生のデバイスファイルも含めないようにされたい。
##############################################################
############################################################### 
ここに、生のデバイスファイルを挿入する。
##############################################################
/dev/rdsk/c1t0d0
/dev/rdsk/c4t4d0
【００５９】
これらのテストはストレスの多い性質を有するため、例示の実施の形態では、ハードウェアパスごとに１つのファイルまたはファイルシステムのみを指定すべきである。
上記例は、／ｔｍｐ、／ｍｏｕｎｔ１、／ｍｏｕｎｔ２、／ｄｅｖ／ｒｄｓｋ／ｃ１ｔ０ｄ０、および／ｄｅｖ／ｒｄｓｋ／ｃ４ｔ４ｄ０が、物理的に個別のディスクに存在するものと仮定している。
ユーザがこれらのサブテストの一方または双方を実行しないことを望む場合には、対応する構成ファイルからあらゆるファイル名またはデバイスファイルを除外することができる。
ｄｉｓｋ＿ｒｗ．ｃｏｎｆまたはｄｉｓｋ＿ｒｅａｄ．ｃｏｎｆが、正当なターゲットを含まない場合には、テストは実行されない。
【００６０】
ネットワークテストエリアにおいて、例示のネットワーク資源テストは、「ｎｅｔｐｅｒｆ」ベンチマークを使用して、ユーザが指定したインタフェースにネットワークトラフィックを提供することができる。
ローカルホストをこのテストに使用できるが、トラフィックは、ほとんどの場合、ＳＵＴ（テスト対象システム）と１つまたは２つ以上のリモートシステムとの間で発生する。
【００６１】
ネットワーク資源構成ファイルは、２つのセクション、すなわち基本構成セクションおよび高度構成セクションに分割することができる。
ユーザは、高度構成セクションなしで済ますように（forego）選択でき、「基本」セクションのみを変更することができる。
この構成ファイルの例示の正当なキーワードを以下に定義する。
キーワードは、大文字小文字を区別せず、「ＫＥＹＷＯＲＤ＝ＶＡＬＵＥ」のフォーマットである。
ここで、等号の周囲に空白は認められない。
【００６２】
第１のキーワード「ＲＥＭＯＴＥ＿ＨＯＳＴ」（リモートホスト）は、ｎｅｔｐｅｒｆベンチマーク用のリモートノードとして使用されるＩＰアドレスまたはホスト名を定義する。
１つまたは２つ以上のＲＥＭＯＴＥ＿ＨＯＳＴを定義することができる。
ＲＥＭＯＴＥ＿ＨＯＳＴが定義されない場合に、テストは終了する。
別のキーワード「ＭＡＸ＿ＬＯＡＤ」（最大負荷）は、ｌｏａｄ＿ｌｅｖｅｌ１００のネットワークテストに対応する複数のｎｅｔｐｅｒｆインスタンスを定義する。
１００％のネットワーク負荷の達成が困難な場合には、用語「ｒｅａｌｌｙ  ｂｕｓｙ」（実際にビジー）が正確である可能性がある。
別のキーワード「ＮＰ＿ＴＥＳＴ」（ＮＰテスト）は、実行される特定のｎｅｔｐｅｒｆテストを定義する。
３つのＴＣＰ＿ＲＲ（要求／応答（request/response））テストをデフォルトで定義することができる。
スケジュールファイルのｌｏａｄ＿ｌｅｖｅｌおよび資源構成ファイルのＭＡＸ＿ＬＯＡＤに基づいて、ｌｏａｄ＿ｌｅｖｅｌで実行されるｎｅｔｐｅｒｆインスタンスの個数は、（ｌｏａｄ＿ｌｅｖｅｌ％＊ＭＡＸ＿ＬＯＡＤ）の最高限度の整数とすることができる。
したがって、最低負荷レベルがｎｅｔｐｅｒｆの１つのインスタンスを実行しているネットワークテストを指定することができる。
【００６３】
実際の例示の資源構成ファイルは、ＩＰアドレスおよびホスト名を使用して３つのリモートホストを定義することができる。
これらのリモートホストは、別々のサブネットに存在する必要はない。
実際には、リモートホストは、一意である必要さえない。
高度セクションでは、ＭＡＸ＿ＬＯＡＤは５に設定される。
これは、１００の負荷レベルがテストスケジュールで指定されると、３つのすべてのＲＥＭＯＴＥ＿ＨＯＳＴにおいて、ｎｅｔｐｅｒｆの５つのインスタンスが同時に起動されることを意味する。
したがって、総数１５個のｎｅｔｐｅｒｆが起動されることになる。
ＮＰ＿ＴＥＳＴキーワードは、実行される特定のｎｅｔｐｅｒｆテストを定義する。
ｎｅｔｐｅｒｆは、要求／応答モードおよびストリームモードにおいてＵＤＰテストおよびＴＣＰテストを実行する能力を有する。
デフォルトの場合、ネットワークテストは、ＴＣＰ要求／応答モードで３つのテストを実行する。
実行されることになるテストは、ＮＰ＿ＴＥＳＴのリストからランダムに選択される。
各テストの継続時間は最大で５分である。
テストスケジュールが５分よりも長いテスト継続時間を定義すると、各テストがＮＰ＿ＴＥＳＴプールからランダムに選択されながら、複数の５分のテストが連続して実行される。
【００６４】
実際の例示の資源構成ファイルは、以下の形を取ることができる。
#####################################################################
### 基本構成
#####################################################################
REMOTE_HOST=192.100.1.1 # 100bt interface
REMOTE_HOST=192.100.1.2 # same interface, different host
REMOTE_HOST=host02 # Gigabit interface to host02
#####################################################################
### 高度構成
#####################################################################
MAX_LOAD=5 # １００％負荷に等しいｎｅｔｐｅｒｆインスタンス数
#####################################################################
### Ｎｅｔｐｅｒｆテスト構成
#####################################################################
# 実行されるＮｅｔｐｅｒｆテスト−同じラインにコメントを加えてはならない。
# これはｎｅｔｐｅｒｆコマンドラインの−ｔポーションである：
# netperf -l 60 -H 172.24.3.102 -t TCP_RR -- -r 20,500 -s 0 -S 0
#
# すなわち、上記場合に、我々は、「TCP_RR -- -r 20,500 -s 0 -S 0」を取り込む。
#
# フォーマット：NP_TEST=netperf_options(引用符なし)
#####################################################################
NP_TEST=TCP_RR -- -r 20,500 -s 0 -S 0
NP_TEST=TCP_RR -- -r 500,20 -s 0 -S 0
NP_TEST=TCP_RR -- -r 4096,4096 -s 0 -S 0
【００６５】
ＬＯＡＤＧＥＮの説明に戻って、ＬＯＡＤＧＥＮは、対話モードである時、直接的な方法でさまざまな資源テストをテストする能力をユーザに提供し、テストを組み合わせ、異なるパラメータを使用して適切なテストのシナリオを作成することをユーザに可能にする。
この手法により、ユーザは、特定のテストと共に使用するテストおよび使用する値を決定することができる。
次に、ユーザは、この情報を構成ファイルに保存することができる。
【００６６】
ＬＯＡＤＧＥＮが起動されると、デーモンｌｏａｄｇｅｎｄは、テスト対象システム（ＳＵＴ）上で起動する。
ｌｏａｄｇｅｎｄは、ユーザの入力を待機しながら、ＳＵＴのバックグラウンドで実行することができる。
ｌｏａｄｇｅｎｄは、ユーザのテスト要求を受け取って、その正当性を確認し、テストドライバと通信して、適切なテストスケジュールをテストドライバに送信する。
以下の例示の擬似コードは、本明細書で説明したデーモンｌｏａｄｇｅｎｄを実施するのに使用することができる。
【００６７】
Ｌｏｏｐ｛／ユーザの入力を待機する
ユーザの入力を以下のケースで解釈する：｛
ケース１：新たな構成ファイルでテストを起動する｛
構成ファイルおよびスケジュールファイルのシンタックスをチェックする。
Ｉｆ  チェックを通過する｛
スケジュールファイル名を有する対応するテストドライバを始動する。
テストドライバのＰＩＤ（プロセス識別子）を記録する。
ｌｏａｄｇｅｎｄログファイルに書き込む。
テスト情報ファイルを更新する。
（テスト情報ファイルは現時点の実行されているテスト情報を記録する。）
｝ｅｌｓｅ｛
エラーメッセージと共に終了する。
｝
｝
ケース２：実行されているテストを停止する｛
要求のシンタックスをチェックする。
Ｉｆ  失敗した、エラーメッセージと共に終了する。
Ｅｌｓｅ｛
（ｐｒｅ＿ｒｅｃｏｒｄｅｄ（事前に記録された）テストドライバのＰＩＤを使用して）対応するテストドライバにＳＩＧＴＥＲＭを送信し、テストを停止させる。
ｌｏａｄｇｅｎｄログファイルに書き込む。
テスト情報ファイルを更新する。
｝
｝
ケース３：現時点のテストを変更する｛
構成ファイルおよびスケジュールファイルのシンタックスをチェックする。
Ｉｆ  チェックを通過する｛
対応するテストドライバ（ＰＩＤ）にＳＩＧＨＵＰを送信して、新たなスケジュールファイルで現時点のスケジュールを停止させる。
ｌｏａｄｇｅｎｄログファイルに書き込む。
テスト情報ファイルを更新する。
｝ｅｌｓｅ｛
エラーメッセージと共に終了する。
｝
｝
ケース４：現時点のテスト情報を表示する｛
現時点の実行されているテスト情報を表示する。
｝
ケース５：ｌｏａｄｇｅｎｄを終了する｛
実行されているすべてのテストドライバにＳＩＧＴＥＲＭを送信して、実行されているすべてのテストを停止させる。
ｌｏａｄｇｅｎｄログファイルに書き込む。
終了する。
｝
【００６８】
各テストドライバは、１つのテスト資源エリアのテストスケジュールを管理する。
テストドライバは、デーモンｌｏａｄｇｅｎｄのみが起動および停止させることができる。
テストドライバは、適用可能な場合に資源構成ファイルの正当性を確認し、テストスケジュール要求を解釈し、指定された負荷（複数可）をシステムの現時点の負荷と比較し、資源テストの実行時期または停止時期および実行または停止する資源テストを決定する。
以下の例示の擬似コードは、本明細書で説明したテストドライバを実施するのに使用することができる。
【００６９】
ｃｕｒｒｅｎｔ＿ｌｏａｄ＿ｌｅｖｅｌ（現時点の負荷レベル）＝０に設定する。
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎ（現時点のテスト継続時間）＝０に設定する。
資源構成ファイルをチェックする（例えば、適用可能な場合）。
資源（後にテストに渡す）をログ記録する。
スケジュールファイルをオープンする。
ラインごとに読み出す｛／＊コメントラインをスキップする
キーワード（ｌｏｏｐ，ｆｏｒｅｖｅｒおよびｓｔｏｐ）をチェックする。
Ｉｆ  キーワードが「ｓｔｏｐ」である｛
実行されているすべての資源テストを停止する。
終了する。
｝ｉｆ  キーワードが「ｌｏｏｐ」である｛
ファイルポインタをファイルの先頭に移動させる。
｝ｉｆ  キーワードが「ｆｏｒｅｖｅｒ」である｛
ファイルのラインからのｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌ（次の負荷レベル）を設定する。
差分＝ｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌ−ｃｕｒｒｅｎｔ＿ｌｏａｄ＿ｌｅｖｅｌを計算する。
ｉｆ  差分＞０｛
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎの間待機する。
追加する資源テスト数を決定して、それらの資源テストを始動する。
ファイルポインタをファイルの末尾に向けることによって、ファイルの読み出しを停止する。
｝ｉｆ  差分＜０｛
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎの間待機する。
停止する資源テスト数を決定して、それらの資源テストを終了する。
ファイルポインタをファイルの末尾に向けることによって、ファイルの読み出しを停止する。
｝Ｉｆ  差分が０である、何も行わない。
｝ｅｌｓｅ｛／通常のスケジュールライン
ファイルのラインからのｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌを設定する。
ファイルのラインからのｎｅｘｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎ（次のテスト継続時間）を設定する。
差分＝ｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌ−ｃｕｒｒｅｎｔ＿ｌｏａｄ＿ｌｅｖｅｌを計算する。
ｉｆ  差分＞０｛
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎの間待機する。
追加する資源テスト数を決定して、それらの資源テストを始動する。
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎ＝ｎｅｘｔ＿ｌｏａｄ＿ｄｕｒａｔｉｏｎに設定する。
ｃｕｒｒｅｎｔ＿ｌｏａｄ＿ｌｅｖｅｌ＝ｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌに設定する。
｝ｉｆ  差分＜０｛
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎの間待機する。
停止する資源テスト数を決定して、それらの資源テストを終了する。
ｃｕｒｒｅｎｔ＿ｔｅｓｔ＿ｄｕｒａｔｉｏｎ＝ｎｅｘｔ＿ｌｏａｄ＿ｄｕｒａｔｉｏｎを設定する。
ｃｕｒｒｅｎｔ＿ｌｏａｄ＿ｌｅｖｅｌ＝ｎｅｘｔ＿ｌｏａｄ＿ｌｅｖｅｌを設定する。
｝
｝
｝
また、テストドライバは、実行中に２つの信号をハンドリングする必要もある。
ＳＩＧＴＥＲＭ：すべてのテストを終わらせて終了する。
ＳＩＧＨＵＰ：現時点のスケジュールファイルの構文解析を停止する。新たなスケジュールファイルの構文解析を開始する。
【００７０】
資源テストは、それぞれ、１つのテストエリアにストレスを加えることに集中することができる。
資源テストは、それ自身のテストドライバが管理することができる。
本明細書で説明したＬＯＡＤＧＥＮの枠組みにおいて所望の負荷を有効に生成するために、資源テストは、以下の要件を満たすことができる。
第１に、各資源テストは、或る定量的な方法で制御可能であり、したがって、テストは、負荷レベルに動的に応答することができる。
負荷レベルの定義は、各資源テストに非常に特有なものとすることができる。
その定義は、資源テスト設計の一部とすることができる。
第２に、各資源テストは、できる限りその資源に集中でき、その資源にのみ影響を与えることができる。
例えば、資源テストがメモリテストである場合、その設計は、あらゆる余分なＣＰＵ時間の使用をできるだけ回避すべきである。
例えば、メモリ資源テストの場合、我々は、物理メモリのＸ％を得るか、または、割り当てるように、Ｘの負荷レベルを定義することができる。
この場合、テストは、非常に不安定な段階ではシステムに負担になる可能性があるので、ユーザは、高い負荷数のスケジューリングに慎重になるべきである。
以下の例示の擬似コードは、メモリテストを実施するのに使用することができる。
【００７１】
システムの物理メモリ量を計算する。
現在使用されている物理メモリ量を計算する。
ｌｏａｄ＿ｌｅｖｅｌおよび上記２つの値（システムのメモリおよび使用されているメモリ）に基づいて、消費すべき物理メモリ量を（ページで）計算する。
メモリ量を分割して、ｌｏａｄ＿ｌｅｖｅｌ分だけ消費し、新たな値ｍｅｍを得る。
ｌｏａｄ＿ｌｅｖｅｌのそれぞれ１パーセントについて、ｍｅｍの量のメモリを消費するプログラムを実行する（すなわち、ユーザが３０％のｌｏａｄ＿ｌｅｖｅｌを要求すると、メモリテストは、メモリの約１％を割り当ててロックする３０個の個々のプロセスを呼び出す）。
【００７２】
テストドライバが生成する各子プロセスは、単に、全システムメモリの１％を割り当て、ｍｌｏｃｋ（）を使用してそのメモリをＲＡＭ（ランダムアクセスメモリ）にロックするように試み、次いで、永久にスリープする（ユーザはシステムのＲＡＭの１００％をロックできないので、ｍｌｏｃｋ（）の失敗はエラーとみなされないことに留意されたい）。
スケジュールファイルのエントリが完了し、新たなスケジュールファイルのエントリが実行されると、新たなレベルと一致するために、子プロセスが生成されるか、または、キルされる。
例えば、スケジュールが５０％、次いで８０％、次いで６０％のレベルのエントリを含んでいた場合、メモリテストは、５０個の子プロセス（５０％）を生成し、指定された量の時間を待機し、次いで、さらに３０個を生成し（８０％）、その指定された量の時間を待機し、次いで、２０個の子プロセスをキルする（６０％）。
【００７３】
テストが負荷レベルに応答して、テストエリアに集中する限り、既存のテストを資源テストに使用することが可能である。
例えば、指定されたリンク上に一定のトラフィックを生成するネットワークテストＡの再利用について考察する。
ネットワークテストＡをネットワーク資源テストとして再利用するには、まず負荷レベルを定義する。
これを行う１つの方法は、既知の量のトラフィック、例えば５％をリンク上に生成するＡを実行する１つの方法を事前に定義することである。
各負荷レベル５がこのテストの１つのプロセスとなる。
したがって、２０の負荷レベルを得るには、Ａの４つのプロセスが同時に呼び出されるか、または、同時に動作するように設定される。
この場合、負荷レベル１５および１６は、解像度または粒度が不十分であるので、両者に差はない。
したがって、この設計では、負荷レベルの粒度の要件を理解して、有効にまたは正確に資源テストを適用する必要がある。
【００７４】
上述した方法、論理、技法、および擬似コード列は、さまざまなプログラミングスタイル（例えば、構造化プログラミング、オブジェクト指向型プログラミング等）およびさまざまな異なるプログラミング言語（例えば、Ｊａｖａ（登録商標）、Ｃ、Ｃ＋＋、Ｃ＃、Ｐａｓｃａｌ、Ａｄａ等）で実施することができる。
【００７５】
本明細書で説明した要素および方法またはプロセスは、マイクロプロセッサ、コンピュータ、または他の任意の計算デバイスを使用して実施することができ、ハードウェアおよび／またはソフトウェア、単一の物理的な場所、またはさまざまな場所もしくはホスト計算プラットフォーム間にわたる分散形式で実施できることが当業者には理解されよう。
エージェントは、あらゆる所望のまたは適切な場所において、ハードウェアおよび／またはソフトウェアもしくはコンピュータプログラム（複数可）で実施することができる。
また、ソフトウェアまたはコンピュータプログラム（複数可）は、マシン可読媒体に記憶でき、この場合、ソフトウェアまたはコンピュータプログラム（複数可）は、コンピュータ、コンピュータシステム、マイクロプロセッサ、他の計算デバイス等の計算デバイスに、これらの方法またはプロセスを実行させる命令を含むことも当業者には理解されよう。
【００７６】
また、本発明は、本発明の精神または本質的な特徴から逸脱することなく、他の特定の形で具体化でき、本発明は、本明細書で説明した特定の実施の形態に限定されるものでないことも当業者には理解されよう。
したがって、ここに開示した実施の形態は、すべての点で、例示とみなされ、限定するものとはみなされない。
本発明の範囲は、上記説明ではなく、添付の特許請求の範囲によって示され、特許請求の範囲の意味および範囲ならびに等価物の範囲内に入るすべての変更は、特許請求の範囲に包含されるように意図されている。
【図面の簡単な説明】
【００７７】
【図１】例示の方法を示す図である。
【図２】別の例示の方法を示す図である。
【図３】例示の実施の形態を示す図である。
【図４】例示のグラフィカルユーザインタフェース（ＧＵＩ）を示す図である。
【図５】例示のファイル構造を示す図である。
【図６】例示の負荷パターンを示す図である。
【符号の説明】
【００７８】
３０２，３０６，３１６・・・表示装置，
３０４，３１４，３１８，３２６，３３０，３３４，３２８，３３２，３３６・・・コンピュータ，
３０４１，３１４１，３１８１・・・テストソフトウェア，
３０８，３２０・・・ハードディスクドライブ，
３１０，３２２・・・メモリ，
３１３，３１９・・・ネットワークインタフェースカード，
３２６１，３３０１，３３４１，３２８１，３３２１，３３６１・・・ネットワークテスト構成，
【図１】
2005182813.tif 000003
【図２】
2005182813.tif 000004
【図３】
2005182813.tif 000005
【図４】
2005182813.tif 000006
【図５】
2005182813.tif 000007
【図６】
2005182813.tif 000008