共计 1883 个字符，预计需要花费 5 分钟才能阅读完成。
前言
前面我们聊过《软件测试笔记（十七）回归测试的介绍和工具选择》，今天要分享的是缺陷的重新验证，这个回归测试的概念很相似，但又有所不同，下面会和大家详细聊聊缺陷的重新验证和它们之间的差异。
缺陷的重新验证定义
定义很明确：确保在早期版本中发现并发布的缺陷在当前版本中得到修复或不被修复。
更简单地说，重新测试就是在修复某个特定的错误之后对其进行测试。
例如，发布了版本 1.0。在测试版本 1.0 时，测试发现了一些缺陷（例如，缺陷 ID 1.0.1 并提交到缺陷系统。测试团队测试 Build1.1 中的缺陷 ID1.0.1，以确定缺陷是否已修复。
按照缺陷生命周期，一旦测试人员发现缺陷，就会将缺陷报告给开发团队。缺陷的状态应该是“提交”。开发团队可以接受或拒绝这个缺陷。如果开发团队接受这个缺陷，那么他们会修复它并在下一个或者几个版本中发布它(取决于缺陷的修复的难易程度)。缺陷的状态将是“准备好进行测试”。现在测试人员验证这个缺陷，以确定它是否被解决。这种测试称为重新验证测试。重新验证测试是一项计划性测试。我们使用的测试用例与我们在早期构建中使用的测试数据相同。如果没有发现缺陷，那么我们将缺陷的状态更改为“已修复”，否则我们将状态更改为“未修复”，并将缺陷重新发送给开发团队。
何时执行缺陷的重新验证？
- 如果在发行说明中指定了特定的错误修复：一旦开发团队发布了新的版本，那么测试团队就必须测试已经发布的修复后的缺陷，以确保缺陷是否被修复。
- 当错误被拒绝时：有时，开发团队会拒绝一些由测试人员提出的缺陷，并提到缺陷的状态是“不可重现”。在这种情况下，测试人员需要重新测试同一个问题，让开发人员知道该问题是有效的和可重现的。
为了避免这种情况，我们需要编写一个好的缺陷报告。请参阅《软件测试笔记（九）怎么样写才是一个好的缺陷报告？》。
缺陷的重新验证及同回归测试的区别
定义不同：
回归测试
当生产代码被修改时，我们都会进行软件回归测试。通常，我们在以下情况下执行回归测试：
- 当新功能添加到应用程序时。示例：一个网站有一个登录功能，允许用户只使用电子邮件登录。现在，新功能看起来像是“提供了一个新功能，可以使用微信登录”。
- 当有变更需求时。示例：从之前可用的登录页中删除“记住密码”。
- 当有缺陷修复时。示例：假设登录按钮在登录页面中不起作用，测试人员报告缺陷，指出登录按钮已损坏。一旦开发人员修复了这个缺陷，测试人员就会测试它，以确保登录按钮是否按照预期的结果工作。同时测试人员回归测试与登录按钮相关的其他功能。
- 当出现性能问题修复时。示例：加载主页需要 5 秒钟将加载时间缩短到 2 秒，我们需要保证主页相关的回归测试都能正常通过。
- 当环境发生变化时。示例：将数据库从 MySQL 更新为 Oracle。
- 当有代码重构的时。
- 缺陷的重新验证
以确保在早期生成中发现并发布的缺陷在当前生成中是否得到修复。
实例
下面以一个登陆界面作为我们比较两者的区别的案例。首先，我们假设两种情况：
案例 1：登录页面 - 登录按钮不起作用（错误）
案例 2：登录页面 - 添加了“保持登录”复选框（新功能）
在案例 1 中，登录按钮不起作用，所以测试人员报告一个缺陷。一旦修复了这个错误，测试人员就会测试它，以确保登录按钮是否按照预期的结果工作。
在前面，也有一篇关于《软件测试笔记（六）缺陷报告应该涵盖哪些内容》的文章，可以帮助更好的提交缺陷。
在案例 2 中，测试人员测试新特性以确保新特性（保持登录）是否按预期工作。
案例 1 正在缺陷的重新验证中。在这里，测试人员使用错误报告中提到的重现步骤，重新测试在早期构建中发现的错误。
同样在案例 1 中，测试人员测试与登陆按钮相关的其他功能，我们称之为回归测试。
在案例 2 中，测试人员测试新功能（保持登录状态）并测试相关功能。在测试新特性的同时测试相关的功能将进行回归测试。
另一个例子：
想象一下，一个正在测试的应用软件有三个模块，即管理、购买和财务。财务模块依赖于采购模块。如果测试人员在购买模块上发现一个缺陷并提交。缺陷修复后，测试人员需要重新测试，以验证与购买相关的缺陷是否修复，并且测试人员还需要进行回归测试，以测试依赖于购买模块的财务模块。
回归和复测之间的一些其他差异：
对失败的测试用例进行缺陷的重新验证，而对通过的测试用例进行回归测试。
缺陷的重新验证确保原始缺陷已被纠正，而回归测试确保没有意外的副作用。
总结
这里大家可以了解了缺陷的重新验证的定义，以及什么时候我们需要执行缺陷的重新验证。同时也对比了非常会让人混淆的回归测试，以及其应用的场景，希望对大家有所帮助。如果大家关于缺陷的重新验证及同回归测试有什么想法，也请留言区回复。
