1、 概述

制定测试策略是指与委托测试的用户进行交流，确定如测试工作的组织和策略的选择以及实现等事宜。测试策略表明了如何进行测试工作。为了尽最大可能利用好资源和时间，应着重测试系统的主要方面或者主要部分。而测试策略为结构化测试奠定了一个重要的基础，以利于形成一个可有效管理的测试进程。

委托测试的用户希望得到产品生产中详细的质量报告，以此来确定最终发布的产品是否满足了这些需要。如果系统质量没有达到要求或者仅仅达到了有限的范围，这就意味着系统处于高危状态，比如需要高额的返工成本或者客户/用户对产品不满意。所以，这种情况下系统就具有了一定的风险。

本文所涉及的风险概念定义如下：

风险是指错误发生时产生的破坏的机会或危险

对于为满足系统质量要求而出现的风险，测试工作可以通过更深层次的洞察和辨析来覆盖风险。当质量不能够及时的得到衡量，例如：开发人员的返工。如果颠覆系统原结构暗示着对产品更大的风险，很明显，好的测试工作是个很不错的解决方案。

没有风险就没有测试

尽管在上文中我们谈到了一般意义上的质量和风险，但在具体的情况下它们有很大的不同。所以，我们要与用户进行具体的讨论，将用户的期望转换为测试的目标，这一点是非常重要的。而测试策略就是在测试的效果和风险的覆盖之间的最优平衡。基于这个目的，将风险定位在质量特性层和单独的子系统。这样一来，找到一个合适的测试覆盖率来评估风险才成为可能。较高的测试覆盖通常导致更多的测试工作。为了达到测试覆盖要求的变化，就要采用多种测试规范技术(测试设计技术)，每一种采用的技术都能提供一种具体的测试覆盖标准，这是至关重要的。

下面这个保险的比喻可能能更好的说明问题。一个人想承保一定的风险，所以就需要最大满足需求的保险。该保险需要一定的保费。如果他支付的保费较少，他承保的程度也就低。结果是如果没有承保的风险发生了，是无法赔付的。另一方面，如果承保越多，需要更多的支付保费，但是目前情况下对这个投保的人是不可能的。

预算    　     　　　         风险覆盖

预算与风险承保的平衡关系

2、 风险评估

测试策略是基于风险评估的。也就是评估错误造成的破坏程度，包括操作前未被发现的错误和操作过程中发生的错误。

风险评估是基于质量特性和子系统的。例如：如果系统用户使用不友好，会造成负面影响。当一个工资系统中薪水计算模块工作异常，将会带来极大的毁坏性。

为了很好的进行评估，风险的两个方面都要考虑：

风险=失败的概率×毁坏率

这里的失败概率与使用率和错误发生率有关，如下所示：

 使用率

一个每天使用几十次的功能出现错误的概率高于一年才用一次的功能

 错误率

以下项目对错误率的评估会有一定的帮助。它们是错误较为集中的地方。部分来自于文章H. Schaefer, 1996 (Surviving under time and budget pressure, in: Conference Proceeding EuroSTAR1996, Amsterdam, the Netherlands)

 复杂功能；

 完成的新功能；

 (尤其是经常)变动的功能；

 在第一次使用时采用了特定工具或者技术的功能；

 在开发过程中从一个开发人员转到另一个开发人员的功能；

 在极端时间压力下确认的功能；

 优化频率高于平均水平的功能；

 有很多接口的功能；

 经验不足的开发人员；

 参与不足的用户；

 开发过程中较低的质量保证；

 低质量较低层次的测试；

 新的开发工具和新的开发环境；

 大规模的开发团队；

 次优的开发团队沟通(例如：由于地理分散或者认为因素)。

 破坏

如果当错误出现，它将对组织造成危害。问题是需要的维修费用(包括系统的和结果的)，失去的收入，丢失客户或者客户的信任。通常如果错误对其它功能或系统产生影响，危害随之增加。如果错误发生在间歇过程中，这样有可能防止他们阻碍用户，所以最终的损害将小于类似于对在线流程造成的损害。当然，如果错误及时的被发现，这种情况可以避免。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。