如何在軟體頻繁改變時測試？〔翻譯〕

    就像一句古老的諺語中說得：“唯一不變的是改變”。
    在軟體開發模型中，曾被認為最優秀的瀑布模型的一個缺陷就是假定很少或者沒有改變，而現實世界是每天都在改變的。也因為如此，其他的開發模型比如“快速應用開發（Rapid Application Development，RAD）”逐漸發展成可以接收改變，並通過計劃好的迭代過程利用這些改變來改進軟體的開發模型。
    雖然RAD可以協助軟體開發人員加快開發的速度，但是卻也讓測試人員非常頭痛。因為每一次改變都有可能產生新的缺陷，而要想找到新的缺陷只有一個辦法——進行全面的迴歸測試——對所有原來已經測試通過的部分再次測試，對傳回值進行比較並找出不同的地方。

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

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

    實際上這是不可能的。不過，這個問題本身就有問題^_^，因為很多時候甚至都不可能在一個完全穩定的環境中測試軟體。這個問題其實是想問：“在軟體頻繁變化的時候，能否進行有效測試？”我們能否期望通過更好的使用人力和其他資源來完成這種測試？我們能否找到所期望的那麼多缺陷？
    通過對使用RAD方法的項目的觀察，我發現軟體測試過程對於發現缺陷是非常重要的，不同的過程會表現出不同的效果。因為大多數時候我們的開發過程都不是簡單的重複，所以在RAD環境中就不能象其他環境那樣——嘗試著用各種方法到處看看能不能找到一些缺陷。

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

    應該花些時間學習怎樣在不同的環境下開展工作，不過在軟體頻繁改變的時候有些一般的策略還是可以參考的。
    .首先，你必須接受這個事實——你不可能有6周的時間對一個每天都在變化的軟體進行測試——或者說你的老闆不會允許你在每次軟體改變後都用這麼長的周期來進行測試。唯一的辦法是你要定義一個可以快速有效完成測試工作的過程。
    .進行風險評估。能夠區分不同測試對象的風險層級是非常重要的，因為這樣你就可以通過對不同的測試對象排列優先順序，在那些很簡單的問題上只花費較少的時間，而對更高的風險則給予更高的優先順序和更多的時間以及其他資源。
    .必須有一個確定的工作版本（基準版本），以便於你在將來進行測試的時候可以進行比較。
    .自動化測試。使用捕捉/回放工具可以藉助一些自動化特性協助你來對軟體進行迴歸測試。應該考慮花些時間和資金把一些工具融入到你的團隊中，讓大家都學會如何使用這些工具會對你的工作有所協助。對於一個不願引入新技術的組織——比如自動化測試載入器——是很難在軟體頻繁改變期間完成測試的。這就像蓋一座房子，手頭上必須要有些合適的工具才行。
    .自動化工具只能對你的操作進行記錄和回放，這是不夠的。你必須明確業務需求，設計測試案例和測試過程，制定測試計劃。另外，如果人們想在長期工作過程中獲得比短期工作更多的好處，就需要考慮測試案例和測試指令碼。

    在軟體頻繁改變的時候進行測試不是不可能的，但是需要快速的響應、努力工作和維護對改變的跟蹤。
    在軟體頻繁改變時進行測試同樣需要一個有創新思維的團隊和過程，工具自己不會工作，只有在工作中由最優秀的人員在合適的時機使用才會產生最好的效果。使工具、人員和過程達到一個最理想的結合是一件非常有挑戰性的事情。

參考資料：“Testing During Rapid Change” By Randy Rice, CQA, CSTE

點擊這裡下載