测试数据为什么重要:
1.最浅显的道理:说白了测试用例的执行工作主要是做一些输入操作,然后观察输出。测试数据就是输入的内容,没有测试数据,你咋执行用例?
2.测试数据是测试设计的重要组成部分,测试用例的有效性严重依赖测试数据的选取或者设计,要记住测试的本质是抽样,样品的选取其实是一门深奥的科学,有学过统计学的同学会深切明白这个道理。
3.没有把测试数据这一块儿理顺,良好的自动化测试简直是空谈。试想,测试自动化采取的最普遍默模式就是“录制-回放”模式,如果搞不定数据,回放基本上会失败,自动化验证自然也就无法有效完成了。
4.测试数据能够启发测试设计。做测试多的同学都会有过选取一组测试用例后来了感觉发现自己思如泉涌的经历。
5.如果是已上线系统,或者生命周期较长的系统,从生产系统上log下来的数据可以很好的指导测试。(通过一些统计可以帮助识别那些业务重要,为能够制定正确的测试策略提供重要信息;对数据做pattern分析的话可以用于补充测试场景、用例,同样十分有益;这些数据还可以在测试中进行复用)。
6.其它种种好处。。。
测试数据的分类
我们可以从多个维度对测试数据进行分类,下面讲一下我的分类方式:
从测试数据的生命周期角度看可以将测试数据分为:稳定和数据、可消耗的数据和混合类型数据
从数据是否可构造的角度来看可以将测试数据分为:可直接构造数据和需要间接获取的数据。
从业务角度来看数据可以分为:合规数据、非合规数据、Fuzz数据
从测试数据来源来看,可以分为:生产dump数据,自己生成的数据
上面的分类其实并不是很准确,但是分类就是为了帮助更高效的解决问题。接下来我会讲解对于上面类型的数据我是如何来处理的。
测试数据的生成过程
概念上的数据:也就是抽象的数据,例如,你的被测物是一款收银软件,你知道每笔交易结束后,需要生成一张“发票”,见过发票的你大概知道 它长什么样子(如下图),“发票”就是概念上的数据,但它并不能直接使用。
被细化了的数据:也就是具体的数据项。拿到发票后,我们还要分析发票里到底有哪些数据,经过需求的获取及分析,我们知道发票包含:发票日期,发票代码,付款方,收款方,金额,防伪码,二维码等。同时我们也知道了这些数据的规约,例如,发票的日期格式是:yyyy年mm月dd日。
真正能使用的数据:我们知道了数据的细节,就可以按照这些细节准备被测系统能够识别和接受的数据了。例如,上面所说的发票付款方,收款方,真正的操作可能会直接在GUI中输入,或者可以调用某些接口,或者可以直接插入数据库。这时候你要做的就是,让你的数据变得能用起来。
从上面的解释可以得到测试数据从被识别,到能够被使用的大体步骤:
事实上,实际工作中,测试数据的准备远远不是这么简单。很多时候上面的每一步骤的推动都是一个艰苦的过程。搞定它需要柯南一样抽丝剥茧的能力和工匠的细致和耐心。我会尽量在后续的文章中讲述一些我的经验。
--------------------------------------------------------------------------------------------------------------------------
本篇是大话测试的第二篇,如果你对测试数据感兴趣,又是第一次看到这篇,请先翻看大话测试数据一
概念测试数据的获取
在上篇中,我提到,获取数据的第一步是获取概念上数据。这一步看起来简单,其实不是那么容易。获取概念数据和获取需求的过程是交织在一起的,事实上,它们其实是一个事儿,因为数据是需求中最重要的组成部分。需求工程是个大话题,目前有很多种流派和实践方式来来搞定需求,但它们的思想都比较一致,那就是:不断的由粗到精的迭代(如下图)。关于需求这里不再展开,不在如果大家有兴趣的话,推荐两本我觉得还不错的书:德国人写的《需求工程,基础原理和技术》和国人写的《软件需求最佳实践》,大家读后结合工作做比较会很有收获。
由上述文字可知,(测试)数据获取也是一个迭代的过程。实际上在项目早期,我们就能获得概念数据。概念数据是什么呢?用大白话说就是:这种数据叫什么,大体啥样子,是干嘛用的。举个例子:如果你的项目是一个信用卡项目,项目有一个功能就是,每月给用户发送“电子对账单”。对于80后,甚至90后的你,一秒钟你就知道这个“电子对账单”大概将会是个什么东西了。“不就是一封电子邮件里放一个网页,里边告诉用户:尊敬的某某先生/小姐!您本月消费了几笔,每笔多少钱,都是哪一天花的。最重要的是,您在本月X日前必须把钱还了。“这样你就建立了对“电子对账单”这种测试数据的概念,也就是说得到了“电子对账单”这种概念的测试数据。
Pretty easy?事实没有那么简单的。事情的本质是:你有一个超级聪明的大脑,能瞬间把你的经验综合起来对需要识别的东西作一判断,并给出一个大致的评估。但如果你大脑没有相关的知识,你就没有那么幸运了。不信,请读一下下图中的文字:
脂多糖是神马?膜蛋白复合体是神马?神马是beta链?桶壁是神马????这特么的都是神马?如果你没有一些生物学知识、高中生物又不幸光睡觉了的话,这段选自《环球科学》的文字不会让你觉得比读日文简单。因此识别概念上的测试数据,你脑子里还得有点儿货才行,这些货是:“技术层面的知识”,“业务层面的知识(领域知识)”,“对于产品本身的认识”,还有“你的常识”。这四点的总结是从测试大师James Bach的课程中获取的,你可以从这里下载他关于快速软件测试的胶片。
你说了,没有这些知识怎么办?答案特别简单,“学啊”!。勤学勤问勤练勤观察,入行几年后,如果不是特别懒惰,前三项都会提高到一个不错的高度。这些都变成了你的价值。经过一段时间爬坡,你就可以很快的获取概念测试数据了。
你说了,废话,我也知道要学,但有没有更具体点儿的?干货,有么?要能咯掉牙的!
好吧,给个干货的链接,你就当它是个checklist,按图索骥吧:关于测试数据的获取(不仅仅是概念测试数据的获取),测试思路的获取,甚至是需求的获取,可以参考这篇文章(抱歉,是英文的),你一定会有收获。
btw,这篇其实废话多点儿, 下两篇是能咯掉牙的。
举个栗子:
接着第二篇的一个小例子“电子对账单”来说吧。
细化的数据就是我们要从逻辑角度识别它的内容和规约。所谓内容,就是数据的是什么?所谓规约就是数据必须符合什么样的规定。我们先来看看信用卡账单长什么样子:
从业务上,它可以分为两部分:行用卡账户信息,和交易明细。账户信息部分如下面截图。
我们可以说,信用卡账户信息的内容有下面几项:卡号,本期应还,本期最低还,还款到期日,清算货币,信用额这些项。每一个数据项有它的规约,在这里,我们叫做业务规约。
抽取数据的过程:
上边的例子貌似很简单:但是我的问题来了,我这是举了一个现成的栗子,真实情况下呢?如何弄清内容有多少,还有每一项内容的业务规约是什么?
我得说,看你运气了。如果运气好,你可以从需求说明书中拿到完整的规约。但测试人员好像都不是那么运气好的人,我们会遇到各种不靠谱的需求。这时候要弄清规约,你可以做的事情有:
1.需求评审,把干系方叫来,一项一项的过。
2.从需求以外的文档搜寻出一些信息,再评审确认。
3.从原有系统中获取。这里的获取方式有:直接在原有系统上尝试,原有系统用户访谈,阅读原有系统文档,阅读原有系统源码。
4.从公司规范、行业规范、国标、国际标准组织规范中获取信息,如,信用卡号的标注,你可以从数个国际标准委员会,支付联盟(如MasterCard,VISA)得到明确的编码协议,咱们的银联也有编码协议。又如身份证号码就会符合国标 GB 11643-1999 各种大型系统中,这些规范协议文档相当重要,因为涉及到系统集成,大家要遵循相同的标准。
5.惯用规范,如日期,时间,地名,职业等一些通用叫法,当然这些也会有标准委员会去界定。
6.不断的迭代验证上面的信息源,但每一段时间都应该文档化文档化并在合适的时候做专家评审,干系人评审。上周我就收获了一个反向案例:我们做了上述5条,并开始了准备测试数据,但是开发的接口改了(少加了一个数据项),导致我的小伙伴修改了大几百份测试数据,这个变更发生在3天之内,第3个工作日我的小伙伴才发现,幸好发现的早。这也说明了迭代的重要性。
7.能够推动在需求的早期关注数据项及其规约,后续的测试将会省却不少麻烦。《实例化需求》是一种非常好的实践方法,大力推荐你反复阅读这本书。
8.测试数据需求的挖掘同测试需求的挖掘,同需求的挖掘其实可以是一件事情《实例化需求》这本书中也有讲这些方法。
一个难点:
下面说一下测试人员感觉比较困难的地方,这也是我经常被问的一些问题,我试着给出一些答案,欢迎大家来讨论。
1.数据项、类型特别多,乱成一团,我怎么去归类这些数据呢?
参考答案:
我做完上述工作的产出是什么?