什么是回归测试？

回归测试是一种黑盒测试技术。它用于验证软件中的代码更改不会影响产品的现有功能。回归测试确保产品在新功能、错误修复或对现有功能的任何更改下都能正常工作。

回归测试是软件测试的一种类型。重新执行测试用例，以检查应用程序先前功能的运行情况，以及新的更改是否产生了任何错误。

当原始功能发生重大变化时，可以在新的构建版本上执行回归测试。它确保即使在发生更改时代码仍然可以工作。回归意味着重新测试应用程序中未更改的部分。

回归测试也称为验证方法。测试用例通常是自动化的。测试用例需要执行多次，手动一遍又一遍地运行相同的测试用例既耗时又乏味。

回归测试示例

在这里，我们将通过一个案例来有效地定义回归测试。

假设有一个产品 Y，其中一个功能是触发确认、接受和已发送邮件。还需要对其进行测试，以确保代码的更改不会影响它们。回归测试不依赖于任何编程语言，如Java、C++、C#等。此方法用于测试产品的修改或任何更新。它确保产品中的任何更改都不会影响产品的现有模块。验证已修复的错误和新增的功能不会在先前工作版本的软件中造成任何问题。

我们何时可以进行回归测试？

每当生产代码被修改时，我们都会进行回归测试。

我们可以在以下情况下执行回归测试，它们是：

1. 当应用程序中添加新功能时。

示例

一个网站有一个登录功能，只允许用户使用电子邮件登录。现在提供一个新功能，可以使用 Facebook 登录。

2. 当有变更需求时。

示例

从登录页面移除了先前适用的“记住密码”功能。

3. 当缺陷被修复时。

示例

假设登录页面上的登录按钮不工作，测试人员报告了一个错误，指出登录按钮已损坏。一旦开发人员修复了错误，测试人员会对其进行测试，以确保登录按钮按预期结果工作。同时，测试人员会测试与登录按钮相关的其他功能。

4. 当有性能问题修复时。

示例

主页加载需要 5 秒，将加载时间减少到 2 秒。

5. 当环境发生变化时。

示例

当我们将数据库从 MySql 更新到 Oracle 时。

如何进行回归测试？

当软件维护包括增强、纠错、优化和删除现有功能时，就需要进行回归测试。这些修改可能会影响系统功能。在这种情况下，回归测试变得必要。

回归测试可以使用以下技术进行：

1. 全部重新测试

“全部重新测试”是进行回归测试的方法之一。在这种方法中，应重新执行所有测试用例套件。在这里，我们可以将重新测试定义为：当一个测试失败，并且我们确定失败的原因是软件故障时，故障被报告，我们可以期待一个新版本的软件，其中缺陷已被修复。在这种情况下，我们将需要再次执行测试以确认故障已修复。这被称为重新测试。有些人会将其称为确认测试。

全部重新测试非常昂贵，因为它需要大量的时间和资源。

2. 回归测试选择

• 在这种技术中，将执行选定的测试用例套件，而不是整个测试用例套件。
• 选定的测试用例套件分为两种情况：
  1. 可重用测试用例。
  2. 过时测试用例。
• 可重用测试用例可以在后续的回归周期中使用。
• 过时测试用例不能在后续的回归周期中使用。

3. 测试用例的优先级排序

根据业务影响、关键性和常用功能对测试用例进行优先级排序。选择测试用例将减少回归测试套件。

回归测试工具有哪些？

回归测试是质量保证（QA）过程中至关重要的一部分；在执行回归测试时，我们可能会面临以下挑战：

• 耗时
  回归测试需要大量时间才能完成。回归测试涉及再次进行现有测试，因此测试人员对重新运行测试并不感到兴奋。
• 复杂
  当需要更新任何产品时，回归测试也很复杂；测试列表也在增加。
• 沟通业务规则
  回归测试确保现有产品功能仍在正常工作。与非技术领导者沟通回归测试可能是一项艰巨的任务。高管希望看到产品向前发展，而投入大量时间进行回归测试以确保现有功能正常工作可能很难。
• 识别影响区域
• 测试用例逐个版本增加
• 资源较少
• 没有准确性
• 重复性任务
• 单调的工作

回归测试过程

回归测试过程可以在构建版本和发布版本之间进行。

跨构建版本的回归测试

每当修复了错误，我们都会重新测试该错误，如果存在任何依赖模块，我们就会进行回归测试。

例如，如果我们有不同的构建版本，如构建 1、构建 2 和构建 3，它们具有不同的场景，我们如何执行回归测试。

构建1

• 首先，客户将提供业务需求。
• 然后开发团队开始开发功能。
• 之后，测试团队将开始编写测试用例；例如，他们为产品的 release#1 编写了 900 个测试用例。
• 然后，他们将开始执行测试用例。
• 产品发布后，客户会进行一轮验收测试。
• 最后，产品被移至生产服务器。

构建2

• 现在，客户要求增加 3-4 个额外（新）功能，并提供新功能的需求。
• 开发团队开始开发新功能。
• 之后，测试团队将开始为新功能编写测试用例，他们编写了大约 150 个新测试用例。因此，两个版本总共编写的测试用例数量为 1050 个。
• 现在测试团队开始使用 150 个新测试用例测试新功能。
• 完成后，他们将借助 900 个测试用例开始测试旧功能，以验证添加新功能是否损坏了旧功能。
• 在这里，测试旧功能被称为回归测试。
• 一旦所有功能（新的和旧的）都经过测试，产品将移交给客户，然后客户将进行验收测试。
• 验收测试完成后，产品将移至生产服务器。

构建3

• 在第二次发布后，客户希望移除其中一个功能，比如“销售”。
• 然后他/她将删除所有属于销售模块的测试用例（大约 120 个测试用例）。
• 然后，测试其他功能以验证在移除销售模块测试用例后，所有其他功能是否正常工作，这个过程在回归测试下完成。

注意

• 测试稳定功能以确保它没有因为更改而损坏。这里的更改意味着修改、添加、错误修复或删除。
• 在不同的构建或发布版本中重新执行相同的测试用例，以确保更改（修改、添加、错误修复或删除）不会在稳定功能中引入错误。

跨发布版本的回归测试

回归测试过程在同一项目有新版本发布时开始，因为新功能可能会影响先前版本中的旧元素。

为了理解回归测试过程，我们将遵循以下步骤：

步骤 1

在Release#1中没有回归测试，因为在 Release#1 中没有发生修改，因为这个版本本身就是新的。

步骤 2

回归测试的概念从Release#2开始，当客户提出一些新需求时。

步骤 3

在获得新需求（修改功能）后，他们（开发人员和测试工程师）首先会理解需求，然后再进行影响分析。

步骤 4

在理解了新需求之后，我们将进行一轮影响分析以避免重大风险，但这里的问题是谁来进行影响分析？

步骤 5

影响分析由客户根据他们的业务知识，开发人员根据他们的编码知识，以及最重要的是，由测试工程师完成，因为他们有产品知识。

注意：如果由单个人进行，他/她可能无法覆盖所有影响区域，所以我们包括所有人员，以便我们可以覆盖最大的影响区域，并且影响分析应该在发布的早期阶段完成。

步骤 6

一旦我们完成了影响区域的分析，开发人员将准备影响区域（文档），客户也将准备影响区域文档，这样我们就可以实现影响分析的最大覆盖范围。

步骤 7

完成影响分析后，开发人员、客户和测试工程师将把影响区域文档的报告#发送给测试负责人。与此同时，测试工程师和开发人员正忙于开发新的测试用例。

步骤8

一旦测试负责人收到报告#，他/她将整合这些报告并存储在版本#1 的测试用例需求库中。

注意：测试用例库：在这里，我们将保存所有版本的测试用例。

步骤 9

之后，测试负责人将借助 RTM（需求可追溯性矩阵）从测试用例库中挑选必要的回归测试用例，并将这些文件放入回归测试套件中。

注意

• 测试负责人会将回归测试用例存储在回归测试套件中，以免将来混淆。
• 回归测试套件：在这里，我们将保存所有影响区域的测试文档。
• 回归测试用例：这些是旧版本测试文档的测试用例，需要重新执行，如下图所示。

步骤 10

之后，当测试工程师完成新测试用例的工作后，测试负责人将分配回归测试用例给测试工程师。

步骤 11

当所有回归测试用例和新功能都稳定并通过后，使用测试用例检查影响区域，直到旧功能和新功能都稳定为止，然后将其移交给客户。

回归测试的类型

回归测试的不同类型如下：

1. 单元回归测试 [URT]
2. 区域回归测试 [RRT]
3. 完整或完全回归测试 [FRT]

1) 单元回归测试 [URT]

在这种测试中，我们只测试改变的单元，而不是影响区域，因为它可能会影响同一模块的组件。

示例 1

在下面的应用程序中，在第一个构建版本中，开发人员开发了一个接受1-15个字符的搜索按钮。然后测试工程师借助测试用例设计技术测试了这个搜索按钮。

现在，客户对需求进行了一些修改，并要求搜索按钮可以接受1-35个字符。测试工程师将只测试搜索按钮，以验证它是否接受1-35个字符，并且不检查第一个构建版本的任何其他功能。

示例 2

在这里，我们有Build B001，并且发现了一个缺陷，报告已提交给开发人员。开发人员将修复该错误并随同在第二个Build B002中开发的一些新功能一起发送。之后，测试工程师只在缺陷修复后进行测试。

• 测试工程师会发现点击提交按钮会跳转到一个空白页面。
• 这是一个缺陷，已发送给开发人员进行修复。
• 当新的构建版本带着错误修复一起到来时，测试工程师将只测试“提交”按钮。
• 在这里，我们不会检查第一个构建版本的其他功能，而是转而测试在第二个构建版本中发送的新功能。
• 我们确定修复提交按钮不会影响其他功能，所以我们只测试已修复的错误。

因此，我们可以说，只测试已更改的功能被称为单元回归测试。

2) 区域回归测试 [RRT]

在这种测试中，我们将测试修改以及影响区域或地区，这被称为区域回归测试。在这里，我们测试影响区域，因为如果存在依赖模块，它也会影响其他模块。

例如

在下图中，我们可以看到我们有四个不同的模块，即模块 A、模块 B、模块 C 和模块 D，它们是由开发人员在第一个构建版本期间提供用于测试的。现在，测试工程师将在模块 D中发现错误。错误报告被发送给开发人员，开发团队修复这些缺陷并发送第二个构建版本。

在第二个构建版本中，之前的缺陷已被修复。现在测试工程师了解到，模块 D 中的错误修复已经影响了模块 A 和模块 C中的某些功能。因此，测试工程师首先测试错误已修复的模块 D，然后检查模块 A 和模块 C中的影响区域。因此，这种测试被称为区域回归测试。

在执行区域回归测试时，我们可能会遇到以下问题：

问题

在第一个构建版本中，客户发送了一些需求修改，并希望在产品中添加新功能。这些需求被发送给开发和测试两个团队。

收到需求后，开发团队开始进行修改，并根据需求开发新功能。

现在，测试负责人向客户发送邮件，询问他们在必要的修改完成后会受到影响的所有影响区域。因此，客户会了解哪些功能需要再次测试。他/她还会向开发团队发送邮件，以了解由于更改和新增功能，应用程序中的哪些区域会受到影响。

同样，客户向测试团队发送一封邮件，索取影响区域的列表。因此，测试负责人将从客户、开发团队以及测试团队收集影响列表。

这份影响列表会发送给所有测试工程师，他们查看列表并检查他们的功能是否被修改，如果是，他们就会进行区域回归测试。影响区域和修改区域都由各自的工程师进行测试。每个测试工程师只测试由于修改可能受到影响的他们自己的功能。

上述方法的问题在于，测试负责人可能无法完全了解影响区域，因为开发团队和客户可能没有太多时间回复他/她的邮件。

解决方案

为了解决上述问题，我们将遵循以下流程：

当一个新的构建版本带着最新的功能和错误修复到来时，测试团队将安排会议，他们将讨论由于上述修改，他们的功能是否受到影响。因此，他们将进行一轮影响分析并生成影响列表。在这个特定的列表中，测试工程师试图包含最大可能的影响区域，这也降低了发现缺陷的机会。

当新的构建版本到来时，测试团队将遵循以下流程：

• 他们将进行冒烟测试，以检查应用程序的基本功能。
• 然后他们将测试新功能。
• 之后，他们将检查已更改的功能。
• 一旦他们检查完已更改的功能，测试工程师将重新测试错误。
• 然后，他们将通过执行区域回归测试来检查影响区域。

使用单元和区域回归测试的缺点

以下是使用单元和区域回归测试的一些缺点：

• 我们可能会错过一些影响区域。
• 我们可能会识别出错误的影响区域。

注意：我们可以说，我们在区域回归测试上做的工作越多，就会发现越多的缺陷。但是，如果我们以同样的专注度进行全回归测试，我们发现的缺陷会更少。因此，我们可以确定，增加测试工作量并不能帮助我们发现更多的缺陷。

3) 全回归测试 [FRT]

在产品的第二次和第三次发布期间，客户要求增加 3-4 个新功能，并且需要修复一些先前版本的缺陷。然后测试团队将进行影响分析，并确定上述修改将导致我们测试整个产品。

因此，我们可以说，测试已修改的功能和所有剩余的（旧）功能被称为全回归测试。

我们什么时候进行全回归测试？

当我们有以下情况时，我们将执行 FRT（全回归测试）：

• 当产品的源文件中发生修改时。例如，JVM 是 JAVA 应用程序的根文件，如果 JVM 中发生任何变化，那么整个 JAVA 程序都将被测试。
• 当我们必须执行 n 次更改时。

注意

区域回归测试是回归测试的理想方法，但问题是，在执行区域回归测试时我们可能会漏掉很多缺陷。

在这里，我们将借助以下方法来解决这个问题：

• 当应用程序交付测试时，测试工程师将测试前 10-14 个周期，并进行RRT（区域回归测试）。
• 然后在第 15 个周期，我们进行 FRT（全回归测试）。然后，在接下来的 10-15 个周期，我们进行区域回归测试，在第 31 个周期，我们进行全回归测试，我们将继续这样进行。
• 但在发布的最后十个周期，我们将只执行完全回归测试。

因此，如果我们遵循上述方法，我们可以发现更多的缺陷。

手动重复进行回归测试的缺点

• 生产力会下降。
• 这是一项困难的工作。
• 测试执行的一致性不高。
• 测试执行时间也增加了。

因此，为了解决这些问题，我们将采用自动化；当我们有n个回归测试周期时，我们将采用自动化回归测试过程。

自动化回归测试过程

通常，当有多个发布版本、多个回归周期或重复性任务时，我们会选择自动化。

自动化回归测试过程可以按以下步骤完成：

注1

使用某些工具测试应用程序的过程称为自动化测试。

假设我们以一个登录模块的示例为例，我们如何执行回归测试。

在这里，登录可以通过两种方式完成，如下所示：

手动：在这种方式下，我们只会进行一到两次回归测试。

自动化：在这种方式下，我们将多次进行自动化，因为我们必须编写测试脚本并执行。

注意2：在实际操作中，如果我们遇到一些问题，例如：

步骤 1

当新版本开始时，我们不会进行自动化，因为没有回归测试和回归测试用例的概念，正如我们在上述过程中所理解的。

步骤 2

当新版本和增强功能开始时，我们有两个团队，即手动团队和自动化团队。

步骤 3

手动团队将审查需求，识别影响区域，并将需求测试套件移交给自动化团队。

步骤 4

现在，手动团队开始处理新功能，而自动化团队将开始开发测试脚本并自动化测试用例，这意味着回归测试用例将被转换为测试脚本。

步骤 5

在他们（自动化团队）开始自动化测试用例之前，他们还会分析哪些用例可以自动化，哪些不能。

步骤 6

根据分析，他们将开始自动化，即将每个回归测试用例转换为测试脚本。

步骤 7

在此过程中，他们将借助回归用例，因为他们既不了解产品，也不了解工具和应用程序。

步骤8

一旦测试脚本准备就绪，他们将开始在新应用程序[旧功能]上执行这些脚本。因为测试脚本是借助回归功能或旧功能编写的。

步骤 9

执行完成后，我们会得到不同的状态，如通过/失败。

步骤 10

如果状态为失败，则需要手动重新确认，如果存在错误，则将报告给相关开发人员。当开发人员修复该错误后，手动测试工程师需要重新测试该错误以及影响区域，自动化测试工程师也需要重新执行脚本。

步骤 11

这个过程会一直持续，直到所有新功能和回归功能都通过为止。

通过自动化测试进行回归测试的好处

• 准确性始终存在，因为任务是由工具完成的，而工具永远不会感到厌烦或疲倦。
• 测试脚本可以在多个发布版本中重复使用。
• 使用自动化可以实现批量执行，即所有编写的测试脚本可以并行或同时执行。
• 尽管回归测试用例的数量逐个发布版本增加，我们也不必增加自动化资源，因为一些回归用例已经从之前的发布版本中自动化了。
• 这是一个节省时间的过程，因为执行速度总是比手动方法快。

如何为回归测试选择测试用例？

从行业检查中发现，客户报告的若干缺陷是由于最后一刻的错误修复造成的。这些修复产生了副作用，因此为回归测试选择测试用例是一门艺术，并非易事。

回归测试可以通过以下方式完成：

• 一个经常出现缺陷的测试用例
• 对用户更可见的功能。
• 验证产品核心功能的测试用例。
• 所有集成测试用例
• 所有复杂的测试用例
• 边界值测试用例
• 成功测试用例的样本
• 失败的测试用例

回归测试工具

如果软件频繁变更，回归测试的成本也会增加。在这些情况下，手动执行测试用例会增加测试执行时间和成本。在这种情况下，自动化测试是最佳选择。自动化的持续时间取决于在后续回归周期中保持可重用的测试用例数量。

以下是用于回归测试的重要工具：

Selenium

Selenium 是一个开源工具。该工具用于 Web 应用程序的自动化测试。对于基于浏览器的回归测试，使用 Selenium。Selenium 用于基于 Web 的应用程序的 UI 级别回归测试。

Ranorex Studio

用于桌面、Web 和移动应用程序的一体化回归测试自动化，内置 Selenium WebDriver。Ranorex Studio 包括完整的 IDE 以及用于无代码自动化的工具。

Quick Test Professional (QTP)

QTP 是一种用于回归测试和功能测试的自动化测试工具。它是一个数据驱动、基于关键字的工具。它使用 VBScript 语言进行自动化。如果我们打开 QTP 工具，我们会看到三个按钮，即录制、播放和停止。这些按钮有助于记录在计算机系统上执行的每次点击和操作。它记录操作并回放。

Rational Functional Tester (RTF)

Rational Functional Tester 是一个 Java 工具，用于自动化软件应用程序的测试用例。RTF 用于自动化回归测试用例，并且它也与 Rational Functional Tester 集成。

有关回归和自动化测试工具的更多信息，请参考以下链接：

自动化测试工具

回归测试和配置管理

在敏捷环境中，代码不断被修改，回归测试中的配置管理变得至关重要。为确保有效的回归测试，我们必须遵循以下步骤：

• 在回归测试阶段不允许对代码进行更改。
• 回归测试用例必须不受开发者更改的影响。
• 用于回归测试的数据库必须是隔离的；不允许对数据库进行更改。

重新测试与回归测试的区别

重新测试（Re-testing）意味着再次测试功能或错误，以确保代码已修复。如果未修复，缺陷无需重新打开。如果已修复，则关闭缺陷。

重新测试是一种测试类型，用于检查在最终执行中不成功的测试用例，在缺陷修复后是否成功通过。

回归测试意味着在软件应用程序进行代码更改时对其进行测试，以确保新代码没有影响软件的其他部分。

回归测试是一种测试类型，用于检查代码更改是否没有改变应用程序的现有功能。

重新测试和回归测试的区别如下：

回归测试的优势

回归测试的优势有：

• 回归测试提高了产品质量。
• 它确保任何错误修复或更改都不会影响产品的现有功能。
• 自动化工具可用于回归测试。
• 它确保已修复的问题不会再次发生。

回归测试的缺点

虽然回归测试有几个优点，但也有缺点。

• 对于代码中的微小更改也应进行回归测试，因为即使是微小的代码更改也可能在现有功能中产生问题。
• 如果项目中没有使用自动化进行测试，那么反复执行测试将是一项耗时且乏味的任务。

结论

回归测试是至关重要的方面之一，因为它有助于交付高质量的产品，从而为组织节省时间和金钱。它通过确保代码中的任何更改都不会影响现有功能，来帮助提供高质量的产品。

为了自动化回归测试用例，有多种自动化工具可用。工具应具备更新测试套件的能力，因为回归测试套件需要频繁更新。