软件测试的本质是什么？

　　最近在读《软件测试》 一书，对叫这个名字的书多，我读的是Ron Patton 写的那本，对!2002年的中文版，已经十年了，虽然没《软件测试的艺术》那么经典，那么有深度，但绝对也是一本不错的好书。读到第三章“软件的实质”，觉得确实不错，这里摘录与大家分享。

　　实质，哲学中的本质，又称为“实质”是指某一对象或事物本身所必然固有的。说的通俗点也就是说软件测试的本来的面目。

　　软件缺陷的定义

　　来看一下Ron Patton 为我们的软件缺陷所下的定义。

　　1、软件没有实现产品的说明书所描述的功能。(个人觉得“描述”比“宣称”更贴切)

　　2、软件实现了产品说明书描述不应有的功能。

　　3、软件执行了产品说明书没讲的操作

　　4、软件没有实现产品说明书没讲但应该实现的功能。

　　5、从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

　　为什么一个定义要这么多条来描述?这个“缺陷”的定义有这么复杂么?不，它其实并不复杂，作者只是想更加全面的来给缺陷下定义。下面我们来以建一栋房子为例，来说明一下每一条定义的意思。需要说明的是没有十分完美而且一成不变的产品说明说，而且在实际项目中，它可能非常简陋，模棱两可，甚至经常变动。

　　1、软件没有实现产品说明书的描述的功能。房子的主要希望有一个落地的大窗户，让阳光更好的照进屋子里，而且他特意在房子的设计图纸中画出来，并且还加以说明。结果，他看到的是四面全是墙壁，只有一个小门的房子。那么对于测试人员来说，他就是一个缺陷。

　　2、软件实现了产品说明书中描述的不应有的功能。由于房子的主人生活在南方，天气温暖，而请来的泥瓦匠是北方的，结果给主人建造的房子具然有一个大大的取暖的烟筒，而且主要主要特意在房子的设计图纸中说明，自己的房子不要烟筒。那么对于测试人员来说，这也是个缺陷。

　　3、软件执行了产品说明书没讲的操作。与第二条类似，不同的是第二条是主人已经明确说了自己不要烟筒，而这一条强调的是在主人没说的情况下。泥瓦匠自作聪明的加了一个烟筒上去。对于测试人员来说，画蛇添足的功能同样被视为缺陷。

　　4、软件没有实现产品说明书没讲但应该实现的功能。房子的主要对屋子的高度、格局，材料，颜色描述的非常清楚。泥瓦匠在建造房子的时候发现，主人没有提地基这回事，为了使房子牢固，所以，所有的房子都是必须要先打地基的，虽然主人没有说，但地基的功能必须要做。如果因为没有描述没有去做，但这又一件必须去做的事。对于测试人员来说，也可以视其这缺陷。

　　6、从软件测试员的角度看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。软件测试员是软件除了测试软件运行的缺陷，同样是作为一个用户在再对软件进行使用。如果感觉自己都很难使用，或软件效率非常低且界面丑陋等情况，也可以认为其存在缺陷。或者是最终用户拿到产品时发现这根本不是自己想要的东西，也可以现其为缺陷。当然，用户说不是自己想要的东西，也不能凭借一面之词，可以拿合约，产品说明书来评估。

　　Ok ，上面分析一下缺陷的定义，如何去判定一个缺陷。下面来看一下测试的原侧，我们可以视其为软件测试过程中的“交通规则”。它会有助于我们更好的进行软件测试的工作。

　　全完测试程序的可能性

　　初做软件测试者可能认为拿到软件后就可以进行完全测试了，找出所有软件缺陷，并使软件完美。遗憾的是这是不可能的，我们无法对一个软件进行完全测试，即使最简单的程序也不行。主要原因如下：

　　输入量太大

　　输出结果太多

　　软件实现的途径太多

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

　　以上的“太多”的可能性加在一起，致使测试条件难以确定。原书中引用计算器的例子，太复杂了，好吧!我们换个更简单有邮箱登录。虽然对以“登录”为样例表示方案，就像每个介绍编程的书上来的第一个例子就是“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、什么都不输，直接点击登录

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

　　软件测试是有风险的

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

原文转自：http://blog.csdn.net/fnngj/article/details/8597036