没有测试数据的用例就像一盘散沙，跑两步就跑不动了

没有测试数据，所谓的功能测试和性能测试全都是无米之炊。但我发现一个蛮诡异的事情，就是行业内很少会有人去强调测试数据的重要性，甚至市面上都没有人在做测试数据这门生意。

至今测试er造测试数据还是靠人工写，电话号码、身份证号、地址随便敲个差不多的数据就凑合着用。
或者用Python或js脚本去跑些测试数据出来，当然这要求你得会写脚本，还要熟悉后端业务接口。

这样带来两类问题 ：
1.对于业务数据简单、常规的项目来说，手工临时敲几个测试数据，用来跑完用例没问题；
但如果你在的行业是电商，是保险类，是银行类，项目数据往往都具有特定的数据结构以及业务约束，如果硬要手造的话——只能说你要么特别聪明，要么特别坚强。

2.绝大部分项目的测试执行排期都非常紧凑，往往给不出写数据脚本的时间，何况调试数据脚本，本身也非常费时，特别是业务关联到多个接口和多个系统、且后端接口还处于开发状态的时候。

低成本、快速造出高可用测试数据

所以我这阵子一直在找一些可用于造数据的工具，甚至降低要求半成品也行，只要它能满足我快速，低成本造测试数据的需求就行。

后面找到了一款叫Apifox的工具，它本身不是专门做测试数据的，它更接近于国产Postman，它自己的定位是Apifox=Postman+Swagger+Jmeter+Mock， 也就是集成了接口文档管理，接口调试、测试、mock功能。

但我取我所需，把它的mock和接口自动化功能结合起来用，就成了为我量身定做的测试数据工厂。 接下来我结合这几天的使用经验，给大家分享下要怎么用这款工具来造测试数据。

根据测试数据的类型，我们把它分为常规数据和专有数据，常规数据如姓名，年龄，手机号，邮箱，身份证号等等；
专有数据如电商项目的运单号，物流数据，订单号等。这部分可通过Apifox的mock智能引擎实现。

根据造数据的难易程度可以分为单个接口可直接生成的数据和需要中间变量、通过多个接口生成的测试数据。这部分可在mock的基础上，通过接口自动化实现。

而为了使构造出来的测试数据更加符合业务要求，在这个基础上可以对测试数据添加数据范围约束，mock期望或者使用mock自定义脚本。

基本上是遵循三个步骤：先构建测试数据字段，再构建接口响应数据，修改测试数据使之更符合业务数据要求。

开始造数据

造数据之前，我们还需要一份接口文档，造数据的基本规则是通过跑接口来造数据的。
Apifox支持Swagger、Postman、yapi等20多种格式的接口文档一键导入，所以无论你的团队用的什么接口管理工具，基本上都能无痛导入进来。

如果你跟开发要到的接口文档是word，html格式的，那就先问问为什么2022年了，还要用web1.0时代的东西，是因为村里还没通网吗？然后再骂骂咧咧、手动一个个把接口复制进apifox。

都导入、复制完成之后，一个整洁的项目接口页面如下，接下来就可以开始干活儿了。

使用mock功能造数据字段

对于测试数据中的常规数据，如姓名、电话号码、邮箱、地址等，Apifox已经内置了一批mock规则。
如下所示，Apifox的mock规则兼容mock.js的语法，并且可以通过正则表达式，灵活构造数据规则。可在项目设置-功能设置-mock设置中查看所有内置规则、添加自定义规则。 使用的时候非常简单，选择测试数据对应的接口，在接口请求和响应的参数中选择变量所对应的造数规则，保存并发起请求，则每次都会生成对应的数据。 举例： 我们使用post接口来生成宠物数据。在请求参数mock规则框选择符合该字段要求的造数规则并保存、发起请求。

则接口保存并返回了对应的宠物数据：

生成专有业务数据

上面生成的常规测试数据是直接使用内置造数规则，构造出来的，我们做的操作基本就是做选择题。这确实符合我们之前所说的低成本、高效造测试数据。 如果是一些垂直行业内专用的业务数据，像刚刚说的物流号，订单号，保单号之类的数据。

Apifox的内置mock规则里没有现成可用的，但它提供了自定义mock规则来满足这类需求。
这里不需要复杂的代码，通过一行正则表达式即可完成造数逻辑。至于写出来的这行正则表达式是否能准确概括数据规则，可以通过一些在线的正则表达式检验器去校验，校验成功后才填到mock规则里。

举例：假设项目涉及到物流行业顺丰的运单号，那么可以在项目设置-智能mock设置里，新建一个自定义mock规则，填入一个正确的正则表达式，之后再在接口响应参数里使用该规则

发起包含该字段的接口请求，可得到符合业务要求的运单号数据：

批量造数据

如果需要生成多条测试数据，则可以在接口设计页面-请求参数中设置动态值，动态值的设置同样遵循mock规则，动态值使得每次提交的数据都不同，则对应的能生成不同的新测试数据。

将该用例保存，导入自动化测试中循环执行10次，则会生成10条测试数据。

使用接口自动化造场景数据

有时候一个测试数据可能需要中间数据才能生成，这需要调用到多个接口，涉及到接口间的参数调用和接口关联的问题。 这里我一般是用apifox的接口自动化功能。 鉴于本文不是专门介绍接口自动化的，只稍微提一下用接口自动化来造测试数据的三个关键问题：

参数用例自动生成 单个接口的响应数据构造在上面已经提到，只需要将配置好的用例保存为参数，接着再自动化测试-新建测试用例-导入步骤里绑定这条用例 场景用例一键导入 根据执行一个业务场景所需要的接口按调用顺序进行拖曳排序，模拟实际操作场景

接口变量提取和接口关联 回到单个接口用例中，将供下游接口使用的参数提取到全局变量中，在需要使用上游接口变量的接口的请求参数中调用该变量。

最后再执行整条测试用例，完成最终测试数据的获取。

使用mock期望，自定义mock脚本完善测试数据

造出来的数据，在数据结构上是没问题了，但某些测试场景下可能存在业务约束，需要更加精确一点的测试数据，那可以用到数据约束，自定义mock脚本。

数据约束在确定了响应数据的数据类型如string，boolean等基础之上，还可以在请求参数-高级设置对数据范围进行进一步约束。 如，对body里的某个参数，数据类型为integer,可以在高级设置里，缩小数据的变化范围。

测试数据的管理

用代码写的造数脚本，通常只有写它的人才知道具体的造数逻辑，这个小伙伴离职了就会比较难维护下来。

但是用这个工具的话，造数逻辑还是比较简单的，而且整个团队都能看到具体、详细的规则，不会因为团队里有人走了，脚本就废掉了。

然后因为是造数是通过接口请求去实现的，造数规则是附带在接口请求和响应参数里的，所以如果版本迭代了，接口变了，那造数规则要改的话，也直接在这个接口文档页面改就好， 也不必去改脚本。

尤其是接口增删改了参数，或者修改了数据类型和数据结构，基本上要改的就是一个正则表达式，接着对应参数页面选择新的造数规则。

这个维护难度简单到我都觉得不能叫维护——就只是，顺手一改了。

下载

介绍完用Apifox 造测试数据的几个方法，大家如果有兴趣的话可以自己下载来尝试一下，软件免费，也不用配置什么，直接去 官网下载来安装就能用了。

官网地址：www.apifox.cn