regression-testing

Regression testing (regression-testing)

Code changes → automatically determine which tests should be regressed.

• Input：Code Diff（git diff <base>...<head>), Bug fix description, requirement change description, existing test cases (markmap + 测试用例.schema.yaml), (optional) requirement model
• Output (written to disk)：{项目}/回归清单_{日期}.md——Must regress (P0) / Recommended regression (P1) / Optional regression (P2), three levels, with justification given for each item.The tier names follow the P-series notation, but the archiving rule is based on directness of impact, which is a separate criterion from the test case's own priority: directly connected to the change → must regress; indirectly affected within the same module → recommended regression; a [P2] test case that is directly connected to the change via code_refs also enters the "must regress" tier (pipeline tiered consumption is executed according to this tier, see ../core/pipeline-integration.md）
• Prerequisite dependencies: a persistent "test case ↔ code ↔ function" traceability mapping; all three layers in v0 come from artifacts written to disk and do not depend on session memory:
  1. Code-level anchors: test case appendix "Code Evidence List (TC ↔ file:line)", structured by the Schema's code_refs structured
  2. Function layer: requirement model + Schema's module / risk_ref
  3. per-run increment: changed file mapping appendix (generated for this diff)

Without this data structure, impact analysis is just "letting the model read the diff once and guess."Pre-launch three-tier asset inventory(determines which path to take, to prevent hardcoding a checklist with zero assets):

• Fully complete(both markmap + Schema traceability mapping present): follow the complete analysis chain of the workflow
• Only markmap, no Schema: first use test-case-writing to extract and backfill from the existing markmap (no manual rewrite needed), then enter the workflow
• Zero test case assets: do not fabricate a checklist from the diff——give the user downgrade options: P0 smoke suggestions (each item marked "no traceability basis, coverage not guaranteed"), or first use test-case-writing to backfill a minimal test case set and then return to run this process

Knowledge base input (checked separately, does not change the above routing): when the project has a .qa/ knowledge base, at startup first read its INDEX.md——flaky-tests.md active entries directly as input for the "historical noise vs. true regression" determination and regression tiering (writing and governance are handled by qa-memory ).

When to Use

• After code changes (feature/Bug fix/refactor) are merged, the regression scope needs to be selected
• After a Bug fix, the test case set for "fix verification + related regression" needs to be determined
• A tiered regression checklist with per-item justification and trimmability is needed

When NOT to Use

• Incremental modification of the test case file itself (marking/adding/deprecating test cases) → test-case-writing incremental update process
• Long-term regression strategy (anchor test cases, regression cadence) → test-strategy 's regression_plan
• Discrimination and characterization of a single failure → execution-type skill single-item process (automated-e2e-testing workflow two / api-testing §4); if a round has ≥3 failures, first go through ../core/triage.md routing; a Bug enters bug-analysisonly after user characterization and adjudication (its input must be a confirmed Bug)
• End-to-end pipeline → qa orchestration

analysis chain

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

workflow

1. Inventory changes

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

Change type classification (four basic categories, same as test-case-writing consistent with the enumeration in Phase 1 "Change Inventory"): 🆕 New / ✏️ Modified (can be further annotated as needed: behavior change, 🐛 Bug fix (linked Bug ticket), 🔧 Refactor (behavior should remain unchanged)) / 🗑️ Deleted / 💀 Dead code. Different types have different regression emphases (Refactor → full behavior anchors; Bug fix → fix verification + historically associated test cases for that Bug; Dead code → no regression test cases generated).

2. Impact scope analysis (map layer by layer along the analysis chain)

• Code layer: In Schema, code_refs test cases that hit changed files (or nearby lines in the same file) → directly affected.code_refs isa snapshot at the time the test case was written rather than a real-time index—if the hit location clearly does not match the content of this diff (function no longer exists / line numbers have shifted as a whole out of the nearby band / file has been renamed), the anchor is judged stale,the entire batch is downgraded to reference signalsand mapping is switched to the functional layer / risk layer, with the criteria noted at the top of the checklist
• Functional layer: all test cases under the function to which the changed function belongs (module / requirements model) → indirectly affected; changes to shared utilities/public components → full consumer lookup(grep referencing parties, judge each one)
• Risk layer: risks in the Risk Map attached to affected functions (risk_ref reverse lookup) → their anchor test cases (Critical risks must enter "must regress")
• Historical layer(when there is a Bug ticket): historical regression test cases for the function involved in that Bug

During analysis, provide evidence for each mapping ("TC-03-02 code_refs hit coupon_service.py:124"），Do not force-fit unmappable items—list them as "impact unclear, manual judgment recommended".

3. Generate a graded regression checklist

When there is an associated Bug,the fix verification test cases are merged into the "must regress" tier: take the fix verification test cases given by bug-analysis "Regression Recommendations" (if there are no existing test cases, provide suggested new TC IDs, with the file filed under test-case-writing), and bidirectionally link them with that Bug entry's "Regression Recommendations".

# 回归清单 — {日期}

- 变更基线：{base}...{head}（{commit 数} commits，{文件数} 文件）
- 变更类型：{新增/修改/修复/重构/删除}
- 关联 Bug：{Bug 编号列表，非修复类变更省略此行；有则与对应 Bug 条目的回归建议双向互链}

## 必须回归（P0）
| 用例 | 依据 |
|------|------|
| TC-01-01（SMOKE-1） | 改动文件 code_refs 直连 + Critical 风险 R1 锚点 |
| TC-03-01（修复验证） | Bug-001 修复验证，来源 bug-analysis「回归建议」（新增编号归 test-case-writing） |

## 建议回归（P1）
| 用例 | 依据 |
|------|------|
| TC-02-03 | 同功能模块间接受影响（module=发放流程） |

## 可选回归（P2）
| 用例 | 依据 |
|------|------|
| TC-06-02 | 公共组件改动，消费关系间接 |

## 影响不明（建议人工判断）
- {文件/功能}：{为什么映射不上}

## 无影响确认（显式排除）
- {模块}：{排除依据，如"改动仅涉日志文案，无行为变更"}

Align with test-strategy regression_plan: anchor test cases (Critical risk P0) enter "must regress" by default; execution method is annotated according to automation_plan (e2e / api / manual).

4. Delivery and execution handoff

• After the checklist is written to disk, hand off for execution: automated portion → automated-e2e-testing / api-testing; manual portion → test engineers
• Pipeline tiered consumption: the three-tier grading of this checklist is also the basis for pipeline trigger tiering—PR smoke runs P0, nightly jobs run full P1 + sampled P2, release gates run the full set; for headless non-interactive runtime, see ../core/pipeline-integration.md(loaded at this point), and batch failures after reflow enter ../core/triage.md
• Regression results are summarized into the test report (../core/report-template.md §5 Regression Summary)
• Triage multiple failures first: when a regression round has ≥3 failures, first pre-classify according to ../core/triage.md four categories—C environment / D flaky are excluded from this round's Bug sync criteria (after C is fixed, affected batches must be rerun as-is), B asset issues are listed separately as to-dos, and only the remaining A category enters downstream status synchronization
• Synchronize regression results to Bug status：Update the corresponding Bug entries for fix verification by result — Pass → Verified and Closed; Fail → Fixed Pending Verification (attach failure evidence; if the entry is already in this state, thenreverification round +1, and upon reaching 3, prompt the user to escalate for adjudication — switch fix direction / move to a not-to-fix review), field definitions see ../core/report-template.md §3 (Usage Convention 6)

Common Mistakes

Error	Consequence	Correct Practice
Match test cases only by changed file names	Different layers with the same name and missed detection of consumers of common components	Follow the analysis chain to the end and grep for references to common components
When there is no Schema, rely on "reading the diff and guessing"	Impact analysis degrades into guessing	First extract the Schema from the existing markmap (test-case-writing）
The checklist gives no basis	Not reviewable, cannot be trimmed	Give the mapping basis for each test case
One-size-fits-all full regression	Regression costs explode and critical test cases are diluted	Three-level classification + explicit exclusion list
Hard-code what cannot be mapped into the checklist	False confidence	List "impact unclear" separately and judge manually
Conflate test case file modification with regression scope	Overstepping responsibilities	Test case modification belongs to test-case-writing, this skill only selects the regression scope
Still produce a three-level checklist as usual with zero test case assets	Fabricate test case names from the diff; the checklist looks professional but is actually unexecutable	First do a three-tier asset inventory; for zero assets, follow the smoke recommendation downgrade path and mark "no traceability basis"
Still treat code_refs with stale anchors as direct evidence	Impact scope errors and omissions after refactoring (missing those truly affected, false positives for those already gone)	If the hit locations do not match the diff, downgrade the whole batch and switch to functional-layer/risk-layer mapping