回归测试（Regression testing） 指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次 出现。通俗一点说，就是改完一堆bug之后，那些曾经正确的依然正确。

　　相信无论从底层的编程人员和测试人员，还是到顶层的项目管理者，都经历过客户的需求变更对项目带来的巨大影响。特别是在项目前期进展并不顺利的情况，突如其来的变更会使得程序员变得消极，焦虑，对自己的代码毫无信心， 系统偶尔出现奇怪行为就胡乱猜测，改了不该改的地方导致更多奇怪现象出现。而对于项目管理者则会发现每多一次的变更都让自己越来越感觉到项目质量不可控。

　　但实际上每次的变更都会做相应的回归测试，但为什么还会使项目组的成员产生如此不安的情绪呢。其实原因很简单，”我怎么知道改了这块会不会影响到其它功能，理论上应该不会，但我不敢保证”，”时间太紧了，大体测试了一下，功能基本没什么问题，但细节上不确定”上面这两种回答无疑是最常见的。那么如何解决上面这两个问题我认为最好的途径是正确的做好回归测试，上面两种状况虽然做了回归测试，但显然方法是错误的。

　　首先，要对回归测试进行的时机的误区进行纠正。回归测试并不是只在需求变更时进行，回归测试可以发生在软件生命周期的任意一个部分，从单元测试（ut），功能测试（ft），集成测试（it），甚至到发布测试。事实上渐进和快速迭代开发中更加频繁的回归测试可以更有效的提高代码质量，使得回归周期更短。因此对于程序员的建议是测试代码先行于功能代码，在程序debug阶段能够做到反复回归测试，维护测试用例库，那么到了测试阶段并会事倍功半。

　　其次，如何有效地进行回归测试，必须解决回归测试中的两个主要问题，一是测试用例的优化选择，二是覆盖率分析。对于第二点来说，当产品的开发周期并不是达到三五年的长度时，如果使用正确的测试用例，基本可以达到理想的覆盖率，而没有必要拿出成本来做这一项。所以在这里谈一下如果选择测试用例。要保证正确的测试用例，前提是有项目中有一个随时维护的测试用例库。对于测试用例库的维护来说， 要及时删除过时的测试用例，改进不受控制的测试用例，删除冗余的测试用例，增添新的测试用例。如果及时对测试用例库进行维护，那么当有新的需求变更时，我们要做的就是相关人员开一个审记会议，增加现有的测试用例来覆盖这些需求变更。当代码修改完毕时，只要能保证所有的测试用例能够全部正确，那么就可以保证这一次的变更不会引起新的BUG。这样即使需求、接口一改再改， 但是有密集的回归测试用例作保证，可以让程序员毫无顾忌的快速的去调整程序。高效高质的需求对应也会提高客户的满意度。

　　最后，回归测试是一件辛苦而且乏味的工作，但对于在软件生命同期来说又是必不可少的，因此对于回归测试来说自动化测试是必要的。 测试的自动化的程度越高，回归的周期就越短，效果越明显，软件的质量也越高，测试是否自动化也是开发是否敏捷的一个主要标志。