多數情況下，一個開發(fā)團隊想要在開發(fā)過程中使用自動化測試，大多數成員都會對它抱以質疑的態(tài)度。畢竟，與其花這點時間寫測試用例，還不如去寫邏輯和引擎 的代碼。根據我們在游戲和其他領域的工作中使用自動化測試的經驗來看，編寫測試代碼會額外增加30%工作量。初看，在時間和資金上這也許是很大的開銷，然而，你要意識到這樣做，省去了人工測試所花費的時間。
自動化測 試可以看作在開發(fā)前期投入，在開發(fā)過程中贏利。大多數的代碼修改，包括Bug修改，都可能會引入更多問題導致程序宕機。所以，理論上說，一旦代碼有所改變，就必須測試所有可能被影響的代碼。自動化測試無需人工干預就可以完成，它們縮短了開發(fā)過程。而且由于自動化測試可以簡單快速的發(fā)現修改的代碼是否能有效地運行，因此也就鼓勵開發(fā)者優(yōu)化和改進現有的代碼。
對我們來說，自動化測試幫助開發(fā)者編寫更穩(wěn)定和可靠的代碼。哪怕是一開始對它抱有懷疑態(tài)度的開發(fā)成員也欣賞它所提供早期反饋的特性，在開發(fā)過程中，它也可以更早的 發(fā)現Bug。開發(fā)者的工作壓力和負荷隨著項目的開展日益加大，盡早的發(fā)現和解決Bug也可以避免給開發(fā)關鍵時期帶來額外的壓力。
在開發(fā)Vision引擎的時候，我們收集了一些數據來研究為提高代碼穩(wěn)定性而實施自動化測試的有效性。2001年早期，全部依靠人工測試的引擎第一個 release版本開發(fā)完成，盡管我們已經進行了很全面的測試，但是每個月，我們的在線技術支持數據庫依然會收到上百個來自客戶的Bug報告。2001年 9月，我們對已有的引擎功能和新增的特征實施自動化測試。這樣，即使我們現在的工作量很大，開發(fā)進展也很正常，每月Bug報告的數量銳減（現在大概是5到10個）。
必須強調，這些圖表只是反映了單元測試用例數量和每月Bug數量兩者之間的相互關系，不能將它理解為必然的因果關系。當然，從2001年到2004年，我們在如何編寫健壯的代碼上學到了很多，在這段時間內，開發(fā)團隊的人數變動頻頻，但是，這些明顯的差異足以說明穩(wěn)定性的提升部分歸功于使用了自動化測試。
游戲中自動化測試的局限性
盡管使用自動化測試對于游戲開發(fā)來說獲益匪淺，但是也有其局限之處。顯然，很難用它來測試游戲的平衡性，也不太可能用它來測試游戲性和畫面的美觀性。在這幾年里，我們總結了一些編寫自動化測試的要點，重點如下：
*測試最重要的模塊（比如，最復雜和最常用的）。對那些最有可能出問題或者不會破壞原先設計的重構任務進行自動化測試，性價比最高。
*當上層功能性測試難以進行的時候，把精力集中在不同的子系統(tǒng)上。例如，你也許不能通過自動化測試來驗證AI系統(tǒng)是否正常工作，但你可以測試當一個怪獸的體力低于一定數值的時候，它是否會“投降”。
此文章共有6頁 上一頁 1 2 3 4 5 6 下一頁
文章來源：中國項目管理資源網
 軟件開發(fā)項目管理培訓課程方案
|
Leadge.com首頁 > 知識庫 
