基于风险的测试学习总结

一.RBT的概念

很有意思的是从字面上讲，RBT可以被翻译成Requirement Base Testing,也可以被翻译成Risk Base Testing。而正好在ISTQB的测试体系里，测试从大的方向可以分为“基于规格说明”的测试技术及“基于缺陷与经验”的测试技术。“基于规格说明"的测试技术，主要讲求的是基于需求说明、规格说明进行结构化的测试计划、测试分析、测试设计、测试执行等工作。本文讲的RBT是Risk Base Testing，它更多的是一种面向缺陷发现的测试技术。

个人理解，RBT不是一种具体的测试工具，也不是具体的某种测试类型（类似功能、性能、可靠性），它更多的是一种宏观上测试策略，对于整个测试活动的组织方式。

二.什么是风险，为什么需要RBT

2.1什么是风险

风险是一种负面的或者不想要的结果，或者事件发生的可能性。任何影响利益相关者对产品质量及成功信心的因素都可以称之为风险。而风险又可以分为产品风险和项目风险：

• 产品风险：与被测试对象有直接关系的风险。
• 项目风险：与整个软件项目的管理与控制相关的风险。

2.2为什么需要RBT

总所周知，由于测试的不可穷尽性。我们总只能在有限的时间、资源和质量之间找平衡。采用RBT又能让测试更具针对性，帮助决策者做测试资源的精确配置–人力、测试优先级等等。

如上图所示，由于缺陷的群集效应，相比基于规格说明的测试，RBT试图通过精准的风险识别来达到更高效的测试。

基于风险的测试不再是强迫所有人依靠例如缺陷数和测试数等不充足的策略性度量来做发布决定，而是和利益相关者一起来做决定剩余风险的可接受级别，从而做出合理的发布决定。

三.如何进行RBT

我们这里说的RBT，是一个广义上的测试，并不仅仅是软件项目测试执行阶段。软件项目测试人员所介入的诸如需求澄清、方案讨论、测试分析等等一切活动都是属于测试活动，也都是进行RBT的时机。

• 通常来说RBT分如下为三步骤：
  GB_T_20918-2007中定义了一套很严格的风险管理规范，在时机软件上可能并不需要达到如此的规范程度，但基本的：风险识别、风险分析、风险控制 过程还是需要有的

3.1风险识别

3.1.1风险识别的手段

风险识别可以采取如下正式或非正式的手段：
1>专家咨询。2>独立评估。3>使用风险模板。4>项目回顾。5>风险研讨会及头脑风暴。6>检查清单。7>问卷调查 8>以往的经验。

本文不是软件测试教材，此处不详细展开

3.1.2风险识别中应该考虑的关注点：

技术因素：

• 技术和团队的复杂度。
• 个人和培训问题。
• 团队内部与团队间的沟通冲突。
• 供应商和客户的合同问题。
• 开发组织的地理分布以及外包。
• 管理上或技术上较差的领导力。
• 时间、资源和管理压力。
• 软件生命周期早期未引入测试和质量保证活动。
• 项目中需求、设计和代码的频繁变更。

也就是从研发项目交付的整体上考虑技术和管理上考虑方方面面的问题。

商业因素:

• 受影响部分的使用频率和重要性。
• 潜在的形象损害。
• 客户和商业损失。
• 潜在的金融、生态或社会方面的损失或法律责任。
• 民事或刑事制裁。

站在用户的角度，从行业、从盈利模式、合规等方面考虑方方面面的问题。

3.1.3风险识别的两个方