Categories
程式開發

優酷如何構建覆蓋全網的播放白盒測試體系


一、背景

隨著移動端業務的持續發展,移動測試技術也從最初偏黑盒的手工測試轉變為基於各類UI自動化測試框架,開發適合自身業務特點的自動化case,一定程度解放了測試人力。

播放器作為優酷的核心基礎模塊,為點播、直播、短視頻等業務提供基礎播放能力,播放質量保障過程涉及到眾多業務方和大量回歸適配工作,因此迫切需要自動化能力。經過一系列調研,我們認為傳統的UI自動化方案在播放場景下存在一系列弊端:

無法有效覆蓋各類播放策略的正確性和有效性;依賴相對固化的UI元素層級,與優酷快速迭代的節奏不match;case開發維護成本高,投入產出低;播放場景強依賴網絡環境,UI自動化在可控網絡方面不夠靈活。

為解決以上問題,優酷測試團隊自研出一套基於AFrame的白盒自動化測試方案,並在此基礎上構建出基於實驗室環境的播測驗證體系和基於外網環境的動態撥測體系。

二、工欲善則利其器-移動端白盒自動化方案

基於AFrame的白盒自動化測試框架由5個核心模塊組成:AFrameSDK、AFrameServer、CaseClient、PKAT和AFrameService;其中AFrameSDK作為移動端側模塊,已集成到優酷app,其餘4個模塊均可脫離移動端,支持單獨部署,各模塊通過WebSocket或者Http進行交互,整體交互關係如下:

優酷如何構建覆蓋全網的播放白盒測試體系 1

  1. AFrameSDK:自動化測試的移動端入口模塊,該模塊包含與AFrameServer長連的WebSocket Client,用於接收和解析AFrameServer下發的測試指令、調度執行、過程同步、數據收集和轉發;
  2. CaseClient:通過改造JUnit測試框架為每個用例創建一個WebSocket Client,向AFrameServer發送執行指令,並接收其中轉的測試結果,完成行為分析和數據判斷;
  3. AFrameServer:框架的數據“中轉站”,監聽來自CaseClient和AFrameSDK的連接請求,為CaseClient和AFrameSDK建立一對一的連接通道;
  4. AFrameService:用於用例管理、執行管理、設備管理、結果管理、配置和任務下發等;
  5. PKAT:播放測試結果校驗和分析中心,是播放業務的“問診台”,多端播放測試用例執行後,由其根據實際場景對Log、VPM埋點、接口數據等關鍵信息進行分析校驗。

移動端自動化調度員-AFrameSDK

作為整個測試框架的入口模塊,也是5個模塊中唯一嵌入移動端的模塊,AFrameSDK承擔著接口自動化調度員的角色。 AFrameSDK的主要工作流程如下:

  1. 與AFrameServer建立連接,等待AFrameServer下發執行指令;
  2. 接收執行指令、解析指令、驅動執行;
  3. 執行數據反饋,並發送回AFrameServer。

AFrameSDK接收到AFrameServer下發的指令後,通過對應的規則完成對指令的解析並驅動app執行。 AFrameSDK內置了若干通用的基礎工具庫供業務方使用,業務方也可以根據自身測試需求,定制化基於業務的測試驅動接口,目前已接入並具備定制化場景測試能力的業務方包括播放器、緩存、來瘋等。

優酷如何構建覆蓋全網的播放白盒測試體系 2

數據中轉服務-AFrameServer

指令和數據是自動化測試的核心物料,AFrameServer作為指令下發和數據傳輸的中心節點,承擔著“搬運工”的角色,AFrameServer將接其收到的連接請求分成如下幾類:

  1. 移動設備端連接;
  2. 用例端連接;
  3. AFrameService連接,用於設備同步、任務同步等;
  4. 功能擴展連接,如內外網穿透需求等。

AFrameServer接收到上述連接請求後,根據分類和連接標識管理所有連接,當連接請求A需要和連接請求B進行通信時,需指定B的連接標識信息,AFrameServer通過該連接標識為A、B提供數據轉發服務。

優酷如何構建覆蓋全網的播放白盒測試體系 3

基於JUnit的用例設計-CaseClient

用例設計是最重要的測試環節之一,用例設計的好壞和覆蓋度直接決定了測試效果,為了提高用例設計和開發效率,對JUnit框架進行二次改造,封裝改造後的用例設計CaseClient主要具備以下優勢:

  1. 支持多用例實例執行隔離,尤其當用例與移動設備存在一對一關聯關係時,可做到互不干擾;
  2. 支持根據執行過程動態控制用例執行,如播放失敗後處理、Crash後優雅終止;
  3. 支持可控化參數輸入,如用於打通限速服務的可控網絡輸入、測試數據輸入、執行參數控制等;
  4. 面向接口編程,無需要關注與AFrameServer間的交互邏輯。

結果管理與任務下發-AFrameService

AFrameService作為測試啟動入口,承擔著“大管家”的角色,該模塊提供了一系列接口供用戶使用或測試平台調用,核心工作流程如下:

  1. 接收AFrameServer同步端設備信息;
  2. 向CaseClient發起測試用例任務執行命令;
  3. 執行完成後,CaseClient將執行基礎數據、執行過程數據回傳至該模塊,同時異步調用PKAT對結果進行分析和校驗;
  4. PKAT分析完成後將結果上傳至該模塊存檔。

三、既要“播測”也要“撥測”

基於實驗室環境的播測能力

基於實驗室環境的播測能力主要包括,播放核心topic自動化&常態化測試能力和播放器基礎質量評估能力(包含:線下穩定性評估、基礎性能評估、VPM基礎校驗)。下面以智能檔為例,簡要介紹播測系統在實際業務中的落地實踐情況:

  1. 常規測試方法:播放上層業務可以通過播放控制面板的UI交互獲得視覺上的反饋,智能檔區別於上層業務,它是基於多種算法去決策視頻流中每個分片的清晰度檔位,即使能夠通過肉眼看出播放過程中的清晰度變化,也無法直觀的確定該清晰度變化是否合理;所以我們通常通過智能檔相關內核日誌,確定每個分片的檔位清晰度及其決策依據;測試時需要從日誌中獲取大量信息來判斷整體決策過程是否正確,測試非常低效,同時大量的上下文信息切換,疏漏無法避免,智能檔測試挑戰重重;

  2. 測試痛點&難點:智能檔涉及算法眾多,算法參數配置複雜(常用算法參數配置超過20餘種);網絡環境模擬難(限速、丟包、延時、網絡秒級控制);校驗標準量化難(算法邏輯複雜,每一次決策都有多種因素影響);日誌量龐大(一集40分鐘的視頻需要關注上千個關鍵信息);

  3. 智能檔播測解決方案:

    第一步,用戶行為模擬: AFrame作為一個獨立模塊打包到被測app,通過獲取當前播放實例,以白盒方式調用播放器內部的各種API,模擬用戶對播放器的各種操作;

    優酷如何構建覆蓋全網的播放白盒測試體系 4

    第二步,測試環境模擬:對於網絡環境模擬,將路由器與一台主機A的網卡連接,通過網卡命令控制連接到路由器的移動設備網速、丟包、延遲。將TCP Server搭建到主機A,任意一台PC/MAC均可通過限速TCP Client對網絡進行秒級控制。限速網絡json配置以_{“50”: [1500, 0, 0]}_為例,含義為50秒時,限速為1500kbps,丟包為0%,延遲為0毫秒;

    測試配置方面,優酷app使用APS和Orange進行線上配置下發,常規測試方法中,我們通過掃碼方式手動拉取配置 且在app重啟後反复操作拉取。在播測方案中,通過AFrame提供的APS和Orange Hook能力,直接通過API接口完成對APS和Orange的配置,例如配置智能檔使用特定的決策策略,只需在測試用例中加上_APSConfig.setAPSConfig (commandSender, “adaptive_bitrate”, “[“source_adaptive_mode=5”]”)_ 即可;

    第三步,全流程自動化:目前基於AFrame測試框架和限速網絡,已實現一鍵式執行智能檔日常回歸測試,用例執行結束後在播放器統一測試平台上生成測試報告。智能檔播測流程如下所示:

    優酷如何構建覆蓋全網的播放白盒測試體系 5

基於外網環境的撥測能力

實驗室網絡和外部網絡的最大區別是網絡環境的複雜性和透明度,在實驗室環境下通過網絡控制來模擬各類場景,在確定的環境下執行播放測試任務,由於清楚的知道實驗室網絡各項指標,測試的預期結果相對比較明確;但由於播放鏈路的複雜性和多樣性,僅在實驗室環境無法有效覆蓋真實情況,因此基於外網環境的撥測能力是對實驗室播測方案的有效補充,在外部網絡中,我們無法準確獲取網絡狀態,因此我們結合自研的網絡探測能力,獲取不同域名下的網絡帶寬、時延、丟包率、連接速度等信息,通過計算其平均值、標準差、變異係數進行動態的case評估校驗。從技術上來講,外網撥測也是基於AFrame框架來實現的,通過AFrameServer外網部署,支持外部設備數據的接收和中轉,結合網絡探測能力,實現基於網絡場景的動態撥測驗證,外網撥測針對網絡調度、播放鏈路相關的潛在問題具備較好的發現能力,由於篇幅有限並且核心鏈路和播測方案類似,這裡不再展開贅述。

四、總結&展望

優酷測試團隊始終關注質量基本盤的有效性和完備性,在持續深化核心topic線下測試評估能力、守住質量基本盤的同時,形成了涵蓋線下測試、冒煙播測、外網撥測的三級漏斗用例模型,測試同學為此持續提供邏輯自洽、基於用戶和業務的思考過程,將三級漏斗用例模型間的聯動共生通過平台化能力表達出來。

作者介紹

默研,阿里文娛資深測試開發工程師。