当开发提了 PR、代码变更需要确定测试范围、或者想通过分析代码来预测可能出 Bug 的区域时使用此技能。从测试视角分析代码变更的影响范围、识别高危模式和典型风险区域。不要看完整代码逻辑——你只需要关注变更类型(新增/修改/删除/重构)、影响范围(接口定义/数据库字段/业务逻辑)和相关依赖,据此确定最小回归测试范围。输出代码变更影响分析报告。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
Coding
回归测试
Try it根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策:冒烟回归(P0核心流程)、核心回归(高影响区域)、全量回归(有余力时)。基于变更分析和风险评估选择最省时的回归策略,而不是盲目全量回归。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
What it does
根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策:冒烟回归(P0核心流程)、核心回归(高影响区域)、全量回归(有余力时)。基于变更分析和风险评估选择最省时的回归策略,而不是盲目全量回归。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
The skill document
⚠️ 安全警告:本技能的示例可能涉及发布阻塞策略和回归用例分级。 实际使用时请勿直接阻塞发布,先与项目经理和开发确认风险等级和发布窗口。 本技能仅在 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+条)
├─ 覆盖全面
├─ 部分需人工执行(探索式)
└─ 结果用于发版决策
回归用例筛选策略
策略1:基于变更的筛选(Change-Based)
适用场景:小迭代 / Bugfix版本
核心逻辑:代码变更 = 需要回归的区域
执行步骤:
1. 获取代码变更列表(Diff / Commit)
2. 确定变更影响的模块和接口
3. 从用例库中提取覆盖这些模块的用例
4. 增加模块间调用链上的关联用例
5. 增加历史缺陷中同类变更的相关用例
适用条件:
├─ 有代码评审结果(qa-code-review-for-test)
├─ 用例与代码有映射关系
└─ 变更边界清晰
优点:精准、用例量少
缺点:依赖代码映射、可能遗漏间接影响
策略2:基于风险的筛选(Risk-Based)
适用场景:大版本 / 重构 / 新功能上线
核心逻辑:高风险区域 = 必须回归
执行步骤:
1. 引用风险评估结果(qa-risk-intuition)
2. 高风险区域 → 全量回归(P0-P2全覆盖)
3. 中风险区域 → 核心回归(P0-P1)
4. 低风险区域 → 冒烟回归(P0)
5. 历史缺陷高发模块 → 增加额外覆盖
适用条件:
├─ 有风险评估报告
├─ 用例库有优先级标注
└─ 回归时间有限
优点:时间弹性大、可裁剪
缺点:依赖风险判断的准确性
策略3:基于时间的筛选(Time-Boxed)
适用场景:回归时间严重不足 / 紧急发布
核心逻辑:时间限制 = 用例上限,按价值排序
执行步骤:
1. 计算可用回归时间
2. 按优先级倒序裁减:
├─ 先保冒烟(P0,必须过)
├─ 再保核心(P0+P1,尽量过)
└─ 最后全量(P0-P2,能过多少算多少)
3. 标记未覆盖的风险区域
4. 输出回归风险报告
优点:总能给出可执行的方案
缺点:覆盖率随裁剪下降,需显式暴露风险
策略比较速查
| 策略 | 适用场景 | 用例量 | 依赖 | 风险暴露 |
|---|---|---|---|---|
| 变更驱动 | 小迭代/Bugfix | 少 | 代码映射 | 低 |
| 风险驱动 | 大版本/重构 | 中 | 风险评估 | 中 |
| 时间驱动 | 紧急发布 | 灵活 | 时间预估 | 高(显式暴露) |
增量 vs 全量 决策
| 决策维度 | 全量回归 | 增量回归 | 差分回归 |
|---|---|---|---|
| 执行范围 | 全部用例 | 变更相关 + 关联 | 变更前 vs 变更后 差异点 |
| 执行时间 | 1-5天 | 2-4小时 | 30-60分钟 |
| 覆盖风险 | 最低 | 中 | 高(漏测风险最高) |
| 适用 | 大版本发版 | 小迭代发版 | Bugfix验证 |
| 自动化要求 | 高 | 中 | 中 |
决策流程:
变更范围是否跨模块?
├─ 是 → 全量回归
└─ 否 → 变更是否涉及核心逻辑?
├─ 是 → 核心回归 + 增量
└─ 否 → 增量回归 + 差分
时间是否充足?
├─ 是 → 全量回归
└─ 否 → 时间驱动裁剪
回归用例维护
新增场景
- 每次发布新增的用例 → 标记回归标签
- 线上Bug修复后 → 增加复测用例并入回归库
- 新功能上线 → 核心用例加入核心回归集
淘汰场景
检查频率:每季度
淘汰标准:
├─ 功能已下线 → 移除
├─ 连续6次回归无失败 → 降级到低频执行
├─ 被更优用例覆盖 → 合并/替换
├─ 执行时间过长且非核心 → 移到手动回归
保留标准:
├─ 每个P0用例至少1个回归用例
├─ 每个历史Bug至少1个复测用例
├─ 每个核心模块至少3个回归用例
效率度量
- 回归用例通过率:> 98%
- 回归执行时长:稳定或下降
- 漏测率:每轮新发现的回归遗漏数
- 回归覆盖代码变更率:变更代码中被回归覆盖的比例
输出示例
用户说"这个版本要回归测试" → 确定变更范围(code-review → 影响模块) → 引用风险评估(risk-intuition → 高/中/低) → 决策:小迭代 → 增量回归(P0 + 变更覆盖) → 输出回归方案:回归范围 + 用例清单 + 时间预估
用户说"回归时间不够,只能测4小时" → 时间驱动策略:
- 冒烟回归(P0):30分钟
- 核心回归(变更区域P0-P1):2.5小时
- 剩余时间:补充高风险区域 → 输出回归风险报告:标注未覆盖的风险区域
用户说"加个字段,影响范围很小" → 变更驱动策略:
- 代码Diff分析:涉及1个字段、1个页面
- 提取该页面的P0-P1用例
- 增加字段输入校验的边界测试 → 输出:增量回归清单(15条用例,耗时30分钟)
检查清单
回归策略制定后检查:
- 是否按金字塔分层(冒烟/核心/全量)?
- 筛选策略是否匹配变更特征?
- 时间约束是否显式考虑?
- 未覆盖的风险区域是否已暴露?
- 回归用例库是否持续维护?
- 回归效率是否有量化指标?
- 每个历史Bug是否有复测用例?
Related skills
当一个迭代结束、一个项目完成、或者发生线上事故需要事后分析时使用此技能。通过系统性的回顾会议和数据复盘,把个人和团队的经验教训转化为可复用的组织资产。不要沦为"说说好话走个形式"——有效的复盘需要有数据支撑(缺陷趋势/漏测分析/效率数据)、有根因分析(为什么出问题)和有 action items(下次怎么做不一样)。输出复盘报告和改进项追踪表。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险(变更范围/影响面/回退成本),设计灰度发布策略(按用户/区域/流量比例),制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了,我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征(新项目/迭代/重构/紧急修复)、风险分布和资源约束设计分层测试策略,明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"。输出包含风险矩阵、分级测试方案的测试策略文档。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
识别那些"看起来很简单但实际风险很高"的测试区域,帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时,应当使用此技能。典型的危险信号包括:频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注概率和影响等级,并附上缓解建议。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当功能已经上线了但还担心线上质量、或者需要设计灰度发布后的验证方案时使用此技能。通过生产监控(APM/日志/用户反馈)、线上巡检拨测、A/B 验证和混沌工程将测试延伸到生产环境。不要把上线当成终点——用户在生产环境的使用方式是永远测不全的。输出右移验证方案(灰度监控指标 + 拨测用例 + 告警阈值 + 回滚触发条件)。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills