背景
在雲測試平臺設計中，Agent 的設計一般來講需要考慮如下一些場景：
- 移動設備的交互控制是否需要 PC 設備的支持
和移動端設備進行數據交互，主要有兩種方式，一是通過常規官方建議的 PC - Mobile 的調試方式，使用公共協議如：adb、usbmuxd 進行數據交互，二是直接在 Mobile 中植入代碼，通過代碼調用系統 API 和服務端進行交互，省去 PC 的中轉環節
- 移動設備在測試任務執行上如何隔離
設備在使用過程中還需要考慮到它會執行哪個 APP 、哪一種類型的 APP、哪一組人員、哪一種測試類型等的業務測試，所以在設計時需要考慮單個設備的「原子性」
- 設備如何做到動態運維和自動化程度
設備的維護對於服務端來講一般都會以設備池的方式運行，這樣就需要考慮到增加、刪除設備對設備池帶來的影響，同時如果設備的維護在公共實驗室或者在遠端的機房，那對應的操作就需要遠程完成，所以設備的維護、重置、監控等相關的操作也需要提供遠程 API
- 自動化框架選擇和運行環境
自動化測試是雲測試的主要目的，自動化框架的選擇會影響自動化測試能力的擴展範圍，所以需要選擇一款合適的「基礎」自動化測試框架
系統選型
知乎雲測平臺採用利用 PC 作爲維護移動設備的服務器，交互模式爲服務端 - PC 端 - 移動設備交互的方式，PC 端部署與服務端進行交互的 agent 代碼，採用 socket 進行通信確保即時性，同時通過 http 主動消費服務端維護的任務池，執行完畢之後返回數據並循環進行，在自動化任務執行上採用 Appium 做爲「基礎」自動化測試框架。系統選型主要基於如下幾點：
- 大部分自動化框架的運行都基於 Mobile 掛載 USB 對應的 PC 上，同時 Agent 服務、自動化框架、硬件運維、異常處理等都需要穩定的 PC 運行環境
- Netty Socket 框架可以提供穩定的即時數據交互
- 任務數據的處理在精度上要求更高，所以採用 Http 請求任務池的方式
- 自動化框架選取在各方面都具有一定優勢的 Appium，「主要是社區比較活躍」，同時設備執行測試任務的隔離也主要由 Appium 來進行控制，如下是對比圖：
Agent 模塊組成
Agent 模塊在雲測試平臺中主要負責設備控制、維護的功能，主要包括三大模塊如下：
實時任務
基於 Netty Socket
實時交互如下圖展示：
移動端設備控制
在這裏移動端設備控制是方便使用者可以在遠端通過一定的方式遠程控制設備的操作，同時看到設備的實時顯示畫面，經過各種調研、測試、實驗選取 openstf [https://github.com/openstf/stf] 開源的兩款工具 minicap / minitouch 來完成這部分功能。stf 是一款可以遠程調試移動手機、手錶、Pad 的 web 工具，使用效果如圖：
參考 stf 的 nodejs 源碼中 minicap / minitouch 這兩款工具的使用方式，由於 Agent 平臺使用 java / kotlin 編寫，而 minicap / minitouch 是用 c/c++ 編寫，所以採用將手動編譯完成的 minicap / minitouch 運行程序內置到 Agent 中提供調用。
minicap
github 地址： https://github.com/openstf/minicap
當設備接入時 minicap 初始化線程會分爲如下幾個步驟對設備初始化和啓動：
minitouch
github 地址： https://github.com/openstf/minitouch
當設備接入時 minitouch 初始化線程也會分爲如下幾個步驟對設備進行初始化：
Agent minitouch / minicap 和 pc 交互圖如下:
定時任務
定時任務，主要是自動化測試任務的數據交互，雲測試平臺的優勢在於可以動態的調用多個設備進行測試，而每個設備的運行又是獨立的，所以任務的運行設計最小粒度以單個設備運行爲準，那麼無論是兼容性測試、安裝測試、自動化腳本測試、性能測試等都會在服務端拆爲單個的任務，以任務池的方式存放到多維隊列中，Agent 只需要在交互時拿到對應設備的隊列任務運行即可。與設備遠程控制要求交互的即時性不一樣，遠程控制要求指令必須在毫秒級以內完成數據的下發和返回，自動化任務交互可以容忍一定的延遲，所以在與服務端交互上採用了 Http 輪詢方式：
Http 輪詢
輪詢的詳細過程如下圖示：
設備維護
Agent 部署完成之後，會主動監聽當前 adb / usb 的設備連接狀態，當有新的設備接入、已有設備移除時會執行圖中的相應步驟來維護設備的連接狀態，做到移動設備的自動化接入和移除。
同時在設備的任務執行、遠程控制、離線上線等過程中都會和服務端進行數據維護交互，同步設備的狀態到服務端，爲服務端的任務處理、排隊策略、動態任務分配等提供判斷依據
遇到的問題和處理
1. minicap / minitouch 設備兼容問題？
由於後面設備類型的未知性，只是在 Agent 內部對指定的機型設備做了特殊兼容處理，除了幾款 stf 天然不支持的設備類型，並未發現有大量的兼容問題。
2. 設備圖片傳輸實時性問題？
目前大部分任務處理都是在公司內網環境，目前只是做了圖片數據級的壓縮，可以預見在網絡環境較差的情況下，可能需要圖片像素級的壓縮處理。
圖片處理是遠端控制的重要環節，主要處理方式如下：
我們從目前比較主流移動設備拿到的單個圖片的大小應該在 1M 左右，如果是高分辨率的設備或者 iPad、AndroidPad 等設備可能會更大，做純數據壓縮最多隻能做到百 KB 大小的級別。
在上面的前提下，我們可以犧牲一部分圖片的清晰度來換取操作的流暢度和網絡性能，如圖所示我們先將原圖按照比例等比壓縮到一定大小，然後將壓縮後的圖片在頁面上渲染到和設備同樣大小，
這樣丟失的清晰度和壓縮的比例有直接關係，在數據傳輸的過程中可以根據網絡質量的好壞動態修改圖片壓縮的比例。
經過圖片壓縮和數據壓縮，圖片的傳輸量級可以縮小到十 KB 大小的級別，經過調整大部分設備圖片數據的大小傳遞都在 20 KB 上下浮動，並且同時具有較好的清晰度。
3. 設備維護線程、自動化處理線程穩定性問題？
針對線程運行、本地環境不穩定，添加了一些頁面手動控制操作，當 Agent 運行過程中發現設備假死、卡頓、超時等問題會直接通過 IM 發送報警，運維可以通過頁面操作重新初始化設備相關線程及時發現和處理問題。
本文轉載自知乎技術專欄。
原文鏈接：