风险处理——老生长谈？

　　在20世纪50年代，当数学家David van Dantzig 在防卫洪水的领域作出先锋性工作的时候，风险分析和风险处理就已经被应用在工程上了。自那以后，风险处理的意识在不同的工程领域得到发展和传播。在软件测试领域，风险处理最早的应用之一是Boris Beizer在他的传奇著作——软件测试技术里著述到，测试时需要考虑到风险。

　　James Bach 在1995年以更时髦的方式第一次介绍了基于风险的测试（RBT），然后在1999年在一篇叫做《启发式基于风险的测试》（“Heuristic Risk-based Testing”，译者注）中得到更详细的描述：

　　1. 列出一个风险的列表

　　2. 进行考察每项风险的测试

　　3. 当风险消失而新的风险出现的时候，调整测试策略

　　自那以后，RBT得到了广泛的关注，ISTQB在他们针对基础级别和进阶级别的测试认证中，将RBT认定为一种重要的测试方式。

　　应用RBT的实践

　　尽管RBT作为一个重要的测试方式得到广泛认同，但对于如何在实践中实际地应用RBT还存在不少混淆。大多数我研究的组织都非正式的在测试中考虑到了风险，但很少有组织具有正式描述的、系统化的方式把风险纳入到他们的测试中。

　　当然，一些采用RBT的障碍源自于通常的拥抱变化的困难。在这方面采用RBT与采用任何其他的变化没有分别。另一方面，更进一步澄清如何在一个实际的环境中应用RBT的工作也是需要的。许多关于RBT的报告描述了RBT的理论框架而没有告诉读者实际的实现细节。具体的说，这关系到以下一些问题：

　　1. 如何识别风险

　　2. 如何评估识别出的风险

　　3. 如何确定合理的减轻风险的活动

　　在一个试验性的研究中（此研究在一个大型的工业化的软件生产商那里进行），一个目标之一是引入RBT，完成一个易于使用的指导方针。以下的段落总结了这个试验性研究一些关键经验，集中在上面提到的几点问题上。

　　风险识别

　　RBT第一个步骤的目标，是发现尽可能多的风险，以力求使得所有重要的风险都在已识别的风险当中。具体的说，风险识别的建议包括头脑风暴会议，和专家的讨论，以及检查表等。所有这些指导方针都很有用很重要。然而，在一个组织中第一次引入基于风险的测试的时候，过去的识别风险的经验通常很少，因此会存在问题，因为所有提及的技术或多或少的依赖于经验。

　　为了克服缺乏经验的问题，我们基于现有的一组High Level需求创建了一个起始点。每一个需求通过以下面的方式转述从而转化成一个风险项：如果这个需求的实现存在一个缺陷那会怎样？

　　结果起始点包含了一组相当多的风险项。然后我们让参与RBT的成员们在想起一个新风险项的时候就把它加进来。我们在后面的段落会更详细的介绍，这些被识别出的风险通过会议的方式得到指导。这个会议在另一方面也促使新风险更快的被识别。如上所述的使用起始点的方法是独立于其它风险识别的方法的，所以当团队的经验增长了之后，可以加入任何其他的方法。

　　风险评估

　　通常，风险是以二维的可能性-结果的形式表述的，这需要对每一个风险项进行度量和评估。然后，或者通过倍乘这两个维度的值从而得出一个单一指标来得出每一个风险项的重要性，或者通过使用一个二维坐标系统来表征每一个风险项的重要性，这个坐标系统里的面积对应了不同水平的重要性。

　　对于参与RBT的不太有经验的成员来说，评估可能性-结果的过程可能很抽象和困难。为了使这个任务更加具体，我们把每个维度划分为一组单独的属性。与可能性相关的属性的例子有：

• 使用频度
• 使用复杂度
• 实现复杂度

　　相对应的，与风险的结果相关的属性的例子有：

• 用户结果
• 业务结果
• 测试组织的结果

　　在我们的例子中，为了达到对于一组风险的普遍认识，我们把所有的项目干系人召集在一个会议里来一起评定风险的维度。在这个会议里，要求每个RBT的参与者对每个风险项的每个属性进行打分，用1~4来标示。通过这样的使用属性，描述一个特定值实际是什么意思就容易了。例如，在我们的例子里，使用频度“1”对应了少于每周一次的使用，“2”对应了每周一次，“3”是每天一次而“4”是一天若干次。这样清晰的描述使得评级更为有效。

　　然后风险的得分被赋予权重，从而得出这两个抽象维度——可能性和结果的指标，基于这些值，也计算尺每个风险项的单一风险指标。

　　单一风险指标方式的一个缺点是，在某一个维度上比较低的风险可能不能引起足够的注意。一个明显的例子是核熔解相关的风险。尽管风险的结果是异常巨大的，但是非常低的可能性使得最终的风险指标相对很低。为了克服这个障碍，我们采用的方式是通过最终的风险指标以及两个单一维度值来判断重要性。最终的风险等级是这三个值中的最大值。

　　减轻风险

　　RBT的最后一个步骤是基于风险的等级，用一组适合的测试用例来覆盖每一个风险项。为了帮助不太有经验的测试人员，我们给出了一组指导性方针。例如，每一个高风险必须被正向测试用例及负向测试用例所覆盖。另外，至少50%与高风险相关的测试用例应该具有最高等级的测试用例优先级。中间等级的风险主要由正向测试用例覆盖，并且可以分布于最高的三个测试用例优先级中，等等。

　　结论

　　针对我们这个试验性的项目的一个关键要点是，一组关于如何在实践中使用RBT的指导方针可以大大地减少采用一个更为结构化的方式来在测试中使用风险的障碍。这一点会在我的Eurostar的演讲中得到进一步的阐述。斯德哥尔摩见！