审计并精简整个回归测试套件时，如何用证据而非直觉删除冗余测试

当你需要审计整个回归测试套件、找出冗余/重复/低价值测试并安全地精简或分层时使用。

适用场景

解决思路

1. 先检查项目根目录的 `.agents/qa-project-context.md`，跳过其中已回答的问题；再澄清：语言/运行器、CI 测试结果历史及其回溯范围、套件规模与当前墙钟时间、业务风险图/关键路径、谁签署删除以及是否有 CODEOWNERS 文件、可接受的观察窗口（默认 2 个 sprint / 2 个 release）。
2. 用 per-test（动态）上下文做覆盖率指纹：pytest/coverage.py 运行 `pytest --cov=src --cov-branch --cov-context=test`，让 coverage.py 在每个测试前后调用 `switch_context()`，把每条被测行标记到运行它的测试；`--cov-branch` 确保走 `if` 和走 `else` 的测试不被视为覆盖“同一行”。
3. 从 `.coverage` SQLite 数据库的 `context` 和 `line_bits`/`arc` 表读出 contexts，为每个测试构建精确的 `(file, line)` 与 `(file, branch-arc)` 集合指纹；据此计算：仅被单个测试覆盖的行/分支（唯一覆盖，保护这些测试），以及一个测试的覆盖集是另一个的超集（subsumption，仅作为冗余候选，不是证明）。
4. 不要按每个测试文件的代码行数排名，也不要仅因整体覆盖率低就删除测试——一行测试可能是守护关键分支的唯一防线。
5. 遇到覆盖率完全相同的两个测试时，不要直接判定冗余：覆盖率相等不证明断言、输入或 oracle 相同。运行变异测试确认：Python 用 mutmut（3.6.0+）或 cosmic-ray，JS/TS 用 StrykerJS（9.x），Java/JVM 用 PIT，Rust 用 cargo-mutants；若 A 杀死了 B 杀死的所有变异体，A 才真正包含 B 的缺陷检测能力，B 才是可辩护的删除候选；若 B 杀死了 A 漏掉的变异体，则保留 B。断言不同且变异结果不同时，保留两者。
6. 做近重复聚类：把每个测试解析为 AST，归一化标识符名和字面量后比较结构，用 token/tree 相似度（归一化 token shingle 的 Jaccard、AST n-gram 的 cosine 或树编辑距离）；不要用原始行号作为相似度信号，也不要按文件名分组。
7. 结合覆盖率画像签名：从第 1 步得到每个测试的覆盖行/分支集合作为执行画像；AST 近似且覆盖率签名近似的测试才是强近重复候选，单一信号较弱。
8. 用可调相似度阈值做聚类（如凝聚/层次聚类，在可配置截断处切割，起始约 0.85，按误报容忍度调整）；输出聚类结果而非删除；每个聚类都交由人工审查，因为复制粘贴的测试常在某个关键断言上分叉。
9. 挖掘 CI 历史：解析 JUnit XML 归档或使用已存储结果的平台（Datadog Test Optimization、Trunk Flaky Tests、BuildPulse、CircleCI test insights），为每个测试计算通过率/失败率和翻转率（连续运行 pass↔fail 的转换频率）。
10. 对从不失败的测试：不要删除。从不失败通常意味着它守护的是低变更、低风险、稳定的代码；处置为“调查，不删除”——检查被测代码的变更率和风险，若覆盖关键路径则保留。
11. 对始终不稳定的测试：不稳定性不由单次运行决定，真正定义是同一 SHA/同一提交上出现不同结果；按提交 SHA 分组运行，找出同一 SHA 上既有通过又有失败的测试。处置为“隔离并修复 flake，绝不为了清理 CI 而删除”；隔离可立即降低 CI 噪音，根因仍要修复（运行时隔离与自愈见 test-reliability）。
12. 按四类不同状态分别处置：Redundant（被另一测试包含——覆盖相同行且幸存者杀死相同变异体）→ 仅在变异杀死检查确认包含后合并或删除，先隔离；Obsolete（测试已移除的功能/死代码/不存在的路径）→ 验证目标确实不存在后删除；Low-value（从未失败且琐碎——getter、no-op、无有意义断言）→ 隔离/转人工审查，低价值不等于零价值；Keep（唯一覆盖、有正缺陷检测历史或守护高风险路径）→ 保留，不受覆盖率重叠影响。
13. 分层（smoke/core/extended）时不要按速度或文件顺序前 N 个排序：以两个证据输入为准——业务风险/关键路径（来自风险图，见 risk-based-testing）和缺陷检测历史（从 CI 历史加关联 bug 单中挖掘实际抓到过真实 bug 的测试）。Smoke 为最高风险路径加经证实的缺陷捕获者，足够快以门禁每次提交；Core 为每次 PR/合并门禁，覆盖所有关键加高风险；Extended 为其余全部（详尽、长时、边界情况）。执行时间只作为次要的平局裁决，绝不作为主排序轴。用 marker/tag 编码分层（`@pytest.mark.smoke` / `@pytest.mark.extended`、Jest/Vitest tag 或 JUnit category），使 `pytest -m smoke` 无需移动文件即可选择分层。
14. 破坏性安全：绝不在单个 PR 中删除整个队列，也不要 `rm` 测试文件。先隔离再删除——把标记的测试标为跳过（`@pytest.mark.skip(reason="curation-2026-Q2, see audit row")`、`xfail`、Jest `.skip`）或移到仍留在仓库中的 `quarantine/`/`deprecated/` 套件；它们停止运行但保持可见且可即时恢复。
15. 要求人工签署：由具名批准人通过测试目录上的 CODEOWNERS 或 PR 上的显式审查者批准；不得以“冗余测试无需审查”为由跳过，冗余在第 2 步确认前只是假设。
16. 定义观察窗口：让队列隔离状态下运行套件一个宽限期（默认 2 个 sprint / 2 个 release），并监控逃逸缺陷——关注生产事故和 bug 单中任何被隔离测试本应捕获的问题；窗口内出现逃逸缺陷意味着该测试并非冗余，应恢复。
17. 之后才以小批量删除，每批关联其审计行；记录隔离位置和提交，使任何测试可一步恢复/回滚；git 历史是底线，不是恢复方案。
18. 产出审计记录：不是删除测试的计数，而是每个被删测试一行，包含：测试 id/路径；类别与理由（redundant/obsolete/low-value 及具体理由，如“被包含；幸存者杀死相同变异体集合”）；被谁取代（取代它的幸存测试 id）；覆盖率增量（删除后不再覆盖的行/分支，前后对比，理想为零净损失）；批准（批准人姓名、PR/提交 SHA、签署日期）；恢复路径（隔离位置和一行恢复/回滚命令）。存为提交的 CSV/Markdown 表（如 `docs/test-curation-log.md`），与删除一起版本化。
19. 验证审计成立后再删除：`sqlite3 .coverage "SELECT COUNT(*) FROM context WHERE context != '';"` 返回约等于测试数的计数（非 0/1）；每条 redundant 行的 `mutation_check` 列已填（yes + run id）；`git log --diff-filter=D --name-only -- tests/ | grep test_` 显示隔离 PR 未删除测试文件，被标记测试为 skip/xfail 或位于 `tests/quarantine/` 下仍可收集；`pytest -m smoke --collect-only` 只返回风险/缺陷捕获队列且在 smoke 预算内，`pytest -m "smoke or core or extended" --collect-only` 覆盖所有测试（无未打标签的测试）；审计记录中无 redundant 行的 `superseded_by`、`coverage_delta` 或 `mutation_check` 为空，声称零净损失的删除其 `coverage_delta` 为 `0 lines / 0 branches`。

适用边界 · 注意事项

• 不适用于判断单个测试是否写得好（坏味道、断言）——那是 ai-qa-review。
• 不适用于在运行时修复单个不稳定测试——那是 test-reliability。
• 不适用于 UI 重构后批量重新生成选择器——那是 selector-drift-recovery。