软件测试金字塔速览

软件测试金字塔不是一套固定配方，而是平衡自动化测试成本与反馈速度的指导模型：底层保留大量快速、聚焦的单元测试；中层使用较少的集成测试和契约测试；顶层只留下少量覆盖完整业务流程的端到端测试。

层级越高，覆盖范围越广，但运行速度、定位效率和稳定性通常越差。测试组合真正应该服从的，是系统架构、缺陷来源、反馈时间和维护成本，而不是某个固定比例。

测试属于哪一层，取决于运行时需要多少系统组件参与，而不是使用了什么测试库。

三个基础层级

单元测试

单元测试只加载一个函数或类，输入数据并检查结果。定价规则、数据校验、状态机和多分支逻辑都适合放在这里。它运行快、定位直接，可以在每次保存代码时执行。

它的边界也很明确：单元测试全部通过，只能说明各个部件独立运行正常，不能证明它们已经正确连接。如果测试开始锁定私有方法的调用顺序，它验证的就不再是行为，而是实现细节，维护成本会迅速上升。

集成测试和服务测试

中层测试保留自己的代码，只替换边界另一侧的依赖。例如，仓储测试连接真实数据库；路由测试运行真实 HTTP 处理器、序列化和错误映射，同时把支付网关替换为桩。

这里最值得覆盖两类问题：一类是序列化边界上的字段名、类型和错误映射；另一类是数据库唯一约束、事务回滚等真实引擎行为。与其争论它是带数据库的单元测试，还是带桩的服务测试，不如看它启动了什么、能发现什么缺陷。

端到端测试

端到端测试以用户或调用方的方式驱动已部署系统，验证业务真正关心的结果。它能同时覆盖组件、配置和环境，也是最慢、最依赖测试数据、最容易不稳定的一层。

顶层需要有意保持精简，只保留那些失败后可能造成资金损失、阻断用户或阻止发布的关键流程。某个端到端测试失败后，应继续追问：同一个缺陷能否由更窄的测试提前发现？如果可以，就补上窄测试；只有广测试仍能提供额外信心时，才继续保留它。

反复重跑直到变绿的测试已经不再是可靠证据，应尽早修复或隔离。

API 和契约测试如何分层

API 描述的是接口，不是测试范围。同一个 HTTP 请求可以位于不同层级：

• 请求进入内存路由，所有外部调用都使用桩，属于组件测试或集成测试
• 请求进入单个运行中的服务，连接自己的数据库，其他服务使用桩，位于服务层
• 请求穿过多个已部署服务，即使没有浏览器，也属于端到端测试

UI 测试同样如此。连接模拟网络的组件渲染测试仍然很窄，虽然它验证了用户看到的内容。判断层级时，应看运行范围，而不是 API、UI 这样的接口名称。

契约测试位于中层。它验证消费者和提供者是否就请求、响应结构达成一致，却不需要启动完整业务流程。以 Pact 为例，消费者记录自己发送的请求和预期响应，提供者在自己的流水线中回放契约，可以在部署前发现协议漂移。

契约测试可以替代一部分端到端测试，但不能替代提供者自己的功能测试，也不适合性能测试、负载测试或不受控消费者的公共 API。

固定比例为什么不可靠

70% 单元测试、20% 集成测试、10% 端到端测试只是常见示意，不是测试金字塔的硬性要求。架构不同，合理形状也不同：规则引擎往往需要更宽的单元测试底座；大量调用其他服务的微服务，风险更多集中在边界，中层自然会变宽。

更可靠的规则是：把每项检查放到能够证明该行为的最低层，只有更广的测试提供了额外信心时才保留它。

调整测试组合时，重点观察四类证据：

• 缺陷主要出现在哪些位置
• 每一层需要运行多久
• 哪些测试经常因非产品原因失败
• 哪些测试只是重复证明同一条规则

用真实缺陷和运行数据调整测试组合，比追逐一个漂亮比例更有价值。

金字塔之外的两种形状

测试奖杯主要面向 JavaScript 应用。它在底部加入类型检查和 Lint 等静态检查，把最大权重放在集成测试，因为前端风险经常出现在组件、状态和请求之间的接缝。如果核心风险是大量独立业务分支，单元测试仍然更便宜。

测试蜂巢主要面向微服务。它强调单个服务与真实边界之间的集成测试，尽量减少依赖其他已部署系统才能通过的集成式测试。服务自身逻辑较薄、风险集中在服务调用时，可以用契约测试支撑中层，而不是堆积跨团队端到端测试。

三种模型并不矛盾。它们都主张优先使用窄而快的测试，控制广测试数量，并让测试分布跟随风险位置变化。

常见反模式

最典型的反模式是冰淇淋甜筒：大量缓慢的端到端测试建立在很薄的底层之上。它常常来自每发现一个缺陷就新增浏览器测试，却从不清理，最终导致套件运行缓慢、定位困难。

另外两种成本更隐蔽：

• 重复覆盖：同一条规则在每一层都被验证，一个缺陷触发多层失败，一次变化要修改多份测试
• 过度模拟：数据库、队列和时钟全部被替换，测试验证的是团队想象中的依赖行为，而不是真实行为

覆盖率也不能代表测试形状，更不能说明关键行为是否得到验证。探索性测试、性能测试、安全测试和无障碍测试则属于独立质量活动，不应被强行塞进金字塔。

把测试套件放进 CI

CI 应按反馈速度和覆盖范围排序，而不是按测试名称排序：

• 先运行单元测试和集成测试，尽快拦截规则和装配错误
• 接着运行契约测试，在部署前发现协议破坏
• 最后对已部署环境运行少量 API 和 UI 端到端测试
• 每个阶段快速失败，不让基础错误继续消耗昂贵环境

从第一天起，至少记录每层运行时间，以及因非产品原因失败的频率。前者能指出快速阶段何时不再快速，后者能指出哪些测试应该修复或删除。

简要结论

测试金字塔可以浓缩成一条规则：在能够证明行为的最低层完成验证，只有更广的测试能提供额外信心时才保留它。

固定比例、层级名称，以及选择金字塔、奖杯还是蜂巢，都是围绕系统风险做出的本地决策。测量每层运行时间和真实失败，让测试形状跟随证据变化。

收录于 FunTester 原创专题：软件测试的道与术

相关阅读：Pact：微服务契约测试的利器 · 测试计划与测试策略的工程化边界 · Go 测试不迷路：单元测试与集成测试详解 · 自动化测试的 8 个最佳实践 · 敏捷中的端到端测试