在接口测试的过程中，如果该接口处于一个非常长的流程的末端，而且该接口会发生数据变更，比如是一个 POST 接口，
假设流程有 20 个步骤，我要测最后一个 post 接口，而前面的接口数据都是强依赖的，这个时候我准备数据有 2 种方式：
1：每次要测第 20 个接口的时候，都顺序执行 1~19 的接口，供第 20 个接口测试的时候调用（缺点：1~19 步执行时间会比较长，且任意一个环节出错，都会导致测试目的达不到，目的：测第 20 个接口）
2：手工准备数据到第 19 步，测完 20 后，将数据恢复到 19 步（缺点：恢复数据比较麻烦）
不知道巨佬们 在这种长流程的接口测试中，都是怎么准备数据的？
膜拜巨佬~
如果是用在单接口测试，可以直接造出前 19 个接口会产生的数据，手工/程序插入到数据库或者相关中间件里面，这样就可以直接测第 20 个接口。当然前提是你要梳理清楚前 19 个接口在干嘛，并且在他们对数据操作产生变动时，也跟着变。
如果是用在多接口测试或者流程测试，前 19 个接口就老老实实调用就好。一般这么长流程的业务，造数据成本会非常高，日常维护一些主流程的接口用于按需造数据，才能提高效率。
PS：之前在信贷业务，就是类似这样的场景，要跑还款流程就得造前面的提交资料、审批、借款三个流程才行。所以整个团队会花不少时间精力去维护整个主流程的接口测试用例，并且通过加一些参数的方式 + 包一个平台的方式，将它变为造数据的工具。
巨佬们 回复一下吧
手工操作费时费力还易错，脚本运行省时省力又可靠。
脚本缺点：需要成本开发。
其实没必要纠结啊 你这第 20 个接口本来也是以来前面 19 个接口 其实也是对前面 19 个接口的测试，其核心都是在改数据，查数据。有些时候你第 20 个接口没达到预期可能就是前面的一个业务接口的问题并不是最后一个接口的问题，所以该跑流程就跑流程，本身没什么可纠结的。如果你不想看接口的业务是否正确，也可以直接看它接口在做怎样的数据库操作 去测 SQL 也行
如果是用在单接口测试，可以直接造出前 19 个接口会产生的数据，手工/程序插入到数据库或者相关中间件里面，这样就可以直接测第 20 个接口。当然前提是你要梳理清楚前 19 个接口在干嘛，并且在他们对数据操作产生变动时，也跟着变。
如果是用在多接口测试或者流程测试，前 19 个接口就老老实实调用就好。一般这么长流程的业务，造数据成本会非常高，日常维护一些主流程的接口用于按需造数据，才能提高效率。
PS：之前在信贷业务，就是类似这样的场景，要跑还款流程就得造前面的提交资料、审批、借款三个流程才行。所以整个团队会花不少时间精力去维护整个主流程的接口测试用例，并且通过加一些参数的方式 + 包一个平台的方式，将它变为造数据的工具。