测试分层 on Dorkytiger 的小屋

六层金字塔总览

Mon, 01 Jan 0001 00:00:00 +0000

3.1 六层金字塔总览

上一节：无　|　下一节：3.2 组件基准

一句话结论

性能测试分六层，每层回答不同的问题。 记住一条法则：要回答「为什么慢」，越往下层（越隔离）越好；要回答「能扛多少」，必须往上走（越接近真实）。

一、用汽车研发理解六层测试

汽车厂商研发一款新车，不会直接让试车员开上高速测。它会经历一整套逐级放大的测试：

汽车研发阶段	对应的性能测试	干什么	成本
零件台架试验	微基准	一个轴承在试验台上转到坏，测寿命	极低
总成试验	组件基准	发动机装在台架上跑，测功率油耗	低
整车转鼓试验	集成基准	整车在实验室里模拟行驶	中
真实道路测试	全链路负载	开上真实道路、真实天气、真实交通	高
碰撞试验	破坏性测试	故意撞毁，看怎么坏、能不能保命	高
耐久路试	浸泡测试	跑 10 万公里，看哪里先磨坏	很高
量产决策	容量测试	决定生产多少台、什么配置	很高

从这张表能读出三件事：

越往上越接近真实，也越贵。 台架试验一小时几百块，风洞试验按小时上万。
越往下越容易定位。 台架上的轴承坏了，你立刻知道是轴承的问题；整车上异响，你要查几十个可能。
每一层都有它才能发现的盲区。 台架测不出风噪，路测才能；路测测不出 10 万公里后的磨损，耐久才能。

性能测试完全一样。

二、六层详解

层级	测什么	时间尺度	单次耗时	能发现	盲区
① 微基准	单个方法/算法	纳秒–微秒	秒级	算法与常数优化、分配热点	看不到 IO、锁、GC 的真实交互
② 组件基准	Repository、序列化、缓存	微秒–毫秒	几十秒	SQL 慢、N+1、序列化开销、索引缺失	无网络、无网关、无真实并发
③ 集成基准	单服务完整启动 + 真实依赖	毫秒	分钟级	连接池、事务、启动预热、AOP 开销	无多服务放大效应
④ 全链路负载	多服务 + 网关 + 真实网络	毫秒–秒	十分钟级	排队、级联、限流、超时配合	成本高、定位难、噪声大
⑤ 专项测试	压力 / 尖峰 / 浸泡	分钟–小时	小时级	拐点、崩溃形态、资源泄漏	不回答「为什么」
⑥ 容量测试	多副本 + 负载分配	小时	小时级	副本数与规格决策	需要接近生产的拓扑

三、核心判断法则

法则一：诊断往下，容量往上

「这个接口为什么慢？」 → 往下走：组件基准 / 微基准 / 剖析
「这个服务能扛多少？」 → 往上走：全链路负载 / 容量测试

混用会怎样：

组件基准：性价比最高的一层

Mon, 01 Jan 0001 00:00:00 +0000

3.2 组件基准：性价比最高的一层

上一节：3.1 六层金字塔总览　|　下一节：3.3 集成基准与全链路配套代码：03-test-pyramid/02-component-benchmark

一句话结论

后端 80% 的性能问题（慢 SQL、N+1、序列化开销、索引缺失、锁竞争）都能在组件基准里被发现，而它的迭代成本只有几十秒。 这是投入产出比最高的一层，也是大多数团队完全缺失的一层。

一、用「台架试验」理解组件基准

汽车厂商测发动机，会把它装在台架上：接上真实的油路、水路、排气，但不装在整车上。

为什么？

台架的好处	对应组件基准
环境可控、可重复	固定数据集、固定随机种子
出问题立刻知道是发动机的	慢就是这条 SQL 慢，不会怪到网络上
一次试验几分钟，一天能试几十轮	一次基准几十秒，快速迭代
能测到极限工况（红线转速）	能测到极端数据（1 亿行、热点 key）

关键：台架用的是真发动机，不是模型。同理，组件基准必须用真实数据库（Testcontainers 起的 PostgreSQL），不能用 H2 之类替代品——因为索引行为、执行计划、锁机制完全不同。

用 H2 做基准的后果：在 H2 上很快的查询，在 PostgreSQL 上可能因为执行计划不同而慢 100 倍。你会得到「测试通过、上线爆炸」的经典结局。

二、组件基准测什么：四件事分开测

一个接口的真实成本 = SQL 执行 + 驱动/ORM 映射 + 业务逻辑 + 序列化。必须分开测，否则你只知道总数，不知道哪块贵。

测什么	怎么测	常见发现
① 纯 SQL 执行	直接用 JDBC 执行，不含映射	缺索引、全表扫描、锁等待
② 驱动/ORM 映射	对比「JDBC 结果集 → 对象」与①的差值	ORM 的反射开销、N+1
③ 业务逻辑	用固定输入调用 service 方法，mock 掉 IO	算法问题、重复计算
④ 序列化	单独测 JSON 编解码	反射型序列化器、大对象

为什么必须分开：假设你测出「接口总耗时 60 ms」，你无法判断该优化哪个。分开之后：

集成基准与全链路：什么时候值得

Mon, 01 Jan 0001 00:00:00 +0000

3.3 集成基准与全链路：什么时候值得

上一节：3.2 组件基准　|　下一节：3.4 负载曲线配套代码：03-test-pyramid/03-integration-and-e2e

一句话结论

集成基准补的是「单服务完整启动」这一层；全链路压测补的是「排队与跨服务放大」。 全链路很贵，只该用在验收 SLO、测容量、验证级联行为这三件事上——绝不能用来定位瓶颈。

一、用「转鼓试验」和「真实路试」理解这两层

	转鼓试验（集成基准）	真实路试（全链路）
在哪跑	实验室，整车在转鼓上	真实道路
有什么	真车、真发动机、真轮胎	加上真实天气、交通、坡度、油品
能发现	整车级别的匹配问题（变速箱逻辑、散热）	高速风噪、长上坡过热、堵车时的油耗
成本	中	高
可重复性	高（环境可控）	低（天气、交通不可控）

对应到后端：

	集成基准	全链路负载
范围	单服务完整启动 + 真实依赖	多服务 + 网关 + 真实网络
能发现	连接池、事务边界、AOP/拦截器开销、启动预热、序列化链路	排队、级联超时、限流配置、跨服务放大
成本	分钟级	十分钟到小时级
可重复性	高	中（受环境噪声影响大）

二、集成基准：填补「单服务完整」的空白

组件基准只测一个 Repository 或一个方法。但真实请求还会经过：

HTTP 层 → 拦截器/中间件 → 鉴权 → 参数校验 → 业务逻辑 → 事务 → 多个 Repository → 序列化 → 响应

这些环节的成本（拦截器链、事务开启/提交、日志、指标埋点）只有把服务完整启动起来才能测到。

负载曲线：阶梯、恒定、尖峰

Mon, 01 Jan 0001 00:00:00 +0000

3.4 负载曲线：阶梯、恒定、尖峰

上一节：3.3 集成基准与全链路　|　下一节：3.5 浸泡测试配套代码：03-test-pyramid/04-load-profiles

一句话结论

三种负载曲线用来发现三种不同的问题：阶梯加压找拐点，恒定压测验证稳态 SLO，尖峰测试验证弹性与恢复。用错曲线，就会测不出你关心的问题。

一、用汽车测试理解三种路况

路况	负载曲线	测什么
匀速巡航	恒定到达率	稳定工况下的油耗与舒适度
逐步加速到极限	阶梯加压	最高能跑多快、什么时候开始抖动
急加速 + 急刹车	尖峰测试	刹车性能、恢复能力、热衰减

汽车厂商三种都测，因为它们暴露的问题完全不同。后端也一样。

二、阶梯加压（Ramping）：找拐点

长什么样

到达率
  ↑
2000 ┤                                    ╭──── 崩溃点
1000 ┤                        ╭───────────╯
 700 ┤              ╭─────────╯  ← 拐点
 400 ┤      ╭───────╯
 100 ┤──────╯
     └──────────────────────────────────────→ 时间
       每级：爬升 30s + 稳态 2~5min

关键参数（每一项都有理由）

参数	建议值	为什么
起始负载	目标容量的 10%~20%	先建立低位基线
每级增幅	1.5–2 倍	太大跳过了拐点，太小耗时太久
爬升时长	30 秒	让系统有时间升到该级（不要瞬间跳变）
稳态时长	2–5 分钟	⚠️ 最关键：队列要建立、缓存要进入混合状态、GC 周期要走过至少一轮
终止条件	崩溃线（第 1 章 1.4 节）	避免把服务压死

最容易犯的错：每级只跑 30 秒

为什么不行：

浸泡测试：唯一能发现泄漏的测试

Mon, 01 Jan 0001 00:00:00 +0000

3.5 浸泡测试：唯一能发现泄漏的测试

上一节：3.4 负载曲线　|　下一节：3.6 破坏性测试配套代码：03-test-pyramid/05-soak-testing

一句话结论

浸泡测试（Soak Test）是唯一能发现「缓慢泄漏」的测试——内存泄漏、连接泄漏、文件描述符泄漏、缓存无界增长。它也是最少人做、回报最高的一种测试，因为它发现的问题往往是半夜 OOM 的直接原因。

一、用「耐久路试」理解浸泡测试

汽车厂商会让一台车连续跑 10 万公里，穿越各种气候与路况。

为什么不跑 1000 公里就够了？

有些问题是随里程累积的：密封圈老化、机油消耗、变速箱磨损。
短途试驾永远发现不了这些——因为它们需要时间。

后端完全一样：

短时间压测（10 分钟）	长时间浸泡（数小时）
发现「慢」和「错」	发现「缓慢变坏」
内存看起来稳定	内存每小时涨 50 MB → 12 小时后 OOM
连接数正常	连接数每小时涨 3 个 → 一天后池子耗尽
文件描述符正常	FD 缓慢泄漏 → 一天后 `Too many open files`

关键：泄漏类问题不会在 10 分钟内显现。它们的特点是「每天的增量很小，但永不回落」——只有拉长时间轴才能看出来。

二、泄漏的四种典型形态

泄漏类型	表现	常见原因
内存泄漏	堆使用持续上升，Full GC 后也不回落	静态集合持有对象、监听器未注销、`ThreadLocal` 未清理、缓存无界
连接泄漏	池中 `active` 持续上升，`idle` 下降，`total` 触顶	异常路径未归还连接、事务未关闭、`use {}` 漏写
线程/协程泄漏	线程数或协程数持续上升	未取消的 `GlobalScope`、未关闭的线程池、阻塞操作堆积
文件描述符泄漏	FD 数持续上升	未关闭的文件/套接字、日志句柄泄漏

Kotlin 特有的两个泄漏源：

破坏性测试：崩溃点与崩溃形态

Mon, 01 Jan 0001 00:00:00 +0000

3.6 破坏性测试：崩溃点与崩溃形态

上一节：3.5 浸泡测试　|　下一节：3.7 层级选择与成本配套代码：03-test-pyramid/06-breakdown-testing

一句话结论

破坏性测试的价值不在于「知道多少 QPS 会垮」，而在于「知道它是怎么垮的」。 崩溃形态决定了故障的影响范围、恢复难度，以及半夜被叫起来时你该做什么。

一、用「碰撞试验」理解破坏性测试

汽车厂商会故意把车撞毁。这不是为了证明车安全，而是为了回答：

碰撞试验要回答的	对应后端
撞了之后哪个部位先变形？	哪类资源先饱和？
乘员舱能不能保住？	核心功能是否还可用（优雅降级）？
是吸能变形还是直接断裂？	是排队变慢，还是直接报错？
撞完还能不能开？	流量回落后能否自愈？
二次碰撞会怎样？	重试会不会造成二次打击？

注意第一个问题：碰撞试验不是只测「多少速度会撞坏」，而是测撞坏的整个过程。

后端也一样：「800 QPS 时崩」这个信息价值有限；「800 QPS 时连接池先满，然后所有接口一起超时，且流量回落后需要 4 分钟才恢复」才是真正有用的结论。

二、五种典型的崩溃形态

崩溃形态	现象	根因	影响范围
① 超时级联	上游超时返回，但对下游的调用还在继续，资源被占住	超时链未递减（第 1 章 1.5 节）	扩散到所有接口
② 重试风暴	系统越慢，客户端重试越多，负载越高	没有退避、抖动、重试预算	自我放大，可能击穿
③ 连接池雪崩	所有连接被慢请求占住，新请求全部排队超时	池太小 + 查询变慢 + 无超时	该服务的所有数据库操作
④ 无界队列 OOM	请求堆积到内存耗尽，进程被杀	队列无上限、无拒绝策略	整个进程
⑤ 限流缺失	一个慢依赖拖垮整个服务的所有接口	没有隔板（按依赖隔离资源池）	全站

怎么观察这五种形态

形态	要采集的数据
超时级联	各层超时配置 + 各依赖的调用数与耗时
重试风暴	客户端重试次数、服务端 QPS 与服务端收到的实际请求数
连接池雪崩	`active`/`idle`/`pending`/`total` 四条曲线 + 获取连接等待时间
无界队列 OOM	队列深度 + 堆使用曲线 + 拒绝/丢弃计数
限流缺失	各依赖的并发数分布（一个依赖是否占用了全部线程/连接）

三、「崩溃点」是次要的，「恢复能力」才是关键

关键问题

① 崩溃点：多少 QPS 开始不可用？
② 恢复时间：流量回落后，多久回到正常？
③ 能否自愈：不重启能不能恢复？
④ 是否残留：恢复后有没有留下副作用（缓存被污染、连接泄漏）？

② 和 ③ 经常被忽略，但它们决定了故障的严重程度。

层级选择与成本

Mon, 01 Jan 0001 00:00:00 +0000

3.7 层级选择与成本

上一节：3.6 破坏性测试　|　下一节：3.8 Lab 3 配套代码：03-test-pyramid/07-selection-and-cost

一句话结论

压测环境本身就是钱（机器、数据准备、人力、时间），而不同层级的成本差几个数量级。能用便宜层级回答的问题，绝不用贵的层级——这不只是省钱，更是为了迭代速度，而迭代速度直接决定优化质量。

一、用「风洞试验按小时计费」理解成本

汽车研发里：

试验	成本	一天能做几次
台架试验	几百元/小时	十几次
转鼓试验	几千元/小时	几次
风洞试验	上万元/小时	一次

工程师的直觉：能用台架回答的问题，绝不进风洞。

因为：风洞一次要几小时，你一天只能验证一个假设；台架一次几分钟，你一天能验证二十个假设。假设验证次数直接决定你找到正确解的概率。

后端完全一样。

二、成本对照表

层级	单次耗时	环境需求	数据准备	一天能做的轮次
① 微基准	秒级	一台开发机	无	上百
② 组件基准	几十秒	一台开发机 + 容器	一次性准备	几十
③ 集成基准	几分钟	一台机器 + DB/缓存	一次性准备	十几次
④ 全链路负载	20–60 分钟	完整环境 + 独立压测机	每次可能都要准备	2–5
⑤ 浸泡测试	1–12 小时	独占环境	一次性	< 1
⑥ 容量测试	数小时	接近生产的拓扑	完整	< 1

看第 4 行和第 2 行的对比：全链路一天只能试 2–5 个假设，组件基准能试几十个。

Lab 3：同一个接口的两层测试

Mon, 01 Jan 0001 00:00:00 +0000

3.8 Lab 3：同一个接口的两层测试

上一节：3.7 层级选择与成本　|　下一节：第 4 章工具链配套代码：03-test-pyramid/08-lab3 预计时长：90 分钟

一、这个 Lab 的目标

亲手验证本章的核心论断：不同层级会发现不同的问题，而且有些问题只有某一层能发现。

做完之后你应该能对任何性能问题回答：「这个该在哪一层测，为什么不是另一层。」

二、任务清单

#	任务	产出	时长
1	搭组件基准（Testcontainers + 采样循环）	`ComponentBench.kt` + 结果表	35 min
2	搭集成基准（Ktor 完整启动）	`IntegrationBench.kt` + 结果表	20 min
3	全链路压测（k6 从另一进程）	k6 报告	20 min
4	对比三层结果，写出「只有它能发现」的清单	实验档案	15 min

三、任务 1：组件基准

准备：

用 Testcontainers 起 PostgreSQL（不要用 H2）。
建表并灌 10 万行数据，用幂律分布（前 1% 的用户占 30%–40% 的查询）。
建必要的索引，故意留一个没有索引的列作为对照。

要测的四件事（分开测）：

#	测什么	预期发现
1	主键查询 `findById`	走索引，P99 应该很低
2	二级索引查询 `findByUserId`	走索引 + 回表
3	无索引列查询 `findByStatus`	⚠️ 全表扫描，P99 随数据量线性恶化
4	批量查询 vs 循环单查	量化「消除 N+1」的收益

方法要求：