3.8 测试与检验
大型项目的测试会分成很多层。我们经常能看见那种包含单元测试、功能测试、回归测试、组件测试、性能测试、系统测试及验收测试的项目。无论测试能找到多少bug，它都要耗费大量的资源与时间。在Software Estimating Rules of Thumb这篇文章[19]中，Capers Jones提出了他所总结的“软件开发成本动因定律”（Law of Software Development Cost Drivers），该定律宣称，“对于所有的软件来说，查找及修复bug都是成本最高的活动。”顺便再说一下，对于BDUF项目来说，还有几个成本比较高的活动排在该因素的后面，它们分别是：写文档、写代码、开会和管理。在军事项目中，写文档会升至第一位。在敏捷项目中，第二位和第四位互换。
测试有一个令人失望的特点，那就是它非常低效。其原因有很多：
- 测试通常致力于证明程序已经实现了它所应该达成的功能，而很少会致力于查找错误。如果我们发现了bug，那就会修复该bug并撰写一项测试，以证明程序现在可以正常运作，然后，这项测试会反复地运行，于是，我们自然就会发现它每次都能够运行通过。简单来说，我们所测试的路径，只不过是程序最有可能走到的那些路径而已。
- 测试，是由那些熟悉应用程序工作原理的人所编写的。而使用该应用程序的人，并不知道它的工作原理，因此可能会采用一些与测试者不同的方式，来操作该应用程序。早在1989年，Miller等就有一项惊人的发现，他们把一些胡乱生成的内容输入给各种UNIX实用程序[20]，然后看到其中有25%～33%的程序无法通过测试。
- 构建测试所需的工作量很大，因此我们不会构建太多的测试。
- 测试本身通常也含有一些错误。
- 有一些错误很难通过测试来检查，例如，时机错误、因数据库中缺失数据所引发的错误，以及由于网络入侵而造成的安全问题等。
- 大部分的测试，都是在测试应用程序上面运行的，然而还有一些错误，则与版本不符或配置不当有关，这些错误发生在我们把应用程序移动到生产系统中的时候。
公司应该让最优秀的人去实现一套良好的系统测试机制。我们也可以换一种说法：编程本领最强的人，不一定是最能把测试写好的人。最适合写测试的，应该是那种颇具创意，而且特别喜欢把应用程序搞坏的人。
有一次笔者听到这样一种说法：专业的古典音乐家与业余的古典音乐家不同，后者只要能把某段乐谱准确地弹完一遍，就不再继续练习了，而前者则会反复练习，直到毫不出错。这是两种不同的境界，业余人士只满足于我能弹好一遍就行，而专家追求的则是每次都能弹好。测试也与之类似。测试并不是只保证应用程序能达到业余水平，而是要按照专业的水平来要求它。为了暴露程序的故障点，笔者建议你采用以下做法：
- 试着令应用程序承担大量的负载，尤其是要使应用程序感觉到，这些负载好像是多位用户同时造成的。
- 试着在程序里面引发故障，而且还要试着在错误恢复的过程之中引发故障。
- 在接缝处寻找故障，也就是要检查部件之间的每一条依赖关系并对其进行测试。
如果应用程序已经发行，而且数据库里也已经有了真实的数据，那么就试着编写一些采用真实数据来运作的测试，同时可能还需要对这些数据做匿名处理。有许多测试都在反复地使用同一份数据，这些测试的编写者尤其需要注意：如果数据库发生了变化，那么相应的数据可能也会有所改变。
想要制作一款高质量的程序，单靠测试是不够的。还应该采取下列措施：
- 使用静态分析器去分析代码，以便找出其中从来没有执行过的代码及变量、还没有初始化就直接使用的变量、有可能无法终止的循环，以及潜在的性能及安全问题。
- 使用代码检查机制。笔者建议执行两个层面的代码检查，第一个层面是由团队内的其他程序员来检查，第二个层面是由系统测试组来检查。前者应该帮助我们消除那些简单的错误以及对系统配置方式的误解，而后者则应该指出安全隐患等更为微妙的问题。
有统计数据表明，上面这些做法和测试一样有效，它也能够检查出bug，而且这些bug还和那些经由测试所检查出来的bug有所不同。
如果我们能够很好地计算出bug的数量，那么可能就会注意到，其中某一部分代码会频繁地出现bug，这部分代码就好像烛光，而这些bug（程序错误/虫子），则像是扑火的飞蛾。这一部分代码需要更为详细地检视，而且有可能需要重写。