百度Hydra工具在移動端UI兼容性測試上的高效應用

導讀：儘管自動化測試技術突飛猛進，可是自動化case構建成本、執行穩定性等問題的存在，使手工測試依然移動端質量保證的重要手段。傳統手工測試必須經過人工操做的方式執行測試用例，效率提高依賴測試人員的操做熟練度。本文從介紹百度內UI兼容性測試現狀切入，引出「一機多控」並以此概念爲基礎打造的工具Hydra。而後從技術實現的角度，介紹了Hydra總體的設計思想以及部分核心模塊的設計。

1、背景

1.1 移動端UI兼容性測試

移動端的UI兼容性測試，顧名思義就是對移動端應用在不一樣機型、不一樣分辨率、尺寸的移動設備上UI界面展現的一致性進行測試。

做爲移動端應用質量保證的重要組成部分，長久以來依然經過純手工的方式進行操做測試。傳統的移動端手工兼容性測試，在百度的應用開發流程中主要在如下兩個階段：

a. 功能測試階段
一般12人，在少許業務線手機（約13臺），總計測試時間在10~20小時。

b. 上線前全功能(迴歸)測試階段
14人，在業務線手機（512臺），總計測試時間在20~50小時。

1.2 面臨的問題

在當前採用的移動端手工兼容性測試，存在如下兩個問題：

a. 效能提高困難
舉例個簡單的例子，一次迴歸測試中UI兼容性在10臺設備上驗證100個case，每一個case耗時1分鐘，那麼總共就須要驗證10x100=1000個case耗時約17個小時。這些case都須要測試人員手工在每臺設備上進行操做。那麼須要下降測試階段的耗時，只能經過增長測試人力的方式。

b. 兼容性測試不夠充分
對於UI兼容性測試來講，覆蓋的品牌、型號、系統版本、UI版本等因素都會影響測試的召回率；但在現狀中，移動設備是每一個業務獨有且有限的，業務線之間設備難以流通。

2、一機多控與Hydra

2.1 Hydra如何解決傳統移動端手工兼容性的問題

移動端的UI兼容性測試依然採用手工測試方式來執行，存在目前尚沒法解決的客觀緣由，好比：移動端應用UI界面迭代快、自動化測試用例生成成本高；UI兼容性穩定沒法進行標準化定義，召回困難，等等。

對於效率問題，Hydra試圖從另外一個思路——也就是經過「一機多控」的方式，提高手工執行測試的效率。一機多控顧名思義就是測試人員控制一臺「主控」設備，他的操控動做可以同時控制多臺「從控」設備，並進行人工的UI校驗，達到在單位時間內進行更多測試的目的。而設備不足的問題，則是經過將「一機多控」與雲設備平臺對接，擺脫物理設備的限制來解決，例如雲設備來提高兼容性測試覆蓋度。

2.2 用戶的需求

對於這樣一款提效手工測試的一機多控工具，一線測試人員又是什麼指望呢？總結來講是如下四個方面：

a. 準：在「主控」設備操控的位置、效果，可以準確無誤地複製到「從控」設備上。這是一機多控工具的基本功能。
b. 多：包括設備數量多、設備種類多、支持的應用種類多。
c. 易用：操控的體驗、交互應當是方便、快捷、符合使用習慣的。
d. 快：操控的速度快。

2.3 Hydra的方案

綜合考慮用戶需求以後，肯定了Hydra的基本形態與技術方案：

首先咱們考慮到「多」的因素，因爲如今主流移動端有Android和IOS兩大系統，設備的驅動方式、工具集差異很是大；其次非原生應用形式如小程序、H5愈來愈多地涌現出來，原生應用的驅動方式並不適合這些新形態的應用。所以咱們決定採用圖像算法來做爲動做「複製」的核心算法。

採用圖像算法，就會引伸出更快地獲取圖像、更快地對圖像計算的問題，所以採用經過PC機有線鏈接的方式，從而更好地知足用戶對準、快的需求。

Hydra的基本形態是一個PC程序，用戶能夠經過有線方式鏈接本地設備，或者經過網絡鏈接雲設備。全部被測應用在設備上的畫面在瀏覽器上直接展現，使測試人員可以更加直觀地對UI界面進行校驗，從而召回UI兼容性問題。這種展現方式也解決了設備增多以後帶來的校驗效率問題。

出於對測試人員使用習慣的考慮，Hydra也支持經過移動設備做爲「主控」來操做。

3、Hydra的技術架構

Hydra總體採用BS架構，經過http/websocket協議與前端展現進行通訊。具體的展示形式與能力實現進行解耦，能夠很是方便地擴展出新的展示類型，好比手機客戶端。

在功能組件中，比較核心的是羣控引擎與圖像合成器，分別負責「一機多控」功能的輸入與輸出部分。

經過瀏覽器/客戶端捕獲用戶在「主控」設備上的實時輸入，經由羣控引擎進行復制以後，同時操做每一臺「從控設備」。操做的反饋經由「實時圖像流」，展現在用戶的瀏覽器/客戶端上。以此達到「所見即所得」的實時操控體驗。

下文將對功能組件中，幾個核心模塊的設計與實現進行介紹。

3.1 羣控引擎

羣控引擎的設計目標是完成一次動做，屢次執行。

其中的難點在於：

a. 不一樣分辨率下，實現座標相關的用戶輸入的準確映射。
b. 不一樣設備性能下，單次動做在不一樣設備上的執行前後問題。
c. 屢次動做組合的時序問題。（如點擊變長按）

針對a.所指的座標映射處理，是經過「多場景高性能圖像算法」來解決，將在後續小節詳細介紹。

對b. 羣控引擎在並行處理「從機」執行動做的時候，會等待全部的座標映射處理完成，統一出發執行，對於用戶來講達到的效果，就是一個動做會「同時」反應。

對c. 羣控引擎爲「主控」和每個「從機」創建動做執行隊列，並記錄「主控」每一次動做的時間戳。在「從機」執行動做的時候，依照「主控」的動做的相對間隔進行執行，確保執行的時序與用戶輸入儘量的一致。

3.2 實時圖像流

實時圖像流是一條設備圖像與展示的傳輸通路，其設計目標是可以實現多機「實時」圖像展現，讓用戶可以更快地查看操做反饋。

其中的難點：
a. 不一樣設備性能下，輸出圖像幀率是不一樣的
b. 網絡設備的圖像輸出幀率不穩定
c. 不受控的幀率致使數據傳輸多，性能消耗大，影響實時性。
d. 前端展現回調爆炸

要解決以上穩定，咱們首先須要明確，對於實時圖像流來講，實時性比起流暢度（幀率）是更重要的。由於用戶的輸入動做是一個離散的行爲，一般須要須要識別的UI兼容性問題也是靜態的。所以咱們首先限制了設備的輸入幀率爲16幀並下降/權衡每幀圖像的尺寸，知足「流暢」的基本需求，同時也儘量下降了數據量形成的性能問題。

限制了單臺幀率以後，多臺設備疊加形成的前端回調爆炸問題，經過自定義的數據協議。將多機圖像合成，從而下降展示層接收到的圖像幀率。在實現的時候，採用固定合成幀率，定時採集全部設備的輸入圖像，爲前端展現屏蔽不一樣設備的圖像幀率差別。

如上圖，咱們有n臺設備，設備#1以固定幀率穩定輸出圖像，設備#2以較低幀率穩定輸出圖像，設備#n則是不穩定輸出圖形。Hydra創建了單獨的「圖像合成」線程，以預期的固定幀率（16fps），從全部設備採集最新的的圖像，做爲給用戶展現的圖像，並進行合成。

上圖展現了自定義的合成數據協議的設計。每一幀中包含全部圖像的數據，在幀頭中對幀的基本信息進行描述，其中就包括包含多少設備圖像。接着在每隔一個設備的單獨圖像數據中，包含數據頭。數據頭描述了設備與圖像的相關信息。同時對整個數據幀的數據部分進行再次壓縮，以減小數據傳輸量。

3.3 多場景高性能圖像算法

在實現了羣控引擎和實時圖像流以後，就實現了羣控的基本雛形。可是要讓羣控的體驗更好，就結合本節介紹的圖像算法。

座標映射的處於架構的核心位置，須要知足性能、準確率、通用性。咱們選取的算法須要綜合考慮上述要求，並進行權衡。因爲咱們總體屬於實時系統，對於性能的要求會更高。

最基本的咱們能夠選取座標值的數學轉換，根據屏幕尺寸按比率進行換算。很顯然這種算法最簡單，性能最高，可是準確率是沒辦法知足的。由於只有當全部設備的圖像是徹底一致的時候，這種算法纔可以準確換算。圖像模板匹配是一種高性能、高準確率的圖像算法，可是對於圖像形變以後就沒法識別，通用性沒法知足。

咱們選取了sift算法做爲基本的圖像算法，經過計算後的特徵點進行換算映射。直接應用sift算法，在準確率、通用性都有比較好的表現，可是性能上有很是大的瓶頸，平均一組圖像的處理耗時在2s，沒法達到實時要求。所以咱們須要對sift算法的應用進行優化：

首先咱們對主控和從控設備的圖像作了一次區域截取，下降算法的計算量；接着並無直接使用計算後的特徵點來映射，由於特徵點的分佈與圖像有關，而座標的輸入能夠是任意的。所以咱們經過選取已有的2個特徵點（圖中紅、綠點）a、b，計算在主控中目標點c與a、b之間關係（偏移角度與距離）。並將這種關係應用從控圖像上進行計算，從而計算出目標座標。

上述算法在大部分場景下能夠表現良好，可是在部分場景（如列表）下準確率存在問題。所以須要進一步進行優化。

在一次羣控映射發起的時候，首先選用cnn算法對頁面進行識別，肯定當前是否處於列表頁面，接着再採用dnn對象識別來檢測圖像中是否已經存在預訓練的圖標。上述過程只在一次羣控映射執行一次，基於以上的結果，在對每個設備進行映射的時候，能夠採起不一樣的策略：若是已經存在預設的圖標，那麼直接採用dnn識別出對象便可。接着根據是否處於列表頁，決定sift算法的參數（更大的選取框、更高的特徵閾值）。

基於以上算法，Hydra實現了平均160ms內的座標映射和97.52%的準確率。

3.4 一致性修復

在實際使用過程當中，設備圖像出現不一致是比較常見的現象。緣由多是「從機」沒有如預期那樣按照「主控」的動做點擊或者出現瞭如系統彈窗之類的預期外界面。羣控中出現不一致是預期中的，爲了提升效率，設計了高效的修復手段。

首先，在Hydra的操控設計時候，支持在羣控過程當中對每一臺設備的單獨查看與控制，當出現個別設備出現不一致的狀況，能夠當即對其進行修復，並回到正常的測試操做流程中。

其次對於比較容易出現不一致的場景，如列表頁，提供了半自動化的滑動一致性修復。

如上圖，當「主控」與「從控」在列表頁滑動的位置不一致的時候，會分別對兩個圖像進行sift計算，獲得對應的特徵點。經過特徵點連線之間的斜率，來判斷當前「從控」圖像是否存在滑動不一致的狀況。

並非全部的特徵點都可以採用。咱們試想一個列表頁面，導航欄和標籤頁是不能滑動的，只有中間的內容才能夠滑動出現不一致。所以咱們將圖像從上到下分紅四個區域，並對每一個區域中的特徵點使用不一樣的權重，最上部分和最下部分不會變更的區域，權重值最低。中間可滑動部分也分紅上下兩個部分，下半部分因爲屏幕尺寸關係，展現的內容高度會存在少量不一致，容易形成誤導，所以賦予中等權重。上半區域是咱們主要用來判斷的區域，賦予最高的權重。

當獲得不一樣權重的特徵點連線以後，咱們對其進行加權平均，便可根據結果判斷是否存在滑動不一致的狀況，並根據斜率計算差別，而後自動操控設備進行反向滑動補償，即完成了滑動一致性修復。

3.5 移動端手持控制

測試人員傳統的測試方式是直接手持設備進行操控，鼠鍵操控的習慣沒法適應。所以Hydra也提供了經過移動手持控制的操做方式。Hydra提供了兩種手持控制的方案：

1. 遙控方案

這種方案下，與瀏覽器方案同樣，先選擇一臺設備做爲主控。接着利用現有的前端技術。從「主控」設備採集到的圖像，會發送到在遙控設備的瀏覽器上並展現，同時採集用戶輸入發送到真正的「主控」上。就好像在遙控「主控「設備同樣。

這種方案的優點是實現簡單，利用現有的前端技術，而且兼容性好，在Android和IOS上都通用。

可是，缺點也很明顯：（1）遙控設備自身並不能用來測試，會浪費一臺設備。（2）假如遙控設備和主控設備的分辨率尺寸不一致，那麼在遙控設備上展現的顯示效果會存在縮放，顯示效果不佳。

1. Android客戶端方案

這種方案是利用Android平臺的開放性，Hydra提供了Android客戶端，當使用這臺設備做爲主控的時候，能夠直接進行操控。Hydra的客戶端會採集用戶的輸入，直接羣控全部的「從控」設備。

那麼如何捕獲用戶輸入呢？

客戶端會預先在手機上創建雙層的懸浮窗。當用戶在手機上進行操控的時候，（好比這裏用戶點擊了（400，1000）這個座標， 那麼會被layer#1攔截到觸摸動做的座標。假如用戶點擊的是如back的虛擬按鍵，那麼會由layer#2進行攔截。當獲取到動做座標以及按鍵信息的時候，客戶端將這些信息發送至羣控引擎，「複製」觸發全部「從控」機進行執行。同時，因爲用戶動做已經被攔截，這些動做沒法直接生效。所以Hydra客戶端上，還包含了微型的執行引擎，能夠對用戶動做進行解釋，而且在當前設備上進行操做。

基於上述兩個方案，就實現了讓用戶使用移動設備來一機多控的能力。

4、Hydra的落地效果

Hydra目前已在百度內多條業務線進行落地，並在app迴歸、廣告測試、運營活動等多種業務場景取得了正向的收益，每週平均提效在20%~70%。

固然Hydra也存在必定的侷限性，在部分場景並不適用或者效果並不明顯：

1.是不適合羣控的場景，好比不一樣帳號的登陸，須要配合外部定製化的輸入方案來實現。
2.是有動態背景如視頻的icon點擊，在識別上存在比較大的瓶頸。
3.是操做鏈路比較長，操做類型比較複雜的用例，在必定時間的羣控以後，出現不一致的機率會增高。
4.還不支持一些複雜的手勢操做如縮放、旋轉等。以上問題咱們在持續的進行優化改進。

5、更進一步提效手工測試——工具箱

一般咱們完成移動端手工測試，須要測試人員去尋找完成測試須要的工具，學習並使用。這種測試過程有必定學習成本而且效果也很難保證。Hydra做爲移動端手工兼容性的提效工具，這種使用模式也體現了咱們對於移動端手工測試領域的思考——在測試人員與設備之間須要一個鏈接的「橋樑」，它是一個工具箱，能夠開箱即用完成具體的測試目標。

更進一步地，它能夠是對手工測試流程進行標準化的測試過程，這種標準化體如今對測試任務階段性的定義、工具的使用、測試數據的收集與結果的校驗。根據測試場景的不一樣，對於每一個階段使用的工具集能夠選擇推薦。還能夠與外部的case管理、bug跟蹤系統打通，造成閉環。經過這種方式，對於手工測試，不只僅能夠對局部的測試任務，更能夠從總體完成效率上獲得進一步提高。

原文連接：https://mp.weixin.qq.com/s/OHmWsHS-_ANrNXj8c5bDNg

---

百度架構師
百度官方技術公衆號上線啦！
技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘信息 · 內推信息 · 技術書籍 · 百度周邊
歡迎各位同窗關注！