回归测试是一套复杂完整的测试，用来测试嵌入在PostgreSQL里的的SQL实现。它同时测试标准SQL操作和PostgreSQL的扩展SQL。这个套件最初是Jolly Chen和Andrew Yu开发的，并且由Marc Fournier和Thomas Lockhart进行了大量的改进和重新封装。自PostgreSQL 6.1以上开始，这个回归测试包含在每个正式发布版本里。

回归测试可以就一套已经安装好并且在运行的服务器进行测试，也可以就制作树里面临时安装的服务器进行测试。详细些说，有“并行”和“串行”运行测试之分。串行模式顺序运行每个测试，而并行模式激活多个服务器进程，并行地运行一组测试．并行测试使我们对进程内部通讯和锁的正确工作有足够的信心。由于历史原因，串行测试通常对一个现存的安装进行测试，而并行测试是“独立”的，不过这么做没有什么技术原因。

每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的I/O操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。

在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：

1. 能够测试软件的所有功能的代表性测试用例。
2. 专门针对可能会被修改影响的软件功能的附加测试。
3. 针对修改过的软件成分的测试。

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只包括那些涉及在主要的软件功能中出现的一个或多个错误类的那些测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

一、概述

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。 (待续)