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

注意：好的介面自動化 Case 設計，依賴於 Case 設計者的功能理解程度（手工測試的功力）+ 功能覆蓋點，在用例設計上面要遵循以下幾點原則：

1.將手工測試點轉換為自動化用例。Case 設計注意：驗證用例通過的標準---參考一個功能點容易出問題的地方。或者說，一個用例的通過說明此功能點一定沒問題；反之，一定有問題。

2.覆蓋手工測試不易檢查／太浪費時間的檢查。例如一個 HTTP 介面設計大量的資料比較的時候； 介面的 json 返回不能直接檢查功能點是否正確（需要呼叫另一個介面的 json 來間接驗證時）；一個介面的 json 返回需要和其他模組的介面聯合” 互相驗證 “（需要呼叫其他模組的介面的 json，兩個 json 相互來驗證彼此的正確性）

3.“邊緣性”的功能檢查。這裡主要指的是迴歸驗證。如果系統涉及邊緣性的功能驗證，把此類功能設計層自動化用例

4.介面驗證的程度。介面的驗證：即判斷一個介面是否正常的標準。注意：介面引數”合理地“組合；

5.DB 資料更新檢查。（如果有必要）注意從介面的角度檢查 DB 資料的更新：

·其他系統的資料更新到待測系統 DB 中的資料，每天待測系統由於使用者操作更新到 DB 中的資料；

6.介面自動化的資料準備。關於是否需要為介面自動化，特意在 DB 中準備需要的資料，適需要程度而定。原則：除非必須，否則不用準備。如果不準備資料，無法完成對介面的驗證，則自己準備資料即可。

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

推薦閱讀：

自動化測試框架的型別有哪些？

怎樣判斷一個軟體專案適不適合自動化測試？

企業選擇自動化測試方案的幾點建議

目前主要的自動化測試框架有哪幾種？