测试分层占比怎么看
测试分层占比描述单元测试、集成测试与端到端测试各占多少，直接影响反馈速度与稳定性：单元测试跑得快、失败定位准，应当占主体；集成测试覆盖模块协作，数量居中；端到端测试慢且易受环境影响，只覆盖关键业务路径。倒置形态俗称冰淇淋筒，大量端到端加手工回归，表现为测试时长不断上升、随机失败增多。
健康形态与反形态
| 健康形态 | 单元测试多、集成测试居中、端到端少而关键 |
|---|---|
| 反形态 | 大量端到端测试，回归依赖手工执行 |
| 典型信号 | 测试时长上升、随机失败变多、修复一次要重跑很久 |
| 关注点 | 占比随系统类型调整，重要的是趋势一致 |
典型使用场景
- 流水线变慢排查：统计分层占比，看是否端到端数量失控导致单次运行时间超标
- 随机失败治理：随机失败集中在端到端层，说明该把校验下沉到单元与集成层
- 新模块设计：动手写测试前先明确各层职责边界，避免把业务分支都放到端到端验证
- 遗留系统改造：把端到端里的业务规则校验逐步提取为单元测试，缩短反馈回路
- 测试投资分配：按层看单位时间的缺陷发现量，决定新增投入投向哪一层
占比观察参考
占比观察参考
# 以下比例仅作趋势参考，不作为硬性门禁
单元测试 70% 以上 秒级反馈主体
集成测试 20% 上下 接口与模块协作
端到端测试 10% 以内 关键业务路径
# 判断重点是趋势：端到端占比是否在持续上升各层职责与边界
| 层次 | 验证什么 | 不该做的事 |
|---|---|---|
| 单元测试 | 单个类或函数的逻辑与分支 | 不应启动数据库与网络 |
| 集成测试 | 模块间协议、持久化与外部依赖契约 | 不应覆盖全部业务分支组合 |
| 端到端测试 | 关键路径整体可用性与部署正确性 | 不应充当业务规则的唯一验证手段 |
| 契约测试 | 接口双方的数据结构与兼容性 | 不应重复验证业务逻辑 |
没有通用正确比例：一个数据处理服务与一个前端应用的合理分层差别很大。可行做法是先记录当前占比作为基线，再观察每次调整后反馈速度与随机失败率是否改善。
只删端到端不补下层覆盖，会留下真实缺口。下沉时按场景逐条迁移：先在单元层复现同一规则，确认能拦住错误，再删除对应的端到端用例。
落地检查清单
- 每层测试的职责边界写进团队约定，评审时按此判断该放哪一层
- 流水线报表按层统计数量与耗时，作为趋势输入
- 随机失败按层归类，优先治理端到端层的环境依赖
- 下沉覆盖时保持一条迁移记录，避免直接删除造成缺口