軟件測試中的回歸測試的風(fēng)險

　　“但是，它僅僅是一個(gè)很小很小的改動(dòng)!我們怎么會(huì )預先想到它會(huì )造成這么大的問(wèn)題?”

　　怎么會(huì )，確實(shí)!

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

　　回歸測試是永遠都需要的。但是我們在非常有限的時(shí)間里測試一個(gè)“很小”的改動(dòng)，我們怎么進(jìn)行充分的回歸測試呢?我們怎么知道查找哪些方面?我們怎么減少出現問(wèn)題的風(fēng)險?

　　回歸的問(wèn)題

　　回歸的問(wèn)題根源是軟件系統的內在復雜性。隨著(zhù)系統的復雜性的增加，更改產(chǎn)生難以預見(jiàn)的影響的可能性也增加了。即使開(kāi)發(fā)人員使用最新的技術(shù)也不可避免。

　　隨著(zhù)系統構建的時(shí)間越長(cháng)回歸的問(wèn)題也會(huì )增多。在幾年后，可能已經(jīng)被更改了很多次，通常是由那些原本不在開(kāi)發(fā)組中的人來(lái)修改的。即使這些人努力理解底層的設計和結構，更改與原本設計主題思想非常匹配也是很難做到的。這樣的更改越多，系統變得越復雜直到變得非常脆弱。

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

　　回歸測試的困難

　　因為任何系統都需要回歸，所以回歸測試非常重要。但是誰(shuí)有時(shí)間對每一個(gè)小的更改都完全地重新測試系統呢?對一個(gè)只是1周多點(diǎn)的開(kāi)發(fā)，我們肯定不能承受1個(gè)月的完全重新測試整個(gè)系統。我們有一個(gè)星期的時(shí)間測試就很幸運了;更通常的情況是，只允許幾天的時(shí)間。

　　既然完全的重測不可能，我們必須決定如何使用很好的時(shí)間來(lái)進(jìn)行測試。但是我們怎么知道怎么做呢?我們怎么預見(jiàn)這些不可預見(jiàn)的問(wèn)題呢?(就像老板要求你把這些會(huì )出現的意外情況做個(gè)列表一樣可笑!)

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

　　基于風(fēng)險的測試

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

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

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

　　-“影響”是確實(shí)出錯后造成的影響程度。不考慮可能性，僅僅考慮出現的問(wèn)題的情況會(huì )有多糟糕。

　　假設一個(gè)會(huì )計系統，我們更改了分期付款的利息。更改會(huì )用3天的時(shí)間，我們會(huì )用2天的時(shí)間來(lái)測試。因為我們不能在兩天時(shí)間內完全充分測試這個(gè)會(huì )計系統，我們需要評估所作的更改給其它系統部分帶來(lái)的風(fēng)險。

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

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

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

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

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

　　- 50%的測試專(zhuān)注于新改的分期付款模塊

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

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

原文轉自：http://www.uml.org.cn/Test/200902267.asp