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

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

　　雖然RAD可以幫助軟件開發人員加快開發的速度，但是卻也讓測試人員非常頭痛。因為每一次改變都有可能產生新的缺陷，而要想找到新的缺陷只有一個辦法??進行全面的回歸測試??對所有原來已經測試通過的部分再次測試，對返回值進行比較并找出不同的地方。

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

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

　　實際上這是不可能的。不過，這個問題本身有問題^_^，因為很多時候甚至都不可能在一個完全穩定的環境中測試軟件。這個問題其實是想問：“在軟件頻繁變化的時候，能否進行有效的測試？”我們能否期望通過更好的使用人力和其他來完成這種測試？我們能否找到所期望的那么多缺陷？

　　通過對使用RAD方法的項目的觀察，我發現過程對于發現缺陷是非常重要的，不同的過程會表現出不同的效果。因為大多數時候我們的開發過程都不是簡單的重復，所以在RAD環境中不能象其他環境那樣??嘗試著用各種方法到處看看能不能找到一些缺陷。

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

　　應該花些時間學習怎樣在不同的環境下開展工作，不過在軟件頻繁改變的時候有些一般的策略還是可以參考的。

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

　　● 進行評估。能夠區分不同測試對象的風險級別是非常重要的，因為這樣你可以通過對不同的測試對象排列優先級，在那些很簡單的問題上只花費較少的時間，而對更高的風險則給予更高的優先級和更多的時間以及其他資源。

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

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

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

　　在軟件頻繁改變的時候進行測試不是不可能的，但是需要快速的響應、努力工作和維護對改變的跟蹤。

　　在軟件頻繁改變時進行測試同樣需要一個有創新思維的團隊和過程，工具自己不會工作，只有在工作中由的人員在合適的時機使用才會產生好的效果。使工具、人員和過程達到一個理想的結合是一件非常有挑戰性的事情。