【web系統UI自動化】關於UI自動化的總結

實施過了web系統的UI自動化，回顧梳理下，想到什麼寫什麼，隨時補充。

首先，自動化測試不是手動測試的替代品，是比較好的補充，並且不是佔大比重的補充。 70%的測試工做集中在底層接口測試和單元測試，20%的測試工做爲集成測試，其餘10%的測試即爲界面測試。

###開發方向：

1. 儘量的相通的模塊，通用的封裝
2. 開發約定好，便於定位
3. 適用兼容測試
4. 無界面運行
5. 快速定位問題：報錯信息、錯誤截圖
6. 多環境

###收益點

1. 腳本開發時間和複用次數
2. 快速驗證，第一時間響應問題

###還能夠作哪些？

1. 兼容性
2. 多環境
3. 便於快速定位
4. 提煉更多通用模塊。
5. 調研更優解決方案，好比：cypress等
6. case依賴優化
7. 深度校驗

###什麼樣的項目適合web自動化

1. 系統穩定，太多的阻止程序或更改。
2. 準備以前，先手工測試，確認自動測試能夠涵蓋的系統功能。
3. 須要多系統，多瀏覽器兼容性測試

###什麼樣的功能點須要web自動化

1. 主業務流程
2. 易於實現自動化的web元素、頁面
3. 重複量大的功能

###web自動化常見的驗證點

1. 頁面元素驗證
2. 頁面列表數據驗證
3. 頁面元素屬性？
4. UI的文本，圖片顯示正確性
5. UI的交互邏輯正確性測試
6. UI上的用戶行爲正確性測試

###對於web自動化框架常見的需求點

1. 分佈式執行，能夠多機器，多瀏覽器同步執行腳本
2. 適用於不一樣環境運行
3. 分層設計，方便維護
4. 生成測試報告
5. 模塊的複用
6. 必要的日誌蒐集

###UI自動化收益點的採集

1. 迴歸測試須要按期運行，在自動化時，它們能夠節省測試人員的時間，咱們能夠更專一於其餘場景和探索性測試。
2. 腳本開發時間和複用次數
3. 誤報頻率

###UI自動化缺點or侷限

1. 不能快速反饋（相對於單元測試和API測試）
2. 只會對於case已肯定的內容進行校驗
3. 運行的穩定性
4. 發現的錯誤很少，大多數錯誤彷佛是經過「意外」或進行探索性測試而發現的。這多是由於在每一個探索性測試會話期間，咱們可能以不一樣的方式測試應用程序，從而經過應用程序找到新的漏洞。
5. 編寫優秀且穩定的XPath / CSS定位器所花費的時間，並在底層HTML標記發生變化時更新它們。
6. UI自己的變化性，要想達到和手工測試相同的覆蓋率，投入比較大。

###如何進行CI（Continuous Integration），也就是持續集成 ● 持續提交代碼 (Check-in) ○ 一天之中屢次提交 ● 持續構建代碼 (Build) ○ 保證在任什麼時候刻代碼是能夠繼續開發的 ● 持續部署代碼 (Deploy) ○ 保證始終有一個能夠部署的版本 ● 持續測試代碼 (Test) ○ 每次提交均執行單元測試 ○ 天天一次或數次集成測試 ○ 天天一次或數次系統測試

不過，高頻的集成，仍是用接口更加合適，後面的工做會把系統的交互接口自動化，屆時分享。