2.1.3 软件测试的风险观点

测试被定义为对软件系统中潜在的各种风险进行评估的活动，这是软件测试的风险观点。一方面，软件测试自身的风险性是人们公认的，测试的覆盖率不能达到100%；另一方面，软件测试的标准有时不清楚，软件规格说明书虽然是测试中的一个标准，但不是唯一的标准。因为规格说明书本身的内容完全有可能是错误的，它所定义的功能特性不是用户所需要的。所以，我们常常强调软件测试人员应该站在客户的角度进行测试，除了发现程序中的错误，还要发现需求定义的错误、规格说明书设计的缺陷。但是，测试在大多数时间/情况下是由工程师完成的，而不是客户自己来做的，所以又怎么能保证工程师和客户想的一样呢？

有人把开发比作打靶，目标明确，就是按照规格说明书去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞。如果只捞大鱼（严重缺陷），网眼就可以大些，撒网区域相对比较集中（测试点集中在主要功能上）。如果想把大大小小的鱼都捞上来，网眼就要小，普遍撒网，不放过任何一块区域（测试点遍及所有功能）。

在“风险”观点的框架下，软件测试可以看作是一个动态的监控过程，对软件开发全过程进行测试，随时发现不健康的征兆，发现问题后报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去。软件测试包括回归测试。这时，软件测试完全可以看作是控制软件质量的过程。

按照这种观点，可以制定基于风险的测试策略，首先要评估测试的风险，每个功能出问题的概率有多大？根据Pareto原则（也叫80/20原则），哪些功能是用户最常用的功能（约占20%）？如果某个功能出问题，对用户的影响又有多大？然后，根据风险大小确定测试的优先级。优先级高的功能特性，测试优先得到执行。一般来讲，高优先级功能（用户最常用的功能，约占20%）的测试会得到完全的、充分的执行，而低优先级功能（用户不常用的功能，约占80%）的测试就可能由于时间或经费的限制，降低测试的要求，减少测试工作量，这样做风险性并不是很大。