背景
為了充分利用雲測試平台維護的裝置，提升空閑裝置使用率，開展自動化測試替代部分回歸測試、重複性測試和多裝置相容測試，同時滿足如下幾種類型的自動化測試需求：
随機測試（monkey、随機操作指令）：
在多裝置執行的基礎上完成安裝、啟動、覆寫安裝、monkey 測試 / 随機指令、解除安裝等一系列操作。
周遊測試（深度周遊、智能探索）：
在 monkey 測試 / 随機指令的基礎上，對執行步驟進行改造，将随機操作替換為 app 内部頁面的深度周遊，設計算法政策在一定程度上對被測 app 進行智能探索操作。
UI 自動化測試（appium）：
在自動化測試架構支援的基礎上，提供多裝置腳本運作能力，測試開發人員隻需要編寫符合規則的測試腳本即可以在雲測試平台上選擇多個裝置進行測試，獲得測試結果。
在以上自動化測試的同時，測試報告中需要展現如下内容：
- 實時生成測試報告、測試結果資料
- 實時擷取裝置的日志并有對應的分析結果
- 可控的自動化測試過程
- 執行過程中裝置頁面截圖或錄制視訊
- 測試結果中裝置類型資料分析
在上面背景說明中，介紹了幾種測試類型需求，前兩種的設計流程比較簡單，也不需要外部人員的參與，第三種測試類型設計比較複雜，後續文章說明也以第三種測試類型為主。
自動化執行架構設計
自動化架構
在
陳康康：知乎移動端雲測試平台實踐(二)—— Agent 設計和實作32 贊同 · 5 評論文章
中自動化架構調研對比和各大雲測試平台的使用，選擇了在各方面都具有一定優勢的自動化測試架構 appium 作為自動化測試的執行控制層，本地啟動 appium hub 的方式接收腳本執行請求，這裡就不多加贅述了。
腳本語言和執行架構
雲測試平台是由 Java + kotlin 開發，用戶端控制都是基于 Java 實作，這裡自然選擇 Java 作為腳本語言，後續的腳本、流程說明也是以 Java 語言實作為主，但是在腳本語言選擇上這裡不是強制要求，同樣可以選擇Ruby、Python、PHP,、JavaScript 和 C#，隻是後續的實作需要平台多做一步相容而已。
在腳本執行方面沒有使用類似 junit、testng等第三方的運作架構，主要是為了保持在運作過程中對腳本運作的控制和運作資料的互動，如下是腳本運作實作方案：
1.由平台提供一定限制範圍的腳本編寫能力
主要是指運作過程的腳本編寫，以及如何提供類似截圖、步驟日志、檢查點等公用方法，對于 Java 來說可以将一些公共的方法抽象出來放到腳本的父對象中，通過繼承将腳本編寫能力賦予給腳本本身，Python 也可以統一一個标準的類庫，通過引入的方式使用。
2.運作時由 agent 動态編譯編寫完成的腳本，反射執行個體化腳本對象
運作時處理腳本需要區分動态語言和非動态語言，還是以 Java、Python 為例，由于沒有借用第三方的測試架構，觸發腳本運作對于 Java 來說需要進行編譯，也就是标題中說到的動态編譯，然後通過反射執行個體化對象運作，這裡有兩個要求，首先腳本編寫需要在雲測試平台限定的包内，其次腳本運作、繼承的方法需要符合約定的規則。對于 Python 來說先将腳本内容以 IO 的方式寫到記憶體中，然後反射通過字元串的形式，導入子產品、去子產品尋找約定函數執行。
3.使用反射執行個體對象運作腳本，并調用執行個體中的方法和腳本進行資料、強控制互動
執行個體化腳本後開始運作腳本，運作前需要将所需要的運作資料注入到執行個體中，例如： appium 的 appiumDriver，運作同時可以随時調用執行個體化對象中的約定方法對腳本運作進行控制，比如擷取執行步驟、日志、圖檔，傳遞參數，控制腳本暫停、運作、停止等互動，這也是為什麼沒有使用一些第三方架構來觸發測試的原因。
通過上述過程基本上實作了用例到執行的基本過程，如圖：
也就是說隻要提供了符合規範的腳本，就可以利用架構的通用性将腳本運作在任何 appium 支援的裝置上，在架構上也剝離了自動化測試最關鍵的工作部分即：腳本編寫，也為腳本管理、資料模闆結合等用例的功能豐富提供更多可能性。
流程設計
如下是腳本自動化測試完整的業務執行方案：
自動化測試 UI 代碼以 git 工程的方式托管在公司的 git 伺服器上，在工程基礎上編寫腳本，調試腳本通過之後合并入 git 工程，在 gitlab 上每一個腳本都會有一個唯一的位址，通過這個位址可以擷取到指定腳本，然後通過接口 / 表單的方式送出腳本運作測試，運作完成得到品質報告。
值得說明一下的是，在自動化測試過程中，公共方法、selenium / appium 公共 page object 等腳本資料會随着自動化測試的深入越發龐大，是以需要圖中的公共方法抽取過程，這樣帶來的好處是由于腳本的抽取、複用會使腳本的編寫效率會越來越快。
如下是腳本執行流程結構圖，包含腳本執行的流程和結果收集：
腳本執行資料、執行互動設計方案：
這裡主要展現的是腳本和運作平台間的資料互動、執行能力互動，比如腳本執行時需要使用到 appium 的 driver，而這個 driver 是通過平台的裝置參數來決定的，在運作時平台動态生成 driver 然後通過協定類的方式注入 driver 到腳本内部，運作過程中通過協定類的停止、暫停、等待、銷毀等方法進行控制，運作完成後通過協定類擷取到運作結果。在腳本需要一些特定的功能時，也可以通過協定類引入接口方法，然後運作平台通過接口代理的方式動态注入實作類的方式實作。
在實施的過程中發現有兩個難點，主要如下：
-
類和第三方包引用管理引起的腳本編譯問題
在自動化測試腳本編寫過程中，不可避免需要使用一些引入包，比如一些友善的工具類使用包等，對于 JAVA 腳本來講更新類、包引入等都需要重新編譯部署才可以運作使用，測試平台不可能會因為腳本類、包的變化重新編譯部署平台，而腳本的編寫絕大部分都是類引入的變化，包引入變化的比例很小，是以在類的變化上使用 Java 動态編譯技術解決類的動态引入，第三方的包引入更新則通過平台工程的發版提前引入這些包更新完成。
-
協定類和包更新的自動化更新過程
在雲平台和腳本工程中間是通過協定類進行資料互動，而定義的這個協定類和包發生之後按照上面的方案來說是需要雲平台重新部署才可以的，在實踐中發現腳本的能力建設和擴充等都需要通過協定類的修改才能實作，這就決定了這個協定類會頻繁的發生變更，是以 Agent 工程中在動态編譯前，手動校驗了伺服器上的協定類版本，如果發現了新版則下載下傳新版的協定類 jar，在動态編譯時替換到 -classpath 的協定類版本參數，這樣就做到了指定協定類内容的動态更新和自動化部署。
腳本設計
在上面提到過 「對于 Java 來說可以将一些公共的方法抽象出來放到腳本的父對象中，通過繼承将腳本編寫能力賦予給腳本本身」，是以腳本設計分兩個子產品：
協定父對象實作
如圖所示父對象中提供了測試驅動 androidDriver、log 日志、checkPoint 檢查點、img 截圖等腳本能力
用例子對象編寫
如圖所示，實際的腳本繼承父對象的能力之後，可以完成編寫相關頁面測試邏輯、業務邏輯的自動化測試任務
腳本調試和運作
平台腳本調試可以通過如下兩種方式進行：
本地調試
自行使用 main 方法、或者使用單元測試架構調試腳本通過
然後将主體修改為規定格式的自動化腳本，視情況修改 appiumDriver 引入方式、添加日志記錄、截圖、檢查點等
遠端調試
遠端調試需要在雲測試平台上申請一台使用裝置如圖：
點選圖中的按鈕，将腳本粘入運作，如下圖：
測試報告展示
報告主要分為如下幾個部分
測試基本資訊
主要展示測試過程的 app 基礎資訊和測試相關的一些資訊展示，概況展示腳本所有檢查點的通過比例，腳本運作的裝置、通過、失敗的資料統計，運作概況展示每一個腳本在每一個裝置上運作的過程和結果，以腳本和裝置為次元，log 連結中會展示詳細的腳本運作步驟日志
檢查點概況
腳本運作的核心結果，主要展示此次自動化測試過程中所有的測試結果
截圖/步驟/異常
在腳本運作結束後，通過反射的方式擷取到腳本用例的詳細資料，通過 「截圖/步驟/異常」細化展示每一次運作的步驟、圖檔、和檢查結果
性能圖表、過程視訊
同時在腳本運作過程中也會通過 appium 架構功能實作裝置的網絡上下行統計、
Get Performance Data - Appiumappium.io/docs/en/commands/device/performance-data/get-performance-data/
和
Start Screen Recording - Appiumappium.io/docs/en/commands/device/recording-screen/start-recording-screen/
，然後渲染性能資料生成圖表并提供視訊回放腳本執行過程
作者:陳康康
出處:https://zhuanlan.zhihu.com/p/84323222