講師：潘志剛
聲網質量效能部門負責人，超過 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 資料

標籤：其他

上一篇：SQL注入

下一篇：關于自動化測驗的幾個正確認知