3.2.2 风险
风险无处不在一在家里、 路上、办公室。我们所做的任何一件事情都有风险相伴，软件交付也不例外。我们购买更安全的汽车、使用防御性驾驶(defensive driving)方法可以降低驾驶的风险。在单位，我们在会议中小心说话，在选择项目时考虑技能的匹配程度，以便减少失业的风险。如何降低软件交付的风险呢?如何应对软件发生故障，并给公司声誉带来难以估量的伤害这一极大可 能事件呢?毕竟，没有完美的软件。
显然，不交付软件不是一条可选之策。尽管这是一种完全消除了故障风险的方法，而.且公司是从可以掌控的风险中盈利的。
注意我们并没有说“准确量化的”风险。至少就我们的目的而言，风险没有数学上的精度要求。我们行走在人行道上而不是大街中央，并不是因为有什么公式计算出59%的风险降低，而只是凭借一个常识: 对行人来说，大街中央不是一个安全的地方。我们购买带安全气囊的汽车，并不是因为我们理解提高事故幸存概率的数学知识，而是因为安全气囊显然可以降低脸被方向盘撞烂的风险。无需太高的精度，风险缓解即可以发挥强大的作用。确定风险的过程称为风险分析。
1.风险分析
在软件测试中，我们按照-一个常识性的过程来理解风险，下面是一些可供参考的因素。
●哪些事件需要担心?
●这些事件发生的可能性有多大?
●一旦发生，对公司产生多大影响?
●一旦发生，对客户产生多大影响?
●产品具备什么缓解措施?
●这些缓解措施有多大可能会失败?
●处理这些失败的成本有哪些?
●恢复过程有多困难?
●事件是一次性问题，还是会再次发生?
影响风险的因素很多，试图精确地、定量地计算风险比缓解风险还要麻烦。在Google,我们确定了两个要素:失败频率(frequency of failure)和影响(impact)。 测试人员用这两个要素给每项能力打分。我们发现，风险实际上是一个定性的相对值，而非一个定量的绝对值。风险分析的目标不是要给出一个精确的值，而是要识别一个能力与另一个相比风险是大是小。这对于决定以何种顺序测试哪些能力足够了。GTA提供了这一选项，如图3.8所示。
GTA中的风险发生频率有4个预定义值。
●罕见(rarely):发生故障的可能性很小，发生问题后的恢复也很容易。
➢示例: Chrome 的下载页面(http://www.google.com/chrome)。 绝大部分内容是静态的，可以自动检测客户端OS。即使页面的核心HTML或脚本发生了崩溃，也很容易通过监视代码发现。
●少见(seldom): 在少数情况下会发生故障，但是在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小。
➢示例: Chrome的Forward 按钮。这个按钮使用的频率远小于Back按钮。从历史记录看，它很少出问题，即使发生了，我们也可以指望早期发布通道上的早期用户会很快的注意到，因为这会是相当明显的。
●偶尔(occasionally): 故障的情形容易想象、场景有点复杂，而该能力是比较常用的。
➢示例: Chrome 的Sync功能。Chrome 会在不同客户端之间同步书签、主题、表单填写、历史和其他用户资料数据，涉及不同的数据类型及多个OS平台，而且变更合并(merging changes)是一个多少有些复杂的计算机科学问题。用户也会注意到数据是否同步成功。同步只会在数据变化时发生，例如当加入一个新书签时。
●常见(often): 此能力所属的特性使用量大、复杂度高、问题频发。
➢示例:Web页面的渲染。这是浏览器的最主要用例。渲染各种来源和质量的HTML、CSS和JavaScript代码是浏览器的基本任务。这些代码的问题会被用户归咎到浏览器。对一个高流量的网站来说，发生问题的风险更大。渲染问题未必总能被用户发现。它们经常导致页面元素不能完全对齐但不会影响功能的正常使用，或者元素没有显示出来但用户可能不会注意到。
测试人员确定每个能力的故障发生频率。我们有意使用偶数值，以免测试人员偷懶使用中间值。在输入时应该认真的想一想。
估计风险影响的方法大致相同，也是从几种偶数取值中选择一个( 更多来自Chrome浏览器的例子)。
●最小(minimal):用户甚至不会注意到的问题。
➢示例: Chrome 实验室是一个可选功能，不能加载“chrome://abs"页面只影响到极少的用户。因为该页面包含可选的Chrome 实验特性，大多数用户甚至不知道它们的存在。这些特性本身也注明了“自担风险”，不会危及核心浏览器。
●一些(some):可能会打扰到用户的问题。一旦发生，重试或恢复机制即可解决问题。
➢示例:refresh按钮。如果当前页面刷新失败，用户就可以在原来的标签页里重新输入URL,或者在一个新的标签页里打开，甚至在极端情形下重启浏览器。故障的代价很低，用户只是稍感烦扰。
●较大(considerable): 故障导致使用受阻。
➢示例:Chrome扩展。如果用户安装了Chrome扩展来增加功能，而这些扩展在新的Chrome版本中加载失败，那么它们的功能也就丢失了。
●最大(maximal):发生的故障会永久性的损害产品的声誉，并导致用户不再使用它。
➢示例: Chrome的自动更新机制。该特性一旦失败， 就会导致关键性的安全升级无法进行，甚至使整个浏览器停止工作。
有时问题对公司和用户产生的影响是不一致的。 例如，公司标志加载失败对于Google是一个问题，但却未必会被用户注意到。在打分的时候注意一下所考虑的风险是针对公司的还是用户的，是非常有用的。
对Google Sites,基于测试人员的输入以及之前给出的特质一组件表，我们可以生成一个风险区域的热图，如图3.9所示。
表中的单元格以红色、黄色或绿色高亮显示，分别表示相应组件在各交叉点的风险级别。风险级别是你已经输入的值的一个 简单计算——每个能力的风险的简单平均。GTA自动生成了这个热图，但电子表格也可以做到。
此图代表了该产品可测试的能力及其风险，这些数字难免有一些偏见，因为它们只代表了测试人员的理解。我们还应该努力听取其他相关人员的意见。下面是一个相关人员的列表以及邀请他们一起来估计风险的一些建议 。
●开发人员:大多数开发人员在被征求意见的时候，都会给自己负责的特性选择最大的风险，因为他们希望自己写的代码得到充分的测试。经验表明，开发人员对自己负责的特性的风险估计过高。
●项目经理: PM也是常人，也会有自己的偏见。在对能力点重要性的评判上，他们当然有自己的偏好。通常来说，他们喜欢那些使得软件能从竞争产品中脱颖而出引人注目的特性。
●销售人员:销售岗位本来就是要吸引用户的，因此他们会对那些有卖点、演示起来很拉风的特性更感兴趣。
●总监和VP:管理层经常会更加注意那些使软件有别于主要竞争对手产品的特性。
显然，所有利益相关人员都有明显的偏好，因此我们的办法就是征求所有人的意见，请大家各自给前面所述的两项指标打分。并不总是轻而易举地就能吸引大家的参与，不过我们发现了一个成功的策略。我们并不需要跟他们解释这个流程然后说服他们来帮忙，只要自己完成然后把热图展示给他们就行了。一旦他们发现其中的偏差，自然就会提出自己的意见。开发人员知道这个热图会被用来决定测试的优先级，因此参与度很高;项目经理和销售人员也是一样，质量对大家都很重要。
这个方法很给力。我们自己确定风险所得到的结论，毫无疑问会被质疑。在将风险分析结果作为随后测试的依据展示给大家的时候，我们实际上是树了一个靶子供大家争论。这就是重点:与其询问他们关于某个模糊概念的看法，不如拿一个明确的结论来引起辩论。通常来说，都是排除容易下定义难。除此之外，我们还会避免让每一个人都去查看他们其实不感兴趣或不理解的数据。这个小策略使得我们通常能得到大量有效的输入纳入风险计算。
一旦风险估计为大家所认同，接下来就是风险缓解了。
