實施過了web系統的ui自動化，回顧梳理下，想到什麼寫什麼，随時補充。
首先，自動化測試不是手動測試的替代品，是比較好的補充，而且不是占大比重的補充。
70%的測試工作集中在底層接口測試和單元測試，20%的測試工作為內建測試，其他10%的測試即為界面測試。
盡可能的相通的子產品，通用的封裝
開發約定好，便于定位
适用相容測試
無界面運作
快速定位問題：報錯資訊、錯誤截圖
多環境
腳本開發時間和複用次數
快速驗證，第一時間響應問題
相容性
便于快速定位
提煉更多通用子產品。
調研更優解決方案，比如：cypress等
case依賴優化
深度校驗
系統穩定，太多的阻止程式或更改。
準備之前，先手工測試，确認自動測試可以涵蓋的系統功能。
需要多系統，多浏覽器相容性測試
主業務流程
易于實作自動化的web元素、頁面
重複量大的功能
頁面元素驗證
頁面清單資料驗證
頁面元素屬性？
ui的文本，圖檔顯示正确性
ui的互動邏輯正确性測試
ui上的使用者行為正确性測試
分布式執行，可以多機器，多浏覽器同步執行腳本
适用于不同環境運作
分層設計，友善維護
生成測試報告
子產品的複用
必要的日志搜集
回歸測試需要定期運作，在自動化時，它們可以節省測試人員的時間，我們可以更專注于其他場景和探索性測試。
誤報頻率
不能快速回報（相對于單元測試和api測試）
隻會對于case已确定的内容進行校驗
運作的穩定性
發現的錯誤不多，大多數錯誤似乎是通過“意外”或進行探索性測試而發現的。這可能是因為在每個探索性測試會話期間，我們可能以不同的方式測試應用程式，進而通過應用程式找到新的漏洞。
編寫優秀且穩定的xpath / css定位器所花費的時間，并在底層html标記發生變化時更新它們。
ui本身的變化性，要想達到和手工測試相同的覆寫率，投入比較大。
不過，高頻的內建，還是用接口更加合适，後面的工作會把系統的互動接口自動化，屆時分享。