不要為了做自動化測試而做自動化，做的首要目標是問題出現時，能第一時間發現? 自動化中的**覆蓋率統計可以作為參考，但不能一開始就為了提高覆蓋率，陷入 case 設計之中。
注意：好的介面自動化 case 設計，依賴於 case 設計者的功能理解程度（手工測試的功力）+ 功能覆蓋點，在用例設計上面要遵循以下幾點原則：
1.將手工測試點轉換為自動化用例。case 設計注意：驗證用例通過的標準---參考乙個功能點容易出問題的地方。或者說，乙個用例的通過說明此功能點一定沒問題；反之，一定有問題。
2.覆蓋手工測試不易檢查／太浪費時間的檢查。例如乙個 http 介面設計大量的資料比較的時候； 介面的 json 返回不能直接檢查功能點是否正確（需要呼叫另乙個介面的 json 來間接驗證時）；乙個介面的 json 返回需要和其他模組的介面聯合」 互相驗證 「（需要呼叫其他模組的介面的 json，兩個 json 相互來驗證彼此的正確性）
3.「邊緣性」的功能檢查。這裡主要指的是回歸驗證。如果系統涉及邊緣性的功能驗證，把此類功能設計層自動化用例
4.介面驗證的程度。介面的驗證：即判斷乙個介面是否正常的標準。注意：介面引數」合理地「組合；
5.db 資料更新檢查。（如果有必要）注意從介面的角度檢查 db 資料的更新：
·其他系統的資料更新到待測系統 db 中的資料，每天待測系統由於使用者操作更新到 db 中的資料；
6.介面自動化的資料準備。關於是否需要為介面自動化，特意在 db 中準備需要的資料，適需要程度而定。原則：除非必須，否則不用準備。如果不準備資料，無法完成對介面的驗證，則自己準備資料即可。
注意：一旦自己準備資料，評估對其他功能驗證的影響。確保 db 中資料量和真實性（模擬的資料需要充足，並且不能和真實資料差異性過大）。
推薦閱讀：
自動化測試框架的型別有哪些？
怎樣判斷乙個軟體專案適不適合自動化測試？
企業選擇自動化測試方案的幾點建議
目前主要的自動化測試框架有哪幾種？
自動化用例設計原則
1.不是所有的手工用例都要轉化為自動化測試用例。2.考慮到指令碼考法的成本，不要選擇流程太複雜的用例。如果有必要考慮把流程拆分成多個用例來實現指令碼。3.選擇的用例最好可以構建場景。例如，乙個功能模組，分多個測試用例，多個用例使用同乙個場景。4.選擇的用例可以帶有目的性。例如 這部分用例做冒煙測試，...
自動化用例設計
用例設計部分，無論是手工測試還是自動化測試，都必須要的環節，也是非常重要的環節。在做自動化的時候，用例需要考慮前置後置 步驟和對比，每乙個部分都要有提供非常明確的測試資料，要考慮資料的重複使用是否會影響指令碼的執行結果。1.不是所有的手工用例都要轉成自動化測試用例 2.考慮到指令碼開發的成本，不要選...
自動化用例設計
自動化用例主要用來冒煙測試和回歸測試 冒煙測試，即為主要功能的用例執行 回歸測試，即為全部或者部分用例的執行 自動化測試得誤區 不編寫自動化測試用例，直接編寫自動化指令碼 直接拿手工測試用例來編寫自動化測試指令碼 自動化用例選型注意事項 1，不是所有的手工測試用例都要轉化為自動化測試用例 2，考慮指...