Skip to content

MS_JMeterTerminology

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

Jmeter用語

概要

  • Jmeter で使用される用語を拾ってまとめた。
  • Jmeter はプログラマブルなツールなので、
    コンポーネントとコンポーネント階層を理解しておく必要がある。

階層

補足（この階層図が本ページの要点）: JMeter の学習でつまずく最大の原因は、
個々のコンポーネント名を覚えることではなく、
**「どのコンポーネントを、どの階層に置くと、どの範囲に効くか」**が
分からないことである。

大原則は次の 2 つ。

  1. 設定エレメント・タイマ・アサーション・前処理／後処理・リスナーは
    「置いた階層の配下すべて」に効く    （スコープを持つ）。
  2. サンプラーだけは「そこで 1 回実行される」（スコープを持たない）。

つまり、HTTP クッキー マネージャをテスト計画直下に置けば全スレッド グループに、
あるサンプラーの子として置けばそのサンプラーだけに効く。
「なぜかタイマが全リクエストに効いてしまう」の類の事故は
ほぼこの原則の理解不足に起因する。

なお、同一階層内の実行順序は種別で決まっており、
配置順ではない（設定エレメント → 前処理 → タイマ → サンプラー →
後処理 → アサーション → リスナー）。

テンプレート

  • Visual Studio 的に言うとプロジェクト・テンプレート的なもの。
  • これを開いて、負荷テストを新規作成する。

テンプレートの種類

以下のようなテンプレートが存在する。

Web サーバ

  • build-web-test-plan.jmx
    比較的単純な負荷テスト
  • build-adv-web-test-plan.jmx
    ログイン処理等を含む、やや複雑な負荷テスト
  • build-webservice-test-plan.jmx
    SOAP を使った負荷テスト

FTP サーバ

  • build-ftp-test-plan.jmx
    比較的単純な負荷テスト

LDAP サーバ

  • build-ldap-ext-test-plan.jmx
    比較的単純な負荷テスト
  • build-ldap-test-plan.jmx
    ループコントローラを利用した負荷テスト

ストレージ

  • jdbc.jmx
    PostgreSQL に対する JDBC 経由の負荷テスト
  • mongodb.jmx
    JSR233 を使った mongodb に対する負荷テスト

その他

  • recording.jmx
    記録コントローラ（ユーザの操作を記録してテスト計画を自動作成する）利用時テンプレート
  • BeanShellSampler.jmx
    Jmeter 用の軽量スクリプト言語（BeanShell）でテストを書いて直接実行。

補足（最新化）: テンプレートは JMeter 5.x でも
bin/templates/ 配下に同名で存在するが、
build-webservice-test-plan.jmx（SOAP/XML-RPC サンプラー用）は
JMeter 3.0 で SOAP/XML-RPC サンプラー自体が削除されたため
現在は存在しない。SOAP のテストは
HTTP リクエスト サンプラー + HTTP ヘッダ マネージャ
（Content-Type: text/xml、SOAPAction）で行う。

同様に MongoDB Script サンプラーも JMeter 4.0 で削除された。
現在の JMeter 5.x で追加されたテンプレートには
bolt.jmx（Neo4j）、functional_test.jmx などがある。

プロパティ

以下の設定が可能。

グローバル定義画面

テスト計画のグローバル定義

スレッドグループ定義画面

テスト計画のスレッドグループ

ワークベンチ

  • ワークベンチとは、作業領域のこと。
    • リクエスト記録領域
    • 測定結果データ領域
  • 特定のテストエレメントは、ワークベンチでのみ使用できる。

補足（最新化：ワークベンチは廃止された）: WorkBench は JMeter 3.1 で非推奨、
4.0 で完全に削除された。現在は次のように扱う。

旧（〜3.x） 現在（4.0 以降）
WorkBench に HTTP(S) Test Script Recorder を追加 テスト計画直下に追加する
WorkBench は保存されない（一時領域） テスト計画の一部として .jmx に保存される
「Save WorkBench」チェックで保存 不要

WorkBench が「保存されない一時領域」だったために
記録したスクリプトを失う事故が多く、
通常のテスト計画ツリーに一本化されたという経緯である。
本節の記述は JMeter 3.x 以前を前提としている点に注意。

HTTPプロキシサーバ

  • HTTP(S) Test Script Recorder（旧 HTTP Proxy Server）
  • 電文をキャプチャしてワークロードをスクリプトとして記録する機能。
  • 使用する場合、ワークベンチにこれを追加する。

補足: 現在はテスト計画直下に追加する（前述）。
また、HTTPS を記録するには JMeter が生成する
ルート証明書（ApacheJMeterTemporaryRootCA.crt）を
ブラウザ／OS の信頼されたルート証明機関にインポートする必要がある
（中間者としてキャプチャするため）。この証明書は有効期間 7 日である。

HTTP Mirror Server

  • 送信されたデータを単にミラーリングする非常に単純な HTTP サーバー。
  • HTTP 要求の内容をチェックするのに便利。

Property Display

System プロパティまたは JMeter プロパティの値が表示される。

テスト計画

  • 負荷テストの実行計画を設定するもの。
  • 以下のプロパティ設定や、コンポーネント追加ができる。

Threads(Users)

  • スレッドグループ（仮想ユーザ群）
  • 追加する場合、テスト計画で右クリック > 追加 > Threads(Users) > XXXX を選択。

Threads(Users)の種類

以下の 3 種類の Threads(Users) がある。

  • スレッドグループ
    通常のスレッドグループ
  • setUp Thread Group
    テスト前のアクションを実行するスレッドグループ。
    • 通常のスレッドグループとほぼ同じ。
    • 通常のスレッドグループの実行前に実行される。
  • tearDown Thread Group
    テスト後のアクションを実行するスレッドグループ。
    • 通常のスレッドグループとほぼ同じ。
    • 通常のスレッドグループの実行後に実行される。

プロパティ

以下のプロパティを設定。

  • 名前
    スレッドグループの名前（ID ではない）。
  • コメント
    スレッドグループの説明
  • スレッド数
    起動するスレッド数 ≒ 仮想ユーザ数
  • Delay Thread creation until needed
    スレッドが必要になったタイミングで生成するオプション。
  • ループ回数
    • テスト・シナリオの実行回数
    • ［無限ループ］にチェックを入れると無限にテスト
  • Ramp-up 期間（秒で指定）
    多重度（仮想ユーザ数）を徐々に増加させるためのパラメタ。
  • スケジューラ
    • 開始時刻
      スケジューラが有効の場合、この時刻が来るまでテストの実施を待つ。
      ただし後述の起動遅延の指定があれば、そちらが優先される。
    • 終了時刻
      スケジューラが有効の場合、この時刻までテストが行われる。
    • 持続時間
      テストをこの時間だけ実行する
    • 起動遅延
      この秒数だけテストの実行を遅延する
    • 終了条件
      Jmeter のスレッドが終了する契機が、
      以下の終了条件のうち、いずれか達成の早いものになる。
      条件チェックは各サンプル間でのみ行われる。
      • 指定のループ回数に達した時
      • 終了時刻に達した時
      • 持続時間に達した時
  • サンプラーエラー後のアクション
    サーバがエラーを返してきた場合など、
    リクエストが何らかの原因でエラーになった際どうするかを選択する。
    • 続行
      エラーを無視してテストを続行
    • Start Next Loop
      エラーを無視して次のループの最初から続行
    • スレッド停止
      現在のスレッドを終了
    • テスト停止
      いずれかのサンプルの終了をもってテスト全体が停止
    • Stop Test Now
      即座にテスト全体を停止。

補足（Ramp-up 期間の決め方）: Ramp-up は「見栄えのため」ではなく
測定を成立させるためのパラメタである。

  • 短すぎると、全スレッドが同時にリクエストを投げるため
    サーバ側のスレッド プール／コネクション プールが枯渇し、
    「サーバの性能」ではなく立ち上がりの詰まりを測ってしまう。
  • 長すぎると、最初のスレッドが終了した後に最後のスレッドが起動し、
    目標の多重度に一度も到達しない。

目安は、

Ramp-up（秒） ≒ スレッド数 ÷ （1 秒あたりに増やしたいユーザ数）

であり、かつ
**「1 スレッドが 1 ループを回る時間 × ループ回数 > Ramp-up」**を満たすこと。
定常状態（全スレッドが走っている区間）を確保してから、
その区間の統計だけを見るのが正しい
（Jmeterの結果のレポーティング）。

また、Delay Thread creation until needed を有効にすると
未起動スレッドのメモリを確保しないため、
大規模な Ramp-up でメモリを節約できる。

補足（サンプラーエラー後のアクションの選び方）: 負荷テストでは
原則**「続行」**にする。「テスト停止」にすると
1 件のエラーで測定全体が失われるためである。
一方、ログイン失敗のまま後続を流しても無意味なケースでは
「Start Next Loop」を選び、シナリオの整合性を保つ。

サンプラー

  • サーバなどのテスト対象に対し、何らかの指示やリクエストを行うためのコンポーネント。
  • サンプラーにより負荷テスト結果が収集され、この結果はリスナーにより参照できる。
  • 追加する場合、スレッドグループかロジックコントローラで右クリック > 追加 > サンプラー > XXXX を選択。
  • 様々なサンプラーがある。
    • Web サーバのテストであれば、「HTTPリクエスト」を選択する。
    • XXX サーバのテストであれば、「XXXX リクエスト」を選択する。

スクリプト系

# サンプラー名 説明
1 BeanShell Sampler BeanShell スクリプト言語を使ってサンプラーを書く
2 BSF Sampler (DEPRECATED) BSF スクリプト言語を使ってサンプラーを書く
3 JSR223 Sampler JSR-223 スクリプト言語を使ってサンプラーを書く
4 Java Request org.apache.jmeter.protocol.java.sampler.JavaSamplerClient を使用してリクエストを送りレスポンスを待つ。
5 JUnit Request JUnit を使用してリクエストを送りレスポンスを待つ。

補足（現在は JSR223 + Groovy 一択）: BSF 系は JMeter 5.0 で削除され、
BeanShell は非推奨である。理由は性能で、
BeanShell はリクエストごとにインタプリタで解釈するため
負荷テストの足を引っ張る（それ自体がボトルネックになる）。

JSR223 サンプラー／要素で Groovy を選び、
「Cache compiled script if available」にチェックを入れると
スクリプトがコンパイルされてキャッシュされ、桁違いに速くなる。

プロトコル系

  • セッション層
# サンプラー名 説明
1 TCP サンプラー サーバに対して TCP リクエストを送りレスポンスを待つ。
  • プレゼンテーション層
# サンプラー名 説明
1 HTTPリクエスト Web サーバに対して HTTP(s) リクエストを送りレスポンスを待つ。
2 FTP リクエスト FTP サーバに対してファイルの取り出し／アップロードのリクエストを送る。
3 LDAP リクエスト 4 種類の LDAP リクエストを送る。
4 LDAP 拡張リクエスト 8 種類の LDAP リクエストを送る。
より実際の LDAP セッションに近いシミュレーションが行える。
5 JDBC Request JDBC でデータベースに対して SQL を送りレスポンスを待つ。
6 MongoDB Script (DEPRECATED) MongoDB に対して MongoDB Script を送りレスポンスを待つ。
  • メール
# サンプラー名 説明
1 SMTP サンプラー SMTP / SMTPS プロトコルを使用してメールメッセージを送信。
2 Mail Reader サンプラー POP3（S）/IMAP（S）プロトコルを使用してメールメッセージを受信（オプションで削除）。
  • JMS（Java Message Service）
# サンプラー名 説明
1 JMS Publisher 指定された宛先（トピック/キュー）にメッセージを送信
2 JMS Subscriber 指定された宛先（トピック/キュー）からメッセージを受信
3 JMS_Point-to-Point ポイントツーポイント接続（キュー）でメッセージを送受信
  • その他
# サンプラー名 説明
1 OS Process Sampler OS コマンドを実行する。

その他

# サンプラー名 説明
1 Access Log Sampler Web サーバーのアクセスログを読んで HTTP リクエストを生成。
2 Test Action ・・・
3 Debug Sampler ・・・

補足: Test Action は「リクエストを送らないサンプラー」で、
一定時間の一時停止（Pause）や、スレッド／テストの停止を行う。
ロジックの区切りとして使う。
なお、JMeter 5.x では JSR223 Sampler に加え
GraphQL HTTP Request（5.4 以降）が標準で追加されている。

ロジックコントローラー

  • ループや条件分岐など、複雑な制御を行うためのコンポーネント。
  • 追加する場合、スレッドグループかロジックコントローラで右クリック > 追加 > ロジックコントローラ > XXXX を選択。
  • また、下位にサンプラー（または子コントローラ）を追加できる。

制御構文系

  • 選択
# ロジックコントローラー名 説明
1 If Controller 指定した条件が "true" の場合、子コントローラーを実行する。条件は JavaScript または変数表現で指定。
2 Switch Controller スイッチの値に従って子コントローラーを実行する。
  • ループ
# ロジックコントローラー名 説明
1 Loop Controller 特定回数分、子コントローラーを実行する。
2 While Controller While で、指定した条件が "false" になるまでループしながら子コントローラーを実行する。
3 ForEach Controller ForEach で、変数の値を変えながらループして、子コントローラーを実行する。

補足（If Controller は「JavaScript を使わない」）: If Controller の条件式は
既定で JavaScript として評価されるが、
リクエストごとに JavaScript エンジンを起動するため非常に遅い。
負荷テストでは必ず
「Interpret Condition as Variable Expression?」にチェックを入れ、
条件を ${__jexl3(...)} のような変数式で書く。
同じ理由で、While Controller の条件も変数式で書くのが定石である。

その他

# ロジックコントローラー名 説明
1 Simple Controller サンプラー、子コントローラーの整理のため。
2 Module Controller リンク先を参照。
3 Include Controller リンク先を参照。

以下は、ググって。

  • Once Only Controller
  • Interleave Controller
  • Random Controller
  • Random Order Controller
  • Throughput Controller
  • Runtime Controller
  • Transaction Controller
  • Critical Section Controller
  • Recording Controller

補足（実務で使用頻度が高いもの）: 上の「ググって」リストのうち、
負荷テストで実際によく使うのは次の 3 つである。

コントローラー 用途
Transaction Controller 配下の複数サンプラーを1 つの取引としてまとめて計測する。画面遷移 1 回＝1 トランザクションとして応答時間を見る場合に必須
Throughput Controller 配下を指定した割合（%）でのみ実行する。「照会 8 割・更新 2 割」といった業務比率の再現に使う
Once Only Controller スレッドごとに初回のみ実行。ログイン処理に使う

Transaction Controller の「Generate parent sample」に
チェックを入れると子サンプルが集計から外れ、
レポートがトランザクション単位になる。

設定エレメント

  • リクエストにかかわる様々な項目を設定する。
  • 追加する場合、テスト計画 － サンプラーを右クリック > 追加 > 設定エレメント > XXXX を選択。

共通

# 設定エレメント名 説明
1 TCP サンプラー設定 TCP サンプラーのデフォルト設定
2 ログイン設定エレメント ユーザ名とパスワードの設定
3 DNS Cache Manager DNS キャッシュ機能を追加

プロトコル

  • HTTP
# 設定エレメント名 説明
1 HTTP 認証マネージャ 認証機能を追加
2 HTTP クッキーマネージャ クッキーを扱う機能を追加
3 HTTP Cache Manager HTTP キャッシュ機能を追加
4 HTTP ヘッダマネージャ ヘッダを追加または上書き
5 HTTP リクエスト初期値設定 HTTP 接続テスト時のデフォルト値を設定
  • その他、既定値
# 設定エレメント名 説明
1 FTP リクエスト初期値設定 FTP リクエストのデフォルト値を設定
2 LDAP リクエスト初期値設定 LDAP リクエストのデフォルト値を設定
3 LDAP 拡張リクエスト初期値設定 LDAP 拡張リクエストのデフォルト値を設定
4 Java リクエスト初期値設定 Java リクエストのデフォルト値を設定
  • 接続設定
# 設定エレメント名 説明
1 JDBC Connection Configuration JDBC の接続設定
2 MongoDB Source Config (DEPRECATED) MongoDB Script サンプラーのための接続設定を行う

補足（HTTP クッキーマネージャは必須）: セッションを持つ Web アプリを
測定する場合、HTTP クッキーマネージャを置かないと
全リクエストが新規セッションになる。
サーバ側にセッションが際限なく積み上がり、
「負荷をかけたらメモリを食い潰した」という
測定側の設定ミスによる偽の障害を起こす。

クッキーマネージャはスレッドごとに独立した Cookie ストアを持つため、
スレッド＝仮想ユーザとして正しく振る舞う。

データ

スレッドグループ以下のコンポーネントの中から参照可能なデータ

# 設定エレメント名 説明
1 Counter カウンタを生成
2 Random Variable ランダム文字列を生成
3 User Defined Variables 任意の初期変数セットを定義
4 CSV Data Set Config 変数値を CSV ファイルで与える

補足（CSV Data Set Config の共有モード）: 分散実行やスレッド間で
同じ行を読ませたくない場合、「Sharing mode」の指定が要点になる。

Sharing mode 挙動
All threads（既定） 全スレッドで 1 つのファイル位置を共有。行が重複しない
Current thread group スレッド グループ単位で共有
Current thread スレッドごとに先頭から独立して読む（行が重複する）

「ユーザ ID が重複してログインに失敗する」の多くは
ここの設定漏れである。詳細は
Jmeterによる可変値の追跡を参照。

その他

# 設定エレメント名 説明
1 Keystore Configuration Java Key Store（証明書ストア）を設定
2 Simple Config Element 任意の値を追加・上書き（開発者向け）

タイマ

  • 待機のためのコンポーネント。
  • 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > タイマ > XXXX を選択。

スクリプト系

# タイマ名 説明
1 BeanShell Timer BeanShell(JSR-274) を使ったタイマ
2 BSF Timer (DEPRECATED) BSF を使ったタイマ
3 JSR223 Timer JSR-223 を使ったタイマ
4 Synchronizing Timer 逆セマフォ的な動きをするタイマ（瞬間的な高負荷を与える）。

定数系

# タイマ名 説明
1 Constant Timer（定数タイマ） 各スレッドリクエストのたびに指定した秒数分遅延する。
2 Constant Throughput Timer（定数スループット・タイマ） トータルのスループットが一定値に近づくように停止時間を調整する。

乱数系

# タイマ名 説明
1 Uniform Random Timer 各スレッドリクエストのたびにランダム時間停止し、遅延時間の総計は乱数値＋オフセット値の合計になるタイマ。
2 Poisson Random Timer 各スレッドリクエストのたびにランダム時間停止し、停止時間の総計はポアソン分布に従うタイマ。
3 Gaussian Random Timer 各スレッドリクエストのたびにランダム時間停止し、遅延時間の総計はガウス分布に従うタイマ。

補足（タイマは「思考時間」であって「待ち時間」ではない）: タイマを入れない
負荷テストは、人間が画面を見ずに 0 秒で次を押し続けるという
非現実的なシナリオになる。結果として、
少ないスレッド数でも過大なスループットが出てしまい、
実運用の同時接続数に換算できない。

実測から多重度を決める場合は
リトルの法則を使うのが確実である。

必要スレッド数 = 目標スループット（req/sec） × （応答時間 + 思考時間）（sec）

逆に、スループットを固定して測りたい場合は
Constant Throughput Timer（または JMeter 5.0 以降の
Precise Throughput Timer）を使い、スレッド数は余裕を持たせる。
Precise Throughput Timer はポアソン到着を再現でき、
Constant Throughput Timer よりも実際のトラフィックに近い。

なお、**Constant Throughput Timer の単位は「分あたり」**であり、
秒あたりと取り違える事故が多い。

前処理

  • 前処理のためのコンポーネント。
  • 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > 前処理 を選択。

スクリプト系

# プリプロセッサ名 説明
1 BeanShell PreProcessor BeanShell の前処理を実行
2 BSF PreProcessor (DEPRECATED) BSF の前処理を実行
3 JSR223 PreProcessor JSR-223 の前処理を実行
4 JDBC PreProcessor SQL の前処理を実行

抽出系

# プリプロセッサ名 説明
1 HTML Link Parser 応答を解析してリンクとフォームを抽出
2 RegEx User Parameters 応答を正規表現を使って解析してパラメタを抽出

その他

# プリプロセッサ名 説明
1 Sample Timeout タイマータスクが完了するまでに時間がかかりすぎると、
サンプルを中断するようにタイマータスクをスケジュールする。
2 User Parameters 個別のスレッドに対してユーザ変数を設定
3 HTTP URL Re-writing Modifier URL 書き換えを行う Web サービスでセッションを引き回す

後処理

  • 後処理のためのコンポーネント。
  • 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > 後処理 を選択。

スクリプト系

# ポストプロセッサ名 説明
1 BeanShell PostProcessor BeanShell の後処理を実行
2 BSF PostProcessor (DEPRECATED) BSF の後処理を実行
3 JSR223 PostProcessor JSR-223 の後処理を実行
4 JDBC PostProcessor SQL の後処理を実行

抽出系

# ポストプロセッサ名 説明
1 Regular Expression Extractor（正規表現抽出） 応答を正規表現を使って解析してパラメタを抽出
2 CSS/JQuery Extractor 応答を CSS/JQuery ライクなセレクタの文法を使って解析してパラメタを抽出
3 XPath Extractor 応答を XPath クエリー言語を使って解析してパラメタを抽出
4 JSON Extractor 応答を JSON-PATH syntax を使って解析してパラメタを抽出

補足（抽出系＝相関、負荷テストの本体）: この「抽出系ポストプロセッサ」こそが、
記録したスクリプトを動く負荷テストに変える要である。
応答に含まれる __VIEWSTATE、__RequestVerificationToken、
セッション ID などの可変値を次のリクエストに引き継ぐ（相関、correlation）。
具体的な手順は
Jmeterによる可変値の追跡を参照。

なお、JMeter 5.x では Boundary Extractor が追加されており、
「左境界文字列」「右境界文字列」を指定するだけで抽出できる。
正規表現より読みやすく、性能も良いため、
単純な挟み取りには Boundary Extractor を推奨する。

その他

# ポストプロセッサ名 説明
1 Debug PostProcessor ・・・
2 Result Status Action Handler サンプラーが失敗したら、スレッドまたはテスト全体を終了する。

アサーション

  • テストをしているサーバから受け取った応答を検査し、その応答が正しい応答かどうかをチェックするためのコンポーネント。
  • 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > アサーション > XXXX を選択。

スクリプト系

# アサーション名 説明
1 BeanShell Assertion BeanShell でアサーションチェックを実行
2 BSF Assertion (DEPRECATED) BSF でアサーションチェックを実行
3 JSR223 Assertion JSR-223 でアサーションチェックを実行

検証系

# アサーション名 説明
1 Response Assertion Perl 互換の正規表現かプレインテキストで比較チェック
2 Compare Assertion 応答の比較チェック（大量のリソースを消費）
3 HTML Assertion JTidy を使って応答の HTML 文法をチェック
4 XML Assertion 応答の XML 文法をチェック
5 XML Schema Assertion 応答の DTD などの XML Schema への準拠をチェック
6 XPath Assertion well-formed や DTD のオプションを持つかチェック、もしくは JTidy を通して XPath のチェック
7 MD5Hex Assertion JTidy を使って応答の MD5 ハッシュをチェック
8 SMIME Assertion Mail Reader サンプラーの応答の署名をチェック

補足（アサーションは必須）: 負荷テストで
アサーションを置かないのは重大な誤りである。
HTTP 200 が返っていても、本文が
「セッションが切れました」「ただいま混み合っています」という
エラー画面であるケースは非常に多い。
この場合、JMeter は成功として集計するため、
「速くて安定していた」という誤った結論が出る。

最低限、主要な画面に Response Assertion で
正常時にのみ現れる文字列（画面タイトル等）を検査させる。
ただし、アサーション自体も CPU を消費するため、
正規表現ではなく「Contains」の平文一致を優先する。

その他

# アサーション名 説明
1 Duration Assertion 応答を与えられた時間内に受け取ったかどうかをチェック
2 Size Assertion 応答のサイズ（バイト数）が正しいか（等しい、より大きい、より小さい、等しくない）をチェック

リスナー

  • テスト中に収集した情報を表示したりファイルへ保存したりして、結果をレポーティングするためのコンポーネント。
  • CUI（non-GUI）モード
    • 出力ファイルが構成されている場合はデータが保管される。
    • 出力ファイルのデータは、ワークベンチの適切なリスナーにロードして分析する。
  • 追加する場合、テスト計画 － サンプラーで右クリック > 追加 > リスナー > XXXX を選択。

スクリプト系

# リスナー名 説明
1 BeanShell Listener サンプルの結果に対して BeanShell を適用する。
2 BSF Listener (DEPRECATED) サンプルの結果に対して BSF を適用する。
3 JSR223 Listener サンプルの結果に対して JSR-223 を適用する。

機能テスト、デバッグ・検証用

リソースの消費量が大きいので、負荷テスト時は削除するか設定を変更する。

  • レポート用
# リスナー名 説明
1 View Results in Table（結果を表で表示） すべてのサンプル結果の行を作成
2 View Results Tree（結果をツリーで表示） サンプル応答のツリーに、すべてのサンプルの応答を表示
3 Graph Results すべてのサンプル時間をプロットする簡単なグラフを生成
  • アサーション用
# リスナー名 説明
1 Assertion Results（アサーション） Assertion エレメントの結果を表示
2 Comparison Assertion Visualizer Compare Assertion エレメントの結果を表示

移行メモ（正誤）: 原典の「レポート用」の表は
連番が 1, 2, 2 となっていたため、1, 2, 3 に修正した。

負荷テストのレポート用

リソースの消費量が小さいので、負荷テスト時に利用する。

# リスナー名 説明
1 Aggregate Report（統計レポート） テストで異なる名前の要求ごとにテーブル行を作成する。
2 Aggregate Graph テストで異なる名前の要求ごとに棒グラフを生成し、PNG ファイルを保存する。
3 Summary Report 統計レポートと似ているが、メモリ使用量が少ない点が異なる。
4 Response Time Graph 応答時間を、ラベル付きの要求毎に示す折れ線グラフに描画
5 Simple Data Writer 結果をファイルに記録（GUI には表示されない）
6 Sample Result Save Configuration 結果ログファイル（JTL）に異なる項目を保存するように設定

補足（最新化：本番測定ではリスナーを置かない）: 「リソースの消費量が小さい」と
書かれているリスナーであっても、
GUI モードで実行する限り、測定結果は信用できない。
JMeter 自身が Swing の描画とサンプル保持に CPU とメモリを費やし、
それがボトルネックになるためである。

現在の定石は次のとおり。

  1. GUI ではシナリオの作成とデバッグのみを行う。

  2. 本番測定は CLI（non-GUI）モードで実行する。

    jmeter -n -t test.jmx -l result.jtl -e -o report_dir

  3. -e -o で HTML ダッシュボードを生成し、そちらで分析する。

この方式なら、テスト計画にリスナーを 1 つも置かなくても
-l の JTL からすべてのレポートが生成できる。
詳細はJmeterの結果のレポーティングを参照。

その他

# リスナー名 説明
1 Save Responses to a file テストの作成のために結果をファイルに記録
2 Generate Summary Results テスト実行の要約をログファイルおよび/または標準出力に生成
3 Mailer Visualizer 失敗応答を受信するとメールを送る
4 Backend Listener BackendListenerClient のカスタム実装をプラグインできる非同期リスナー

補足（Backend Listener が実務の主役）: Backend Listener は
測定結果を実行中にリアルタイムで外部に送出する非同期リスナーで、
InfluxDB + Grafana の組み合わせが事実上の標準になっている。

  • 非同期なので測定への影響が小さい。
  • 長時間テストの途中経過を見られる（劣化の開始時刻が分かる）。
  • サーバ側のメトリクス（CPU・メモリ・GC）と
    同一の時間軸で重ねられるため、因果の特定が容易になる
    （因果関係の分析例）。

JMeter 5.x では InfluxDB / Graphite 用の実装が標準同梱されている。

その他

Test Fragment

  • スレッドグループまたは WorkBench に配置できる。
  • Include Controller および Module Controller とともに使用される。

Module Controller

Test Fragment で代替テスト計画に迅速かつ容易に切り替えて実行。

Include Controller

以下で作成した外部の JMX ファイルをインクルードする。

Debug

Debug Sampler

  • すべての JMeter 変数および/またはプロパティの値を含むサンプルを生成。
  • サンプルの値は、「結果ツリー・リスナー応答データの表示」ペインに表示される。

Debug PostProcessor

  • 以前のサンプラプロパティ、JMeter 変数、プロパティおよび/またはシステムプロパティの詳細を含むサンプルを生成。
  • サンプルの値は、「結果ツリー・リスナー応答データの表示」ペインに表示される。

補足: この 2 つは相関（可変値の追跡）のデバッグで
最もよく使うため、覚えておくとよい。
実際の使い方は
Jmeterによる可変値の追跡を参照。
なお、本番測定時には必ず削除または無効化すること
（全変数を毎回文字列化するため重い）。

関数と変数

補足（変数と関数の記法）: JMeter の記法は 2 系統ある。

記法 意味
変数の参照 ${変数名}（スレッドごとに独立）
関数の呼び出し ${__関数名(引数,)}（アンダースコア 2 つ）
プロパティの参照 ${__P(プロパティ名,既定値)}（全スレッド共通、CLI の -J で外から与えられる）

負荷テストの条件（スレッド数・Ramp-up・持続時間）を
プロパティ参照で書いておくと、
jmeter -n -t test.jmx -Jthreads=100 のように
JMX を編集せずに条件を変えられるため、
CI やパラメタ振りに便利である。

スクリプト

よくわからないが、以下の 3 つがあるもよう。

BeanShell(JSR-274)

Bean スクリプト・フレームワーク (BSF)

JSR-223

補足（3 つの関係）: 原典の「よくわからない」に答えると、
これらは「Java からスクリプト言語を呼ぶ仕組み」の世代交代である。

# 仕組み 位置付け
1 BeanShell Java 風の文法を持つ独立したインタプリタ。JSR-274 として標準化が試みられたが成立せず、規格としては存在しない
2 BSF（Bean Scripting Framework） Apache のスクリプト呼び出し抽象化。JSR-223 の前身
3 JSR-223（javax.script） Java SE 6 で標準採用された正式規格。BSF を置き換えた

したがって現在の選択は JSR-223 + Groovy の一択であり、
BSF は JMeter 5.0 で削除、BeanShell は非推奨である
（前掲「スクリプト系」の補足を参照）。

参考

Apache JMeter - User's Manual

Tags: 移行, テスト, ツール類

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally