隨著美團點評業(yè)務越來越多，研發(fā)團隊越來越龐大，對測試手機的需求顯著增長。這對公司來說是一筆不小的開支，但現(xiàn)有測試手機資源分配不均，利用率也非常有限，導致各個團隊開發(fā)、測試過程中都很難做到多機型覆蓋。怎么樣合理、高效利用這些測試手機資源，是擺在我們面前的一道難題。

成都創(chuàng)新互聯(lián)公司從2013年開始，我們提供高端網(wǎng)站建設、小程序開發(fā)、電商視覺設計、重慶APP開發(fā)公司及網(wǎng)絡營銷搜索優(yōu)化服務，在傳統(tǒng)互聯(lián)網(wǎng)與移動互聯(lián)網(wǎng)發(fā)展的背景下，我們堅守著用標準的設計方案與技術開發(fā)實力作基礎，以企業(yè)及品牌的互聯(lián)網(wǎng)商業(yè)目標為核心，為客戶打造具商業(yè)價值與用戶體驗的互聯(lián)網(wǎng)+產品。

現(xiàn)有的方案

為了解決這些問題，業(yè)內也出現(xiàn)了一些手機管理和在線調試使用的工具或平臺，比較常見的有:

• OpenSTF

• 百度MTC的遠程真機調試

• Testin的云真機

• 騰訊WeTest的云真機

• 阿里MQC的遠程真機租用

其中OpenSTF是開源項目，其他的平臺大多也都是基于OpenSTF原理實現(xiàn)的。因此，我們對OpenSTF項目進行了深入研究。

遇到的問題

我們首先按照OpenSTF官方的方案進行了搭建，并進行了小規(guī)模的應用，但漸漸的我們發(fā)現(xiàn)了它的一些問題：

• 模塊過多而且耦合緊密，解耦難度較大，每次修改需要更新所有模塊，難以快速迭代開發(fā)。

• 部分技術選型落后。由于OpenSTF出現(xiàn)的時間比較早，部分技術已經(jīng)落后于目前的主流。例如OpenSTF前端選用AngularJS 1.0進行開發(fā)，在生態(tài)鏈方面已經(jīng)落后于其他流行的框架；數(shù)據(jù)庫方面選用非關系型數(shù)據(jù)庫RethinkDB，在數(shù)據(jù)計算和性能方面弱于MySQL等關系型數(shù)據(jù)庫，同時RethinkDB資料較少，不便于開發(fā)與維護。

• OpenSTF屏幕圖像傳輸采用圖片單張傳輸?shù)姆绞竭M行，而且畫質不能由用戶來調節(jié)，實際應用中占用帶寬很高，在網(wǎng)絡比較差的情況下會有嚴重的卡頓現(xiàn)象，體驗很差。

我們的方案

架構設計

根據(jù)業(yè)務場景的需要，并吸取了OpenSTF結構優(yōu)點，我們采用Agent/Server模型的模塊化設計方案。下面分別介紹主要模塊的功能：

• Agent模塊。Agent模塊與OpenSTF的provider類似，部署在服務器上或者用戶的電腦上，Agent連接真實的手機，并且將手機的屏幕圖像通過Websocket動態(tài)代理到Websocket服務器上，然后通過消息中心來進行消息的傳遞。

• Server模塊。Server用來集中管理和調度手機，與OpenSTF結構不同的是，我們的Server端包含Web服務器、Websocket服務器、動態(tài)代理以及消息處理服務等部分，Server將用戶的訪問動態(tài)代理到對應的Web服務器和Websocket服務器上，并通過消息處理模塊向消息中心傳遞消息，實現(xiàn)用戶與Agent端手機的交互。

• 數(shù)據(jù)存儲模塊。數(shù)據(jù)存儲模塊用來保存整個平臺的數(shù)據(jù)，例如手機的狀態(tài)、用戶使用記錄等。數(shù)據(jù)存儲模塊由MySQL數(shù)據(jù)庫和一個RPC服務組成，Server不再直接讀寫數(shù)據(jù)庫，而是通過一個RPC服務來進行數(shù)據(jù)的讀寫操作。

• 消息中心。與OpenSTF的triproxy功能類似，是連接手機和Server的樞紐，消息中心主要處理屏幕的操作以及手機的狀態(tài)變更等消息。

通過模塊化設計，項目結構比OpenSTF更加清晰。下面是整個系統(tǒng)的設計圖：

架構的優(yōu)勢

Agent模塊我們直接復用了OpenSTF的provider大部分功能，包括minicap、minitouch等。在此基礎上，我們也擴展了一部分OpenSTF缺失的功能，比如：

• 在provider的基礎上進行了二次開發(fā)，使其支持畫質/幀率調節(jié)（ 下文會有詳細說明 ）。

• 加入健康檢測功能，檢測手機網(wǎng)絡是否正常、是否設置了網(wǎng)絡代理等。

• 加入Inspector功能，方便獲取UI控件樹（ 下文會有詳細說明 ）。

• 對Agent進行了版本區(qū)分，便于Web端根據(jù)不同的Agent版本對相應的功能展示和隱藏。

在Server模塊中，我們引入了動態(tài)代理的機制，并且重新開發(fā)了Web部分，采用了Vue 2.0 + iView來實現(xiàn)，數(shù)據(jù)庫采用了MySQL。

相比OpenSTF原生架構，總結下來有以下優(yōu)勢：

• 模塊耦合程度低，開發(fā)和部署更方便。OpenSTF各個功能模塊不僅數(shù)量多而且代碼耦合緊密，在此基礎上進行二次開發(fā)和部署非常困難。而我們將整個項目分為Server、Agent、消息中心、數(shù)據(jù)存儲四個模塊，四個模塊功能和代碼都是獨立的，基本上沒有耦合關系，支持快速迭代開發(fā)，部署也很方便。

• 前端框架更主流，開發(fā)和維護成本低。OpenSTF前端是使用AngularJS 1.0實現(xiàn)的，AngularJS 1.0已經(jīng)處于廢棄階段，各種第三方組件基本已經(jīng)停止支持，AngularJS 2.0的社區(qū)和生態(tài)并未成熟，而我們采用了Vue 2.0前端框架，Vue 2.0相對已經(jīng)成熟，在美團側也已經(jīng)有大量應用，能夠快速開發(fā)高質量的Web功能。

• 數(shù)據(jù)庫性能強，設計靈活、維護方便。OpenSTF使用RethikDB作為數(shù)據(jù)庫，RethikDB是一個NoSQL型數(shù)據(jù)庫，它有非常多的缺點，比如處理大量數(shù)據(jù)時的性能很差，資料非常匱乏，排查問題和數(shù)據(jù)庫維護都非常困難。而我們采用了MySQL數(shù)據(jù)庫，很好的解決了這些問題，并且實現(xiàn)了Server模塊與數(shù)據(jù)讀寫的分離，這樣在更新數(shù)據(jù)庫表結構的時候無須同時修改Server端的代碼，只要保證RPC服務的接口格式一致即可，開發(fā)和維護更加方便。

除了這些基礎的功能之外，我們還開發(fā)了一些特色的功能，下面我們來詳細介紹。

特色功能

與客戶端自動化相結合

為了合理、高效利用測試手機資源，我們與客戶端自動化進行了結合，主要有兩個方面：

• 與集團內部的云測平臺深度融合。在云測平臺的服務器節(jié)點上部署Agent代碼，為云測平臺自動化任務創(chuàng)建者提供自動化過程展示和遠程調試功能，同時將云測平臺空閑的手機開放給更多人使用。

• 開放API。我們開放了一些API給普通用戶，供用戶查詢手機狀態(tài)、占用手機、連接adb調試等，用戶可以使用腳本調用API，然后直接在平臺的手機上進行自動化測試。

預約功能

當一臺手機處于繁忙狀態(tài)時，用戶必須要等待手機空閑后才能使用，由于手機空閑時間不確定，就會給用戶帶來很大的不便。為了解決這個問題，我們開發(fā)了手機預約的功能，用戶可以預約處于繁忙狀態(tài)的手機，當手機空閑時，自動幫預約用戶占用15分鐘，并通過即時通訊工具通知預約人。

畫質調節(jié)

遠程調試平臺的核心是實時獲取屏幕圖像，由于屏幕傳輸需要比較大的網(wǎng)絡帶寬，在網(wǎng)絡不佳的情況下就會出現(xiàn)卡頓現(xiàn)象。因此，我們針對不同的網(wǎng)絡做了一些流暢度的優(yōu)化，下面來介紹一下其中的細節(jié)。

屏幕獲取的原理是通過minicap來高速截圖，每秒最高可達60張，然后將這些截圖顯示在Web上。因此，我們考慮從兩個方面來優(yōu)化網(wǎng)絡帶寬的占用， 第一個是調節(jié)截圖的質量 ，minicap本身支持調節(jié)畫質（ OpenSTF固定設置了80%的壓縮比 ），關鍵代碼如下：

var

 rate =  

Number

(match[

6

])


    

if

 (rate > 

2

 && rate < 

100

) {


      log.info(rate)


      

if

 (rate > 

30

) {


        options.screenJpegQuality = 

80



      }

else

 

if

 (rate > 

15

) {


        options.screenJpegQuality = 

50



      }

else

 {


        options.screenJpegQuality = 

20



      }




      frameProducer.restart()


      framerate = rate


    }

第二個是調節(jié)每秒發(fā)送的圖片張數(shù) ，也就是幀率，我們可以在Agent端控制發(fā)送圖片的數(shù)量，關鍵代碼如下：

# 首先修改幀率發(fā)送部分：





function

 

wsFrameNotifier


(frame)

 

{  


  

if

 (latesenttime == 


 || Date.now()-latesenttime > 

1000

/framerate) {  


    latesenttime = Date.now()  


    

return

 send(frame, {  


      binary: 

true

  


    })  


  }  


}



# 再加入調整幀率的代碼：




case

 

'rate'

:  


  

var

 rate =  Number(match[

6

])  


  

if

 (rate > 

2

 && rate < 

100

) {  


    framerate = rate  


  }  


  

break

那么，幀率和圖片壓縮比調節(jié)到多少才能滿足不同網(wǎng)絡環(huán)境的需要呢？我們先來看一組數(shù)據(jù)：

圖片壓縮比	圖片尺寸
100%	69.82KB
80%	46.78KB
50%	41.87KB
20%	37.84KB
10%	35.84KB

表中是使用minicap做的圖片壓縮實驗，從數(shù)據(jù)中我們可以看到當圖片質量降低到80%時圖片大小降低比較明顯，而圖片質量并沒有明顯的下降。繼續(xù)降低圖片質量，圖片大小降低有限。我們再來看另外一組數(shù)據(jù)：

幀率	圖片壓縮比	實際流量
60	100%	4.02M/S
60	80%	2.74M/S
60	50%	2.41M/S
30	80%	1.43M/S
30	50%	1.22M/S
30	20%	1.10M/S
15	50%	0.63M/S
15	20%	0.55M/S
15	10%	0.52M/S

表中是各種幀率和壓縮比組合產生的實際流量數(shù)據(jù)。

從數(shù)據(jù)中我們可以看到最高幀率和壓縮比的組合下，流量達到了4M/S，而80%壓縮比時流量減小到了2.7M/S，降低非常明顯?？紤]到實際網(wǎng)絡情況，我們將 60幀、80%壓縮作為了高畫質選項 。

而圖片質量從80%降低到50%時圖片大小下降并不明顯，此時降低幀率就成了很好的選擇。當幀率降低到30幀時流量降低了一半，1.2M/S的流量能夠滿足大部分網(wǎng)絡狀況使用，30幀也能保證操作的流暢度，于是 30幀、50%壓縮比成為了中畫質的選項 。

低畫質主要是為了保證在較差的網(wǎng)絡環(huán)境能夠正常使用，500K/S的流量是紅線。我們將 15幀、20%壓縮比作為低畫質選項 ，此時圖片質量和幀率較低，但能夠保證基本的使用體驗。

除了通過降低圖片質量和幀率來減小手機屏幕圖像傳輸?shù)牧髁客?，將圖像使用H264等編碼壓縮成視頻傳輸也是一種有效降低流量的辦法，相對于圖片，圖像的壓縮率將會更高，用戶的操作體驗也會更好。但是圖像壓縮編碼原理比較復雜，相關技術我們還在研究當中。

App Mock

在做App測試過程中經(jīng)常需要抓包，一般情況下，我們通過修改WiFi的代理然后用抓包工具就可以實現(xiàn)。但是這樣做的效率比較低，多個工具切換也非常不便。借助集團的Mock平臺，我們開發(fā)了一鍵Mock功能，能夠快速完成相應App的Mock操作。帶來的好處是我們可以一邊操作App，一邊查看App發(fā)出的請求，大大提高了測試的效率。

App Inspector

App Inspector功能可以讓用戶在平臺上使用真機的同時查看頁面控件樹及頁面元素，并且支持Xpath，更加方便高效的查找頁面元素，給UI自動化測試提供了很大便利。

這個功能我們是借助Uiautomator實現(xiàn)的?；驹硎菍懸粋€Uiautomator用例，用來獲取當前頁面的Hierarchy，然后將用例打包成一個JAR放到Agent端。當在Web端觸發(fā)獲取控件樹時，Agent將JAR包推送到手機上并運行，此時會在手機端生成一個XML文件。然后再使用cat命令獲取XML內容并在前端解析。用例核心代碼如下：

public

 


class

 

launch

 

extends

 

UiAutomatorTestCase

 

{




    


public

 

void

 

testDumpHierarchy


()

 

throws

 UiObjectNotFoundException 

{


        File file = 

new

 File(

"/data/local/tmp/local/tmp/uidump.xml"

);


        UiDevice uiDevice = getUiDevice();


        String filename = 

"uidump.xml"

;


        uiDevice.dumpWindowHierarchy(filename);


    } }

當然，你也可以用adb命令來獲取Hierarchy：

adb shell uiautomator 

dump

 /data/

local

/tmp/uidump.xml

但這種方式不能獲取動態(tài)頁面，比如視頻播放頁面。

數(shù)據(jù)報表

為了更好的了解平臺的運營情況，我們做了詳細的數(shù)據(jù)統(tǒng)計，主要從使用次數(shù)、使用時間、設備數(shù)量、使用分布等方面進行統(tǒng)計。目前我們管理的手機近300臺，平均每個月有超過500名研發(fā)人員在使用我們的平臺，每天的使用次數(shù)達到280次，每天總使用時長超過60小時。

其他小功能

除了以上幾個比較大的功能點，我們也做了一些貼心的小功能，比如：檢測手機網(wǎng)絡是否設置代理、檢測手機已安裝的應用版本及安裝時間、快速安裝最新版本的測試包、支持App內的Schema跳轉等等。這些小功能為研發(fā)人員節(jié)省了很多時間，提升了他們的工作效率。

未來規(guī)劃

iOS手機支持

目前，云真機平臺只支持Android手機，對iOS手機的支持正在進行中。我們已經(jīng)初步完成了主要功能的開發(fā)，預計很快上線。

產品優(yōu)化

我們計劃繼續(xù)擴展產品功能，比如支持Log日志展示和性能數(shù)據(jù)采集等。目前云真機平臺已經(jīng)在美團點評內部平穩(wěn)運行超過兩年，我們會繼續(xù)不斷迭代版本、打磨產品，提供更好的使用體驗。

作者簡介

東初，大眾點評平臺質量工具組負責人。7年互聯(lián)網(wǎng)行業(yè)測試、開發(fā)經(jīng)驗，2015年加入原大眾點評。先后主導了云真機平臺、單元測試平臺、web安全實驗平臺等項目的開發(fā)，致力于用工具來提升研發(fā)團隊的工作效率。

李帥，大眾點評高級測試開發(fā)工程師。2015年加入原大眾點評，主要負責云真機平臺的開發(fā)以及客戶端底層組件的測試。熱衷于鉆研測試領域的前沿技術，并推動了多項新技術落地。

【本文轉載自美團技術團隊微信公眾號，轉載授權可聯(lián)系原作者】

文章題目：業(yè)務實踐分享：美團點評團隊云真機平臺實踐-創(chuàng)新互聯(lián)
分享URL：http://chinadenli.net/article36/dgphsg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、定制開發(fā)、手機網(wǎng)站建設、用戶體驗、網(wǎng)站設計公司、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)