大话测试数据（一）

测试数据在整个测试过程中扮演着极为重要的角色，但是它却像个没有星象的演员，明明至少是男二号，但总是被观众忽略。在测试过程中，我们往往在测试计划阶段就忽略了测试数据，在起先没有给测试数据的设计、准备留出足够的时间，投入足够的精力，到了测试执行阶段追悔莫及。只有吃过大亏的测试人员，才会在下一个测试开始的初期就认真的对待它。楼主也算是吃过亏的人。因此在现在经手的测试工作中，总会提着测试数据这根弦。今天一个网上的一个同学问了一个关于测试数据的问题，随手回答了一下以后，发现自己其实已经积累了一些经验了。现在把它们总结出来,供大家讨论。 欢迎提出各种建议和各种问题，我会试着作出解答。

 

　　测试数据为什么重要：

     1.最浅显的道理：说白了测试用例的执行工作主要是做一些输入操作，然后观察输出。测试数据就是输入的内容，没有测试数据，你咋执行用例？

     2.测试数据是测试设计的重要组成部分，测试用例的有效性严重依赖测试数据的选取或者设计，要记住测试的本质是抽样，样品的选取其实是一门深奥的科学，有学过统计学的同学会深切明白这个道理。

     3.没有把测试数据这一块儿理顺，良好的自动化测试简直是空谈。试想，测试自动化采取的最普遍默模式就是“录制-回放”模式，如果搞不定数据，回放基本上会失败，自动化验证自然也就无法有效完成了。

     4.测试数据能够启发测试设计。做测试多的同学都会有过选取一组测试用例后来了感觉发现自己思如泉涌的经历。

     5.如果是已上线系统，或者生命周期较长的系统，从生产系统上log下来的数据可以很好的指导测试。（通过一些统计可以帮助识别那些业务重要，为能够制定正确的测试策略提供重要信息；对数据做pattern分析的话可以用于补充测试场景、用例，同样十分有益；这些数据还可以在测试中进行复用）。

　　6.其它种种好处。。。

 

     测试数据的分类

     我们可以从多个维度对测试数据进行分类，下面讲一下我的分类方式：

     从测试数据的生命周期角度看可以将测试数据分为：稳定和数据、可消耗的数据和混合类型数据

• 稳定的数据：在一轮/多轮测试执行过程中几乎不会发生变化的数据，如常见的电商系统中的一些基础数据--城市，邮政编码，一些商品的属性，如衣服尺寸码等。
• 可消耗数据：测试执行完某个步骤后，数据发生不可逆改变，或者发生逆转操作需要耗费大量精力的改变。这类数据的例子有：商品的库存，票务系统里的票，要被                    夜维程序删除的过期数据，网络数据包等等。
• 混合类型数据：某些数据是复合型数据，如XML结构或者Json结构的某些数据，一条数据中的一部分是稳定的数据，另一部分是可消耗数据，这样的例子其实很常见，一般这样的数据会被当做可消耗数据来处理。

　　从数据是否可构造的角度来看可以将测试数据分为：可直接构造数据和需要间接获取的数据。

• 可直接构造的数据：常见系统的大部分数据都可以直接被构造，通过操作系统本身，或者通过调用某些接口（SQL也算接口）插入数据，有时候甚至这些数据就是文本，直接准备好他们就行了。
• 需要间接获取的数据：手工制造成本太高（理论上我们可以制造所有测试数据，但有时候就是成本太高），如某些以二进制存储的含有信息的数据（被序列化的数据），某些非文本数据，例如音频数据，视频数据，传感器上传过来的极为复杂的带有某些pattern的数据。举个很好玩的例子，见过“猎曲奇兵”这款软件么？偶然听到一首歌，打开猎曲奇兵，十秒钟左右它就能告诉你是哪一首歌。你基本上无法自己创造一条有效的测试数据，除非你是张学友或者Lady Gaga。

　　从业务角度来看数据可以分为：合规数据、非合规数据、Fuzz数据

• 合规数据：望文生义，就是符合业务规则的数据，如能够通过校验的身份证号。
• 非合规数据：显然就是不符合业务规则的数据，当你被要求输入注册邮箱的时候，你给出这样的输入：skytraveler@@163.com 显然不会合规。　
• Fuzz数据：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.数据项、类型特别多，乱成一团，我怎么去归类这些数据呢？

参考答案：

• 考虑数据对应的现实世界中的事物，如信用卡电子账单，现实中不是有的银行会记纸质账单么？一张账单里的内容从业务角度上会归到一类。就算现实世界中没有的东西，你以前的经验也会从一定程度上自动帮你做规整。比如你玩网游，你选的角色身上的一堆装备就可以归类，有武器，有防具，有药品等等。
• 先画一下业务流，使用UML工具里的用例图，或者时序图把业务流程大致画出来，看看交互的实体有哪些。然后可以根据实体对数据进行归类，这算是一种比较行之有效的方法。如果业务流都画不清，说明设计、需求有问题，数据也不可能清晰。什么？这活儿谁做？不错，搞清这些主要应该是产品、需求、设计人员的工作。但我的建议是我的建议是：如果有可能，协作！
• 其它建模工具也可以，BPMN，数据流图，甚至思维导图，乱乱的草图都会有帮助，逐步细化，总能够分得开。
• 这里是从业务角度来看数据，先不要太考虑技术层面的一些附加数据，如序列号，索引，数据库外键，时间戳等这些东西。那些信息在制造测试数据的时候（后续会讲）再考虑。

 

我做完上述工作的产出是什么？

• 测试人员对被测物更深层次的了解，梳理测试数据的过程其实是一个学习被测物的非常好的过程。
• 干系人对于规约的一致认识，高质量的需求文档。（强烈建议整合到需求中，这样所有干系人才能有一份统一的规约）
• 一些有利于测试工作开展的辅助文档