物理引擎的簡單測試代碼,如果任何一個VTEST條件沒有滿足,那么測試就失敗。該測什么?當(dāng)要決定測試的范圍時,實用第一。一般來說,為簡單的功能編寫單元測試是沒有意義的,比如常見的getter和setter方法。為了讓自動化測試物有 所值,被測試的代碼至少應(yīng)該是可能會產(chǎn)生錯誤的,比如,發(fā)射一束穿透游戲場景的光線并且返回它穿過的任何幾何物體的方法(光線測試),然后將返回的結(jié)果與 編寫測試用例的作者提供的預(yù)期結(jié)果作比較。
到底是只為類的公用 接口編寫測試用例(黑盒測試)還是要兼顧類的私有成員(白盒測試),是一個有爭議的問題。通常來說,黑盒測試比白盒測試粗糙,它們只能檢查一個操作的最終 結(jié)果,不能檢查內(nèi)部中間狀態(tài),它們對于被修改的測試代碼比較遲鈍。剛才提到的光線測試功能可能被全部重寫(比如原先的版本運行效率不夠),但是它返回的結(jié)果沒有變化。這時,白盒測試用例就需要跟著重寫,然而黑盒測試可以繼續(xù)用來檢測代碼修改后,所產(chǎn)生的結(jié)果是否與原先一致。
因此,我們認為自動化測試中,測試范圍只要包括類的公有成員就夠了,畢竟,類的內(nèi)部修改比它接口修改要頻繁得多。
回歸測試
特別是在游戲開發(fā)領(lǐng)域,大多數(shù)情況下,把測試結(jié)果和用例編寫者提供的數(shù)據(jù)手工作比較是不太現(xiàn)實的。例如,檢測與復(fù)雜的幾何體碰撞的交點,人工提供相關(guān)測 試數(shù)據(jù)幾乎不可能。相反,將測試結(jié)果與早期代碼產(chǎn)生的結(jié)果數(shù)據(jù)相比較,被稱為“回歸測試”。用例編寫者可以評審參考數(shù)據(jù),例如,使用簡化圖形的碰撞物體,如果被證實是正確的,它就可以一直用于測試。這樣,自動化測試可以幫助你確認新代碼產(chǎn)生的結(jié)果與原先的一致。
代碼功能測試會生成非常復(fù)雜的輸出數(shù)據(jù),比如游戲的圖形渲染引擎,回歸測試是唯一可行的自動化測試。以圖形渲染引擎為例,所有圖形測試以輸出最終平臺相關(guān)的圖形文件為結(jié)果。一旦自動化測試開始運行,渲染出來的圖形文件與樣本圖形文件逐一像素的進行比較,如果有差異,那么測試失敗。為了減少樣本圖形文件的存占用,你可以使用圖形快照來進行測試。
圖形回歸測試的優(yōu)勢在于即使是肉眼難以發(fā)現(xiàn)的微小差異也不會被漏掉。除非人們對這個場景非常熟悉,否則很難會有人注意到場景中缺失的一個陰影或一個物體或者某個光源的R值與B值被錯換了。而回歸測試就不會放過任何一個這樣的錯誤。
必須注意到,任何情況下,回歸測試的樣本數(shù)據(jù)都是自動生成的。樣本數(shù)據(jù)也許是平臺相關(guān),特別涉及到渲染輸出的時候,因此,它也許要被生成多次,即使是這樣,當(dāng)渲染通道發(fā)生變化導(dǎo)致生成的圖形文件有所改變,樣本數(shù)據(jù)也要重新生成。為了不打擊開發(fā)者編寫回歸測試的積極性,要做到只需點擊框架用戶界面上一個按鈕就可以重新生成新的參考數(shù)據(jù)。
如何把所有的整合在一起
此文章共有6頁 上一頁 1 2 3 4 5 6 下一頁
文章來源:中國項目管理資源網(wǎng)
軟件開發(fā)項目管理培訓(xùn)課程方案
|