今天我们就简单来讨论一下RBT分析，而真正的RBT分析实战是我们咨询服务的一个亮点。如果问你，首屈一指的软件测试策略是什么？自然是基于风险的测试（RBT）策略。而RBT策略首先应用于测试需求分析，而且测试分析是测试设计、执行的基础。
  1.什么是RBT
  RBT就是一种基于风险概率的软件测试策略，即根据软件的复杂性和耦合性、业务的关联性、功能的使用频率、应用场景、可能存在缺陷等来评估风险，并基于风险的严重性来设置/确定测试的优先级，从而根据测试优先级来安排测试资源（人力、时间等）、测试任务的先后次序。这里说的风险，主要指产品的质量风险或产品某些方面存在缺陷的风险，即对产品质量产生不良影响的概率事件，或者说，用户使用软件应用的特征和功能时可能受到的影响，如可能碰到无法使用、服务中断、操作困难或出错等问题。
  2.RBT分析方法
  RBT分析方法，包括定量分析和定性分析，大多数情况下是定性分析，除非软件研发收集了足够的相对规范的数据。首先，我们需要分析每一项业务需求、应用场景、E2E业务流程、功能需求和非功能性需求，确定测试项。针对测试项进行质量/测试风险分析，这时需要考虑到质量要求、开发人员的素质、设计或代码可能出现的问题、进度压力、资源不足、范围边界不确定、技术限制、系统复杂性、上一个版本（或遗留系统）的影响等带来的影响，以及功能的可见性、使用频率、故障引起的成本等，尽可能列出风险的影响因素，最终识别出主要的风险因素，建立风险checklist，从而更好地判断产品需求实现的质量风险，即确定失效的概率和对用户的影响。这可以用风险评估矩阵来完成，如下图所示，从而确定测试项的优先级，从而可以对测试项进行排序，确定基于风险的测试计划，包括测试任务的先后次序、测试过程等。
  风险越高的测试项越要优先进行测试设计和执行，越需要安排专业能力强、经验丰富的研发/测试人员来完成该测试项的设计。基于设计和执行的结果分析，包括对缺陷自身的分析和回溯性分析（回溯到测试用例、回溯到业务/功能/非功能性需求等），反过来可以进一步完善风险checklist和风险评估矩阵。基于风险的测试可用于任何层次的测试，如组件、集成、系统和验收测试，也适用于手工测试和自动化测试，以及探索式测试方式等。
  3.RBT分析的价值
  举一个简单的例子来说明RBT分析的价值。
  假如有一个测试任务，根据测试工作量的评估需要5天才能完成测试，但现在因为业务紧急需求，需要提前三天交付，测试的时间只有2天。如果按部就班进行测试（不考虑加班），测试的覆盖率只有2/5=40%（相对测试计划，假定测试计划的覆盖率是good enough），40%太低，无法达到交付的要求。如果采用RBT策略进行分析，虽然天也只执行了20%的测试用例，按照理想的情况（80/20原则），但可以覆盖80%的质量风险（缺陷）。在对剩余的80%测试用例进行分析，第2天执行其中的20%测试用例，可以覆盖剩余的20%质量风险的80%，即再覆盖16%的质量风险（缺陷），这样最理想情况下可以达到96%的风险覆盖率，即使不能达到理想状态，也远远高于40%，在时间特别有限的情况下，基本达到产品发布的要求。
  4.RBT分析在持续测试中的应用与价值
  RBT在持续测试中的应用，可以参考之前发布的文章：2020年软件测试趋势报道：彻底实现持续测试（中）或参考《敏捷测试：以持续测试促进持续交付》，虽然不能代表全部，可以代表其中一个典型的应用。
  总之，在持续测试甚至在一般的测试环境下，RBT是最基本的测试策略，而RBT的测试需求分析是基础，是我们需要掌握的基本技能之一。