提效赋能利器：数据工厂

前言

在日常功能测试中，我们需要创建测试数据；
在自动化测试中，我们也需要创建测试数据；
在不同环境中，也需要分别去创建不同的测试数据；
在链路测试中，不仅底层应用需要创建测试数据，上层应用场景测试也需要创建测试数据。

创建测试数据这件事情本身并没有错，但是有没有更高效的处理方式呢？

比如同一个场景，但是因为所属业务线不同，导致大家测试的关注点是不一样的，为了不干扰彼此的测试结果，基本都是各自创建各自的测试数据，这带来了很大的资产，资源浪费。

又比如在整个测试活动里面：联调-冒烟-提测-预发-发布，这几个环节里面都涉及测试数据的生成，再加上不同角色对同一测试数据的需求，这个量就更大了。如果是微服务架构，越是上游越对基础数据依赖更甚。

正文

为了减少测试数据创建的耗费的时间，这个时候一般就会想到数据工厂，而一个完备的数据工厂需要经历以下4个阶段：

一、单应用业务内部产出生成各类业务特征的测试数据服务

二、提供对外测试数据服务赋能的能力，比如搭建数据工厂平台

三、链路式测试数据服务能力提供

四、测试环境稳定后，复用测试数据服务能力，衍生到线上环境，提供线上测试数据生产的能力

第一阶段

这个阶段单应用产出生成各类业务特性的测试数据服务，看业务复杂度，主要有以下2种方式：

1、通过sql脚本组装各类数据之间的关联关系

2、通过已有的工程服务，自己组装参数，这种方式对工程服务的正确性要求比较高，一般是在服务稳定的基础上才采用

第二阶段

第一个阶段服务的影响范围主要集中在团队内部，到了第二阶段后，需要扩大使用范围，并将各个业务应用对应的测试数据服务集中起来管理，此时数据工厂便诞生了。根据人员能力的不同，数据工厂也存在几种不同的形式：

第一种：仅提供测试数据服务集中管理的能力，这类数据工厂只需要提供业务线-接口-参数-调用日志这4类基础的管理功能即可，但是这类对各业务线的QA要求较高，需要具备代码编写能力。各业务线自主产生自己业务的测试数据创建服务。

第二种：公司内部存在单独的自动化部门，由这类人员统一去产出，直接赋能给业务线的QA。这种形式类似于装修中的全包模式。

第三阶段

经历过第二阶段后，这些服务都已经被很好的管理起来了，但是服务和服务之间都是单点的，而真实的业务是链路式的，此时就需要我们将有业务关联的服务前后串联起来，直接一次性生成链路式测试数据，而不需要QA介入一个服务调用完毕后，在去使用第二个、第三个，乃至第N个服务了。这种情况对最上游的业务QA来说是最能提效的。链路式服务这种做的好的也会存在以下形态：

1、硬代码，人为主动将这些服务串联好作为一个整体对外提供

2、通过流程编排自主将需要的服务节点给串起来，这个可由使用人员自主组合

第二种形态对工程能力要求比较高，除非业务特别负责，一般情况下，基本都会选择第一种形态。

第四阶段

经历过前面几个阶段后，已经可以很好的在测试阶段运转起来了，为了最大化这种服务能力，也为了更好的缩短线上功能验收时间和效率，会将这类服务也赋能到线上环境。当然这种情况，仅限于基于已有工程的服务自主去组装测试数据这种模式，因为线上的数据库处于安全考虑，并不会对正式服务以外提供写操作权限的。而且这种对于大技改类的架构调整收益会特别明显，因为一般这类项目里面对测试数据的需求量比较大。

当然，有便捷就会有风险。这个阶段，能力被复用且衍生到了线上，虽然开心但也不能大意，需要做好线上测试数据的管理，包括管控测试数据在线上的露出风险，测试数据服务的稳定性等，以免产生脏数据影响到了线上功能等。

至此，对于数据工厂的部分就介绍完毕了。有更好的想法欢迎留言讨论。