返回技能市场

根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策:冒烟回归(P0核心流程)、核心回归(高影响区域)、全量回归(有余力时)。基于变更分析和风险评估选择最省时的回归策略,而不是盲目全量回归。

版本: 1.0.1分类: 测试与质量
中文

SKILL.md

⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills

⚠️ 安全警告:本技能的示例可能涉及发布阻塞策略和回归用例分级。 实际使用时请勿直接阻塞发布,先与项目经理和开发确认风险等级和发布窗口。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。

回归测试策略

无代码评审时的替代方案:如果 qa-code-review-for-test 的输出不可用(代码评审不在本次工作流路径中),可直接根据用户提供的变更描述、版本 diff 或功能变更列表来确定变更影响范围和回归重点。上游依赖为可选,不阻塞工作流执行。

核心原则

回归不是全量重测,而是「判断哪些不用测」比「决定哪些要测」更重要。

回归金字塔

第1层:冒烟回归(P0 — 提交级)

定位:每次提交/部署必须通过的快速验证
执行频率:每次提交/构建
执行方式:自动化(CI/CD触发)
执行时间:< 15分钟
覆盖率:核心流程 100%

典型用例:
├─ 关键登录态验证
├─ 主页/核心页面可访问
├─ 核心API健康检查
├─ 数据库连接正常

用例特征:
├─ 数量少(< 50条)
├─ 执行快(秒级)
├─ 结果明确(通过/不通过)
└─ 失败即阻塞发布

第2层:核心回归(P0 + P1 — 日级)

定位:每日/每个迭代版本的关键功能验证
执行频率:每日/每次提测
执行方式:自动化为主 + 人工抽测
执行时间:< 2小时
覆盖率:核心功能 100% + 关联功能 80%

典型用例:
├─ 所有P0用例
├─ 关联功能的核心场景
├─ 历史缺陷的复测用例
├─ 变更影响区域的主路径

用例特征:
├─ 中等数量(100-500条)
├─ 覆盖核心链路
├─ 可自动化率 > 80%
└─ 失败需人工确认

第3层:全量回归(P0-P3 — 发版级)

定位:大版本发布前的全面验证
执行频率:每个大版本
执行方式:自动 + 人工结合
执行时间:1-5天
覆盖率:全功能覆盖 90%+

典型用例:
├─ 全量P0-P2用例
├─ 所有功能点的边界场景
├─ 兼容性覆盖组合
├─ 全链路性能验证

用例特征:
├─ 数量大(500+条)
├─ 覆盖全面
├─ 部分需人工执行(探索式)
└─ 结果用于发版决策

加载时机

什么时候读读哪个
确定"回归哪些"时references/regression-selection.md

回归用例筛选策略的完整内容已下沉至 references/regression-selection.md,避免每次触发都占用上下文。

增量 vs 全量 决策

决策维度全量回归增量回归差分回归
执行范围全部用例变更相关 + 关联变更前 vs 变更后 差异点
执行时间1-5天2-4小时30-60分钟
覆盖风险最低中高(漏测风险最高)
适用大版本发版小迭代发版Bugfix验证
自动化要求高中中
决策流程:
变更范围是否跨模块?
├─ 是 → 全量回归
└─ 否 → 变更是否涉及核心逻辑?
    ├─ 是 → 核心回归 + 增量
    └─ 否 → 增量回归 + 差分

时间是否充足?
├─ 是 → 全量回归
└─ 否 → 时间驱动裁剪

回归用例维护

新增场景

  • 每次发布新增的用例 → 标记回归标签
  • 线上Bug修复后 → 增加复测用例并入回归库
  • 新功能上线 → 核心用例加入核心回归集

淘汰场景

检查频率:每季度
淘汰标准:
├─ 功能已下线 → 移除
├─ 连续6次回归无失败 → 降级到低频执行
├─ 被更优用例覆盖 → 合并/替换
├─ 执行时间过长且非核心 → 移到手动回归

保留标准:
├─ 每个P0用例至少1个回归用例
├─ 每个历史Bug至少1个复测用例
├─ 每个核心模块至少3个回归用例

效率度量

  • 回归用例通过率:> 98%
  • 回归执行时长:稳定或下降
  • 漏测率:每轮新发现的回归遗漏数
  • 回归覆盖代码变更率:变更代码中被回归覆盖的比例

输出示例

用户说"这个版本要回归测试" → 确定变更范围(code-review → 影响模块) → 引用风险评估(risk-intuition → 高/中/低) → 决策:小迭代 → 增量回归(P0 + 变更覆盖) → 输出回归方案:回归范围 + 用例清单 + 时间预估

用户说"回归时间不够,只能测4小时" → 时间驱动策略:

  1. 冒烟回归(P0):30分钟
  2. 核心回归(变更区域P0-P1):2.5小时
  3. 剩余时间:补充高风险区域 → 输出回归风险报告:标注未覆盖的风险区域

用户说"加个字段,影响范围很小" → 变更驱动策略:

  1. 代码Diff分析:涉及1个字段、1个页面
  2. 提取该页面的P0-P1用例
  3. 增加字段输入校验的边界测试 → 输出:增量回归清单(15条用例,耗时30分钟)

检查清单

回归策略制定后检查:

  • 是否按金字塔分层(冒烟/核心/全量)?
  • 筛选策略是否匹配变更特征?
  • 时间约束是否显式考虑?
  • 未覆盖的风险区域是否已暴露?
  • 回归用例库是否持续维护?
  • 回归效率是否有量化指标?
  • 每个历史Bug是否有复测用例?

评论与讨论

0/2000

还没有评论,分享你的体验吧。