📚 课程目录第4章 JMeter核心用法

第4章 JMeter核心用法：线程组、取样器、监听器、断言、参数化、逻辑控制器

性能测试搞了这么多年，我觉得JMeter最妙的地方在于——它把复杂压测场景拆成了几个积木块。你只需要搭好线程组、塞取样器、挂上监听器，再加点断言和参数化，一套压测脚本就出来了。今天我把这六个核心组件掰开揉碎了讲，全是实战里趟过坑的经验。

核心心法：JMeter的测试计划就是一棵树。根是测试计划，主干是线程组，枝干是取样器和逻辑控制器，叶子是监听器、断言、配置元件。想清楚树的结构，脚本才不乱。

4.1 线程组——压测的发动机

我习惯把线程组当成虚拟用户池。你设多少线程，就模拟多少用户。这里有个新手常犯的错——以为线程数越大越好。其实线程数受限于服务器和网络，你硬塞1万个线程，自己机器先挂了。

参数	说明	我常用的值
线程数	并发用户数	根据目标TPS计算
Ramp-Up Period	启动所有线程的时间（秒）	等于线程数/10
循环次数	每个线程执行次数	永远（用持续时间控制）
持续时间	压测时长	至少300秒（稳定期）

我曾经犯过一个低级错误——Ramp-Up设成0。结果1秒内所有线程冲上去，服务器直接打嗝。后来我学乖了，Ramp-Up时长至少是线程数的十分之一，让用户慢慢入场，更接近真实场景。

避坑：不要用「循环次数=永远」却不设持续时间。压测脚本如果没人手动停，可能跑几天几夜，白白浪费资源。我团队就出过这种事——半夜压测忘记关，第二天发现日志撑爆了磁盘。

4.2 取样器——发什么请求你说了算

取样器就是实际发送请求的组件。HTTP请求最常用，还有JDBC、JMS、FTP等。说白了就是告诉JMeter：「嘿，朝这个地址发个GET，带上这些参数」。

我现场写个例子解释一下——平时调接口最喜欢用HTTP请求默认值元件，把协议、域名、端口抽出来，后面所有取样器都不用重复填。

// 这不是代码，是配置思路
HTTP请求默认值：
  协议：https
  服务器：api.xxx.com
  端口：443
  内容编码：UTF-8
  超时连接：5000
  超时响应：10000

// 具体取样器只需填路径和参数
路径：/v1/user/login
参数：username=${user} password=${pwd}

我个人的习惯：每个取样器都配上断言，哪怕只是「响应代码200」的简单检查。否则脚本跑完了，你都不知道请求是不是真的成功了。留个坑——没有断言的结果，你敢信吗？

4.3 监听器——结果要看，但不能滥用

监听器负责收集和展示测试结果。聚合报告、查看结果树、图形结果是最常用的三件套。

监听器	用途	注意
聚合报告	统计TPS、响应时间、错误率	压测时不要GUI开这个，资源吃太多
查看结果树	调试脚本，看请求/响应详情	调试完就禁用，否则压测时内存爆
图形结果	实时看趋势	适合本地调试，慎用于大规模压测

记得有一次，我用JMeter压线上服务，开着查看结果树跑了半小时，JMeter进程占了8G内存——收集的响应数据全堆在树上。打那以后，我压测一律用命令行模式（jmeter -n -t script.jmx -l result.jtl），监听器只配一个简单的聚合报告或者干脆用后端监听器写数据库。

高效做法：压测时不要用任何图形化监听器，改用简单数据写入器（Simple Data Writer），把原始结果存成CSV，事后用分析脚本处理。这样JMeter本身性能开销降到最低。

4.4 断言——结果到底行不行？

断言就是自动检查响应是否符合预期。响应断言最常用——检查返回的JSON里有没有"success":true，或者状态码是不是200。

我通常会在每个关键取样器下挂两个断言：

状态码断言：验证HTTP响应码为200/201/302等
内容断言：用JSON断言或响应文本断言，检查业务字段

你想想看——假如你压测一个登录接口，返回的HTTP码全是200，但响应体里写的是"登录失败"，你的压测结果还有意义吗？我一开始就踩过这个坑，跑了500并发，错误率0%，结果一查全是验证码错误的提示。从那以后，断言成了我脚本里的必需品。

// 断言示例：JSON断言
断言路径：$.code
期望值：0
是否相等：是

// 或者用响应断言
模式匹配：包含
测试模式：登录成功

4.5 参数化——别让所有用户用同一个账号

真实场景里，每个用户的信息都不一样。如果100个线程都用同一个用户登录，服务器可能把后面的请求当作重复登录拒绝掉。这就需要用参数化来模拟不同用户。

CSV数据文件配置：最常用的方式。我习惯把测试数据放在CSV里，第一列是用户名，第二列是密码，一行一个用户。

列名	数据
username	test_001
password	123456
email	test_001@abc.com

配置的时候注意「线程共享模式」，默认是「所有线程」，意味着所有线程共用同一个CSV指针，不会重复读取同一行。但如果用「当前线程」，每个线程独立读取，适合不同用户循环使用。

函数助手：适合生成动态数据。比如用${__counter(,)}生成递增序号，用${__Random(1,100)}生成随机ID。我经常在压测注册场景时，用函数助手直接生成随机手机号：1${__Random(3000000000,3999999999)}，省去准备CSV的麻烦。

坑点：CSV文件编码必须跟JMeter工程编码一致。我用UTF-8保存CSV，但Excel默认GBK，导进去乱码。后来我统一用VSCode保存CSV，指定UTF-8 without BOM，再没出过乱码问题。

4.6 逻辑控制器——控制脚本执行流程

有了逻辑控制器，脚本不再是一条直线。你可以做循环、条件判断、交替执行等操作。

我最常用的几个：

循环控制器：让一段请求重复执行多次，比如反复提交表单
交替控制器：轮流执行子节点，比如模拟不同接口的混合请求
若控制器：根据条件执行，比如登录成功后才能操作下单
吞吐量控制器：按比例控制请求分布，实现混合场景压测

说到混合场景，我之前做个电商压测：60%的流量是浏览商品，30%是加购物车，10%是提交订单。用吞吐量控制器设好百分比，完全不用手动编排线程。

逻辑控制器还支持嵌套，比如循环控制器里套个如果控制器，实现「如果当前用户有优惠券，就执行下单」这种复杂流程。嗯，这里要注意——嵌套太深会降低脚本可读性，我一般不超过3层。

我的六步搭脚本法：先建线程组（定并发）→ 加取样器（定请求）→ 挂断言（验结果）→ 配参数化（造数据）→ 加逻辑控制器（控流程）→ 上监听器（收结果）。顺序不重要，但每一步都不能少。我团队新人都按这个流程走，脚本很少返工。

这六个组件就像乐高积木。线程组是底座，取样器是马达，断言是质检，参数化是不同颜色的砖块，逻辑控制器帮你搭出复杂造型，监听器则是检查成品的手电筒。不会用的组件，先去官网看文档，或者用JMeter的「模板」功能生成一个Demo脚本，拆开看看别人怎么配的。我在项目里反复翻过十几个模板，才练出现在的水平。

好了，这一章的内容就到这里。把这六个核心组件用熟了，你在性能测试里已经能跑通80%的场景了。剩下20%是细节——比如分布式压测、自定义Java请求、数据库压测，我们后面章节再细聊。