【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)
            ○ 每次提交均執行單元測試
            ○ 每天一次或數次集成測試
            ○ 每天一次或數次系統測試

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