编写目的
1、为什么要写这这块内容
①记录实践过程，组内讨论学习
②另外希望有朋友一起来讨论，怎么可以针对不同的项目达到最佳实践
谈到接口自动化测试，印象里网上的教程，一般都是工具介绍、入门级介绍（有API文档，入参个位数，出参完善易懂），给人的感觉都是泡杯茶，它就自己唰唰唰的测试完了，还有完善的测试报告，节省了好多人力。
以前也有做过简单的项目，emmmmm，确实容易。这次负责的是大型的ERP项目，人手少，业务复杂，一开始真的无从入手。
先说明下项目业务，业务中业务链很长（长的一条链路中走的接口上百），业务链分支多。
下图为其中一个业务链的部分内容：
手工测试中有两个主要痛点：
1、前置数据构造繁琐：如上图，假如需要测试收款单，则需要准备前置数据订单->计划->账单，花费14分钟（这里的时间指的是无脑构造，实际中一般都会大于）准备，然后才开始正式测试。
2、业务表单复杂，分支多：如订单，字段数超过150+，其中的一些字段是嵌套的json（服务明细）；然后订单的类别超过120+，还有各种不同的计费方式等，即case数极多，修改其中一个场景，需要回归的case量很大。
因此自动化的方案上考虑分成两块，1、2两块互相补充：
1、自动化测试：这块主要在自动化测试环境执行，做回归测试，执行前获取mysqlbinlog的节点，执行后还原至该节点；
2、自动构造数据：这块主要用于手工测试环境准备各个节点数据，减少前置数据构造时间，每个节点都会不停构造可用数据，设置阙值为10，小于10时自动新增该节点数据。
其中的难点在于数据：
接口用数据：每个接口case量很多，每个case的data构造耗时都很多，工作量极大极大。这里考虑与手工测试相结合，各个接口封装对应的从DB获取数据，生成api用data（可跨环境获取）的方法：其中数据分成sourcedata（来源数据，一般来源于手工测试后存储在DB的数据）+prefixdata（前置数据，比如订单提交审批，会用到草稿的订单的ID等）-->处理后的数据processeddata-->映射成apidata。每次同一场景新增case，只需要添加用例名+数据主键。
前置数据：
①常见方案一：在用例prepare部分，调用前置的接口来新增数据，这种方案在业务链较短的业务中适用，长业务链的话会导致用例执行速度很慢，且稳定性较低。
②常见方案二：先人工准备好各个用例的前置数据（也可以用前置接口的脚本来生成），每次执行完自动化脚本后，回滚数据库，则可以反复使用。如果只是做自动化测试，那么这种方案就可以了。
③方案三：因为考虑要减少手工测试构造数据时间，因此在手工测试环境，不能还原数据库，数据每次被使用就消耗了。这里考虑每个节点的脚本执行完，把场景+数据主键+其他信息存入数据池，状态为可用。手工测试通过数据平台查询数据，被查询的数据状态置为不可用。每个节点的可用数据小于设定的阙值时，脚本自动执行新增该节点数据。
项目里方案二、三结合使用。