Web UI自動化最佳實踐

三思然後行

UI自動化測試最終目的是啥？投入產出比的最佳平衡點在哪？不少實施者在搭建UI自動化框架前每每缺少思考，爲了自動化而自動化。三思然後行，方向決定成敗。因爲項目接口（API and Service）自動化代碼行覆蓋率已經達到70%，基於當前自動化人力和項目質量目標，咱們的自動化最終目的是覆蓋上線迴歸的UI CheckPoint，爲了下降後期維護成本，CheckPoint偏重於入口展現和用戶事件響應邏輯。圍繞目標，在搭建UI自動化框架的過程當中探索了一些優化點，來分享一下

最佳實踐

• 資源代碼分離

XML與Java Object建議映射關係，一個頁面對應一個XML，頁面、控件信息和測試數據統一管理維護，如圖：

測試用例執行以前，會將XML轉化成Java Object，且會實例化一些操做類的方法，如圖：

經過Override能夠知足同一事件不一樣場景下的使用，也便於日誌格式的一致性，提升腳本失敗緣由分析效率

---

• 自動抓取控件生成XML

既然採用XML管理Page和Element數據，那麼生成XML這件事就能夠自動化了，不過困難在於如何定義控件XPath生成規則，須要把手動寫控件XPath的思考過程，抽象化，規則化。須要經過兩方面來完成：

1. 有事件響應的控件，如button、a、input。而這些控件具有通用屬性，且在一個頁面大多時候具有惟一性，如：text、value、herf、placeholder，因此優先生成這個規則的XPath：
   
2. 業務通用組件通常基於div的形式，獲取class生成惟一識別的XPath:

---

• 操做步驟使用接口請求代替UI操做

這一點套用在iOS、Android、Web、H五、小程序幾乎全部前端UI自動化上，都是適用的。由於接口請求的穩定性和維護成本永遠低於UI操做。準確來講，與CheckPoint無直接關聯的UI操做，如數據的建立和刪除。這裏是post請求的方法封裝：

---

• 命令模式進行測試後的數據清理

命令模式是Java種開發設計模型的一種，在這裏具體是這樣運用的：
一、每一項測試數據的清理，都是一個任務類，全部的任務類都繼承了一個抽象類，在action方法裏定義了數據清理的接口請求。
二、在每次建立數據後，實例化任務類，而後添加到隊列裏
三、全部測試用例執行完成後，afterTest裏遍歷隊列依次數據清理

採用這個方式的優點：
一、自動化測試任務中途異常退出結束了，也能夠清理掉已建立的數據
二、支持多份的一樣數據清理，數據之間不受影響
三、無需用完馬上刪除，統一清理，且支持併發，高效

---

• 經過Listener收集數據生成測試報告

日誌統一，操做事件和檢查點清晰可見，加上失敗截圖保存，一旦出現失敗能夠快速定位問題，大大下降後期維護成本