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

　　編寫友好的測試代碼

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

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

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

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

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

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

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

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

　　自動化測 試可以看作在開發前期投入，在開發過程中贏利。大多數的代碼修改，包括Bug修改，都可能會引入更多問題導致程序宕機。所以，理論上說，一旦代碼有所改變，就必須測試所有可能被影響的代碼。自動化測試無需人工干預就可以完成，它們縮短了開發過程。而且由于自動化測試可以簡單快速的發現修改的代碼是否能有效地運行，因此也就鼓勵開發者優化和改進現有的代碼。

　　對我們來說，自動化測試幫助開發者編寫更穩定和可靠的代碼。哪怕是一開始對它抱有懷疑態度的開發成員也欣賞它所提供早期反饋的特性，在開發過程中，它也可以更早的 發現Bug。開發者的工作壓力和負荷隨著項目的開展日益加大，盡早的發現和解決Bug也可以避免給開發關鍵時期帶來額外的壓力。

　　在開發Vision引擎的時候，我們收集了一些數據來研究為提高代碼穩定性而實施自動化測試的有效性。2001年早期，全部依靠人工測試的引擎第一個 release版本開發完成，盡管我們已經進行了很全面的測試，但是每個月，我們的在線技術支持數據庫依然會收到上百個來自客戶的Bug報告。2001年 9月，我們對已有的引擎功能和新增的特征實施自動化測試。這樣，即使我們現在的工作量很大，開發進展也很正常，每月Bug報告的數量銳減(現在大概是5到10個)。

　　必須強調，這些圖表只是反映了單元測試用例數量和每月Bug數量兩者之間的相互關系，不能將它理解為必然的因果關系。當然，從2001年到2004年，我們在如何編寫健壯的代碼上學到了很多，在這段時間內，開發團隊的人數變動頻頻，但是，這些明顯的差異足以說明穩定性的提升部分歸功于使用了自動化測試。

　　游戲中自動化測試的局限性

　　盡管使用自動化測試對于游戲開發來說獲益匪淺，但是也有其局限之處。顯然，很難用它來測試游戲的平衡性，也不太可能用它來測試游戲性和畫面的美觀性。在這幾年里，我們總結了一些編寫自動化測試的要點，重點如下：

　　*測試最重要的模塊(比如，最復雜和最常用的)。對那些最有可能出問題或者不會破壞原先設計的重構任務進行自動化測試，性價比最高。

　　*當上層功能性測試難以進行的時候，把精力集中在不同的子系統上。例如，你也許不能通過自動化測試來驗證AI系統是否正常工作，但你可以測試當一個怪獸的體力低于一定數值的時候，它是否會“投降”。

　　*用壓力測試來驗證你的代碼的強壯性。如果你的游戲在極端條件下運行的很好，比如，每秒有2000個怪獸出生和死亡，一個場景中同時放入500個有真實物理特性的物體，一幅地圖輪流載入200次，那么玩家作一些異常操作時，宕機的可能性就會小很多。

　　*在修改Bug前，也為它編寫測試用例。這樣的話，可以確保這些Bug在今后的版本中不會重現。

　　*回歸測試。例如，圖像或狀態比較的話，使用指定的測試場景要比使用產品地圖更容易維護。如果你認為測試用產品數據可能會經常變動，那么你最好使用小的測試場景。否則，不斷的生成新的參考數據會使得開發團隊產生疲倦和厭煩的情緒。

　　* 測試用例越簡單越好，不要奢望有非常大的覆蓋面。搭建一個易維護和可擴展的自動化測試是一個長期的任務。一般來說，“底層”代碼，例如算術、碰撞檢測和渲染，更容易進行自動化測試，對于游戲性和完整的游戲測試來說，還是需要經過QA人員親自測試。當然，QA部門的注意力也要從技術轉移到與游戲性相關的問題上去。“到A房間后，因為通風口前面的箱子太高了，所以出不去”這樣的報告就會取代“當我的角色轉動的時候，屏幕上出現了很多扭曲的三角面”。

　　持續集成

　　在一個復雜的軟件項目中引入自動化測試，你會發覺運行它也需要一定的時間，我們看到的一些項目甚至需要幾個小時。如果讓開發者在他們的開發用機上運行的話，測試會完全占用他們的機器，影響工作，那么結果就是他們不去運行測試用例，很顯然，沒有被運行的用例是沒有任何價值的。

　　解決方法就是搭建一臺或多臺專用的自動化測試機。它同時還運行版本管理軟件(Subversion/CVS/Perforce)，一旦發現提交了新代 碼，那么代碼就會被Check out并編譯，測試用例也會自動運行。最后，系統會將測試結果報告以email的形式自動發送給最近提交代碼的開發者。

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