多數(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è)試可以簡(jiǎn)單快速的發(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ù)量?jī)烧咧g的相互關(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ì)“投降”。
此文章共有6頁 上一頁 1 2 3 4 5 6 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
 軟件開發(fā)項(xiàng)目管理培訓(xùn)課程方案
|
Leadge.com首頁 > 知識(shí)庫 
