現(xiàn)在，許多游戲項目要么跳票嚴重，要不就是發(fā)布時Bug多多。當然，這樣的現(xiàn)象并不僅存于游戲工業(yè)。例如，根據(jù)2001Standish集團發(fā)表的那份 聲名狼藉的報告“極度混亂”所表述的，70%以上的軟件項目要么被取消，要么嚴重的超時和超支。然而，游戲是軟件開發(fā)復(fù)雜性的最佳代表，不同技能的人需要 協(xié)同工作，這也就是某些人所說的游戲項目中高風(fēng)險因素所在。
軟件項目延期、Bug滿天飛和失敗的原因是多種多樣的，但看起來除了隨產(chǎn)品特性不斷變化之外，測試和品質(zhì)管理是永恒的問題。以我們的經(jīng)驗來看，相當多數(shù)的游戲開發(fā)工作室完全依靠人工的方式來測試游戲引擎、開發(fā)工具和游戲代碼，幾乎沒有采用自動化過程測試。很巧，在2002GDC的圓桌會議：游戲中的純軟件工 程，只有18%的與會者表示他們參與的項目采用了自動化測試。
在2000年，我們的客戶，當時新成立的中間件公司對我們的3D引擎的穩(wěn)定性和大量的BUG抱怨頻頻，我們第一次想到了自動化測試。直到那時，每當完成一 個新特征，我們還是依靠人工測試，并且使用這些特征開發(fā)出技術(shù)演示供市場部使用。我們在徹底分析了情況后得出以下結(jié)論，我們的軟件質(zhì)量問題主要和我們測試 方法有關(guān)：
*人工測試不夠全面和徹底，因為它僅僅花費了很多時間。 代碼在修改或添加之后，它本應(yīng)運行預(yù)定義的人工測試集來保證修改不會產(chǎn)生新的問題。人工測試花費的時間越來越多，并給開發(fā)者帶來挫折感，打擊他們執(zhí)行測試 的積極性。而且，測試的工作量使得開發(fā)者不愿意改進或優(yōu)化現(xiàn)有的代碼。
*當開發(fā)者測試他們自己的代碼時，他們總是不愿意（潛意識？）執(zhí)行最苛刻的測試用例，因此就導(dǎo)致了最有可能出錯之處也是最不可能被全面測試到這樣的情形。
因此，我們決定采用自動化測試，從開發(fā)一個新SDK部件開始。結(jié)果是鼓舞人心的，最終我們把它推廣到所有的SDK部件開發(fā)中去。測試框架極限編程，由Kent Beck和Martin Fowler總結(jié)的一系列方法和經(jīng)驗，帶來了自動化測試的流行。一般來說，自動化測試指無需用戶干預(yù)，用來驗證軟件產(chǎn)品中的功能子集的代碼和數(shù)據(jù)。它可以是用來測試某個特定類方法（通常稱為單元測試），也可以是用來測試程序功能性的集成測試（功能測試）。
為了促進自動化測試進程，有許多開源代碼的單元測試框架，比如CPPunit（C++專用）或Nunit（.Net專用）。這些測試框架提供了GUI來 運行測試集并提供測試結(jié)果反饋。根據(jù)你的項目，也許需要根據(jù)你的游戲進行一些額外的功能擴展和自定義，例如支持跨平臺。這些測試框架的內(nèi)容，一個單元測試 對應(yīng)一個函數(shù)，測試類由多個單元測試組成，并且包含一個開始和結(jié)束測試的方法（例如載入和卸載一幅地圖）。這些測試類可以放在分離的執(zhí)行文件中，例如 DLL文件，也可以與主項目在一起。除此之外，測試類應(yīng)該存放在產(chǎn)品代碼之外的文件中，這樣的話，他們就可以很方便的從版本發(fā)布中移除。
此文章共有6頁 1 2 3 4 5 6 下一頁
文章來源：中國項目管理資源網(wǎng)
 軟件開發(fā)項目管理培訓(xùn)課程方案
|
Leadge.com首頁 > 知識庫 
