包括游戲在內(nèi)的所有應(yīng)用,完整的測(cè)試集合包括單元測(cè)試和回歸測(cè)試。單元測(cè)試適合于測(cè)試底層功能性、基礎(chǔ)庫(kù)文件和平臺(tái)類庫(kù)。上層的各種功能特征集成測(cè)試可以使用回歸測(cè)試。根據(jù)結(jié)果,你可以有選擇的重構(gòu)或優(yōu)化你的邏輯或引擎代碼,回歸測(cè)試一旦失敗,你會(huì)馬上發(fā)現(xiàn)出問題的地方,單元測(cè)試失敗可以讓你精確的定位出錯(cuò)之處。
知道代碼被你編寫的自動(dòng)化測(cè)試覆蓋得范圍是非常有好 處的,你可以使用代碼覆蓋率調(diào)查工具(BullseyeCoverage/AQtime)。代碼覆蓋率分析會(huì)告訴你,你的代碼哪些被調(diào)用,也可以提示你測(cè) 試集合中的疏漏之處。測(cè)試覆蓋率應(yīng)該是多少,無(wú)法精確定量,盡管它取決于被測(cè)試的代碼。細(xì)小的方法無(wú)需測(cè)試,調(diào)試用的函數(shù)也不必測(cè)試。并且,幾乎所有的項(xiàng) 目都會(huì)包括一些“死”代碼,也就是不會(huì)被調(diào)用到的代碼,那么,這些代碼自然也不用測(cè)試?偠灾,現(xiàn)實(shí)中,我們見過的使用自動(dòng)化測(cè)試的游戲和中間件項(xiàng)目中 測(cè)試覆蓋率大致是55%到70%。
編寫友好的測(cè)試代碼
必須承認(rèn),并不是所有的代碼都能使用自動(dòng)化測(cè)試。以單元測(cè)試為例,嚴(yán)格的面向?qū)ο,良好的類和函?shù)模塊化封裝設(shè)計(jì)可以大大提高它的測(cè)試效率。類的接口越多,為它編寫的單元測(cè)試就越多。同樣,過多的使用C++的友元也會(huì)增加編寫的難度,甚至無(wú)法為該類編寫(黑盒)單元測(cè)試用例。
在寫代碼的時(shí)候,要時(shí)刻牢記保持良好的測(cè)試性。在開發(fā)過程中,就會(huì)變成可行但是單調(diào)乏味的工作,有時(shí)候它需要很好的結(jié)構(gòu)性。要在游戲開發(fā)中使用,以下幾點(diǎn)必須牢記:
*所有的回歸測(cè)試都取決于明確的行為。比如,使用隨計(jì)算法的尋徑系統(tǒng)可以提供一個(gè)初始化隨機(jī)種子的公共方法使得角色的行動(dòng)決策更復(fù)雜多變。這個(gè)方法在隨后的測(cè)試中可以被用來(lái)確保角色始終選取同樣的路徑。
*同樣,回歸測(cè)試中要避免與幀數(shù)相關(guān)的情況;否則,有真實(shí)物理特性的物體或渲染輸出也許會(huì)和以前的數(shù)據(jù)不同,特別是當(dāng)結(jié)果來(lái)自不同的機(jī)器或者不同的編譯條件(debug 和release)。在測(cè)試時(shí),使用恒定的虛擬幀數(shù)就可以避免這樣的問題。
* 嚴(yán)重依賴于用戶輸入的軟件很難測(cè)試,比如游戲內(nèi)置的編輯系統(tǒng)或者游戲工具。這樣的話,把UI 和邏輯代碼嚴(yán)格的區(qū)分開會(huì)有所幫助。在我們的游戲工具里, UI界面里每個(gè)用戶動(dòng)作會(huì)執(zhí)行一條或多條簡(jiǎn)單的腳本指令。每條腳本指令可以很明確的重現(xiàn)用戶的原意。這樣,測(cè)試用例可以簡(jiǎn)單的執(zhí)行這些指令并且與樣本數(shù)據(jù) 作比較就可以(比如導(dǎo)出地形文件)。
也可以使用GUI捕捉工具來(lái)測(cè)試UI,但我們發(fā)現(xiàn)這并不是個(gè)好辦法。UI會(huì)經(jīng)常改變,哪怕一個(gè)按鈕僅僅移動(dòng)幾個(gè)像素也會(huì)使捕捉軟件失效,GUI捕捉工具也許會(huì)幫倒忙。
關(guān)于測(cè)試的疑問:我們真的可以節(jié)省時(shí)間么?
此文章共有6頁(yè) 上一頁(yè) 1 2 3 4 5 6 下一頁(yè)
文章來(lái)源:中國(guó)項(xiàng)目管理資源網(wǎng)
軟件開發(fā)項(xiàng)目管理培訓(xùn)課程方案 |