冰淇淋甜筒反模式是什么
冰淇淋甜筒是与测试金字塔相反的用例分布：大量缓慢的端到端测试压在顶层，单元与集成测试投入不足。Google Testing Blog 的观察是：随着代码库扩大，E2E 用例数量增长会让套件耗时线性上升，而单元测试增长相对可控。甜筒分布的结果是反馈慢、失败定位难、维护成本高——跑一遍全量要几十分钟，失败原因却常指向测试脚本本身。
基本信息
| 识别信号 | 全量回归几十分钟以上、失败常指向脚本本身 |
|---|---|
| 常见成因 | 历史上每次发布都新增 E2E，缺少单元与契约层投入 |
| 代价 | 反馈周期长、定位难、用例维护成本高 |
| 改进路径 | 梳理高频失败点，下沉为单元或 API 层用例 |
| 收口原则 | E2E 只保留关键业务路径，覆盖转移到下层 |
典型使用场景
- 存量诊断：统计各层用例数量、耗时与失败率，画出真实分布。
- 改进立项：用耗时数据论证下沉重构的收益。
- E2E 瘦身：把可从接口层验证的步骤从 E2E 中拆出。
- 新用例定位：评审时判断这条检查应该放金字塔哪一层。
- CI 提速：把慢用例下沉后，合并前的反馈时间显著缩短。
- 稳定性治理：高频失败的 E2E 优先改造而不是关闭。
改进动作示意
改进动作示意
1. 盘点：各层用例数 / 执行耗时 / 失败率
2. 下沉：E2E 中的参数校验改到单元与接口层
3. 收口：E2E 只留关键业务路径（下单、支付、登录）
4. 度量：反馈时长与 flaky 率作为改进验收指标把稳定性差的 E2E 全部删除不是解法：应先补齐下层覆盖，再精简 E2E，避免覆盖出现真空。
分布要看三个数字：数量、耗时、失败率——只看数量会低估甜筒分布的真实代价。
下沉检查项时同步补断言维度：从界面断言改为接口断言，覆盖的字段与状态要重新设计，防止覆盖真空。