3. テスト計画の要素

このセクションでは、テスト計画のさまざまな部分について説明します。

最小限のテストは、テスト計画、スレッドグループ、および 1 つ以上のサンプラーで構成されます。

3.0 テスト計画¶

テスト計画オブジェクトには、「機能テスト」というチェックボックスがあります。選択すると、JMeter はサーバーから返されたデータをサンプルごとに記録します。テストリスナーでファイルを選択した場合、このデータはファイルに書き込まれます。これは、JMeter が正しく構成されていること、およびサーバーが期待どおりの結果を返していることを確認するために小規模な実行を行う場合に役立ちます。その結果、ファイルが急速に大きくなり、JMeter のパフォーマンスが低下します。ストレステストを行う場合は、このオプションをオフにする必要があります (既定ではオフになっています)。

データをファイルに記録しない場合、このオプションは何の違いもありません。

リスナーの [構成] ボタンを使用して、保存するフィールドを決定することもできます。

3.1 スレッドグループ¶

スレッドグループ要素は、あらゆるテスト計画の出発点です。すべてのコントローラーとサンプラーは、スレッドグループの下にある必要があります。リスナーなどの他の要素は、テスト計画の直下に配置できます。この場合、それらはすべてのスレッドグループに適用されます。名前が示すように、スレッドグループ要素は、JMeter がテストの実行に使用するスレッドの数を制御します。スレッドグループのコントロールを使用すると、次のことができます。

スレッド数を設定する
ランプアップ期間の設定
テストを実行する回数を設定します

各スレッドは、テスト計画全体を実行し、他のテストスレッドとは完全に独立しています。サーバーアプリケーションへの同時接続をシミュレートするために、複数のスレッドが使用されます。

ランプアップ期間は、JMeter に、選択されたスレッドの最大数まで「ランプアップ」するのにかかる時間を伝えます。10 個のスレッドが使用され、ランプアップ期間が 100 秒の場合、JMeter は 10 個のスレッドすべてを起動して実行するのに 100 秒かかります。各スレッドは、前のスレッドが開始されてから 10 (100/10) 秒後に開始されます。30 のスレッドがあり、ランプアップ期間が 120 秒の場合、連続する各スレッドは 4 秒ずつ遅延します。

ランプアップは、テストの開始時にワークロードが大きすぎるのを避けるために十分長く、最初のスレッドが終了する前に最後のスレッドが実行を開始できるように十分に短くする必要があります (それが必要な場合を除きます)。

Ramp-up = スレッド数から始めて、必要に応じて上下に調整します。

デフォルトでは、スレッドグループはその要素を 1 回ループするように構成されています。

スレッドグループでは、スレッドの有効期間を指定することもできます。スレッドグループパネルの下部にあるチェックボックスをクリックして、テストの期間と起動遅延を入力できる追加フィールドを有効/無効にします期間 (秒)と起動遅延 (秒)を構成して、各スレッドの期間を制御できますグループと何秒後に開始します。テストが開始されると、JMeter は、スレッドグループのスレッドを開始する前にStartup Delay (秒)待機し、構成されたDuration (秒) 時間実行します。

3.2 コントローラー¶

JMeter には、サンプラーと論理コントローラーの 2 種類のコントローラーがあります。これらは、テストの処理を駆動します。

サンプラーは、サーバーにリクエストを送信するように JMeter に指示します。たとえば、JMeter で HTTP リクエストを送信する場合は、HTTP リクエストサンプラーを追加します。サンプラーに 1 つ以上の構成要素を追加して、要求をカスタマイズすることもできます。詳細については、サンプラーを参照してください。

論理コントローラを使用すると、リクエストを送信するタイミングを決定するために JMeter が使用するロジックをカスタマイズできます。たとえば、インターリーブロジックコントローラーを追加して、2 つの HTTP リクエストサンプラーを交互に切り替えることができます。詳細については、「論理コントローラー」を参照してください。

3.2.1 サンプラー¶

サンプラーは、JMeter に要求をサーバーに送信して応答を待つように指示します。ツリーに表示される順序で処理されます。コントローラーを使用して、サンプラーの繰り返し回数を変更できます。

JMeter サンプラには以下が含まれます。

FTP リクエスト
HTTP リクエスト (SOAP または REST Web サービスにも使用可能)
JDBC リクエスト
Java オブジェクト要求
JMS リクエスト
JUnit テストリクエスト
LDAP リクエスト
メールリクエスト
OS プロセス要求
TCP リクエスト

各サンプラーには、設定可能ないくつかのプロパティがあります。テスト計画に 1 つ以上の構成要素を追加することで、サンプラーをさらにカスタマイズできます。

同じタイプの複数の要求 (HTTP 要求など) を同じサーバーに送信する場合は、デフォルト構成要素の使用を検討してください。各コントローラーには、1 つ以上の Defaults 要素があります (以下を参照)。

リクエストの結果をディスクに表示および/または保存するには、テスト計画にリスナーを追加することを忘れないでください。

リクエストのレスポンスに対して JMeter に基本的な検証を実行させることに関心がある場合は、サンプラーにアサーションを追加します。たとえば、Web アプリケーションのストレステストでは、サーバーは成功した "HTTP 応答" コードを返すことがありますが、ページにエラーがあるか、セクションが欠落している可能性があります。特定の HTML タグ、一般的なエラー文字列などをチェックするアサーションを追加できます。JMeter では、正規表現を使用してこれらのアサーションを作成できます。

JMeter の組み込みサンプラー

3.2.2 ロジックコントローラー¶

ロジックコントローラを使用すると、リクエストを送信するタイミングを決定するために JMeter が使用するロジックをカスタマイズできます。ロジックコントローラは、子要素からのリクエストの順序を変更できます。リクエスト自体を変更したり、JMeter にリクエストを繰り返させたりすることができます。

テスト計画に対するロジックコントローラーの影響を理解するには、次のテストツリーを検討してください。

テスト計画

スレッドグループ

ワンスオンリーコントローラー

ログインリクエスト ( HTTP リクエスト)

検索ページの読み込み (HTTP サンプラー)
インターリーブコントローラ

「A」を検索 (HTTP サンプラー)
「B」を検索 (HTTP サンプラー)
HTTP デフォルト要求 (構成要素)

HTTP デフォルト要求 (構成要素)
Cookie マネージャー (構成要素)

このテストに関する最初のことは、ログインリクエストが初回のみ実行されることです。以降の反復ではスキップされます。これは、 Once Only Controllerの効果によるものです。

ログイン後、次の Sampler が検索ページを読み込みます (ユーザーがログインし、検索を行うために検索ページに移動する Web アプリケーションを想像してください)。これは単純なリクエストであり、ロジックコントローラによってフィルタリングされていません。

検索ページを読み込んだ後、検索を実行します。実際には、2 つの異なる検索を実行したいと考えています。ただし、検索ごとに検索ページ自体を再読み込みする必要があります。これは、4 つの単純な HTTP 要求要素 (ロード検索、検索 "A"、ロード検索、検索 "B") を持つことで実現できます。代わりに、テストごとに 1 つの子リクエストを渡すInterleave Controllerを使用します。子要素の順序を保持します (つまり、ランダムに渡すのではなく、その場所を「記憶」します)。2 つの子リクエストをインターリーブするのはやり過ぎかもしれませんが、簡単に 8 つまたは 20 の子リクエストが存在する可能性があります。

HTTP リクエストのデフォルトに注意してくださいインターリーブコントローラに属します。「検索 A」と「検索 B」が同じ PATH 情報を共有しているとします (HTTP 要求の仕様には、ドメイン、ポート、メソッド、プロトコル、パス、引数、およびその他のオプション項目が含まれます)。これは理にかなっています。どちらも検索リクエストであり、同じバックエンド検索エンジン (サーブレットまたは CGI スクリプトなど) にヒットします。PATH フィールドに同じ情報を使用して両方の HTTP サンプラーを構成するのではなく、その情報を単一の構成要素に抽象化できます。インターリーブコントローラが「検索 A」または「検索 B」からの要求を「渡す」とき、HTTP デフォルト要求構成要素からの値で空白を埋めます。したがって、これらのリクエストの PATH フィールドは空白のままにします。その情報を構成要素に入れます。この場合、これはせいぜいマイナーな利点ですが、機能を示しています。

ツリーの次の要素は別の HTTP デフォルトリクエストで、今回はスレッドグループ自体に追加されます。スレッドグループにはロジックコントローラが組み込まれているため、この構成要素を上記とまったく同じように使用します。通過するリクエストの空白を埋めます。Web テストでは、すべての HTTP Sampler 要素で DOMAIN フィールドを空白のままにし、代わりにその情報を HTTP デフォルトリクエスト要素に入れ、スレッドグループに追加すると非常に便利です。そうすることで、テスト計画の 1 つのフィールドを変更するだけで、別のサーバーでアプリケーションをテストできます。そうしないと、すべてのサンプラーを編集する必要があります。

最後の要素はHTTP Cookie Managerです。すべての Web テストに Cookie Manager を追加する必要があります。そうしないと、JMeter は Cookie を無視します。スレッドグループレベルで追加することにより、すべての HTTP リクエストが同じ Cookie を共有するようになります。

ロジックコントローラを組み合わせて、さまざまな結果を得ることができます。組み込みロジックコントローラーのリストを参照してください。

3.2.3 テストフラグメント¶

テストフラグメント要素は、スレッドグループ要素と同じレベルのテスト計画ツリーに存在する特殊なタイプのコントローラーです。Module ControllerまたはInclude_Controllerによって参照されない限り実行されないという点で、スレッドグループとは区別されます。

この要素は、テスト計画内でのコードの再利用のみを目的としています

3.3 リスナー¶

リスナーは、JMeter の実行中にテストケースに関して JMeter が収集する情報へのアクセスを提供します。Graph Resultsリスナーは、応答時間をグラフにプロットします。「View Results Tree」リスナーは、サンプラーの要求と応答の詳細を表示し、応答の基本的な HTML および XML 表現を表示できます。他のリスナーは、要約または集計情報を提供します。

さらに、リスナーは後で使用するためにデータをファイルに送ることができます。JMeter のすべてのリスナーは、データを保存するファイルを示すフィールドを提供します。保存するフィールドを選択し、CSV または XML 形式を使用するかどうかを選択するために使用できる [構成] ボタンもあります。

すべてのリスナーが同じデータを保存することに注意してください。唯一の違いは、データが画面に表示される方法です。

リスナーは、テスト計画の直下を含め、テストのどこにでも追加できます。それらは、そのレベル以下の要素からのみデータを収集します。

JMeterにはいくつかのリスナーが付属しています。

3.4 タイマー¶

デフォルトでは、JMeter スレッドはサンプラーを一時停止せずに順番に実行します。使用可能なタイマーの 1 つをスレッドグループに追加して、遅延を指定することをお勧めします。遅延を追加しないと、JMeter は非常に短い時間で大量のリクエストを行い、サーバーに負荷をかける可能性があります。

タイマーは、スコープ内にある各サンプラーの前に、JMeter を一定時間遅延させます。

複数のタイマーをスレッドグループに追加することを選択した場合、JMeter はタイマーの合計を取得し、タイマーが適用されるサンプラーを実行する前に、その時間だけ一時停止します。タイマーは、適用されるサンプラーを制限するために、サンプラーまたはコントローラーの子として追加できます。

テスト計画の 1 か所で一時停止を行うには、フロー制御アクションサンプラーを使用できます。

3.5 アサーション¶

アサーションを使用すると、テスト対象のサーバーから受信した応答に関する事実をアサートできます。アサーションを使用すると、アプリケーションが期待する結果を返すことを基本的に「テスト」できます。

たとえば、クエリへの応答に特定のテキストが含まれることをアサートできます。指定するテキストは Perl スタイルの正規表現にすることができ、応答にテキストを含めること、または応答全体と一致することを示すことができます。

どのサンプラーにもアサーションを追加できます。たとえば、テキスト「</HTML>」をチェックするアサーションを HTTP リクエストに追加できます。JMeter は、HTTP 応答にテキストが存在することを確認します。JMeter がテキストを見つけられない場合、これは失敗した要求としてマークされます。

アサーションは、そのスコープ内にあるすべてのサンプラーに適用されることに注意してください。アサーションを 1 つのサンプラーに制限するには、アサーションをサンプラーの子として追加します。

アサーション結果を表示するには、アサーションリスナーをスレッドグループに追加します。失敗したアサーションはツリービューとテーブルリスナーにも表示され、集計レポートや概要レポートなどでエラー %age にカウントされます。

3.6 構成要素¶

構成要素はサンプラーと密接に連携します。リクエストを送信しませんが ( HTTP(S) Test Script Recorderを除く)、リクエストを追加または変更できます。

構成要素には、要素を配置したツリーブランチ内からのみアクセスできます。たとえば、HTTP Cookie Manager を Simple Logic Controller 内に配置すると、Cookie Manager は、Simple Logic Controller 内に配置した HTTP Request Controller からのみアクセス可能になります (図 1 を参照)。Cookie Manager は、HTTP 要求「Web ページ 1」および「Web ページ 2」にアクセスできますが、「Web ページ 3」にはアクセスできません。

また、ツリーブランチ内の構成要素は、「親」ブランチ内の同じ要素よりも優先されます。たとえば、「Web Defaults 1」と「Web Defaults 2」という 2 つの HTTP Request Defaults 要素を定義しました。「Web Defaults 1」は Loop Controller 内に配置したため、「Web Page 2」のみがアクセスできます。他の HTTP 要求は、「Web デフォルト 2」を使用します。これは、それをスレッドグループ (他のすべてのブランチの「親」) に配置したためです。

ユーザー定義変数構成要素は異なります。配置場所に関係なく、テストの開始時に処理されます。簡単にするために、要素はスレッドグループの先頭にのみ配置することをお勧めします。

3.7 プリプロセッサ要素¶

プリプロセッサは、サンプラーリクエストが作成される前に何らかのアクションを実行します。プリプロセッサがサンプラー要素にアタッチされている場合、そのサンプラー要素が実行される直前に実行されます。プリプロセッサは、実行直前にサンプルリクエストの設定を変更したり、レスポンステキストから抽出されていない変数を更新したりするために最もよく使用されます。プリプロセッサが実行されるタイミングの詳細については、スコープルールを参照してください。

3.8 ポストプロセッサ要素¶

ポストプロセッサは、サンプラーリクエストが作成された後に何らかのアクションを実行します。Post-Processor が Sampler 要素にアタッチされている場合、そのサンプラー要素が実行された直後に実行されます。ポストプロセッサは、応答データを処理するために最もよく使用され、多くの場合、応答データから値を抽出します。ポストプロセッサが実行されるタイミングの詳細については、スコープルールを参照してください。

3.9 実行順序¶

構成要素
プリプロセッサ
タイマー
サンプラー
ポストプロセッサ ( SampleResult がnullでない場合)
アサーション ( SampleResult がnullでない場合)
リスナー ( SampleResult がnullでない場合)

タイマー、アサーション、プリおよびポストプロセッサは、それらが適用されるサンプラーがある場合にのみ処理されることに注意してください。ロジックコントローラーとサンプラーは、ツリーに表示される順序で処理されます。他のテスト要素は、それらが見つかった範囲とテスト要素のタイプに従って処理されます。[型内では、要素はツリーに表示される順序で処理されます]。

たとえば、次のテスト計画では:

コントローラ

ポストプロセッサ 1
サンプラー1
サンプラー 2
タイマー1
アサーション 1
プリプロセッサ 1
タイマー 2
ポストプロセッサー 2

実行順序は次のようになります。

プリプロセッサ 1
タイマー1
タイマー 2
サンプラー1
ポストプロセッサ 1
ポストプロセッサー 2
アサーション 1

プリプロセッサ 1
タイマー1
タイマー 2
サンプラー 2
ポストプロセッサ 1
ポストプロセッサー 2
アサーション 1

3.10 スコーピング規則¶

JMeter テストツリーには、階層的で順序付けられた要素が含まれています。テストツリーの一部の要素は厳密に階層化されており (リスナー、構成要素、ポストプロセッサ、プリプロセッサ、アサーション、タイマー)、一部は主に順序付けされています (コントローラ、サンプラ)。テスト計画を作成するときは、実行する一連のステップを表すサンプルリクエストの順序付きリストを (Sampler 経由で) 作成します。これらの要求は、多くの場合、順序付けされたコントローラー内で編成されます。次のテストツリーがあるとします。

要求の順序は、1、2、3、4 です。

一部のコントローラーは、そのサブ要素の順序に影響を与えます。これらの特定のコントローラーについては、コンポーネントリファレンスを参照してください。

他の要素は階層的です。たとえば、アサーションはテストツリー内で階層化されています。親がリクエストの場合、そのリクエストに適用されます。親がコントローラーの場合、そのコントローラーの子孫であるすべてのリクエストに影響します。次のテストツリーでは:

アサーション #1 はリクエスト 1 にのみ適用され、アサーション #2 はリクエスト 2 と 3 に適用されます。

別の例として、今回はタイマーを使用します。

この例では、リクエストは実行される順序を反映するように名前が付けられています。タイマー #1 は、要求 2、3、および 4 に適用されます (順序が階層要素に無関係であることに注意してください)。アサーション 1 は、リクエスト 3 にのみ適用されます。タイマー #2 はすべての要求に影響します。

これらの例によって、構成 (階層) 要素がどのように適用されるかが明確になることを願っています。各 Request がツリーブランチを渡され、その親、次にその親の親などに渡され、その親のすべての構成要素を収集するたびに、それがどのように機能するかがわかります。

構成要素のヘッダーマネージャー、Cookie マネージャー、および承認マネージャーは、構成の既定の要素とは異なる方法で処理されます。Configuration Default 要素の設定は、Sampler がアクセスできる一連の値にマージされます。ただし、マネージャーからの設定はマージされません。複数のマネージャーがサンプラーのスコープ内にある場合、1 つのマネージャーのみが使用されますが、現在、使用されるマネージャーを指定する方法はありません。

3.11 プロパティと変数¶

JMeterプロパティはjmeter.propertiesで定義されます(詳細については、「はじめに - JMeterの構成」を参照してください)。
プロパティは jmeter に対してグローバルであり、主に JMeter が使用するデフォルトの一部を定義するために使用されます。たとえば、プロパティremote_hostsは、JMeter がリモートで実行しようとするサーバーを定義します。プロパティはテスト計画で参照できます -関数 - プロパティの読み取りを参照してください- ただし、スレッド固有の値には使用できません。

JMeter変数は、各スレッドに対してローカルです。値は、スレッドごとに同じ場合もあれば、異なる場合もあります。
変数がスレッドによって更新される場合、変数のスレッドコピーのみが変更されます。たとえば、Regular Expression Extractor Post-Processor は、そのスレッドが読み取ったサンプルに従って変数を設定し、これらは後で同じスレッドで使用できます。変数と関数の参照方法の詳細については、関数と変数を参照してください。

テスト計画およびユーザー定義変数構成要素によって定義された値は、起動時にテスト計画全体で使用できることに注意してください。同じ変数が複数の UDV 要素で定義されている場合、最後の要素が有効になります。スレッドが開始されると、変数の初期セットが各スレッドにコピーされます。User Parameters Pre-Processor やRegular Expression Extractor Post-Processorなどの他の要素を使用して、同じ変数を再定義する (または新しい変数を作成する) ことができます。これらの再定義は、現在のスレッドにのみ適用されます。

setProperty関数を使用して、JMeter プロパティを定義できます。これらはテスト計画に対してグローバルであるため、必要に応じてスレッド間で情報を渡すために使用できます。

変数とプロパティの両方で大文字と小文字が区別されます。

3.12 変数を使用してテストをパラメータ化する¶

変数は変化する必要はありません。一度定義すれば、そのままにしておくと値が変化しません。したがって、テスト計画で頻繁に使用される式の省略形として使用できます。または、実行中は一定であるが、実行ごとに異なる可能性がある項目の場合。たとえば、ホストの名前、またはスレッドグループ内のスレッドの数です。

テスト計画をどのように構成するかを決定するときは、どの項目が実行に対して一定であるかを書き留めますが、どの項目が実行間で変化する可能性があります。これらのいくつかの変数名を決定します。おそらく、C_またはK_をプレフィックスとして付けるか、テスト中に変更する必要がある変数と区別するために大文字のみを使用するなどの命名規則を使用します。また、正規表現ポストプロセッサで抽出されたカウンタや値など、スレッドに対してローカルである必要がある項目も考慮してください。これらには別の命名規則を使用することをお勧めします。

たとえば、テスト計画で次のように定義できます。

ホスト www.example.com
スレッド 10
ループ 20

これらは、テスト計画で${HOST} ${THREADS}などとして参照できます。後でホストを変更する場合は、HOST変数の値を変更するだけです。これは少数のテストでは問題なく機能しますが、多くの異なる組み合わせをテストする場合は面倒になります。1 つの解決策は、プロパティを使用して変数の値を定義することです。次に例を示します。

ホスト ${__P(ホスト,www.example.com)}
スレッド ${__P(threads,10)}
ループ ${__P(loops,20)}

その後、次のようにコマンドラインで一部またはすべての値を変更できます。

jmeter … -Jhost=www3.example.org -Jloops=13

Go to top