读者可以考虑一下倘若编译程序能够正确地指出代码中的所有问题，那相应程序的错误情况会怎样？这不单指语法错误，还包括程序中的任何问题，不管它有多么隐蔽。例如，假定程序中有“差1”错误，编译程序可以采用某种方法将其查出，并给出如下的错误信息

-> line 23: while (i<=j)

off by one error: this should be ‘<‘

又如，编译程序可以发现算法中有下面的错误：

-> line 42: int itoa(int i, char* str)

algorithm error: itoa fails when i is -32768

再如，当出现了参数传递错误时，编译程序可以给出如下的错误信息：

-> line 318: strCopy = memcpy(malloc(length), str, length);

Invalid argument: memcpy fails when malloc returns NULL

好了，要求编译程序能够做到这一程度似乎有点过分。但如编译程序真能做到这些，可以想象编写无错程序会变得多么容易。那简直是小事一桩，和当前程序员的一般作法真没法比。

假如在间谍卫星上用摄像机对准某个典型的软件车间．就会看到程序员们正弓着身子趴在键盘上跟踪错误；旁边，测试者正在对刚作出的内部版本发起攻击，轮番轰炸式地输入人量的数据以求找出新的错误。你还会发现，测试员正在检查老版本的错误是否溜进了新版本。可以推想，这种查错方法比用上面的假想编译程序进行查错要花费大得多的工作量、确实如此，而且它还要有点运气。

运气？

是的，运气。测试者之所以能够发现错误，不正是因为他注意到了诸如某个数不对、某个功能没按所期望的方式工作或者程序瘫痪这些现象吗？再看看上面的假想编译程序给出的上述错误：程序虽然有了“差1”错误，但如果它仍能工作，那么测试者能看得出来吗？就算看得出来，那么另外两个错误呢？

这听起来好象很可怕但测试人员就是这样做的大量给程序输入数据，希望潜在的错误能够亮相。“噢，不！我们测试人员的工作可不这么简单，我们还要使用代码覆蓋工具、自动的测试集、随机的“猴”程序、抽点打印或其他什么的”。也许是这样，但还是让我们来看看这些工具究竟做了些什么吧！覆蓋分析工具能够指明程序中哪些部分未被测试到，测试人员可以使用这一信息派生出新的测试用例。至于其它的工具无非都是“输入数据、观察结果”这一策略的自动化。

请不要产生误解，我并不是说测试人员的所作所为都是错误的。我只是说利用黑箱方法所能做的只是往程序里填数据，并看它弹出什么。这就好比确定一个人是不是疯子一样。问一些问题，得到回答后进行判断。但这样还是不能确定此人是不是疯子。因为我们没法知道其头脑中在想些什么。你总会这样地问自己：“我问的问题够吗？我问的问题对吗……”。

因此，不要光依赖黑箱测试方法。还应该试着去模仿前面所讲的假想编译程序，来排除运气对程序测试的影响，自动地抓住错误的每个机会。