risk-based-testing

name	risk-based-testing
description	测试时间有限要分优先级时使用。适用于版本测试规划、紧急修复验证、跨模块风险评估。融合概率×影响矩阵、Bach Heuristic Risk-Based Testing、HAZOP。

风险驱动测试（Risk-Based Testing）

参考来源：Hans Schaefer《Risk-Based Testing》、James Bach《Heuristic Risk-Based Testing》、ISTQB Advanced Test Manager。

适用场景

• 测试时间不够，要决定先测哪个
• 版本发布前评估"未测到"的风险
• 紧急修复验证（影响范围分析）
• 跨模块功能上线（风险点识别）
• 与 PM 谈判"哪些不测"的依据

核心原则

1. 不能测所有东西
   接受这个事实是 RBT 的起点

2. 测试是为了"暴露风险"
   不是验证开发对，是验证"它会出错的地方"

3. 风险 = 概率 × 影响
   两个维度都要量化，不能拍脑袋

4. 风险随时间和变更动态变化
   每次迭代重新评估

5. 沟通比矩阵更重要
   矩阵是工具，目标是和团队对齐"什么风险可接受"

风险矩阵（5×5 标准模型）

影响 ↑
  5 │ M  H  H  C  C
  4 │ L  M  H  H  C
  3 │ L  M  M  H  H
  2 │ L  L  M  M  H
  1 │ L  L  L  M  M
    └──────────────→ 概率
      1  2  3  4  5

L 低风险（接受）
M 中风险（监控）
H 高风险（必须测试 / 缓解）
C 关键风险（不测就不上）

影响维度（业务视角）

等级	用户影响	业务影响	修复成本
5 关键	全用户阻塞、数据丢失	资金损失、合规	紧急回滚 + 加班修复
4 严重	部分用户阻塞	客诉、SLA 违约	当天热修
3 中等	功能不可用但有 workaround	体验下降	下版本修
2 轻微	偶发 / UI 问题	几乎无	排期修
1 极小	边缘场景	无	可以不修

概率维度（技术视角）

等级	触发条件	历史数据
5 极高	主路径必触发	上版本同模块出过 Bug
4 高	常用路径会触发	同类业务出过
3 中	部分用户触发	偶发记录
2 低	少见组合触发	无历史
1 极低	极端边缘场景	理论可能

风险识别 Checklist（James Bach Heuristic）

业务风险

• 涉及钱（支付 / 退款 / 扣减）
• 涉及隐私（PII / 健康数据 / 身份）
• 涉及合规（GDPR / 等保 / 行业法规）
• 影响品牌（用户面 / 媒体可见）
• 影响 SLA / 合同义务

技术风险

• 新技术 / 新依赖（首次使用）
• 重构（行为应不变但难证明）
• 跨服务 / 跨数据中心
• 异步 / 并发 / 分布式
• 依赖第三方
• 性能敏感（高 QPS / 大数据）

流程风险

• 多人参与（沟通缺口）
• 时间紧（赶上线）
• 测试环境与生产差异大
• 数据迁移
• 灰度策略不成熟

历史风险

• 同模块上版本有 Bug
• 同类业务出过事故
• 同开发者写的代码出过 Bug
• 复现概率不稳定的历史 Bug

工作流程

1. 识别风险点（用上面 Checklist）
   ↓
2. 给每个风险打分
   - 概率 P (1~5)
   - 影响 I (1~5)
   ↓
3. 排序
   按 P × I 倒序
   ↓
4. 分级处理
   - C（关键）→ 必测 + 多种方法 + 评审
   - H（高）→ 必测 + 标准方法
   - M（中）→ 选测 + 单一方法
   - L（低）→ 接受 / 不测 / 监控
   ↓
5. 与 PM / Tech Lead 评审
   - 哪些可以"不测"
   - 哪些需要额外资源
   - 哪些需要灰度 / 监控兜底
   ↓
6. 输出风险登记表

风险登记表（输出物）

ID	风险描述	概率	影响	等级	测试策略	缓解措施	责任人	状态
R1	支付幂等失效导致重复扣款	4	5	C	全路径 + 并发测试	灰度 5% + 监控	QA + Dev	✅ 已测
R2	大订单分页超时	3	4	H	性能测试 1 万订单	索引 + 分页优化	DBA	⏳ 进行中
R3	移动端 iOS 18 兼容	2	3	M	主路径手测	客诉监控	QA	接受

时间分配模型（80/15/5）

80% 时间 → 关键和高风险（C + H）
  - 完整用例 + 多角度方法
  - 自动化优先

15% 时间 → 中风险（M）
  - 主路径用例
  - 选测，时间充裕再补

5% 时间 → 低风险（L）
  - 抽样 / 探索式 / 监控
  - 显式记录"接受"

决策表：何时升级风险

触发条件	动作
C 级风险 + 时间不够	推迟上线 / 砍范围 / 申请加资源
H 级风险 + 测试发现 Bug	升级为 C，重新评估上线
M 级风险 + 历史出过事	升级为 H
多个 H 风险叠加	整体升级为 C 处理

与其他工具结合

+ test-strategy：测试范围按风险分配
+ test-case-design：高风险路径多种方法覆盖
+ exploratory-testing：高风险区域 charter
+ regression-testing：高风险点纳入回归核心
+ quality-gate：C/H 级风险必须 0，否则不放行

质量自检

□ 每个风险都有概率 × 影响打分
□ 打分有依据，不是拍脑袋
□ C 级风险有缓解措施（不只是测试）
□ 风险登记表与 PM/Tech Lead 评审过
□ "不测"的低风险有显式记录和接受
□ 时间分配按 80/15/5
□ 历史 Bug 转化为风险点
□ 灰度 / 监控作为风险兜底（不只是测试兜底）

常见坑

1. 风险靠感觉打分——同一风险不同人打 H/L 差异大，要有依据
2. 只识别技术风险——漏业务、流程、历史四个维度
3. 风险登记表不更新——上线前的快照，没人看
4. C 级风险靠"测得严"解决——应该砍范围 / 灰度 / 推迟
5. 时间平均分配——80% 模块得 80% 时间，C 级却只有 5 小时
6. 不沟通就决策——QA 单方面"不测"，PM 不知情
7. 历史 Bug 不复用——上版本出过的同类问题没纳入新风险
8. 缓解措施 = 多写用例——忽略灰度、监控、回滚等非测试手段

配套模板

• templates/risk-register-template.md — 风险登记表 + 概率影响矩阵 + 缓解措施跟踪

与其他 skill 的协作

上游：
  test-strategy → 提供测试范围
  历史 field-journal → 提供历史风险

下游：
  test-case-design → 高风险用例细化
  exploratory-testing → 高风险区域 charter
  regression-testing → 风险点入回归
  quality-gate → 风险等级转化为放行条件
  test-report → 风险结论作为最终判断