zhaoxuya520 回归测试（Regression Testing）
参考来源：ISTQB Foundation、Google《Software Engineering at Google》Test Selection、Microsoft Test Impact Analysis。
适用场景
- 版本发布前回归
- Bug 修复后验证不引入新问题
- 重构 / 架构调整后行为不变验证
- 依赖升级（库 / 框架 / 数据库版本）
- 配置变更（环境 / 网关 / 缓存）
核心原则
1. 不重复发生的 Bug 才是好回归
每个修复的 Bug 必须有回归用例
2. 回归不是全跑
要做影响分析，按变更范围选择套件
3. 三层套件结构
Smoke / Sanity / Full（详见下文）
4. 套件要剪枝
失败率 < 5% 才稳定
半年没失败的可能要删（或归档）
5. 自动化是回归的归宿
手工回归不可持续
三层套件结构
┌─────────────────────────────────────┐
│ Smoke（5 分钟） │
│ - CI 每次必跑 │
│ - 核心路径"能用"验证 │
│ - 失败 = 阻塞合并 │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Sanity（30 分钟） │
│ - 发布前 / 每日定时跑 │
│ - 主要功能正确性验证 │
│ - 失败 = 阻塞发布 │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Full（1~3 小时） │
│ - 重大版本 / 重构后跑 │
│ - 全量回归 │
│ - 失败 = 评估影响后决策 │
└─────────────────────────────────────┘
影响分析（Impact Analysis）
1. 变更内容是什么？
- 新增功能
- 修改逻辑
- 修复 Bug
- 重构（行为应不变）
- 依赖升级
2. 变更影响哪些代码？
- 直接修改的模块
- 调用方（谁用了它）
- 被调用方（它用了谁）
- 共享代码（utils、middleware）
3. 变更影响哪些功能？
- 直接相关的用户流程
- 间接相关（共享数据 / 状态 / 配置）
4. 选择回归套件
- Smoke：必跑
- Sanity：相关模块
- Full：跨模块大改 / 重构
影响层级表
| 变更类型 | 推荐回归 |
|---|---|
| Bug 修复（单点） | Smoke + 该 Bug 历史用例 |
| 功能修改（单模块） | Smoke + Sanity（该模块） |
| 跨模块功能 | Smoke + Sanity（涉及模块） |
| 共享代码变更（utils） | Smoke + Sanity（所有模块） |
| 重构（行为不变） | Full |
| 数据库迁移 | Full + 数据完整性专项 |
| 依赖升级（major） | Full |
| 配置变更 | 受影响场景 + Smoke |
Bug → 回归用例的转化
Bug 修复后必做：
1. 写一条复现用例（最小复现路径）
2. 写一条边界用例（防类似变体）
3. 加入 Sanity 套件
4. 标注：源自 Bug-XXX
5. 6 个月内不删除
示例：
Bug-789：退款金额可输入负数
→ 回归用例 1：输入 -100，预期返回 INVALID_AMOUNT，金额无变化
→ 回归用例 2：输入 0，预期返回 INVALID_AMOUNT
→ 回归用例 3：输入超过订单金额的正数，预期返回 EXCEED_LIMIT
→ 回归用例 4：边界：等于订单金额（应该成功）
套件维护（剪枝）
| 时机 | 动作 |
|---|---|
| 失败率 > 5% | 修复或隔离 Flaky 用例 |
| 6 个月未失败 | 审视，可能要删 |
| 模块下线 | 删除相关用例 |
| 业务变更 | 同步更新 |
| 用例执行 > 5 分钟 | 拆分或优化 |
工作流程
1. 收集变更说明
- 修改了什么 / 为什么 / 影响范围
↓
2. 影响分析
- 用变更范围决定回归层级
↓
3. 选择套件
- Smoke / Sanity / Full
↓
4. 添加新用例（如有 Bug 修复）
- 历史 Bug 转回归用例
↓
5. 执行（优先自动化）
- 失败 → bug-reporting
↓
6. 失败分析
- 真 Bug：开发修
- Flaky：隔离 / 修复
- 测试代码问题：修测试
↓
7. 报告
- 通过率 / 失败用例 / 是否阻塞
↓
8. 套件维护
- 加新用例 / 删旧用例 / 修 Flaky
自动化策略
高优先（必自动化）：
- Smoke 套件 100%
- Sanity 套件 80%+
- 历史 Bug 回归用例
中优先（可自动化）：
- Full 套件中稳定部分
- API 契约测试
低优先（保留手工）：
- UI 视觉回归
- 兼容性（多浏览器 / 设备）
- 探索式
Flaky 用例处理
症状：用例时通过时失败，无规律
排查顺序：
1. 时序：异步等待不够
2. 数据：上一个用例污染
3. 状态：缓存 / 会话残留
4. 环境：网络 / 第三方抖动
5. 并发：多线程 / 多用户冲突
6. 时间：依赖具体日期 / 时区
处理：
- 立即隔离（标 @flaky 跳过 CI）
- 1 周内修复或删除
- 不要"多重试几次让它过"
质量自检
□ 三层套件清晰（Smoke/Sanity/Full）
□ Smoke < 5 min，Sanity < 30 min
□ 历史 Bug 100% 转回归用例
□ 失败率 < 5%
□ Flaky 用例已隔离或修复
□ 影响分析驱动套件选择
□ 重构后跑 Full
□ 6 个月未失败的用例已审视
□ 自动化优先级合理
常见坑
- Bug 修了不加回归用例——同 Bug 反复出现
- 回归不分层——每次都跑 3 小时，CI 卡死
- 不做影响分析——全跑或随机选
- Flaky 用例靠重试——掩盖真问题
- 半年没维护——套件臃肿，新用例淹没
- 手工回归依赖人——不可持续，遗漏率高
- 重构不跑 Full——以为"行为不变"，实际改坏
- 回归套件失败率 >> 真 Bug 率——用例本身的问题
- 删用例不评审——重要用例被误删
- Smoke 跑得太重——CI 体验差，不愿跑
配套模板
templates/regression-suite-template.md— 三层套件 + 影响分析 + 历史 Bug 跟踪 + 套件健康自检
与其他 skill 的协作
上游：
test-case-design → 提供用例
bug-reporting → 历史 Bug
risk-based-testing → 高风险点入回归
下游：
自动化测试工作流 → 实现自动化套件
quality-gate → 回归通过率作为门禁
test-report → 回归结果纳入报告