作者：羅必達，騰訊音視頻實驗室質量平臺組組長，高級工程師。早年在微軟從事移動測試開發，先後參與了 Windows Live Messenger 和 Bing Mobile 兩個項目的測試工作。2011 年加入騰訊，轉型音視頻技術研究，從事建立音視頻技術測試體系的工作，並負責 QQ 音視頻通話以及騰訊雲互動直播 SDK 的底層音視頻引擎的測試，在工作和研究中對音視頻質量評估積累了豐富的經驗。喜歡音樂和玩樂器，喜歡攝影，喜歡繪畫，是個不折不扣的“文藝青年”。
從事音視頻相關的測試工作也有將近5年的時間了，一路看着QQ音視頻的發展，從當時只有幾個人的小團隊，到現在連續兩年公司技術突破獎金獎，回想起來確實挺激動。好吧，自戀的東西少提爲妙，進入正題。
爲什麼要寫這篇文章
幾年前我就想寫這麼一篇文章了，但是當時音視頻在SNG乃至公司都是一塊比較小衆、相對獨立的一個業務分支。隨着SNG對音視頻越來越重視，最近也有越來越多的團隊線下找我諮詢關於音視頻測試的一些方法，我突然覺得，是時候把自己這幾年對音視頻測試相關的思考分享給大家了。當然也有自私的一面，因爲音視頻只是一種技術，應用非常廣泛，而我們多年投身在實時音視頻通信這其中一塊分支上，難免會對整個音視頻行業產生片面的認識，所以也想借此跟大家交流，讓我們團隊自身可以拓展一下知識面。
音視頻測試測的究竟是什麼
我覺得這個問題很重要。很多向我諮詢音視頻測試方法的同學，也許連這個問題都還沒有想清楚（說得太直接，抱歉）。其實這不奇怪，說實話我也是最近纔開始思考這個問題。音視頻測試測的究竟是什麼？
我思考這個問題的原因是，很多同學向我諮詢音視頻測試方法，但我卻沒辦法給出一個明確的答案。腦海裏把這5年的經驗都翻了一遍，發現都無法找到可以滿足他們的答案。最後終於茅塞頓開，原因是我們都沒想清楚要測的是什麼。
上文已經提到，音視頻只是一種技術，應用面太廣，並非但凡跟“音視頻”這幾個字眼沾上邊的都可以用一套方法去解決，也就是說，沒有“銀彈”。
首先我們要問自己，我所負責的音視頻業務究竟要測的是什麼。是“音視頻本身”的質量，還是“音視頻周邊”相關的東西。
這麼說有點抽象，我還是舉些例子吧。
例如我們這5年來一直負責的QQ音視頻通話，學術一點來說就是實時音視頻通話，因爲音視頻的內容是我們實時生成的，在傳輸過程中，爲了保證通話的實時性，我們還需要對音視頻的一些參數進行實時調控（例如分辨率、碼率和幀率等等），以適應複雜的網絡狀況（注意網絡狀況是不斷在實時變化的，之前看了很多公司內部關於網絡相關的分享，大多數建立在靜態分析上，這其實是不正確的，當然業務不同，關注點不一樣）。所以我們要測試的就是“音視頻的質量”。
好了，大家可能要問，還有不是測“音視頻質量”的音視頻測試嗎？有的，我再舉個例子。例如QQ空間裏可能要播一個騰訊視頻，這個視頻已經在後臺存好了，你沒辦法控制它的生成，也無法動態對它進行調控（即使可以調控，也是非實時調控）。在這種情況下，你測試的並不是“音視頻質量”，而是“播放質量”，也就是我剛剛所說的“音視頻周邊”相關的東西。這類測試，跟大家平時測的其他非音視頻需求沒有太大的不同，唯一區別就是，可能對音視頻相關知識的一些瞭解會對你設計測試用例帶來一些幫助。
分析所測的音視頻需求
剛剛說了一大堆，無非是想告訴大家，在接到音視頻測試需求的時候，需要對其進行業務分析。我再重申一下剛剛的論點：
首先問自己，我所測試的是不是音視頻質量
在解答了這個問題後，你可以進行業務分析了。
不同的業務，對音視頻的要求是不一樣的，相應的測試方法也不一樣。我這裏簡單做一些歸類：
- 實時通話類業務
例如我們所負責的QQ音視頻，就是這類業務。這類業務對實時性的要求很高。想象一下，你在跟家人聊天，在講完一句話後，要在幾秒後才能聽到對方的反應，這是不可接受的。這就要求我們實時地根據網絡情況，提供不同質量的音視頻。例如，在鏈路帶寬突降的時候，我們需要立刻感知到，並且儘快降低碼率，以使得通話能夠順利進行（可參考網絡帶寬的水池效應，這時候如果我們還追求所謂的清晰度、流暢度，那其實是本末倒置的）；當帶寬恢復後，我們還要儘快地把碼率提上來，以便用戶得到清晰流暢的畫面和聲音。這些調整同樣需要在其他網絡損傷中進行，例如丟包（還分隨機丟包和連續丟包）、抖動等等。
所以實時通話類業務的測試，我們更多地把關注點放在”流控策略“上面。
- 異步通話類業務
異步通話類業務典型的代表是PTT。由於不需要根據網絡進行實時調控（有點類似於傳文件），所以這類音視頻業務的音視頻測試相對簡單，只需要關注生成的語音音質和大小的權衡關係就行了（注意我只是說音視頻測試，其他例如到達率等等的測試，那已經不是音視頻測試的範疇了，下面幾個分類也如此）。也就是因爲這樣，這種業務的音視頻開發工作更多地是在選擇合適的CODEC以及選擇哪個碼率（非實時選擇）更優上。這種情況下，對用戶在音質和流量的接受程度就至關重要了，當然，這種事情我個人認爲應該產品經理來把握比較好（別跟我扯產品經理不需要技術知識）。
- 一對多的秀場類業務
這類業務最近很火，最典型的就是全民直播（例如映客、花椒等等，一抓一大把）。這類業務的特點是對延時要求不高，但對清晰度和流暢度要求很高。也正是因爲延時要求不高的特點，纔可以把碼率維持在高段，來做到高分辨率和高幀率（這是實時類無法做到的）。一般來講，技術上都以RTMP來實現。
基於以上特點，這類音視頻業務，重點就不是放在”音視頻本身”的質量上了，而是其他體驗了，比如說美顏、美白等等跟趣味相關的前處理上，還有頻道進入的速度、切換速度等用戶體驗上。
另外必須要提一下，這類業務並非完全對實時性沒有要求。例如教育，在一般場景下，確實是這種一對多的業務形態，但是，一旦有老師跟學生之間的交互，那麼，保證一定的實時性也是必須的。所以，還是得看具體的業務形態具體分析。
- 流媒體類業務
流媒體類業務是音視頻技術的一個很重要的分支。作爲常年從事通話類業務的我，或許沒有太多資格來對這一塊提建議。但因爲這個部分是介紹不同業務的音視頻測試特點，我還是有必要來講一下流媒體這一個分類。
流媒體類業務相對通話類業務，有一個很大的不同，那就是用戶之間基本上沒有音視頻層面的互動。廣義上來講秀場類業務也可以歸爲這一類。
同樣，這類業務對實時性沒有要求，音視頻也是存儲在後臺的數據。音視頻測試在這類業務上更多是關注編碼或者轉碼的質量。這類測試由於可以使用很多全參考的工具（如PEAQ、PEVQ等），相對來講會比較簡單，甚至開發人員自己就可以對這一塊進行測試了。
在傳輸層面，我不太清楚現在的流媒體業務會不會根據網絡情況來動態轉碼（比如動態轉分辨率和碼率）。如果有，那這一塊文章就大了。如果沒有，只是靜態地切換幾個已生成的分辨率，那基本上也跟音視頻測試沒太大的關係了。
這類業務離不開下面要講的另一類業務。
- 播放類業務
我把QQ音樂和騰訊視頻這種業務的客戶端歸類到播放類上（也就是說，不考慮服務器的內容生成或轉碼部分）。這類業務剛剛提過，測試的其實不是“音視頻本身”的質量，而是播放器的質量。這類業務在傳輸方面，更多的是考慮緩存大小與實際體驗（例如流暢性）的關係。
但是這裏有一點要注意的，這類業務也並不是完全和音視頻測試毫無關係，例如QQ音樂客戶端有個音效相關的功能，這是後處理技術，也是需要一定的音視頻測試。
。。。。。。
還有很多業務類型，就不在這裏一一列舉了。
也許上面的分類不一定準確，但這不重要，重要的是想希望大家在面對音視頻相關的測試需求時，認真分析一下其特點，然後有所針對地進行測試。
需要什麼知識
無論你是不是“真的在測音視頻”，跟音視頻沾點邊的需求，都需要你具備一定的音視頻基礎知識。
當然這些知識沒有辦法在一篇文章裏面講清楚，所以僅在這裏列舉一下，大家可以根據自己的需求去學習。
音頻知識
（基礎篇）
瞭解術語：採樣率、聲道、碼率、噪聲抑制（NS）、回聲抵消（EC）、增益控制（GC）、信噪比
瞭解CODEC：語音類CODEC、音樂類CODEC，以及他們之間的應用範圍及區別
（進階篇）
瞭解採樣定理、心理聲學模型、傅里葉變換、頻譜
視頻知識
（基礎篇）
瞭解術語：分辨率、顏色空間（RGB、YUV等）、幀率、碼率
（進階篇）
瞭解人眼視覺系統特性，瞭解視頻編碼原理，瞭解幀類型（I幀、P幀、B幀）及參考關係
網絡知識
（基礎篇）
瞭解損傷類型：丟包（連續丟包、隨機丟包；固有丟包、擁塞丟包）、延時、抖動
（進階篇）
瞭解丟包恢復策略（FEC、重傳）及其優缺點，瞭解Jitter Buffer及其影響，瞭解實時帶寬預測算法
評測知識
無參考評估、全參考評估（PESQ、POLQA、PEAQ、PSNR、SSIM、PEVQ等）、MOS
其他
瞭解一些攝影相關的知識（例如快門、光圈、感光度），瞭解一些平臺音視頻相關的API（採集和渲染）
Q&A
這裏把一些大家以前問到，或者可能問題的一些典型問題，拋出來給大家分享一下。
Q：清晰度高指的是分辨率高嗎？
A：這個估計是很多非音視頻專業的同學常常會搞混的兩個概念。我這裏先給出答案：分辨率確實會影響清晰度，但是兩者沒有絕對的關係。爲什麼這麼說呢？拋開採集因素（例如攝像頭沒對焦）之外，這裏還涉及一個因素：碼率。我先假設這裏大家講的不是無損視頻，那麼必然涉及到編碼。如果編碼碼率低，就算分辨率再高，單幀質量也會由於各種塊效應顯得很“髒”，就更不用提清晰度了。
Q：採樣率對音質有什麼影響？
A：首先要了解採樣定理，即採樣率必須高於輸入信號最高頻率的2倍，這樣才能無失真地恢復原始信號或完整地保留信息。也就是說，8kHz的採樣率只能表示0~4kHz頻率的聲音信號，而48kHz能夠表示0~24kHz頻率的聲音信號。所以，如果要表示所有人耳能聽到的所有聲音（頻率範圍20~20kHz），就必須使用40kHz以上的採樣率（常見的是44.1kHz和48kHz）。當然，採樣率高了，意味着數據量就大了，編碼後的碼率也就高了。所以選擇什麼採樣率，跟你的應用對高頻的需求有多大。例如電話這種應用，目的是用於人與人的溝通，而人類的發聲範圍是100~3400Hz，所以8kHz基本上就能滿足。QQ音視頻用的是16kHz採樣率，因爲用戶在滿足溝通之餘，還需要一定的所謂的真實感。
這個採樣定理也可以用在視頻上，比如上面所說的分辨率，實際上就是空間採樣率，分辨率越高，能夠表示的空間頻率越大，也就是說可以表示更加複雜的紋理，所以一般情況下清晰度也就上去了。
Q：碼率能再低些嗎？
A：這是我最經常被問到的問題，特別是之前在跟手Q基礎側PK音視頻流量的時候。這個問題其實不好回答，因爲這裏涉及到質量與碼率的權衡關係。在相同的CODEC情況下，碼率對質量的影響最大，降低碼率，意味着就損失質量，而音視頻質量卻又是一個非常主觀的東西。你很難證明目前的質量是否可以再降。因此QQ音視頻只能在移動網絡這種流量敏感的網絡類型中，提供比wifi及有線網絡質量稍差的體驗，以減少流量的消耗。但是依然會被問，還能再低些嗎？這個問題沒有答案。
Q：我看你們的文檔裏經常有提到主觀測試，有更高效的方法嗎？
A：首先，我要強調一點，如果你是做音視頻測試，一定不能排斥主觀測試，哪怕效率低下。這是因爲音視頻質量本來就是一個很主觀的東西。我舉個例子，在可用帶寬極低的情況下，QQ音視頻能用的碼率有限，在視頻中，必然涉及清晰度和流暢度的權衡。如果這時你問不同的人，是希望保證清晰度還是流暢度，你肯定會得到不同的答案。ITU對主觀測試有一些規範，也就是我們經常聽到的MOS評分，這是最準確的測試方法。
但是主觀測試確實很影響效率，這個毋庸置疑，所以業內也有很多人在研究客觀評測的方法，例如PESQ等等，目的是使得這些工具評測的結果更加符合主觀。
再來舉個我們經常提到的一個悖論的例子。我們來說一下回聲抵消的測試。目前我們回聲抵消只有主觀測試的方法，爲什麼呢？回聲抵消算法的關鍵是區分一段語音近端信號和遠端回聲，然後進行消除。我們要測試回聲抵消的效果，那麼就需要一個判斷回聲是否被消除乾淨的算法或工具，咦，這不就是在做回聲抵消嗎？如果我的算法沒有開發的算法好，那我肯定檢查不出來是否有回聲，如果算法比開發的好，那爲啥開發不直接把我的算法用在回聲抵消中呢？
Q：能否告訴我你的測試結果究竟是pass還是fail？
A：能，也不能。音視頻質量的測試從來就不只有0和1的結果。音視頻質量往往是在給定資源情況下的一種權衡結果（參考上面講到的清晰度與流暢度）。所以這裏要明確你的目標是什麼，但這個目標不一定是“正確”的。如果拿捏不準自己的產品音視頻質量是否已經達到最優，通過競品對比分析也是一種很有效的解決方法，這也是很多產品在做性能優化時採用的手段