浅谈对测试数据的选取

 

浅谈对测试数据的选取

1.数据与测试数据

   任何的软件项目都主要是围绕着数据的输入＼输出作为实现的终极目的。其间所要经过的繁琐冗长的处理计算在本文先暂不过多的展开讨论。我们首先回顾一个什么是数据和我们对数据的操作以方便的认识到它在参与计算机的计算过程中如何完成解决实际生活中的问题并同时会有哪些表性的特质。从而为我们设计并建立一个由经验建立起来的坐标系,从而在设计时我们就可以把可能会产生问题的情况更早在项目的地图上标识出来，及早的考虑进去，相比起等问题产生而不得不努力解决问题要节省更多的成本,也是一个项目要追求的核心价值。

    首先数据的定义是对客观事物的符号表示，是关于现实世界中的地方、事件、其他对象或概念的描述。可见计算机一直处理的就是不同的符号体系，数学符号体系，语言符号体系，图像符号体系，声音符号体系及一系列可以更加专业，更加细化的符号集合。它们在计算机里我们就用来作为数据了，而不同的项目就是针对某一种，或者数种联合起来的数据符号进行处理的过程了。而什么又是测试数据呢，笔者目前粗浅的认为通过几种分析方法进而抽象出来的为了最大范围的勾勒出一套描述一组要处理的具有相同属性且在时间与空间上有所定义和限制的数据集合可称为我们要选择的测试数据。

2.测试数据

    那么暂时把一个结论作为目标放在了通盘的蓝图之上后。我们可以尝试从下面的数据流上进行分析来尽早的定义出我们制定测试数据一些基本步骤。

1 定义出项目中不同的功能模块，方便测试区域划分。

2 所测试部分的初始的数据源及产生的数据类型。( 数据的产生者,人,机器.产生的是声音,文字,还是图像等)

3 数据的输入(自动的,手动的……)

4 数据的存储和处理(一个单一的数据元素对象的大小,系统要在一个怎样的时间,空间范围内存储与处理它)

5 对数据的操作和对于它们的处理规则(算法,)

6 实际的输出和期望的输出(存留状态)

    如果我们尝试以上的步骤就可以大致的勾勒出了我们要处理的数据的特征了,那么我们再进一步的把规则内的数据的再分划一下,然后提出具有多种不同临界状态的多组数据出来,也有一部分的测试数据被选择出来了。但是有一点要注意的是,就是规则外的数据也会是我们的测试数据,我在下边的反向测试部分说明了一下我是对这部的数据一些观点。

继续我们对刚才对提取测试数据的剖析,看看将上面的分析方法与我的目前工作结合起来并是如何挑选较为合适的测试数据的。首先如果一个测试的功能区的数据是由其它系统发送过来的,就可以首先知道该数据已经是经过一组规则过滤过的,那么就可以尽量少的关注规则外的反向测试数据,而选择一组前面提到过的接近规则临界状态的值来测试.如最大的字段长度,最小的字段长度记录，如一套银行货币系统，当发生了货币换算的情况下一个货币值被扩大或缩小的边界值情况。或一套OA系统有频繁的文件上传/下载，则此文件的最大容量上限也可选作为一个测试数据.这样便可在系统全部构建好后可以保证我们的测试通道畅通,而且利于更早的发现系统瓶颈.提高测试用例的重用性.

在这里我想说在考虑临界状态时不能仅定义为静态，而是要考虑到它在进入第三步即数据处理后会达到一个怎样的量级,如前面被提到的被频繁修改的文件，重新生成后的状态也要有所考虑。当然这部分测试问题更多的是在进行系统的负载测试时才能暴露出来的。但恰当的测试数据会更早更明确的在测试开始时就引发系统的缺陷，这是测试数据为测试工作所作的最有价值的贡献。

    上面的测试数据的选择是针对项目局部系统来进行选取的，一个成熟的针对某一项目的测试最初应当是由API级别的测试堆叠起来的，如果一个大型系统的API集合所有用到的测试数据都被收集起来,并在后续的系统联合测试时可以通过的话，无颖将得到一个很高的测试覆盖率。这里整体的测试框架不是本文要涉及的问题，就不予展开讨论了。

区别以上的系统，一些居于二线的独立的功能系统,可能更多是只有几个小的模块分布相互依赖较为松散，那么对于此类更倾向于只需要进行轻量级测试工作的项目可以无需开展进行API级别的测试，而直接针对全工作流程的测试了。即尽量保证模块单元能处理的数据范围在测试数据中已有所覆盖。以一个简单B/S结构的程序为例，我们在UI层输入的数据经过很少的中间处理就贯穿了整个系统直接送达数据库了，这种没有用API剥离开的层次结构的测试数据我们就有必要尽早选取一些会暴露系统安全的数据比较好一些，例如常见的SQL注入字符的选取。这种非业务逻辑的测试数据很容易就可以用正则表达式来解决.但需要业务逻辑支持的测试数据，我仍倾向于按照上面的方法来指导推演找出更高的系统漏洞.

最后我再谈一谈在负面或称反向测试层面上我们所进行的测试数据选择，我个人认为这部分的测试工作应划分入系统安全性的测试之中。基本这一类的测试数据基本上是比较通用的，建立一个这类数据的用例库也相对容易。例如：SQL注入、字段长度、数字边界、日期、会话超时等等,这样的测试数据我个人觉得应该是系统的次重点，因为没有任何系统可以进行满足穷举的测试数据。不作为重点并不意味着不重视，而是在项目成本控制下有所重点的关注，不能求末逐本的把时间浪费在思考如何使系统不好使上面。这就需要项目组人员更加智慧的来权衡它的比重了。

在测试数据的选择上我们要尽量跳出数字符号的范畴，因为很多领域的实际应用并不是单纯的银行汇票，作为一名软件人。我们要保证的产品质量可能是很多不同行业的，如在一个图像处理的系统中，测试的数据我们不仅要从它的大小，可能还要看它的色彩明暗上判断某一函数是否有效。而在一套自动化的锅炉供暖系统中，我们可能还要用温度计去不同的管线节点，找出我们的测试数据范围（笔者偶尔从同学那了解到这个有趣的话题）等许多我们未曾接触过的广泛领域。

    作者以上针对测试数据的几点看法更多都是基于理想化的项目流程下的，故可能只适合项目人员作为实施前的参考。其间要对每一点都在项目都有所体现要更大程度上的依赖于实施人员的素质与经验了。不过有计划的选择了高质量的测试数据将会对后续的更高级的测试工作性能测试，或者进行到回归测试等打下一个良好的基础，也是持续改进质量软件质量的有力支持。