數字電視應用平臺的自動化測試設計與實現

莊子健

摘 要：本文從數字電視應用項目的軟件測試實踐出發，根據軟件測試基本原理和系統設計用例，選用合適的測試工具制定自動化測試腳本，有效地提高系統回歸測試質量，提升回歸測試效率，確保產品質量穩定。

關鍵詞：自動化測試腳本；軟件測試；系統設計用例

1 引言

隨著軟件產品在各個應用領域的普及，軟件的質量問題逐漸成為人們關注的焦點。質量不過關的軟件產品在使用中可能出現各種意想不到的問題。軟件使用者經常發現一些已經推向市場的產品，由于存在嚴重質量缺陷而導致大量退貨，或者一再返工，進行長期的修改和維護。這樣不僅影響了軟件提供商的工作，額外提高了產品成本，也耽誤了客戶業務的開展，影響正常工作，甚至會產生嚴重的或災難性的后果[1]。

本文中的項目產品為“TVNow”。TVNow系統是國內SeaChange公司針對國內市場推出的一套視頻服務產品，能夠為客戶提供實現媒體流點播，錄播，實時收看等多種媒體服務功能的硬件和軟件的架構。筆者參與了這個項目的測試工作，主要負責系統中的隨心點播應用的測試用例設計，測試的管理，測試文檔的維護，測試環境的搭建，自動化測試軟件的設計與開發以及ADI測試。

本課題研究主要從以下幾方面著手：⑴根據TVNow系統的需求設計測試用例。⑵針對測試的特點，開發出一套簡單易用的自動化測試腳本。⑶對整個自動化測試框架流程進行總體設計。⑷TVNow測試文檔的編寫與管理，在整個項目實施過程中，指定項目進度。本項目自動化測試的目標是：提升工作效率50%，加快測試進度50%，控制產品的bug數量在上一個版本中bug數量的50%以下。

2 數字電視平臺應用性需求分析

數字電視交互業務平臺（Back Office）為各個業務的接入提供一個開放式的平臺，對內屏蔽各業務系統的差異[2]，對外屏蔽內部各種復雜的業務邏輯，為新業務的快速接入提供有力的支撐。業務平臺層提供認證、鑒權、計費等業務控制能力和產品管理、內容管理等能力，從而實現業務的可管理性與可運營性[3]。

2.1 TVBS系統簡介

本產品的工程實踐項目“TVBS”是SeaChange公司針對國內市場推出的數字電視解決方案，為客戶提供多種方便、簡捷媒體服務功能的硬件和軟件的架構。TVBS能將媒體提供的廣播節目錄制到存儲服務器，提供給數字機頂盒和PC客戶端進行點播。

TVNow系統可以主要實現以下三種功能：

2.1.1 隨心點播（Video-on-Demand，VOD）

2.1.2 隨心錄像（Network Personal Video Recorder，NPVR）

2.1.3 實時節目點播（Pause TV）

一種能讓用戶在電視廣播節目播送過程中，使用暫停，回放鍵來定格電視畫面和回放電視節目的點播功能。用戶可以實時觀看當前播放的電視廣播節目，并在觀看節目時進行暫停、回放等流控操作。

2.2 數字電視平臺功能性需求分析

數字電視平臺功能決定了系統軟件所要執行的任務。TVBS產品主要有以下功能模塊：OTE接口模塊，OSS接口模塊和Nav接口模塊組成。

2.2.1 OTE接口模塊

需求定義及分析： 從機頂盒客戶端購買RVOD和促銷中的產品，OTE將會執行促銷和優惠規則，然后對用戶發布tickets，價格和租賃期限的相關信息。

用戶通過PO或優惠券購買節目和節目包，機頂盒客戶端提交數據到OTE，OTE將會根據優惠規則計算價格，發布tickets或優惠券給用戶。

如果用戶是通過PO購買產品的，需要product offering id；如果用戶是通過優惠券購買產品的，需要coupon id。該操作保證售出的產品可以播放并使用相應的促銷或優惠券。

返回數據是一個優惠列表。OTE將會為每一個節目發布一個ticket。如果用戶購買一個節目包，第一個ticket將會是節目包的價格，其它ticket的價格為0；如果用戶購買的產品正在促銷買2送1，前兩個ticket將會是兩個節目的價格，第三個ticket 價格為0。測試方法是模擬STB發送http的請求，根據設置不同的參數，來判斷返回的XML中判斷測試標準，測試環境要求：Windows 2003 Server， client網絡連接正常且有自己的IP。

測試點涉及：Device ID，Home ID，Product Offering ID， Coupon ID，Local Entry ID，Entry Type。

測試方法：通過測試頁面驗證參數，在各類參數中輸入相應的數據要求。

通過標準：檢查返回數據中的參數，Transaction ID， Product Type，Transaction Time，Ticket ID，Ticket Type，Buy From，Price，Purchase Time，Effective Time， Expiration Time， View Status

2.2.2 OSS接口模塊

含有User Login，機頂盒下的用戶登錄；User Update password，更新已登錄用戶賬號密碼；Create User，創建新用戶；Add Favorite Item，該操作添加收藏夾節目到SMS。

它們都有各自的測試點，測試方法和通過標準。

2.2.3 Nav接口模塊

需求定義及分析：List Entry是將指定的導航過程中產生的Entry以文件數據方式列出。Entry是一種抽象的數據，它可以是PO，Space，View，Folder，節目包，節目或關聯節目中的任意一種數據。

2.3 數字電視平臺性能需求分析

2.3.1 分析角度

按照成熟的性能測試策略，從前端、服務端、網絡幾個層次來分析。（為以后的測試打下指標基礎）前端：并發用戶數；服務端：系統處理能力和硬件選型等；網絡端：網絡流量和帶寬。從軟件結構分析，找出可能瓶頸。系統將來是否能夠滿足性能壓力？從軟件系統耗時功能分析。標準主體數據庫維護平臺：元數據樹的瀏覽，因為需要從多個表中構建多一個元數據，A市的數據量很大，所以應該重點測試。數據庫結構的創建，需要在數據庫中創建實例和結構，所以耗用時間長，需要測試。

2.3.2 用戶訪問量

目的：知道最大的并發用戶數。

用戶數：調查了解和本項目相關的模塊，OSS、OTE、Nav或TianShan 4個模塊。以每個模塊訪問的數量按500至1000人計算，乘上4個模塊，合計為4000人次。檢查系統需要支持1000×4=4000人次的最大并發。

到目前為止，如果不在標準主題數據庫上面增加別的應用，整個WFES端需要支持4000最大并發數。

3 數字電視平臺自動化測試框架的設計與實現

3.1 自動化測試框架的設計

一個自動化測試項目會有一個到多個測試場景（Scenario），而每個測試場景又會有一個到多個測試用例（Test Case）。

自動化測試配置到每個測試用例上，每個Scenario便包含了這些測試用例的載體，其本身不包含任何數據。

3.2 自動化測試框架的實現

3.2.1 數據準備模塊實現方法

數據準備模塊是整個自動化測試框架的執行入口，它需要為整個執行過程完成一個良好的鋪墊，所以執行模塊不僅包括了執行所有用例本身，還需要負責完成包括執行之前的一系列動作。

3.2.2 主線程組模塊

測試腳本主線程組模塊的主要方法包括：瀏覽節目，訂錄并購買節目，點播節目。

3.2.3 性能測試的實現

根據軟件系統耗時功能分析， 用戶訪問量和系統業務量的混合業務分析，按照用戶的實際使用人數比例來模擬各個模塊的組合并發情況。混合業務測試特點是根據用戶使用系統的情況分成不同的用戶組進行并發，每組的用戶比例要根據實際情況來匹配，通常會取各個相關模塊最大的并發用戶數目進行組合。

按照性能測試設計定義的每個模塊1000人次訪問并發量，配500個線程，單位1秒內遞增，共計循環2次。⑴通過新建一個Test Plan，設置Thread Group。⑵設2個頁面接受模擬訪問，如OSS和OTE頁面。⑶添加幾個關鍵**，如Aggregate Graph、Graph Results、Summary Report、View Results in Table、View Results Tree等。

[參考文獻]

[1]William E.Perry.軟件測試的有效方法[M].清華大學出版社， 2008：20～200頁.

[2]許永明.IPTV：技術與應用實踐[M].電子工業出版社，2006：19～28.

[3]盧官明，宗昉.IPTV技術及應用[M].人民郵電出版社，2007：10～245頁.

[4]崔啟亮，胡一鳴.國際化軟件測試[M].電子工業出版社，2006：13～27頁.