从“70/20/10”回到成本本身
在自动化测试讨论中，测试金字塔经常被简化为一组比例：单元测试多一些、接口测试少一些、端到端测试更少一些。但掘金这篇关于测试金字塔与自动化分层的文章提醒团队，金字塔真正表达的不是用例数量指标，而是成本结构：越往上，执行越慢、成本越高、稳定性越差、维护负担越重。
文章将测试金字塔追溯到 Mike Cohn 2009 年出版的《Succeeding with Agile》。其经典结构是：底层为单元测试，中间为服务或接口层测试，上层为 UI 与端到端测试。三层分别承担不同目标，而不是简单凑出一个比例。
- 单元测试：验证函数、类、模块的行为与边界，单次耗时通常在毫秒级，稳定性高，失败定位可以精确到函数或分支。
- 服务或接口测试：验证模块间协作、API 契约、数据库交互等，耗时多在百毫秒到秒级，失败定位通常可以落到接口或组件。
- UI / E2E 测试：验证端到端业务流程和跨系统链路，耗时从秒到分钟不等，稳定性较低，失败常常需要人工判读。
文章特别指出，网上常见的“单测 70% / 集成 20% / E2E 10%”或“60/30/10”并没有权威出处，更多是对金字塔图形的口语化转述。因此，合理比例应由被测系统自身形态决定，而不是套用固定模板。
四个维度比较金字塔、奖杯与蜂巢
围绕不同团队常用的金字塔、奖杯、蜂巢等模型，文章给出的判断是：这些模型差异主要来自适用语境，而不是简单的对错。要判断一个自动化用例应该放在哪一层，需要拆开看四个维度：编写成本、执行成本、维护成本，以及失败信息的信噪比。
其中，最容易被低估的是 E2E 测试的维护成本。文章提到，E2E 的维护并不是“编写成本的两倍”这样一次性增加，而是会随着 UI 变化、环境变化、依赖变化被反复触发。业界常见“1 个 E2E 约等于 10 个单测的编写成本、50 倍维护成本”这类说法，文章将其标注为经验值，认为数量级直觉可以参考，但具体数字不应作为权威引用。
由此，文章给出一个核心结论：测试金字塔不是审美偏好，而是在给定覆盖率目标下，让总成本尽量小的结构。当团队要求“全都写 E2E”，实际上等同于要求用最贵的工具反复验证同一件事。
为了帮助工程师做分层决策，文章提出了几个可操作的问题：
- 是否必须跨进程、跨系统才能验证？如果是，用例应往上层放。
- 真实依赖是否必要，还是可以用 mock 替代？如果可以替代，用例应往下层放。
- 失败时定位是否唯一？如果失败信息难以定位，应往下层拆分。
- 该逻辑变更频率是否足够高？如果高频变更，应优先放到低层，避免上层维护成本被变更频率放大。
把分层落到 CI：不同阶段跑不同测试
文章没有停留在模型比较，而是进一步把自动化分层接入 CI 流程，给出了一套按触发时机划分执行范围的策略。
- 每次 commit：执行单元测试、静态检查和 lint，目标时长控制在 2 到 5 分钟内，失败直接阻断合并。
- 每个 MR 或 PR：执行单元测试、服务或接口测试以及关键契约测试，目标时长控制在 15 到 30 分钟内，失败阻断合并。
- 合并到主干：执行全量测试、集成测试和冒烟 E2E，目标时长约 1 到 2 小时，失败阻断发布。
- 夜间或发布前：执行全量 E2E、性能、长稳和兼容矩阵测试，耗时可能从数小时到数天，部分结果择要阻断，其余记录追踪。
这套表格的意义在于，它把抽象的“测试分层”转化为工程团队可以执行的反馈机制。单元测试保证快速反馈，接口测试承接模块协作与契约风险，E2E 测试则放在更靠后的发布关口，用于捕捉装配错误、流程断裂和真实环境差异。
对 AI 编程工具链和智能开发平台同样如此。随着代码生成、自动补全和 Agent 编程工具进入研发流程，自动化测试的价值不再只是“发现 bug”，而是成为衡量 AI 产出质量、控制变更风险和维持反馈速度的基础设施。
从工程角度看，测试金字塔给出的并不是一个固定比例，而是一组成本约束下的排序原则：能在低层验证的问题，不要拖到高层；必须在上层暴露的问题，也不要寄希望于低层完全覆盖。真正的自动化测试策略，应该围绕系统形态、变更频率和反馈时长来设计，而不是围绕一个被误读的数字比例。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ce-shi-jin-zi-ta-bu-shi-shu-liang-kpi-er-shi-yi-dao-gong
