*用壓力測試來驗證你的代碼的強壯性。如果你的游戲在極端條件下運行的很好，比如，每秒有2000個怪獸出生和死亡，一個場景中同時放入500個有真實物理特性的物體，一幅地圖輪流載入200次，那么玩家作一些異常操作時，宕機的可能性就會小很多。
*在修改Bug前，也為它編寫測試用例。這樣的話，可以確保這些Bug在今后的版本中不會重現(xiàn)。
*回歸測試。例如，圖像或狀態(tài)比較的話，使用指定的測試場景要比使用產(chǎn)品地圖更容易維護。如果你認為測試用產(chǎn)品數(shù)據(jù)可能會經(jīng)常變動，那么你最好使用小的測試場景。否則，不斷的生成新的參考數(shù)據(jù)會使得開發(fā)團隊產(chǎn)生疲倦和厭煩的情緒。
* 測試用例越簡單越好，不要奢望有非常大的覆蓋面。搭建一個易維護和可擴展的自動化測試是一個長期的任務(wù)。一般來說，“底層”代碼，例如算術(shù)、碰撞檢測和渲染，更容易進行自動化測試，對于游戲性和完整的游戲測試來說，還是需要經(jīng)過QA人員親自測試。當然，QA部門的注意力也要從技術(shù)轉(zhuǎn)移到與游戲性相關(guān)的問題上去�！暗紸房間后，因為通風口前面的箱子太高了，所以出不去”這樣的報告就會取代“當我的角色轉(zhuǎn)動的時候，屏幕上出現(xiàn)了很多扭曲的三角面”。
持續(xù)集成
在一個復(fù)雜的軟件項目中引入自動化測試，你會發(fā)覺運行它也需要一定的時間，我們看到的一些項目甚至需要幾個小時。如果讓開發(fā)者在他們的開發(fā)用機上運行的話，測試會完全占用他們的機器，影響工作，那么結(jié)果就是他們不去運行測試用例，很顯然，沒有被運行的用例是沒有任何價值的。
解決方法就是搭建一臺或多臺專用的自動化測試機。它同時還運行版本管理軟件（Subversion/CVS/Perforce），一旦發(fā)現(xiàn)提交了新代 碼，那么代碼就會被Check out并編譯，測試用例也會自動運行。最后，系統(tǒng)會將測試結(jié)果報告以email的形式自動發(fā)送給最近提交代碼的開發(fā)者。
完全自動化、重復(fù)的 build和測試過程，這種過程每天運行多次，在極限編程中，我們把它稱為：持續(xù)集成。為了更好的實行持續(xù)集成，像 Cruise Control或者Anthill這樣的開源代碼工具可以將版本管理軟件和自動build工具，例如ANT，整合起來。使用這樣的工具， 可以很輕松的搭建適合自己的持續(xù)集成系統(tǒng)。
我們發(fā)現(xiàn)搭建專用持續(xù)集成服務(wù)器使得開發(fā)過程變得更順暢，開發(fā)者可以更專注于自己的工作。與此同時，測試可以被很好的運行，一旦提交了錯誤的代碼，持續(xù)集成系統(tǒng)會自動通知開發(fā)者和項目經(jīng)理，因此開發(fā)者也可不必為此分心。自動化，自動化！
自動化測試和持續(xù)集成的使用為我們在游戲和工具的開發(fā)上帶來了極大的收益。例如，持續(xù)集成服務(wù)器根據(jù)Wiki中的變化，每天自動生成CHF （windows幫助文件）文件。而且，使用ANT和CruiseControl來制作軟件自動分發(fā)包會非常容易。這樣一來，用最新的代碼（或最新的 tag）創(chuàng)建一個完整的分發(fā)包就是舉手之勞。
此文章共有6頁 上一頁 1 2 3 4 5 6 下一頁
文章來源：中國項目管理資源網(wǎng)
 軟件開發(fā)項目管理培訓課程方案
|
Leadge.com首頁 > 知識庫 
