背景

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

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

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

• 云端：

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

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

• 客戶端：

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

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

業(yè)務(wù)難點(diǎn)

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

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

• 手機(jī)：Android；Ios；
• 帶屏：公版；運(yùn)營(yíng)商；

• 無屏：Linux；RTOS；

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

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

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

質(zhì)量策略

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

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

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

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

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

• 進(jìn)程非前臺(tái)時(shí)表現(xiàn)異常；
• 會(huì)話通道占用；

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

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

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

音視頻回歸實(shí)驗(yàn)室

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

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

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

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

兼容性驗(yàn)證

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

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

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

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

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

弱網(wǎng)模擬

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

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

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

LinuxTC中配置丟包和延時(shí)：

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

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

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

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

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

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

鏈路排查工具

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

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

查詢用戶會(huì)話列表如下：

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

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

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

QoS

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

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

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

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

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

• 視頻質(zhì)量：圖像編解碼時(shí)延方式測(cè)試畫面延時(shí)；音畫同步檢測(cè)；基于ITU標(biāo)準(zhǔn)，搭建清晰度mos分平臺(tái)；流暢度校驗(yàn)；
• 音頻質(zhì)量：實(shí)時(shí)音頻3A處理校驗(yàn)；音頻延時(shí)校驗(yàn)；基于有/無參考語音質(zhì)量評(píng)估模型，搭建音頻mos分平臺(tái)；