回歸的風險

原文：The Risk of Regression – Alan S.Koch

        “但是，它僅僅是一個很小很小的改動！我們怎么會預先想到它會造成這么大的問題？”

        怎么會，確實！

        回歸（向后追溯）是軟件系統的現實生活。即使之前是很好地工作的，但是不能確保它會在最近的“很小”的改變后也能工作。是的，模塊設計和充分的系統架構可以減少這種問題的出現，但是不能完全消除。

        回歸測試是永遠都需要的。但是我們在非常有限的時間里測試一個“很小”的改動，我們怎么進行充分的回歸測試呢？我們怎么知道查找哪些方面？我們怎么減少出現問題的風險？

回歸的問題

        回歸的問題根源是軟件系統的內在復雜性。隨著系統的復雜性的增加，更改產生難以預見的影響的可能性也增加了。即使開發人員使用最新的技術也不可避免。

        隨著系統構建的時間越長回歸的問題也會增多。在幾年后，可能已經被更改了很多次，通常是由那些原本不在開發組中的人來修改的。即使這些人努力理解底層的設計和結構，更改與原本設計主題思想非常匹配也是很難做到的。這樣的更改越多，系統變得越復雜直到變得非常脆弱。

        脆弱的軟件就像脆弱的金屬。被彎曲和扭轉了這么多次以致你對它做的任何事都可能導致它的破裂。當一個軟件系統變得脆弱，人們實際上會很害怕改變它。他們知道他們做的任何事情都可能導致更多的問題。易脆（不可維護）是舊的軟件系統被替換的主要原因之一。

回歸測試的困難

        因為任何系統都需要回歸，所以回歸測試非常重要。但是誰有時間對每一個小的更改都完全地重新測試系統呢？對一個只是1周多點的開發，我們肯定不能承受1個月的完全重新測試整個系統。我們有一個星期的時間測試就很幸運了；更通常的情況是，只允許幾天的時間。

        既然完全的重測不可能，我們必須決定如何使用很好的時間來進行測試。但是我們怎么知道怎么做呢？我們怎么預見這些不可預見的問題呢？（就像老板要求你把這些會出現的意外情況做個列表一樣可笑?。?/P>

        現實中，我們總是有測試壓力，即使當測試一個新的系統時?？偸遣粔驎r間去完成所有應該完成的測試，因此我們必須充分利用可用的時間，用最好的方法去測試。我們在這種情況下我們必須使用“基于風險的測試方法” 。

基于風險的測試

        基于風險的測試的本質是我們評估系統不同部分蘊含的風險，并專注于我們的測試在那些最高風險的地方。這個方法可能讓系統的某些部分缺乏充分的測試，甚至完全不測，但是它保證了這樣做的風險是最低的。

        “風險”對于測試與風險對于其他任何情況是一樣的。為了評估風險，我們必須認識到它有兩個截然不同的方面：可能性和影響。

-          “可能性”是可能出錯的機會。不考慮影響程度，僅僅考慮出現問題的機會有多大。

-          “影響”是確實出錯后造成的影響程度。不考慮可能性，僅僅考慮出現的問題的情況會有多糟糕。

        假設一個會計系統，我們更改了分期付款的利息。更改會用3天的時間，我們會用2天的時間來測試。因為我們不能在兩天時間內完全充分測試這個會計系統，我們需要評估所作的更改給其它系統部分帶來的風險。

-          分期付款模塊的功能會很可能出錯，因為這些是更改的部分。它們同時是對系統來說相對影響重大的部分，因為它們影響收入。既是高可能性的，又是高影響程度的，意味著系統的這部分必須投入充分的測試。

-          應收款模塊擁有中等程度的錯誤可能性，因為改變的功能是這個模塊的一個緊密組成部分。因為收款模塊影響收入，因此出錯的影響程度是高的。所以收款模塊也需要投入足夠的測試關注，因為它擁有中-高程度的風險。

-          總賬模塊擁有低程度的錯誤可能性。但是如果錯誤會對公司有重大的影響。因此總賬模塊擁有低-高程度的風險。

-          最后，應付款出錯的可能性很低，因為更改功能與它沒有什么關系。而且這個模塊錯誤后的影響最多也是中等程度的。因此擁有低-中程度風險，不需要投入太多的測試。

        使用這些風險信息，我們可能選擇這樣分配我們的測試：

-          50%的測試專注于新改的分期付款模塊

-          30%的測試放在應收款模塊

-          15%的測試放在總賬模塊

-          5%的測試時間放在應付款模塊

        使用基于風險的測試策略不能保證沒有回歸。但是會顯著地減少對一個大系統進行的小更改的風險。

原文轉自：http://www.anti-gravitydesign.com