网易有道 UI 自动化探索与落地方案
前言
文末給大家準備了資料（好幾套面試題加學習資料等），需要自取！
《Succeeding with Agile》一書中提出了測試金字塔這個概念。它將軟件測試按照不同的粒度進行分類，越上層代表測試的集成度越高但執行越緩慢；越下層代表測試的隔離性越好但執行越輕量，所以一個快速、可維護、覆蓋范圍合理的測試模型可以大致概括為：70% 小而快的單元測試 +20% 覆蓋率高的接口測試 +10% 的 UI 測試。
然而，在大家固有的認知中，UI 自動化投入高、維護成本大、運行穩定性差，我們要怎么合理的分配業務場景和時間上的投入，才能最大程度的提升回報率呢？
對于有道來說，軟件部分的測試也一直沒有形成廣泛而通用的 UI 自動化方案。隨著業務的高速前進，客戶端的發版愈加頻繁，發版又通常節奏緊湊且優先級高，每次發版都需要進行 “核心 Case” 的回歸以保證 APP 主流程、主功能的完好。單對 “有道精品課” 這一個 APP 來說，平均每周發版一次，每次發版有 4-5 個小組需要進行 “核心 case” 的回歸，每個小組大概花費 4 小時的時間。而” 核心 case“又不常變動，所以使用 UI 自動化來解決發版回歸測試導致的人力浪費問題是非常合適的。
下面我從前期的調研總結、最終方案、重點模塊的原理與優化方案介紹、使用效果這幾個方面為大家分享一下我們安卓端目前采用的 UI 自動化方案。
方案調研
通過調研目前各互聯網公司公開出來的已有方案，以及結合公司內其他同事的調研、實踐文檔，我將 UI 自動化包含的工作規整為 5 類，分別是：構造 Case、校驗 Case、修改 Case、回放 Case、回放結果。下面將分別說明每一類中我所期望的方案與目前已有方案之間的差異。
構造 Case
構造 Case 是指基于 Case 的路徑，模擬用戶真實的手勢操作。
最常用的工具是以 selenium 為代表的，通過寫代碼來定位目標元素，再調用工具內置的函數對定位到的元素進行操作。但真實用起來會發現這要求測試同學學習語法、寫代碼，上手門檻高而且編寫 Case 花費時間長；后來出現了 smart Auto 這種提供了一些語法糖的工具，使用更貼合人們語言的偽代碼，雖然降低了測試同學的學習和應用成本，但是依然需要經歷將實際的手勢動作翻譯為代碼再編寫出來的冗余過程；后來又有了 Espresso 一類可以錄制操作的工具，可是他們大多需要手機連接電腦，在電腦 “投影” 過來的屏幕上用鼠標模擬手勢操作，仍然是比較耗時且無法滿足我們一些特殊的情景（比如二維碼掃描功能等）。
基于以上的調研和分析，我們希望能有一個工具不需要翻譯成任何的代碼語言、直接在手機端就可以錄制操作。這樣既降低了測試同學的使用門檻，又縮短了構造 Case 的時間。
b. 校驗 Case
校驗 Case 是指用戶一系列操作后，判斷結果是否符合預期，也就是說是否到達了我們希望的頁面，頁面中的內容、排版、樣式甚至是到達消耗的時間是否符合我們的預期。
而目前對 Case 結果的校驗方式，大多數都是判斷某個文案或者某個元素 id 是否存在。但很多情況下，文案和元素 id 的內容是動態變化的，而且僅僅通過某個文案存在 or 某個元素存在只能證明這個元素是正常的，并不能證明 UI 層面的正確性，所以我們希望可以在不寫代碼的基礎上，做到真正的對 UI 展示進行校驗。
c. 修改 Case
Case 的維護成本是 UI 自動化飽受詬病的部分，原因是校驗和構造 Case 都是通過硬編碼的方式生成的，無論操作路徑更改還是結果更改還是頁面元素更改都需要對 Case 進行修改，修改又需要重復 “查找元素、寫代碼” 的過程。雖然我們選擇了不易變更的核心 Case 做 UI 自動化，減少了一部分的維護成本，但我們仍然希望可以進一步減少對 Case 的維護。
d. 回放 Case、回放結果
執行階段只要保證 Case 可以穩定、較快反應速度的回放即可，只要前期構造 Case 和校驗 Case 部分精心設計，回放一般不會有太大的問題。
但對于回放結果的處理上，一方面是目前已有的工具很多都只展示當次回放的結果，或者將回放結果存儲在手機端，并不能對結果長期的保存、對比。可對于發版的回歸測試來說，我們需要對每次的結果以及回歸內容有一個長期的記錄，方便發版過程中各角色人員實時查看，更是保證數據的可回溯性；另一方面我們希望可以對結果二次評論、手動確認，保證每個執行失敗的 Case/異常情況都有確定的人員進行跟進并有地方記錄和保存跟進結果。
方案的確定
基于以上的調研和對調研結果的分析，再結合我們的預期，我們最終選用的方案是：
1、構造 Case：對開源工具 Solopi 二次開發，使其更貼合我們需要的手勢/操作，達到純手機端錄制操作步驟的效果，Solopi 具體的使用和原理在這里就不做詳細介紹了，大家可以移步 GitHub 查看官方文檔。
2、校驗 Case：對關鍵步驟的執行結果進行截圖，使用 openCV 與已知該步驟正確的圖片進行對比，達到校驗 UI 層面是否正確的期望。另外直接截圖對比的方式也省去了校驗規則修改帶來的 UICase 的修改工作。
3、回放結果：搭建測試報告平臺，擴展 Solopi 的 schema，實現回放結果的持久化和二次批注功能。
重點模塊的實現與優化
a. 數據構造階段的實現：
用戶在手機端使用 Solopi'對 “核心 Case” 的操作步驟進行錄制，錄制過程中在需要做校驗的位置截圖并對該位置的截圖命名，錄制結束后會生成錄制腳本的 JSON 文件和一批截圖，這兩部分產物我們可以通過平臺的 “UI 信息管理頁” 進行上傳錄入&維護更新。通過這一步我們確保了參照系的截圖是經過人工檢查的，后續回放過程中產生的截圖和這一版本的截圖進行對比，結果才具有可靠性。如果某個步驟校驗的頁面結構/內容發生了變化，我們也僅需要在平臺中將對應的這一張截圖進行替換即可，大大節省了 UICase 的維護成本。
錄制 UICase 的過程中，很多用戶的操作都會對數據庫產生影響，以往我們會使用 Mock 接口的方式處理 post 請求，但 Mock 接口依然需要大量的維護成本且并沒有做到完全真實的模擬用戶操作。所以我們采用將請求錄制下來，簡單的篩選后復用的方式，在回放結束后搭配清理數據的步驟，就可以保證錄制場景從 UI&接口兩個方面的可重復回放性。
我們將"為該 UI 操作開始前構造數據的一系列接口、該 UI 的操作信息、該 UI 操作結束后清理數據的一系列接口"按照正確的順序拼裝成一個 Case，多個 Case 再次組裝，這樣就獲得了回放單元——執行集。
b. 執行與結果收集階段的實現：
回放是以"執行集"單位進行的，測試同學想對某個執行集進行回放的時候，只需要在平臺下載一個用于回放的 Zip 包到本地，將電腦和手機連接，運行 Zip 包中的 EnvController 即可開始回放。
EnvController 會先自動構造出本次回放需要的環境，然后驅動 orderController 按照執行集中所有 Case 的配置，一步步執行接口請求 or 調用 Solopi‘進行回放。當所有的步驟完成后，ReplayCore 會把回放結果收集起來通過 PicHandle 服務將本次回放的截圖和參照系截圖做對比，生成最終的結果。
最終結果上傳到平臺后，不同的結果狀態會有不同的標識，對比有異常的圖片會用紅色框標出，方便測試同學 check。測試同學還可以對回放結果進行二次的人工審核、批注和狀態的更正。也可以將本次回放失敗的 Case 一鍵生成一個新的執行集，進行新一輪的回放。
c. 執行順序性的保證：
如果本次執行步驟是接口請求，那我們通過 OrderController 直接發送 HTTP 請求，這個過程是同步的，我們只需要等待 HTTP 的響應結果即可。但回放 UI 操作是通過 adb 調用 Solopi'的 schema 來進行的，這個命令是異步的，并且回放 UI 操作所花費的時間是不固定的，那我們該怎么在 Solopi'端回放結束后通知到 OrderController 進行下一步的操作呢？
這個過程中我們經歷了幾次的嘗試，最終采用的方案是在 OrderController 調用 adb 的同時，向手機端的 NowOrder 文件寫入當前正在執行第幾步，當 Solopi'端回放結束的時候通過 NowOrder 文件中的內容作為參數再通知 OrderController 進行后續的指令查找和判斷，這樣就保證了執行的順序性。
這樣做還有一個好處，如果回放因為各種各樣的原因被暴力終止了（電腦沒電了、手機和電腦斷開了連接等），我們也可以通過 OrderController 的日志或者手機端 NowOrder 的內容快速判斷出當前被中斷的是哪一個步驟，使用人工驅動 OrderController 的方式繼續回放。
d. 圖片對比的優化之路：
我們有了參照系圖片和待驗證圖片后，就希望通過圖片對比的方式篩分圖片，一開始選用了 md5 的方式對比，但由于 md5 的對比太過于嚴格，而頁面 UI 常常有 1px 量級甚至更小的差距，但這些差距是可以接受的，并且通過 md5 對比后雖然能得到兩張圖片是否一致的結論，但難以標注出有差異的區域，所以為了讓測試同學更加清晰的看出兩張圖片的區別，我后面選取了 openCV 圖片對比的方式，先將截圖中手機自帶的工具欄裁剪掉，減少噪聲后再做對比，并將對比不一致的位置使用紅色方框標出，大概實現的效果如圖：
試用一段時候后，我們發現，如果圖片有差異的點比較集中，就會導致圖片中紅框密集，甚至無法看清截圖原本的樣子，給測試同學人工 check 帶來一些不便，于是在對比圖片的代碼中優化了紅框放置規則的算法，解決了紅框相互密集覆蓋的問題。
效果與總結
雖然實現方案中涉及到的模塊比較多，但這些對于測試同學來說全部是黑盒的，測試同學只需要在平臺中簡單的操作和配置即可，所有的用戶相關的操作如下：
為了達到無人值守的效果，我在很多位置都增加了通知功能，正常結束/各種異常的情況都能第一時間通知到執行人，保證 UI 自動化回放開始到驗收結果之前，都不需要再投入人力。
在這段時間的探索和實踐中，我認為 UI 自動化不應該為了有而有，也不應該是別人都有我們也要有。我們并不能通過一個團隊是否有 UI 自動化或者什么其他的測試手段來評判一個測試團隊是否先進和高效。UI 自動化應該是隨著業務迭代、業務形態的變化趨勢應運而生的，在這個基礎上找到合適的業務開展 UI 自動化工作，才能得到更高的性價比。通過這篇文章的介紹，希望能給大家提供一些在 UI 自動化方面的想法和思路。
福利
?
總結
以上是生活随笔為你收集整理的网易有道 UI 自动化探索与落地方案的全部內容，希望文章能夠幫你解決所遇到的問題。
