---
name: regression-testing
slug: regression-testing
displayName: 回归测试
version: 0.6.0
description: 代码变更（diff/Bug 修复/需求变更）后判断应回归哪些测试时使用——沿"改动文件 → 改动函数 → 受影响功能 → 受影响用例"分析链，基于用例 Schema 的追溯映射产出分级回归清单。不用于：用例文件本身的增量修改（test-case-writing）、长期回归策略（test-strategy）。
---
# 回归测试（regression-testing）
代码变更 → 自动判断应该回归哪些测试。
- **输入**：Code Diff（`git diff ...`）、Bug 修复说明、需求变更说明、已有用例（markmap + `测试用例.schema.yaml`）、（可选）需求模型
- **输出（落盘）**：`{项目}/回归清单_{日期}.md`——必须回归（P0）/ 建议回归（P1）/ 可选回归（P2）三级，逐条给依据
- **前置依赖**：持久的"用例 ↔ 代码 ↔ 功能"追溯映射，v0 三层全部来自落盘产物，不依赖会话记忆：
1. **代码级锚点**：用例附录「代码证据清单（TC ↔ 文件:行）」，由 Schema 的 `code_refs` 结构化
2. **功能层**：需求模型 + Schema 的 `module` / `risk_ref`
3. **per-run 增量**：改动文件映射附录（针对本次 diff 生成）
> 没有这个数据结构，影响面分析就只是"让模型读一遍 diff 猜"。**启动前三档资产盘点**（决定走哪条路，防止零资产硬编清单）：
> - **全套齐**（markmap + Schema 追溯映射都在）：走工作流完整分析链
> - **只有 markmap 无 Schema**：先由 `test-case-writing` 对存量 markmap 抽取补建（不需要人工重写），再进工作流
> - **零用例资产**：不凭 diff 编造清单——向用户给降级选项：P0 冒烟建议（逐条标「无追溯依据，覆盖不保真」），或先由 `test-case-writing` 补建最小用例集再回来跑本流程
## When to Use
- 代码变更（feature/Bug 修复/重构）合入后，需要选择回归范围
- Bug 修复后需要确定"修复验证 + 关联回归"的用例集
- 需要一份逐条给依据、可裁剪的分级回归清单
## When NOT to Use
- 用例文件的增量修改本身（标记/新增/废弃用例）→ `test-case-writing` 增量更新流程
- 长期回归策略（锚点用例、回归节奏）→ `test-strategy` 的 regression_plan
- 判断某次失败是不是 Bug → `bug-analysis` / `automated-e2e-testing` 工作流二
- 端到端流水线 → `qa` 编排
## 分析链
```text
Changed Files（git diff）
↓
Changed Functions（diff 中被修改的函数/类/组件）
↓
Affected Features（函数 → 所属功能：经 Schema code_refs / module / 需求模型映射）
↓
Affected Test Cases（功能 → 用例：risk_ref / module / 附录改动文件映射）
↓
Regression Scope（三级回归清单 + 依据）
```
## 工作流
### 1. 盘点变更
```bash
git diff ... --stat # 改动文件清单
git diff ... -U3 # 逐文件读改动内容，定位改动函数
```
变更类型分类（基础四类，与 `test-case-writing` 阶段一「改动盘点」的枚举一致）：🆕 新建 / ✏️ 修改（可按需细分标注：行为修改、🐛 Bug 修复（关联 Bug 单）、🔧 重构（行为应不变））/ 🗑️ 删除 / 💀 死代码。类型不同，回归侧重不同（重构 → 全量行为锚点；Bug 修复 → 修复验证 + 该 Bug 历史关联用例；死代码 → 不产生回归用例）。
### 2. 影响面分析（沿分析链逐层映射）
- **代码层**：Schema 中 `code_refs` 命中改动文件（或同文件邻近行）的用例 → 直接受影响。`code_refs` 是**用例编写时的快照而非实时索引**——命中处与本次 diff 内容明显对不上（函数已消失 / 行号整体偏移出邻近带 / 文件已改名）即判锚点陈旧，**整批降级为参考信号**改走功能层 / 风险层映射，并在清单头部注明口径
- **功能层**：改动函数所属功能（module / 需求模型）下的全部用例 → 间接受影响；共享工具/公共组件改动 → **消费方全查**（grep 引用方，逐个判断）
- **风险层**：Risk Map 中挂在受影响功能上的风险（`risk_ref` 反查）→ 其锚点用例（Critical 风险必进"必须回归"）
- **历史层**（有 Bug 单时）：该 Bug 涉及功能的历史回归用例
> 分析过程对每个映射给依据（"TC-03-02 code_refs 命中 `coupon_service.py:124`"），**映射不上的不硬编**——列入"影响不明，建议人工判断"。
### 3. 生成分级回归清单
```markdown
# 回归清单 — {日期}
- 变更基线：{base}...{head}（{commit 数} commits，{文件数} 文件）
- 变更类型：{新增/修改/修复/重构/删除}
- 关联 Bug：{Bug 编号列表，非修复类变更省略此行；有则与对应 Bug 条目的回归建议双向互链}
## 必须回归（P0）
| 用例 | 依据 |
|------|------|
| TC-01-01（SMOKE-1） | 改动文件 code_refs 直连 + Critical 风险 R1 锚点 |
## 建议回归（P1）
| 用例 | 依据 |
|------|------|
| TC-02-03 | 同功能模块间接受影响（module=发放流程） |
## 可选回归（P2）
| 用例 | 依据 |
|------|------|
| TC-06-02 | 公共组件改动，消费关系间接 |
## 影响不明（建议人工判断）
- {文件/功能}：{为什么映射不上}
## 无影响确认（显式排除）
- {模块}：{排除依据，如"改动仅涉日志文案，无行为变更"}
```
> 与 `test-strategy` 的 regression_plan 对齐：锚点用例（Critical 风险 P0）默认进"必须回归"；执行方式按 automation_plan（e2e / api / 手动）标注。
### 4. 交付与执行衔接
- 清单落盘后交执行：自动化部分 → `automated-e2e-testing` / `api-testing`；手动部分 → 测试工程师
- 回归结果汇总进测试报告（`../core/report-template.md` §5 回归摘要）
- **多失败先分流**：一轮回归失败 ≥3 条时，先按 `../core/triage.md` 四分类预归类——C 环境 / D 不稳定剔出本轮 Bug 同步口径（C 修复后受影响批次强制原样重跑），B 资产问题单列待办，剩余 A 类才进入下行状态同步
- **回归结果同步 Bug 状态**：修复验证对应的 Bug 条目按结果更新——通过 → 已验证关闭；失败 → 已修复待验证（附失败证据；条目已处于该状态则**复验轮次 +1**，达 3 向用户提示升级裁决——换修复方向 / 转不予修复评审），字段口径见 `../core/report-template.md` §3（使用约定 6）
## Common Mistakes
| 错误 | 后果 | 正确做法 |
|------|------|---------|
| 只按改动文件名匹配用例 | 同名不同层、公共组件消费方漏检 | 沿分析链走到底，公共组件 grep 引用方 |
| 无 Schema 时靠"读 diff 猜" | 影响面分析退化为猜 | 先对存量 markmap 抽取 Schema（`test-case-writing`） |
| 清单不给依据 | 不可复核，无法裁剪 | 每条用例给映射依据 |
| 全量回归一刀切 | 回归成本爆炸、关键用例被稀释 | 三级分级 + 显式排除清单 |
| 映射不上的硬编进清单 | 虚假置信 | "影响不明"单独列出，人工判断 |
| 用例文件修改与回归范围混为一谈 | 职责越界 | 用例修改归 `test-case-writing`，本 skill 只选回归范围 |
| 零用例资产仍照常产出三级清单 | 凭 diff 编造用例名，清单表面专业实则不可执行 | 先做三档资产盘点；零资产走冒烟建议降级路径并标「无追溯依据」 |
| 锚点陈旧的 code_refs 仍当直连依据 | 重构后影响面错漏（漏掉真受影响的、误报已消亡的） | 命中处与 diff 对不上即整批降级，改走功能层/风险层映射 |