# Risk Based Testing

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

- Skill: `zhaoxuya520/risk-based-testing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/risk-based-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/risk-based-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/risk-based-testing

---


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

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

## 适用场景

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

## 核心原则

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

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

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

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

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

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

```text
影响 ↑
  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

## 工作流程

```text
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）

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

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

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

## 决策表：何时升级风险

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

## 与其他工具结合

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

## 质量自检

```text
□ 每个风险都有概率 × 影响打分
□ 打分有依据，不是拍脑袋
□ 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 的协作

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

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