回歸的風險

回歸的風險

陳能技

2007-10-11

原文：the risk of regression – alan s.koch

「但是，它僅僅是乙個很小很小的改動！我們怎麼會預先想到它會造成這麼大的問題？」

怎麼會，確實！

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

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

回歸的問題

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

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

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

回歸測試的困難

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

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

現實中，我們總是有測試壓力，即使當測試乙個新的系統時。總是不夠時間去完成所有應該完成的測試，因此我們必須充分利用可用的時間，用最好的方法去測試。我們在這種情況下我們必須使用「基於風險的測試方法」。

基於風險的測試

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

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

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

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

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

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

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

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

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

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

50%的測試專注於新改的分期付款模組 -

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

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

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

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