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

　　現在，許多游戲項目要么跳票嚴重，要不就是發布時Bug多多。當然，這樣的現象并不僅存于游戲工業。例如，根據2001Standish集團發表的那份 聲名狼藉的報告“極度混亂”所表述的，70%以上的軟件項目要么被取消，要么嚴重的超時和超支。然而，游戲是軟件開發復雜性的最佳代表，不同技能的人需要 協同工作，這也就是某些人所說的游戲項目中高風險因素所在。

　　軟件項目延期、Bug滿天飛和失敗的原因是多種多樣的，但看起來除了隨產品特性不斷變化之外，測試和品質管理是永恒的問題。以我們的經驗來看，相當多數的游戲開發工作室完全依靠人工的方式來測試游戲引擎、開發工具和游戲代碼，幾乎沒有采用自動化過程測試。很巧，在2002GDC的圓桌會議：游戲中的純軟件工 程，只有18%的與會者表示他們參與的項目采用了自動化測試。

　　在2000年，我們的客戶，當時新成立的中間件公司對我們的3D引擎的穩定性和大量的BUG抱怨頻頻，我們第一次想到了自動化測試。直到那時，每當完成一 個新特征，我們還是依靠人工測試，并且使用這些特征開發出技術演示供市場部使用。我們在徹底分析了情況后得出以下結論，我們的軟件質量問題主要和我們測試 方法有關：

　　*人工測試不夠全面和徹底，因為它僅僅花費了很多時間。 代碼在修改或添加之后，它本應運行預定義的人工測試集來保證修改不會產生新的問題。人工測試花費的時間越來越多，并給開發者帶來挫折感，打擊他們執行測試 的積極性。而且，測試的工作量使得開發者不愿意改進或優化現有的代碼。

　　*當開發者測試他們自己的代碼時，他們總是不愿意(潛意識?)執行最苛刻的測試用例，因此就導致了最有可能出錯之處也是最不可能被全面測試到這樣的情形。

　　因此，我們決定采用自動化測試，從開發一個新SDK部件開始。結果是鼓舞人心的，最終我們把它推廣到所有的SDK部件開發中去。測試框架極限編程，由Kent Beck和Martin Fowler總結的一系列方法和經驗，帶來了自動化測試的流行。一般來說，自動化測試指無需用戶干預，用來驗證軟件產品中的功能子集的代碼和數據。它可以是用來測試某個特定類方法(通常稱為單元測試)，也可以是用來測試程序功能性的集成測試(功能測試)。

　　為了促進自動化測試進程，有許多開源代碼的單元測試框架，比如CPPunit(C++專用)或Nunit(.Net專用)。這些測試框架提供了GUI來 運行測試集并提供測試結果反饋。根據你的項目，也許需要根據你的游戲進行一些額外的功能擴展和自定義，例如支持跨平臺。這些測試框架的內容，一個單元測試 對應一個函數，測試類由多個單元測試組成，并且包含一個開始和結束測試的方法(例如載入和卸載一幅地圖)。這些測試類可以放在分離的執行文件中，例如 DLL文件，也可以與主項目在一起。除此之外，測試類應該存放在產品代碼之外的文件中，這樣的話，他們就可以很方便的從版本發布中移除。

　　物理引擎的簡單測試代碼，如果任何一個VTEST條件沒有滿足，那么測試就失敗。該測什么?當要決定測試的范圍時，實用第一。一般來說，為簡單的功能編寫單元測試是沒有意義的，比如常見的getter和setter方法。為了讓自動化測試物有 所值，被測試的代碼至少應該是可能會產生錯誤的，比如，發射一束穿透游戲場景的光線并且返回它穿過的任何幾何物體的方法(光線測試)，然后將返回的結果與 編寫測試用例的作者提供的預期結果作比較。

　　到底是只為類的公用 接口編寫測試用例(黑盒測試)還是要兼顧類的私有成員(白盒測試)，是一個有爭議的問題。通常來說，黑盒測試比白盒測試粗糙，它們只能檢查一個操作的最終 結果，不能檢查內部中間狀態，它們對于被修改的測試代碼比較遲鈍。剛才提到的光線測試功能可能被全部重寫(比如原先的版本運行效率不夠)，但是它返回的結果沒有變化。這時，白盒測試用例就需要跟著重寫，然而黑盒測試可以繼續用來檢測代碼修改后，所產生的結果是否與原先一致。

　　因此，我們認為自動化測試中，測試范圍只要包括類的公有成員就夠了，畢竟，類的內部修改比它接口修改要頻繁得多。

　　回歸測試

　　特別是在游戲開發領域，大多數情況下，把測試結果和用例編寫者提供的數據手工作比較是不太現實的。例如，檢測與復雜的幾何體碰撞的交點，人工提供相關測 試數據幾乎不可能。相反，將測試結果與早期代碼產生的結果數據相比較，被稱為“回歸測試”。用例編寫者可以評審參考數據，例如，使用簡化圖形的碰撞物體，如果被證實是正確的，它就可以一直用于測試。這樣，自動化測試可以幫助你確認新代碼產生的結果與原先的一致。

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

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

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

　　如何把所有的整合在一起

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

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

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