数据探索测试（2）

输入数据的测试2：

（一）蝴蝶效应测试法：

现实生活中会出现这样的例子，往往大的事故会导致一次性损失，而那些微小的事故，往往显得不是那么起眼，却会在某个时候造成巨大的损失，就好像是蝴蝶效应。

在测试的过程中，同样存在这样的问题，测试人员会将用例设计的十分“明显”，来判断程序是否会防护或作出对应的反应，其实许多情况下数据的用例 设计可以做一些蝴蝶效应的处理，看看是否会造成像龙卷风一般的后果。

这里举一个例子：程序要从数据中读取“Product”这个数据，并且会对没有这个关键字的情况作出告警提示，测试用例可以设计为“Sheet ”等这样与关键词差异很大的用例，来测试程序的该项功能。但是否可以将用例设计为“Product1”。从本质上而言，“Sheet”和“Product1”的用例是一致的，但是有时候的结果却很不相同，如果开发人员的代码是这样：

if（key==“Product”）

{

    //代码的具体内容

}

那么这样的情况是可以防护住输入数据出错的情况的。但是如果代码是以下的情况：

if（key.Contains(“Product”)）

{

    //代码的具体内容

}

那么“Sheet”和“Product1”的用例所起的作用就差距很大了。所以测试用例有时越接近正确值反而测试效果越好。这就是蝴蝶效应，越小的变化反而越会造成巨大的后果。

那么如果开发人员没有用Contains呐？那我就反问万一他用了呐？测试就是考虑到一切可能的情况，提高软件的健壮性。退一步，开发人员代码规范，没有用Contains，那么我们来考虑他的关键词从何而来，是直接读取，还是字符串分割。如果是前者，那么在输入数据的源文件中做一些细小的偏移量，如果是后者，在原始的字符串中，细微改变一下分割符，特别是空格，将这样的设计作为测试用例，往往会发现较多的bug。

蝴蝶效应测试法的几点意见：

1.设计测试用例时，可以在正确输入的数据入手，做一些细微的改变，反而能发挥用例很大的作用。

2.关注某些具体数据从源数据到中间数据经历的处理过程，来微微改变源数据（偏移量，分隔符）作为测试用例。

（二）墙角测试法

在日常生活中，比如在打扫卫生时，总是会去扫那些常使用的地方，或者是那些容易扫到的地方，而像墙角，特别是储藏室的墙角，就很难会打扫到，而且长时间内对你的生活影响还很小（毕竟不会有很多人关注储藏室墙角的卫生）。

测试的数据有时也是这样的，有些问题就像墙角的卫生一样，很少会被测试到，甚至在使用的过程中也很少会被使用到，所以某些Bug会长期存在。

下面举一个测试工作中出现过的实例：

软件在界面处需要设计一个版本输入框，格式为“*(0-255).*(1-255).*(1-255).*(0-255)”按照测试用例设计的一些原则，可能会对空值啊，边界值等做一些检查，而且实际应用软件的过程中，版本号的种类不会超过10种，所以测试完成后一直都没有出现过什么问题。但是有一组测试用例产生了一个Bug，当输入的数据为“*.10.*.*”时，程序报错，输入版本号不正确，究其原因发现是开发人员在写正则表达式的时候出现了这样的错误，中间两位只要在末尾是“0”，就会认为是错误的。

从测试的角度而言，这样的Bug是很难发现的，首先不太可能遍历所有的输入情况（组合太多），其次特殊值的测试也很难覆盖到这样的测试用例。

生活中会有一些人自带洁癖属性，就是打扫卫生的时候，所有角落都需要打扫到，软件测试也是需要某些洁癖，这种洁癖可以排查出很多Bug。

对于界面输入数据的检查，有一个不成熟的小建议：

Review Code+Smart Monkey Test;

因为界面的交互性原因，所以很难将某些功能模块做集成测试，而View代码就成为了一种很好的测试方法，如果代码功底较好的测试在View这段正则表达式的时候就会发现其中的一些问题。

代码看出来错误的难度是很大的，所以建议这里再结合一下SmartMonkey测试（聪明的猴子测试）

设计一只聪明的猴子（程序或者脚本实现），让它在输入框中输入数字，规定好正确的范围，在范围内随机输入版本号，这样的猴子测试存在一定的可能性将问题暴露出来。

总结一下墙角测试的一些方法：

1.对于UI界面的输入检查，可以采用Review Code+Smart MonkeyTest的方法来解决。

2.从软件设计的角度而言，给用户的公开接口开放度越小越好，比如版本号的设计如果用下来菜单选择，将所有可能的情况列出来（情况少的情况），让用户选择而不是输入，其实可以从源头上解决这样的问题，这也需要与开发人员进行交互。