一、接口自動化測試的 “能 “
接口自動化的目標
• 用於項目的 API 層的 HTTP 接口的功能邏輯驗證• 減少手工測試的工作（迴歸驗證；跨模塊的驗證）• 實現手工驗證不能做的驗證（如接口涉及大量數據的排序比較）• 手工很難充分驗證的功能邏輯（如接口的功能驗證涉及大量的數據）
P.S. 實際項目中，接口自動化的根本目的是什麼？
個人認爲是定時跑時，能監控接口，當接口功能失常時，可以及時發現，即發現 Bug。因此，可以使用代碼覆蓋率來評估接口自動化的完整性，但更重要的是發現問題。
接口自動化 Case 用例設計原則
切記：
• 不要爲了做自動化而做自動化，做的首要目標是問題出現時，能第一時間發現；• 自動化中的代碼覆蓋率統計可以作爲參考，但不能一開始就爲了提高覆蓋率，陷入 Case 設計之中；
注意：好的接口自動化 Case 設計，依賴於 Case 設計者的功能理解程度（手工測試的功力）+ 功能覆蓋點
原則：
1. 將手工測試點轉換爲自動化用例。Case 設計注意：驗證用例通過的標準---參考一個功能點容易出問題的地方。或者說，一個用例的通過說明此功能點一定沒問題；反之，一定有問題。
2. 覆蓋手工測試不易檢查／太浪費時間的檢查
比如：
• 一個 HTTP 接口設計大量的數據比較的時候；• 接口的 json 返回不能直接檢查功能點是否正確（需要調用另一個接口的 json 來間接驗證時）；• 一個接口的 json 返回需要和其他模塊的接口聯合” 互相驗證 “（需要調用其他模塊的接口的 json，兩個 json 相互來驗證彼此的正確性）
3. ”邊緣性“的功能檢查 這裏主要指的是迴歸驗證。如果系統涉及邊緣性的功能驗證，把此類功能設計層自動化用例
4. 接口驗證的程度 接口的驗證：即判斷一個接口是否正常的標準。注意：接口參數”合理地“組合；
5. DB 數據更新檢查
（如果有必要）注意從接口的角度檢查 DB 數據的更新：
• 其他系統的數據更新到待測系統 DB 中的數據；• 每天待測系統由於用戶操作更新到 DB 中的數據；
6. 接口自動化的數據準備
關於是否需要爲接口自動化，特意在 DB 中準備需要的數據，適需要程度而定。原則：除非必須，否則不用準備。如果不準備數據，無法完成對接口的驗證，則自己準備數據即可。
注意：一旦自己準備數據，評估對其他功能驗證的影響。確保 DB 中數據量和真實性（模擬的數據需要充足，並且不能和真實數據差異性過大）。
接口自動化用例定時跑
自動化一般會選擇每天定時跑。這裏需要注意的一點就是定時跑的時間選擇。時間選擇上注意幾點：
1）在線上跑時，注意對線上接口的影響（一般要求：線上的迴歸驗證可以隨時跑）；
2）如果要檢查 DB 數據更新的有關邏輯，注意數據的穩定性 (如用戶量少的時候)；
3）在測試時（非生產環境），接口涉及讀，寫 DB，考慮是否需要定時跑；
二、接口自動化測試的”不能“
首先，接口自動化不是萬能的，總有覆蓋不到的時候。知道自動化的”不能“之處，才能更好配合手工測試出問題。
自動化的”不能“之處如下：
1）HTTP 接口突然出現壓力問題（前期的壓測）；
2）Web 層面的手動測試 (新功能上線後，對原有功能迴歸時，仍需要接口自動化驗證接口，手工測試 Web 頁面功能)；
3）異常情況（如需要第三方 API 掛掉／超時的場景）；
接口自動化之難點：
1）實現變動 vs 維護的工作量 vs 檢查的詳細程度；
檢查詳細程度：自己和自己比；自己和同類接口同一指標比較（因爲口徑不一致，或者內部實現變化，需要後續維護）；
經驗：自己和自己比，擴展和兼容性比較好（動態參數 + 完成功能檢查）；而自己和別的接口比 看需求而定（接口提測前後 數據準確性檢查比較參考）；
P.S. 小的點，執行時間和執行頻率；
用途：發現功能失常，功能不可用；
2）接口監控 —— 執行時間和執行頻率
• 檢查詳細程度 vs 執行時間和執行頻率 (只能和自己)；• 檢查詳細程度 vs 經常頻繁報警（一個接口怎樣算是正常的，返回非200+功能正常）
3）數據報表；
數據的正確性：統計口徑（業務方的口徑+多個接口／模塊口徑的差異後導致業務方不一致）。
接口自動化之痛點
痛點當然源自難點：
•當接口本身實現頻繁變動、對接口的檢查太過詳細、開發修復緩慢時，那麼不停的報警將會來了。•不合理的自動化設計及維護方案，造成自動化成本大於自動化收益時，接口自動化就變得無足輕重了。實際項目中的體會是：爲了自動化而自動化。特別測試場景過於複雜時，當自動化實現成本遠大於手工測試成本時，就沒有必要非去自動化測試了。
（文章來源於霍格沃茲測試學院）