*回歸測試。例如，圖像或狀態比較的話，使用指定的測試場景要比使用產品地圖更容易維護。如果你認為測試用產品數據可能會經常變動，那么你最好使用小的測試場景。否則，不斷的生成新的參考數據會使得開發團隊產生疲倦和厭煩的情緒。
* 測試用例越簡單越好，不要奢望有非常大的覆蓋面。搭建一個易維護和可擴展的自動化測試是一個長期的任務。一般來說，“底層”代碼，例如算術、碰撞檢測和渲染，更容易進行自動化測試，對于游戲性和完整的游戲測試來說，還是需要經過QA人員親自測試。當然，QA部門的注意力也要從技術轉移到與游戲性相關的問題上去�！暗紸房間后，因為通風口前面的箱子太高了，所以出不去”這樣的報告就會取代“當我的角色轉動的時候，屏幕上出現了很多扭曲的三角面”。
持續集成
在一個復雜的軟件項目中引入自動化測試，你會發覺運行它也需要一定的時間，我們看到的一些項目甚至需要幾個小時。如果讓開發者在他們的開發用機上運行的話，測試會完全占用他們的機器，影響工作，那么結果就是他們不去運行測試用例，很顯然，沒有被運行的用例是沒有任何價值的。
解決方法就是搭建一臺或多臺專用的自動化測試機。它同時還運行版本管理軟件(Subversion/CVS/Perforce)，一旦發現提交了新代 碼，那么代碼就會被Check out并編譯，測試用例也會自動運行。最后，系統會將測試結果報告以email的形式自動發送給最近提交代碼的開發者。
完全自動化、重復的 build和測試過程，這種過程每天運行多次，在極限編程中，我們把它稱為：持續集成。為了更好的實行持續集成，像 Cruise Control或者Anthill這樣的開源代碼工具可以將版本管理軟件和自動build工具，例如ANT，整合起來。使用這樣的工具， 可以很輕松的搭建適合自己的持續集成系統。
我們發現搭建專用持續集成服務器使得開發過程變得更順暢，開發者可以更專注于自己的工作。與此同時，測試可以被很好的運行，一旦提交了錯誤的代碼，持續集成系統會自動通知開發者和項目經理，因此開發者也可不必為此分心。自動化，自動化!
自動化測試和持續集成的使用為我們在游戲和工具的開發上帶來了極大的收益。例如，持續集成服務器根據Wiki中的變化，每天自動生成CHF (windows幫助文件)文件。而且，使用ANT和CruiseControl來制作軟件自動分發包會非常容易。這樣一來，用最新的代碼(或最新的 tag)創建一個完整的分發包就是舉手之勞。
自動化過程中的自 動化測試執行，例如測試框架中的常規單元和回歸測試，他們不是用來檢查錯誤，而是用在相同環境下得到測試結果來衡量和比較引擎的性能(系統配置的結果以 XML文件格式存放在版本管理軟件系統上)。如果當前的結果比參考結果差很多，那么測試失敗，反之，它就成為了新的參考結果。
性能測試是一種特殊的回歸測試。當引擎代碼被重構，我們通過它來確保修改不會降低引擎原有的性能。這樣，就迫使我們時刻關注代碼的運行效率和對代碼的優化工作，可以避免遇到在實際運行中，速度突然變慢的現象發生。
結論
根據我們的經驗，使用自動化測試和持續集成可以使開發團隊工作更有效而開發出更好、穩定、簡單的軟件。而且，減少人工測試也可以減少開發團隊的壓力和工作負荷，可以在開發過程中盡早的發現Bug。
當然，自動化測試不會使你的游戲想當然成為暢銷品。但毋庸置疑，它會使各類開發人員甚至玩家活得更自在。
參考
* Unit Tests: http://c2.com/cgi/wiki?UnitTest
* The Standish Group, Inc. (2001), Extreme Chaos
* By the Books: Solid Software Engineering for Games (GDC 2002 roundtable):
* http://www.convexhull.com/sweng/GDC2002.html
* Continuous Integration: http://cruisecontrol.sourceforge.net/
* http://c2.com/cgi/wiki?ContinuousIntegration
* ANT: http://ant.apache.org
* BullseyeCoverage: http://www.bullseye.com
* AQtime: http://www.automatedqa.com
文章來源于領測軟件測試網 http://www.kjueaiud.com/
