不对所有可能性进行软件测试的原因

%cou5i!hb0m0　　--Edsger W. Dijkstra，计算领域先驱（1930-2002）51Testing软件测试网(yHnkW'_h

2T5i4B6u4l3lL)P]r_0　　“Programming as a discipline of mathematical nature”

!})f lx$oK0　　《美国数学月刊》第81卷（1974）第6期，608-612页

　　最近有一位测试经理（testmanager）向我咨询，说他的上级经理要求他“测试所有的可能”。而我并不是第一次听到这种无法实现的要求。51Testing软件测试网\!},ux?

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

　　1、可能进行测试的数目是无限的51Testing软件测试网(rX(W~ YE;D X*R W

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

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

　　把握说已经对所有的可能性都进行了测试？确定测试用例的数目，把它写下来，然后再阅读下一段看看你的答案是否正确。51Testing软件测试网:E3c @D$|W{ @;Up

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

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

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

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

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

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

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

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

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

　　2、测试最多只是采样

0UG%I^7]us+\0　　由于我们无法测试所有的可能性，所以任何实际的测试集都是某种程度的样本--以某种方式代表整个可能测试集合的一个部分或者片段。我们理所当然 地希望它是一个良好的代表，但这就会带来一个问题：“对谁而言是良好的？”本质上，采样也是一个心理过程，而且也是一个感性过程。令某人满意的样本也许会 让另一个人觉得一点儿也不满意。51Testing软件测试网;c:W:]L P7n

　　那么我们如何决定采哪些样？我们如何知道是否获取了足够大的样本来充分代表所有情况？我们如何知道是否获得了合适的样本？51Testing软件测试网"`5bHzjY Rw

　　当我和同事Elisabeth Hendrickson思考这一问题的时候，刚好在新墨西哥州的佩科斯峡谷遇到了一场暴雨。我住处门廊外面挂了一个雨量计，它通过上端的一个小开口来对雨水进行采样。当时的雨是散得很开的大51Testing软件测试网y&mR8lSX

Q[6E8c!M'W&ngH~3E0　　雨滴，每隔几秒钟就会落下一阵。这个雨量计也许在西雅图是比较合适的，因为它在连绵几个小时的细雨中可以工作得很好。但是当佩科斯的暴雨在下了十分钟后停下来时，雨量计的底部完全是干的，与下了雨的事实完全不符。

　　但是Elizabeth和我是亲眼看着下的雨，实际上，我们都被淋透了。我们马上认识到这个雨量计在暴雨持续的那几分钟内没能对隔着几英寸落下的巨大雨滴进行充分的采样。Elizabeth看着我还在滴水的胡子说：“作为雨量计而言，你比走廊上的那个更好。”

　　请注意情况也可能刚好相反。如果刚才那些巨大的雨滴中有一两滴刚好落进了那个小开口，雨量计也许就会表示降雨量达到了四分之一英寸，而这同样是 不准确的。我们在测试中经常会看到相同的现象：我们取少量的样本--到处尝试一下--然后对整个产品中问题的密度做出过低或者过高的报告。51Testing软件测试网6ql1E]'j_/}8F?,P

Cz[UUc0　　3、信息的成本可能超过无知的成本51Testing软件测试网,w%WZPu/ys

　　不可能进行穷举测试导致我们要在两个难以达到的，但是同样吸引人的目标之间进行取舍：51Testing软件测试网/WA6ue*x,i

　　1）我们希望测试能够覆盖所有令人感兴趣的条件。

l2PY{R+`0　　2）我们希望将测试集减小到可以管理、可以承受的程度。

pN(v8mAQ7KZ0　　要理解第一个目标的含义，不妨考虑一下有多少次测试人员并不是在寻找某种类型的缺陷，却碰巧发现了这种致命缺陷。他们发现这个缺陷的原因只是运 气好（如果他们不想知道这个缺陷的话，就是运气不好），而不是由于他们正在执行一组精心设计的用于发现这个特定问题的测试。缺陷就这样出现了，就像是葡萄 干麦片中出现一只蚂蚁。但这完全只是运气吗？有没有某种心理学方法可以帮助确定如何才能发现更多的这种令人吃惊的缺陷？我相信拓展我们对测试的看法可以提 供部分答案。51Testing软件测试网(ZfLB4\3w6S8@r

　　4、我们也许可以用较少的测试获取更多的信息51Testing软件测试网\ R:p |I

$rwI$zLU3\ Z0　　最近，很多和我交谈过的人都很关注前述的第二个目标，也就是将测试集减小到可以管理、可以承受的程度。他们被要求或者被命令要在测试队伍更小而责任更大的条件下生存甚至是发展。

(SMK'g4k(r9S4Z0　　有人给我讲过一个比较极端的情况：有名测试人员向顾问寻求建议，如何处理一个左右为难的局面：“我们的测试团队刚刚从30人减小到了3人，而且还要'确保'这个产品。我如何确定该测试哪些东西？”

　　有一种观点认为测试人员不能“确保”任何事，所以他们根本就不应该进行尝试。但是这样的观点无法说服任何一名正在艰难的经济条件下努力保持公司 运行的管理人员。那么该怎么办？无可否认，减小后的团队无法完成更大的团队本来可以完成的所有事，但是可以在他们可能进行的测试中加以选择，可以找出让有 限的资源得到最佳利用的那些测试。51Testing软件测试网!}"T4b{l2Kz_m]

P2M A2P&r#c0　　顾问给出的建议提供了很好的基础：“首先，要认识到任何测试集都是一种采样方法。然后，无论你有多少资源，都要尽可能选择那些具有最强代表性的测试集。”51Testing软件测试网,d&Y!jM)[

　　5、测试自助餐

-}_Xr2\:S G0　　想象一下你站在一张长长的桌子前，桌子上摆满了用例、边界条件、兼容性测试、交互测试、权限矩阵等，手上拿着一个盘子。测试自助餐允许就餐者在点餐桌前走两三个来回，所以你知道自己必须做出明智的选择。你该怎么做？

　　如果你曾经看到过其他人在真正的自助餐中面对这样的场景，就会知道不同个性的人会用不同的方法来解决这个问题。有些人会对餐厅领班或者服务员抱 怨盘子太小，并在整个就餐过程中发牢骚，让其他人也没了食欲。有些人则会转身愤怒地走开，因为他们认为不应该限制他们吃的食物量。51Testing软件测试网nC@y+`{

,dQ2R L5Y0　　有些人则会从食物队列的开头开始，用他们最先遇到的两道喜欢的菜装满盘子。这样做明智吗？在餐馆中也许是明智的，但在使用有限的资源进行测试时恐怕不是。51Testing软件测试网&v&P mL8e;h

xDXj8zV3t0　　在面对无法完成的测试任务集时（实际上这是测试中总会遇到的情况），从头开始进行，看看在分配的时间内测试能够进行到哪一步的做法可能是很有诱 惑力的。另一种做法则是从整个特性集中选择那些简单的、可以很快完成的测试。两种方法对测试人员而言都是很方便的，但它们是否为测试提供了足够的食物？51Testing软件测试网G$b_o8Z{ `3O3r

c8@1^3JG-m HPD0　　要进行良好的测试，测试人员就必须注意到有限的测试、资源和时间带来的限制。测试人员还必须注意自己的个性，也就是他们选择自助餐的方式。51Testing软件测试网Uy#`&x0hc&iu-[2w

　　经理们也需要注意这些限制和倾向。无论你有多喜欢“穷举”测试的奢华，都不要期望测试人员能够对测试加以“穷举”。你必须接受让自己的食欲以某种受控的方式得到满足。

}x_&wq!k-D:`4e0　　小结

　　本质上，任何特定的候选产品上可以进行的测试数目都是无限的。经理们和测试人员必须尽力了解采样给测试过程带来的风险，而不是要求执行“所有的”测试。51Testing软件测试网`Gy.s
qut