作為一名測試開發從業者，自動化測試好像是繞不開的話題...。結合最近接觸到的一些測開應聘同學聊到關于前端自動化測試及自己的理解，分享一下自己對UI自動化測試的認識，大概如下。

測試分層的自動化測試思想

自動化測試分層思想所倡導的是對系統進行分層，針對不同層次選擇合適的自動化類型進行測試的一種測試策略，同時自動化測試分層思想也與測試階段(單元測試、集成測試、系統測試)具備相關性。項目的自動化測試覆蓋程度取決于各分層自動化測試分層策略設計的合理性、全面性。

Unit-單元測試

一般由開發人員開展測試，也就是我們日常所說的開發人員對自己開發代碼的自測過程。

Service-服務集成的接口自動化測試

通常指的是API接口自動化測試，在分層自動化測試的應用中，接口自動化是最常見的自動化解決方案。

同時，結合數據驅動測試框架、關鍵字驅動測試框架可以滿足大部分測試場景，包含含有復雜業務邏輯的功能的覆蓋(B接口依賴A接口返回)，同時降低測試代碼的冗余。特別是在前后端分離的產品架構設計中，可以對功能點進行有效的覆蓋，至于頁面顯示、頁面元素布局、展示的驗證可以通過手工測試或者其他工具覆蓋。

UI-頁面自動化測試

UI層是與用戶進行交互的，用戶通過與UI層交互使用系統功能。測試人員的大部分測試工作(黑盒測試)也集中在這一層。根據個人實踐經驗，大部分場景下都不推薦UI自動化，難以做到高效的維護，投入產出比不可控。關于UI自動化的三點建議如下：

• 優先考慮底層自動化覆蓋，盡量不進行UI自動化覆蓋。
• 優先考慮核心功能的自動化覆蓋，降低非核心功能的自動化覆蓋。
• 著重考慮自動化的可擴展性、易維護性設計。

---

自動化測試開展的必要條件

首先，是否開展自動化，通常需要同時滿足以下條件：

• 軟件需求變動不頻繁(超過10%的變動是頻繁變動，同時10%并不是一個固定值，根據其維護、擴展成本適當調整閾值)
• 項目周期足夠長
• 自動化測試用例可重復使用

同時，自動化測試的是否易于擴展、易于維護對其可持續性而言非常重要。

---

自動化測試的局限性

一方面，自動化測試的局限性體現在上述其開展的必要條件，如果在不滿足其必要條件的背景下，開展自動化會發現自動化并不會提高測試效率，甚至可能加大了測試成本。

另一方面，UI自動化與接口自動化本身的局限性，UI自動化較接口自動化而言其具備覆蓋率高的優勢(接口測試無法覆蓋頁面元素、格式、數據)，接口自動化較UI自動化而言具備高擴展、易維護、問題修復成本低的優勢。

---

自動化測試的目的

自動化測試的直接目的是圍繞產品質量提高測試效率，其根本目的(效率轉化)無外乎以下幾點：

• 真正的實現項目人力投入的縮減
• 做更多更有意義的測試，比如更深入的需求分析、測試設計或者對測試左移、右移的投入；
• 適應開發模式的轉變，比如類敏捷、devops、testops模式下的頻繁迭代、持續部署、質量運營等。

前端自動化測試

我們知道UI自動化其開展的前提更強調系統的穩定性，不穩定的系統會導致頻繁的自動化用例維護，這種維護成本是巨大的，甚至會出現原本兩個人測試的項目，引入UI自動化現在需要三個人測試的情況。那么系統穩定性高，改動的可能性較小的情況下如何進行UI自動化？——建議參考Robot Framework + Selenium2Library，同時自動化測試設計時考慮數據與代碼分離，以便減低維護成本，提高其可擴展性。

如果系統的穩定性一般，存在需求改動、頁面優化的可能性，如何開展高覆蓋的自動化測試？——建議參考Robot Framework + RequestsLibrary +Python requests(自定義關鍵字庫開發)實現接口自動化，也需要考慮數據與代碼分離的設計策略，同時RobotFramework支持數據驅動，用例編寫效率會得到很大的提升。基于此再使用UI Recorder(阿里開源的一款零成本UI自動化錄制工具)進行整體頁面的自動化測試。

---

最后，充分考慮易維護性、易擴展性的自動化測試策略設計，是可以實現自動化測試前移的，并非只能用于系統穩定或者回歸測試的場景中。

希望以上分享對你有所幫助，歡迎大家關注、評論、留言。

總結

以上是生活随笔為你收集整理的ui自动化测试框架_浅谈前端（UI）自动化测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。