UI自動化測試一直都是如此的令人糾結，自動化測試初學者總是拿它入門，但有些經驗豐富者對其又是毀譽參半，抑或抛出分層自動化測試那個經典的“金字塔”，來說明UI自動化測試還是少做為好。

筆者在從事7年産品研發之後，臨危受命轉向測試領域，至今又7年有餘。期間最關注的一直是UI端/用戶端的自動化技術：從Web應用到移動App、從測試到RPA（機器人流程自動化）、從框架研發到應用推廣。

本文主要分享為什麼要做UI自動化測試、UI自動化測試框架設計要點、團隊合作方式、推廣注意事項以及其他的心得體會，希望能給各位同行帶來思想上的碰撞。

如果一個組織真正重視軟件質量，UI自動化測試是有必要做。有如下幾點理由：

任何自動化工具都是在簡單、機械、重複的任務場景下最能發揮作用，UI測試非常符合這個特點。

對于很多組織來說，UI測試是當前耗費測試團隊人力最多的環節，大部分專職測試人員日常工作就是UI測試。“工欲善其事必先利其器”，測試人員也需要自動化工具來提升其日常工作效率。

所以任何項目中有人拿“分層自動化測試”跟我講不要做UI自動化測試的時候，我都會先請他們把接口測試和單元測試展示給我看看，然後再跟他們探讨自動化測試的實施策略。

但是從實踐的角度，為什麼很多質疑的聲音呢？

歸根結底就是三個字“不穩定”！

測試環境構建不穩定、被測軟件界面不穩定、測試框架運行不穩定。

其實隻要适當的過程改善和開發團隊配合，這些問題基本都是能夠解決或者明顯改善的。

以測試環境為例，在純手工測試階段，有些項目的測試環境可以被随時停止、随意更新。這樣對手工測試也是有影響的（工作進度受幹擾、測試計劃被打亂），但是可以忍受。自動化測試會對測試環境提出更規範的要求，至少不能随時停止，這就需要對研發測試過程進行必要的改善。

然而被測軟件界面不穩定、測試框架運行不穩定，就沒有測試環境不穩定那麼容易解決了。這裡面主要涉及與開發團隊的配合、測試框架的設計。

在分層自動化測試理論中，提到單元測試和接口測試是比較穩定和容易實現的。除了底層代碼受用戶需求變化影響相對較少、編寫自動化用例成本較低之外，其實隐含了一個很少被提及的原因：單元測試和接口測試通常是開發團隊内部的工作，當發現一個方法或服務接口設計的不合理導緻自動化測試用例編寫困難的時候，即便沒有直接對應到一個缺陷上，他們也通常會進行調整，使代碼設計實現更加優化、更規範。

UI自動化測試需要開發團隊配合指的當然不是不允許開發團隊随便修改UI實現，指的主要是約定并遵守良好的UI編碼規範、及時修正未對應功能缺陷但卻影響UI自動化測試的編碼問題等。

UI自動化測試最關鍵的步驟是“定位頁面對象”，下面舉一個具體的例子，說明開發團隊一些分内的、簡單的配合，對自動化測試是多麼的重要。

定位頁面對象的方法有很多，除了ID、XPath、CSS等之外，筆者推薦根據上下文文本定位對象。

以下圖界面為例：

　　如果測試腳本想要使用上下文文本定位對象的方法（如下所示）：

在測試框架中就要解決怎麼根據文本準确定位到後面的輸入域/下拉框的問題。

其實隻要開發團隊遵守HTML的基本标準，規範使用Label标簽及for屬性（如下所示），測試框架中實現上述效果就會變得很容易的。

如果不遵守基本的UI編碼規範，每個開發人員都随意編寫前端代碼，UI自動化測試的成本和難度就會明顯增加。

自動化測試框架的設計方法有很多，筆者這些年一直堅持的自動化測試框架設計核心思想是要“與開發模式匹配”。

以WebUI開發為例，現在主要有兩類模式：

采用統一UI類庫，企業或項目組采用統一的前端UI組件庫進行開發，如，JQuery。

采用統一開發框架，包括UI開發工具（甚至采用UI模型驅動開發），在采用統一UI類庫的基礎上，通過工具或模型來确保UI代碼的規範性和一緻性。

在這兩種模式下由于大量的UI類庫，前端會解析出大量的、動态的、機器生成的頁面源碼，不再适合采用傳統的腳本錄制和頁面對象識别的方式來制作測試腳本。

對應這兩種開發模式，筆者經常采用的自動化測試框架設計模式有：UI組件封裝模式、開發框架對接模式等。

1）UI組件封裝模式

PageObject模式是自動化測試最常采用的模式，但是在基于UI類庫開發的系統中，頁面對象數量太多，而且很多工具識别頁面對象也變得更加的不準确和不智能。

所謂UI組件封裝模式，指的是根據開發所采用UI類庫提供的UI組件類型（比如，input、select、date、button、tree、grid等）對應提供相應的自動化測試控件。

将每類UI控件的定位方式和交互邏輯都封裝到對應的自動化測試控件中，測試人員通過簡單的DSL語言即可描述測試過程（如下所示），具體的解析執行交個測試框架進行統一處理。

通過這種測試框架設計模式，可以降低腳本編寫難度和腳本代碼量，提高對象識别和執行穩定性，将UI類庫變更帶來的影響限制到測試框架中，不往測試腳本中擴散。

2）開發框架對接模式

當企業采用了統一開發框架，特别是通過工具生成大量UI代碼時，我們可以先了解哪些代碼是開發人員寫的、哪些代碼是工具生成的、哪些信息是在開發框架中統一管理的。

在自動化測試框架設計時，充分利用這些資源可以大幅提升框架的易用性。如下圖所示，對接開發框架之後，我們可以輕易的一鍵獲取項目完整菜單結構（作為測試用例大概），并且準确識别頁面對象。

有了完整的測試用例大綱和頁面對象之後，測試腳本的編寫就會更加容易。另外，當未來項目版本升級之後，可以通過再次探測對比，識别頁面對象的變更及影響的測試腳本，進而提醒測試人員批量修改腳本。降低在回歸測試過程中發現腳本執行不過，帶來的反複修改、反複回歸驗證的成本。

4.什麼樣的項目更适合做自動化測試

在有些人看來，質量不高的原因是沒有采用先進的測試技術，比如自動化測試。

但質量不高的真正原因是項目本身的質量要求就是不高的。否則哪怕堆人肉，也要實現充分的回歸測試。如果在這種情況下，如果采用适合的測試框架和實施策略推行自動化測試，通常會取得比較明顯的成效。

所以關于什麼類型的項目适合做自動化測試，我想回答的并不是什麼項目周期長、需要長期維護、采用敏捷開發模式、組織推行DevOps、測試團隊有基本編碼技能，balabala…

這些年筆者建議不要做UI自動化測試的項目也有很多，一些被我拒絕支持的項目也符合上述特點。後來我在評估一個項目是否适合做自動化測試時，引入了一些非技術指标：

當前測試覆蓋度、質量風險及測試投入；

目标測試覆蓋度、質量風險，以及如果不引入自動化手段需要的測試投入；

這個目标是誰制定的或者是向誰承諾要達成的？

如果項目沒有制定一個在當前人力資源下無法達成的回顧覆蓋範圍目标，或者僅僅是項目組内定的目标，都沒有向老闆彙報或向客戶承諾此目标。我覺得在這種情況下說要做自動化測試都是不太有誠意的。

對于真心實意要做自動化測試的項目，接下來我會引導他們把現有所有測試用例拿出來，具體分析每個（每類）用例的自動化執行可行性、實現技術方案（UI、接口），以及前期需要投入的成本。

在做完自動化測試ROI分析之後，如果确定要引入自動化測試，那麼再輔以适當的自動化測試框架，實施成功的可能性是非常大的。

更多UI測試文章，請前往51Testing軟件測試網。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!