4. 性能回归策略

性能回归测试，说白了就是「版本升级了，性能别掉坑里」。我见过太多团队，上线前只跑功能测试，结果新版本一上线，接口响应时间从 50ms 飙到 500ms，用户直接炸锅。嗯，今天我们就聊聊怎么把这件事做扎实。

4.1 回归测试范围界定：不是所有接口都要测

很多同学一上来就问：「我该压哪些接口？」我的回答是：不是所有接口都值得回归。你想想看，一个系统几百个接口，全压一遍，时间成本谁扛得住？

我个人习惯用「三圈法」来界定范围：

• 核心圈：用户高频使用的接口（比如登录、下单、支付）。这些必须回归，没得商量。
• 影响圈：本次代码变更涉及到的接口，以及它们依赖的下游服务。我在项目中遇到过，改了一个订单查询接口，结果把库存服务的连接池打满了——这就是影响圈没覆盖到。
• 风险圈：历史上出过问题的接口，或者近期重构过的模块。这些地方容易埋雷，我建议至少跑一轮轻量级压测。

4.2 基线版本建立：没有对比就没有伤害

基线版本是什么？说白了就是「一把尺子」。你新版本跑出来的数据，得跟这把尺子比，才知道是进步了还是退步了。

建立基线版本，我一般分三步走：

1. 选一个稳定的旧版本：通常是上一个正式发布的版本，或者某个里程碑版本。别拿开发中的版本当基线，那叫自欺欺人。
2. 在相同环境下跑一轮完整的压测：环境配置、数据量、压测参数，全部记录清楚。我曾经吃过一次亏，基线版本用的 4 核 8G，新版本用的 8 核 16G，结果性能提升了 50%，我还以为是代码优化得好——后来发现是硬件作弊。
3. 把结果固化下来：TPS、响应时间、错误率、CPU 使用率、内存占用，这些关键指标存到文档或数据库中。下次回归时直接拉出来对比。

4.3 对比指标选取：TPS、响应时间、错误率

指标选多了容易眼花，选少了又怕漏掉问题。我个人习惯盯死三个核心指标：TPS、响应时间、错误率。这三个指标，基本能反映系统的「快不快、稳不稳、好不好」。

4.3.1 TPS（每秒事务数）

TPS 代表系统的吞吐能力。说白了就是「系统一秒能处理多少请求」。这个指标我一般关注两点：

• 峰值 TPS：系统能扛的最大并发量。如果新版本峰值 TPS 下降了 10% 以上，基本可以判定性能退化了。
• 稳定 TPS：长时间运行下的平均吞吐。有些系统峰值很高，但跑几分钟就掉下来了，这种「虚胖」的 TPS 没有意义。

4.3.2 响应时间

响应时间，用户感知最直接。我一般看三个分位值：

为什么看分位值而不是平均值？因为平均值会被极端值拉偏。举个例子：100 个请求，99 个 100ms，1 个 10s，平均值接近 200ms，看起来还行，但那个 10s 的请求用户早就骂娘了。

4.3.3 错误率

错误率这个指标，我把它当作「一票否决权」。只要错误率超过 1%，不管 TPS 多高、响应时间多低，这个版本都不能上线。

常见的错误类型包括：

• 超时错误：请求发出去，服务端没响应。通常是连接池耗尽或线程阻塞。
• 业务错误：接口返回了非 200 的状态码。比如库存不足、参数校验失败。
• 系统错误：500、502、503 这些。说明系统已经扛不住了。

4.4 回归策略的整体流程

说了这么多，我画了一张流程图，帮你把整个回归策略串起来：

4.5 避坑指南：我踩过的几个坑

做性能回归这么多年，我踩过不少坑。分享几个典型的：

• 坑一：基线版本数据丢失。有一次换电脑，基线数据没备份，新版本跑出来不知道跟谁比。后来我养成了习惯，每次基线数据都存到 Git 仓库里，跟代码一起管理。
• 坑二：环境不一致。基线版本在测试环境跑的，新版本在预发环境跑的，两个环境配置不一样，对比结果毫无意义。现在我要求回归测试必须在同一套环境上执行。
• 坑三：只看平均值。前面说了，平均值会骗人。我建议把 P95、P99 也纳入对比范围，尤其是 P99，最能反映系统的尾部延迟。

好了，关于性能回归策略，今天就聊到这里。记住一句话：没有基线，就没有对比；没有对比，就没有优化。下次做回归测试的时候，先把基线建好，再动手压测。