很多JMeter用戶，尤其是初學(xué)者，往往止步于最簡單的“線程組”->“HTTP請求”->“查看結(jié)果樹”的工作流。這就像擁有一把瑞士軍刀卻只用來開瓶蓋，完全浪費了它的強大潛力。

事實上，JMeter內(nèi)置了大量高效、實用的元件，掌握它們不僅能讓你從重復(fù)勞動中解放出來，更能讓你設(shè)計出專業(yè)級、易維護、高復(fù)用的性能測試腳本。本文將帶你揭秘那些被嚴重低估的JMeter神器元件，用過之后你只會感嘆：為什么沒早點知道！

1、用戶定義的變量

(User Defined Variables)

- 腳本的“控制臺”

新手做法：將域名、端口、路徑等參數(shù)寫死在每一個HTTP請求中。切換環(huán)境？準備用到令人頭皮發(fā)麻的“查找替換”功能吧！

高手做法：使用用戶定義的變量集中管理所有配置。

使用方法：

在線程組起始位置右鍵 -> 添加 -> 配置元件 -> 用戶定義的變量

在表格中定義你的變量，例如：

在所有HTTP請求的“路徑”欄中，你不再填寫完整的URL，而是使用${protocol}://${domain}:${port}${version}/login 這種形式。

推薦原因：

當需要從測試環(huán)境切換到生產(chǎn)環(huán)境時，你只需要在這個元件里修改一次domain的值（例如改為 api.your-app-prod.com），整個腳本的所有請求就全部自動生效！只需改這一個地方！維護腳本的效率提升10086倍。

2、JSR223處理器- 動態(tài)處理的終極瑞士軍刀

新手做法：遇到復(fù)雜的動態(tài)數(shù)據(jù)（如加密簽名、MD5、復(fù)雜斷言）時，試圖用各種內(nèi)置配置元件（如BeanShell、函數(shù)助手）拼湊實現(xiàn)，或者干脆選擇放棄，無法完成真實的測試場景。腳本變得臃腫、低效且難以維護。

高手做法：使用JSR223處理器并選擇Groovy作為語言，用幾行代碼輕松解決一切動態(tài)數(shù)據(jù)處理難題。Groovy語法類似Java但更簡潔，且性能遠超BeanShell，是JMeter中執(zhí)行自定義邏輯的首選。

使用方法：

位置：JSR223 PreProcessor：在請求發(fā)送前執(zhí)行，用于生成或處理參數(shù)。

JSR223 PostProcessor：在請求返回后執(zhí)行，用于提取或驗證響應(yīng)數(shù)據(jù)。

添加方法：在某個HTTP請求或節(jié)點上右鍵->添加->預(yù)處理器/后置處理器->JSR223 PreProcessor/JSR223

PostProcessor。

Language：必須選擇 groovy。

Parameters：傳遞給腳本的參數(shù)（可選）。

Script：在下方的編輯框中編寫你的Groovy代碼。

3、吞吐量控制器- 控制業(yè)務(wù)比例的金手指

新手做法：認為“線程數(shù)”和“循環(huán)次數(shù)”就能模擬所有場景，無法精確控制不同業(yè)務(wù)操作的比例。

高手做法：使用吞吐量控制器精確控制不同請求的執(zhí)行頻率。

使用方法：

3.1、右鍵線程組->添加->邏輯控制器->吞吐量控制器

3.2、將需要控制的請求（如“瀏覽商品”、“提交訂單”）放到其下面。

3.3、選擇“百分比吞吐量”，并設(shè)置比例。

Eg：一個電商場景中，100%的用戶會瀏覽商品，但只有30%的用戶會添加購物車，最后只有10%的用戶會真正下單。就可以這樣設(shè)置：

一個吞吐量控制器(100%)->瀏覽商品請求

一個吞吐量控制器(30%)->添加購物車請求

一個吞吐量控制器(10%)->提交訂單請求

它控制的是執(zhí)行次數(shù)占總迭代次數(shù)的百分比，而不是線程數(shù)。這能極其真實地模擬出線上業(yè)務(wù)的實際壓力模型，讓你的壓測結(jié)果可信度飆升。

4、事務(wù)控制器- 業(yè)務(wù)性能的真實度量衡

新手做法：在測試報告中只關(guān)注單個請求的響應(yīng)時間（如“登錄”、“查詢商品”、“下單”各自花了多久）。但用戶感知的是一個完整操作的耗時，比如“從登錄到成功下單”總共花了多少時間。單獨看每個請求無法評估整個業(yè)務(wù)流程的真實用戶體驗。

高手做法：使用Transaction Controller將一系列相關(guān)的請求（Sampler）組合成一個邏輯上的“事務(wù)”。JMeter會自動統(tǒng)計這個事務(wù)整體的響應(yīng)時間、吞吐量、是否成功等關(guān)鍵指標，讓你能從業(yè)務(wù)視角而非技術(shù)視角評估性能。

使用方法：右鍵線程組->添加->邏輯控制器->Transaction Controller。

參數(shù)說明：

Name：控制器名稱，可以根據(jù)實際情況進行設(shè)置
Comments：注釋，描述在業(yè)務(wù)中的作用
Generate Parent Sample：選中，事務(wù)控制器將作為其他取樣器的父級取樣器進行展示；不選，事務(wù)控制器僅作為獨立的取樣器進行展示
Include duration of timer and pre-post processors in generated sample：是否在生成的取樣器中統(tǒng)計包括計時器、預(yù)處理以及后置處理的延遲時間。默認是不勾選。

執(zhí)行后，可以發(fā)現(xiàn)，勾選Generate Parent Sample 后，聚合報告會將事務(wù)控制器及其下的取樣器執(zhí)行情況均匯總統(tǒng)計，最終僅以事務(wù)控制器作為結(jié)果進行匯總統(tǒng)計。

5、常數(shù)吞吐量定時器- 精準控制壓力的節(jié)流閥

新手做法：為了模擬一定壓力，盲目設(shè)置線程組的“線程數(shù)”和“循環(huán)次數(shù)”，或者使用固定的“思考時間”。結(jié)果要么壓力瞬間飆高導(dǎo)致服務(wù)器被打垮，要么壓力曲線呈鋸齒狀起伏不定，無法實現(xiàn)穩(wěn)定、精確的吞吐量控制，測試結(jié)果毫無參考價值。

高手做法：使用Constant Throughput Timer，以每分鐘采樣數(shù)為單位，精確地控制整個測試計劃每秒需要發(fā)出的請求數(shù)。這是實現(xiàn)穩(wěn)定壓力模型、進行容量規(guī)劃和穩(wěn)定性測試的終極神器。

使用方法：在測試計劃、線程組或某個HTTP請求上右鍵 -> 添加 -> 定時器 -> Constant Throughput Timer。

情景設(shè)置：假設(shè)你需要評估一個下單接口的容量，業(yè)務(wù)上這個接口的峰值流量是 每分鐘處理1200個請求（即每秒20個請求）。

JMeter會自動計算和調(diào)節(jié)！它會智能地控制每個線程的請求間隔，確保所有線程在一分鐘內(nèi)發(fā)出的請求總數(shù)精確地等于你設(shè)定的目標值（1200次）。這樣你得到的壓力曲線將是一條平穩(wěn)的直線，而不是劇烈波動的鋸齒線。

這意味著：

對服務(wù)器友好：你不會用突發(fā)流量沖垮服務(wù)器，從而得到更真實的性能數(shù)據(jù)。

結(jié)果可衡量：你可以清晰地看到，在穩(wěn)定的每秒20個請求的壓力下，系統(tǒng)的響應(yīng)時間、錯誤率、資源消耗是多少。然后你可以逐步提高目標吞吐量（如到1500、1800...），直到系統(tǒng)出現(xiàn)瓶頸（如響應(yīng)時間陡增或錯誤率上升），這個拐點就是系統(tǒng)的最大容量。

模擬真實場景：線上業(yè)務(wù)流量通常是相對平穩(wěn)的，而非瞬間爆發(fā)的，這個定時器能最真實地模擬這一特性。

關(guān)鍵配置：

Target throughput (in samples per minute)：目標吞吐量。這是核心參數(shù)，填寫你希望達到的每分鐘請求數(shù)。

Calculate throughput based on：吞吐量計算基準。

This thread only：僅控制當前線程的吞吐量。

All active threads (推薦)：基于所有活動線程數(shù)來計算和控制總吞吐量。

All active threads in current thread group：基于當前線程組的所有活動線程來計算。

All active threads (shared)：跨所有線程組控制（需要設(shè)置為全局定時器）。

6、If Controller (如果控制器)

- 讓腳本擁有智能判斷的能力

新手做法：為了模擬不同場景，編寫多個獨立的測試腳本（如一個“成功登錄”的腳本，一個“登錄失敗”的腳本）?；蛘邔⑺姓埱缶€性執(zhí)行，無法根據(jù)服務(wù)器的響應(yīng)結(jié)果動態(tài)決定后續(xù)流程，導(dǎo)致腳本僵硬、不真實，且維護成本翻倍。

高手做法：使用If Controller，根據(jù)前一個請求的響應(yīng)結(jié)果、變量值或任何可評估的條件，智能地決定是否執(zhí)行其內(nèi)部的請求。這讓你的腳本能像真實用戶一樣“思考”，根據(jù)情況做出不同反應(yīng)，極大增強了腳本的靈活性和真實性。

使用方法：右鍵線程組或控制器 -> 添加 -> 邏輯控制器 -> 如果（If）控制器。

比如上面定義了個變量，name=jmeter，下面有個百度的請求放在if控制器，if控制器條件里定義，當name=jmeter成立時，才會去執(zhí)行訪問百度的請求，否則就不執(zhí)行。

參數(shù)說明：

Name（名稱）
自定義控制器名稱，建議寫清楚判斷邏輯，如：“僅當?shù)卿洺晒r執(zhí)行”。

Condition（條件表達式）
核心參數(shù)！填寫判斷條件，比如："${status}" == "success"

Interpret Condition as Variable Expression?（將條件解釋為變量表達式？）
勾選：條件會被當作“字符串表達式”解析（推薦）
不勾選：條件需返回 “true”或“false”字符串（老版本兼容用，不推薦）

Evaluate for all children?（為所有子節(jié)點評估條件？）
勾選：每個子節(jié)點執(zhí)行前都重新判斷條件（動態(tài)場景用）
不勾選：只在控制器入口判斷一次（靜態(tài)條件用，性能略優(yōu)）

另外，我還想到一個很常見的場景： 登錄失敗自動重試（最多3次）：

1、登錄請求 → 提取 ${login_status}

2、If Controller條件設(shè)置：

${login_status} != "OK" ，計數(shù)器+再次登錄請求，直到計數(shù)器大于3，才會停止重試，并結(jié)束后續(xù)的操作。

7、JSON提取器- 告別又臭又長的正則表達式

新手做法：面對一個JSON格式的接口響應(yīng)，依然使用復(fù)雜的正則表達式提取器，像解析HTML一樣用 "token":\s*"([^"]+)" 這種模式去匹配。一旦JSON格式稍有變化（比如多了一個空格），提取立刻失敗，調(diào)試到懷疑人生。

高手做法：

位置：在需要提取數(shù)據(jù)的HTTP請求上右鍵 -> 添加 -> 后置處理器 -> JSON提取器。

假如要提取的json為：

那我們應(yīng)該設(shè)置如下：

推薦原因：精準而強大！使用標準的JSONPath語法，無論數(shù)據(jù)嵌套在多少層之下，都可以像打開一個文件路徑一樣輕松定位。表達式直觀易讀，后期維護一看就懂，再也不用 decipher（破譯）那些天書般的正則表達式了。

配置說明：
Names of created variables：定義變量名，用于存儲提取結(jié)果（例如Token）。
JSON Path expressions：填寫JSONPath表達式來定位數(shù)據(jù)（例如 $.data.token）。
Match No.：可選。如果路徑匹配到多個值，用于選擇第幾個（0表示隨機，1表示第一個）。
Compute concatenation var：可選。如果匹配到多個值，將所有值拼接后存入變量（變量名_s）。

附：常用JSONPath語法示例

以上就是本次分享的JMeter核心“神器”。它們絕非冷門的功能，而是真正能讓你從“腳本的搬運工”轉(zhuǎn)變?yōu)椤靶阅軠y試的設(shè)計師”的關(guān)鍵樞紐。

然而，工具的價值永遠取決于使用它的人。我希望大家學(xué)到的不僅僅是這些元件的用法，更是一種思維模式的轉(zhuǎn)變：從“能用”到“好用”，從關(guān)注“單個請求”到關(guān)注“業(yè)務(wù)流”，從“手動操作”到“自動化與智能化”。

??轉(zhuǎn)崗軟件I測試/野路子技能提升

??想了解更多漲薪技能提升方法

??可以到我的個人號：atstudy-js

即可加入領(lǐng)取 ??????

轉(zhuǎn)行、入門、提升、需要的各種干貨資料

內(nèi)含AI測試、 車載測試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行/游戲測試、AIGC