一句话：金字塔表达的是成本结构（越往上越慢、越贵、越脆），不是用例数量的 KPI——把它当比例指标考核，就是下一个被刷掉的数字。
定位：测试技术第 3 页。回答"自动化用例放在哪一层"，把 [[黑盒测试技术]] 与 [[白盒测试与覆盖率]] 的手段落到工程结构上。
上游：[[测试过程模型与左移右移]]（左移与 CI 回路的理论基础） · 下游：[[FlakyTest治理]]（分层失稳的典型症状）、[[测试度量与质量成本]]（自动化 ROI）
一、原始表述与三层定义
测试金字塔（Mike Cohn，《Succeeding with Agile》2009）：
╱╲ UI / E2E 少、慢、贵、脆
╱ ╲
╱────╲ Service / API 中等
╱ ╲ （集成、组件、契约）
╱────────╲ Unit 多、快、省、稳
╱__________╲
| 层 | 测什么 | 单次耗时量级 | 稳定性 | 失败定位精度 | 维护成本 | 能拦住什么 |
|---|---|---|---|---|---|---|
| 单元 Unit | 函数/类/模块的行为与边界 | 毫秒 | 高 | 精确到函数/分支 | 低（重构时需同步改） | 逻辑错误、边界、分支遗漏 |
| 服务/接口 Service | 模块间协作、API 契约、DB 交互 | 百毫秒~秒 | 中 | 到接口/组件 | 中 | 集成错误、契约不匹配、数据问题 |
| UI / E2E | 端到端业务流程、跨系统 | 秒~分钟 | 低 | 到页面/步骤（常需人工判读） | 高（脆弱） | 装配错误、流程断裂、真实环境差异 |
比例数字的真相：网上常见的"单测 70% / 集成 20% / E2E 10%"（或 60/30/10）没有权威出处，是 Cohn 图形的口语化转述。本页刻意不给推荐比例——比例的合理值由被测系统的形状决定，见 §二。
二、其他分层模型（说明"金字塔不是唯一答案"）
| 模型 | 主张 | 提出语境 | 隐含代价 |
|---|---|---|---|
| 测试金字塔 | 单元最多，越往上越少 | 单体应用、传统后端 | 前端/微服务语境下"业务价值覆盖不足" |
| 测试冰淇淋筒（反模式） | 手工/UI 测试最多，单测最少 | 无架构约束的团队自然演化 | 反馈慢、维护成本爆炸 |
| 测试奖杯 Testing Trophy | 静态检查 → 单元 → 集成（最厚） → E2E | 前端 / React 生态（Kent C. Dodds） | 集成测试的环境依赖成本被低估 |
| 蜂巢模型 Honeycomb | 以集成/契约测试为主体，单测与 E2E 都少 | 微服务架构（Spotify 语境） | 需要成熟的契约与本地仿真能力 |
| 沙漏（反模式） | 单元 + E2E 多，中间层空 | 常见于"单测写得好但服务层缺位" | 中间层缺口直接变成缺陷逃逸 |
关键判断（高级回答的分水岭）：金字塔/奖杯/蜂巢的差异来自语境，不是对错——
- 单体、领域逻辑密集 → 金字塔仍然最优（逻辑在单元里能被精确验证）
- 前端/UI 重、逻辑薄 → 奖杯（静态检查 + 组件测试性价比最高）
- 微服务、跨服务装配复杂 → 蜂巢（契约测试是唯一能低成本覆盖服务间装配的手段，见 [[接口与契约测试]]）
- 无论哪种形状，共同不变量是："反馈越快、定位越准的测试应该越多"
三、成本曲线（为什么要"金字塔"而不是"倒过来"）
要拆成四个独立维度看，混在一起谈就会得出"E2E 更真实所以更好"的错误结论：
| 维度 | 单元 | 服务/接口 | UI/E2E | 变化趋势 |
|---|---|---|---|---|
| 编写成本 | 低（随代码一起写） | 中 | 高（环境、数据、选择器） | 近似线性上升 |
| 执行成本 | 毫秒级 | 百毫秒级 | 秒~分钟级 | 上升 2~4 个数量级 |
| 维护成本 | 低（重构需同步） | 中 | 高（非线性） | 超线性上升（最容易被低估） |
| 失败信噪比 | 高（失败即真问题） | 中 | 低（环境/数据/flaky 混杂） | 下降 |
成本
↑ ╱ 维护成本（E2E，超线性）
│ ╱
│ ╱
│ ╱ ╱ 执行成本
│ ________╱ ＿＿＿＿╱
│ ＿＿╱
└──────────────────────────────────────────→ 层级
单元 服务/接口 UI/E2E
最被低估的一条：E2E 的维护成本不是"编写成本的 2 倍"，而是随 UI/环境变更反复触发。业界常引用"1 个 E2E ≈ 10 个单测的编写成本、50 倍维护成本"这类倍数（⚠️ 属经验值，无权威出处，见 §口径提示）——数量级直觉可用，数字不可引用。
由此得到的核心结论：金字塔不是审美偏好，而是在给定覆盖率目标下让总成本最小的结构。当有人要求"全都写 E2E"，等价于要求"用最贵的工具做同一件事"。
四、反模式（形状诊断）
| 反模式 | 形状 | 典型症状 | 根因 | 修正路径 |
|---|---|---|---|---|
| 冰淇淋筒 Ice Cream Cone | ▽（倒三角） | 手工回归为主、E2E 一堆、单测几乎没有；发布前"回归周" | 无架构约束，测试从 UI 开始写 | 先补服务层契约测试（收益最快）→ 再补单元 |
| 沙漏 Hourglass | ⧗ | 单元覆盖高、E2E 多，中间层空 | 单测由开发写、E2E 由 QA 写，缺"服务层"归属人 | 明确服务层 owner，补契约/组件测试 |
| 纸杯蛋糕 Cupcake | ≣ | 同一功能在多层被手工重复测 | 层间职责未定义，靠"多测一遍"求安心 | 定义各层职责边界（§五 表），删除冗余 |
| 死亡金字塔 | △（但全是手工） | 形状对、但"单元"是人工点检 | 无自动化能力，只有手工脚本 | 从 CI 门禁切入做自动化（见 [[SSD自动化测试体系]] 的 L2→L4 路径） |
| 比例 KPI | — | "自动化率必须 80%""单测占比必须 70%" | 把结构当目标（古德哈特定律） | 指标换成 CI 反馈时长 + flaky 率 + 逃逸率（见 [[测试度量与质量成本]] §五） |
五、分层策略怎么落地
5.1 各层职责边界（避免重复与空白）
| 层 | 应该测 | 不应该测（交给别层） |
|---|---|---|
| 单元 | 逻辑分支、边界、异常路径、算法正确性 | 真实依赖行为、端到端装配、UI 呈现 |
| 服务/接口 | 接口契约、参数校验、错误码、幂等、数据读写、事务边界 | UI 交互细节、跨系统流程 |
| UI/E2E | 关键业务流（冒烟级）、跨系统装配、真实环境差异、用户可见行为 | 大量分支组合（用下层覆盖）、纯展示逻辑 |
5.2 一条用例该放哪层？四个判据
① 是否必须跨进程/跨系统才能验证？ 是 → 往上层放
② 真实依赖是否必要（还是可 mock）？ 可 mock → 往下层放
③ 失败时定位是否唯一？ 否 → 往下层拆
④ 该逻辑的变更频率高吗？ 高 → 往下层放（上层的维护成本 × 变更频率 = 痛点）
5.3 分层执行策略（与 CI 回路绑定）
| 触发时机 | 执行范围 | 目标时长 | 失败处理 |
|---|---|---|---|
| 每次 commit | 单元 + 静态检查 + lint | < 2~5 分钟 | 直接阻断合并 |
| 每个 MR/PR | 单元 + 服务/接口 + 关键契约 | < 15~30 分钟 | 阻断合并 |
| 合并到主干 | 全量 + 集成 + 冒烟 E2E | < 1~2 小时 | 阻断发布 |
| 夜间/发布前 | 全量 E2E + 性能 + 长稳 + 兼容矩阵 | 小时~天 | 择要阻断，其余记录 |
这张表就是 [[测试度量与质量成本]] §五"CI 反馈时长"指标的落地形态；本库已有同构实现见 [[SSD自动化测试体系]]（L4 Jenkins 6 层 Gate）。
5.4 自动化 ROI 的判断
自动化收益 ≈ 手工单次耗时 × 执行次数 − 编写成本 − 维护成本 × 变更次数
- 适用：高频回归、长耗时步骤、需要精确重复的场景（长稳、数据校验）
- 不适用：一次性验证、探索式测试、UI 频繁大改期、判定需人工审美的场景
- ⚠️ 公式为本库归纳的启发式（推断），各部门成本口径需自行校准
六、本库对接
| 场景 | 分层形态 | 本库锚点 |
|---|---|---|
| SSD 测试 | 固件单测不可见 → 以"接口/协议层 + 硬件在环 + 长稳"为主，形状更接近蜂巢 | [[SSD测试方法与体系]] |
| SSD 自动化体系 | 已有 L2（Python+FIO+Quarch 自建）→ L3（eBird/Quarch/SanBlaze 程控）→ L4（Jenkins 6 层 Gate）的自下而上分层，是本页最佳实例 | [[SSD自动化测试体系]] |
| 网络测试 | 协议一致性（服务/接口层）权重高，端到端场景少而关键 | [[网络测试专家面试准备]] |
| AI 芯片验证 | 模块级（单元）→ 子系统 → 全芯片/系统级，层级划分与软件同源 | [[AI芯片验证岗位面试准备]] |
| LLM 应用 | 传统金字塔变形：评测集 + 门禁取代大量单测 | [[大模型评测技术]]、[[Langfuse速通手册]] |
口径提示
- 本页为通用方法论整理（
sources: []）。分层比例数字（70/20/10 等）无权威出处，属对 Cohn 示意图的口语化转述，本页不推荐具体比例 - 成本倍数（"1 个 E2E ≈ 10 个单测"、"50 倍维护成本"）为流传广泛但无可靠出处的经验值——⚠️ 仅可作数量级直觉，不可作为预算或排期依据
- Testing Trophy 的归属（Kent C. Dodds）与 Honeycomb 的归属（Spotify）中，Trophy 较为确定，Honeycomb 的原始出处本库未核实（多方转述不一），引用时宜标"据业界转述"
- §5.4 的 ROI 公式与 §5.2 的四个判据是本库归纳的启发式（推断），非标准方法
- 各层"单次耗时量级"为经验量级，强依赖技术栈（Go 单测与 Python UI 测试差 2~3 个数量级）
