干貨分享：Totoro 在自動化測試領域的深耕與收獲

自動化測試框架 Totoro 是由螞蟻金服終端工程技術部實驗平臺技術組自主研發(fā)的一套自動化測試框架，支持  Android 、 iOS 、 HTML5 、 小程序 、 Weex 、 Cube  等移動端自動化測試場景。

為了確保螞蟻金服移動測試平臺在集群環(huán)境下能夠穩(wěn)定、高效運行自動化任務，并靈活快速支持多場景域內業(yè)務，Totoro 經歷了從 0 到 1，從 1 到 2，并逐步演進到目前支撐阿里域內 10+ BU 日常自動化測試及結合移動開發(fā)平臺 mPaaS 對外輸出，成為集團內使用面最廣、性能最為穩(wěn)定的自動化測試框架之一。

本文將圍繞 Totoro 一路踩坑、迭代完善成熟的過程，從沉淀總結的一些方法論和解決方案展開分享：

• Totoro C/S 架構模型設計
• 全鏈路穩(wěn)定性構建
• 安卓 App 全自動智能安裝
• 全場景的異常彈窗治理
• Totoro 重要里程碑及未來規(guī)劃

Totoro C/S架構模型設計

螞蟻金服移動測試平臺最開始引用了 Appium 開源解決方案，但由于其部署復雜、接口不穩(wěn)定、設備掉線、多層服務鏈路、社區(qū)維護不夠迅速等種種問題，綜合評估業(yè)內類似框架都有共性的痛點，因此我們決定重新設計一套適合云測集群環(huán)境、滿足域內不同業(yè)務需求快速迭代更新的解決方案。

基于已有的痛點，我們認為 Totoro 從設計上需要滿足“調用鏈路盡可能短”、“項目結構盡可能簡單透明”等特點，從而確保測試鏈路上的不穩(wěn)定因素盡可能少。同時，綜合考慮異常情況下，我們需要能夠快速定位問題，并具備一定的自修復能力。結合業(yè)內多個框架普遍采用三層或多層的設計，Totoro 最終被設計成了 C/S 模型的兩層架構。

兩層架構的設計理念實際上為 Totoro 帶來很多優(yōu)點，比如：

1. 服務統(tǒng)一集成到了手機端，縮減了 PC 端的繁雜調用 ：只要 Client 端與手機鏈接，就可以開始自動化流程，避免了中間服務的命令中轉及服務本身資源管理；
2. 真正的 C/S 架構模型 ：無論在自動化的調用速度還是鏈路的穩(wěn)定性上都有了質的提升，此外簡單的架構模型確保了近些年框架快速迭代的可行性。

全鏈路穩(wěn)定性構建

面對螞蟻云測集群自動化嚴格的要求，穩(wěn)定性的問題依然浮出水面，成為 Totoro 不得不解決的一道難題。

在自動化任務的任何鏈路節(jié)點都有可能發(fā)生異常，所以穩(wěn)定性實際上覆蓋多個層面，比如：

• 框架本身 API 功能穩(wěn)定性；
• 宿主服務穩(wěn)定性；
• 設備鏈接在線穩(wěn)定性；
• 設備網絡穩(wěn)定性；
• 硬件 Hub 穩(wěn)定性。

接下來我們從以上 5 個方面闡述在整個調用鏈路上我們都做了那些努力。

1. 程序異常全面治理

Totoro 框架在前期開發(fā)中，日常維護需要投入極大精力，每日要面臨框架自身缺陷引起的異常和各種業(yè)務自身的異常問題。同時，各類異常問題要求人工篩選，從而推動框架自身及業(yè)務方去解決。由此帶來的結果是，大部分云測任務因為這類代碼問題而引起終止，導致測試開發(fā)不夠穩(wěn)定。

為了改善任務異常帶來的不穩(wěn)定因素，杜絕框架自身 SDK 問題，并且業(yè)務異常能夠做到智能分類，我們首先做了一次全類型異常堆棧的上報統(tǒng)計。根據后臺統(tǒng)計數(shù)據可以大概分為“業(yè)務層邏輯異?！焙汀癝DK 層異?！?，針對發(fā)現(xiàn)問題，我們集中投入專項研發(fā)精力，修復框架邏輯不合理引起的異常，杜絕 SDK 自身問題；針對海量業(yè)務異常，我們做了一層抽象歸類，將業(yè)務異常邏輯歸類為明文提示并給予一定推動建議，并且添加檢測點狀態(tài)校驗；針對某些偶現(xiàn)異常，重腳步層做一次重試提示用例結果成功率。

在程序異常治理過程中，我們發(fā)現(xiàn)業(yè)務用例大多都需要在程序各個運行階段封裝一些業(yè)務邏輯，然而 SDK 層也會有一定的初始化過程，通過 JUnit run 起來的用例一旦業(yè)務封裝或SDK層接口調用實際不對，就有可能引起程序不穩(wěn)定現(xiàn)象。因此，Totoro 框架更加現(xiàn)有的業(yè)務需求現(xiàn)狀，及日常已發(fā)現(xiàn)的問題，自身定制了一套規(guī)范的 Totoro 用例生命周期，業(yè)務用例可以在鉤子方法中封裝各個節(jié)點的邏輯。

2. 手機宿主服務穩(wěn)定性保障

Totoro 框架在手機中的核心服務（TotoroUiautomator/TotoroWDA）在用例執(zhí)行過程中，會發(fā)現(xiàn)鏈接失敗、服務不可用等情況，這種不穩(wěn)定因素更多是系統(tǒng)限制造成的，能做的就是在恰當時候重啟服務，保障整個自動化流程正常進行。

• API 接口級別異常分析，過濾服務異常情況，觸發(fā)重啟。并且能夠保留或恢復用例現(xiàn)場。
• Agent daemon 進程服務輪訓監(jiān)控，動態(tài)啟動異常服務（針對 TotoroWDA）。
• 端口轉發(fā)失效的假性異常分析，通過網絡探測，觸發(fā)假重啟邏輯。

3. 手機穩(wěn)定鏈接策略

手機掉線問題是自動化任務流程中必須面對的問題，Totoro 聯(lián)合螞蟻云測平臺采用了一套軟硬件全鏈路的設備在線保障服務。

Ⅰ. 軟件鏈路上的掉線恢復能力

軟件鏈路上的能力是指集成在 Totoro Client 端的一套設備恢復方案，嵌入在底層通信接口處，一旦發(fā)現(xiàn)設備掉線，可以通過遠程網絡服務，發(fā)送消息到手機中的核心服務，通過設備 owner 權限重啟手機 ADB，如果依舊失敗將進行 PC 端鏈路的 usbreset。

正常情況下，三次重啟內手機 ADB 幾乎都能恢復。個別情況恢復失敗的，會有現(xiàn)場詳細信息上報，且會觸發(fā) changedevices 策略更換手機重新執(zhí)行測試任務，保障流程正常。如果根據歷史上報數(shù)據統(tǒng)計，分析老舊設備處于經常掉線的不穩(wěn)定狀態(tài)，會采取降級措施，調換到對鏈接要求低的設備池中（如 monkey 池）或下線操作。

Ⅱ. 硬件鏈路上的設備鏈接護航能力

在硬件鏈路的穩(wěn)定性構建中，大多云測平臺選擇購買質量較好的 USB Hub。然而螞蟻云測平臺目前要面臨每日 7k+ 級別的自動化任務和 mPaaS 金融云級別的用例穩(wěn)定性挑戰(zhàn)，經過實驗，市面上再好的設備也無法達到的所有工程需要的質量標準，并且缺少智能控制模塊。因此螞蟻終端工程技術部實驗平臺組自研了一套 SmartHub，具備獨立穩(wěn)定的供電模塊，每個端口可遠程程序自動控制（電壓/電源/重置等）。目前為止 SmartHub 已經全面量產并投入使用，效果圖如下：

4. 設備網絡穩(wěn)定性

設置網絡服務的穩(wěn)定提供，我們主要做了以下幾方面嘗試：

• 用例失敗檢測點的網絡探測快照，快速定位用例失敗現(xiàn)場是否有網絡問題；
• SLM 云終端服務管理手機網絡，能夠自動鏈接指定網絡，并具備網絡異常后重置鏈接能力；
• 云測平臺集群環(huán)境升級機柜，隔離網絡，保障網絡熱點穩(wěn)定性。（終端實驗室的集群服務將以規(guī)范化的屏蔽機柜為單位，提供穩(wěn)定的移動自動化服務）。

5. 多維度策略 提升用例成功率

在真實的用例構建環(huán)境中，需要有很多細節(jié)策略點保障整個服務的穩(wěn)定運行，這里主要羅列幾條主要的方案：

• 針對頑固偶現(xiàn)的不穩(wěn)定因素，采取 DeviceChange（更換設備）策略。
• 針對手機內存、資源等系統(tǒng)限制，會采用 DeviceReboot（重啟手機）策略。
• 針對偶現(xiàn)的既定的幾種抽象異常類型，采用重新執(zhí)行策略，有效提高成功率。
• 針對全場景的異常點，釘釘報警，及時發(fā)布補丁。

安卓App全自動智能安裝

螞蟻云測自動化執(zhí)行集群環(huán)境中，應用全自動智能安裝是最常見場景之一，然而 Android ROM 的碎片化和各個廠商的定制化，導致在安裝過程中需要適配各種各樣的彈窗；甚至部分廠商需要登錄態(tài)且要求輸入賬號密碼，導致在數(shù)以千計的機型集群環(huán)境中全自動智能安裝應用成了一個挑戰(zhàn)。如下圖部分安裝彈窗場景：

1. 技術選型

Totoro 框架的自動化服務能力是基于 Uiautomator2 深度定制的，因此整個服務會以 APK 形式安裝在手機端。要做到一套完整的全自動安裝方案，就必須拋棄在 Totoro 服務 APK 里實現(xiàn)。

最終，我們采用了可以獨立在手機中免安裝直接運行的 Uiautomator1 方案進行實現(xiàn)，作為獨立的安裝彈窗處理專項進行迭代更新。

針對國內機型及云測機房全線機型，安裝彈窗專項項目，前期以全覆蓋的方式抽象彈窗點擊規(guī)律，dump 頁面控件信息，查找關鍵字，做了機型緯度的適配，并且在每個任務有安全失敗報警機制，研發(fā)人員能夠快速兼容問題機型，及 UI 變更。

最終實現(xiàn)了一套可以處理大部分 ROM 安裝彈窗場景的持續(xù)迭代的智能安裝彈窗處理方案。

2. 智能盲點

由于整個彈窗處理依賴與 dump 控件信息邏輯，某些廠商（華為、vivo、oppo 等）為了防止黑產及其他安全考量，部分安裝鏈路上的彈窗頁面會禁止 dump 功能，導致我們獲取不到頁面信息，而無法判斷應該點擊的頁面坐標信息。

針對該場景，我們對機房的手機做了大量的安裝調研，發(fā)現(xiàn)彈窗的 button 出現(xiàn)的位置區(qū)域和意義是有一定規(guī)律的，有些需要服務重啟才能 dump 控件信息，有些是按照版本及機型呈現(xiàn)規(guī)律的 UI 樣式，有些需要特殊的手機 Action 才能獲取相應事件。我們將這些規(guī)律進一步抽象分類，做了一套智能盲點邏輯，針對無法 dump 到的場景具備拓展兼容的能力。

3. 算法輔助實踐

智能盲點在個別規(guī)律沒有考慮周全的場景下仍然會出現(xiàn)失敗的情況，那么，如何構建一套自適應的能力呢？

因此，我們在思考是否可以結合 AI 能力來智能分析頁面信息，由算法結果提供具體的點擊路徑方案，從而快速兼容遺留場景。

目前結合 OCR 服務，Totoro 具備智能分析界面信息，精準獲取點擊目標坐標，完成彈窗處理的能力。后續(xù)將結合深度算法實踐，采用安裝場景模型數(shù)據，讓算法直接給出操作建議，完成整個場景的自適應兼容方法。

4. 云測效果視頻

目前自動化安裝組件經過多緯度的場景兼容，已具備一定自適應能力，能夠完成日常自動化安裝任務，目前已處于極低成本的維護狀態(tài)。除了應用在日常自動化任務中，該功能也嵌入了云測平臺的遠程租用功能，以下是安裝效果：

全場景的彈窗治理

移動自動化測試過程中的各種手機彈窗是影響用例穩(wěn)定性執(zhí)行的重要因素之一，面對各種類型及場景的彈窗，Totoro 框架中自研了一套全場景的彈窗治理方案：

1. 深度改造安卓 Watcher 接口

異常彈窗的處理中，安卓框架中給出了  UiDevice.registerWatcher  接口方案。但是我們實際使用中發(fā)現(xiàn)，這個接口回調不是穩(wěn)定的，更加官方解釋,當自動化過程中查找一個控件失敗時候才會觸發(fā)回調。

為了能夠構建多場景的監(jiān)聽機制，必須要有一套頁面監(jiān)聽的穩(wěn)定回調接口。經過翻看 UiWatcher 相關源碼發(fā)現(xiàn)，可以通過 hook，主動觸發(fā)  runWatchers()  。而我們需要做的，還需要在頁面彈窗變化時，穩(wěn)定觸發(fā)該接口。

安卓 Accessibility 服務可以通過注冊，監(jiān)聽彈窗或者頁面甚至一個細微的控件變化，為了性能均衡，只需注冊彈窗變化回調事件即可。這樣一套穩(wěn)定的彈窗監(jiān)聽回調機制就構建好了。

2. 多維度注冊監(jiān)聽

有了保障  registerWatcher  接口的回調穩(wěn)定性的機制，那個我們就可以依賴這個接口去監(jiān)聽頁面UI的變化，做到穩(wěn)定處理頁面彈窗。結合業(yè)務需求及日常用例場景，Totoro 框架中可以針對以下緯度來監(jiān)聽頁面變化，做到幾乎全場景的彈窗治理。

• 注冊關鍵字文案監(jiān)聽
• 注冊內容模糊匹配，精準點擊目標控件
• 注冊 desc 文案
• 注冊資源 ID
• 注冊目標控件，觸發(fā)一個 Action

3. 機器學習圖像檢測方案

然后面對無法 dump 到控件信息的非 Native 頁面（H5 /小程序），就需要結合機器學習的方式，采用算法能力去分析頁面 UI 結構，去處理頁面中可能的異常彈窗。

Totoro 算法同學自研了一套控件 dump 算法能力，脫離平臺及頁面渲染方式，可以將 App 截圖通過算法生產頁面原始控件圖，滿足非 native 場景的彈窗處理。

目前機器學習的分析能力仍然在快速迭代中，除了應用在彈窗頁面分析處理外，還應用在頁面異常類型檢測（包括加載失敗、控件截斷黑白屏等），已成功落地小程序日常準入和支付寶錢包日常兼容性等重要業(yè)務線中，后續(xù)會推廣到更多的業(yè)務中去，讓 AI 賦能不是一句空話。

重要里程碑與規(guī)劃

Totoro自動化測試框架從立項到現(xiàn)在已經走過近三個年頭，目前仍然處于快速迭代時期。最近一年，項目自身穩(wěn)定性質量有了質的提升，在與螞蟻云測平臺共同努力下，越來越多的域內 BU 選擇螞蟻云測和 Totoro 作為移動自動化云測方案。

規(guī)劃

為更好的支撐域內及 mPaaS 移動自動化測試測試技術，高效輸出 Totoro 實驗 SDK ，我們還有很多事情可以完善。

未來，我們將從以下幾個場景發(fā)力，朝著 規(guī)范化 、 可擴展 、 多語言平臺 、 插件化方向 繼續(xù)努力發(fā)展。

• 繼續(xù)降低用例維護成本；
• 完善多端腳本語言支持；
• 標準化文檔、項目配置等構建；
• 加強 AI 賦能，繼續(xù)深挖落地場景；
• 構建開發(fā)者社區(qū)，擁抱開發(fā)者，支持域內更多的業(yè)務線，最大價值化項目的業(yè)務價值。