用途：在多次发布之间跟踪、管理和维护回归测试套件，确保已修复的缺陷保持修复、既有功能保持稳定，并识别“已修缺陷缺少对应回归测试”的覆盖缺口。
主要能力：扫描代码库中的缺陷修复提交（如 fix:、bugfix、closes #、工单号等模式），为每个修复检查是否存在对应回归测试，并将缺少测试的修复标记为覆盖缺口；生成回归测试清单（regression-tests.json 或 regression-tests.md），记录缺陷工单号、测试文件与测试名、缺陷严重级别、测试添加日期、当前状态；为既有回归测试添加可追溯元数据；生成回归覆盖率报告，展示已修缺陷与有回归测试缺陷的占比、按严重级别排序的未测回归、以及变得不稳定或被禁用的测试；可配置 CI 检查，在修复类 PR 未包含至少一个回归测试时使构建失败；并支持按周或按发布周期进行定期审计。
使用方式：需要测试框架支持标签或标记，如 @tag、pytest.mark、JUnit @Tag；需要带问题编号的缺陷跟踪系统，如 GitHub Issues、Jira、Linear；需要可访问的 Git 历史以关联修复与测试；需要已有具名测试用例；需要 CI 产出 JUnit XML 或 JSON 测试结果；按文档流程扫描、标记、生成清单与报告并接入 CI。
适用场景：发布前回归验证、缺陷修复闭环检查、测试套件健康度与覆盖率审计。
限制与错误处理：若回归测试通过但缺陷复现，说明测试未覆盖确切失败条件，需依据原始报告更新断言；孤立回归标签需在无效工单被关闭后定期清理或重新分配；被持续跳过的测试需修复环境依赖或改为带正确初始化的集成测试；被重构删除代码路径导致的“假覆盖缺口”应标注为“resolved by removal”；不稳定回归测试需用重试、固定随机种子或模拟时钟稳定，并标记 @flaky 以便监测。其他具体平台差异或价格暂未提供。