测试管理 - 基于产品风险的测试策略

对于测试工程师而言，随着在这个行业的深耕，逐渐会接触到一些项目层次的理念和方法论。

风险分析以及风险管理就是其中重要的一项。

风险管理与质量控制实际存在着非常大的关联关系，也是管理测试的有效理念。

 

 

 

 

1. 什么是风险

在项目管理的领域内，风险被定义为：某一事件发生给项目目标带来不利影响的可能性。

 

在开发新的软件系统过程中，由于存在许多不确定因素，软件开发失败的风险是客观存在的。因此，风险分析对于软件项目管理是决定性的。风险管理是项目管理团队的重要职责，也是促使项目成功的有效办法，测试管理人员以及整个测试团队在这个过程当中要起到非常重要的作用。

风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括：风险识别、风险评估、风险策略、风险解决和风险监督等。

对大多数软件研发组织和项目而言，当谈及风险的时候，一般分为两个方面：

• 项目风险（过程风险）
• 产品风险（质量风险）

我们首先要将这两个概念区分开来，因为测试团队在这两项风险管理过程中的任务可能是截然不同的。

 

1.1 项目风险

项目风险或者叫“过程风险”是围绕项目按目标交付的能力的一系列风险，比如来自组织方面，人员管理方面，流程方面和其他方面的风险。

 

 

我们只对测试工程中常见的风险做一个大致罗列，如：

• 技能、培训和人员不足；
• 项目团队成员出现的个人问题，人员流失；
• 组织内部协作不调，缺乏有效的沟通渠道；
• 管理流程缺乏组织，测试工作的支撑和依赖无法得到满足；
• 项目成员尤其是管理人员可能对测试团队抱有错误的态度和认知；
• 有效的测试方法（比如静态测试）不受重视；
• 技术支持的缺乏导致的测试技术问题；
• 测试时间受到压缩；
• 交付的代码质量低下，加重测试以及返工任务量；
• 产品的缺失配置管理，变更流程等控制手段；
• 离岸团队的合作效率问题；
• 第三方支持的问题；

以上都是可能影响到测试任务完成的常见项目风险，管理人员需要在计划阶段对风险进行预估，并给出规避方案和应急措施。

 

1.2. 产品风险

产品风险又称为“质量风险”，用通俗的话讲即为：“产品交付之后可能带有的质量问题”。

为什么我们研发的软件产品会有风险存在呢？问这个问题实际就等同于问“为什么软件产品可能会有缺陷呢”？

其实其本质在于“人都是会犯错误的”这样一个论断的成立。

基于这个论断我们又可以推论出：“因为人都会犯错误，所以人开发出来的软件也就可能带有错误”。

这些在研发过程中我们犯的错误，遗留在产品中，就是缺陷；缺陷存在的可能性，就是产品风险。

产品风险产生的原因，可能有以下这些：

1. 产品大小/代码量：工作量越大，那么我们就越有可能犯错。
2. 技术因素：未曾使用过的新技术都存在风险。包括未使用过的新型硬件、支持软件，缺乏标准与规范的非传统的开发方法等。技术过时也是风险。
3. 开发环境：适用的开发工具不足、不可靠、使用不方便等因素，都会降低开发效率。
4. 组织规模和人员经验：比如人手不足，人员经验不丰富，都有可能带来产品风险。
5. 客户因素：表现在客户需求经常矛盾，不了解客户的特殊需要，客户不了解项目中采用的新技术，且双方又难于沟通等。

在软件研发领域，通过测试过程发现并且解决问题，实际就是产品风险的最重要和直接的规避手段。

换言之，软件测试就是产品风险管理的重要手段，也即产品风险控制的有效办法，甚至有些组织会将软件测试从组织架构上纳入风险管控部门。

常见的软件产品风险有如下类型：

• 软件的故障频发；
• 软件/硬件对个人或公司造成损害；
• 软件特性低劣，比如性能低下；
• 数据完整性不足；
• 既定的功能未被完全满足；

等等。可以看到，以上的软件产品风险，我们软件测试的活动和任务都有可能对他们进行评估，并且通过信息收集和事件报告等手段实现规避和控制的目的。

 

2. 项目风险管理

风险管理一般通过下面四个阶段来完成：

1. 风险识别
2. 风险评估
3. 风险缓解
4. 风险监控

 在进行风险管理的过程中，要把握好四个原则：

• 可避免的风险，采取好的过程管理和流程控制来应对；
• 不可避免的风险，采取降低和转移的措施；
• 做好风险管理计划；
• 做好应急方案；

 

我们列举一下测试过程中可能存在的风险和对应的可行举措：

对于测试过程风险：

• 需求的计划外变更
  • 做好变更控制和配置管理
  • 为可能的变更预留时间和人员的调整空间
• 测试用例执行率不足
  • 日常跟踪所有工作过程，及时发现阻碍测试执行的因素并协调解决
• 测试分析产生偏差
  • 更完善的测试分析流程，对于经验不足的人员安排指导
  • 用评审的手段予以检查
• 测试用例设计不足
  • 更完善的测试分析流程
  • 充足的人员技能培训和指导
  • 用例评审的把关
测试与生产环境差异
• 尽量缩小测试环境与生产环境的差异，比如使用更大的数据量
• 更强的客户响应以确定用户生产环境的特性
• 偶现类问题
  • 倡议充分的问题记录和分析流程
• 代码质量过低
  • 更好的单元测试实行
  • 倡议和建立规范的提测控制流程
• 回归测试覆盖率不足
  • 适合的回归测试策略
  • 自动化的回归测试覆盖

 

对于人员风险：

• 人员流失
  • 积极响应人员诉求
  • 创造更积极的工作流程及环境
  • 做好人员技能储备
• 人员不可用状态（休假等）
  • 建立良好的文档归档流程
  • 建立完善的工作后备机制（不可让某项工作只有某一个人能完成）
  • 协调完备的人员抽调机制
• 新人工作准备
  • 建立良好的人员培训机制
  • 建立帮助新人融入的导师机制
• 外包人员管理
  • 控制项目团队中外包或兼职人员的比例
  • 与外包人员保持足够的沟通和把控
  • 与外包公司保持足够的管理联系

 

可以看到这部分项目风险预估和应对的内容，更多的出现在测试计划以及一些项目筹划会议上，应划归为项目管理范畴。

 

3. 基于风险的测试

上文提到，项目风险需要通过管理手段和策略来缓解规避。

那么产品风险呢？长话短说：测试（质量控制）就是降低产品风险的行之有效的手段。

 

 

正因为如此，所以以风险为基准来制定的策略是测试领域内非常重要也非常普及的一种方法。

这就是所谓的基于风险的测试（Risk Based Test - RBT）。

常见的测试策略可能有：

• 分析型策略
• 基于模型的策略（如：基于运行概况分析的测试） ·
• 符合过程或标准的策略（如符合OWASP标准的web安全测试）
• 应对型策略（如：探索性测试）
• 咨询式策略（如：外部机构测试）
• 面向回归测试策略（如：自动化回归测试）

而基于风险的测试就是典型的分析性策略。

正如我们前文中提到的项目风险和产品风险的区别，基于风险的测试是基于“产品”风险而非项目风险。通过对于产品不同区域和特性可能遗留缺陷，以及其影响程度的分析，确定测试的资源分配等问题。

基于风险的测试策略之所以有很大的应用价值，是基于以下几个基本论断：

1. 事有轻重缓急，对于测试工程而言，并非所有被测对象和模块都具有同等的重要程度。
2. 测试不可穷尽，测试成本和错误成本处在天平两端，用更少的资源和成本覆盖更多更重要的测试目标是测试管理的重要诉求。
3. 缺陷具有集群性，经验而论，对于缺陷集中的模块投入更多的测试关注度和资源可以最有效的发现最多的缺陷，从而带来质量的快速提升。

 

 

下面我们通过一个简化版的RBT实例来论述其组织实施过程。

某税务处理系统

• 该项目为一个COTS产品的定制性二次开发项目
• 项目周期计划为4个月
• 采用持续集成，高速迭代的研发方式

①风险识别：识别出软件研发过程中，可能产生缺陷的区域，包括功能模块和专项问题，罗列如下：

这个风险识别的过程，可以依靠专家的分析，比如测试经理和开发组长、项目经理等的讨论，但是更多的情况下应该依靠集体智慧，条件允许的话项目所有利益相关方，都应该参与到风险分析的过程中来。在风险识别这个动作上，头脑风暴是一种可行的方法（即与会各方各抒己见，提出自己认为产品可能有的风险项）。

除了头脑风暴法以外，更为严格的风险研讨会议，经验总结会议，第三方独立评估，问卷调查法都是可以使用的风险识别方法。不同的人员处在不同角度和专业背景下，对于风险的识别和分析等可以提供更全面专业的思路。

 

②风险评估：在风险评估过程中，我们要对上个阶段列出的风险项目做出评估，得出风险高低大小的一个排序。

风险评估中需要考虑的两个维度：风险发生的可能性大小，以及风险如果发生，带来的影响范围和严重程度。两个维度结合起来，才最终定义一个风险项目的级别高低。

因此，首先需要确定我们对于这两个维度以及风险级别之间的判别关系，采用风险定义矩阵是一个比较好的做法，比如采用如下风险分析矩阵：

 

将识别阶段得出的风险项目列表进行两个维度的风险判断，得出如下结果：每一个风险项都从两个维度给他’高、中、低‘的判断，得出下表：

 

 

按照风险分析矩阵，进一步整理：

 

  

到此为止我们已经得到了风险评估结果列表，可以使用风险追踪表格管理起来。

在这个评估过程中，只是使用简单的高中低三个级别的划分对于风险进行评估。如果需要更为精细的评估，也可以采用更为细致的评分方式，并且对于风险的发生概率和影响度可以分开进行更为严格的评估，比如使用下表进行的发生概率分析：

 

 

 同理对于另外的影响范围和严重程度，也可以做出类似的分析评估。

最后使用（可能性X影响）的公式得出风险项目的最终级别。

 

③风险缓解

基于产品风险分析，测试管理人员可以在测试活动的安排上，实施缓解措施：

确定测试优先级

根据测试风险的分析和评估得到的风险分布，确定测试的优先级。如上例中，将风险级别最高的三个项目定位最高优先级，优先进行测试分析、设计和执行。其他项以此类推。

确定测试完备性

前面提到的一个假设条件：并不是所有的测试对项目而言是同等重要的。同样的道理，并不需要对测试对象的不同内容进行同等重要的测试，最重要或者风险最大的模块或者对象需要测试得更加彻底，更加完备。而对于风险比较小、优先级低的模块或对象，可以简单测试。对于优先级最低的对象，在时间和成本等不允许的时候，甚至不进行测试。

为达到更高的完备度，可以采用更为严格的测试分析、设计，更为全面的执行和测试覆盖。

测试资源优化分配

根据测试风险的分析和测试优先级的评估，将经验丰富和技术能力丰富的测试人员（不管是设计人员、实现人员，还是执行人员）放在最重要的模块或测试对象中，可以达到如下效果：

• 设计更加完善、完备和准确的测试用例。
• 实现高质量的测试用例脚本和代码。
• 更加高效地发现测试对象中的缺陷。

这种基于风险的测试策略可以非常有效的帮助测试团队快速实现重要模块的测试覆盖，并且可以有效的快速提升产品质量，进而带来利益相关方的信心提升。同时，对于测试监控而言也是非常有帮助的。

 

④风险追踪

风险分析不是一个一次性的工作，需要持续追踪。通过在项目实际研发过程中得到的信息和反馈，对风险等级进行调整，比如调高和调低风险等级。

一个实际的例子是：当项目开始时，将某一个风险项目定为了高级，因此这个风险项很有可能引起了团队的重视。而正因为团队对这个风险项目很重视，以至于在后续工作开展过程中，团队投入了更多的资源和力量，导致最终测试阶段可能反而在这个模块里面没有发现太多问题，也即他真正展示出来的风险等级并没有预计的那么高。当发现这样的现象时，应该对风险跟踪表做出及时更新。

风险级别的更新可以是即时的，即发现现象则对应更改；也可以是阶段性的，比如每周一次，对于风险项目进行更新和调整。

风险级别一旦发生调整，测试活动的安排也应随之相应调整。

 

4. 总结

风险的控制，在企业生产和管理中是被广为接受和采纳的理念。

对于软件产业而言，产品质量风险的缓解很大程度依赖于测试工作所提供的质量控制（QC）。

也许并不是所有测试人员都会采用如本文所述的精益化的风险管理过程，但不管是对于测试管理人员还是测试技术人员而言，风险的观念都是不可或缺的。

不论采用怎样的测试过程，都应采用风险管控理解来编排工作，抓住重心，这样才能将有限的（有时非常有限！）测试时间合理投入到无限的任务中去。