一、前言

接口通俗來講就是前端和后段之間傳輸數據的橋梁，注意：不是每一個項目都有接口，一些大型項目是前后端分離的，那么他們怎么實現數據的傳遞和返回呢？在通俗來講就是前端和后段都有一個模擬參數數據

二、接口自動化測試的 "能 "

1、接口自動化的目標

• 用于項目的 API 層的 HTTP 接口的功能邏輯驗證
• 減少手工測試的工作（回歸驗證；跨模塊的驗證）
• 實現手工驗證不能做的驗證（如接口涉及大量數據的排序比較）
• 手工很難充分驗證的功能邏輯（如接口的功能驗證涉及大量的數據）

P.S. 實際項目中，接口自動化的根本目的是什么？

個人認為是定時跑時，能監控接口，當接口功能失常時，可以及時發現，即發現 Bug。因此，可以使用代碼覆蓋率來評估接口自動化的完整性，但更重要的是發現問題

2、接口自動化 Case 用例設計原則

切記：

• 不要為了做自動化而做自動化，做的首要目標是問題出現時，能第一時間發現
• 自動化中的代碼覆蓋率統計可以作為參考，但不能一開始就為了提高覆蓋率，陷入 Case 設計之中

注意：好的接口自動化 Case 設計，依賴于 Case 設計者的功能理解程度（手工測試的功力）+ 功能覆蓋點

原則：

1.將手工測試點轉換為自動化用例

Case 設計注意：驗證用例通過的標準—參考一個功能點容易出問題的地方。或者說，一個用例的通過說明此功能點一定沒問題；反之，一定有問題。

2.覆蓋手工測試不易檢查／太浪費時間的檢查

比如：

• 一個 HTTP 接口設計大量的數據比較的時候
• 接口的 json 返回不能直接檢查功能點是否正確（需要調用另一個接口的 json 來間接驗證時）
• 一個接口的 json 返回需要和其他模塊的接口聯合” 互相驗證 “（需要調用其他模塊的接口的 json，兩個 json 相互來驗證彼此的正確性）

3.“邊緣性” 的功能檢查 這里主要指的是回歸驗證

如果系統涉及邊緣性的功能驗證，把此類功能設計層自動化用例

4.接口驗證的程度

接口的驗證：即判斷一個接口是否正常的標準。注意：接口參數”合理地“組合

5.DB 數據更新檢查

（如果有必要）注意從接口的角度檢查 DB 數據的更新：

• 其他系統的數據更新到待測系統 DB 中的數據
• 每天待測系統由于用戶操作更新到 DB 中的數據

6.接口自動化的數據準備

關于是否需要為接口自動化，特意在 DB 中準備需要的數據，適需要程度而定。原則：除非必須，否則不用準備。如果不準備數據，無法完成對接口的驗證，則自己準備數據即可

注意：一旦自己準備數據，評估對其他功能驗證的影響。確保 DB 中數據量和真實性（模擬的數據需要充足，并且不能和真實數據差異性過大）

3、接口自動化用例定時跑

自動化一般會選擇每天定時跑。這里需要注意的一點就是定時跑的時間選擇

時間選擇上注意幾點：

1）在線上跑時，注意對線上接口的影響（一般要求：線上的回歸驗證可以隨時跑）

2）如果要檢查 DB 數據更新的有關邏輯，注意數據的穩定性 (如用戶量少的時候)

3）在測試時（非生產環境），接口涉及讀，寫 DB，考慮是否需要定時跑

三、接口自動化測試的 "不能 "

首先，接口自動化不是萬能的，總有覆蓋不到的時候。知道自動化的”不能“之處，才能更好配合手工測試出問題

自動化的 ”不能“ 之處如下：

1）HTTP 接口突然出現壓力問題（前期的壓測）

2）Web 層面的手動測試 (新功能上線后，對原有功能回歸時，仍需要接口自動化驗證接口，手工測試 Web 頁面功能)

3）異常情況（如需要第三方 API 掛掉／超時的場景）

1、接口自動化之難點

1）實現變動 vs 維護的工作量 vs 檢查的詳細程度

檢查詳細程度：自己和自己比；自己和同類接口同一指標比較（因為口徑不一致，或者內部實現變化，需要后續維護）

經驗：自己和自己比，擴展和兼容性比較好（動態參數 + 完成功能檢查）；而自己和別的接口比 看需求而定（接口提測前后 數據準確性檢查比較參考）；

P.S. 小的點，執行時間和執行頻率

用途：發現功能失常，功能不可用；

2）接口監控 —— 執行時間和執行頻率

• 檢查詳細程度 vs 執行時間和執行頻率 (只能和自己)
• 檢查詳細程度 vs 經常頻繁報警（一個接口怎樣算是正常的，返回非200+功能正常）

3）數據報表

數據的正確性：統計口徑（業務方的口徑+多個接口／模塊口徑的差異后導致業務方不一致）

2、接口自動化之痛點

痛點當然源自難點：

• 當接口本身實現頻繁變動、對接口的檢查太過詳細、開發修復緩慢時，那么不停的報警將會來了
• 不合理的自動化設計及維護方案，造成自動化成本大于自動化收益時，接口自動化就變得無足輕重了

實際項目中的體會是：為了自動化而自動化。特別測試場景過于復雜時，當自動化實現成本遠大于手工測試成本時，就沒有必要非去自動化測試了

相對于UI自動化而言，接口自動化具有更大的價值

為了優化轉化路徑或者提升用戶體驗，APP/web界面的按鈕控件和布局幾乎每個版本都會發生一次變化，導致自動化的代碼頻繁變更，沒有起到減少工作量的效果

而接口一旦研發完成，后期重構/大幅度修改的頻率則比較低.因而做接口自動化性價比還是很高的，對于迭代版本舊有功能的回歸，beta測試，線上回歸都能起到事半功倍的作用。

同時，在這我為大家準備了一份軟件測試視頻教程（含面試、接口、自動化、性能測試等），就在下方，需要的可以直接去觀看。