“测试也许可以令人信服地表明存在缺陷，但是永远无法表明不存在缺陷。”

　　--Edsger W. Dijkstra，计算领域先驱（1930-2002）

　　“Programming as a discipline of mathematical nature”

　　《美国数学月刊》第81卷（1974）第6期，608-612页

　　最近有一位测试经理（test manager）向我咨询，说他的上级经理要求他“测试所有的可能”。而我并不是第一次听到这种无法实现的要求。

　　为什么无法实现呢？首先，人类的大脑不仅会犯错，而且它的容量也是有限的。其次，没有人的生命可以无限长。所以，无论我们多想进行所有可能的测试，也无法全部考虑到；即使全都考虑到了，也无法活得足够长来将它们进行完。此外，在大多数情况下，要进行所有可能测试的成本也太高了--因为对任何程序而言，可能进行的测试数目都是无限的。下面我们来看看原因。

　　1、可能进行测试的数目是无限的

　　我们考虑一下对能够想象到的最简单的程序进行测试：该程序的功能就是在用户敲击空格键的时候在屏幕上显示内容为“Hello Dolly！”的消息作为响应。我们要测试些什么？简单起见，我们希望测试每次按下空格键的时候，都能得到“Hello Dolly！”消息；而每次我们按下其他的键或组合键时，都不会在屏幕上得到任何响应。

　　如果不能查看程序内部的代码，需要执行多少测试用例才能让你有

　　把握说已经对所有的可能性都进行了测试？确定测试用例的数目，把它写下来，然后再阅读下一段看看你的答案是否正确。

　　由于不能查看程序内部的代码，所以就无法知道程序员是否设置了某些奇异的条件。例如，也许程序被设计成外面看起来一切正常，直到用户输入一组极不可能出现的按键序列。假设我将程序设置成要求先按W键，接着按3次空格键，再按M键，又是按三次空格键，然后按J键，接下来再按168次键而且不能包含字母L，在输入满足这个条件的时候程序会在屏幕上问：“Whaaa？”。你先前建立的测试用例穷举集是否能检测到这个怪异的条件？而这一条件在程序中隐藏了一条多余的而且是非预期的“Whaaa”响应。

　　是不是觉得这个条件太怪异了，不切实际？在对一个理论上应该是高度安全的应用进行技术审查时，我们发现一个名为Wanda Marilyn Jones（不是她的真名，不过首字母是一样的）的程序员在编写口令保护时在软件中设置了一个以此为条件的后门。无论真正的口令是什么，她都可以绕过正常的口令保护，随时闯入系统。在严格控制下进行的一个极复杂的测试计划也未能发现这个后门，让它存在了三年，直到我们对它进行技术审查。按照Edsger Dijkstra的说法就是：“测试可以揭示缺陷的存在，而不能表明它们不存在。”

　　现在明白了没有？如果没有想到对软件进行穷举测试需要的测试数目是无穷大的，或者至少是“在整个生命中无法完成的一个数字”，就无法理解本章的要点。不过这个例子应该可以让你明白了。

　　请注意我根本没有提及在不同配置下对程序进行测试的可能性，而这一问题是产品开发人员通常都会遇到的。如果程序需要在10种不同的CPU上运行，每种都分别要对应10种可能的内存大小和10种不同的磁盘驱动器大小，可能就意味着要测试10乘10乘10，也就是1000种不同的配置。

　　但是对于很多真实的测试情况而言，这个例子还是过于简单了。在真实的测试中，测试人员要解决由不同的制造商、不同的驱动程序、不

　　同的操作系统版本、同时运行的其他程序，以及其他不同的外围设备组合带来的其他的复杂性，任何一种配置都可能导致错误。要“完全”覆盖像这样的所有可能配置，会要求以quadrillion（10的15次方）计算的测试用例。而这还没有考虑对程序在任何一种配置下所应完成的各种功能进行测试。

　　即使这一巨大的数字也没有考虑测试的执行顺序所可能带来的影响。如果用户可以调用10个功能，仅仅使用10个不同的测试是不够的，因为以不同的顺序执行这些功能也许会产生不同的结果。所以，我们需要10！（10的阶乘，大约六百万）个测试而不只是10个测试才能覆盖所有的执行序列。

　　但这也不够，因为如果程序用到了内存（所有真正的程序都会用到），那么我们再次执行某个测试序列的时候，就有可能会产生与第一次不同的结果。

　　这些巨大的数字（所有的都乘在一起）还忽略了真正的随机性，例如某个外部设备在哪一纳秒上产生中断，或者用户在哪一毫秒敲击例如J键，总而言之，测试可以让人筋疲力尽，但它是不可能穷尽的。