背景

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

現(xiàn)有的方案

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

• OpenSTF
• 百度MTC的遠程真機調(diào)試
• Testin的云真機
• 騰訊WeTest的云真機
• 阿里MQC的遠程真機租用

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

遇到的問題

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

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

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

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

我們的方案

架構(gòu)設(shè)計

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

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

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

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

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

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

架構(gòu)的優(yōu)勢

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

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

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

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

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

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

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

• 模塊耦合程度低，開發(fā)和部署更方便。OpenSTF各個功能模塊不僅數(shù)量多而且代碼耦合緊密，在此基礎(chǔ)上進行二次開發(fā)和部署非常困難。而我們將整個項目分為Server、Agent、消息中心、數(shù)據(jù)存儲四個模塊，四個模塊功能和代碼都是獨立的，基本上沒有耦合關(guān)系，支持快速迭代開發(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)成熟，在美團側(cè)也已經(jīng)有大量應(yīng)用，能夠快速開發(fā)高質(zhì)量的Web功能。

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

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

特色功能

與客戶端自動化相結(jié)合

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

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

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

預(yù)約功能

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

畫質(zhì)調(diào)節(jié)

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

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

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}

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

# 首先修改幀率發(fā)送部分： function wsFrameNotifier(frame) { if (latesenttime == 0 || Date.now()-latesenttime > 1000/framerate) { latesenttime = Date.now() return send(frame, { binary: true }) } } # 再加入調(diào)整幀率的代碼： case 'rate': var rate = Number(match[6]) if (rate > 2 && rate < 100) { framerate = rate } break

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

圖片壓縮比圖片尺寸

100%	69.82KB
80%	46.78KB
50%	41.87KB
20%	37.84KB
10%	35.84KB

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

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

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

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

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

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

App Mock

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

App Inspector

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

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

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);} }

當(dāng)然，你也可以用adb命令來獲取Hierarchy：

adb shell uiautomator dump /data/local/tmp/uidump.xml

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

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

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

其他小功能

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

未來規(guī)劃

iOS手機支持

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

產(chǎn)品優(yōu)化

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

作者簡介

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

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

招聘信息

點評平臺－平臺質(zhì)量中心，Base上海，主要負責(zé)大眾點評平臺入口和基礎(chǔ)功能的質(zhì)量保障。平臺包括大眾點評App、大眾點評微信小程序、PC站：www.dianping.com、 M站：m.dianping.com；主要業(yè)務(wù)涵蓋：賬號、POI、評價、視頻、文章、會員社區(qū)、問答、運營活動、搜索推薦、通信鏈路、運營活動等基礎(chǔ)業(yè)務(wù)。熱忱期待各位QA、開發(fā)、算法人才加入點評平臺技術(shù)部。聯(lián)系郵箱：wenjie.pan#dianping.com。

更多專業(yè)前端知識，請上 【猿2048】www.mk2048.com

總結(jié)

以上是生活随笔為你收集整理的美团点评云真机平台实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。