回归测试与重新测试的比较

重新测试

重新测试是指检查在最终执行中发现存在缺陷或错误的单个测试用例的过程。在大多数情况下，测试人员在测试软件程序时会发现这些缺陷，并将它们报告给开发人员进行更正。然后，开发人员修复错误并将其返回给测试人员进行审查。此持续过程称为重新测试。

示例 - 假设已发布版本 1.0。测试团队在测试版本 1.0 时发现了某些问题（例如，缺陷 ID 1.0.1 和缺陷 ID 1.0.2）并进行了报告。测试团队在版本 1.1 中检查缺陷 1.0.1 和 1.0.2（仅当版本 1.1 发行说明中指定了这两个问题时），以查看它们是否已得到解决。

流程

  • 一旦测试人员发现问题，就会根据缺陷生命周期将该缺陷提交给开发团队。该缺陷的状态应为“新建”。

  • 开发团队可能会接受或拒绝该缺陷。如果开发团队同意修复该问题，它将包含在下一个版本中。该缺陷的状态将变为“准备就绪，等待 QA”。

  • 现在，测试人员检查该缺陷以查看它是否已得到解决。这种类型的测试称为重新测试。重新测试是一种定期进行的测试方法。我们使用与先前版本中相同的测试用例和测试数据。

  • 如果未检测到该问题，则缺陷状态将更改为“已修复”，否则状态将更改为“未修复”，并将缺陷重新测试文档发送给开发团队。

何时应重新测试

  • 当发行说明中提到特定问题修复时 - 开发团队发布新版本后，测试团队必须测试之前报告的问题，以确保已解决这些问题。

  • 当缺陷被拒绝时 - 有时，开发团队会拒绝测试人员发现的一些问题，理由是该缺陷的状态为“无法重现”。在这种情况下，测试人员必须重新测试相同的问题，以确保它是合法的并且对于开发人员是可以重现的。

  • 当客户请求重新测试时 - 客户有时可能会要求我们重复测试，以建立对产品质量的信任。在这种情况下，测试团队将重新测试产品。

    修改代码后，绝不应仅重新测试问题修复就发布产品；我们还必须进行回归测试。

什么是回归测试以及它是如何工作的？

回归测试是一种软件测试类型，用于确保最近的程序或代码修改不会破坏当前的功能。回归测试只是对以前执行的测试用例进行完整或部分重新执行，以确认当前功能是否正常工作。

回归测试可确保新的代码修改不会对当前功能产生意外后果。它确保在进行了最新的代码修改后，旧代码继续发挥作用。

需要进行回归测试 - 当需要更改代码并且我们需要查看更改后的代码是否影响软件程序的其他部分时，回归测试的需求最常出现。当向软件程序引入新功能时，以及针对错误和性能问题，也需要进行回归测试。

回归测试：分步指南

要开始回归测试过程，我们必须首先调试代码以查找任何缺陷。在检测到缺陷并实施必要的修改后，通过从测试套件中选择涵盖更新和受影响代码部分的适当测试用例来执行回归测试。

软件维护包括增强功能、错误修复、优化和消除现有功能。这些更改可能会导致系统出现故障。因此，需要进行回归测试。可以使用以下策略进行回归测试

应重复所有测试。

这是回归测试方法之一，其中重新运行现有测试桶或套件中的所有测试。这非常昂贵，因为它需要大量的时间和金钱。

回归测试选择

回归测试选择是一种方法，其中从测试套件中运行一部分测试用例，以查看更新的代码是否对软件应用程序有任何影响。测试用例分为两类：可重用的测试用例，可在后续回归周期中重复使用；过时的测试用例，无法重复使用。

测试用例优先级

根据测试用例的业务影响、严重性和使用频率对其进行优先级排序。如果对测试用例进行优先级排序，则回归测试套件将大大减少。

回归测试测试用例选择

根据行业统计数据，客户报告的大部分缺陷是由最后时刻的错误修补程序造成的，这些修补程序产生了意外后果，这使得为回归测试选择测试用例成为一门艺术，而不是一项简单的任务。可以使用以下测试场景来创建有效的回归测试 -

  • 缺陷数量较多的测试场景

  • 如果功能更可见，用户将能够看到更多功能。

  • 测试产品基本功能的测试场景

  • 经历重大和最近更改的功能的案例研究

  • 所有集成测试用例

  • 所有扩展测试用例

  • 边界值测试用例

  • 下面显示了一些成功的测试示例。

  • 一系列失败的测试场景

回归测试工具

如果您的软件经常更新，则回归测试成本将会增加。在这种情况下，手动执行测试用例会增加测试执行时间和成本。在这种情况下，回归测试用例的自动化是最佳选择。自动化的程度取决于可以在后续回归周期中重复使用的测试用例的数量。

以下是软件工程中用于功能和回归测试的最重要的工具 -

  • Avo Assure

  • Eggplant

  • Selenium

  • Quick Test Professional (QTP)

  • Rational Functional Tester (RFT)

配置管理与回归测试

在代码不断更新的敏捷环境中，回归测试期间的配置管理变得至关重要。为了确保回归测试成功，请牢记以下几点 -

  • 应使用配置管理解决方案运行回归测试代码。

  • 在回归测试阶段，不允许对代码进行任何修改。开发人员更改不得影响回归测试代码。

  • 需要隔离用于回归测试的数据库。不允许进行任何数据库更新。

良好的回归方法可以为企业节省时间和金钱。根据银行业的一个案例研究，回归在问题修复方面节省了高达 60% 的时间和 40% 的金钱（这些问题本来可以通过回归测试发现）。

QA 候选人经常询问重新测试与回归测试。

回归测试与重新测试

  • 通过的测试用例会进行回归测试，而失败的测试用例会进行重新测试。

  • 回归测试查找意外后果，而重新测试确保已修复初始缺陷。

  • 回归测试不包括缺陷验证，而重新测试则包括缺陷验证。

  • 回归测试被称为通用测试，而重新测试被称为计划测试。

  • 自动化允许进行回归测试，但不允许进行重新测试。

下面提供了带有示例的完整比较。

回归测试重新测试

回归测试用于确保最近的程序或代码修改没有破坏任何现有的功能。在解决故障后，会进行重新测试以确保在最终执行中失败的测试用例通过。
回归测试的目标是确保新的代码修改不会影响当前的功能。根据缺陷修复，进行重新测试。
回归测试不包括缺陷验证。重新测试包括缺陷检查。
根据项目和可用资源，回归测试和重新测试可以同时进行。重新测试比回归测试具有更高的优先级，因此在回归测试之前完成。
回归测试可以自动化，但手动测试可能代价高昂且耗时。重新测试的测试用例无法自动化。
回归测试是一种用于各种目的的测试。重新测试是一种定期进行的测试方法。
通过的测试用例会进行回归测试。只有失败的测试用例才会进行重新测试。
回归测试查找意外后果。重新测试确保已解决初始问题。
仅当修改现有项目或需要修改时才执行回归测试。使用新的构建，重新测试使用相同的数据和环境但不同的输入运行缺陷。
回归测试用例可能存在于功能规范、用户培训和手册以及已修复问题的缺陷报告中。在开始测试之前，无法获取重新测试的测试用例

更新于： 2021年11月30日

649 次查看

启动你的职业生涯

通过完成课程获得认证

开始
广告