风险无处不在--在家里、路上、办公室。我们所做的任何一件事情都有风险相伴，软件交付也不例外。如何降低软件交付的风险呢？如何应对软件发生故障，并给公司声誉带来难以估量的伤害这一极大可能事件呢？
风险是不可能准确量化的，但是我们会遵循一些常识来规避风险，比如行走在人行道而不是马路中间。在应对风险时，我们首先要对需求进行分析：
哪些事件需要担心？
这些事件发生的可能性有多大？
一旦发生，对公司产生多大影响？
产品具备什么缓解措施？
这些缓解措施有多大可能会失败？
处理这些失败的成本有哪些？
恢复过程有多困难？
事件是一次性问题，还是会再次发生？
影响风险的因素很多，试图精确地、定量地计算风险比缓解风险还要麻烦。在Google，我们确定了两个要素：失败频率和影响。测试人员利用这两个要素给每项能力打分。我们发现，风险实际上是一个定性的相对值，而非一个定量的绝对值。风险分析的目标不是要给出一个精确的值，而是要识别一个能力与另一个相比风险是大是小。这对于决定以何种顺序测试哪些能力足够了。GTA提供了这一选项，GTA中的风险发生频率有4个预定义值：
罕见：发生故障的可能性很小，发生问题后的恢复也很容易；
少见：在少数情况下会发生故障，但是在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小；
偶尔：故障的情形易想象、场景有点复杂，而该能力是比较常用的；
常见：此能力所属的特性使用量大、复杂度高、问题频发。
估计风险影响的方法大致相同，也是从几种偶数取值中选择一个：
最小：用户甚至不会注意到的问题；
一些：可能会打扰到用户的问题。一旦发生，重试或恢复机制即可解决问题；
较大：故障导致使用受阻；
最大：发生的故障会永久性地损害产品的声誉，并导致用户不再使用它。
有时问题对公司和用户产生的影响是不一致的。例如公司标志加载失败对公司是一个问题，但却未必会被用户注意到。在打分的时候注意一下所考虑的风险是针对公司的还是用户的，是非常有用的。
分析完需求后，接下来就是处理了。风险不大可能彻底消除。驾驶有风险，但我们仍然会开车出行；旅游有风险，但我们并没有停止旅游。通常情况下，风险并没有真的变成伤害。为什么呢？因为我们会以实际行动缓解风险。
就软件而言，一种极端的缓解办法是去掉风险最大的组件：交付的软件越少，风险越小。但是，除了彻底的风险消除，还有很多措施可以缓解风险：
1、我们可以围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束；
2、我们可以编写回归测试用例，以确保问题在重现时可以被捕捉到；
3、我们可以编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性；
4、我们可以插入监听代码，以便更早地监测到故障；
5、我们可以插入监听代码，发现新旧版本间的行为变化以发现回归问题。
具体的风险缓解措施很大程度上取决于应用本身及用户对于安全性的期望。测试人员可能会参与到实际的缓解过程，但更主要的工作是暴露风险。那些标记为红色的能力点比黄色和绿色要优先处理，按照风险顺序进行测试。原则是：如果不能全测，就先测最重要的，也就是风险最大的。
