2.3 自动化测试金字塔

2.3 自动化测试金字塔

本节摘要：自动化测试金字塔主张：大量快速的单元测试打底，适量的服务层集成测试居中，少量的端到端测试封顶。分层的原因是各层在"反馈速度、可信度、维护成本"三个维度上各有长短。本节讲清各层的分工边界、好测试的判据、契约测试对集成爆炸的缓解，以及测试套件臃肿后的瘦身方法。

读完这节你能回答

1. 解释测试金字塔分层的经济学逻辑
2. 区分"有回归价值的测试"与"只是覆盖率的测试"
3. 用契约测试替代一部分跨服务端到端测试
4. 对变慢的测试套件执行一次系统性瘦身

一、倒金字塔的危险

先看一个真实团队走过的弯路。该团队起步时没有单元测试文化，质量把关靠测试工程师手工回归，后来引入自动化，选择了见效最快的方式：把手工用例全部翻译成端到端的界面自动化脚本。三个月后他们有了 400 个自动化用例，覆盖率看起来很美。然后问题开始显现：全量跑一遍要四个小时；界面文案改一个字，三十个用例失败；偶发失败占了两成，没人分得清是真缺陷还是脚本抖动。一年后，这套自动化因为"维护不过来"被整体废弃。

他们建的是"倒金字塔"——大量重而脆的端到端测试压顶，缺少轻而稳的单元测试打底。头重脚缓，一次小小的震动就全盘崩塌。

金字塔的分层不是审美偏好，是三笔经济学账。

速度账。单元测试以毫秒计，全量数千个几十秒跑完；端到端测试以分钟计，还要排队等真实环境。速度决定了测试能被运行的频率——只有跑得快的测试才能在每个提交上都跑（反馈原则）。

定位账。单元测试失败，问题就在那几十行代码里；端到端测试失败，问题可能在界面、接口、数据库、网络、测试数据的任何一处。同样一个缺陷，在不同层暴露，排查成本差一个数量级。

维护账。端到端测试与系统耦合面最宽，任何一处改动的破坏半径都最大；单元测试只与一个模块耦合，维护成本最低。把测试投资按金字塔分布，总维护成本最低。

二、三层分工与配比

单元测试验证一个函数、一个类的行为，外部依赖（数据库、网络、时钟）全部用替身替换。它有两个常被忽视的要求：一是快，一个单元测试超过 100 毫秒就该审视；二是确定性，同一份代码必须时绿时绿，任何随机因素（随机数、当前时间、遍历顺序）都要被钉死。

服务层集成测试验证模块之间的协作：服务与真实数据库的读写、消息的收发、接口契约的正确性。这一层的关键是"依赖要真、范围要窄"——拉起真实的数据库容器，但只测一个服务，不把上下游全串起来。上节流水线配置里的集成测试段就是这一层。

端到端测试从用户的视角穿过整个系统，验证"整列车真的能从始发站开到终点站"。它最接近真相，也最贵最脆，所以只保留最关键的用户旅程：下单、支付、登录这类一旦损坏就是事故的主干路径。把端到端测试当成对前两层抽样复核的手段，而不是发现日常缺陷的主力——主力在下面两层。

三、什么样的测试才有价值

覆盖率是一个被广泛误解的指标。覆盖率衡量"哪些代码被执行过"，不衡量"断言是否验证了正确的行为"。下面两段测试代码覆盖率完全相同，价值天差地别。

// 无价值：调用一遍不断言，纯凑覆盖率
test('订单计算', () => {
  calcOrderTotal({ items: [...], coupon: 'SALE10' });
});

// 有价值：断言具体行为，含边界与失败路径
test('满减券作用于含运费订单的顺序', () => {
  const t1 = calcOrderTotal({ items: [{price: 95, qty: 2}],
                             shipping: 12, coupon: 'OVER150' });
  expect(t1.discount).toBe(20);        // 满减基准不含运费
  expect(t1.total).toBe(202);          // 190 - 20 + 12

  const t2 = calcOrderTotal({ items: [{price: 95, qty: 1}],
                             shipping: 12, coupon: 'OVER150' });
  expect(t2.discount).toBe(0);         // 未达门槛不生效，不报错
  expect(t2.warnings).toContain('未满减门槛');
});
​

判别好测试的一个实用问句：**"如果这段代码的行为悄悄变错了，这个测试会红吗？"**会红，它就是资产；可能不红（断言松、路径没走到），它就是负债——不仅不防回归，还给人虚假的安全感，并且让套件白白变慢。

⚠️ 常见坑：为了覆盖率指标对 getter、setter、纯配置代码补测试。这类测试维护成本为正、回归价值趋零。覆盖率应作为"发现完全没被测试的模块"的雷达，而不是逐行达标指标；追求形式化的百分百往往把套件塞满负债。

四、契约测试：缓解集成爆炸

微服务架构下，服务 A 依赖服务 B 的接口。要验证两者协作，传统做法是端到端地把 A、B 及其全部依赖串起来测——服务一多，组合数爆炸，环境搭建和维护成本失控。另一种极端是各自单元测试全用模拟，接口不兼容要等到联调甚至上线才发现。

契约测试走中间道路：消费方把自己的期望写成契约，提供方在自己的流水线里单独验证自己满足契约。两边不需要同时在场，兼容性在各自的 CI 里持续被验证。

# 消费方声明的契约片段：订单服务依赖用户服务
contract: user-service / get-user
request:
  method: GET
  path: /users/{id}
response:
  status: 200
  body:
    id: 42
    name: "张三"          # 期望字段存在且类型为字符串
    level: 3              # 期望字段存在且类型为数字
​

用户服务的流水线每次变更都会跑一遍所有消费方登记的契约。若某次重构删掉了 level 字段，不是等订单服务的工程师来投诉，而是用户服务自己的 CI 立刻标红。契约测试把"跨团队的集成验证"拆解成了"各自独立运行的兼容性验证"，这是金字塔中间层在分布式场景下的重要扩展。

五、套件瘦身的四个动作

测试套件和代码一样会腐化。当你发现全量测试超过二十分钟、或团队开始习惯性忽略某几个"总是红"的测试，就该执行瘦身。

动作一：隔离 flaky。统计每个测试的历史通过率，把低于九成的移入隔离区单独跑。flaky 测试不修复就等于教团队无视红色，危害比没有测试更大。隔离后逐个根治：种子随机数、冻结时钟、等待显式条件而不是固定休眠。

动作二：删除不再反映需求的测试。业务规则改了、功能下线了，对应测试应该删而不是改个期望值硬凑绿。测试是行为的规格说明，规格过时了就是噪音。

动作三：下移。审查慢的集成测试：其中验证的究竟是协作问题还是纯逻辑问题？纯逻辑的搬回单元层（提速一到两个数量级），只留真正需要真实依赖的部分。

动作四：标记分层执行。给测试打上"每次提交跑 / 每日定时跑 / 发布前跑"三级标签，提交时只跑第一级。这本质上是把金字塔从空间分层扩展到了时间分层。

本节要点回顾

• 倒金字塔的教训：全靠端到端，四小时一轮、脆、维护不动，最终废弃——分层是经济学必然
• 三笔账：速度决定运行频率，定位决定排查成本，维护决定长期存活
• 配比参考：单元八成、集成一成五、端到端半成；端到端只留关键用户旅程
• 好测试判据："行为悄悄变错时它会红吗"——松断言的测试是负债
• 契约测试：期望写成契约、提供方各自验证，把集成爆炸拆解为独立 CI 检查
• 瘦身四动作：隔离 flaky、删除过时、逻辑下移、分层标记执行