确定测试或者说再（重新）测试，和回归测试是两个概念。但是有些测试成熟度等级较低的组织经常会把回归测试等同于再测试，当软件发生更改之后，只进行了再测试，却没有进行回归测试，这会给软件带来很大的风险。
什么是再测试？
再测试 是仅针对缺陷的修正进行的测试，使用的是与发现该缺陷相同的测试用例（测试用例也可能会进行适当的调整），主要目的只是确认变更是否有效。
什么是回归测试？
回归测试 要测试的软件是通过测试发现了缺陷并对缺陷完成了修正的，回归测试的主要目的是确保变更没有给软件带来新的缺陷。
所以，回归测试要运行的测试用例就不能只是原来发现缺陷的那个测试用例，至少还应覆盖软件的常用的和重要的功能。
软件在它的生命周期中的任何一个阶段都可能会发生变更，软件变更之后都需要开展相应的回归测试。
回归测试可以在各个测试级别进行：单元测试、集成测试、配置项测试、系统测试和第三方测试。
回归测试的时机——软件可能的变更包括：
- 因修复缺陷进行的变更。
- 因需求变更或者采用新技术带来的变更。
- 因数据库的变更和升级带来的变更。
- 因软件运行环境的改变带来的变更。
要想回归测试有效，必须确定合适的回归测试的范围。选择回归测试用例的策略有以下几种：
- 零回归测试：所谓零回归测试就是没有进行任何回归的测试，即只进行了再测试，仅验证发现的缺陷的更改是否有效。
- 基于风险的回归测试（推荐）：这种回归测试不仅覆盖已经发生变更的功能模块，还要覆盖那些风险优先级较高——一旦发生风险就会造成严重后果的功能模块。
- 完全回归测试：这个策略不考虑变更影响，重新运行所有的测试用例。
这三种回归测试策略中，零回归测试的风险比较大，而完全回归测试的成本比较高，所以采用最多的就是基于风险的回归测试。
总之，再测试只验证更改是否有效，回归测试却能保证软件在更改后不会引入新的缺陷，所以软件更改之后必须要做回归测试，而不能只做再测试。
这正是：
软件变更做测试，验证更改是其一
不要引入新缺陷，回归方能达目的
源自公众号 软件工程之思