基于风险的测试学习总结

一.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风险识别的两个方向：

风险识别可以分为如下两个方向：INSIDE-OUT、OUTSIDE-IN:

INSIDE-OUT:
INSIDE-OUT的基本思路是从具体分析测试对象的详细信息和背景信息入手，识别与之相关的风险。采用该方法，测试人员在学习测试对象时需要不断地提出这样的问题“这里可能会存在什么样的风险”。更加正确地说，针对测试对象的每个部分，测试人员需要回答下面3个问题。

• 弱点Vulnerabilities：测试对象有何种弱点或者可能的失效？
• 原由Treats：测试对象在何种输入或者情况下会导致出现缺陷和弱点，并且触发测试对象出现失效？
• 影响者Victims：弱点或者失效的影响对象是谁？其影响程度有多大？

INSIDE-OUT分析方法需要测试人员深入了解测试对象。其常用过程可以是在带有黑板/白板的会议室中测试人员询问开发人员相关的问题（如这个功能是如何实现的？）；开发人员在黑板/白板上画出相应的原理图，并讲解测试对象的内部工作过程；同时测试人员在开发人员画原理图时，快速地思考一些问题。测试人员和开发人员之间可以很快的在测试对象工作原理方面有相当的认同。在测试人员存在疑虑或者不清楚时可以立即询问开发人员。在了解测试对象的工作原理之后，测试人员即可开始查找其中的弱点或者可能的失效。

OUSIDE-IN:
OUSIDE-IN，目前的理解更多是更多的是通过一些预先制定的 Check-list、启发、规范对于被测系统进行Check，从而发现被测系统存在的一些风险。例如:

• ISO9126中定义的常见风险列表
• 质量特性列表
• 通用风险列表
• 领域风险列表

3.1.4全流程的风险识别：

从研发全流程的角度考虑风险，我们可以有如下启发：
需求：

• 产品的业务需求、用户需求、功能需求和系统需求是否完整、清晰？
• 仅仅是用户提出的不成熟的解决方案当需求？还是能解决用户深层次痛点的需求？甚至是满足用户人性层面的诉求？
• 开发人员在进行产品设计之前是否充分理解了需求。

设计：

• 是否为规模庞大、复杂以及难以理解的对象？
• 是否使用了新技术？是否为新的团队？没有任何经验可以借鉴？
• 功能与非功能性的设计是否都有充分考虑？性能？可靠性？精度？
• 开发人员在设计中是否存在一些比较担忧的地方？是否有一些设计瓶颈？
• 开发人员是否能够自己讲的清楚设计？
• 项目对依赖和约束是否有充分考虑？（合规、不同团队的进度）

流程：

• 项目是否使用了新的流程、开发方法等？
• 开发人员是否会自测？是如何自测的？测试的深度和发现的问题如何？
• 开发人员如何进行代码修改，是如何保证修改正确性的？
• 开发人员如何进行版本管理？

变更：

• 新版本在旧功能方面做了哪些修改？修改后的主要影响是什么？
• 在项目过程中需求是否总在变化？

组织和人：

• 异地开发带来的沟通协作、进度问题、不同的开发流程、能力?
• 人力，团队稳定性。
• 环境和资源是否具备和充足。

历史：

• 基于缺陷群集效应和杀虫剂效应。分析历史缺陷，从而得到更多的Idea。

3.2风险分析

3.2.1风险分级

风险主要从可能性和严重程度两个维度考虑它的分级:

风险的级别 = 风险的可能性 * 风险的影响（严重程度）

• 风险的可能性：测试对象中存在潜在问题的可能性。
• 风险的影响（严重程度）：风险发生后，对用户、客户或其他利益相关者影响的严重性。

风险级别的判定：

3.2.2基于风险分级的测试安排

不难看出，其实基本思路就是根据风险级别的高低给予不同测试资源和人力的分配。高风险的问题将获得更多资源和人力的关注。

风险覆盖策略：

• 广度覆盖： 按一定权值同时对高风险和低风险的问题安排测试。
• 深度覆盖： 严格按照优先级进行测试工作安排。

3.3风险控制

在风险管理中，风险应对主要分为如下四种：

• 风险回避：指主动避开损失发生的可能性。
• 转移风险：通过某种安排，将自己面临的风险全部或部分转给其他一方。
• 减轻风险：指采取措施，降低风险发生的可能性或影响。
• 接受风险：指自己理性或非理性的承担风险。

不同的风险控制策略正体现了RBT的价值，项目的资源总是有限的很难奢望真正0缺陷的产品。风险回避、风险接受也是常常需要面对的一种策略。

3.3.1风险记录与跟踪

前面总结了风险的两个维度；风险的分级；基于风险分级的测试安排。那么当我们发现和识别风险后，还需要对风险进行记录和跟踪，这样才能保证风险控制能够落地。那么风险的记录可以采用如下的表格进行记录：

风险类别：
可以是 产品风险、项目风险。如果是产品风险，可以进一步说明是 功能、可用性、性能、可靠性等。

可能性、影响、风险级别
与上文 风险分析 中介绍的概念相同。

测试安排：
可以使用 风险分析中 基于风险级别的测试安排。也可以针对风险制定探索性测试章程，将章程的描述或编号维护在这个之中。

追踪：
描述风险当前的状态。“新建”、“已转移”、“已接受”、“已爆发”（已在商用中爆发问题）、“已减轻”、“减轻中”。

个人觉得重点在于风险的跟踪。我们在记录风险后需要定期的与项目干系人讨论风险的控制策略，并力求得到项目干系人的支持。安排落实计划（测试探索计划、开发计划等）。风险跟踪的活动中要求测试人员能够转型，主动承担起更重要的职责，而不仅仅是作为研发最后一个环境的 Checker。

3.3.2风险减轻

四种风险控制策略，在这里我们重点风险减轻的方法。

作为测试人员，最直接的风险减轻的方法就是通过测试 反馈缺陷，并跟踪缺陷。但在RBT理念里面，系统测试人员能够做的更多，以下是从全流程的角度，总结的部分风险减轻的方法：

3.3.2.1需求类风险

1>需求描述不清，不能有效指导开发和测试的工作：
加强需求场景的评审，在需求澄清中加强对于场景疑问的沟通，确保对于需求理解的一致性。

2>开发人员在设计时没有充分理解需求,特别是易用性和性能方面：
a.测试人员提早开展性能相关的测试探索。（很多性能问题由于早期就已经定型的架构问题）
b.在需求澄清中要明确性能规格。
c.编写实例化验收测试用例，并确保能够被正确实现。评审验收测试用例。

3.3.2.2设计类风险

使用了新的技术平台

a.新旧平台对比寻找差异性、变化点。
b.针对变化点、差异点可能引入的问题进行针对性的探索。

设计过于复杂，难以理解

a.与需求工程师进行确认，确认是否存在过度设计。
b.要求开发人员进行方案的讲解和梳理。

3.3.2.3流程类风险

1>开发自测不充分：
a.通过测试分层的方式与开发约定好测试分工。（重复覆盖，重复视角引起的效率浪费）
c.与开发沟通开发已测试部分，有针对性的进行补位。
d.为开发的自测活动提供测试环境框架 或测试设计技术指导 。

3.3.2.4变更类风险

在项目过程中，需求总是在增加

a.和开发人员、需求工程师进行沟通，进行需求控制。
b.裁剪部分低优先级需求。

3.3.2.5组织和人风险

团队大部分人员没有测试设计经验

a.好的测试设计案例学习。
b.带领团队做好测试分析、加强评审。

测试工具不满足：

a.测试工具采购及进度跟踪。
b.积极寻找替代工具。

3.3.2.6历史类风险

特性在基线版本中就存在很多bug

对基线版本该特性进行缺陷分析、分析哪些测试手段容易发现该特性的问题，据此进行探索性测试。

基线版本中开发人员修改引入缺陷导致缺陷趋势无法收敛，对测试进度和产品发布造成了影响

在继承版本中，很可能会存在同样的风险。对基线版本中开发人员修改引入的缺陷问题进行根因分析，针对根因来制定措施。

四. 基于风险测试的挑战：

4.1测试策略的动态变化：

“基于规格说明”、“基于风险的测试”都有其存在的价值，不是谁替代谁的关系。“倒浴盆曲线”，给我们的启示是，测试策略一定是随着项目处于不同阶段和不断调整的。一定要在关键的项目里程碑的时候重新调整风险分析、测试和项目。

4.2风险级别认识的一致性：

项目中不同人、不同视角、不同知识背景甚至利益关系导致会对同一个风险的认知程度不一样，但一个RBT的跟踪和落地很多时候需要项目干系人的意见达成一致。这就是非常大的挑战，通常可以：

• 影响力、行政权力。（不可频繁使用）
• 在其他风险级别上做出调整，让所有风险的级别在整体上符合双方的要求。（妥协和退让、相互理解）
• 把不一致的问题上报到一些资深的项目利益相关者那里。

4.3如何让人们对于风险做出理智的决定（风险评价的客观性）。

—风险带来的恐惧感觉会提升风险感的知级别。

4.4所有风险都是高优先级？

相对于第一点，有时候大家很容易达成风险认识的一致性，即所有风险都是高优先级。那么此时风险优先级评估将没有意义。可能从整个项目的成本、进度、预算的层面进行取舍。

五.业界专家对于实施RBT的忠告：

以下内容来源于 “海盗派Tester” 微信群中关于RBT的讨论:

群中有包含 邰晓梅、刘琛梅、高翔、Michael Bolton等众多国内外测试专家…

5.1 RBT应该是持续性的，而不是一次性的。

项目持续在演进，那么风险是持续存在的。RBT不能仅仅做成一种Show，一种临时性的活动。应该持续的去做。

5.2 RBT应该更注重内容，而不是形式。

1> RBT过程中，应该重视的风险识别、分析和跟踪的过程。虽然有些CheckList、风险记录表、质量特性列表…等文档化的东西，但应该已实用便捷为主。

2> RBT应该是持续化的工作，那么频繁化正式化的会议、评审可能会成为项目不能承受之痛。应该多转化为非正式的，频繁的的沟通和交流。

5.3 RBT也应该快速迭代和反馈。

注意RBT的粒度，不要奢求一次性做大而全的风险识别，风险分析等活动。应该秉承敏捷思想，缩小RBT的范围，并频繁反馈，频繁的去更新对于当前项目风险的认识。

5.4 RBT应该内化为日常测试工作中的一种习惯。