Qa Regression Testing

SKILL.md

---
name: qa-regression-testing
version: 1.6.0
description: >-
  根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策：冒烟回归（P0核心流程）、核心回归（高影响区域）、全量回归（有余力时）。基于变更分析和风险评估选择最省时的回归策略，而不是盲目全量回归。

when_to_use: 用户说"回归测试"、"回归策略"、"回归范围"、"回归用例"、"冒烟测试"、"全量回归"、"回归不够时间"、"哪些要回归"、版本迭代需要确定回归范围时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-code-review-for-test      # 可选输入：变更影响范围（无CR结果时基于变更描述直接分析）
    - qa-risk-intuition            # 输入：风险等级判断
    - qa-test-case-design          # 输入：测试用例库
  downstream:
    - qa-ci-cd-testing             # 输出：回归策略配置到CI/CD
    - qa-test-strategy-design      # 输出：回归策略纳入整体测试策略
input_format:
  required:
    - name: 变更范围
      type: string
      description: 本次变更的功能和代码范围
    - name: 历史用例集
      type: array
      description: 全部历史测试用例
  optional:
    - name: 风险评估
      type: object
      description: 变更风险评估
    - name: 时间约束
      type: string
      description: 回归测试时间限制
output_format:
  traceability:
    - 回归用例沿用原始ID（TC-XXXX）
    - - 标注回归级别（冒烟/核心/全量）
  structure:
    - regression_plan: 回归测试方案
    - selected_cases: 选取用例清单
    - risk_based_priority: 基于风险的优先级
    - execution_strategy: 执行策略
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
  reference_value: "根据变更范围调整回归深度：简单×1/中等×2/复杂×3"
  minimum: "至少完成冒烟回归、核心回归、选择全量回归3级策略"
error_recovery_guidance:
  on_failure: "回归范围遗漏高风险区域时回退到风险评估补充"
  retry_behavior: "补充风险评估后重新选取回归用例"
---
> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞策略和回归用例分级。
> 实际使用时请勿直接阻塞发布，先与项目经理和开发确认风险等级和发布窗口。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 回归测试策略

> **无代码评审时的替代方案**：如果 `qa-code-review-for-test` 的输出不可用（代码评审不在本次工作流路径中），可直接根据用户提供的变更描述、版本 diff 或功能变更列表来确定变更影响范围和回归重点。上游依赖为可选，不阻塞工作流执行。

## 核心原则

回归不是全量重测，而是「判断哪些不用测」比「决定哪些要测」更重要。

## 回归金字塔

### 第1层：冒烟回归（P0 — 提交级）

```text
定位：每次提交/部署必须通过的快速验证
执行频率：每次提交/构建
执行方式：自动化（CI/CD触发）
执行时间：< 15分钟
覆盖率：核心流程 100%

典型用例：
├─ 关键登录态验证
├─ 主页/核心页面可访问
├─ 核心API健康检查
├─ 数据库连接正常

用例特征：
├─ 数量少（< 50条）
├─ 执行快（秒级）
├─ 结果明确（通过/不通过）
└─ 失败即阻塞发布
```

### 第2层：核心回归（P0 + P1 — 日级）

```text
定位：每日/每个迭代版本的关键功能验证
执行频率：每日/每次提测
执行方式：自动化为主 + 人工抽测
执行时间：< 2小时
覆盖率：核心功能 100% + 关联功能 80%

典型用例：
├─ 所有P0用例
├─ 关联功能的核心场景
├─ 历史缺陷的复测用例
├─ 变更影响区域的主路径

用例特征：
├─ 中等数量（100-500条）
├─ 覆盖核心链路
├─ 可自动化率 > 80%
└─ 失败需人工确认
```

### 第3层：全量回归（P0-P3 — 发版级）

```text
定位：大版本发布前的全面验证
执行频率：每个大版本
执行方式：自动 + 人工结合
执行时间：1-5天
覆盖率：全功能覆盖 90%+

典型用例：
├─ 全量P0-P2用例
├─ 所有功能点的边界场景
├─ 兼容性覆盖组合
├─ 全链路性能验证

用例特征：
├─ 数量大（500+条）
├─ 覆盖全面
├─ 部分需人工执行（探索式）
└─ 结果用于发版决策
```

## 回归用例筛选策略

### 策略1：基于变更的筛选（Change-Based）

```text
适用场景：小迭代 / Bugfix版本
核心逻辑：代码变更 = 需要回归的区域

执行步骤：
1. 获取代码变更列表（Diff / Commit）
2. 确定变更影响的模块和接口
3. 从用例库中提取覆盖这些模块的用例
4. 增加模块间调用链上的关联用例
5. 增加历史缺陷中同类变更的相关用例

适用条件：
├─ 有代码评审结果（qa-code-review-for-test）
├─ 用例与代码有映射关系
└─ 变更边界清晰

优点：精准、用例量少
缺点：依赖代码映射、可能遗漏间接影响
```

### 策略2：基于风险的筛选（Risk-Based）

```text
适用场景：大版本 / 重构 / 新功能上线
核心逻辑：高风险区域 = 必须回归

执行步骤：
1. 引用风险评估结果（qa-risk-intuition）
2. 高风险区域 → 全量回归（P0-P2全覆盖）
3. 中风险区域 → 核心回归（P0-P1）
4. 低风险区域 → 冒烟回归（P0）
5. 历史缺陷高发模块 → 增加额外覆盖

适用条件：
├─ 有风险评估报告
├─ 用例库有优先级标注
└─ 回归时间有限

优点：时间弹性大、可裁剪
缺点：依赖风险判断的准确性
```

### 策略3：基于时间的筛选（Time-Boxed）

```text
适用场景：回归时间严重不足 / 紧急发布
核心逻辑：时间限制 = 用例上限，按价值排序

执行步骤：
1. 计算可用回归时间
2. 按优先级倒序裁减：
   ├─ 先保冒烟（P0，必须过）
   ├─ 再保核心（P0+P1，尽量过）
   └─ 最后全量（P0-P2，能过多少算多少）
3. 标记未覆盖的风险区域
4. 输出回归风险报告

优点：总能给出可执行的方案
缺点：覆盖率随裁剪下降，需显式暴露风险
```

### 策略比较速查

| 策略 | 适用场景 | 用例量 | 依赖 | 风险暴露 |
|------|---------|-------|------|---------|
| 变更驱动 | 小迭代/Bugfix | 少 | 代码映射 | 低 |
| 风险驱动 | 大版本/重构 | 中 | 风险评估 | 中 |
| 时间驱动 | 紧急发布 | 灵活 | 时间预估 | 高（显式暴露） |

## 增量 vs 全量 决策

| 决策维度 | 全量回归 | 增量回归 | 差分回归 |
|---------|---------|---------|---------|
| 执行范围 | 全部用例 | 变更相关 + 关联 | 变更前 vs 变更后 差异点 |
| 执行时间 | 1-5天 | 2-4小时 | 30-60分钟 |
| 覆盖风险 | 最低 | 中 | 高（漏测风险最高） |
| 适用 | 大版本发版 | 小迭代发版 | Bugfix验证 |
| 自动化要求 | 高 | 中 | 中 |

```text
决策流程：
变更范围是否跨模块？
├─ 是 → 全量回归
└─ 否 → 变更是否涉及核心逻辑？
    ├─ 是 → 核心回归 + 增量
    └─ 否 → 增量回归 + 差分

时间是否充足？
├─ 是 → 全量回归
└─ 否 → 时间驱动裁剪
```

## 回归用例维护

### 新增场景
- 每次发布新增的用例 → 标记回归标签
- 线上Bug修复后 → 增加复测用例并入回归库
- 新功能上线 → 核心用例加入核心回归集

### 淘汰场景
```text
检查频率：每季度
淘汰标准：
├─ 功能已下线 → 移除
├─ 连续6次回归无失败 → 降级到低频执行
├─ 被更优用例覆盖 → 合并/替换
├─ 执行时间过长且非核心 → 移到手动回归

保留标准：
├─ 每个P0用例至少1个回归用例
├─ 每个历史Bug至少1个复测用例
├─ 每个核心模块至少3个回归用例
```

### 效率度量
- 回归用例通过率：> 98%
- 回归执行时长：稳定或下降
- 漏测率：每轮新发现的回归遗漏数
- 回归覆盖代码变更率：变更代码中被回归覆盖的比例

## 输出示例

**用户说"这个版本要回归测试"**
→ 确定变更范围（code-review → 影响模块）
→ 引用风险评估（risk-intuition → 高/中/低）
→ 决策：小迭代 → 增量回归（P0 + 变更覆盖）
→ 输出回归方案：回归范围 + 用例清单 + 时间预估

**用户说"回归时间不够，只能测4小时"**
→ 时间驱动策略：
  1. 冒烟回归（P0）：30分钟
  2. 核心回归（变更区域P0-P1）：2.5小时
  3. 剩余时间：补充高风险区域
→ 输出回归风险报告：标注未覆盖的风险区域

**用户说"加个字段，影响范围很小"**
→ 变更驱动策略：
  1. 代码Diff分析：涉及1个字段、1个页面
  2. 提取该页面的P0-P1用例
  3. 增加字段输入校验的边界测试
→ 输出：增量回归清单（15条用例，耗时30分钟）

## 检查清单

回归策略制定后检查：
- [ ] 是否按金字塔分层（冒烟/核心/全量）？
- [ ] 筛选策略是否匹配变更特征？
- [ ] 时间约束是否显式考虑？
- [ ] 未覆盖的风险区域是否已暴露？
- [ ] 回归用例库是否持续维护？
- [ ] 回归效率是否有量化指标？
- [ ] 每个历史Bug是否有复测用例？