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