最近在做接口测试自动化，遇到一个问题，就是某些系统业务逻辑复杂，依赖性较强，接口之间存在数据依赖（例如上一步的接口产生了某些数据，可能通过响应返回，也可能存在数据库中），另外涉及创建等接口数据需要一直更新，不然就用不了。主要有如下问题：
1、测试数据如何构造更有效：业务依赖强，通过流程性一步步构建数据链条太长，且效率应该不高；通过数据库直接构造，数据库表和业务的逻辑关系确实也复杂，完全梳理清楚有不小的工作量。（目前使用比较简单的 testng 数据驱动，但用例多了之后，测试数据维护在 excel 就不太方便了，另外目前系统整体的数据字典其实是不清晰的，或者说是没有维护的。）
2、如果能通过上述 1 构造测试数据，如何能和自动化用例形成有效的关联，数据和用例能一一对应上？我的理解是需要有一个中间环节，管理用例 - 触发数据构造 - 保证数据和用例之间的关联，这样整体的复杂度就上升了一个层次。
综上，请教各位大佬是否有比较好的实践或者建议，构造复杂业务下的接口自动化？谢谢。
“通过数据库直接构造” 不可取。
最好还是走流程生成，哪怕效率低一点。
提取关键流程接口，封装关键字或者方法，用例驱动部分把所有预处理操作放入 before 中。数据部分把每个用例分为预处理包含的数据和当前用例包含的数据。
另外，再复杂的接口能慢到哪儿去。。。对于慢的查询类或者有第三方的，mock 大法祭出来
用例多了，按类整理或者流程整理呀。都放一起能不乱吗...
数据都搞不清楚怎么去下手呢，从一个个小的功能入手，把每个功能的数据都抓出来整理，这些事情还是要做，不然其他都是空谈，不想用重新生成的方式。你就要一点点去把生成的过程弄清楚
脱离场景只对接口做自动化，虽然很省事，但是用例维护后期起来很麻烦。二个是在数据库构造数据就要在用例里写 sql，表结构一变化脚本大概率就要 gg。我曾经 2000 多个用例因为表结构变化全部 gg，写了个处理字符串的方法把多的字段剔除，少的补上，但我的用例全部是基于构造数据的 sql 设计的，sql 都变了用例可靠性还有多少，无法再维护。
失败的经验一大堆，总结起来就一句话，产品如果不配做自动化咋样都做不起来。