测试分层

本章定位：回答「在哪一层测」。同一个性能问题，选错层级要么浪费几天，要么得出错误结论。

前置知识：第 0 章（协调遗漏、排队）、第 1 章（SLO、容量曲线） 预计总时长：约 3.5 小时（阅读 2 小时 + Lab 3 约 1.5 小时） 配套代码：docs/code/03-test-pyramid/

一、本章要回答的六个问题

1. 为什么「一上来就压全链路」通常是错的？（第 1 节）
2. 有什么测试只要几十秒、却能发现 80% 的性能问题？（第 2 节）
3. 什么时候值得做全链路压测，什么时候不值得？（第 3 节）
4. 阶梯加压、恒定压测、尖峰测试分别用来发现什么？（第 4 节）
5. 为什么「跑了 10 分钟没问题」不能说明没问题？（第 5 节）
6. 系统垮掉的时候，你该记录哪些信息？（第 6 节）

二、为什么「在哪测」比「怎么测」更先决定成败

一个真实的场景：

同事说：「订单接口慢了，你压一下看看。」

如果你直接上全链路压测，会得到这样的结果：

压测了 40 分钟，结论：QPS 800 时 P99 是 420 ms，超标。
原因：不知道。

40 分钟换来一个「不知道」。 而如果用正确的层级，可能 5 分钟就有答案：

组件基准（30 秒）：发现 select * from orders where user_id = ? 这条 SQL 的 P99 是 380 ms
→ 结论：缺索引。

核心区别：组件基准隔离了网络、网关、排队，把「慢」直接暴露成「这条 SQL 慢」。全链路压测里，这 380 ms 会被淹没在总延迟里，你只能看到「整体慢」。

本章的核心法则：要回答「为什么慢」，越往下层越好；要回答「能扛多少」，必须往上走。

三、小节地图

四、本章的产出物

1. 对一个接口的两层测试：组件基准 + 全链路压测，并说明各自发现了什么只有它能发现的问题。
2. 一条负载曲线：至少包含阶梯加压与恒定压测两种模式。
3. 一次浸泡测试：至少 30 分钟，输出资源趋势（内存、连接数、线程数是否单调上升）。
4. 一次破坏性测试记录：崩溃点、崩溃形态（超时级联？连接池耗尽？OOM？）、恢复时间。
5. 一张层级选择决策表：针对你自己的服务，写清「什么问题在哪个层级查」。

五、学完本章的验收标准

• 面对一个性能问题，能先判断该在哪个层级测，并说出理由。
• 能写出一个组件基准（真实数据库 + 采样循环 + 报告 P50/P99）。
• 能说出全链路压测的三个「值得做」的理由和三个「不值得做」的理由。
• 能设计阶梯、恒定、尖峰三种负载曲线，并说清各自要发现什么。
• 知道浸泡测试至少该跑多久，以及该盯哪些指标。
• 破坏性测试能记录崩溃形态，而不只是崩溃点。

六、一个提醒

本章开始你会真的搭环境（Testcontainers、k6、Docker）。这意味着：

• 你的结论开始变得可迁移（不再是「开发机上的数字」）。
• 但环境影响也变多了：容器 CPU 配额、数据量、数据分布、网络位置。

所以第 1 章的两张表（SLO 表、实验元数据）从本章开始真正派上用场。 每做一次测试，都要先把它们填上。