如何对数据进行测试?

发表于:2013-01-10来源:生生不息作者:circleoflife点击数: 标签:数据测试
如何对数据进行测试?前两天在阿里技术嘉年华上分享了一个有关《报表类型的数据测试》的话题,发现很多人的遇到了我之前测试时候遇到的问题,我相信我们之前走过的弯路,以及最后的解决方案和经验,就可以帮助大家构建出更好的数据测试用例。

  前两天在阿里技术嘉年华上分享了一个有关《报表类型的数据测试》的话题,发现很多人的遇到了我之前测试时候遇到的问题,我相信我们之前走过的弯路,以及最后的解决方案和经验,就可以帮助大家构建出更好的数据测试用例

  所以我决定写一系列关于数据测试的文章,帮助大家避免我们曾经遇到过的问题,建立起强壮的自动化测试用例。

  这系列文章不是:

  1. 我们不针对敏捷测试,不专门讲持续集成等战略上的概念,战略上讲,这些东西很重要,但是依然要落在每一个强壮和易维护的自动化测试用例上。

  2. 我们不推荐框架,更多的讲思想和做法。因为我们在开始做这些工作之前,并没有在市面上找到合适的解决我们问题的框架,所以我们只能从头开始。好处是可以从很基本的方面理解我们的思想,坏处是没有现成可用的工具。不过不用担心,我们非常乐意把自己的框架开源出来,但是要整理一下。

  3. 我们不讲UI的测试,因为我们的数据测试会更加专注于数据,如果你要测试UI上的数据,那么请先学习UI自动化测试框架,把这些数据获取好。

  这系列文章会:

  1. 用我们实际中的例子对数据测试进行系统的讲解。如果你可以从我的例子中找到平时工作的影子,那么你一定会有所收获。

  2. 文章中不仅仅会涉及数据测试方面的内容,为了讲明白我为什么这么设计框架,我可能还会提及其他自动化测试方面的东西,略嫌啰嗦请海涵。

  那么言归正传,什么是数据测试呢?

  数据测试不是一种测试方法,而是一种针对特定的被测对象所采取的一系列方法,提高这些被测对象测试效率的方法。

  我定义我们的被测对象是:一切以数据计算和变化为过程的,可以以只对数据进行对比来测试的系统。

  我和你一样讨厌晦涩的定义,我以几个例子来解释:

  1. 我们团队的最著名产品:量子恒道店铺统计,整体来说,因为有很多UI方面的测试,这些测试很多地方不能单靠数据来验证,所以整体来说量子店铺统计不是数据测试的被测对象;但是我们拆开来看,量子恒道的所有后台计算,都是数据测试的被测对象,因为他们从数据开始,经过计算,生成的都是数据。

  2. 一个负责在网络集群之间传递消息的消息中间件,不是数据测试的被测对象。他们虽然输入是数据,输出依然是数据,也可能进行了数据的计算,但是测试重点在于网络的可用和稳定,数据测试不是我们的测试重点,所以不是。

  3. Hadoop, hive, storm等平台本身不是我们的被测试对象,但是基于这些平台写的应用,全部可以是数据测试的被测试对象。

  4. 某网站的OpenAPI,可以是数据测试对象,因为用户都是从http请求请求数据,经过数据库,然后通过http响应返回相应的数据。

  5. 一个MVC架构的网站,除掉V之后的部分是吗?大部分情况,是的,但是如果这个网站的M和C层组成的是一套完整的增删改查业务体系的话,我并不推荐数据测试的方法,原因见文章:《用白盒的思想黑盒的测试》

  6. 某银行的数据库搬迁服务,是数据测试对象。

  总之一句话,当测试人员的关注点在于数据是否正确,而不是其他流程、UI、性能等地方的时候,那么你就需要数据测试了。

  不知道你有没有找到自己工作中的数据被测对象呢?

  如果已经读了上一篇文章《深入探究数据测试之一:数据测试概论》,相信大家已经对数据测试有了更加详细的理解,也有可能找到了现实测试中的具体例子。

  我们第一步要做的事情,是封装你的无关操作。而这一步的基础,就是设计自动化测试用例。

  什么是无关操作?无关操作是和期望操作正好相反的一个概念。

  测试人员的期望操作,就是要写在自动化测试用例里面的代码的最理想状况。所以无关操作就是你不想写在自动化测试用例里面的代码。拿下面这个测试来举例:

  第一个例子:假设我们要测试一个hive脚本:(如果你熟悉hive,那么你应该可以看出我代码所指的事情,如果你没有用过hive,那么就把hive看成是一种sql语言就好了)

  读了上一篇文章《深入探究数据测试之二:设计你的自动化测试用例》,相信你已经对自己未来的自动化测试用例代码有所了解。这篇文章,我们就来谈谈在一淘,我们如何封装这些无关操作。这里就要讲讲我们为封装操作专门开发的框架SmartTest。

  首先要知道,代码不可能无故减少,只能是被封装了而已。也就是说,上一篇的第一个例子中间所做的所有的事情,一样都不能少,而是仅仅被搬到其他地方而已。

  那么搬到什么地方了呢?我们这里提出一个概念,叫做测试应用。测试应用就是把所有的测试的过程和被测试对象的建模行为封装好的一个类。这个类将所有的测试过程全部纳入到每一个类函数中,而把动态的信息暴露出来,允许用户设置。

  如上一篇博文的第二个例子,underTest就是一个测试应用。也许你会说,原来就是把之前的代码全部搬入到underTest的go函数中啊,这简单。但是如果是仅仅的这么搬家,那么这个封装就太无聊了。

  做搬家之前,我们将会对整个测试过程进行阶段划分:

  如上图,我们可以看出,我们使用测试应用,定义了一个自动化测试用例的运行的三个阶段:setup, run和teardown。每一个阶段又划分了若干步骤:

  Setup的cleanEvironment步骤:负责清理环境,确保这个测试用例可以正确执行。好的习惯是每一次测试用例运行完毕之后清理一次,但是却不能保证如果测试用例运行失败或者中途退出导致没有进行环境清理,而且很多情况会需要现场环境进行错误排查,所以我们将清理环境放在了每个测试用例之前。

  Setup的generateConfig步骤,被测试对象总有多多少少的config配置,这一步就是将这些配置设置成为测试用例需要的配置,然后放置在合适的地方。

  Setup的generateData步骤,这一步是至关重要的步骤,因为我们是数据测试,这个阶段需要将需要的数据生成出来,放在合适的位置,等待被测试程序取用。我们后面的章节会对这一个阶段做的事情进行更加全面的讲解。

  Setup的StartRefService步骤,将本次测试的依赖服务启动起来,可能是mysql,可能是httpd,看被测试系统的应用场景。

原文转自:http://www.ltesting.net