自動化測試的主要目的是用來回歸測試的，當代碼有變化時，有可能影響不應該變化的邏輯，這個時候為了確認這種情況，就需要進行回歸測試。有時候回歸測試的范圍比較大，如果全由人工的測試，一次兩次還可以接受，如果每次都這樣做，人力成本不說，反反復復執行相同測試用例的測試人員也會抱怨。

通過接口自動化測試可以實現手工測試不容易做的驗證，比如驗證接口中大量數據的排序，多字段的比較，如果都通過人肉來做，效率問題不可接受。

手工很難充分驗證的功能邏輯，一些異常、極限的場景，通過手工很難構造，此時如果我們了解接口的內部邏輯，通過使用腳本有目的的構造這樣的場景來觸發接口的內部邏輯，從而對這些邏輯進行驗證測試，相對來說是很容易的。

采用定時的針對線上接口的自動化測試，能啟動一定的監控作用，當接口功能出現問題時，通過定時的巡檢測試就可以及時發現。

首先就是對于業務要有相當程度的理解，如果要設計好的接口自動化測試用例，一定要對業務有著深刻的理解，因為接口自動化的前期會有一定的投入，如果我們可以將有限的投入聚焦業務中的核心功能點，會有事半功倍的效果。

其次是擁有設計功能測試用例所用到的測試設計基本功，自動化測試和功能測試一樣，同樣不可窮舉、不能做到足夠的充分測試，那么就需要經過一定的測試分析，來選擇最有效的測試用例。

最后是有一些代碼能力，架構設計能力。

接口自動化測試需要注意什么

由于開展接口自動化測試有一定的成本，所以編寫接口自動化測試用例，實際上要有一個權衡的。

如果測試用例寫得很細，我們測試了接口中每個功能點甚至是每一條分支路徑都有涵蓋，那么就會特別依賴被測代碼的邏輯，如果被測代碼邏輯稍微有點變化，測試用例可能就會執行失敗。

如果我們的測試用例驗證的內容沒那么細的話，那有可能即使被測代碼邏輯有變動，但是測試用例執行不容易失敗，這時就有可能遺漏由于代碼變動產生的真的bug。

所以開展自動化測試要找到一個平衡點，尤其是要注意和其他層面的測試相互配合，比如單元測試、UI自動化測試、人工測試等。我們可以事先定義出一套分層測試的規范，即哪些邏輯應該有接口自動化測試保證，哪些邏輯要由UI自動化測試保證，哪些邏輯要由人工測試保證。我們在進行不同層面的測試時，就能互相配合，達到一個較高的測試覆蓋率。這個規范沒有統一的標準，也是根據自己團隊的實際業務、資源、人力等因素來設定的。

最后，接口自動化測試用例其實也是有生命周期的，從產生到修改、再到廢棄。自動化測試用例只要在生命周期內才能發揮價值，所以我們要盡可能的延長它的生命周期，還要盡可能的降低case的產生成本和修改成本，所以整個自動化測試用例就要進行管理。

推薦閱讀：

接口自動化框架有哪些？解鎖各種接口自動化測框架對比分析