摘要：項目的開發(fā)風(fēng)險來自于對需求的誤解，來自于設(shè)計與開發(fā)過程及產(chǎn)品的缺陷，只有盡早發(fā)現(xiàn)這些缺陷，才能降低并控制項目風(fēng)險。基于這種思想，軟件業(yè)出現(xiàn)了一些新的測試思路。(據(jù)調(diào)查，測試中發(fā)現(xiàn)的BUG有56%是來自需求文檔，而這56%的BUG正是由于需求文檔編寫存在問題，不明確、不清晰、不正確所導(dǎo)致的。)

 

　　1、測試驅(qū)動開發(fā)。這種測試思想被近流行的XP(Extreme Programming)極限編程方式所大力提倡。它的基本思想是，通過測試來為編程做指導(dǎo)，在某個要開發(fā)的需求對象明確之后，在編碼之前，先進(jìn)行相關(guān)測試代碼(測試代碼的內(nèi)容和需求規(guī)格說明書描述是相同的，有人把它稱為“可執(zhí)行的需求規(guī)格說明書”)的編寫工作，完成之后針對測試代碼進(jìn)行編程，然后再用測試程序?qū)﹂_發(fā)代碼進(jìn)行測試，驗證其正確性，若程序通過了測試，說明它是符合需求規(guī)格說明書要求的。周而復(fù)始，通過這樣的過程，開發(fā)進(jìn)程得以層層深入，直到開發(fā)完成。而這時單元測試也基本完成了。

 

　　這種測試方式的大的好處是，盡早地發(fā)現(xiàn)設(shè)計、開發(fā)中存在的問題，避免傳統(tǒng)開發(fā)模式中的“測試過程中發(fā)現(xiàn)代碼不能滿足需求而導(dǎo)致的大量返工”。降低項目風(fēng)險;同時可以盡早地將“半成品”展示給客戶，使客戶對需求進(jìn)行驗證、補(bǔ)充及完善，另外測試代碼的表達(dá)方式相對準(zhǔn)確、無二義性，可以降低因需求理解錯誤而導(dǎo)致的項目風(fēng)險。


　　2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發(fā)模式演變而來。在迭代開發(fā)模式中，每個迭代都包含需求、設(shè)計、編碼、集成、測試等過程。在每一次迭代完成之后，便會開始新的迭代過程。通過一次次迭代的累進(jìn)，系統(tǒng)會增量式集成一些新的功能，直至整個系統(tǒng)功能的完成。其中，每個迭代周期的測試工作由兩方面內(nèi)容構(gòu)成：

 

　　* 對當(dāng)前迭代周期產(chǎn)品的增量測試。


　　* 對前迭代周期已完成功能的回歸測試。

　　隨著迭代周期的累進(jìn)，測試工作內(nèi)容隨之不斷變化。早期迭代測試重點在于新功能的測試，后期迭代測試重點在于累積功能的回歸測試。

　　有的人不喜歡XP編程的開發(fā)方式，認(rèn)為其沒有明確的階段性劃分，不利于計劃管理，模式過于靈活，不好掌握。迭代式開發(fā)模式為這些人提供了新的選擇。這種開發(fā)方式繼承了瀑布式開發(fā)模式的優(yōu)點――全面、嚴(yán)謹(jǐn)、有計劃性、易管理，更重要的是，這種模式將測試工作分布到每個迭代周期中，使測試工作提前進(jìn)行，從而使將發(fā)現(xiàn)軟件缺陷的周期提前，大大降低軟件風(fēng)險及開發(fā)成本。

　　它將軟件開發(fā)比喻成制作一桌盛宴，項目經(jīng)理比作大廚，測試人員比作品嘗師，用戶則比作餐者。為保障飯菜質(zhì)量，上菜之前，先由品嘗師對滿桌的半成品、準(zhǔn)成品逐個品嘗，發(fā)現(xiàn)不足的地方要及時通知大廚進(jìn)行改進(jìn)，完善質(zhì)量，直至品嘗師覺得：全部的飯菜已經(jīng)色、香、味俱佳，滿足用戶要求了，才通過審查，允許飯菜上桌，供餐者品嘗。我想說的是：飯菜質(zhì)量靠品嘗師的監(jiān)督，但主要靠的是大廚的技術(shù)，同理，軟件的質(zhì)量則是靠各個項目管理過程的互相配合及項目經(jīng)理的整體控制和把握，測試只是其中的一份子。所以，請不要將軟件的質(zhì)量都交給測試過程來承擔(dān)，那樣將是“生命不能承受之重”。