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

  • Z时代
  • 2024-01-10
  • 分类：综合

重新测试

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

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

过程

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

  • 开发团队可能会接受或拒绝该错误。如果开发团队同意修复该问题，将包含在后续版本中。该错误的状态将是“准备进行 QA”。

  • 测试人员现在检查错误以查看它是否已被解决。重新测试是这种测试的术语。重新测试是一种定期进行的测试方法。我们使用了与之前版本中使用的相同的测试用例和测试数据。

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

我们什么时候应该重新测试

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

  • 当错误被拒绝时 - 有时，开发团队会拒绝测试人员发现的一些问题，理由是错误的状态为不可重现。在这种情况下，测试人员必须重新测试相同的问题，以确保它对开发人员来说是合法且可重复的。

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

    产品不应该在修改代码并重新测试问题修复后推出；我们还必须进行回归测试。

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

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

回归测试确保新代码修改不会对当前功能产生意外后果。它保证在进行最近的代码修改后旧代码继续运行。

回归测试是必需的-需要进行回归测试出现最多的时候有需要改变的代码，我们需要看到的软件程序是否改变的代码影响其他部分。当向软件程序引入新功能以及错误和性能问题时，也需要进行回归测试。

回归测试：分步指南

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

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

所有的测试都应该重复。

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

回归测试的选择

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

测试用例优先级

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

回归测试测试用例选择

根据行业统计，客户报告的很大一部分缺陷是由最后一刻的错误补丁引起的，这些补丁具有意想不到的后果，这使得选择测试用例进行回归测试成为一门艺术，而不是一项简单的任务。以下测试场景可用于创建有效的回归测试 -

  • 具有大量缺陷的测试场景

  • 如果功能更加明显，用户将能够看到更多功能。

  • 测试产品基本特性的测试场景

  • 经历过重大和近期变化的功能的案例研究

  • 用于集成的所有测试用例

  • 所有广泛的测试用例

  • 边值检验案例

  • 一些成功的测试示例如下所示。

  • 一系列故障测试场景

回归测试工具

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

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

  • Avo 保证

  • 茄子

  • 硒

  • 快速测试专家 (QTP)

  • Rational 功能测试器 (RFT)

配置管理和回归测试

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

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

  • 在回归测试阶段，不得修改代码。开发人员更改不得影响回归测试代码。

  • 有必要隔离用于回归测试的数据库。不允许数据库更新。

一个好的回归方法可以为企业节省时间和金钱。根据银行业的一项案例研究，回归在问题修复中最多可节省 60% 的时间和 40% 的资金（这可以通过回归测试发现）。

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

回归测试与重新测试

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

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

  • 缺陷验证不包含在回归测试中，但包含在重新测试中。

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

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

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

回归测试重新测试

回归测试用于确保最近的程序或代码修改没有损坏任何现有功能。

解决故障后，进行重新测试以确保在最终执行中失败的测试用例通过。

回归测试的目标是确保新的代码修改不会影响当前的功能。

在缺陷修复的基础上，进行重新测试。

回归测试不包括缺陷验证。

重新测试包括缺陷检查。

回归测试和重新测试可以同时进行，具体取决于项目和可用资源。

重新测试比回归测试具有更高的优先级，因此它在回归测试之前完成。

回归测试可能是自动化的，但手动测试可能成本高昂且耗时。

重新测试的测试用例不能自动化。
回归测试测试是一种用于各种目的的测试重新测试是一种定期进行的测试方法。
通过的测试用例将接受回归测试只有失败的测试用例才会进行重新测试。
回归测试寻找意外的结果重新测试可确保初始问题已得到解决。
回归测试仅在修改现有项目或需要修改时执行使用全新构建，重新测试会运行具有相同数据和环境但输入不同的缺陷。

回归测试用例可以在功能规范、用户培训和手册以及修复问题的缺陷报告中找到。

在开始测试之前，无法获取重新测试的测试用例

以上是 回归测试和重新测试的比较 的全部内容， 来源链接： utcz.com/z/341321.html

回到顶部