业务背景
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、编写数据构造对测试人员业务理解有很大的帮助。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
