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