基于风险的测试是什么
基于风险的测试（RBT）按「发生可能性 × 影响程度」对功能与质量属性排序，把有限的测试资源投向高风险区域：高风险多测深测，低风险少测或抽测。风险分析不只是计划阶段的一次作业——它贯穿测试设计、执行排序与退出决策，并随需求变更、缺陷分布与发布节奏持续更新。
基本信息
| 排序依据 | 发生可能性（复杂度、变更量、历史缺陷）与影响程度（用户、资金、合规） |
|---|---|
| 评估形式 | 风险清单或矩阵，落到具体条目并关联用例 |
| 更新时机 | 需求变更、缺陷分布变化与发布节奏调整时重评 |
| 排序复审 | 按迭代节奏复核可能性与影响评分 |
| 退出依据 | 高风险区域覆盖达标才谈退出，而不是用例全跑完 |
评估示例
| 风险项 | 可能性 | 影响 | 处置 |
|---|---|---|---|
| 支付回调丢失 | 中 | 高 | 优先覆盖：幂等、重试、对账用例 |
| 导出报表字段错位 | 高 | 低 | 常规覆盖 + 抽查 |
| 对账任务超时 | 低 | 高 | 针对超时与补偿机制定向设计 |
| 帮助页文案过时 | 高 | 极低 | 抽测或免测，登记跟踪 |
典型使用场景
- 测试计划编制：用风险排序决定各模块的测试深度与用例密度。
- 资源紧张时取舍：时间被压缩时明确保什么、舍什么、谁确认。
- 回归范围选择：按变更影响面圈定回归范围，避免全量重跑。
- 发布放行评审：以高风险覆盖状态作为退出判据。
- 探索式测试排程：风险高的区域安排更多会话时间。
- 缺陷复盘：把事故反推成新的风险项，更新清单。
风险清单要落到具体条目并关联用例，否则无法验证高风险已被覆盖。
风险评分不必精确：排序的用途是分配资源，能稳定区分优先级就够；纠缠小数点会消耗大量讨论时间。
高风险区域的「深测」要具体化：增加参数组合、异常分支、并发与恢复场景，而不是把同样的用例跑三遍。