虽然很少有人会对这些答复产生异议，但是作为一个软件工程师，需要有更严格的标准来决定是否已经进行了足够的测试。Musa和Ackerman［MUS89］提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错的操作概率大于0。995的话，那么我们就有95％的信心说我们已经进行了足够的测试。”

　　使用概率论模型和软件可靠性理论，可以建立一种作为执行时间的函数软件故障（在测试过程中发现的错误）模型［MUS89］。一个称为对数泊松执行时间模型（logarithmic Poissonexecution－time model）的软件故障模型为：

　　f（t）＝（1/p）1n（l0pt+1） （17。1）

　　其中f（t）＝软件在一定的测试时间t后，可能会发生故障的预期累计数目。

　　l0＝在测试刚开始时的初始软件故障密度（单位时间内的故障数）。

　　p＝错误被发现和修正的过程中故障密度的指数递减值。

　　瞬时的故障密度，l（t）可以使用f（t）的导数得出，

　　l（t）＝l0/（l0pt+1） （17。2）

　　使用等式（17。2）中给出的关系，测试人员可以预测测试进程中错误的急剧减少。实际的错误密度可以画在预测曲线上。如果在测试过程中实际收集的数据和对数泊松执行时间模型能够在大量数据下都相当好地接近的话，那么这个模型就可以用来预测为了达到一个可以接收的低故障密度，整个测试过程所需要的时间。

　　通过在软件测试过程中收集数据和利用现有的软件可靠性模型，就可能得到回答“测试什么时候完成”这种问题的有意义的指导原则。毫无疑问的是，在测试的量化规则建立之前仍然需要大量的进一步工作，但是，现有经验理论总比直觉要好不少。

　　2、策略问题

　　在本章的后面部分，我们会探讨一个软件测试的系统化策略。但是，如果无视一些重要的问题的话，那么即使是最好的策略也会失败。 Tom Gilb【GIL95】指出如果要实现一个成功的软件测试策略的话，下面的问题是必须涉及的：

　　在着手开始测试之前较长时间内，就要以量化的形式确定产品的需求。虽然测试的主要目的是找错误，一个好的测试策略同样可以评估其他的质量特性，比如可移植性、可维护性和可用性。这些应当用一种可以测度的方式来表示，从而保证测试结果是不含糊的。

　　明显地指出测试目标。测试的特定目标应当用可以测度的术语来描述。比如，测试有效性、测试覆盖率、故障出现的平均时间、发现和改正缺陷的开销、允许剩余的缺陷密度或出现频率、以及每次回归测试的工作时间都应当在测试计划中清楚地说明【GIL95】。

　　了解软件的用户并为每一类用户建立相应档案通过着重于测试产品的实际用途。“使用实例”——描述每一类用户的交互情况图研究可以减少整个测试的工作量。

　　建立一个强调“快速循环测试”的测试计划。Gilb【GIL95】建议软件工程队伍“学会以对客户有用的功能添加或/和质量改进的快速循环测试方法（用百分之二的项目开销）进行测试”。从这些快速循环测试中得到的反馈可以用来控制质量的级别和相应的测试策略。

　　设计一个能够测试自身是否“强壮”的软件。软件可以使用反调试技术的方法来设计，这就是说，软件应当能够诊断特定类型的错误，另外，设计应当能够包括自动测试和回归测试。

　　使用有效的正式技术复审作为测试之前的过滤器。正式技术复审在发现错误方面可以和测试一样有效，由于这个原因，复审可以减少为了得到高质量软件所需的测试工作量。

　　使用正式技术复审来评估测试策略和测试用例本身。正式的技术复审可以发现在测试过程中的不一致性、遗漏和完全的错误。这样可以节省时间，同时也能够提高产品的质量。

　　为测试过程建立一种连续改善的实现方法。测试策略必须进行测量，在测试过程中收集的度量数据应当被用作软件测试的统计过程控制方法的一部分。