**複雜業務流**末端的介面前置資料應該如何準備？

做介面測試有個難點一直沒有找到很好的解決方案，就是針對業務流程非複雜的末端的介面測試邏輯時，依賴的資料應該透過什麼方式準備。
例如：
有一個單據，需要經過【處理 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 介面的入參真的有點龐大了，讓我在對入參組合的測試上非常的懵，不知道界限是什麼。