软件测试中的回归测试的风险

　　“但是，它仅仅是一个很小很小的改动!我们怎么会预先想到它会造成这么大的问题?”

　　怎么会，确实!

　　回归(向后追溯)是软件系统的现实生活。即使之前是很好地工作的，但是不能确保它会在最近的“很小”的改变后也能工作。是的，模块设计和充分的系统架构可以减少这种问题的出现，但是不能完全消除。

　　回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动，我们怎么进行充分的回归测试呢?我们怎么知道查找哪些方面?我们怎么减少出现问题的风险?

　　回归的问题

　　回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加，更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。

　　随着系统构建的时间越长回归的问题也会增多。在几年后，可能已经被更改了很多次，通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构，更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多，系统变得越复杂直到变得非常脆弱。

　　脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱，人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆(不可维护)是旧的软件系统被替换的主要原因之一。

　　回归测试的困难

　　因为任何系统都需要回归，所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢?对一个只是1周多点的开发，我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了;更通常的情况是，只允许几天的时间。

　　既然完全的重测不可能，我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢?我们怎么预见这些不可预见的问题呢?(就像老板要求你把这些会出现的意外情况做个列表一样可笑!)

　　现实中，我们总是有测试压力，即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试，因此我们必须充分利用可用的时间，用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。

　　基于风险的测试

　　基于风险的测试的本质是我们评估系统不同部分蕴含的风险，并专注于我们的测试在那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试，甚至完全不测，但是它保证了这样做的风险是最低的。

　　“风险”对于测试与风险对于其他任何情况是一样的。为了评估风险，我们必须认识到它有两个截然不同的方面：可能性和影响。

　　-“可能性”是可能出错的机会。不考虑影响程度，仅仅考虑出现问题的机会有多大。

　　-“影响”是确实出错后造成的影响程度。不考虑可能性，仅仅考虑出现的问题的情况会有多糟糕。

　　假设一个会计系统，我们更改了分期付款的利息。更改会用3天的时间，我们会用2天的时间来测试。因为我们不能在两天时间内完全充分测试这个会计系统，我们需要评估所作的更改给其它系统部分带来的风险。

　　-分期付款模块的功能会很可能出错，因为这些是更改的部分。它们同时是对系统来说相对影响重大的部分，因为它们影响收入。既是高可能性的，又是高影响程度的，意味着系统的这部分必须投入充分的测试。

　　-应收款模块拥有中等程度的错误可能性，因为改变的功能是这个模块的一个紧密组成部分。因为收款模块影响收入，因此出错的影响程度是高的。所以收款模块也需要投入足够的测试关注，因为它拥有中-高程度的风险。

　　-总账模块拥有低程度的错误可能性。但是如果错误会对公司有重大的影响。因此总账模块拥有低-高程度的风险。

　　-最后，应付款出错的可能性很低，因为更改功能与它没有什么关系。而且这个模块错误后的影响最多也是中等程度的。因此拥有低-中程度风险，不需要投入太多的测试。

　　使用这些风险信息，我们可能选择这样分配我们的测试：

　　- 50%的测试专注于新改的分期付款模块

　　- 30%的测试放在应收款模块

　　- 15%的测试放在总账模块

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