确认测试或再测试是针对缺陷的修正进行的测试，用的是发现此缺陷的同一个测试用例，测试用例也可能会进行适当的调整。确认测试或再测试的主要目的是确认缺陷的修正是有效的。

　　回归测试是指测试以前测试并修改过的程序，确保变更没有给软件其他未变更部分带来新的缺陷。软件修改后或使用环境变更后要执行回归测试。回归测试在整个软件测试过程中占有很重要的地位，是保证软件质量的一个重要测试活动。回归测试可以应用在各个测试级别：组件测试、集成测试、系统测试和验收测试。

　　在软件开发生命周期中的任何一个阶段都可能会发生软件的变更。软件变更之后都需要开展相应的回归测试。可能的变更包括：

　　● 缺陷的修复。

　　● 版本变更和升级（例如：增加了新的功能或采用了新的技术）。

　　● 数据库的变更和升级。

　　● 软件使用平台的变更和升级（例如：软件运行环境的变更等）。

　　在进行回归测试的时候，必须采用合适的回归测试策略确定回归测试的范围。这涉及回归测试用例选择的策略。下面是几种常用的回归测试策略：

　　● 零回归测试：针对缺陷的修复，只做确认测试，即重新运行所有发现缺陷的测试用例，判断新的软件版本是否已经修正了这些缺陷。针对新增功能，只运行所有新增加的功能测试用例，用来判断是否正确实现了新的功能，这是正常测试的一部分。这种策略并没有进行任何回归测试，所以也称为零回归测试。

　　● 基于风险的回归测试：是基于风险的分析而展开的，这种方法需要进行变更影响分析。确定变更如何影响现有系统的过程，也称之为影响分析，它有助于决定回归测试的广度和深度。回归测试的范围取决于变更影响分析的结果。

　　● 完全回归测试：这个策略不考虑变更影响，重新运行所有的测试用例，这是一种安全的回归测试策略，遗漏缺陷的风险小，但是测试成本很高。

　　零回归测试只进行了很少的测试，而完全回归测试运行了所有的测试用例，它们在实际测试过程中可能运用的都比较少，因为零回归测试存在的风险比较高，而完全回归测试工作量巨大。一般来说，基于风险的回归测试在测试过程中运用比较多，由于对软件变更进行了相关的影响分析，测试重点会放在软件变更可能会影响的功能和模块。在平衡进度、成本和质量的前提下，尽量覆盖风险高的功能和模块，例如：系统中增加了一个新的功能，需要分析新增加的功能对已有系统的影响，那些和新增加功能有关联的其他功能模块是选择回归测试用例的重点。