数据探索式测试（3）

输入数据测试3：

（一）自我检测法：

软件的输入数据，在某种程度上是存在着固定的一些规则的，而往往程序员如果不熟悉所测行业业务的话，所执行的case就很可能仅仅局限于需求所提供的检查项，而一些规则性质的东西，一旦在需求中描述不够精确就更很容易造成用例覆盖率的遗漏。

举一个生活中的例子与之比较，就好像你给一个非计算机专业的人远程讲解如何安装操作系统一样，你十分详细的说了怎么操作，然而那边却还是一愁莫展，最后你火急火燎的跑过去，结果一看，那边还在纠结怎么处理镜像文件。然后你就会发牢骚，这个镜像文件不是肯定会装的吗？对于你而言是肯定的事情，但对于别人而言不会也是常理之中。

软件从系统设计层面到软件需求层面再到架构层面，有多少情况是忽略了那些顶层设计“习以为常”的规则和原则。当软件到了测试人员手中以后，如果只根据那么“半成品”的需求来测试，将会忽略掉许多功能点。

这也将会成为你变成优秀测试的重要条件之一——熟悉业务流程。那么怎样能够尽量避免这样的问题，或者说怎样能够成为一个优秀的测试人员呐？

这里提出了一个自我检测的方法，就是对取得的输入数据做测试前的预先检查，对于大量数据而言，人工检查输入数据的工作量巨大。所以一个合理的解决方案是通过脚本来完成这一轮数据的预检测，下面举一个实际测试中的小例子：

输入的数据是Excel表格，其中有一个很简单的原则：

coordinate			Type	Inform area
user
track	chainage	Or
2	104.27	0	0	61.00
1	104.27	0	0	61.00
2	175.42	1	0
1	175.42	1	0	301.72
2	225.57	0	0	105.27
1	302.72	1	0	346.00
2	379.28	0	0	302.00
1	379.28	0	0

上表中需要当Or的值为0时，chainage的值要大于Inform area的值，当Or为1时，chainage的值要小于Inform area的值，这条原则并没有出现在需求文档中，所以在测试中就没有测试这条需求。而开发人员对需求的理解有不够全面，导致这个Bug一直没有被发现。

其实这类问题最好的解决方法是在数据设设计时就通过某些方法来防护住这个问题，使之不出现这样的设计缺陷。

从测试的角度，可以做到的是当获取到测试数据时先来一次预检测，这里提供一种解决方案：

在Excel表格中写VBA脚本，做一个简单的判断，然后设计报错机制。当数据测试之前，先在VBA中跑一次，如果出现问题则返回给数据设计，报出问题，尽早反馈。

同样这样的脚本也可以成为测试用例，而不仅仅是依据需求文档。所有的预处理脚本处理的问题都应该成为故障输入的测试用例之一。

如果可以在需求文档评审阶段就可以根据所有的预检测脚本提出需求的问题，其实能很大程度上节约后期出现Bug后修改的成本。

下面是自我检测法的几个注意点：

1.注意数据预处理脚本语言的灵活性和积累，这样可以应对需求多变更新较快的软件。

2.在文档审查阶段就可以由脚本导出一份Checklist，然后比对需求，提出Comments

3.可以托管脚本代码，让公司的各个参与者都可以来完善脚本实现，当然，这就要求脚本工具的封装性和可拓展性很高了。