怎么會，確實！
回歸（向后追溯）是軟件系統的現實生活。即使之前是很好地工作的，但是不能確保它會在最近的“很小”的改變后也能工作。是的，模塊設計和充分的系統架構可以減少這種問題的出現，但是不能完全消除。
回歸測試是永遠都需要的。但是我們在非常有限的時間里測試一個“很小”的改動，我們怎么進行充分的回歸測試呢？我們怎么知道查找哪些方面？我們怎么減少出現問題的風險？
回歸的問題
回歸的問題根源是軟件系統的內在復雜性。隨著系統的復雜性的增加，更改產生難以預見的影響的可能性也增加了。即使開發人員使用最新的技術也不可避免。
隨著系統構建的時間越長回歸的問題也會增多。在幾年后，可能已經被更改了很多次，通常是由那些原本不在開發組中的人來修改的。即使這些人努力理解底層的設計和結構，更改與原本設計主題思想非常匹配也是很難做到的。這樣的更改越多，系統變得越復雜直到變得非常脆弱。
脆弱的軟件就像脆弱的金屬。被彎曲和扭轉了這么多次以致你對它做的任何事都可能導致它的破裂。當一個軟件系統變得脆弱，人們實際上會很害怕改變它。他們知道他們做的任何事情都可能導致更多的問題。易脆（不可維護）是舊的軟件系統被替換的主要原因之一。
回歸測試的困難
因為任何系統都需要回歸，所以回歸測試非常重要。但是誰有時間對每一個小的更改都完全地重新測試系統呢？對一個只是1周多點的開發，我們肯定不能承受1個月的完全重新測試整個系統。我們有一個星期的時間測試就很幸運了；更通常的情況是，只允許幾天的時間。
既然完全的重測不可能，我們必須決定如何使用很好的時間來進行測試。但是我們怎么知道怎么做呢？我們怎么預見這些不可預見的問題呢？（就像老板要求你把這些會出現的意外情況做個列表一樣可笑�。�
現實中，我們總是有測試壓力，即使當測試一個新的系統時�？偸遣粔驎r間去完成所有應該完成的測試，因此我們必須充分利用可用的時間，用最好的方法去測試。我們在這種情況下我們必須使用“基于風險的測試方法” 。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
