|
51cmm (2005-06-16 11:25:38)
現(xiàn)在，許多游戲項(xiàng)目要么跳票嚴(yán)重，要不就是發(fā)布時(shí)Bug多多。當(dāng)然，這樣的現(xiàn)象并不僅存于游戲工業(yè)。例如，根據(jù)2001Standish集團(tuán)發(fā)表的那份聲名狼藉的報(bào)告“極度混亂”所表述的，70%以上的軟件項(xiàng)目要么被取消，要么嚴(yán)重的超時(shí)和超支。然而，游戲是軟件開發(fā)復(fù)雜性的最佳代表，不同技能的人需要協(xié)同工作，這也就是某些人所說的游戲項(xiàng)目中高風(fēng)險(xiǎn)因素所在。 軟件項(xiàng)目延期、Bug滿天飛和失敗的原因是多種多樣的，但看起來除了隨產(chǎn)品特性不斷變化之外，測(cè)試和品質(zhì)管理是永恒的問題。以我們的經(jīng)驗(yàn)來看，相當(dāng)多數(shù)的游戲開發(fā)工作室完全依靠人工的方式來測(cè)試游戲引擎、開發(fā)工具和游戲代碼，幾乎沒有采用自動(dòng)化過程測(cè)試。很巧，在2002GDC的圓桌會(huì)議：游戲中的純軟件工程，只有18%的與會(huì)者表示他們參與的項(xiàng)目采用了自動(dòng)化測(cè)試。 在2000年，我們的客戶，當(dāng)時(shí)新成立的中間件公司對(duì)我們的3D引擎的穩(wěn)定性和大量的BUG抱怨頻頻，我們第一次想到了自動(dòng)化測(cè)試。直到那時(shí)，每當(dāng)完成一個(gè)新特征，我們還是依靠人工測(cè)試，并且使用這些特征開發(fā)出技術(shù)演示供市場(chǎng)部使用。我們?cè)趶氐追治隽饲闆r后得出以下結(jié)論，我們的軟件質(zhì)量問題主要和我們測(cè)試方法有關(guān)： *人工測(cè)試不夠全面和徹底，因?yàn)樗鼉H僅花費(fèi)了很多時(shí)間。代碼在修改或添加之后，它本應(yīng)運(yùn)行預(yù)定義的人工測(cè)試集來保證修改不會(huì)產(chǎn)生新的問題。人工測(cè)試花費(fèi)的時(shí)間越來越多，并給開發(fā)者帶來挫折感，打擊他們執(zhí)行測(cè)試的積極性。而且，測(cè)試的工作量使得開發(fā)者不愿意改進(jìn)或優(yōu)化現(xiàn)有的代碼。 *當(dāng)開發(fā)者測(cè)試他們自己的代碼時(shí)，他們總是不愿意（潛意識(shí)？）執(zhí)行最苛刻的測(cè)試用例，因此就導(dǎo)致了最有可能出錯(cuò)之處也是最不可能被全面測(cè)試到這樣的情形。 因此，我們決定采用自動(dòng)化測(cè)試，從開發(fā)一個(gè)新SDK部件開始。結(jié)果是鼓舞人心的，最終我們把它推廣到所有的SDK部件開發(fā)中去。測(cè)試框架極限編程，由Kent Beck和Martin Fowler總結(jié)的一系列方法和經(jīng)驗(yàn)，帶來了自動(dòng)化測(cè)試的流行。一般來說，自動(dòng)化測(cè)試指無需用戶干預(yù)，用來驗(yàn)證軟件產(chǎn)品中的功能子集的代碼和數(shù)據(jù)。它可以是用來測(cè)試某個(gè)特定類方法（通常稱為單元測(cè)試），也可以是用來測(cè)試程序功能性的集成測(cè)試（功能測(cè)試）。 為了促進(jìn)自動(dòng)化測(cè)試進(jìn)程，有許多開源代碼的單元測(cè)試框架，比如CPPunit（C++專用）或Nunit（.Net專用）。這些測(cè)試框架提供了GUI來運(yùn)行測(cè)試集并提供測(cè)試結(jié)果反饋。根據(jù)你的項(xiàng)目，也許需要根據(jù)你的游戲進(jìn)行一些額外的功能擴(kuò)展和自定義，例如支持跨平臺(tái)。這些測(cè)試框架的內(nèi)容，一個(gè)單元測(cè)試對(duì)應(yīng)一個(gè)函數(shù)，測(cè)試類由多個(gè)單元測(cè)試組成，并且包含一個(gè)開始和結(jié)束測(cè)試的方法（例如載入和卸載一幅地圖）。這些測(cè)試類可以放在分離的執(zhí)行文件中，例如 DLL文件，也可以與主項(xiàng)目在一起。除此之外，測(cè)試類應(yīng)該存放在產(chǎn)品代碼之外的文件中，這樣的話，他們就可以很方便的從版本發(fā)布中移除。 物理引擎的簡單測(cè)試代碼，如果任何一個(gè)VTEST條件沒有滿足，那么測(cè)試就失敗。該測(cè)什么？當(dāng)要決定測(cè)試的范圍時(shí)，實(shí)用第一。一般來說，為簡單的功能編寫單元測(cè)試是沒有意義的，比如常見的 getter和setter方法。為了讓自動(dòng)化測(cè)試物有所值，被測(cè)試的代碼至少應(yīng)該是可能會(huì)產(chǎn)生錯(cuò)誤的，比如，發(fā)射一束穿透游戲場(chǎng)景的光線并且返回它穿過的任何幾何物體的方法（光線測(cè)試），然后將返回的結(jié)果與編寫測(cè)試用例的作者提供的預(yù)期結(jié)果作比較。 到底是只為類的公用接口編寫測(cè)試用例（黑盒測(cè)試）還是要兼顧類的私有成員（白盒測(cè)試），是一個(gè)有爭議的問題。通常來說，黑盒測(cè)試比白盒測(cè)試粗糙，它們只能檢查一個(gè)操作的最終結(jié)果，不能檢查內(nèi)部中間狀態(tài)，它們對(duì)于被修改的測(cè)試代碼比較遲鈍。剛才提到的光線測(cè)試功能可能被全部重寫（比如原先的版本運(yùn)行效率不夠），但是它返回的結(jié)果沒有變化。這時(shí)，白盒測(cè)試用例就需要跟著重寫，然而黑盒測(cè)試可以繼續(xù)用來檢測(cè)代碼修改后，所產(chǎn)生的結(jié)果是否與原先一致。 因此，我們認(rèn)為自動(dòng)化測(cè)試中，測(cè)試范圍只要包括類的公有成員就夠了，畢竟，類的內(nèi)部修改比它接口修改要頻繁得多。 回歸測(cè)試 特別是在游戲開發(fā)領(lǐng)域，大多數(shù)情況下，把測(cè)試結(jié)果和用例編寫者提供的數(shù)據(jù)手工作比較是不太現(xiàn)實(shí)的。例如，檢測(cè)與復(fù)雜的幾何體碰撞的交點(diǎn)，人工提供相關(guān)測(cè)試數(shù)據(jù)幾乎不可能。相反，將測(cè)試結(jié)果與早期代碼產(chǎn)生的結(jié)果數(shù)據(jù)相比較，被稱為“回歸測(cè)試”。用例編寫者可以評(píng)審參考數(shù)據(jù)，例如，使用簡化圖形的碰撞物體，如果被證實(shí)是正確的，它就可以一直用于測(cè)試。這樣，自動(dòng)化測(cè)試可以幫助你確認(rèn)新代碼產(chǎn)生的結(jié)果與原先的一致。 代碼功能測(cè)試會(huì)生成非常復(fù)雜的輸出數(shù)據(jù)，比如游戲的圖形渲染引擎，回歸測(cè)試是唯一可行的自動(dòng)化測(cè)試。以圖形渲染引擎為例，所有圖形測(cè)試以輸出最終平臺(tái)相關(guān)的圖形文件為結(jié)果。一旦自動(dòng)化測(cè)試開始運(yùn)行，渲染出來的圖形文件與樣本圖形文件逐一像素的進(jìn)行比較，如果有差異，那么測(cè)試失敗。為了減少樣本圖形文件的存占用，你可以使用圖形快照來進(jìn)行測(cè)試。 圖形回歸測(cè)試的優(yōu)勢(shì)在于即使是肉眼難以發(fā)現(xiàn)的微小差異也不會(huì)被漏掉。除非人們對(duì)這個(gè)場(chǎng)景非常熟悉，否則很難會(huì)有人注意到場(chǎng)景中缺失的一個(gè)陰影或一個(gè)物體或者某個(gè)光源的R值與B值被錯(cuò)換了。而回歸測(cè)試就不會(huì)放過任何一個(gè)這樣的錯(cuò)誤。 必須注意到，任何情況下，回歸測(cè)試的樣本數(shù)據(jù)都是自動(dòng)生成的。樣本數(shù)據(jù)也許是平臺(tái)相關(guān)，特別涉及到渲染輸出的時(shí)候，因此，它也許要被生成多次，即使是這樣，當(dāng)渲染通道發(fā)生變化導(dǎo)致生成的圖形文件有所改變，樣本數(shù)據(jù)也要重新生成。為了不打擊開發(fā)者編寫回歸測(cè)試的積極性，要做到只需點(diǎn)擊框架用戶界面上一個(gè)按鈕就可以重新生成新的參考數(shù)據(jù)。 如何把所有的整合在一起 包括游戲在內(nèi)的所有應(yīng)用，完整的測(cè)試集合包括單元測(cè)試和回歸測(cè)試。單元測(cè)試適合于測(cè)試底層功能性、基礎(chǔ)庫文件和平臺(tái)類庫。上層的各種功能特征集成測(cè)試可以使用回歸測(cè)試。根據(jù)結(jié)果，你可以有選擇的重構(gòu)或優(yōu)化你的邏輯或引擎代碼，回歸測(cè)試一旦失敗，你會(huì)馬上發(fā)現(xiàn)出問題的地方，單元測(cè)試失敗可以讓你精確的定位出錯(cuò)之處。 知道代碼被你編寫的自動(dòng)化測(cè)試覆蓋得范圍是非常有好處的，你可以使用代碼覆蓋率調(diào)查工具（BullseyeCoverage/AQtime）。代碼覆蓋率分析會(huì)告訴你，你的代碼哪些被調(diào)用，也可以提示你測(cè)試集合中的疏漏之處。測(cè)試覆蓋率應(yīng)該是多少，無法精確定量，盡管它取決于被測(cè)試的代碼。細(xì)小的方法無需測(cè)試，調(diào)試用的函數(shù)也不必測(cè)試。并且，幾乎所有的項(xiàng)目都會(huì)包括一些“死”代碼，也就是不會(huì)被調(diào)用到的代碼，那么，這些代碼自然也不用測(cè)試?？偠灾?，現(xiàn)實(shí)中，我們見過的使用自動(dòng)化測(cè)試的游戲和中間件項(xiàng)目中測(cè)試覆蓋率大致是55%到70%。 編寫友好的測(cè)試代碼 必須承認(rèn)，并不是所有的代碼都能使用自動(dòng)化測(cè)試。以單元測(cè)試為例，嚴(yán)格的面向?qū)ο?，良好的類和函?shù)模塊化封裝設(shè)計(jì)可以大大提高它的測(cè)試效率。類的接口越多，為它編寫的單元測(cè)試就越多。同樣，過多的使用C++的友元也會(huì)增加編寫的難度，甚至無法為該類編寫（黑盒）單元測(cè)試用例。 在寫代碼的時(shí)候，要時(shí)刻牢記保持良好的測(cè)試性。在開發(fā)過程中，就會(huì)變成可行但是單調(diào)乏味的工作，有時(shí)候它需要很好的結(jié)構(gòu)性。要在游戲開發(fā)中使用，以下幾點(diǎn)必須牢記： *所有的回歸測(cè)試都取決于明確的行為。比如，使用隨計(jì)算法的尋徑系統(tǒng)可以提供一個(gè)初始化隨機(jī)種子的公共方法使得角色的行動(dòng)決策更復(fù)雜多變。這個(gè)方法在隨后的測(cè)試中可以被用來確保角色始終選取同樣的路徑。 *同樣，回歸測(cè)試中要避免與幀數(shù)相關(guān)的情況；否則，有真實(shí)物理特性的物體或渲染輸出也許會(huì)和以前的數(shù)據(jù)不同，特別是當(dāng)結(jié)果來自不同的機(jī)器或者不同的編譯條件（debug 和release）。在測(cè)試時(shí)，使用恒定的虛擬幀數(shù)就可以避免這樣的問題。 * 嚴(yán)重依賴于用戶輸入的軟件很難測(cè)試，比如游戲內(nèi)置的編輯系統(tǒng)或者游戲工具。這樣的話，把UI 和邏輯代碼嚴(yán)格的區(qū)分開會(huì)有所幫助。在我們的游戲工具里， UI界面里每個(gè)用戶動(dòng)作會(huì)執(zhí)行一條或多條簡單的腳本指令。每條腳本指令可以很明確的重現(xiàn)用戶的原意。這樣，測(cè)試用例可以簡單的執(zhí)行這些指令并且與樣本數(shù)據(jù)作比較就可以（比如導(dǎo)出地形文件）。 也可以使用GUI捕捉工具來測(cè)試UI，但我們發(fā)現(xiàn)這并不是個(gè)好辦法。UI會(huì)經(jīng)常改變，哪怕一個(gè)按鈕僅僅移動(dòng)幾個(gè)像素也會(huì)使捕捉軟件失效，GUI捕捉工具也許會(huì)幫倒忙。 關(guān)于測(cè)試的疑問：我們真的可以節(jié)省時(shí)間么？ 多數(shù)情況下，一個(gè)開發(fā)團(tuán)隊(duì)想要在開發(fā)過程中使用自動(dòng)化測(cè)試，大多數(shù)成員都會(huì)對(duì)它抱以質(zhì)疑的態(tài)度。畢竟，與其花這點(diǎn)時(shí)間寫測(cè)試用例，還不如去寫邏輯和引擎的代碼。根據(jù)我們?cè)谟螒蚝推渌I(lǐng)域的工作中使用自動(dòng)化測(cè)試的經(jīng)驗(yàn)來看，編寫測(cè)試代碼會(huì)額外增加30%工作量。初看，在時(shí)間和資金上這也許是很大的開銷，然而，你要意識(shí)到這樣做，省去了人工測(cè)試所花費(fèi)的時(shí)間。 自動(dòng)化測(cè)試可以看作在開發(fā)前期投入，在開發(fā)過程中贏利。大多數(shù)的代碼修改，包括Bug修改，都可能會(huì)引入更多問題導(dǎo)致程序宕機(jī)。所以，理論上說，一旦代碼有所改變，就必須測(cè)試所有可能被影響的代碼。自動(dòng)化測(cè)試無需人工干預(yù)就可以完成，它們縮短了開發(fā)過程。而且由于自動(dòng)化測(cè)試可以簡單快速的發(fā)現(xiàn)修改的代碼是否能有效地運(yùn)行，因此也就鼓勵(lì)開發(fā)者優(yōu)化和改進(jìn)現(xiàn)有的代碼。 對(duì)我們來說，自動(dòng)化測(cè)試幫助開發(fā)者編寫更穩(wěn)定和可靠的代碼。哪怕是一開始對(duì)它抱有懷疑態(tài)度的開發(fā)成員也欣賞它所提供早期反饋的特性，在開發(fā)過程中，它也可以更早的發(fā)現(xiàn)Bug。開發(fā)者的工作壓力和負(fù)荷隨著項(xiàng)目的開展日益加大，盡早的發(fā)現(xiàn)和解決Bug也可以避免給開發(fā)關(guān)鍵時(shí)期帶來額外的壓力。 在開發(fā)Vision引擎的時(shí)候，我們收集了一些數(shù)據(jù)來研究為提高代碼穩(wěn)定性而實(shí)施自動(dòng)化測(cè)試的有效性。2001年早期，全部依靠人工測(cè)試的引擎第一個(gè) release版本開發(fā)完成，盡管我們已經(jīng)進(jìn)行了很全面的測(cè)試，但是每個(gè)月，我們的在線技術(shù)支持?jǐn)?shù)據(jù)庫依然會(huì)收到上百個(gè)來自客戶的Bug報(bào)告。2001年 9月，我們對(duì)已有的引擎功能和新增的特征實(shí)施自動(dòng)化測(cè)試。這樣，即使我們現(xiàn)在的工作量很大，開發(fā)進(jìn)展也很正常，每月Bug報(bào)告的數(shù)量銳減（現(xiàn)在大概是5到 10個(gè)）。 必須強(qiáng)調(diào)，這些圖表只是反映了單元測(cè)試用例數(shù)量和每月Bug數(shù)量兩者之間的相互關(guān)系，不能將它理解為必然的因果關(guān)系。當(dāng)然，從2001年到2004年，我們?cè)谌绾尉帉懡训拇a上學(xué)到了很多，在這段時(shí)間內(nèi)，開發(fā)團(tuán)隊(duì)的人數(shù)變動(dòng)頻頻，但是，這些明顯的差異足以說明穩(wěn)定性的提升部分歸功于使用了自動(dòng)化測(cè)試。 游戲中自動(dòng)化測(cè)試的局限性 盡管使用自動(dòng)化測(cè)試對(duì)于游戲開發(fā)來說獲益匪淺，但是也有其局限之處。顯然，很難用它來測(cè)試游戲的平衡性，也不太可能用它來測(cè)試游戲性和畫面的美觀性。在這幾年里，我們總結(jié)了一些編寫自動(dòng)化測(cè)試的要點(diǎn)，重點(diǎn)如下： *測(cè)試最重要的模塊（比如，最復(fù)雜和最常用的）。對(duì)那些最有可能出問題或者不會(huì)破壞原先設(shè)計(jì)的重構(gòu)任務(wù)進(jìn)行自動(dòng)化測(cè)試，性價(jià)比最高。 *當(dāng)上層功能性測(cè)試難以進(jìn)行的時(shí)候，把精力集中在不同的子系統(tǒng)上。例如，你也許不能通過自動(dòng)化測(cè)試來驗(yàn)證AI系統(tǒng)是否正常工作，但你可以測(cè)試當(dāng)一個(gè)怪獸的體力低于一定數(shù)值的時(shí)候，它是否會(huì)“投降”。 *用壓力測(cè)試來驗(yàn)證你的代碼的強(qiáng)壯性。如果你的游戲在極端條件下運(yùn)行的很好，比如，每秒有2000個(gè)怪獸出生和死亡，一個(gè)場(chǎng)景中同時(shí)放入500個(gè)有真實(shí)物理特性的物體，一幅地圖輪流載入200次，那么玩家作一些異常操作時(shí)，宕機(jī)的可能性就會(huì)小很多。 *在修改Bug前，也為它編寫測(cè)試用例。這樣的話，可以確保這些Bug在今后的版本中不會(huì)重現(xiàn)。 *回歸測(cè)試。例如，圖像或狀態(tài)比較的話，使用指定的測(cè)試場(chǎng)景要比使用產(chǎn)品地圖更容易維護(hù)。如果你認(rèn)為測(cè)試用產(chǎn)品數(shù)據(jù)可能會(huì)經(jīng)常變動(dòng)，那么你最好使用小的測(cè)試場(chǎng)景。否則，不斷的生成新的參考數(shù)據(jù)會(huì)使得開發(fā)團(tuán)隊(duì)產(chǎn)生疲倦和厭煩的情緒。 * 測(cè)試用例越簡單越好，不要奢望有非常大的覆蓋面。搭建一個(gè)易維護(hù)和可擴(kuò)展的自動(dòng)化測(cè)試是一個(gè)長期的任務(wù)。一般來說，“底層”代碼，例如算術(shù)、碰撞檢測(cè)和渲染，更容易進(jìn)行自動(dòng)化測(cè)試，對(duì)于游戲性和完整的游戲測(cè)試來說，還是需要經(jīng)過QA人員親自測(cè)試。當(dāng)然，QA部門的注意力也要從技術(shù)轉(zhuǎn)移到與游戲性相關(guān)的問題上去。“到A房間后，因?yàn)橥L(fēng)口前面的箱子太高了，所以出不去”這樣的報(bào)告就會(huì)取代“當(dāng)我的角色轉(zhuǎn)動(dòng)的時(shí)候，屏幕上出現(xiàn)了很多扭曲的三角面”。 持續(xù)集成 在一個(gè)復(fù)雜的軟件項(xiàng)目中引入自動(dòng)化測(cè)試，你會(huì)發(fā)覺運(yùn)行它也需要一定的時(shí)間，我們看到的一些項(xiàng)目甚至需要幾個(gè)小時(shí)。如果讓開發(fā)者在他們的開發(fā)用機(jī)上運(yùn)行的話，測(cè)試會(huì)完全占用他們的機(jī)器，影響工作，那么結(jié)果就是他們不去運(yùn)行測(cè)試用例，很顯然，沒有被運(yùn)行的用例是沒有任何價(jià)值的。 解決方法就是搭建一臺(tái)或多臺(tái)專用的自動(dòng)化測(cè)試機(jī)。它同時(shí)還運(yùn)行版本管理軟件（Subversion/CVS/Perforce），一旦發(fā)現(xiàn)提交了新代 碼，那么代碼就會(huì)被Check out并編譯，測(cè)試用例也會(huì)自動(dòng)運(yùn)行。最后，系統(tǒng)會(huì)將測(cè)試結(jié)果報(bào)告以email的形式自動(dòng)發(fā)送給最近提交代碼的開發(fā)者。 完全自動(dòng)化、重復(fù)的 build和測(cè)試過程，這種過程每天運(yùn)行多次，在極限編程中，我們把它稱為：持續(xù)集成。為了更好的實(shí)行持續(xù)集成，像 Cruise Control或者Anthill這樣的開源代碼工具可以將版本管理軟件和自動(dòng)build工具，例如ANT，整合起來。使用這樣的工具，可以很輕松的搭建適合自己的持續(xù)集成系統(tǒng)。 我們發(fā)現(xiàn)搭建專用持續(xù)集成服務(wù)器使得開發(fā)過程變得更順暢，開發(fā)者可以更專注于自己的工作。與此同時(shí)，測(cè)試可以被很好的運(yùn)行，一旦提交了錯(cuò)誤的代碼，持續(xù)集成系統(tǒng)會(huì)自動(dòng)通知開發(fā)者和項(xiàng)目經(jīng)理，因此開發(fā)者也可不必為此分心。自動(dòng)化，自動(dòng)化！ 自動(dòng)化測(cè)試和持續(xù)集成的使用為我們?cè)谟螒蚝凸ぞ叩拈_發(fā)上帶來了極大的收益。例如，持續(xù)集成服務(wù)器根據(jù)Wiki中的變化，每天自動(dòng)生成CHF （windows幫助文件）文件。而且，使用ANT和CruiseControl來制作軟件自動(dòng)分發(fā)包會(huì)非常容易。這樣一來，用最新的代碼（或最新的 tag）創(chuàng)建一個(gè)完整的分發(fā)包就是舉手之勞。 自動(dòng)化過程中的自動(dòng)化測(cè)試執(zhí)行，例如測(cè)試框架中的常規(guī)單元和回歸測(cè)試，他們不是用來檢查錯(cuò)誤，而是用在相同環(huán)境下得到測(cè)試結(jié)果來衡量和比較引擎的性能（系統(tǒng)配置的結(jié)果以 XML文件格式存放在版本管理軟件系統(tǒng)上）。如果當(dāng)前的結(jié)果比參考結(jié)果差很多，那么測(cè)試失敗，反之，它就成為了新的參考結(jié)果。 性能測(cè)試是一種特殊的回歸測(cè)試。當(dāng)引擎代碼被重構(gòu)，我們通過它來確保修改不會(huì)降低引擎原有的性能。這樣，就迫使我們時(shí)刻關(guān)注代碼的運(yùn)行效率和對(duì)代碼的優(yōu)化工作，可以避免遇到在實(shí)際運(yùn)行中，速度突然變慢的現(xiàn)象發(fā)生。 結(jié)論 根據(jù)我們的經(jīng)驗(yàn)，使用自動(dòng)化測(cè)試和持續(xù)集成可以使開發(fā)團(tuán)隊(duì)工作更有效而開發(fā)出更好、穩(wěn)定、簡單的軟件。而且，減少人工測(cè)試也可以減少開發(fā)團(tuán)隊(duì)的壓力和工作負(fù)荷，可以在開發(fā)過程中盡早的發(fā)現(xiàn)Bug。 當(dāng)然，自動(dòng)化測(cè)試不會(huì)使你的游戲想當(dāng)然成為暢銷品。但毋庸置疑，它會(huì)使各類開發(fā)人員甚至玩家活得更自在。 |
|
|
