在做接口自動化測試時，遇到下面這個疑惑，然後再羣裏請教了大家，討論如下，可以參考下：
討論1：
上海—橙子探索測試 10:12:34
自動化測試中，提現接口一般會依賴前置功能實名認證、綁卡、設置交易密碼等才能進行提現操作或依賴前置接口實名認證、綁卡、設置交易密碼的響應數據（姓名、身份證、卡號、交易密碼）等 ，這只是簡單的實例，可能實際場景中遠比這種複雜的多，所以進行提現接口測試時，需先構建完成前置功能實名認證、綁卡、設置交易密碼且構建前置接口的響應數據，一般調前置功能接口或用sql構造前置功能數據兩種方法，那種方法更合理方便呢？
風い 10:14:00
要保證用例獨立運行的能力 只能麻煩
z 10:14:56
做成場景測試用例
天 10:19:08
上海—橙子探索測試 自動化測試中，接口4依賴前置接口順序或數據1 2 3 ，接口5依賴前置接口順序或數據1 2 3 4，（比如：提現 可能需要先設置登錄密碼、再實名認證，才能提現），所以接口4時，需要構建前置接口順序或數據1 2 3，接口5時，需要構建前置接口順序或數據1 2 3 4 …… 這樣的話，每個接口裏都存在大量重複前置sql侯建，感覺太麻煩了，有什麼好的方法嗎？
@上海—橙子探索測試 如果測試環境中，數據不會被清理，可以把參數寫死。否則的話，只能通過接口來造前置條件的數據，來保證腳本的健壯性
上海—橙子探索測試 10:39:53
@天 嗯 我目前是通過sql構建數據的 用完又清掉 所以導致每個用例都要重新構造
上海—橙子探索測試 10:40:17
@z 場景的話那就是場景自動化了 不是單接口自動化
翡翠 10:41:08
直接調接口
翡翠 10:41:17
不行上容器，開虛擬數據庫
翡翠 10:41:20
隨用隨刪
上海—橙子探索測試 10:41:46
調接口不穩定吧 我覺得還不如sql吧
翡翠 10:42:04
的確不如sql穩定
翡翠 10:42:19
所以我說，不行上容器
翡翠 10:42:25
隨用隨刪
天 10:43:44
你們在用docker嗎
翡翠 10:43:59
我在弄
翡翠 10:44:16
還沒弄好
天 10:44:59
上海—橙子探索測試 @天 嗯 我目前是通過sql構建數據的 用完又清掉 所以導致每個用例都要重新構造
@上海—橙子探索測試 你的sql會向服務器插入數據嗎
天 10:46:34
我之前就想過用docker來實現，先把數據添加到docker中的數據庫中。跑自動化時就切換到docker裏面的數據庫，執行完畢後就切換到測試環境的數據庫
z 10:46:58
@上海—橙子探索測試 你這本來有就依賴關係的，除非你再數據庫維護一組數據 專門用於測試這個接口，執行完畢後把數據還原
天10:48:41
z @上海—橙子探索測試 你這本來有就依賴關係的，除非你再數據庫維護一組數據 專門用於測試這個接口，執行完畢後把數據還原
@zx 我以前也是這麼想的，但是沒有實現
zz 10:49:22
@翡翠 不行上容器，開虛擬數據庫
天錐樹 10:49:23
數據都是在數據庫中準備好的，直接跑接口來驗證邏輯，比較麻煩的是維護數據
zz 10:49:26
這是啥意思啊
天 10:49:46
什麼是虛擬數據庫啊
z 10:50:30
把業務熟悉後，維護起來也不是很難
翡翠 10:50:54
開個容器，容器裏面有數據
翡翠 10:51:09
因爲數據庫是假的，你隨便弄
翡翠 10:51:19
不考慮環境污染那些
翡翠 10:51:23
反正最後都要刪
z 10:51:54
數據不一定要存儲在數據庫，可以用文本，執行前寫入進去就好
z 10:52:02
執行完畢後，再刪掉
zz 10:56:48
意思是我們自己copy一套生產壞境的數據庫
zz 10:57:10
跑case的時候 把業務服切到虛擬數據庫來？
翡翠 10:57:49
case就在容器裏面炮
翡翠 10:57:51
跑
翡翠 10:57:58
具體你看一下docker
上海—橙子探索測試 10:58:24
@天 各種sql都會的
上海—橙子探索測試 10:59:13
增刪改查
zz 11:05:19
在哪裏跑有什麼沒關係呀
zz 11:05:31
你總得連服務器啊
天 11:15:23
上海—橙子探索測試 @天 各種sql都會的
@上海—橙子探索測試 搞那麼多sql，還真不如調用接口來造數據。萬一sql錯了，出現的問題，開發肯定不認，而且還會是覺得浪費他們的開發時間。如果接口造的數據，有問題，絕對是代碼的問題，開發跑不脫
天11:15:55
反正接口之前有依賴的自動化很麻煩
像風 11:17:28
sql性能高得多
像風 11:17:43
開發給你sql就行了啊
上海—橙子探索測試 11:19:11
嗯 各有利弊吧
討論2：
橙子：接口自動化中，前置數據大家都是怎麼準備的
橙子：我發現前置數據又是一個大頭
H：前置數據？是指？傳參？
橙子：比如要提現是不是要登錄、實名認證-審覈、綁卡-審覈、充值
橙子：這只是一個示例 也許實際項目中更復雜 涉及多個系統
H：這個是 挺複雜的一個，而且還是必須的，接口之間存在很強的依賴
橙子：我們目前1個項目涉及3個系統交互的，我目前走的sql，單發現，走sql需要對業務邏輯、表關聯需要非常數據，且sql之間頁存在依賴，有點麻煩
H：1.從接口關聯方面做，2.通過sql方面做
橙子：感覺還是sql簡單點
H：嗯嗯，如果表關聯很強，不建議走sql方面，除非是 把涉及的表關係理的很清楚
橙子：是的 要不然數據容易錯，且如果表字段、業務一旦發生變化，sql隨時需要改動
H：不過這些如果發生變化，那對應的 接口 也會有變更的，從接口方面走，也的改
由以上總結得出：
1、調業務接口構造前置功能數據，更合理，避免出現錯誤數據導致測試結果的不準確、接口會被重複調用多次
封裝被調用的獨立方法，需要時直接調用，判斷是否成功，如果成功，進行響應數據提取進行下一步接口用例測試；如果失敗，直接報出失敗的接口，不進行下一步接口用例測試
2、使用sql操作構造前置功能數據，不推薦使用，容易出現數據錯誤導致測試結果不準確或不穩定性、對業務熟悉度，表關聯關係熟悉度要求高
根據業務關係、表之間關係封裝構造前置sql和數據清理sql，再用例執行前進行前置功能數據構造調用和執行後進行測試數據清理還原，保證用例可重複執行
3、根據實際情況合理選取
由於只是針對提現接口進行測試，所以重點不關心實名認證、綁卡、設置交易密碼模塊，故1和2都可以