回归测试（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 个月未失败的用例已审视
□ 自动化优先级合理

常见坑

1. Bug 修了不加回归用例——同 Bug 反复出现
2. 回归不分层——每次都跑 3 小时，CI 卡死
3. 不做影响分析——全跑或随机选
4. Flaky 用例靠重试——掩盖真问题
5. 半年没维护——套件臃肿，新用例淹没
6. 手工回归依赖人——不可持续，遗漏率高
7. 重构不跑 Full——以为"行为不变"，实际改坏
8. 回归套件失败率 >> 真 Bug 率——用例本身的问题
9. 删用例不评审——重要用例被误删
10. Smoke 跑得太重——CI 体验差，不愿跑

配套模板

• templates/regression-suite-template.md — 三层套件 + 影响分析 + 历史 Bug 跟踪 + 套件健康自检

与其他 skill 的协作

上游：
  test-case-design → 提供用例
  bug-reporting → 历史 Bug
  risk-based-testing → 高风险点入回归

下游：
  自动化测试工作流 → 实现自动化套件
  quality-gate → 回归通过率作为门禁
  test-report → 回归结果纳入报告