数据构造那些事儿

业务背景

1、A 系统订单状态流转，需要依赖 B 系统售卖结果，B 系统售卖结果依赖 C 系统库存结果，操作 A 系统订单状态流转，就需要调用到另外两个系统的链路

2、B 系统售卖结果，内部调用逻辑复杂，链路调 4-5 次才会去判断 C 系统的库存

3、A 系统商品数据，需要去查 D 系统商品数据，而 D 系统商品又依赖 C 系统的库数据

4、A 接口调用 C 方法，返回参数校验 D 方法，D 方法匹配结果查询数据库结果，返回数据调用 B 方法，组合返回给 A 接口

……

真实的业务场景是错综复杂，要一个场景一场景人工验证，耗费人力和时间太多太多

本文主要介绍如何利用数据构造提高测试效率和经验总结：

一、什么是数据构造

数据构造顾名思义就是造数据，常用来构造测试数据，主要作用提升工作效率。

众所周知在日常测试过程中，会频繁造数来验证各种场景，其中包括功能测试、沙箱测试、生产验证、性能测试等等，需测试人员花费很多的时间准备大量的数据，且有些场景复杂或涉及多方系统，工作中不可避免，为解决这个痛点，衍生了很多的造数方式，从而提高工作效率，以下内容结合日常工作阐述下一些关于数据构造的一些见解~

二、常用的数据构造方式

数据构造的方式有很多种，下面介绍下常见的几种数据构造方式

三、我们怎么做数据构造的

数据构造主要是使用 QA 自研的 datapt 平台，前端采用低代码平台配置+后端 java 代码实现具体数据构造逻辑方法，不同业务团队写好后端逻辑代码，使用前端进行配置即可使用。

下面以深圳侧金融测试小组来进行剖析，这里面主要的核心设计以及思想来自组长前期在框架上的设计基础，以及我在后期维护过程的个人理解做一个总结。

1、勇于尝试从 0 到 1

开发一次数据构造，是需要一定的技术基础的（java 代码能力和对业务链路熟悉程度），我本身对 java 认知主要还是来自于理论知识上居多，缺少实际编写能力，由于以往的工作使用 python 相对多些，接触到新语言是比较弱势的，相信很多同学也会遇到这个困扰。

那么，完成一次数据构造，我是如何从 0 到 1 呢，这里面离不开组长以及 QA 团队、RD 团队各位小伙伴的鼓励和支持，再加上自身对技术有着浓厚的兴趣，通过 B 站以及一些其他方式进行学习，慢慢的开始尝试写一些简单的数据构造场景

后端实现造数后，确实内心还是有一点窃喜的，从业务流程梳理链路，并组成对应数据构造方法，不仅能更了解和熟悉业务，还能提升 java 技术能力，何乐而不为呢！经过几个月的学习和实践，到目前为止，我们的小组全员都已经能独立参与数据构造开发。

2、用最简单的方式实现

基于测试人员对于用户体验的认知，所以我们在写数据构造的时候，尽可能简化入参，减少使用成本、下面是一些方法论

• • 能不填参数，尽量就不填（比如一些参数可随机就尽量随机生成并保留支持手动指定输入）

• • 能填简单参数，决不用复杂参数（例如：能用手机号绝不让填写用户 id）

• • 能整合的业务场景，尽量放一起（例如入库需对接外部系统依赖调用等等，则整合成一键入库到上架）

• • 能选择的，则不用输入（多种参数或场景做成下拉框方式）

• • 参数使用，能从上一个接口自动带过来，就配置直接带过来，减少重复录入动作

• 
  

3、复杂关联场景拆分

例如一个下单场景就有几十种流转方式，而我们采用场景拆分（代码层面不同场景上下文进行关联），根据不同流转状态，能随心所欲造出不同节点的场景。

除了上面的场景构造，我们还支持从任意场景进行扭转到任意正向场景的功能，提高验证便捷性

构造完成，推送结果通知 

4、让更多的人用起来

数据构造开发，由于前期是 QA 统一输出的，所以每次有创新或更改都会及时同步到团队当中，目前使用群体不仅仅 QA，甚至于 RD 和产品也都在使用数据构造快速造数据，同步方式有以下几种：

• • 采用会议同步的方式进行统一宣传

• • 在完成新的数据构造，主动同步出来，让更多的人去使用

• • 不断的去收集一些需求，解决其他同学造数痛点

5、做一个最好的售后

我们不一定是最好的开发，但一定是最好的售后。在使用过程中难免遇到各种各样的问题，毕竟在编码能力确实有不如开发的地方，在编写代码的逻辑和严谨性也存在考虑不全面，有开发在使用过程遇到问题，还开玩笑的说要给你们 QA 提个 bug 哦，这些反馈上来的问题我们很欣然的接受，并且尝试着去解决它，在很大程度会得到别人对测试团队的信任和认可（有点偷偷乐着，以前是给开发提 bug，现在反过来是开发给我们提 bug）。

6、数据构造前置化

前置化，在这里我们理解为项目在开发中或者测试中，就得把数据构造场景提前准备好。

通常数据构造后端调用的代码方法都是项目的代码，基于稳定性来说，可能在上线后来维护是最好的，至少不会有 bug。但是我们为什么要把数据构造前置呢？我们一起来看看好处：

1）提前调用业务代码，通过数据构造场景调用，也是实现业务代码测试，达到白盒测试的效果

2）数据构造通常是链路调用造数，对业务链路也能覆盖到位

3）提高代码覆盖率

4）测试左移，提前介入到业务逻辑测试，满足开发自测的条件

5）解决测试后期造数困难的问题

6）场景构造过程提前了解业务代码实现的合理性和可靠性，避免存在问题等到测试中或上线后才发现

7）对验收流程帮助大，场景构造好了，可以随时使用，也或重复使用

8）让 QA 同学更好的理解业务代码

……

举个例子：我们有一个需求，主要是引入外部供应商的商品到内部平台的仓库，这个需求需要频繁构造大量入库数据，我们在预知这个情况后，我们提前把批量造数功能进行实现，从而在后期功能测试回归测试起到关键性作用。

7、数据共建

上述已大致有讲到使用群体有包含 RD，若长期只是 QA 来维护，也是会存在一些短板的，所以我们决定到数据构造工程和开发一起共建，通过一些业务项目的开发，需要开发数据构造场景，让 RD 同步参与进来一起开发，达到长期共建的效果，能更好的服务于团队。

其实共同开发数据构造已经在践行了，已经有部分的开发同学参与了数据构造工程开发，他们相对更加专业，定位问题更加直接，他们参与进来很大程度是对于数据构造的依赖，做场景的补充。如果能有更多的开发同学参与进来，我相信数据构造会越来越好。

四、总结-价值体现

上述内容说了那么多，我们也做了那么多，那它究竟能给我们带来什么价值呢，我们的动力来自哪里？

在这里分享一下价值体现的总结：

1、给开发自测提供了很大的支持力度，尤其给前端同学造数带来的很大的便利性

2、在不同测试阶段，大大降低了测试人员造数的成本，快速提高工作效率

3、对于外部测试同学做上下游系统关联场景验证时，可以一键即达，满足全流程测试验证，提高关联系统的验证效率

4、提升了测试人员专业技能，代码能力，同时得到其他部门对测试人员的认可

5、提升业务回归测试的效率，

6、不同数据场景，覆盖不同的代码框架，对代码覆盖率起到了很好的效果

7、通过场景构造提升测试人员对于系统技术实现方式有更多的了解，在测试过程中也能考虑更多的场景

8、编写数据构造对测试人员业务理解有很大的帮助

......

愿景：用技术支撑助力业务高效运作，只要数据构造写的好，下班就能下的早~~~

作者：刘永强

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」（综合性）、「大转转 FE」（专注于 FE）、「转转 QA」（专注于 QA），更多干货实践，欢迎交流分享~