? ? ? ?各位粉絲朋友們大家好，最近在學習研究接口自動化測試時，在設計思路和實踐過程中，碰到了很多問題，再不斷的優化和調整，這過程中產生了很多疑問和不解，并與很多測試的朋友進行交流想法，但是各自想法意見偏差較大，所以我初次整理了幾個問題分享給大家，想聽聽大家的設計思路和想法：

一、接口自動化中，列表類功能如何做斷言比較合理？

1、斷言接口響應的code、msg、響應時長

2、斷言響應的關鍵字段值

3、關鍵字段值與sql查詢出來的預期值做比對

二、接口自動化中，表單提交類功能如何斷言？

1、斷言接口響應的code、msg、響應時長

2、接口的傳參字段值和提交后，入庫更新后字段值做比對

三、接口自動化中，前置和數據清理大家會做嗎？如果不做數據清理，每次跑自動化時，不清楚賬號處于哪個進度，每個用例開始時都要判斷下，這樣會很麻煩？

一般我會做前置數據清理和后置數據清理，因為不能確定賬號當前處于什么進度，假如我想跑實名認證成功用例，測試賬號某天已經實名認證過了，但是當我跑實名認證用例時，目前并不知道測試賬號的進度情況，這時接口提示已經綁定過了，導致了跑的用例不是我想要的，所以每個接口用例用例跑之前和跑之后都清理下產生的數據，保證了賬號的可重復使用

四、接口自動化中，場景自動化測試和單接口自動化測試的區別是什么？

1、單接口自動化注重接口的健壯性，使用測試方法對接口進行測試的，接口之間相互獨立，關聯性不大

2、場景自動化注重業務流程，將有業務關聯流程的接口串起來，保證了業務的正確性，如果1個接口失敗，整個場景就算失敗了

五、接口自動化中，前置數據依賴，大家是如何處理的？

1、用sql構造前置數據，前提是你對業務非常數據，業務關聯的相關表字段非常數據，這樣才能確保sql構造的數據準備，當前用例才可以正常進行

2、調用相關接口獲取依賴值

六、接口自動化中，前置業務依賴，大家是如何處理的？

1、用sql構造前置數據，前提是你對業務非常數據，業務關聯的相關表字段非常數據，這樣才能確保sql構造的數據準備，當前用例才可以正常進行

2、單獨封裝前置依賴接口，這樣的話處理會非常復雜點，比如一個項目，必須進行登錄、實名認證、綁定銀行卡，才可以進行充值、提現操作，這樣如果我們進行充值或提現用例測試時，就需要調登錄-實名認證-綁卡接口，然后在可以正常進行，這里邏輯處理稍復雜些，目前正常嘗試這種方法

七、前置功能依賴，sql處理好點還是調前置接口好點？

根據實際項目中的具體case靈活運用，各有利弊，調api生成數據能夠保證數據準確性，而且執行效率高，而業務較為復雜的情況下，需要調用多個前置api，這樣處理就較為復雜；但不是所有數據創建都有對應的api，這時候只能通過sql構造前置數據了，使用sql構造數據前提是業務和業務關系到的表需要非常熟悉，sql操作的話能夠直接通過數據庫操作，在短時間內生成批量數據，但是后期如果sql語句變化時，維護成本比較高。

總結

以上是生活随笔為你收集整理的接口自动化实战设计思路，想法及疑问（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

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