完全测试程序的可能性

完全测试程序的可能性

输入量太大

输出结果太多

软件实现的途径太多

软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。

以上的“太多”的可能性加在一起，致使测试条件难以确定。原书中引用计算器的例子，太复杂了，好吧!我们换个更简单有邮箱登录。虽然对以“登录”为样例表示方案，就像每个介绍编程的书上来的第一个例子就是“hello world”。但这个例更能简单的说明问题，这里就再用一下。

以126邮箱为例，其用户长度为50个字符，密码确实不太好计算(因为都是*号)，所以这里也按50个字符来计算。好吧!虽然，我已经知道了正确的用户名和密码。

在输入正确用户名的情况下：

1、输入正确的密码名是还否可以登录，

2、那么错误输入0 呢?1呢?2呢?......直到

99999999999999999999999999999999999999999999999999 ，

3、如果密码不是数字，而是字符呢，a 、b、c ... aa、bb 、cc .....

4、如果是大写呢 A 、B、C.... AA 、BB、CC.....

5、如果是大小写呢 Aa、Ab ....

6、如果是小写+数字呢 1a 、1b 、1c ....2a 、2b 、2c.....

7、如果是大写+数字呢 1A 、1B 、1Cc....2A 、2A 、2A.....

8、如果是大写+小写+数字呢 1Aa 、1Bb 、1Cc ....1Aa 、1Bb 、1Cc.....

9、如果有特殊字符呢 @#￥%……&*

10、如果输入字符有空格呢 a b、adbc ee......

11、如果是其它字符+大小写字母+数字呢+空格呢 !@#&+123AIBKIkklzcb ......

......

12、再换正确的密码，错误的文件名再来一次。

13、用错误的用户名和密码再把上面的情况验证一次。(这样会匹配到所有的用户名密码)

这样穷举下去，哪怕世界上超级的计算机，也需要计算十年、百年才能验证所有情况。如果觉得某些测试条件是重复的或都无必要的或都为了节省时间，而将其剔除，那么就不能称为完全测试。