接下来的问题是，我们该如何判定风险发生频率和风险影响程度是“高”“中”还是“低”呢？参考“风险识别清单”中的分类，我对其中部分的风险发生频率和风险影响程度进行了分析，供读者参考。
2）需求类的风险
需求类的风险主要表现在如下两点：
· 需求的质量不高，不足以支撑后续开发和测试。
· 开发和测试未能正确理解需求。
上述风险一旦成了问题，可能导致返工或者需求变更，对设计、编码和测试都会有较大的影响，而且风险发生的概率也会比较高。因此，对需求类的风险，建议将它的风险的影响程度和风险发生频率设置为“高”，重点关注。
3）设计类的风险
设计类的风险主要集中在设计的正确性和全面性上。这些风险一旦成了问题，就是产品缺陷。换句话说，它们的风险发生频率总是很高的。并且比较麻烦的是，很多时候，一个风险最后会向系统引入很多缺陷。对测试而言，会增加测试的工作量，影响测试进度，影响产品质量。
我们如何判断设计类的风险的风险影响程度呢？我们假设这些风险最后成了缺陷，对这些由风险引入的缺陷，我们评估一下：
· 测试容易发现这些缺陷吗？
· 开发修复这些缺陷的改动大吗？影响的功能模块多吗？
· 测试容易验证这个缺陷吗？回归测试的工作量大吗？
· 如果这个缺陷逃逸到了用户处，对用户的影响大吗？
一般来说，测试难于发现的缺陷，风险的影响程度更高；基础的、底层的、共用的设计，风险的影响程度更高；需要特殊测试工具或复杂测试环境才能验证的，风险的影响程度更高；在用户处发生概率高、会对用户的业务造成严重影响的问题，风险的影响程度更高。
4）流程类的风险
由于大家都要遵循流程，所以流程类风险的风险发生频率往往很高，建议至少为中级。
从风险影响程度的角度来说，会影响到团队合作，或是涉及规范性方面的风险，风险的影响程度更高，建议至少为中级。
5）历史类的风险
“历史总是会被一次次地重演”，历史类的风险也是一样的——历史上曾经发生过的问题，再次成为问题的风险依然很大。所以历史类的风险，风险发生的概率应该总是高的。
历史类风险的风险影响程度，可以参考历史的风险影响程度来确定。
6.7.2 风险应对
在风险管理中，风险应对主要分为如下4种：
· 回避风险：指主动避开损失发生的可能性。
· 转移风险：指通过某种安排，将自己面临的风险全部或部分转移给其他一方。
· 减轻风险：指采取预防措施，以降低损失发生的可能性和影响程度。
· 接受风险：指自己理性或非理性地主动承担风险。
下面是一个使用上述4种不同的方式进行风险应对的例子：
“风险应对”举例：新需求在开发过程中不断被增加
· “回避风险”的做法：置之不理。
· “转移风险”的做法：将新需求外包。
· “减轻风险”的做法：寻求额外资源或裁剪其他优先级低的需求。
· “接受风险”的做法：将新需求加入项目范围，通过加班来完成新需求。
对测试来说，可以结合风险和当前项目的实际情况，来选择合适的风险应对方案。
此外，我也总结了一些项目中常见的风险和应对这些风险比较通用的思路，供读者参考（表6-19）。
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第六章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
