自動化測 試可以看作在開發前期投入，在開發過程中贏利。大多數的代碼修改，包括Bug修改，都可能會引入更多問題導致程序宕機。所以，理論上說，一旦代碼有所改變，就必須測試所有可能被影響的代碼。自動化測試無需人工干預就可以完成，它們縮短了開發過程。而且由于自動化測試可以簡單快速的發現修改的代碼是否能有效地運行，因此也就鼓勵開發者優化和改進現有的代碼。
對我們來說，自動化測試幫助開發者編寫更穩定和可靠的代碼。哪怕是一開始對它抱有懷疑態度的開發成員也欣賞它所提供早期反饋的特性，在開發過程中，它也可以更早的 發現Bug。開發者的工作壓力和負荷隨著項目的開展日益加大，盡早的發現和解決Bug也可以避免給開發關鍵時期帶來額外的壓力。
在開發Vision引擎的時候，我們收集了一些數據來研究為提高代碼穩定性而實施自動化測試的有效性。2001年早期，全部依靠人工測試的引擎第一個 release版本開發完成，盡管我們已經進行了很全面的測試，但是每個月，我們的在線技術支持數據庫依然會收到上百個來自客戶的Bug報告。2001年 9月，我們對已有的引擎功能和新增的特征實施自動化測試。這樣，即使我們現在的工作量很大，開發進展也很正常，每月Bug報告的數量銳減(現在大概是5到10個)。
必須強調，這些圖表只是反映了單元測試用例數量和每月Bug數量兩者之間的相互關系，不能將它理解為必然的因果關系。當然，從2001年到2004年，我們在如何編寫健壯的代碼上學到了很多，在這段時間內，開發團隊的人數變動頻頻，但是，這些明顯的差異足以說明穩定性的提升部分歸功于使用了自動化測試。
游戲中自動化測試的局限性
盡管使用自動化測試對于游戲開發來說獲益匪淺，但是也有其局限之處。顯然，很難用它來測試游戲的平衡性，也不太可能用它來測試游戲性和畫面的美觀性。在這幾年里，我們總結了一些編寫自動化測試的要點，重點如下：
*測試最重要的模塊(比如，最復雜和最常用的)。對那些最有可能出問題或者不會破壞原先設計的重構任務進行自動化測試，性價比最高。
*當上層功能性測試難以進行的時候，把精力集中在不同的子系統上。例如，你也許不能通過自動化測試來驗證AI系統是否正常工作，但你可以測試當一個怪獸的體力低于一定數值的時候，它是否會“投降”。
*用壓力測試來驗證你的代碼的強壯性。如果你的游戲在極端條件下運行的很好，比如，每秒有2000個怪獸出生和死亡，一個場景中同時放入500個有真實物理特性的物體，一幅地圖輪流載入200次，那么玩家作一些異常操作時，宕機的可能性就會小很多。
*在修改Bug前，也為它編寫測試用例。這樣的話，可以確保這些Bug在今后的版本中不會重現。
*回歸測試。例如，圖像或狀態比較的話，使用指定的測試場景要比使用產品地圖更容易維護。如果你認為測試用產品數據可能會經常變動，那么你最好使用小的測試場景。否則，不斷的生成新的參考數據會使得開發團隊產生疲倦和厭煩的情緒。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
