自動化終極思想：以目標為導向，不斷抽象沉淀，消除冗余，做到測試數據與測試代碼分離
1、自動化測試對人員的要求
1、對測試人員的技能要求較高，需要自己寫測試代碼或看得懂別人的測試代碼；
2、需要根據版本迭代進行更新測試用例，有一定的維護成本；
3、自動化能發現的缺陷數（bug）遠遠少於手工測試，產出低；
4、自動化測試的產出價值在於長期的回歸測試，短期內發揮的作用不明顯；
2、為何要自動化（借助自動化能解決什么問題？）
1、測試資源緊張，手工測試可能覆蓋不全，容易錯過一些邊界異常校驗；
2、釋放測試人力，提高回歸測試的效率，縮短回歸測試時間；
3、實現手工測試無法完成的測試任務；
4、加深業務/流程認知，有助於發現系統中隱藏的問題；
3、設計自動化用例的原則
基本原則：
1、自動化測試用例的范圍必須是相對核心的業務流程，即覆蓋主體功能的核心測試點和重復執行率較高的模塊；
2、在測試腳本和被測代碼都保持不變的情況下，測試用例的結果應該是穩定的，這一點非常重要；
3、除非是必要的情況，否則任何用例都應當避免做持久化的操作，以保證環境始終是干凈的；
4、Once Written, Run Anytime as Desired ；（測試用例的健壯性）
5、不是所有的接口測試用例都可以使用自動化測試來實現，自動化測試替代不了手工測試，兩者的有效結合是保證項目質量的關鍵。
6、回歸測試場景中，測試用例的選擇一般以正向為主，逆向為輔，不過分追求100%覆蓋；
PS:自動化用例設計原則
1、保持case的獨立性
2、保持case的可遷移行
3、提高case的執行效率
4、接口測試優先級原則
1、外部接口優先級高
2、內部接口優先級低
5、自動化用例編寫規范：測試代碼層
1、命名規范：Keyword命名，第一個單詞應以小寫字母開頭，后面的單詞則用大寫字母開頭，駝峰命名法；
如：queryUserInfo、queryOperatorInfo、queryOperatorDetails等
2、參數命名：參數的命名規范和方法的命名規范相同，請在盡量保證參數名稱為一個單詞的情況下使參數的命名盡可能明確。
如：queryUserInfo，明確這是一個查詢用戶信息的接口
3、全局變量命名：如果一個變量名稱全局都在使用，可以考慮用大寫的字母“G”(或是Global)來定義。
如：G_Env_Url、Global_Env_Url （ip地址+端口）
4、testCase規范：測試用例盡量使用TAG標簽內容來標記，驗證回歸時優先驗證正常接口的調用
PS：以上所寫純屬個人總結