分类：
2008-10-15 16:43:04
“但是，它仅仅是一个很小很小的改动！我们怎么会预先想到它会造成这么大的问题？”
怎么会，确实！
回归（向后追溯）是软件系统的现实生活。即使之前是很好地工作的，但是不能确保它会在最近的“很小”的改变后也能工作。是的，模块设计和充分的系统架构可以减少这种问题的出现，但是不能完全消除。
回归是永远都需要的。但是我们在非常有限的时间里一个“很小”的改动，我们怎么进行充分的回归测试呢？我们怎么知道查找哪些方面？我们怎么减少出现问题的风险？
回归的问题
回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加，更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。
随着系统构建的时间越长回归的问题也会增多。在几年后，可能已经被更改了很多次，通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构，更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多，系统变得越复杂直到变得非常脆弱。
脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱，人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆（不可维护）是旧的软件系统被替换的主要原因之一。
回归测试的困难
因为任何系统都需要回归，所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢？对一个只是1周多点的开发，我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了；更通常的情况是，只允许几天的时间。
既然完全的重测不可能，我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢？我们怎么预见这些不可预见的问题呢？（就像老板要求你把这些会出现的意外情况做个列表一样可笑！）
现实中，我们总是有测试压力，即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试，因此我们必须充分利用可用的时间，用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。
[1]
