像一句古老的諺語中說得：“不變的是改變”。

　　在軟件開發(fā)模型中，曾被認(rèn)為的瀑布模型的一個缺陷是假定很少或者沒有改變，而現(xiàn)實(shí)世界是每天都在改變的。也因?yàn)槿绱，其他的開發(fā)模型比如“快速應(yīng)用開發(fā)（Rapid Application Development，RAD）”逐漸發(fā)展成可以接收改變，并通過計(jì)劃好的迭代過程利用這些改變來改進(jìn)軟件的開發(fā)模型。

　　雖然RAD可以幫助軟件開發(fā)人員加快開發(fā)的速度，但是卻也讓測試人員非常頭痛。因?yàn)槊恳淮胃淖兌加锌赡墚a(chǎn)生新的缺陷，而要想找到新的缺陷只有一個辦法??進(jìn)行全面的回歸測試??對所有原來已經(jīng)測試通過的部分再次測試，對返回值進(jìn)行比較并找出不同的地方。

　　這里有兩個問題需要注意：

　　1）在軟件頻繁改變的時候，可能進(jìn)行全面測試嗎？

　　實(shí)際上這是不可能的。不過，這個問題本身有問題^_^，因?yàn)楹芏鄷r候甚至都不可能在一個完全穩(wěn)定的環(huán)境中測試軟件。這個問題其實(shí)是想問：“在軟件頻繁變化的時候，能否進(jìn)行有效的測試？”我們能否期望通過更好的使用人力和其他來完成這種測試？我們能否找到所期望的那么多缺陷？

　　通過對使用RAD方法的項(xiàng)目的觀察，我發(fā)現(xiàn)過程對于發(fā)現(xiàn)缺陷是非常重要的，不同的過程會表現(xiàn)出不同的效果。因?yàn)榇蠖鄶?shù)時候我們的開發(fā)過程都不是簡單的重復(fù)，所以在RAD環(huán)境中不能象其他環(huán)境那樣??嘗試著用各種方法到處看看能不能找到一些缺陷。

　　2）在軟件頻繁改變的時候，有哪些策略可以使用？

　　應(yīng)該花些時間學(xué)習(xí)怎樣在不同的環(huán)境下開展工作，不過在軟件頻繁改變的時候有些一般的策略還是可以參考的。

　　● 首先，你必須接受這個事實(shí)??你不可能有6周的時間對一個每天都在變化的軟件進(jìn)行測試??或者說你的老板不會允許你在每次軟件改變后都用這么長的周期來進(jìn)行測試。的辦法是你要定義一個可以快速有效的完成測試任務(wù)的過程。

　　● 進(jìn)行評估。能夠區(qū)分不同測試對象的風(fēng)險級別是非常重要的，因?yàn)檫@樣你可以通過對不同的測試對象排列優(yōu)先級，在那些很簡單的問題上只花費(fèi)較少的時間，而對更高的風(fēng)險則給予更高的優(yōu)先級和更多的時間以及其他資源。

　　● 必須有一個確定的工作版本（基線版本），以便于你在將來進(jìn)行測試的時候可以進(jìn)行比較。

　　● 自動化測試。使用捕捉/回放工具可以借助一些自動化特性幫助你來對軟件進(jìn)行回歸測試。應(yīng)該考慮花些時間和資金把一些工具融入到你的中，讓大家都學(xué)會如何使用這些工具會對你的工作有所幫助。對于一個不愿引入的組織??比如自動化??是很難在軟件頻繁改變期間完成測試的。這像蓋一座房子，手頭上必須要有些合適的工具才行。

　　● 自動化工具只能對你的操作進(jìn)行記錄和回放，這是不夠的。你必須明確業(yè)務(wù)需求，設(shè)計(jì)測試用例和測試過程，制定測試計(jì)劃。另外，如果人們想在長期工作過程中獲得比短期工作更多的好處，需要考慮測試用例和測試腳本。

　　在軟件頻繁改變的時候進(jìn)行測試不是不可能的，但是需要快速的響應(yīng)、努力工作和維護(hù)對改變的跟蹤。

　　在軟件頻繁改變時進(jìn)行測試同樣需要一個有創(chuàng)新思維的團(tuán)隊(duì)和過程，工具自己不會工作，只有在工作中由的人員在合適的時機(jī)使用才會產(chǎn)生好的效果。使工具、人員和過程達(dá)到一個理想的結(jié)合是一件非常有挑戰(zhàn)性的事情。