第4章   基于风险的软件测试

本章主要介绍基于风险的软件测试方法。基于风险的软件测试方法既是一种测试设计方法也是一种测试管理方法，基于与大部分书保持一致，笔者把这一章放在本篇中介绍。

基于风险的软件测试是对辨识出的测试风险及其特征进行明确的定义描述、分析和描述风险发生可能性的高低、风险发生的条件等。

首先，软件测试团队面临的问题是软件测试任务的时间压力。这个现象普遍存在，一般由于开发工程师开发周期加强，而版本发布的时间不变，运用其他技术很难保证软件测试的执行，如果运用基于风险的测试方法，在线性开发模式中可以优先考虑风险级别高的测试用例，而对于风险级别低的测试用例，可以不执行。在迭代过程中采取的策略是不减少测试范围，而是减少迭代次数。

其次，软件测试团队经常面临的问题是系统需求质量低下或者不完整。在这种情况下可以召集利益相关者，从而对需求进行风险评估：哪些优先级比较高，必须进行详细的测试；哪些优先级中等，简单测试一下就可以；而对于优先级低的，有时间可以测试，没时间可以不测试。这样也不要求一份相对比较完整的需求说明书了。

最后，在项目软件测试过程中，每隔一段时间对测试情况进行监控。软件测试经理可以对已经执行的测试用例以及已经发现的缺陷进行评估，从而决定是否需要继续测试，如果需要，测试哪些内容？哪些测试内容需要增加？重点需要测试哪些模块等，从而随时对软件测试计划进行调控。

本章的内容包括：

• 基于风险的软件测试方法。
•  软件测试风险级别确认与调整。

4.2.2  调整风险级别

案例4-3：风险级别的调整。

假设原先的风险级别见表4-8。

表4-8                                                           原先的风险级别

目前级别发现的风险见表4-9。

表4-9                                                       目前级别发现的缺陷

下面来看如何调整风险级别。

Mi=高级错误数×5+中级错误数×3+低级错误数×1。

a=（Mi/∑Mi）×100%，根据a获得现在的发生可能性b。

•  1%～20%：b=1。
•  21%～40%：b=2。
•  41%～60%：b=3。
•  61%～80%：b=4。
•  81%～100%：b=5。

于是得到表4-10。

表4-10                                                     风险级别调整（一）

所以，e=(c + b)/2×d（c为原可能性，b为现在可能性，(c + b)/2为调整后的可能性。d为原严重性，e为现优先级）。

由于缺陷只体现出可能性，而对严重度的影响不存在，所以不考虑对影响度的调整。根据前面的公式，得到表4-11。

表4-11                                                     风险级别调整（二）

比较前后结果，得到表4-12。

表4-12                                                           前后结果比较

顾翔凡言：

敏捷具有适用性，即使用了敏捷，也不要做成假敏捷，掌握敏捷的真谛。