【背景】 我做了 5 年测试开发，最近被一个很朴素的问题卡住了：性能回归测试到底算不算「测试」？
传统功能测试的逻辑很清晰：输入 → 断言 → pass/fail，二值判定，结果理想情况下是确定的。但性能测试呢？同一个接口、同一台机器、同一份数据，JMeter 跑 10 次 P99 能散出 8~15ms 的波动。这时候你说「P99 ≤ 20ms 算 pass」——我跑出来 19.2ms 我信不信？我同事跑出来 21.3ms 他信不信？
这不是「机器不够好」的问题，而是性能结果天然带噪声。打个比方：功能测试像用尺子量桌子，量两次结果一样；性能测试像称体重，今天 72.3kg、明天 71.8kg，你很难说「桌子变短了 0.5cm」。它是「体检」，不是「考试」。
【常见的几种做法】 我在不同团队见过至少三种流派：
A 派——「全量进 CI」：每个 PR 都跑核心接口的性能基准，P99 超阈值就 block 合并。 优点：问题在最早阶段暴露。 缺点：CI 时间从 8 分钟飙到 40 分钟，开发怨气很大；而且 flaky 率不低（我见过的团队在 5%~15% 之间），误报频繁，最后大家学会「重跑一次就过」。
B 派——「发布前独立跑」：CI 只管功能和集成，性能测试单独一条流水线，打 tag / 发版前跑一轮，人工看报告决定能不能发。 优点：不阻塞日常开发，报告可以积累趋势。 缺点：如果 3 个 PR 叠加引入了 2ms 退化，每个单独看都没超阈值，合在一起就超了——温水煮青蛙，而且「到底是谁引入的」回溯成本高。
C 派——「SLO 驱动 + 线上拨测」：不关心 CI 里的性能测试，靠线上 SLO 预算 + 定时拨测兜底，P99 漂移了再回溯。 优点：最接近真实用户体感。 缺点：发现时已经影响用户了，回溯时「到底是哪个 PR 引入的」经常查不清楚——尤其索引变更、配置变更这类不体现在代码 diff 里的东西。
【我的倾向与理由】 我倾向 B 派 + 一点 A 派的混合，具体分三层：
第一层（CI 内）：只跑「性能冒烟」——3 个核心接口、单并发、100 次请求，目的不是测性能，而是断言没出现数量级退化（比如 P99 突然从 15ms 飙到 150ms，大概率是死循环或 N+1 查询）。阈值设宽（比如硬阈值 10 倍），只拦「灾难级退化」，不拦 1~2ms 的抖动。
第二层（发布候选阶段）：跑完整压测场景（多并发、阶梯加压、混合读写），产出趋势报告。报告里设一条「滑动窗口基线」：连续 3 个版本 P99 单调上升超过 10%，即使没超硬阈值也触发 review。这一层解决「温水煮青蛙」。
第三层（线上）：SLO 预算 + 拨测兜底，但拨测结果要能关联到 commit / release，让回溯有抓手。
为什么不硬塞进 CI 全量跑？因为性能测试的信噪比天然比功能测试低。在信噪比不够的环节硬卡流程，只会制造「测试疲劳」——大家开始跳过、忽略、甚至绕过，最后这条规则形同虚设。不如承认它「不像功能测试那么确定」，把它放到信噪比更充裕的环节（发布前、低峰期、独占资源）。
【想听大家怎么选】
- 你们团队的「性能回归」在哪个环节跑？CI 里、发布前、还是纯线上？
- 如果有进 CI 的，flaky 率大概多少？你们怎么处理的——自动重试？隔离到独立 job？还是直接容忍误报、靠人工判断？
- 有没有人试过「性能测试的测试」——比如用统计方法（t-test、置信区间、CUSUM 变点检测）来判断「这次退化是不是真的」？效果如何，还是说工程上根本不值得？
- 纯 C 派（SLO + 拨测）的兄弟们：你们有没有遇到过「线上 P99 漂了 3 天才发现是某个索引变更 / 配置变更引入的」这种回溯噩梦？当时怎么定位的？
- 一个更根本的问题：你们团队里「性能测试」这个活，到底是 QA 的、开发的、还是 SRE 的？ ownership 不清是不是 flaky 和推诿的根因？
欢迎拍砖，尤其是 A 派和 C 派的朋友，我想听听你们为什么坚持。