以上的“太多”的可能性加在一起，致使测试条件难以确定。原书中引用计算器的例子，太复杂了，好吧！我们换个更简单有邮箱登录。虽然对以“登录”为样例表示方案，像每个介绍编程的书上来的第一个例子是“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、用错误的用户名和密码再把上面的情况验证一次。（这样会匹配到所有的用户名密码）

　　14、什么都不输，直接点击登录

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

　　软件测试是有风险的

　　好吧！你已经知道了完全测试是有风险的，如果决定不去测试所有的情况，那么我们选择了风险。在上面的邮箱登录的例子中，（假如）由于程序的所使用语言的特定，有些字符在存储的时候会被转义，如& 会被转义为_ 存储，一个叫“&&” 用户，一个叫“ __”的用户，使用了相同的密码，碰巧程序员没考虑到这种情况，那么程序该如何登录呢？（我也不知道，这只是个假设的例子）

　　对于一个免费开放的邮箱来说，会有成千上万的用户每天都有用户注册登录，如果有用户遇到了上面的问题呢？程序该如何处理？当然，对于一个邮箱系统，你可能不以为然，他的修复速度与成本都不算高，假如，这个用户有非常保密且重要的邮件，结果被别一个用户登录查看了呢？假如这不是一个邮箱系统，而是一个银行系统呢？那有可能用户的财产会受到损失。（相比较而言，互联网产品（B/S架构）比客户端产品（C/S架构）的修复速度与成本要低）。