qa-regression-testing

⚠️ 安全警告：本技能的示例可能涉及发布阻塞策略和回归用例分级。 实际使用时请勿直接阻塞发布，先与项目经理和开发确认风险等级和发布窗口。 本技能仅在 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	少	代码映射	低
风险驱动	大版本/重构	中	风险评估	中
时间驱动	紧急发布	灵活	时间预估	高（显式暴露）