在做接口自動化測試時，遇到下面這個疑惑，然后再群里請教了大家，討論如下，可以參考下：

討論1：

上海—橙子探索測試?10:12:34
自動化測試中，提現(xiàn)接口一般會依賴前置功能實名認證、綁卡、設置交易密碼等才能進行提現(xiàn)操作或依賴前置接口實名認證、綁卡、設置交易密碼的響應數據（姓名、身份證、卡號、交易密碼）等?，這只是簡單的實例，可能實際場景中遠比這種復雜的多，所以進行提現(xiàn)接口測試時，需先構建完成前置功能實名認證、綁卡、設置交易密碼且構建前置接口的響應數據，一般調前置功能接口或用sql構造前置功能數據兩種方法，那種方法更合理方便呢？
風い?10:14:00
要保證用例獨立運行的能力??只能麻煩
z?10:14:56
做成場景測試用例
天?10:19:08
上海—橙子探索測試 自動化測試中，接口4依賴前置接口順序或數據1 2 3 ，接口5依賴前置接口順序或數據1 2 3 4，（比如：提現(xiàn) 可能需要先設置登錄密碼、再實名認證，才能提現(xiàn)），所以接口4時，需要構建前置接口順序或數據1 2 3，接口5時，需要構建前置接口順序或數據1 2 3 4 …… 這樣的話，每個接口里都存在大量重復前置sql侯建，感覺太麻煩了，有什么好的方法嗎？
@上海—橙子探索測試?如果測試環(huán)境中，數據不會被清理，可以把參數寫死。否則的話，只能通過接口來造前置條件的數據，來保證腳本的健壯性
上海—橙子探索測試?10:39:53
@天?嗯??我目前是通過sql構建數據的??用完又清掉?所以導致每個用例都要重新構造
上海—橙子探索測試?10:40:17
@z?場景的話那就是場景自動化了??不是單接口自動化
翡翠?10:41:08
直接調接口
翡翠?10:41:17
不行上容器，開虛擬數據庫
翡翠?10:41:20
隨用隨刪
上海—橙子探索測試?10:41:46
調接口不穩(wěn)定吧??我覺得還不如sql吧
翡翠?10:42:04
的確不如sql穩(wěn)定
翡翠?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來實現(xiàn)，先把數據添加到docker中的數據庫中。跑自動化時就切換到docker里面的數據庫，執(zhí)行完畢后就切換到測試環(huán)境的數據庫
z?10:46:58
@上海—橙子探索測試?你這本來有就依賴關系的，除非你再數據庫維護一組數據?專門用于測試這個接口，執(zhí)行完畢后把數據還原
天10:48:41
z?@上海—橙子探索測試 你這本來有就依賴關系的，除非你再數據庫維護一組數據 專門用于測試這個接口，執(zhí)行完畢后把數據還原
@zx?我以前也是這么想的，但是沒有實現(xiàn)
zz?10:49:22
@翡翠?不行上容器，開虛擬數據庫
天錐樹?10:49:23
數據都是在數據庫中準備好的，直接跑接口來驗證邏輯，比較麻煩的是維護數據
zz?10:49:26
這是啥意思啊
天?10:49:46
什么是虛擬數據庫啊
z?10:50:30
把業(yè)務熟悉后，維護起來也不是很難
翡翠?10:50:54
開個容器，容器里面有數據
翡翠?10:51:09
因為數據庫是假的，你隨便弄
翡翠?10:51:19
不考慮環(huán)境污染那些
翡翠?10:51:23
反正最后都要刪
z?10:51:54
數據不一定要存儲在數據庫，可以用文本，執(zhí)行前寫入進去就好
z?10:52:02
執(zhí)行完畢后，再刪掉
zz?10:56:48
意思是我們自己copy一套生產壞境的數據庫?
zz?10:57:10
跑case的時候?把業(yè)務服切到虛擬數據庫來？
翡翠?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錯了，出現(xiàn)的問題，開發(fā)肯定不認，而且還會是覺得浪費他們的開發(fā)時間。如果接口造的數據，有問題，絕對是代碼的問題，開發(fā)跑不脫
天11:15:55
反正接口之前有依賴的自動化很麻煩
像風 11:17:28
sql性能高得多
像風 11:17:43
開發(fā)給你sql就行了啊
上海—橙子探索測試?11:19:11
嗯?各有利弊吧

討論2：

橙子：接口自動化中，前置數據大家都是怎么準備的

橙子：我發(fā)現(xiàn)前置數據又是一個大頭

H：前置數據？是指？傳參？

橙子：比如要提現(xiàn)是不是要登錄、實名認證-審核、綁卡-審核、充值

橙子：這只是一個示例 ?也許實際項目中更復雜 ?涉及多個系統(tǒng)

H：這個是 挺復雜的一個，而且還是必須的，接口之間存在很強的依賴

橙子：我們目前1個項目涉及3個系統(tǒng)交互的，我目前走的sql，單發(fā)現(xiàn)，走sql需要對業(yè)務邏輯、表關聯(lián)需要非常數據，且sql之間頁存在依賴，有點麻煩

H：1.從接口關聯(lián)方面做，2.通過sql方面做

橙子：感覺還是sql簡單點

H：嗯嗯，如果表關聯(lián)很強，不建議走sql方面，除非是 把涉及的表關系理的很清楚

橙子：是的 ?要不然數據容易錯，且如果表字段、業(yè)務一旦發(fā)生變化，sql隨時需要改動

H：不過這些如果發(fā)生變化，那對應的 接口 也會有變更的，從接口方面走，也的改

?

由以上總結得出：

1、調業(yè)務接口構造前置功能數據，更合理，避免出現(xiàn)錯誤數據導致測試結果的不準確、接口會被重復調用多次?

封裝被調用的獨立方法，需要時直接調用，判斷是否成功，如果成功，進行響應數據提取進行下一步接口用例測試；如果失敗，直接報出失敗的接口，不進行下一步接口用例測試

2、使用sql操作構造前置功能數據，不推薦使用，容易出現(xiàn)數據錯誤導致測試結果不準確或不穩(wěn)定性、對業(yè)務熟悉度，表關聯(lián)關系熟悉度要求高

根據業(yè)務關系、表之間關系封裝構造前置sql和數據清理sql，再用例執(zhí)行前進行前置功能數據構造調用和執(zhí)行后進行測試數據清理還原，保證用例可重復執(zhí)行

3、根據實際情況合理選取

由于只是針對提現(xiàn)接口進行測試，所以重點不關心實名認證、綁卡、設置交易密碼模塊，故1和2都可以

?

總結

以上是生活随笔為你收集整理的Python自动化测试|如何解决前置模块及数据依赖（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。