企业官网建设流程全解析

很多人做性能测试就是「跑一下 Jmeter，截个图，写个报告」，但真到线上出了性能问题，根本不知道从哪查起。

这篇把性能测试的核心指标、测试类型、Jmeter 实战、瓶颈定位、报告写法全部串起来，新人能建立完整认知，老人能对照查漏补缺。

一、性能测试到底测什么

性能测试不是「测一下快不快」，而是在给定的负载条件下，验证系统的响应时间、吞吐量、资源利用率是否满足要求。

举个真实场景：电商大促前，产品说「下单接口要支持 500 并发，响应时间不超过 500ms」。性能测试要做的就是：模拟 500 个用户同时下单，看响应时间能不能达标、系统会不会崩、瓶颈在哪。

性能测试的核心价值：在上线前发现容量瓶颈，避免线上被流量打挂。

二、必须搞懂的 6 个核心指标

一个关键认知：TPS 和并发数不是线性关系。并发数从 0 增加时，TPS 线性上升；到某个点后 TPS 增长放缓；超过系统瓶颈后，TPS 开始下降，响应时间急剧上升，错误率飙升。这个拐点就是系统的最大容量。

三、性能测试的 5 种类型

很多人把「压力测试」当成性能测试的全部，其实它只是其中一种。

实际项目中最常用的组合：先做基准测试（单用户）→ 负载测试（预期并发）→ 压力测试（找极限）→ 稳定性测试（长时间）。

四、Jmeter 压测实战

Jmeter 是最常用的开源压测工具，支持 HTTP、数据库、MQ 等多种协议。

4.1 命令行执行压测

GUI 模式只用来调试脚本，正式压测必须用命令行（非 GUI 模式），否则 GUI 本身会消耗资源影响结果。

jmeter-n-torder_test.jmx-lresult.jtl-e-oreport/

参数说明：-n非 GUI 模式，-t指定脚本，-l结果文件，-e -o生成 HTML 报告。

4.2 压测脚本的核心结构

一个 Jmeter 脚本（.jmx）的核心组成：

Test Plan ├── Thread Group（线程组：设置并发数、循环次数、持续时间） │ ├── HTTP Request（请求：URL、方法、参数） │ ├── HTTP Header Manager（请求头：Content-Type、Token） │ ├── CSV Data Set Config（参数化：从CSV读取测试数据） │ ├── Response Assertion（断言：校验响应码或响应内容） │ └── Timer（定时器：模拟用户思考时间） └── Listener（监听器：查看结果，命令行模式不需要）

4.3 线程组参数怎么设

Number of Threads (users): 500 Ramp-Up Period (seconds): 60 Loop Count: 永远 Duration (seconds): 600

含义：60 秒内启动 500 个线程，持续运行 600 秒（10 分钟）。Ramp-Up 不能设为 0，否则瞬间加压会把系统打懵，也不符合真实用户行为。

4.4 参数化避免缓存干扰

压测时如果所有请求都查同一个 ID，数据库和缓存会命中热点，结果不真实。用 CSV 参数化让每个请求用不同数据。

CSV Data Set Config Filename: user_ids.csv Variable Names: userId Delimiter: ,

请求中引用变量：

GET /api/order/${userId}

五、压测场景设计（实战重点）

不要一上来就 500 并发跑 10 分钟，科学的场景设计是这样的：

场景1：基准测试

单用户循环调用 100 次，得到单用户下的响应时间和 TPS，作为后续对比的基线。

线程数: 1 循环次数: 100 持续时间: 不限制

场景2：阶梯加压

逐步增加并发，找到 TPS 拐点和响应时间突变点。

100 并发 → 运行 5 分钟 200 并发 → 运行 5 分钟 300 并发 → 运行 5 分钟 500 并发 → 运行 5 分钟 800 并发 → 运行 5 分钟

每一档记录 TPS、平均响应时间、90 分位响应时间、错误率、CPU/内存。阶梯加压是找瓶颈最有效的方式。

场景3：峰值测试

模拟大促峰值，用最大预期并发持续跑 15-30 分钟，验证系统在峰值下是否稳定。

场景4：混合场景

真实用户不会只调一个接口。按业务比例混合多个接口，比如下单 60%、查询 30%、支付 10%，更贴近真实流量。

场景5：稳定性测试

用 50%-70% 的峰值负载持续跑 12-24 小时，重点观察内存是否持续增长（内存泄漏）、连接数是否堆积、GC 是否频繁。

六、瓶颈定位方法论

压测出了问题，不要瞎猜，按这个顺序自上而下查：

第一步：看应用服务器资源

top-c

看 CPU 使用率、负载（load average）、进程状态。CPU 持续 100% 说明计算瓶颈；CPU 不高但响应慢，可能在等 IO 或锁。

vmstat15

看us（用户态CPU）、sy（内核态CPU）、wa（IO等待）。wa高说明磁盘 IO 是瓶颈。

第二步：看数据库

SHOWPROCESSLIST;SHOWENGINEINNODBSTATUS;

看有没有大量锁等待、慢 SQL、连接数打满。数据库是最常见的瓶颈点，重点看慢查询日志和锁等待。

第三步：看应用日志和 GC

tail-fapp.log|grepERROR jstat-gcutil<pid>1000

看有没有异常、超时、重试风暴。GC 频繁（YGC 每秒多次、FGC 间隔短）说明内存不够或有大对象。

第四步：看网络和下游依赖

netstat-an|grepTIME_WAIT|wc-l

TIME_WAIT 堆积说明连接没复用。下游服务（Redis、MQ、第三方接口）响应慢也会拖垮上游。

瓶颈定位的核心原则：一次只改一个变量，改完重新压测对比，确认是不是这个瓶颈。不要同时改多处，否则不知道哪个起了作用。

七、性能测试报告怎么写

一份合格的性能测试报告包含这些部分：

报告里必须有对比数据：优化前 vs 优化后的 TPS 和响应时间对比，用数字说话，不要写「性能有提升」这种空话。

八、真实案例：下单接口从 200 TPS 优化到 1500 TPS

现象：下单接口压测，200 并发时 TPS 只有 200，响应时间 800ms，CPU 才 30%。

排查过程：

1. CPU 不高但 TPS 上不去 → 不是计算瓶颈，可能在等什么
2. vmstat看wa不高 → 不是磁盘 IO
3. 查数据库SHOW PROCESSLIST→ 大量行锁等待
4. 看代码 → 下单时先查库存再扣减，用了SELECT ... FOR UPDATE，热点商品行锁竞争严重

优化方案：

• 库存扣减改用 Redis 原子操作（DECR），减少数据库行锁
• 数据库只做最终一致性记录，异步同步库存
• 热点商品库存分桶，降低锁粒度

优化结果：同样 200 并发，TPS 从 200 提升到 1500，响应时间从 800ms 降到 120ms。

这个案例说明：性能瓶颈往往不是机器不够，而是设计问题（锁、缓存、SQL）。

九、经验总结

给新人的建议

1. 先搞懂指标再动手：TPS、响应时间、并发数的关系没搞懂，压测数据就是一堆数字
2. 压测必须参数化：所有请求查同一个 ID，结果没有参考价值
3. 命令行模式压测：GUI 模式本身耗资源，会影响结果
4. 压测同时监控资源：只看 Jmeter 结果不看服务器资源，等于白测
5. 一次只改一个变量：定位瓶颈的基本原则

给老人的进阶点

1. 全链路压测：不只是单接口，要模拟真实用户链路（浏览→加购→下单→支付）
2. 流量录制回放：用线上真实流量录制，压测时回放，比模拟数据更真实
3. 性能左移：在 CI/CD 中加入性能门禁，每次代码变更自动跑基准测试，性能劣化超过阈值就拦截
4. 混沌工程：在压测中注入故障（杀节点、网络延迟、磁盘满），验证系统的容错和自愈能力
5. 容量规划：不只是找瓶颈，还要根据业务增长预测未来 3-6 个月需要多少机器

最后

性能测试的本质不是「跑个工具出个报告」，而是理解系统在压力下的行为，找到瓶颈，用数据驱动优化。

记住这个公式：科学的场景设计 + 全面的监控 + 一次一个变量的定位 = 有效的性能测试。

如果这篇帮你建立了性能测试的完整认知，欢迎点赞收藏。后续会更新 Jmeter 进阶、全链路压测、性能调优实战，关注不迷路。

#软件测试 #性能测试 #测试工程师 #Jmeter #压测 #接口测试 #自动化测试