WEB-UI自動化實踐

1.設計背景

隨着IT行業的發展，產品愈漸複雜，web端業務及流程更加繁瑣，目前UI測試僅是針對單一頁面，操做量大。爲了知足多頁面功能及流程的需求及節省工時，設計了這款UI 自動化測試程序。旨在提供接口，集成到蝸牛自動化測試框架，方便用例的設計。

整個程序是基於 selenium 設計的。程序對 selenium 提供的接口進行了二次封裝以知足平常的用例設計，二次封裝後的接口解決了元素加載，元素定位解析等問題，可讓用例設計變得更加簡捷。

之因此採用 Selenium 的模式。緣由一，對於用戶來講這是一個開源框架，很想窺探一二; 緣由二，Selenium 可無縫接入。這是一個用於Web應用程序測試的工具，支持多平臺、多瀏覽器、多語言去實現自動化測試，Selenium2將瀏覽器原生的API封裝成WebDriver API，能夠直接操做瀏覽器頁面裏的元素，甚至操做瀏覽器自己（截屏，窗口大小，啓動，關閉之類的）,因此就像真正的用戶在操做同樣。

目前支持：Mac、Windows操做系統，chrome、Firefox、IE瀏覽器。

2.工做原理

• 在蝸牛管理後臺添加測試用例。

• 蝸牛管理後臺測試用例執行調用任務執行接口，傳送任務id及測試數據的JSON格式字符串給程序。

• 程序根據獲取數據，解析並處理。

• 啓動瀏覽器後，selenium-webdriver會將目標瀏覽器綁定到特定的端口，啓動後的瀏覽器則做爲webdriver的server。

• 客戶端(也就是測試腳本)，藉助ComandExecutor發送HTTP請求給server端（通訊協議：The WebDriver Wire Protocol，在HTTP request的body中，會以WebDriver Wire協議規定的JSON格式的字符串來告訴Selenium，咱們但願瀏覽器接下來作什麼事情）。

• Server端須要依賴原生的瀏覽器組件，轉化Web Service的命令爲瀏覽器native的調用來完成操做。

• 最後將處理結果及任務id經過JSON字符串的格式返回給蝸牛，經過蝸牛的管理後臺可查看每條用例執行結果。

3.框架介紹

3.1．工程結構

 

按照實際的業務流程調用對應接口來實現 WEB-UI 自動化測試用例。case 層可調用 service 層和 pageObject 層的接口，pageObject 是對每個頁面元素的一個封裝，service 是對一個經常使用的業務模塊功能的封裝。好比一個查詢企業信息的測試用例，須要依賴登入，這個業務功能就能夠直接調用 service 中的接口。企業查詢的建立就能夠調用 pageObject 中的接口，而後按照查詢的業務流程，在測試用例中把這些接口串起來就造成了一個 UI 自動化測試用例，詳細細節接下去會舉例說明。

如企業查詢。查詢以前，須要登入管理後臺，登入操做已封裝到業務層，直接調用 service 層的接口，不須要在乎這個步驟的細節；登入以後要指定一個路徑，找到對應的空間，直接調用 model 層的接口，不須要在乎這個步驟的細節；接着是建立查詢，建立查詢的全部定位方法也封裝到業務層，這就是個企業查詢的實現，也是用例設計中最主要的環節。

整個工程基於 selenium，採用 pageObject 模式搭建。下面對工程中的幾個重要模塊作介紹。

 

3.1.1 driver — 接口層

對 web 頁面全部元素的操做都是在driver定義接口並實現的。driver 對 selenium 提供的接口作了二次封裝，對外提供封裝後的接口。pageObject 實現了一些公共方法，好比給輸入框賦值等，目前 pageObject封裝的方法很少，大多功能均可以經過 selenium 實現。driver 層對開源工具接口作了二次封裝，想要驅動一個瀏覽器還有一個必不可少的工具 —— 瀏覽器驅動，這個驅動放在 Referenced Libraries 裏，驅動的版本必須與被測瀏覽器版本相匹配。

3.1.2 model — 數據模型

建立數據模型爲了實現測試數據和測試用例分離而採起的一種方法，具體的測試數據初始化。能夠對一個業務流程中須要測試數據的元素在一個 model 中定義出來，方便管理和代碼閱讀。

3.1.3 pageObject — 業務層

pageObject 模式，採用接口形式封裝每個頁面須要用到的元素，實現封裝只要作兩步：一、肯定元素的定位方式；二、調用 driver 中對應的操做接口。driver 的接口實現包含了必定的容錯能力，但並非全面的，部分頁面或者組件具備獨特性，單純調用 driver 的接口並不能保證測試用例的穩定性，此時就須要在 pageObject 的接口實現中加入一些容錯算法，確保用例穩定性。

3.1.4 service — 提供業務功能

一個業務流程不少時候依賴其餘業務模塊功能，爲了方便設計一個測試用例，也爲了不重複造輪子，service 層就提供了一些經常使用的業務功能，好比登入、企業查詢等。依賴方只須要在 service 層調用便可。

3.2．功能優化

對selenium 作二次封裝的同時也對接口作了優化，框架的初衷是使UI 用例的設計儘量的易設計、易讀、易維護。

3.2.1 接口優化

直接調用 selenium 的接口常常會遇到些使人頭疼的問題，好比網絡問題使頁面 loading 太慢，須要操做的元素還沒展現出來，這種狀況就會常常報元素找不到的 error，致使用例執行失敗，但實際上這種報錯並非一個 bug，其測試結果是無效的。爲了減小誤報率 driver 層接口設計了等待元素加載的功能，使用的關鍵方法：cf.searchForElementVisibleXpath(TestStartQuitwd.wd, "//*[text()='運營平臺登陸']", id, 200, 100L)。參考代碼：

 

在 click、input 等操做接口中加入循環查找的判斷可最大限度的等待一個元素的加載從而提升測試用例的穩定性。

3.2.2 元素定位統一入口

接觸過 UI 自動化用例設計的測試人員會比較清楚，想經過 selenium 操做一個元素，其中必不可少的就是對元素定位的描述，通俗的講就是要通知接口在當前頁面操做哪一個位置上的元素。定位一個元素的方法不少，經常使用的有 id，name，css，xpath 等，對應不一樣的定位方法selenium 在處理上也給出了不一樣接口，這從維護角度上來考慮顯然不是最好的。最好的作法就是用例設計者只管元素定位和操做事件的調用，而事件在實現上走了哪一種渠道最好是無感知，無需維護的。對此框架封裝了一個方法供 driver 調用，主要功能就是解析描述元素的字符串自動判斷是 id、css 仍是 xpath。

3.3．元素定位

UI自動化用例其實能夠分紅兩部分，1. 定位元素；2. 調用接口操做該元素。其中定位一個元素的方法不少，經常使用的有 id，name，css，xpath。實際設計中選擇哪一種定位方法通常會在維護角度上考慮的會多一些，由於如今的服務器性能配置等都很優秀，因此跑一個WEB-UI用例能夠不用考慮性能問題。從維護成本上考慮會優先選擇 id、name，其次 css，最後用 xpath。

咱們不能保證每個 web 系統的全部元素都能提供一個惟一 id 或 name，固然若是能和前端開發達成合做，這就是一件很美好的事情了。通常狀況下咱們都須要面對沒有 id 和 name 這兩個屬性的狀況。這時咱們就可使用 css 樣式，不少時候 css 樣式是能知足咱們的定位需求。固然在這些都不提供給咱們的狀況下就只能選擇 xpath，使用 xpath 的優勢 1. 易獲取，主流瀏覽器只要打開「查看」就能夠經過 copy 輕鬆獲取到；2. 頁面上的元素均可以用 xpath 來描述；缺點，不穩定，大量使用會給用例維護產生很大的負擔。

xpath 通常只要前端在頁面上作一下小調整，用例就必須從新維護，在不得不使用 xpath 的狀況下，爲了減小從此的維護量，可對 xpath 作一些優化，能夠減小 xpath 的路徑長度提升穩定性。如下是實踐過程當中最長用到的幾種類型：

• 依靠本身的屬性文本定位，如 //input[@value=‘XXXXX’]
• 包含指示性字符，如 //input[contains(text(),’指示性字符’)]
• 巧妙使用content，如 //*[@id=‘app-container']

4.常見報錯

使用過程當中常常會遇到問題，這裏作下總結方便 debug。

1.某些頁面彈窗，有時候定位不到彈窗元素。理論上 selenium 在一個頁面中查找一個元素是能夠定位到，但有些時候出現彈窗，此時就須要在從新定位彈窗。解決方法：

 

2．有些輸入框不能被 input 接口正常操做。實踐過程當中在日曆控件中遇到過，元素定位什麼的都對，但就是不能正常被操做。解決方法：判斷元素是不是select類型，以後再賦值。解決代碼：

 

3.發現 selenium 的某些接口不能 work 了，此時最大的可能就是瀏覽器升級了。解決方法：從新下載低版本瀏覽器。

4.元素不可見。有一種元素能在頁面上正常展現，但對於工具來講它是不可見的，這是由於在通常狀況下，元素可見須要知足如下幾個條件：visibility!=hidden ; display!=none; opacity!=0; height、width都大於0;對於 input 標籤，沒有 hidden 屬性。如截圖就是隻讀的實例。

 

解決方法：調用接口 TestStartQuitwd.js.executeScript("var txtN = document.getElementsByName("timeRange"); txtN[0].readOnly = false;");

5.結束語

UI自動化是在開源工具的基礎上作了些優化，在 driver 層，數據層、業務層以及用例層的解決方案還有很大的提高空間。WEB-UI自動化還不完美，後期還需繼續努力。感謝一直以來支持研究的小夥伴。

-來源：宜信技術學院官網：http://college.creditease.cn/#/index

做者：顏博蓮