不要為了做自動化測試而做自動化，做的首要目標是問題出現時，能第一時間發現? 自動化中的代碼覆蓋率統計可以作為參考，但不能一開始就為了提高覆蓋率，陷入 Case 設計之中。
注意：好的接口自動化 Case 設計，依賴于 Case 設計者的功能理解程度，手工測試的功力，功能測試覆蓋點，在用例設計上面要遵循以下幾點原則：
1.將手工測試點轉換為自動化用例。Case 設計注意：驗證用例通過的標準---參考一個功能點容易出問題的地方。或者說，一個用例的通過說明此功能點一定沒問題；反之，一定有問題。
2.覆蓋手工測試不易檢查／太浪費時間的檢查。例如一個 HTTP 接口設計大量的數據比較的時候； 接口的 json 返回不能直接檢查功能點是否正確，需要調用另一個接口的 json 來間接驗證時；一個接口的 json 返回需要和其他模塊的接口聯合” 互相驗證 “，需要調用其他模塊的接口的 json，兩個 json 相互來驗證彼此的正確性。
3.“邊緣性”的功能檢查。這里主要指的是回歸測試驗證。如果系統涉及邊緣性的功能驗證，把此類功能設計層自動化用例。
4.接口驗證的程度。接口的驗證：即判斷一個接口是否正常的標準。注意：接口參數”合理地“組合。
5.DB 數據更新檢查。注意從接口的角度檢查 DB 數據的更新，·其他系統的數據更新到待測系統 DB 中的數據，每天待測系統由于用戶操作更新到 DB 中的數據。
6.接口自動化的數據準備。關于是否需要為接口自動化，特意在 DB 中準備需要的數據，適需要程度而定。原則：除非必須，否則不用準備。如果不準備數據，無法完成對接口的驗證，則自己準備數據即可。
注意：一旦自己準備數據，評估對其他功能驗證的影響。確保 DB 中數據量和真實性，模擬的數據需要充足，并且不能和真實數據差異性過大。
推薦閱讀：
sales@spasvo.com
