regression-testing

回归测试（regression-testing）

代码变更 → 自动判断应该回归哪些测试。

• 输入：Code Diff（git diff <base>...<head>）、Bug 修复说明、需求变更说明、已有用例（markmap + 测试用例.schema.yaml）、（可选）需求模型
• 输出（落盘）：{项目}/回归清单_{日期}.md——必须回归（P0）/ 建议回归（P1）/ 可选回归（P2）三级，逐条给依据。档名沿用 P 系记号，但归档规则是影响直接程度，与用例自身优先级是两套口径：直连改动 → 必须回归，同模块间接受影响 → 建议回归；一条 [P2] 用例因 code_refs 直连改动同样进「必须回归」档（流水线分层消费按本档位执行，见 ../core/pipeline-integration.md）
• 前置依赖：持久的"用例 ↔ 代码 ↔ 功能"追溯映射，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 补建最小用例集再回来跑本流程

知识库输入（另查，不改变上述分流）：项目存在 .qa/ 知识库时，启动先读其 INDEX.md——flaky-tests.md 的 active 条目直接作为「历史噪声 vs 真实回归」判定与回归分级的输入（写入与治理由 qa-memory 承担）。

When to Use

• 代码变更（feature/Bug 修复/重构）合入后，需要选择回归范围
• Bug 修复后需要确定"修复验证 + 关联回归"的用例集
• 需要一份逐条给依据、可裁剪的分级回归清单

When NOT to Use

• 用例文件的增量修改本身（标记/新增/废弃用例）→ test-case-writing 增量更新流程
• 长期回归策略（锚点用例、回归节奏）→ test-strategy 的 regression_plan
• 单条失败的分辨与定性 → 执行类 skill 单条流程（automated-e2e-testing 工作流二 / api-testing §4）；一轮失败 ≥3 条先走 ../core/triage.md 分流；Bug 经用户定性裁决后才进 bug-analysis（其输入必须是已确认 Bug）
• 端到端流水线 → qa 编排

分析链

Changed Files（git diff）
    ↓
Changed Functions（diff 中被修改的函数/类/组件）
    ↓
Affected Features（函数 → 所属功能：经 Schema code_refs / module / 需求模型映射）
    ↓
Affected Test Cases（功能 → 用例：risk_ref / module / 附录改动文件映射）
    ↓
Regression Scope（三级回归清单 + 依据）

工作流

1. 盘点变更

git diff <base>...<head> --stat          # 改动文件清单
git diff <base>...<head> -U3             # 逐文件读改动内容，定位改动函数

变更类型分类（基础四类，与 test-case-writing 阶段一「改动盘点」的枚举一致）：🆕 新建 / ✏️ 修改（可按需细分标注：行为修改、🐛 Bug 修复（关联 Bug 单）、🔧 重构（行为应不变））/ 🗑️ 删除 / 💀 死代码。类型不同，回归侧重不同（重构 → 全量行为锚点；Bug 修复 → 修复验证 + 该 Bug 历史关联用例；死代码 → 不产生回归用例）。