CODING DevOps 線下沙龍回顧二：SDK 測試最佳實踐

講師：潘志剛
聲網質量效能部門負責人，超過 14 年服務器、移動終端、音視頻編解碼以及汽車電子等跨行業從業經歷，負責創建測試基礎架構和自動化測試方案，主持搭建持續集成測試生態體系。現任聲網質量效能部門負責人，負責推動質量和效能持續優化，專一技術創新賦能團隊軟件保證，經過軟件和硬件的高效結合，探索產品交付的最優解決方案。

前言

SDK 測試不一樣於 APP 測試，不只要站在終端用戶角度考慮問題，還須要站在 APP 開發者的角度考慮問題。面對不一樣的行業需求，如何保證質量固若金湯，這是一條探索未知的賽道。本期推送將爲你們帶來聲網研發效能負責人潘志剛的《SDK 測試最佳實踐——打造質量保證的一體化應用平臺》，分享一體化應用平臺的演變以及如何整合基礎能力，保證測試和交付的高效執行，提高質量效能。

1.0 GUI Driven Test

SDK（軟件開發工具包）是聲網對外主要的產品交付，是用於爲特定軟件包、軟件框架、硬件平臺以及操做系統等建立應用軟件的開發應用的集合，跟傳統意義上的 APP、外圍應用或者最終客戶感知到的產物是不同的，對於最終端用戶來講是無形的。

早期爲了保障 SDK 測試的質量，測試人員須要根據 SDK 交付的 API 設置 GUI demo。好比在一個實時的互聯網通信界面，須要用戶加入到對應頻道進行相應的音頻和視頻通信，在這樣的界面裏會設計對應 Button、下拉列表，或者小的圖標，每個對應的元素體現對應接口實現能力。以下圖所示，最下面 4 個 Button 分別是麥克風、攝像頭、掛機按紐，對應 API 接口 enableLocalAudio、enableLocalVide、startScreenCapture 和 leaveChannel，右上角看到信號條圖標是獲取 onNetworkQuality 接口。經過這樣簡單的 Demo，測試人員設計相應的 test case，確保每個接口能夠正常調用，基於此來保證初期迭代裏交付的質量標準。

然而隨着交付平臺愈來愈多，交付須要基於桌面端、移動端、web 端，桌面端包括 Windows，macOS 和 Linux，移動端包括安卓和 ios，愈來愈多平臺設計相應的 demo 勢必須要測試人員投入更多資源，同時 API 在不斷增加。所以自動化是必然趨勢。

2.0 GUI Demo Test Automation

2.0 階段是 GUI Demo Test Automation，開發人員將平臺進行了分層。

如上圖，上面的 iOS、OSX、Android 等是對外交付的平臺，下面是對應平臺用到的第三方開源工具，如 Appium 和 Selenium，中間這一層作相應分裝，其目的在於提升測試效能，用一套 case 覆蓋到全部交付的平臺。實現 70% 的自動化程度已經可以讓團隊節約一半的時間，極大地提升了測試效率。

3.0 API Demo Test

3.0 階段進入到 API Demo Test。聲網的測試主體是 SDK，SDK 關注點在於 API 功能實現、平臺適配、面向開發者、性能功耗包體積，集成構建打包；而 APP 關注業務功能、用戶交互、終端用戶、界面操做和程序安裝。針對 SDK、APP 兩種徹底不一樣的測試重點，聲網從新設計了一套針對 SDK 的自動化測試框架——Wayang Testframework。

Wayang 的原理來自印度尼西亞的一種木偶戲，前端是一個木偶，後臺表演者經過線和靈巧的手控制前端木偶去作相應的動做。在這樣的一個體系裏有三個不一樣的對象，左邊的對象是 test client，中間是 test server，右邊是對應的 test demo。Test client 至關於木偶戲幕後的表演者，須要明確本身的測試需求是什麼，設計相應的 test case；test demo 至關於前端的木偶，會根據測試端發出持續請求作相應行爲調用。全部的主動調用以及被動調用都是基於代碼輸出。在整個體系裏面全部的接口調用和相應回調都是基於代碼終端的輸出，無需關心界面的實現。和自動化 2.0 與手工 1.0 相比，目前天天能夠完成一百個以上 API 測試，自動化測試覆蓋率可以超過 80%。

4.0 AIO

在完成 Wayang 實踐後，聲網仍在思考是否可以有進一步的優化實踐。隨着產品交付迭代週期愈來愈緊，以及更多的需求介入，從測試角度來講，光考慮測試環節是不夠的，須要把整個產品交付歸入思考範圍以內——包括前期構建、打包、測試、交付。所以，這裏引入了 AIO 的理念。

AIO 是箱庭和沙盒的結合。那麼，什麼是箱庭和沙盒呢？箱庭可以提供基礎設施，至關於遊戲裏提供相應的陷阱、敵人或者寶箱，如何去獲取或者擊敗由本身決定。而沙盒意味着把最小的原子單位開放給用戶，典型例子有個人世界、樂高，最小單位就是一個 cube。聲網的測試單位是基於 API，那麼在整個交付裏面，箱庭對應着保證基礎設施（e.g：網絡、電源，測試環境）穩定運行，至於沙盒則會拆分構建、測試、上線發佈三個版塊。

在聲網一體化 AIO 架構裏面，包含了一系列相應的 module。

AIO 架構包括了設備集羣。由於不一樣平臺交付必然覆蓋各類各樣的狀況，須要考慮到不一樣設備的兼容性。調度中心確保全部設備在預期設定中如期交付，所以須要服務網關的存在。數據中心會分析 SDK 產物明確的 log 輸出；最後一塊是構建發佈，ACCS 平臺包括編譯、發佈、崩潰上報、數據分析、自動化測試等功能模塊。下面基礎能力表明着更底層的元素，如鏈路模擬、物理鏈接控制、人機交互等。

回到剛纔所說的 Wayang 的特性，須要有一個 client 對應一個 demo。Client 表演者知道須要作什麼，而後讓 demo 去作相應的事情。基於這個狀況，聲網作了進一步的提高。經過 API driven test，聲網設立了一個獨立的 soloWayang app，裏面的 test iterator 生成器能夠不停地把測試 API 持續調用。經過基於 test farm 併發測試，在全部設備上跑 soloWayang，全部相應的 API 都會被測試以確保發現和處理問題。

在測試環節裏面，會有很是多數據產生，包括 SDK data、demo data、test data 和 server data。如何去將這些數據作合理有效的預先挖掘？

傳統模式下，數據的價值在於出現問題後去分析數據。逆轉一下思惟的話，若是可以對數據進行提早收集和預分析，就能夠在問題暴露以前主動地去發現和解決風險。聲網數據分析平臺經過 Beats、Logstash 對不一樣平臺的數據進行清洗，將無效信息剔除。Kibana 經過相應的過濾，可以把相應問題列舉出來。舉個例子，某個晚上跑了四百臺設備，發現某臺設備出現對應的 log 異常，經過 Kibana 能夠進行預警，及時發現這個問題是否真的只有一臺設備存在，或者在數臺機器裏都存在共性。之前經過人工的方式去挖掘幾臺設備的數據是否有相應的問題，很難聯想到是否是與某一個系統有關、與某一個芯片有關，仍是跟某一個特定的網絡場景有關。經過數據分析平臺的合理過濾，可以幫助咱們經過種種證據的彙總來有效發現問題，儘早解決問題。

Q：針對於手機 APP 去作測試，若是須要上百部手機同時連起來，作一個性能測試環境。但一臺電腦的支持能力是有限的，可能同時鏈接十幾臺手機就達到極限了，怎麼去作橫向擴展作性能環境？
A：若是是針對安卓手機的話， 咱們有一臺早期的節點同時鏈接了 30 檯安卓設備證實是可行的，建議再肯定一下節點和外設的配置。更多的機器鏈接能夠經過採用集羣的方式來部署 test farm。另外，能夠在相應的 test app 應用中設計獨立的性能測試組件，有利於實現性能測試的橫向擴展。

點擊獲取視頻和 PPT 資料