回归范围怎么定
回归用例选取解决「改了一处要复验多少」：按变更影响面（模块、接口、公共库、配置）圈定必测集，再补历史高发区域与核心链路。回归集不是越大越好——冗余用例拉长执行时间、稀释注意力；也不是越小越好——漏选直接把缺陷放到门外。
基本信息
| 影响面映射 | 代码模块与用例目录的对应表，选取的核心依据 |
|---|---|
| 分层 | 核心冒烟必跑、模块级按需、全量发版前 |
| 历史权重 | 曾出缺陷的区域加权，优先复验 |
| 时效管理 | 长期稳定且低价值的用例定期评审下线 |
| 公共变更 | 工具库、序列化、鉴权升级：影响面接近全量 |
| 度量 | 回归拦截率、执行时长、漏检事故数 |
变更类型与选取策略
| 变更类型 | 选取策略 | 理由 |
|---|---|---|
| 单模块需求 | 该模块加依赖方 | 影响面清晰、成本可控 |
| 公共库升级 | 全量或高比例抽样 | 影响面横跨所有模块 |
| 配置与环境变更 | 冒烟加兼容性检查 | 先确认基本盘不受影响 |
| 数据模型变更 | 全接口基本流 | 结构变化影响所有读写 |
典型使用场景
- 版本发布前：按变更清单圈定回归范围
- 重构分支：接口未变实现全改，按契约回归
- 公共组件升级：评估影响面决定全量与否
- 回归瘦身：把四小时的全量压到四十分钟
- 事故之后：把漏检点补成回归用例
用最近一次漏检事故校准回归集：每起漏检都应该变成一条回归用例或一条映射规则。
冒烟集与回归集分开维护：冒烟必须快（分钟级），回归可以长，两者职责不同不要混。
删除用例要有记录：写明删除理由与时间，出问题时才能判断是「没测」还是「测过被删」。