风险驱动测试（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）
业务风险
技术风险
流程风险
历史风险
工作流程
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 转化为风险点
□ 灰度 / 监控作为风险兜底（不只是测试兜底）
常见坑
- 风险靠感觉打分——同一风险不同人打 H/L 差异大，要有依据
- 只识别技术风险——漏业务、流程、历史四个维度
- 风险登记表不更新——上线前的快照，没人看
- C 级风险靠"测得严"解决——应该砍范围 / 灰度 / 推迟
- 时间平均分配——80% 模块得 80% 时间，C 级却只有 5 小时
- 不沟通就决策——QA 单方面"不测"，PM 不知情
- 历史 Bug 不复用——上版本出过的同类问题没纳入新风险
- 缓解措施 = 多写用例——忽略灰度、监控、回滚等非测试手段
配套模板
templates/risk-register-template.md — 风险登记表 + 概率影响矩阵 + 缓解措施跟踪
与其他 skill 的协作
上游：
test-strategy → 提供测试范围
历史 field-journal → 提供历史风险
下游：
test-case-design → 高风险用例细化
exploratory-testing → 高风险区域 charter
regression-testing → 风险点入回归
quality-gate → 风险等级转化为放行条件
test-report → 风险结论作为最终判断
zhaoxuya520