背景

音視頻做為天貓精靈的重要業(yè)務(wù)，可支持多態(tài)終端的愛家看護監(jiān)控、音視頻通話等場景，志在打造陪伴類心智，為用戶生活增添便捷和美好。近一年業(yè)務(wù)經(jīng)歷了手機/音箱/云端/服務(wù)商等整體換血，在維持40萬日活訪問的基礎(chǔ)上，打造新品賣點，提升性能耗時。音視頻業(yè)務(wù)的質(zhì)量保證，除了要考慮通用音視頻指標，還要結(jié)合業(yè)務(wù)架構(gòu)實際，從功能/穩(wěn)定/性能/QoS等方面提升用戶體驗，了解行業(yè)位置?，F(xiàn)將質(zhì)?？蚣芸偨Y(jié)如下，希望能拋磚引玉，共同進步。

業(yè)務(wù)架構(gòu)

貓精音視頻的業(yè)務(wù)架構(gòu)，主要分云端和客戶端兩部分：云端主要建立媒體流會話和會話推拉流；客戶端分帶屏/無屏音箱、手機app等，主要在各終端適配sdk，協(xié)調(diào)硬件資源，承載用戶交互。

• 云端：

主叫發(fā)起呼叫時，ai-iot-vision-platform開始對接RTC媒體服務(wù)商，注冊媒體流會話通道：先獲取本輪中的會話id/token等鑒權(quán)信息，再推送呼叫指令給被叫設(shè)備（單臺或多臺）；某臺被叫接聽后，vision先推送接聽指令到主叫，告知通道建立成功，再發(fā)送主被叫信息至RTC server，完成會話通道建立；

通道建立后，主/被叫端直接和下游RTC Server通信，RTC根據(jù)各端攜帶的會話id/token等，對比之前保存的主被叫信息，進行鑒權(quán)；鑒權(quán)通過后，端側(cè)開始媒體幀的推/拉流，進行監(jiān)控/音頻/視頻通話操作；通話掛斷后，vision關(guān)閉本輪會話，同時向RTC發(fā)送指令關(guān)閉本輪通道，釋放資源；

• 客戶端：

包括主叫和被叫方，按業(yè)務(wù)調(diào)用順序從上至下，可分為3塊：

1. 按鍵/屏幕/語音/攝像頭 App：最上層應(yīng)用，控制各終端硬件操作，資源調(diào)配。根據(jù)業(yè)務(wù)優(yōu)先級，需考慮各資源搶占的場景，避免異常；需考慮資源調(diào)用時序，避免無效調(diào)用，影響業(yè)務(wù)耗時；
2. GenieRTC App：核心業(yè)務(wù)應(yīng)用，按照業(yè)務(wù)時序分別和云端通信，調(diào)用上層硬件資源，啟動下層sdk邏輯。因為邏輯復(fù)雜且需在各態(tài)終端兼容，容易出現(xiàn)狀態(tài)機時序異?；蛘呓K端不匹配問題；
3. RTC sdk：最下層的sdk，負責(zé)和RTC server通信進行媒體幀的推拉流，初期較多推拉流失敗導(dǎo)致的黑屏或卡死。因為歷史原因，要同時集成AliRtc和ARtc雙sdk，和各自的server端通信，提供媒體流服務(wù)；

業(yè)務(wù)難點

綜合業(yè)務(wù)特征和用戶反饋，貓精音視頻質(zhì)保主要難點如下：

• 設(shè)備版本多：業(yè)務(wù)承載的端較多，底層系統(tǒng)或業(yè)務(wù)線各不相同，GenieRtc無法通用，需根據(jù)各端形態(tài)分別開發(fā)驗證。主要設(shè)備版本如上圖，可分為：

• 手機：Android；Ios；
• 帶屏：公版；運營商；

• 無屏：Linux；RTOS；

各端升級更新均要做回歸驗證，由于業(yè)務(wù)發(fā)展更新版本多，財年三端共迭代近百次，需自動化手段解決大量的回歸需求；

• 組合搭配多：需考慮主被叫中形態(tài)/系統(tǒng)/sdk/新老鏈路等組合，優(yōu)化整合后涉及鏈路60+條；每個鏈路需考慮監(jiān)控/視頻/音頻場景；各場景需考慮語音/屏幕/手勢/按鍵等操作；再加上單用戶多設(shè)備/攝像頭占用/音視頻焦點搶占等異常場景，組合后場景總量1000+；

• 異常時序場景：云端鏈路上vision應(yīng)用和端上主叫/被叫共有3個狀態(tài)機，有各自的時序定義且互相依賴，容易出現(xiàn)某狀態(tài)機異常導(dǎo)致整條會話鏈路堵死，甚至?xí)挓o法消亡，資源占用無法再打，造成規(guī)模性故障。常見異常原因有：硬件性能/軟件bug/網(wǎng)絡(luò)狀態(tài)等，均會導(dǎo)致端側(cè)時序錯誤，云端會話建立困難。該類問題一般為偶現(xiàn)不好排查，需分析多端日志定位問題；
• 弱網(wǎng)問題多：根據(jù)2021.10～2022.1業(yè)務(wù)數(shù)據(jù)，平均弱網(wǎng)uv占比為36.81%（UV占比 = 統(tǒng)計觸發(fā)弱網(wǎng)埋點設(shè)備數(shù)量 / 總設(shè)備數(shù)量），約1/3用戶上行網(wǎng)絡(luò)表現(xiàn)不佳，易出現(xiàn)監(jiān)控或視頻場景中的黑屏/掛斷/卡頓/無聲音等情況，工單數(shù)據(jù)中該類占比87%；弱網(wǎng)場景在持續(xù)優(yōu)化中，QA也需要搭建高效的弱網(wǎng)測試環(huán)境，驗證提升效果；

質(zhì)量策略

音視頻質(zhì)量涵蓋面廣內(nèi)容多，需根據(jù)業(yè)務(wù)實際明確質(zhì)保范圍，再選擇適合的測試手段和標準。貓精音視頻業(yè)務(wù)，用戶主要使用場景為監(jiān)控和通話，講究互動的實時性，對時延/卡頓/黑屏等容錯率較低；該場景同時使用上下行網(wǎng)絡(luò)，對網(wǎng)絡(luò)環(huán)境要求較高。所以在保留核心功能/性能/QoS的前提下，增加了不同網(wǎng)絡(luò)的穩(wěn)定性指標，保證業(yè)務(wù)穩(wěn)定提升。

業(yè)務(wù)功能

業(yè)務(wù)場景相對確定，但主被叫因素變化多會導(dǎo)致分支較多。故使用單因素分析法，先只變化主被叫的形態(tài)/SDK/系統(tǒng)中單個因素，確定分支鏈路，再根據(jù)業(yè)務(wù)遍歷每條分支的測試場景。列出核心功能測試矩陣如下：

此外，每條鏈路還需考慮的業(yè)務(wù)異常場景，包括但不限于：

• 單人多設(shè)備；
• 攝像頭搶占；

• 進程非前臺時表現(xiàn)異常；
• 會話通道占用；

• 斷電/斷網(wǎng)狀態(tài)機時序異常；
• 音箱按鍵交互；

• 音箱資源搶占（內(nèi)存/音視頻焦點）；

所以功能驗證場景達1000+，且涉及的端多，各端升級均需進行必要的回歸，工作量較大。采用音視頻回歸實驗室，自動化部分場景，減輕人工負擔(dān)。

音視頻回歸實驗室

appium是移動應(yīng)用測試框架，可支持android/ios等系統(tǒng)，實驗室中用來做音箱端（同為android系統(tǒng)）/手機端的控件操作和校驗。參考功能矩陣，頁面類測試場景（如監(jiān)控類和視頻/音頻屏幕類）主要通過appium觸發(fā)控件操作，再進行頁面上的控件斷言，當(dāng)控件不可見時（如判斷新老鏈路/畫面全屏等），通過端側(cè)的日志關(guān)鍵字斷言；語音類測試場景（如視頻和音頻語音類）可通過網(wǎng)關(guān)層接口灌入，模擬用戶語音發(fā)起通話，再進行頁面的控件斷言和端側(cè)的日志斷言。

實驗室運行在已有的天梯平臺，上傳好測試腳本，平臺啟動任務(wù)后，云端下發(fā)任務(wù)至樹莓派實驗室，再分別控制主叫/被叫方操作和斷言，最后平臺化展示結(jié)果。

由于無屏音箱底層系統(tǒng)差異，實驗室暫未涵蓋無屏音箱場景。如下，實驗室中主叫/被叫分別對應(yīng)一臺手機和一臺帶屏音箱，保證核心的功能場景。

當(dāng)前app和帶屏交互鏈路中，所有屏幕類正常場景均實現(xiàn)自動化，占核心場景60%。天梯平臺中測試結(jié)果展示如下，

兼容性驗證

不同設(shè)備的編解碼能力會影響通話表現(xiàn)，該能力由于底層系統(tǒng)/資源配置不同，差異較大。實際場景中，音箱配置相對固定，手機機型更多變，工單中也更多會報出不同手機的異常表現(xiàn)（如手機畫面顛倒；app未啟動/手機黑屏?xí)r，手機推送異常等），所以參考線上手機使用量選擇10款機型，基于云真機平臺，驗證在同樣網(wǎng)絡(luò)環(huán)境下，不同機型通話表現(xiàn)。

兼容性場景除覆蓋主鏈路外，還需考慮app推送，攝像頭搶占，進程非前臺等場景。如下為云真機平臺執(zhí)行截圖：

業(yè)務(wù)穩(wěn)定

分析線上工單數(shù)據(jù)，通話超時/掛斷/黑屏/卡斷等問題約占87%，分析問題主要為不同網(wǎng)絡(luò)下，通話表現(xiàn)較競品有一定差距，所以優(yōu)先從網(wǎng)絡(luò)環(huán)境出發(fā)，逐步提升弱網(wǎng)穩(wěn)定性；同時由于偶現(xiàn)問題日志不全不好復(fù)現(xiàn)，故建立日志排查工具提升效率：

1. 接通成功率和耗時較競品有一定差距，需模擬用戶操作，建立各網(wǎng)絡(luò)環(huán)境下的基線指標，提升穩(wěn)定性效率。故采用軟件方式模擬弱網(wǎng)環(huán)境，在不同弱網(wǎng)級別上進行接通率和耗時監(jiān)控，建立基線指標；
2. 日志抓取過程較復(fù)雜（有6步驟），部分sdk底層日志需單獨打包才能抓取，若有遺漏得再次復(fù)現(xiàn)偶現(xiàn)問題；同時排查線上問題時，需要從多平臺獲取各端日志且時間不同步，存在學(xué)習(xí)成本。所以在雮塵珠平臺上，增加性能基線平臺和鏈路排查工具，提升測試和排查效率。

弱網(wǎng)模擬

參考業(yè)內(nèi)指標和用戶真實網(wǎng)絡(luò)數(shù)據(jù)，制定網(wǎng)絡(luò)分級策略如下。主要為網(wǎng)絡(luò)帶寬，丟包率，延時3個指標的設(shè)置。

為了具備通用性及成本控制，采用軟件方式模擬弱網(wǎng)3個指標的設(shè)置。經(jīng)過選型比較，采用樹莓派+linuxTC方式來模擬網(wǎng)絡(luò)損耗，可任一網(wǎng)絡(luò)環(huán)境中配置，增加通用性。主要架構(gòu)如下：

業(yè)務(wù)中用戶網(wǎng)絡(luò)為POOR及以下的約占1/3，所以弱網(wǎng)測試范圍主要考慮正常/Poor/Bad三個網(wǎng)絡(luò)級別，各自比較貓精和競品在不同網(wǎng)絡(luò)下的性能指標。如下在linuxTC中，配置poor網(wǎng)絡(luò)。

LinuxTC中配置丟包和延時：

路由器中配置上行網(wǎng)絡(luò)流量：

配置后，檢查各配置參數(shù)是否生效：

穩(wěn)定性基線平臺

項目初期穩(wěn)定性指標為人工測試，百次重復(fù)量大且計時有誤差，所以基于totoro完成穩(wěn)定性腳本，用戶先本地配置網(wǎng)絡(luò)環(huán)境和安裝各端待測版本，再本地啟動腳本開始監(jiān)控/視頻/音頻多輪執(zhí)行，監(jiān)控屏端控件展示并拆解每輪端側(cè)日志，得出耗時和通過率數(shù)據(jù)，保存數(shù)據(jù)和日志供后續(xù)排查，最后上傳json文件至穩(wěn)定性平臺形成基線。

使用自動化腳本，指定測試類型和次數(shù)，運行后獲取每輪端側(cè)日志，整體運行結(jié)果和json文件，其中通話成功率主要從屏幕控件分析；通話耗時主要從日志關(guān)鍵字獲取。

穩(wěn)定性基線為前幾次指標值均值，若測試數(shù)據(jù)低于基線則不滿足發(fā)布標準，需分析日志排查定位。

鏈路排查工具

工具主要是從sls中獲取云端/主叫/被叫的埋點日志，根據(jù)關(guān)鍵字整合，鏈路化展示狀態(tài)機時序，便于快速定位偶現(xiàn)問題，避免無效的問題復(fù)現(xiàn)。平臺輸入賬號信息，可查詢用戶下所有通話列表，進入會話詳情，可查看云/主/被通話時序，高效定位問題原因。

各狀態(tài)機正常通話時序參考如下。其中主叫無answer類應(yīng)答時序，云端根據(jù)用戶接聽/拒絕操作，時序不同。

查詢用戶會話列表如下：

對比云端和端側(cè)狀態(tài)，定位通話中問題原因：

業(yè)務(wù)性能

基于業(yè)務(wù)現(xiàn)狀，性能指標主要考慮核心業(yè)務(wù)場景下的cpu/mem/電量等資源消耗情況，建立性能基線和發(fā)布卡口。其中cpu和mem主要基于組內(nèi)自研工具mobilePerf，電量基于Power Monitor。后續(xù)計劃引入流量消耗，設(shè)備溫度等指標保證音視頻的用戶體驗。

QoS

當(dāng)前監(jiān)控的QoS指標包括：音頻質(zhì)量（MOS分），音視頻延時，音畫同步，視頻清晰度，視頻流暢度等。主要基于阿里云自動化評測平臺實現(xiàn)，每個sdk大版本會有測試數(shù)據(jù)產(chǎn)出，以保證流媒體推送服務(wù)的質(zhì)量推進。

后續(xù)規(guī)劃

隨著貓精音視頻業(yè)務(wù)逐步發(fā)展、競品差距逐步減小，質(zhì)保逐漸從手工到半自動化，從功能擴展到性能穩(wěn)定QoS等，但音視頻內(nèi)容多涉及廣，測試指標/工具/策略都需要進一步優(yōu)化和改進，以提升行業(yè)位置和用戶體驗：

• 測試指標：功能上增加異常場景，提升自動化率；性能上增加流量、電量、溫度等測評指標和手段；硬件上增加設(shè)備編碼、解碼能力測評；
• 測試工具：加強網(wǎng)絡(luò)測評，對不同運營商/wifi/地域的信號分級，為弱網(wǎng)指標提供參考；參考優(yōu)秀經(jīng)驗，優(yōu)化首幀時長計算方法從日志分析變?yōu)閳D像分析，更真實地反映端側(cè)耗時；

• 測試策略：搭建音頻質(zhì)量和視頻質(zhì)量QoS體系：

• 視頻質(zhì)量：圖像編解碼時延方式測試畫面延時；音畫同步檢測；基于ITU標準，搭建清晰度mos分平臺；流暢度校驗；
• 音頻質(zhì)量：實時音頻3A處理校驗；音頻延時校驗；基于有/無參考語音質(zhì)量評估模型，搭建音頻mos分平臺；