背景
在雲測試平台設計中，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 發送報警，運維可以通過頁面操作重新初始化裝置相關線程及時發現和處理問題。
作者:陳康康
出處:https://zhuanlan.zhihu.com/p/83373208