测试金字塔是什么
测试金字塔是 Mike Cohn 在《Succeeding with Agile》中提出的自动化测试分层模型，经 Martin Fowler 文章《The Practical Test Pyramid》推广：底层是大量快速的单元测试，中层是适量的集成与服务测试，顶层是少量端到端测试。它表达的不是硬性比例，而是成本结构——越靠下的用例越快、越稳、定位越准、维护越便宜，应承担主要验证量；越靠上的用例越接近真实用户，但慢、贵、易碎，只保留关键链路。它也是团队取舍辩论的统一语言：当有人提议再写一条 E2E 时，先用它判断有没有更低成本层级的替代方案。
基本信息
| 提出者 | Mike Cohn《Succeeding with Agile》 |
|---|---|
| 推广文章 | Martin Fowler《The Practical Test Pyramid》 |
| 底层 | 单元测试：数量最多，毫秒级反馈 |
| 中层 | 集成/服务测试：验证模块契约与关键交互 |
| 顶层 | 端到端测试：只覆盖登录、下单等核心链路 |
| 核心主张 | 用数量与成本结构指导投入分配，而非固定比例 |
典型使用场景
- 规划测试投入：新项目决定各类用例配比时作为默认起点
- 评估既有套件：判断当前形状是金字塔、倒金字塔还是沙漏
- 评审新增用例：先问验证目标属于哪一层，避免默认堆到 E2E
- CI 分级设计：提交级跑单元层，合并前跑集成层，夜间跑 E2E 层
- 与测试奖杯对照：前后端一体项目可考虑提高集成层占比
- 缺陷归位：修复缺陷时先补最低能捕获它的层级用例
- 统一语言：向新成员解释团队测试策略时的参考框架
分层目录示例
分层目录示例
tests/
unit/ # 毫秒级：每次提交都跑，数量最多
test_pricing.py
integration/ # 秒级：连真实依赖，提交级或每日构建跑
test_orders_api.py
e2e/ # 分钟级：只覆盖登录、下单等关键链路
test_checkout_flow.py常见套件形状
| 形状 | 特征 | 典型问题 |
|---|---|---|
| 金字塔 | 单元多、E2E 少 | 反馈快、整体稳，推荐默认形态 |
| 倒金字塔 | UI/E2E 占多数 | 流水线慢、失败定位难、维护成本高 |
| 沙漏 | 单元与 E2E 多、集成层空 | 单元全绿但联调即崩，问题集中暴露 |
| 奖杯（Testing Trophy） | 集成层占比最高 | 适合组件与 API 边界清晰的团队 |
层与层之间不是替代关系：单元测试证明逻辑正确，集成测试证明模块能协作，端到端测试证明业务链路可用；缺哪一层，风险就从哪里漏出去。
金字塔没有官方固定比例：常见经验是单元层贡献七成以上的用例量，但契约密集的服务端项目里集成层占比可以显著更高；关键是让每层的负担与其成本匹配。
判断形状是否健康可看三个信号：各层用例数量比、全套件执行时长、失败定位平均耗时；形状问题通常先在这两个成本指标上暴露，而不是等到线上事故。
「单元」粒度存在学派差异：经典学派允许真实协作者加少量替身，伦敦学派主张全部 mock 并验证交互；团队需约定一致口径，否则同一套件的写法会互相矛盾。
历史项目 UI 用例占比高时，改造路径通常是：新增验证优先下沉到单元或 API 层，E2E 只保留冒烟链路，逐条搬迁而非一次性重写。