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

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

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

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

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

Totoro C/S架構模型設計

螞蟻金服移動測試平臺最開始引用了 Appium 開源解決方案，但因爲其部署複雜、接口不穩定、設備掉線、多層服務鏈路、社區維護不夠迅速等種種問題，綜合評估業內相似框架都有共性的痛點，所以咱們決定從新設計一套適合雲測集羣環境、知足域內不一樣業務需求快速迭代更新的解決方案。

基於已有的痛點，咱們認爲 Totoro 從設計上須要知足「調用鏈路儘量短」、「項目結構儘量簡單透明」等特色，從而確保測試鏈路上的不穩定因素儘量少。同時，綜合考慮異常狀況下，咱們須要可以快速定位問題，並具有必定的自修復能力。結合業內多個框架廣泛採用三層或多層的設計，Totoro 最終被設計成了 C/S 模型的兩層架構。

兩層架構的設計理念實際上爲 Totoro 帶來不少優勢，好比：

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

全鏈路穩定性構建

面對螞蟻雲測集羣自動化嚴格的要求，穩定性的問題依然浮出水面，成爲 Totoro 不得不解決的一道難題。

在自動化任務的任何鏈路節點都有可能發生異常，因此穩定性實際上覆蓋多個層面，好比：

• 框架自己 API 功能穩定性；
• 宿主服務穩定性；
• 設備連接在線穩定性；
• 設備網絡穩定性；
• 硬件 Hub 穩定性。

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

1. 程序異常全面治理

Totoro 框架在前期開發中，平常維護須要投入極大精力，每日要面臨框架自身缺陷引發的異常和各類業務自身的異常問題。同時，各種異常問題要求人工篩選，從而推進框架自身及業務方去解決。由此帶來的結果是，大部分雲測任務由於這類代碼問題而引發終止，致使測試開發不夠穩定。

爲了改善任務異常帶來的不穩定因素，杜絕框架自身 SDK 問題，而且業務異常可以作到智能分類，咱們首先作了一次全類型異常堆棧的上報統計。根據後臺統計數據能夠大概分爲「業務層邏輯異常」和「SDK 層異常」，針對發現問題，咱們集中投入專項研發精力，修復框架邏輯不合理引發的異常，杜絕 SDK 自身問題；針對海量業務異常，咱們作了一層抽象歸類，將業務異常邏輯歸類爲明文提示並給予必定推進建議，而且添加檢測點狀態校驗；針對某些偶現異常，重腳步層作一次重試提示用例結果成功率。

在程序異常治理過程當中，咱們發現業務用例大多都須要在程序各個運行階段封裝一些業務邏輯，然而 SDK 層也會有必定的初始化過程，經過 JUnit run 起來的用例一旦業務封裝或SDK層接口調用實際不對，就有可能引發程序不穩定現象。所以，Totoro 框架更加現有的業務需求現狀，及平常已發現的問題，自身定製了一套規範的 Totoro 用例生命週期，業務用例能夠在鉤子方法中封裝各個節點的邏輯。

2. 手機宿主服務穩定性保障

Totoro 框架在手機中的核心服務（TotoroUiautomator/TotoroWDA）在用例執行過程當中，會發現連接失敗、服務不可用等狀況，這種不穩定因素更可能是系統限制形成的，能作的就是在恰當時候重啓服務，保障整個自動化流程正常進行。

• API 接口級別異常分析，過濾服務異常狀況，觸發重啓。而且可以保留或恢復用例現場。
• Agent daemon 進程服務輪訓監控，動態啓動異常服務（針對 TotoroWDA）。
• 端口轉發失效的假性異常分析，經過網絡探測，觸發假重啓邏輯。

3. 手機穩定連接策略

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

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

軟件鏈路上的能力是指集成在 Totoro Client 端的一套設備恢復方案，嵌入在底層通訊接口處，一旦發現設備掉線，能夠經過遠程網絡服務，發送消息到手機中的核心服務，經過設備 owner 權限重啓手機 ADB，若是依舊失敗將進行 PC 端鏈路的 usbreset。

正常狀況下，三次重啓內手機 ADB 幾乎都能恢復。個別狀況恢復失敗的，會有現場詳細信息上報，且會觸發 changedevices 策略更換手機從新執行測試任務，保障流程正常。若是根據歷史上報數據統計，分析老舊設備處於常常掉線的不穩定狀態，會採起降級措施，調換到對連接要求低的設備池中（如 monkey 池）或下線操做。

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

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

4. 設備網絡穩定性

設置網絡服務的穩定提供，咱們主要作了如下幾方面嘗試：

• 用例失敗檢測點的網絡探測快照，快速定位用例失敗現場是否有網絡問題；
• SLM 雲終端服務管理手機網絡，可以自動連接指定網絡，並具有網絡異常後重置連接能力；
• 雲測平臺集羣環境升級機櫃，隔離網絡，保障網絡熱點穩定性。（終端實驗室的集羣服務將以規範化的屏蔽機櫃爲單位，提供穩定的移動自動化服務）。

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

在真實的用例構建環境中，須要有不少細節策略點保障整個服務的穩定運行，這裏主要羅列幾條主要的方案：

• 針對頑固偶現的不穩定因素，採起 DeviceChange（更換設備）策略。
• 針對手機內存、資源等系統限制，會採用 DeviceReboot（重啓手機）策略。
• 針對偶現的既定的幾種抽象異常類型，採用從新執行策略，有效提升成功率。
• 針對全場景的異常點，釘釘報警，及時發佈補丁。

安卓App全自動智能安裝

螞蟻雲測自動化執行集羣環境中，應用全自動智能安裝是最多見場景之一，然而 Android ROM 的碎片化和各個廠商的定製化，致使在安裝過程當中須要適配各類各樣的彈窗；甚至部分廠商須要登陸態且要求輸入帳號密碼，致使在數以千計的機型集羣環境中全自動智能安裝應用成了一個挑戰。以下圖部分安裝彈窗場景：

1. 技術選型

Totoro 框架的自動化服務能力是基於 Uiautomator2 深度定製的，所以整個服務會以 APK 形式安裝在手機端。要作到一套完整的全自動安裝方案，就必須拋棄在 Totoro 服務 APK 裏實現。

最終，咱們採用了能夠獨立在手機中免安裝直接運行的 Uiautomator1 方案進行實現，做爲獨立的安裝彈窗處理專項進行迭代更新。

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

最終實現了一套能夠處理大部分 ROM 安裝彈窗場景的持續迭代的智能安裝彈窗處理方案。

2. 智能盲點

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

針對該場景，咱們對機房的手機作了大量的安裝調研，發現彈窗的 button 出現的位置區域和意義是有必定規律的，有些須要服務重啓才能 dump 控件信息，有些是按照版本及機型呈現規律的 UI 樣式，有些須要特殊的手機 Action 才能獲取相應事件。咱們將這些規律進一步抽象分類，作了一套智能盲點邏輯，針對沒法 dump 到的場景具有拓展兼容的能力。

3. 算法輔助實踐

智能盲點在個別規律沒有考慮周全的場景下仍然會出現失敗的狀況，那麼，如何構建一套自適應的能力呢？

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

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

4. 雲測效果視頻

目前自動化安裝組件通過多緯度的場景兼容，已具有必定自適應能力，可以完成平常自動化安裝任務，目前已處於極低成本的維護狀態。除了應用在平常自動化任務中，該功能也嵌入了雲測平臺的遠程租用功能，如下是安裝效果：

全場景的彈窗治理

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

1. 深度改造安卓 Watcher 接口

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

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

安卓 Accessibility 服務能夠經過註冊，監聽彈窗或者頁面甚至一個細微的控件變化，爲了性能均衡，只需註冊彈窗變化回調事件便可。這樣一套穩定的彈窗監聽回調機制就構建好了。

2. 多維度註冊監聽

有了保障 registerWatcher 接口的回調穩定性的機制，那個咱們就能夠依賴這個接口去監聽頁面UI的變化，作到穩定處理頁面彈窗。結合業務需求及平常用例場景，Totoro 框架中能夠針對如下緯度來監聽頁面變化，作到幾乎全場景的彈窗治理。

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

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

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

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

​

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

重要里程碑與規劃

Totoro自動化測試框架從立項到如今已經走過近三個年頭，目前仍然處於快速迭代時期。最近一年，項目自身穩定性質量有了質的提高，在與螞蟻雲測平臺共同努力下，愈來愈多的域內 BU 選擇螞蟻雲測和 Totoro 做爲移動自動化雲測方案。

規劃

爲更好的支撐域內及 mPaaS 移動自動化測試測試技術，高效輸出 Totoro 實驗 SDK ，咱們還有不少事情能夠完善。

將來，咱們將從如下幾個場景發力，朝着規範化、可擴展、多語言平臺、插件化方向繼續努力發展。

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

活動推薦：

「7 月 27 日：mPaaS 與你上海見」

App 架構設計缺乏彈性動態從而致使可用性低，啓動性能差、缺乏弱網加速等，直接影響用戶體驗和業務發展。

本期 CodeDay 將重點提煉支付寶內部最佳實踐，結合性能優化、動態研發、小程序一站式研發等議題展開，更有配套的 Demo Show，不可錯過！