做功能测试久了，有没有这种感觉：明明每个接口单独看都没问题，一上线并发一上来，系统就开始抽风——页面转圈圈、接口超时、数据库连接池打满……
这些问题，功能测试发现不了，只能靠性能测试。
今天这篇文章，就是写给想入门性能测试、但不知道从哪里开始的朋友。我会手把手带你，用 JMeter 写出第一个性能测试脚本。零基础也能跟得上。
为什么要学 JMeter？
先说个现实：不懂性能测试的测试工程师，天花板很低。
现在的互联网公司，招测试工程师几乎都会问一句：“有没有做过性能测试？” 不是因为这个技能有多高深，而是因为系统上线后出的性能问题，往往比功能 Bug 更要命——功能问题影响部分用户，性能问题可能直接让整个系统宕机。
那为什么是 JMeter？
几个很实在的理由：
- 免费开源，不要钱——Apache 基金会出品，永久免费
- 上手快，生态成熟——搞性能测试的人几乎都在用，社区资料多到看不完
- 支持协议多——HTTP、HTTPS、JDBC、FTP、WebService……你遇到的大多数场景都覆盖了
- 可视化界面——不用写代码，点点点就能跑起来，对新手极度友好
换句话说：JMeter 就是性能测试领域的新手村神器。
学会了它，你才算真正踏进了性能测试的大门。
JMeter 是什么？
JMeter 的全称是 Apache JMeter，最初是为了测试 Apache Web 服务器的性能而开发的，后来逐渐演变成一款通用的负载测试工具。
它的核心原理很简单：
用模拟并发请求的方式，向目标服务器发起压力，然后统计服务器的响应情况。
你可以把它想象成一个”模拟用户”的工具——你告诉它模拟多少个”用户”，每个”用户”以什么节奏去访问哪个接口，它就帮你老老实实地执行，然后把结果统计出来。
几个关键概念先混个脸熟，后面你会反复见到它们：
- 测试计划（Test Plan）：整个测试的配置文件，相当于”剧本”
- 线程组（Thread Group）：模拟的用户组，包含有多少用户、以什么方式执行
- 取样器（Sampler）：具体的请求，比如 HTTP 请求、JDBC 查询
- 监听器（Listener）：查看结果的方式，结果树、聚合报告都是它
- 配置元件（Config Element）：比如参数化、Cookie 管理等辅助配置
别急着记，用着用着就熟了。
安装和启动
这部分我尽量说得简洁，安装其实就两步。
第一步：下载 JDK
JMeter 是用 Java 写的，运行它需要 JDK（Java Development Kit）。建议 JDK 11 或以上版本。
下载地址：https://adoptium.net/（推荐 Adoptium 的 Temurin 版本，稳定免费）
安装完成后，打开命令行输入 java -version，能看到版本号就说明装好了。
第二步：下载 JMeter
官网：https://jmeter.apache.org/
进入下载页面，下载 Binary 版本的压缩包（.zip 或 .tgz），解压到任意目录即可。
启动 JMeter：
- Windows 用户：进入
bin目录，双击jmeter.bat - Mac/Linux 用户：进入
bin目录，执行./jmeter
启动后，你会看到一个界面，左边是空的测试计划，右边是工作区。这就是 JMeter 的主界面了。
💡 小提示：第一次启动 JMeter 时，建议用管理员身份运行（Windows），否则可能会遇到一些写入权限问题。
第一个脚本：手把手完整步骤
激动人心的环节来了！我们现在就写一个最简单的脚本：模拟 10 个用户，同时访问一个网站首页，统计响应情况。
步骤一：创建测试计划
JMeter 打开后，默认就有一个空的”测试计划”。
点击测试计划，给它起个名字，比如 我的第一个性能测试，下面的描述可以写：“模拟10个用户访问百度首页”。
测试计划名称建议用英文或拼音，路径中不要有中文，避免一些奇怪的兼容性问题。
步骤二：添加线程组
右键点击测试计划 → 添加 → 线程（用户）→ 线程组
线程组配置页面中，有三个数字你需要知道：
| 参数 | 含义 |
|---|---|
| 线程数 | 模拟的用户数量，这里填 10 |
| Ramp-Up 时间（秒） | 所有用户启动的总时间，这里填 5（即5秒内逐步启动10个用户） |
| 循环次数 | 每个用户重复执行多少次，这里填 1 |
解释一下：10 个线程，Ramp-Up 5 秒，意味着 JMeter 会在 5 秒内均匀地启动 10 个用户线程，每 0.5 秒启动 1 个。这样模拟的是”逐步加压”，而不是”瞬间爆炸”。
步骤三：添加 HTTP 请求采样器
右键点击线程组 → 添加 → 取样器 → HTTP 请求
在 HTTP 请求的配置页面，填写：
- 协议：https（大多数网站现在都是 https 了）
- 服务器名称或 IP：www.baidu.com（注意不要带 https:// 前缀）
- 端口号：443（HTTPS 默认端口，留空也可以）
- 路径：/（表示访问首页）
- 请求方法：GET
📌 小技巧：路径那里写
/就是访问百度首页，如果写/s?wd=hello，就是访问百度搜索”hello”的页面。
步骤四：添加监听器（查看结果）
现在脚本已经搭好了，但你还需要一个”眼睛”来看结果。JMeter 提供了很多监听器，这里我们用两个最常用的。
第一个：查看结果树
右键线程组 → 添加 → 监听器 → 查看结果树
这个可以看到每一次请求的详细信息——请求参数、响应数据、响应时间、状态码。它适合调试脚本用。
第二个：聚合报告
右键线程组 → 添加 → 监听器 → 聚合报告
这个适合看整体性能数据，是最常用的性能指标汇总表。
步骤五：运行脚本
点击工具栏上的绿色 ▶️ 按钮（或按 Ctrl+R），脚本就开始运行了。
等待几秒钟（取决于你设置的 Ramp-Up 时间），运行结束后，点击”聚合报告”就能看到结果了。
脚本运行后，怎么看结果？
现在脚本已经搭好了，但你还需要一个”眼睛”来看结果。JMeter 提供了很多监听器，这里我们用两个最常用的。
第一个：查看结果树
右键线程组 → 添加 → 监听器 → 查看结果树
这个可以看到每一次请求的详细信息——请求参数、响应数据、响应时间、状态码。它适合调试脚本用。
第二个：聚合报告
右键线程组 → 添加 → 监听器 → 聚合报告
这个适合看整体性能数据，是最常用的性能指标汇总表。
步骤五：运行脚本
点击工具栏上的绿色 ▶️ 按钮（或按 Ctrl+R），脚本就开始运行了。
等待几秒钟（取决于你设置的 Ramp-Up 时间），运行结束后，点击”聚合报告”就能看到结果了。
脚本运行后，怎么看结果？
Average（平均响应时间）：所有请求的平均耗时。这个数字越大，说明系统越慢。一般来说，接口响应时间 < 200ms 算优秀，200-500ms 是可接受，超过 1 秒就要注意了。
Error%（错误率）：请求中出错的占比。错误率 > 1%，就要排查是脚本问题还是服务器真的扛不住了。
Throughput（吞吐量）：服务器每秒能处理的请求数。这个数字越大，说明服务器性能越好。可以简单理解为——吞吐量越高，系统承载能力越强。
💡 怎么看自己系统的性能是好是坏？记住一个原则：和自己的历史数据比，不要和别人的系统比。 每个系统的业务场景和硬件配置都不一样，横向比较没意义。
常见新手坑
坑一：响应断言忘加，查出来的数据全是”成功”
很多新手跑完脚本一看，100% 成功率，兴高采烈——结果一看响应体，全是报错信息。
原因：JMeter 默认只看你请求有没有发出去、发出去有没有返回，不看返回内容对不对。
解决办法：给 HTTP 请求添加”响应断言”。右键 HTTP 请求 → 添加 → 断言 → 响应断言。设置你要校验的关键字，比如包含 "code":200，这样只有真正返回正确内容的请求才会被标记为成功。
坑二：没设参数化，同一个用户被重复测试
你测试登录接口，10 个线程用的都是同一个账号——结果服务器检测到异常，直接把账号封了，或者数据库里插了一堆重复数据。
解决办法：用 CSV 数据文件做参数化。添加”CSV 数据文件设置”配置元件，把用户名密码写在 CSV 文件里，JMeter 会自动按行读取，每个线程取不同的值。
坑三：结果文件太大，把 JMeter 跑崩了
新手喜欢用”查看结果树”来追踪所有请求，跑个大并发测试，几万个请求全写进内存，JMeter 直接卡死给你看。
解决办法：正式压测时，把”查看结果树”禁用或删掉。只保留”聚合报告”这类汇总型监听器。如果确实需要保存详细日志，用 Simple Data Writer 保存到文件，而不是用结果树。
坑四：不懂关联，两个请求之间断了
你登录后拿到了一个 token，但下一个接口需要这个 token 才能访问——结果请求失败了。
原因：JMeter 默认不会自动把上一个请求的返回数据传给下一个请求，需要你手动”关联”。
解决办法：用”正则表达式提取器”或”JSON 提取器”，从上一个请求的响应中提取需要的数据（比如 token），存成变量，在下一个请求里引用。听起来复杂，但用一次就明白了。
坑五：只看平均响应时间，被平均值骗了
你的平均响应时间是 200ms，看起来挺正常——但实际上 50% 的请求在 50ms 内完成，剩下 50% 都在 5 秒以上。平均值被严重拉平了。
怎么看：看 Median（中位数） 和 90% Line（90%线） 这两个指标。中位数表示 50% 请求的响应时间，90%线表示 90% 请求的响应时间。这两个数字差距越大，说明性能越不稳定。
写到最后
看到这里，恭喜你！你已经完成了 JMeter 从零到一的跨越——会装、会配、会跑、会看结果。
但这只是开始。
性能测试真正难的，不是工具本身，而是怎么设计一个合理的性能测试场景。比如：
- 什么叫”正常用户”的访问模式？
- 压力要加到多大才算测透了？
- 如何判断系统性能的瓶颈在哪里？
这些问题的答案，需要你在实践中慢慢摸索。
下一步，建议你学习这些内容：
- 参数化和关联——做更复杂的业务场景测试
- Think Time（思考时间）——模拟真实用户的操作节奏
- 分布式压测——用多台机器联合压测，模拟更大并发
- 性能监控——配合 Grafana + Prometheus，看服务器 CPU、内存、GC 等指标