08 性能与稳定性测试

狂师2026/8/25...大约 6 分钟

08 性能与稳定性测试

性能测试不能只停在「打开 JMeter 压一下，然后贴一张 QPS 图」。先明确目标，再设计压测，最后用证据定位瓶颈。

为什么重要

性能问题是最容易「上线后爆炸」的类别：功能测试全绿，大促一来系统崩了。性能测试能力 = 压测执行 + 监控观测 + 瓶颈定位，三者缺一不可。这也是面试里最能区分「用过工具」和「解决过问题」的章节——完整走通一次「压测 → 发现瓶颈 → 推动优化 → 复测验证」的闭环，就是一个高含金量项目（第 12 章项目三）。

知识清单

压测目标分类【必须掌握】

先明确测试目标，目标不同，压测模型完全不同：

目标	典型问题	压测模型
容量验证	单接口 / 核心链路能扛多少 QPS	阶梯加压，找拐点
峰值模拟	大促 / 秒杀场景扛不扛得住	定时突击（ spike ），瞬时至峰值
稳定性	长时间运行会不会内存泄漏、连接泄漏	恒定中高压持续数小时以上
限流降级验证	触发限流后系统行为对不对	越过阈值的定向压测
瓶颈定位	慢在哪里	定向单层压测 + 监控对照

压测方法论【必须掌握】

一套标准的压测流程：

定场景：压哪个接口、什么比例混合（读:写 = 8:2？）、数据规模多大（100 条订单还是 1 亿条）。
定模型：并发用户数、思考时间（think time）、持续时间、加压方式（阶梯 / 突击 / 恒定）。
备环境：环境配置和生产等比（或说明差异）、数据预热、监控就位。
执行与观察：从低负载开始，逐级加压，每级稳定后再升。
找拐点：吞吐不再涨、响应时间陡增的那个点，就是系统当前容量。
定位瓶颈：对照监控分层找（见下）。
出报告：场景、模型、指标、瓶颈证据、优化对比、结论边界。
复测验证：优化后同模型复压，对比数据闭环。

常见工具【必须掌握一个】

工具	特点	适合
JMeter	企业最常见，GUI + 脚本，协议支持广	企业求职通用性最高
k6	脚本化（JS），开发者体验好，CI 友好	开发型团队
Locust	Python 写场景，灵活建模复杂用户行为	Python 技术栈、复杂行为模型
Gatling	性能好，报告漂亮，Scala/Java 栈	JVM 技术栈团队

核心指标【必须掌握】

吞吐量：QPS / TPS（注意两者的区别：一个事务可能含多个请求）。
响应时间：平均值只是参考，P95 / P99 才是体验真相（能说出为什么平均数会骗人）。
错误率：HTTP 错误、业务错误、超时要分开统计。
资源指标：CPU、内存、磁盘 I/O、网络 I/O、线程数、连接数、GC 频率。
依赖指标：数据库慢 SQL、连接池等待、Redis 命中率、消息队列堆积。

监控与瓶颈定位【必须掌握】

没有监控的压测价值很低。至少要能看到四层：

压测机（脚本有没有成为瓶颈）
  -> 网关 / 负载均衡（连接数、限流日志）
    -> 应用服务（线程池、GC、CPU、接口耗时分布）
      -> 依赖（数据库慢 SQL、连接池、Redis、下游接口）

响应慢的排查顺序：先确认不是压测脚本自己的问题（客户端瓶颈），再看应用线程是否耗尽、GC 是否频繁，再看数据库慢 SQL / 连接池等待，再看外部依赖和网络。工具：top / vmstat、jstack / arthas、慢查询日志、链路追踪（SkyWalking / OpenTelemetry 的概念级了解）。

稳定性与混沌工程【了解即可】

稳定性测试：恒定负载跑数小时，观察内存曲线是否持续上涨（泄漏）、连接是否释放。
混沌工程概念：主动注入故障（杀进程、断网、磁盘满）验证系统韧性，了解 ChaosBlade / Chaos Mesh 的名字和用途即可，是第 09 章右移话题的延伸。

性能测试报告【必须掌握】

一份合格报告要能回答：这次压测的业务场景是什么？并发用户、请求比例、数据规模和持续时间是多少？瓶颈出在哪里，证据是什么？优化前后指标变化如何？当前结论的边界是什么（什么配置、什么数据规模下的结论）？

学习建议与常见误区

从单接口容量起步：选一个读接口（如商品查询），阶梯加压找到拐点，写第一份报告。然后进阶到混合场景（浏览 + 下单），最后做一次带监控大盘的完整压测。
练手系统：用自己 Docker 起的小服务（第 04 章）最方便，可以故意加慢 SQL、去掉索引，自己制造瓶颈自己定位，比压别人的系统收获大。
误区一：只发压不看监控。 压出 QPS 3000 然后呢？瓶颈在哪个层？「压完了」和「证明容量、定位瓶颈」之间差着一整套监控证据。
误区二：并发数等于用户数。 1000 并发线程不等于 1000 在线用户，思考时间会让真实并发远小于在线数。容量估算要说清假设。
误区三：拿压测环境数据给生产背书。 环境配置、数据量、网络拓扑都不同，结论必须标注边界。
误区四：平均值达标就安全。 平均 50ms 但 P99 是 5s，意味着每 100 个用户有 1 个等 5 秒——投诉就来自他们。

自查清单

P95 和 P99 分别代表什么？为什么性能目标通常定在分位数而不是均值？
阶梯加压、恒定负载、峰值突击三种模型分别验证什么？
QPS 和 TPS 的区别？下单事务包含 4 个请求，TPS 100 时 QPS 大约多少？
吞吐量上不去但 CPU 很闲，你的排查顺序是什么？
怎么判断「压不出更高 QPS」是服务瓶颈还是压测机瓶颈？
慢 SQL 导致 P99 高，除了加索引还可能有什么优化方向？
写出性能报告必备的六个部分。
稳定性测试跑 8 小时，内存缓慢上涨，可能是什么问题？怎么进一步确认？