游戲項目中的自動化測試和持續集成[2]

　　游戲項目中的自動化測試和持續集成[2]   軟件測試

　　代碼功能測試會生成非常復雜的輸出數據，比如游戲的圖形渲染引擎，回歸測試是唯一可行的自動化測試。以圖形渲染引擎為例，所有圖形測試以輸出最終平臺相關的圖形文件為結果。一旦自動化測試開始運行，渲染出來的圖形文件與樣本圖形文件逐一像素的進行比較，如果有差異，那么測試失敗。為了減少樣本圖形文件的存占用，你可以使用圖形快照來進行測試。

　　圖形回歸測試的優勢在于即使是肉眼難以發現的微小差異也不會被漏掉。除非人們對這個場景非常熟悉，否則很難會有人注意到場景中缺失的一個陰影或一個物體或者某個光源的R值與B值被錯換了。而回歸測試就不會放過任何一個這樣的錯誤。

　　必須注意到，任何情況下，回歸測試的樣本數據都是自動生成的。樣本數據也許是平臺相關，特別涉及到渲染輸出的時候，因此，它也許要被生成多次，即使是這樣，當渲染通道發生變化導致生成的圖形文件有所改變，樣本數據也要重新生成。為了不打擊開發者編寫回歸測試的積極性，要做到只需點擊框架用戶界面上一個按鈕就可以重新生成新的參考數據。

　　如何把所有的整合在一起

　　包括游戲在內的所有應用，完整的測試集合包括單元測試和回歸測試。單元測試適合于測試底層功能性、基礎庫文件和平臺類庫。上層的各種功能特征集成測試可以使用回歸測試。根據結果，你可以有選擇的重構或優化你的邏輯或引擎代碼，回歸測試一旦失敗，你會馬上發現出問題的地方，單元測試失敗可以讓你精確的定位出錯之處。

　　知道代碼被你編寫的自動化測試覆蓋得范圍是非常有好 處的，你可以使用代碼覆蓋率調查工具(BullseyeCoverage/AQtime)。代碼覆蓋率分析會告訴你，你的代碼哪些被調用，也可以提示你測 試集合中的疏漏之處。測試覆蓋率應該是多少，無法精確定量，盡管它取決于被測試的代碼。細小的方法無需測試，調試用的函數也不必測試。并且，幾乎所有的項 目都會包括一些“死”代碼，也就是不會被調用到的代碼，那么，這些代碼自然也不用測試?？偠灾?，現實中，我們見過的使用自動化測試的游戲和中間件項目中 測試覆蓋率大致是55%到70%。

　　編寫友好的測試代碼

　　必須承認，并不是所有的代碼都能使用自動化測試。以單元測試為例，嚴格的面向對象，良好的類和函數模塊化封裝設計可以大大提高它的測試效率。類的接口越多，為它編寫的單元測試就越多。同樣，過多的使用C++的友元也會增加編寫的難度，甚至無法為該類編寫(黑盒)單元測試用例。

　　在寫代碼的時候，要時刻牢記保持良好的測試性。在開發過程中，就會變成可行但是單調乏味的工作，有時候它需要很好的結構性。要在游戲開發中使用，以下幾點必須牢記：

　　*所有的回歸測試都取決于明確的行為。比如，使用隨計算法的尋徑系統可以提供一個初始化隨機種子的公共方法使得角色的行動決策更復雜多變。這個方法在隨后的測試中可以被用來確保角色始終選取同樣的路徑。

　　*同樣，回歸測試中要避免與幀數相關的情況;否則，有真實物理特性的物體或渲染輸出也許會和以前的數據不同，特別是當結果來自不同的機器或者不同的編譯條件(debug 和release)。在測試時，使用恒定的虛擬幀數就可以避免這樣的問題。

　　* 嚴重依賴于用戶輸入的軟件很難測試，比如游戲內置的編輯系統或者游戲工具。這樣的話，把UI 和邏輯代碼嚴格的區分開會有所幫助。在我們的游戲工具里， UI界面里每個用戶動作會執行一條或多條簡單的腳本指令。每條腳本指令可以很明確的重現用戶的原意。這樣，測試用例可以簡單的執行這些指令并且與樣本數據 作比較就可以(比如導出地形文件)。

　　也可以使用GUI捕捉工具來測試UI，但我們發現這并不是個好辦法。UI會經常改變，哪怕一個按鈕僅僅移動幾個像素也會使捕捉軟件失效，GUI捕捉工具也許會幫倒忙。

　　關于測試的疑問：我們真的可以節省時間么?

　　多數情況下，一個開發團隊想要在開發過程中使用自動化測試，大多數成員都會對它抱以質疑的態度。畢竟，與其花這點時間寫測試用例，還不如去寫邏輯和引擎 的代碼。根據我們在游戲和其他領域的工作中使用自動化測試的經驗來看，編寫測試代碼會額外增加30%工作量。初看，在時間和資金上這也許是很大的開銷，然而，你要意識到這樣做，省去了人工測試所花費的時間。

原文轉自：http://www.anti-gravitydesign.com