流媒體服務器的自動測試系統
引言
目前,隨著移動增值業務的快速發展和第三代數字通信技術的實施,移動增值業務已經不再僅僅局限于短信、彩信、彩鈴等窄帶業務,用戶對于在移動網絡環境下點播和觀看視頻的需求越來越迫切。流媒體技術作為在互聯網上實時傳輸音、視頻的主要方式,成為一種在數據網絡上傳遞多媒體視頻數據的主流技術。如此,流媒體服務系統對于作為承載多媒體基本業務的流媒體服務器的評估也顯得由為重要。
當前的流媒體系統包含了多種網絡接入方式,多種軟件體系架構,及多種應用場景如電視會議系統、網絡電視(IPTV)系統等。如何有效的測量各種系統所提 供的視頻業務支撐能力就成為一個有待研究的問題,此類問題直接關系到各流媒體系統的優越性、實用性以及其重大革新意義的展現。并且當前的各個流媒體系統都 面臨不斷升級的需求,對于系統升級前后的兼容性、一致性也需要給出評價。
由于音頻、視頻信號很難量化表示,目前對流媒體服務器的測試方法一般還是通過人工“察言觀色”的方式完成,即測試人員通過STB (Set-Top-Box,機頂盒) 或Web頁面與流媒體服務器建立連接,由測試人員發起測試,并對測試結果進行主觀判斷,分析系統的工作情況。但是由人工來測試工作量將非常大,并且人工測試也很難提取服務器的各種性能響應參數,驗證檢查力度不夠,測試有效性低,不夠全面,可維護和可擴展性差,測試效果不理想。
這里列舉幾個常見的問題實例:
1、手工測試過程中,大量的精力花在輸入數據、執行測試用例,監聽觀看系統的音視頻輸出是否正常上,無法集中精力到關鍵問題,如提高測試的有效性,編寫更多更好的測試用例等。
2、由于采用人工判斷的方式,所以無法對系統的性能指標進行量化分析。
3、測試工作中許多操作是重復性的、非智力性的和非創造性的,并要求準確細致地完成,對于重復性手工測試很難保證每一次測試的效率與有效性。
4、如果有大量(如幾千)的測試用例,需要在短時間內(如1天)完成,手工測試幾乎不可能做到
為解決手工測試存在的問題,我們很自然的就想到了自動化測試。自動化測試的優點有很多,如快速、可靠、可重復性、可重用性等等,這些優點使得自動化測試在流媒體服務器測試過程中的地位不斷提高,成為評價流媒體服務器的重要方法。
本文研究的主題就是如何設計實現針對流媒體服務器的自動化測試系統,達到快速量化的判定流媒體系統的目的。該測試系統包括以下內容:
● 流媒體操作功能測試;
● 流媒體數據有效性正確性驗證;
● 流媒體系統性能測試。
流媒體技術概述及研究現狀
在流媒體(Streaming Media)技術出現之前,人們若想從網絡上觀看影片,必須先將影視文件下載到本地,然后才可進行播放。流媒體技術的出現客服了這個限制,它可以讓用戶不 需要將整個影音文件下載到用戶機器,而是一邊下載一邊播放。所以流媒體是指在數據網絡上按時間先后次序傳輸和播放的連續音、視頻數據流。流媒體數據流具有 3個特點:連續性、實時性、時序性,即其數據流具有嚴格的前后時序關系。這種提供一邊下載一邊播放的服務系統稱為流媒體服務系統。所以對于流媒體服務系統 的評價需要測試系統的數據延時,丟包率,比特率等指標;不僅如此為不斷提升移動環境下流媒體業務的服務質量,需要通過不斷提升服務器能力,提升終端能力, 增加傳輸和編碼效率等辦法來多方面地提升整個移動流媒體系統的性能。而提升系統性能的前提是對目前系統性能可以進行準確地測試和評價。
目前,對流媒體服務器的測試多關注與流媒體服務器的性能測試。流媒體服務器性能測試指標主要有最大并發流數目、帶寬波動、丟包率和平均響應時間等,其中最 大并發流數目是關注的最多的。最大并發流數目是指流媒體服務器能夠支持的有效的、能夠同時在線正常觀看節目的最大用戶數目。
……………………
查看全文請點擊下載:http://www.51testing.com/html/56/n-811856.html
3.3 RTP流的測試
流媒體服務器通過RTP協議封裝音頻和視頻流。流媒體自動化測試系統通過捕獲發送的RTP流并分析這些RTP流來判斷流媒體服務器的性能。
RTP流中封裝的是流媒體服務所需的音頻流和視頻流,其中音視頻都是通過特定的壓縮技術對音視頻流進行編碼,目前視頻流傳輸中最為重要的編解碼標準有國 際電聯的H.261、H.263,運動靜止圖像專家組的M-JPEG和國際標準化組織運動圖像專家組的MPEG系列標準。這些標準都采用幀作為每一幅畫面 的單位,為了支持多種協議的編碼格式,本文論述的流媒體自動化測試系統不直接按照各種協議分析幀數據,而是對所有的協議采用統一的處理方法,這樣增加了測 試系統的通用性。
具體的方法,按照PTS建立每一幀的索引,對每一幀的數據應用MD5算法產生信息摘要;然后對接收的媒體流與預存的媒體流中相同幀進行一次MD5校驗,從而得出結論當前幀是否完全。
RTP流中另一個重要的指標為丟包率,由于流媒體服務器需要經過對流媒體數據的編碼和加密后將數據壓縮到RTP數據包中,所以測試系統無法從簡單的統計RTP包的個數中得到丟包率。本文論述的流媒體自動化測試系統根據RTP流中每個RTP包必須順序傳送來計算丟包率。
具體的方法,根據當前RTP包的序號判斷下一個RTP包的序號,如果RTP包的序號不符合,則丟包加一;然后在根據新的RTP包的序號判斷下一個RTP 包的序號。在數據流結束時,根據丟包數與總的RTP包數計算丟包率。這樣丟包率數據同時也可以反映數據傳輸的亂序問題。
級別 | 功能 | 粒度 |
活躍級 | 檢查RTP包的延時,丟包率,比特率等基本信息 | 基本 |
探測級 | 需設定采樣率;除統計活躍級的信息外,還需要按照采樣率分析關鍵幀的數據。 | 較詳細 |
完整級 | 除統計活躍級的信息外,還要對所有的幀進行分析。 | 詳細 |
3.4 性能測試
性能測試主要是測試被測的流媒體服務器在預期用戶量或者打用戶量情況下系統的穩定性、可靠性和響應時間。本測試系統通過逐漸增加并發流的數目的方法觀察各個性能參數的變化從而得出服務器的最大服務能力。
目前本測試系統對于流媒體服務器的性能參數定義如下:
1)最大并發流數目:流媒體服務器可以長時間支持的客戶端數目。
2)聚合輸出帶寬:流媒體服務器發送的總的帶寬。
3)請求響應時延:從用戶發出RTSP點播開始到接收第一個RTP數據包之間的時間間隔。
4)丟包率:客戶端接收到的不連續的數據包的比率。
測試系統通過多線程的客戶端以及可以配置多個客戶端這些靈活的方案實現對流媒體服務器的測試。
4、流媒體自動化測試系統實現
4.1 測試服務器的實現
本文所述的測試服務器完成測試任務的管理與測試數據的統計分析工作。它由主線程、調度線程、配置線程、定時線程和輸 出線程組成。主線程完成其他線程的創建工作,然后輪詢是否有新的任務,如果監測到新的任務,交由配置線程讀取新任務的各種配置參數。調度線程負責將新的測 試任務分配給某個測試客戶端進行執行。定時線程會定時觸發分析線程讀取測試客戶端送上來的測試結果進行分析。最后交由輸出線程保存測試結果的磁盤文件中。
分析線程需要根據測試任務的需要根據不同的測試級別進行分析,當進行完整級的測試分析時會消耗較大的CPU與內存資源,所以使用時間片強制使得分析線程讓出系統資源使得測試服務器可以響應外部的輸入,并且可以使用定時器使得分析線程在特定的時間繼續分析測試數據。
測試服務器的內部線程實現如下圖所示
……………………
查看全文請點擊下載:http://www.51testing.com/html/56/n-811856.html
4.3 自動化測試系統的部署
本文所述的流媒體自動化測試系統,基于測試服務器與測試客戶端的實現,能夠支持分布式的部署。在具體部署測試時,可以根據測試的流媒體服務器的能力進行靈活的部署配置。
當測試的流媒體服務器系統可以支持多臺服務器同時提供流媒體服務,可以將測試服務器與測試客戶端部署在不同的硬件服務器,并且可以部署多個測試 客戶端用于測試不同的服務器。當測試的流媒體服務器為單服務器或者提供的并發負載能力較低時,可以將測試服務器與測試客戶端部署在同一個硬件服務器。由于 單個測試客戶端就可以支持與多個流媒體服務器建立流媒體服務會話連接,所以一般情況下,單臺測試服務器就可以支持對含有多個流媒體服務器的流媒體服務系統 進行測試。
……
查看全文請點擊下載:http://www.51testing.com/html/56/n-811856.html
本文收錄于《51測試天地》電子雜志第二十五期。
版權聲明:本文出自51Testing軟件測試網電子雜志——《51測試天地》第二十五期。51Testing軟件測試網及相關內容提供者擁有51testing.com內容的全部版權,未經明確的書面許可,任何人或單位不得對本網站內容復制、轉載或進行鏡像,否則將追究法律責任