2、校验金字塔：从单元测试到端到端测试的分层策略、各层比例与职责

说到持续校验，很多人第一反应就是「多写测试」。但写多少？写在哪一层？比例怎么分？

我见过不少团队，一上来就堆 UI 自动化，结果维护成本高得吓人，跑一次全量回归要一整天。也见过反过来的——只写单元测试，集成测试几乎为零，上线前心里完全没底。

说白了，测试不是越多越好，而是分层合理才有效。这就是我们今天要聊的「校验金字塔」。

2.1 校验金字塔长什么样？

这个概念最早由 Mike Cohn 提出，后来在持续交付社区被广泛采纳。它的核心思想很简单：底层测试要多、快、便宜；上层测试要少、慢、贵。

我习惯把金字塔分成三层：

• 底层：单元测试 —— 验证单个函数、方法、类的行为
• 中层：集成测试 / 契约测试 —— 验证模块间、服务间的交互
• 顶层：端到端测试（E2E） —— 验证完整业务流程

下面这张图可以帮你快速建立直观印象：

2.2 各层职责与比例

比例不是拍脑袋定的。我根据过去几个项目的经验，给出一组经过验证的参考值：

层级	推荐比例	核心职责	典型工具
单元测试	60% - 70%	验证业务逻辑、边界条件、异常路径	Jest, JUnit, pytest, Go test
集成测试	20% - 30%	验证 API 契约、数据库交互、外部服务	Spring Boot Test, Testcontainers, Pact
E2E 测试	5% - 10%	验证关键用户旅程、核心业务流程	Cypress, Playwright, Selenium

2.3 各层测试的「避坑指南」

这些年踩过的坑不少，挑几个典型的说说：

2.3.1 单元测试：别写成「实现测试」

我曾经见过一个团队，单元测试覆盖率 95%，但每次重构都全红。为什么？因为他们测的是函数内部怎么实现的，而不是函数应该输出什么。

正确的做法是：只测公开接口的行为，不测私有方法的实现细节。举个例子：

// ❌ 错误：测试内部实现
test('should call internal method', () => {
  const spy = jest.spyOn(obj, '_privateMethod');
  obj.doSomething();
  expect(spy).toHaveBeenCalled();
});

// ✅ 正确：测试外部行为
test('should return correct result', () => {
  const result = obj.doSomething(42);
  expect(result).toBe(84);
});

2.3.2 集成测试：别依赖真实环境

我记得有一次，集成测试在本地全过，但 CI 上全挂。查了半天，原来是测试里连了一个开发环境的数据库，数据被其他人改了。

解决方案很简单：用 Testcontainers 或 Docker Compose 在测试中启动临时依赖。这样每次运行都是干净的环境，不会互相影响。

2.3.3 E2E 测试：别什么都测

E2E 测试是最贵的。跑一次全量 E2E 可能要 30 分钟，如果什么都往里塞，CI 流水线会变成噩梦。

我建议只覆盖核心用户旅程：注册登录、下单支付、核心功能流转。那些边边角角的异常场景，交给单元测试和集成测试去覆盖。

2.4 如何判断你的金字塔是否健康？

这里有几个我常用的「健康检查」指标：

• 执行时间：单元测试应在秒级完成，集成测试在分钟级，E2E 不超过 15 分钟
• 失败定位：单元测试失败能直接定位到函数，E2E 失败能定位到页面和操作步骤
• 维护成本：每次需求变更，需要改动的测试数量应该与变更范围成正比
• 反馈速度：从提交代码到拿到测试结果，不应超过 10 分钟

如果发现 E2E 测试经常因为 UI 小改动就全挂，说明你的金字塔「头重脚轻」了。这时候应该把那些脆弱的 E2E 用例往下沉，用更稳定的集成测试或单元测试来覆盖。

2.5 一个实战案例

去年我带的一个电商项目，团队一开始写了 200 个 E2E 测试，单元测试只有 50 个。结果每次上线前，E2E 跑完要 40 分钟，还经常因为某个按钮位置变了就挂一片。

我们花了两个迭代做重构：

1. 把 150 个 E2E 用例拆解成 300 个集成测试 + 500 个单元测试
2. 保留 50 个核心 E2E 用例（登录、搜索、加购、支付、退款）
3. 引入契约测试（Pact）来验证服务间 API 兼容性

重构后的效果：

• 全量测试执行时间从 40 分钟降到 8 分钟
• 测试失败率从 30% 降到 5%
• 每次发布前的信心指数明显提升