2.2 测试自动化
　　软件测试是非常昂贵的。自动化是销减成本的好办法。软件测试工具和技术通常缺乏适应性和可伸缩性。原因是不言而喻的。为了使过程自动化，我们不得不从规格说明中生成预言（oracle），生成测试用例来测试目标软件，以决定他们的正确性。今天，我们还没有一个系统全面达到这个目标。一般还是需要一定的人为干预，自动化的程度停留在自动化测试脚本的水平。
　　在可靠性测试和性能测试中问题减少了。在鲁棒性测试中，简单的规格说明和预言：不瘫痪，不挂死。类似的简单度量也可以用在压力测试中。
　2.3 什么时候停止测试？
　　测试是个永无止境的工作。我们不可能把所有的缺陷都测试出来并将他们消除。在一些点上，我们不得不停止测试将软件发布出去。问题是什么时候我们可以停止测试呢？
　　现实地讲，测试是个预算、时间和质量三这的平衡。它受利益模型驱动。悲观的途径，也是通常采用的途径，是当被分配的资源—时间、预算或测试用例—用完了的时候停止测试。乐观的停止测试准则，是当可靠性满足了需求，或继续测试不能带来更多利益时，停止测试。这通常需要使用可靠性模型来评价或预测软件的可靠性。每个评价需要重复运行：失效数据收集—建模—预测。然而，这个方法不能很好地适合高度可依赖（ultra-dependable）的系统，因为实际领域里的失效数据需要太长时间的积累。
　2.4 测试的替代
　　软件测试被越来越多地认为是一种有问题的解决质量问题的方法。依靠测试来定位或纠正问题是一个永无止境的工作。缺陷不能彻底根除。正如复杂性屏障（complexitybarrier）所指出的：测试并修复问题可能并不一定提高软件的质量和可靠性。有时侯修复一个问题可能引入更加严重的问题。1991年发生在美国加州和东部海岸的例子：在信号系统中只改了3行代码就引起了灾难的发生。
　　狭义地来看，很多测试技术也有暇疵。例如，覆盖测试。在代码覆盖、分支覆盖真的和软件质量相关吗？没有明确的证据表明这一点。所谓的“人测试”如代码审查、走查和评审，被建议成作为传统测试方法的替代。代码审查（inspection）可作为单元测试的高效的替代品。实验结果表明，在发现缺陷的数量和发现缺陷的成本上来讲，逐步提取代码来阅读，至少和实际运行功能和结构化测试的功效相当。
　　使用形式化的方法来证明软件的正确性也是一个具有诱惑力的研究方向。但这个方法也没有超越复杂性屏障。对于相对简单的软件，这个方法很好用。对于那些复杂的系统，就不一样了。
　　广义地讲，我们可以开始质疑测试的终极目标。因为发现缺陷并消除那些缺陷并不一定就能提高质量，那么我们为什么需要更有效的测试方法呢？类似的问题就象汽车制造过程。在手工艺时代，我们制造汽车，砍掉问题和缺陷。但是这样的方法早已被流水线和好的质量工程过程所淘汰了，汽车可以在生产阶段做到无缺陷。这表明将设计工程化（如clean-room软件工程），对于减少缺陷，比起测试工程工程化来得更有效。测试只不过是用来做质量检测和管理的，或者，“为可测试性而设计”。对软件来说，这是一次从手工艺生产到工程化的跳跃。