基于风险的测试学习总结

基于风险的测试学习总结

• 一.RBT的概念
• 二.什么是风险，为什么需要RBT
• • 2.1什么是风险
  • 2.2为什么需要RBT
• 三.如何进行RBT
• • 3.1风险识别
  • • 3.1.1风险识别的手段
    • 3.1.2风险识别中应该考虑的关注点：
    • 3.1.3风险识别的两个方向：
    • 3.1.4全流程的风险识别：
  • 3.2风险分析
  • • 3.2.1风险分级
    • 3.2.2基于风险分级的测试安排
  • 3.3风险控制
  • • 3.3.1风险记录与跟踪
    • 3.3.2风险减轻
    • • 3.3.2.1需求类风险
      • 3.3.2.2设计类风险
      • 3.3.2.3流程类风险
      • 3.3.2.4变更类风险
      • 3.3.2.5组织和人风险
      • 3.3.2.6历史类风险
• 四. 基于风险测试的挑战：
• • 4.1测试策略的动态变化：
  • 4.2风险级别认识的一致性：
  • 4.3如何让人们对于风险做出理智的决定（风险评价的客观性）。
  • 4.4所有风险都是高优先级/li>
• 五.业界专家对于实施RBT的忠告：
• • 5.1 RBT应该是持续性的，而不是一次性的。
  • 5.2 RBT应该更注重内容，而不是形式。
  • 5.3 RBT也应该快速迭代和反馈。
  • 5.4 RBT应该内化为日常测试工作中的一种习惯。

一.RBT的概念

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

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

2.1什么是风险

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

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

2.2为什么需要RBT

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

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

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

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

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

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所有风险都是高优先级/h2>

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

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

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

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

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

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

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

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

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

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

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