| 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）
业务风险
技术风险
流程风险
历史风险
工作流程
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 → 风险结论作为最终判断
