數(shù)字電視應(yīng)用平臺的自動化測試設(shè)計(jì)與實(shí)現(xiàn)

莊子健

摘 要：本文從數(shù)字電視應(yīng)用項(xiàng)目的軟件測試實(shí)踐出發(fā)，根據(jù)軟件測試基本原理和系統(tǒng)設(shè)計(jì)用例，選用合適的測試工具制定自動化測試腳本，有效地提高系統(tǒng)回歸測試質(zhì)量，提升回歸測試效率，確保產(chǎn)品質(zhì)量穩(wěn)定。

關(guān)鍵詞：自動化測試腳本；軟件測試；系統(tǒng)設(shè)計(jì)用例

1 引言

隨著軟件產(chǎn)品在各個(gè)應(yīng)用領(lǐng)域的普及，軟件的質(zhì)量問題逐漸成為人們關(guān)注的焦點(diǎn)。質(zhì)量不過關(guān)的軟件產(chǎn)品在使用中可能出現(xiàn)各種意想不到的問題。軟件使用者經(jīng)常發(fā)現(xiàn)一些已經(jīng)推向市場的產(chǎn)品，由于存在嚴(yán)重質(zhì)量缺陷而導(dǎo)致大量退貨，或者一再返工，進(jìn)行長期的修改和維護(hù)。這樣不僅影響了軟件提供商的工作，額外提高了產(chǎn)品成本，也耽誤了客戶業(yè)務(wù)的開展，影響正常工作，甚至?xí)a(chǎn)生嚴(yán)重的或?yàn)?zāi)難性的后果[1]。

本文中的項(xiàng)目產(chǎn)品為“TVNow”。TVNow系統(tǒng)是國內(nèi)SeaChange公司針對國內(nèi)市場推出的一套視頻服務(wù)產(chǎn)品，能夠?yàn)榭蛻籼峁?shí)現(xiàn)媒體流點(diǎn)播，錄播，實(shí)時(shí)收看等多種媒體服務(wù)功能的硬件和軟件的架構(gòu)。筆者參與了這個(gè)項(xiàng)目的測試工作，主要負(fù)責(zé)系統(tǒng)中的隨心點(diǎn)播應(yīng)用的測試用例設(shè)計(jì)，測試的管理，測試文檔的維護(hù)，測試環(huán)境的搭建，自動化測試軟件的設(shè)計(jì)與開發(fā)以及ADI測試。

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

2 數(shù)字電視平臺應(yīng)用性需求分析

數(shù)字電視交互業(yè)務(wù)平臺（Back Office）為各個(gè)業(yè)務(wù)的接入提供一個(gè)開放式的平臺，對內(nèi)屏蔽各業(yè)務(wù)系統(tǒng)的差異[2]，對外屏蔽內(nèi)部各種復(fù)雜的業(yè)務(wù)邏輯，為新業(yè)務(wù)的快速接入提供有力的支撐。業(yè)務(wù)平臺層提供認(rèn)證、鑒權(quán)、計(jì)費(fèi)等業(yè)務(wù)控制能力和產(chǎn)品管理、內(nèi)容管理等能力，從而實(shí)現(xiàn)業(yè)務(wù)的可管理性與可運(yùn)營性[3]。

2.1 TVBS系統(tǒng)簡介

本產(chǎn)品的工程實(shí)踐項(xiàng)目“TVBS”是SeaChange公司針對國內(nèi)市場推出的數(shù)字電視解決方案，為客戶提供多種方便、簡捷媒體服務(wù)功能的硬件和軟件的架構(gòu)。TVBS能將媒體提供的廣播節(jié)目錄制到存儲服務(wù)器，提供給數(shù)字機(jī)頂盒和PC客戶端進(jìn)行點(diǎn)播。

TVNow系統(tǒng)可以主要實(shí)現(xiàn)以下三種功能：

2.1.1 隨心點(diǎn)播（Video-on-Demand，VOD）

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

2.1.3 實(shí)時(shí)節(jié)目點(diǎn)播（Pause TV）

一種能讓用戶在電視廣播節(jié)目播送過程中，使用暫停，回放鍵來定格電視畫面和回放電視節(jié)目的點(diǎn)播功能。用戶可以實(shí)時(shí)觀看當(dāng)前播放的電視廣播節(jié)目，并在觀看節(jié)目時(shí)進(jìn)行暫停、回放等流控操作。

2.2 數(shù)字電視平臺功能性需求分析

數(shù)字電視平臺功能決定了系統(tǒng)軟件所要執(zhí)行的任務(wù)。TVBS產(chǎn)品主要有以下功能模塊：OTE接口模塊，OSS接口模塊和Nav接口模塊組成。

2.2.1 OTE接口模塊

需求定義及分析： 從機(jī)頂盒客戶端購買RVOD和促銷中的產(chǎn)品，OTE將會執(zhí)行促銷和優(yōu)惠規(guī)則，然后對用戶發(fā)布tickets，價(jià)格和租賃期限的相關(guān)信息。

用戶通過PO或優(yōu)惠券購買節(jié)目和節(jié)目包，機(jī)頂盒客戶端提交數(shù)據(jù)到OTE，OTE將會根據(jù)優(yōu)惠規(guī)則計(jì)算價(jià)格，發(fā)布tickets或優(yōu)惠券給用戶。

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

返回?cái)?shù)據(jù)是一個(gè)優(yōu)惠列表。OTE將會為每一個(gè)節(jié)目發(fā)布一個(gè)ticket。如果用戶購買一個(gè)節(jié)目包，第一個(gè)ticket將會是節(jié)目包的價(jià)格，其它ticket的價(jià)格為0；如果用戶購買的產(chǎn)品正在促銷買2送1，前兩個(gè)ticket將會是兩個(gè)節(jié)目的價(jià)格，第三個(gè)ticket 價(jià)格為0。測試方法是模擬STB發(fā)送http的請求，根據(jù)設(shè)置不同的參數(shù)，來判斷返回的XML中判斷測試標(biāo)準(zhǔn)，測試環(huán)境要求：Windows 2003 Server， client網(wǎng)絡(luò)連接正常且有自己的IP。

測試點(diǎn)涉及：Device ID，Home ID，Product Offering ID， Coupon ID，Local Entry ID，Entry Type。

測試方法：通過測試頁面驗(yàn)證參數(shù)，在各類參數(shù)中輸入相應(yīng)的數(shù)據(jù)要求。

通過標(biāo)準(zhǔn)：檢查返回?cái)?shù)據(jù)中的參數(shù)，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，機(jī)頂盒下的用戶登錄；User Update password，更新已登錄用戶賬號密碼；Create User，創(chuàng)建新用戶；Add Favorite Item，該操作添加收藏夾節(jié)目到SMS。

它們都有各自的測試點(diǎn)，測試方法和通過標(biāo)準(zhǔn)。

2.2.3 Nav接口模塊

需求定義及分析：List Entry是將指定的導(dǎo)航過程中產(chǎn)生的Entry以文件數(shù)據(jù)方式列出。Entry是一種抽象的數(shù)據(jù)，它可以是PO，Space，View，F(xiàn)older，節(jié)目包，節(jié)目或關(guān)聯(lián)節(jié)目中的任意一種數(shù)據(jù)。

2.3 數(shù)字電視平臺性能需求分析

2.3.1 分析角度

按照成熟的性能測試策略，從前端、服務(wù)端、網(wǎng)絡(luò)幾個(gè)層次來分析。（為以后的測試打下指標(biāo)基礎(chǔ)）前端：并發(fā)用戶數(shù)；服務(wù)端：系統(tǒng)處理能力和硬件選型等；網(wǎng)絡(luò)端：網(wǎng)絡(luò)流量和帶寬。從軟件結(jié)構(gòu)分析，找出可能瓶頸。系統(tǒng)將來是否能夠滿足性能壓力？從軟件系統(tǒng)耗時(shí)功能分析。標(biāo)準(zhǔn)主體數(shù)據(jù)庫維護(hù)平臺：元數(shù)據(jù)樹的瀏覽，因?yàn)樾枰獜亩鄠€(gè)表中構(gòu)建多一個(gè)元數(shù)據(jù)，A市的數(shù)據(jù)量很大，所以應(yīng)該重點(diǎn)測試。數(shù)據(jù)庫結(jié)構(gòu)的創(chuàng)建，需要在數(shù)據(jù)庫中創(chuàng)建實(shí)例和結(jié)構(gòu)，所以耗用時(shí)間長，需要測試。

2.3.2 用戶訪問量

目的：知道最大的并發(fā)用戶數(shù)。

用戶數(shù)：調(diào)查了解和本項(xiàng)目相關(guān)的模塊，OSS、OTE、Nav或TianShan 4個(gè)模塊。以每個(gè)模塊訪問的數(shù)量按500至1000人計(jì)算，乘上4個(gè)模塊，合計(jì)為4000人次。檢查系統(tǒng)需要支持1000×4=4000人次的最大并發(fā)。

到目前為止，如果不在標(biāo)準(zhǔn)主題數(shù)據(jù)庫上面增加別的應(yīng)用，整個(gè)WFES端需要支持4000最大并發(fā)數(shù)。

3 數(shù)字電視平臺自動化測試框架的設(shè)計(jì)與實(shí)現(xiàn)

3.1 自動化測試框架的設(shè)計(jì)

一個(gè)自動化測試項(xiàng)目會有一個(gè)到多個(gè)測試場景（Scenario），而每個(gè)測試場景又會有一個(gè)到多個(gè)測試用例（Test Case）。

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

3.2 自動化測試框架的實(shí)現(xiàn)

3.2.1 數(shù)據(jù)準(zhǔn)備模塊實(shí)現(xiàn)方法

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

3.2.2 主線程組模塊

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

3.2.3 性能測試的實(shí)現(xiàn)

根據(jù)軟件系統(tǒng)耗時(shí)功能分析， 用戶訪問量和系統(tǒng)業(yè)務(wù)量的混合業(yè)務(wù)分析，按照用戶的實(shí)際使用人數(shù)比例來模擬各個(gè)模塊的組合并發(fā)情況?；旌蠘I(yè)務(wù)測試特點(diǎn)是根據(jù)用戶使用系統(tǒng)的情況分成不同的用戶組進(jìn)行并發(fā)，每組的用戶比例要根據(jù)實(shí)際情況來匹配，通常會取各個(gè)相關(guān)模塊最大的并發(fā)用戶數(shù)目進(jìn)行組合。

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

[參考文獻(xiàn)]

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

[2]許永明.IPTV：技術(shù)與應(yīng)用實(shí)踐[M].電子工業(yè)出版社，2006：19～28.

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

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