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 賦能，繼續深挖落地場景 ；
• 構建開發者社群，擁抱開發者，支援域內更多的業務線，最大價值化專案的業務價值 。