做接口测试有个难点一直没有找到很好的解决方案，就是针对业务流程非复杂的末端的接口测试逻辑时，依赖的数据应该通过什么方式准备。
例如：
有一个单据，需要经过【处理 1】-【处理 7】后，操作【处理 8】进行完结这笔单据，并且单据的处理 1-处理 7 操作从前端操作上是不可跨越的。
我需要测试【处理 8】这个接口的业务逻辑的时候，需要单据已经完成了【处理 1】-【处理 7】的操作，且经过【处理 8】后的单据是不可逆，不能再利用的。
问题：
那么我的测试【处理 8】这个接口的时候，数据准备应该如何？
试过的方案：
方案 1
调用前置接口【处理 1】-【处理 7】，但是流程过于长，前置接口有出问题的风险，且逻辑分支比较多，通过此方法造数据可能造数据的调用代码远远大于实际测试【处理 8】接口的数据。
方案 2
先页面造好数据，进行数据库 dump，由于外部因素，开发这边不能给出一个接口涉及掉的表结构等等，所以整个数据库 dump，但是存在各个业务可能同时由不同的人触发，整个库 dump 就不能多线程执行用例，不灵活，而每个业务接口一个库也不现实。

求助，有什么好的方案？

追加
1、说明一下另一个不太愿意调用接口去造数据的原因是，现在业务中例如单据这种都是要求的 id，包括单据中的一些属性值都是需要传值 id，然后和公司账号相关联的，还考虑到环境的问题，例如我测试环境和灰度环境，数据库是两套，所以一套入参不能满足两个环境运行，可能我还是想要脱离这个限制吧，让这个接口测试代码是可复用的，而不是一旦换了环境或者数据库因为某种原因重置了，一些前置的操作还需要手动去执行。
2、不知道大家现在服务架构是如何的，我们现在是在切换到 vue+springboot 的模式进行中，会有一个 service 和 controller，我的理解上，要做接口测试，应该是针对 controller 层的，但是实际要求我做 service 层的接口测试，会有点迷茫吧，就是一个 service 接口可能支持了好多 controller 的，实际上 service 接口的入参真的有点庞大了，让我在对入参组合的测试上非常的懵，不知道界限是什么。