1. 什么是回归测试？

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

回归测试是一种软件测试。重新执行测试用例以检查应用程序的先前功能是否正常工作，并且新的更改没有产生任何错误。

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

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

2. 回归测试示例

在这里，我们将采用一个案例来有效地定义回归测试：

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

3. 我们什么时候可以执行回归测试？

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

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

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

例：

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

2. 当有变更要求时

例：

请记住以前适用的登录页面中删除的密码。

3.缺陷何时修复

例：

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

4. 当存在性能问题修复时

例：

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

5. 环境发生变化时

例：

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

4. 如何执行回归测试？

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

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

4.1 全部重新测试

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

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

4.2 回归测试选择

• 在此技术中，将执行选定的测试用例集，而不是整个测试用例集。
• 选定的测试用例分为两种情况

• 可重用的测试用例。
• 过时的测试用例。

• 可重用的测试用例可以在后续回归周期中使用。
• 过时的测试用例不能在后续回归周期中使用。

4.3 测试用例的优先级

根据业务影响、关键和经常使用的功能确定测试用例的优先级。选择测试用例将减少回归测集。

5. 什么是回归测试工具？

回归测试是 QA 流程的重要组成部分;在执行回归时，我们可能会面临以下挑战：

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

6. 回归测试过程

回归测试过程可以跨生成和发布执行。

6.1 跨构建的回归测试

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

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

构建1

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

构建2

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

  完成验收测试后，产品将移动到生产服务器。

构建3

• 在第二个版本之后，客户希望删除其中一个功能，如 Sales。
• 然后他将删除属于销售模块的所有测试用例（大约 120 个测试用例）。
• 然后，测试其他功能，以验证在删除销售模块测试用例后所有其他功能是否正常工作，并且此过程是在回归测试下完成的。

7. 跨版本的回归测试

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

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

步骤1

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

步骤2

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

步骤3

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

步骤4

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

步骤5

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

步骤6

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

步骤7

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

步骤8

一旦测试负责人获得报告，他将合并报告并存储在版本#1的测试用例需求存储库中。

步骤9

之后，测试主管将借助 RTM 并从测试用例存储库中选择必要的回归测试用例，这些文件将被放置在回归测试集中。

注意：

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

步骤10

之后，当测试工程师完成新测试用例的工作后，测试主管会将回归测试用例分配给测试工程师。

步骤11

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

8. 回归测试的类型

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

• 单元回归测试 [URT]
• 区域回归测试[RRT]
• 完整或完全回归测试 [FRT]

8.1 单元回归测试 [URT]

在这种情况下，我们将仅测试更改的单元，而不是影响区域，因为它可能会影响同一模块的组件。

例1

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

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

例2

在这里，我们有Build B001，并确定了缺陷，并将报告交付给开发人员。开发人员将修复该错误并发送在第二个版本 B002 中开发的一些新功能。之后，测试工程师将仅在缺陷修复后进行测试。

• 测试工程师将确定单击“提交”按钮将进入空白页。
• 这是一个缺陷，它被发送给开发人员进行修复。
• 当新版本附带错误修复时，测试工程师将仅测试“提交”按钮。
• 在这里，我们不会检查第一个构建的其他功能，而是继续测试新功能并在第二个构建中发送。
• 我们确信修复“提交”按钮不会影响其他功能，因此我们仅测试已修复的错误。

因此，我们可以说，仅通过测试更改的功能称为单元回归测试。

8.2 区域回归检验 [RRT]

在此，我们将测试修改以及影响区域或区域，称为区域回归测试。在这里，我们正在测试影响区域，因为如果有可靠的模块，它也会影响其他模块。

例如：

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

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

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

问题：

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

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

现在，测试负责人向客户端发送邮件，并询问他们所有影响区域都是在完成必要的修改后将受到影响的影响区域。因此，客户会得到一个想法，需要再次测试所有功能。他/她还将向开发团队发送邮件，以了解应用程序中的哪些区域将因新功能的更改和添加而受到影响。

同样，客户向测试团队发送邮件，以获取影响区域列表。因此，测试主管还将从客户端、开发团队和测试团队收集影响列表。

此影响列表将发送给所有查看列表并检查其功能是否被修改的测试工程师，如果是，则进行区域回归测试。冲击区域和修改区域都由各自的工程师进行测试。每个测试工程师只测试可能因修改而受到影响的功能。

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

解决方案

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

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

当新版本到来时，测试团队将遵循以下过程：

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

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

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

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

8.3 全回归测试 [FRT]

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

因此，我们可以说测试修改后的特征和所有剩余的特征称为完全回归测试。

当我们有以下条件时，我们将执行 FRT：

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

注意：

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

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

当测试申请被给出时，测试工程师将测试第一个10-14个周期，并将进行RRT。

然后在第 15 个周期，我们做 FRT。再一次，在接下来的10-15个周期，我们进行区域回归测试，对于第31个周期，我们进行完整的回归测试，我们将继续这样。

但是对于版本的最后十个周期，我们将只执行完整的回归测试。

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

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

• 生产力将下降。
• 这是一项艰巨的工作。
• 测试执行没有一致性。
• 并且测试执行时间也增加了。

因此，我们将进行自动化以解决这些问题;当我们有回归测试周期的 n 个数字时，我们将进行自动化回归测试过程。

9. 自动化回归测试流程

通常，每当有多个版本或多个回归周期或存在重复性任务时，我们都会进行自动化。

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

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

假设如果我们以一个 Login 模块的示例为例，那么我们如何执行回归测试。

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

手动地：在这种情况下，我们将只执行一次和两次回归。

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

注意2：实时，如果我们遇到一些问题，例如：

步骤1

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

步骤2

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

步骤3

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

步骤4

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

步骤5

在自动化团队开始自动化测试用例之前，他们还将分析哪些所有用例都可以自动化或不自动化。

步骤6

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

步骤7

在此过程中，他们将获得回归案例的帮助，因为他们没有产品知识以及工具和应用程序。

步骤8

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

步骤9

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

步骤10

如果状态为失败，这意味着需要手动重新确认，如果 Bug 存在，则它将报告给相关开发人员。当开发人员修复该 bug 时，手动测试工程师需要重新测试 Bug 以及影响区域，并且脚本也需要由自动化测试工程师重新执行。

步骤11

此过程一直持续到所有新功能和回归功能都将被传递。

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

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

10. 如何选择回归测试的测试用例？

它是从行业检查中发现的。客户报告的几个缺陷是由于最后一刻的错误修复造成的。这些会产生副作用，因此选择测试用例进行回归测试是一门艺术，而不是一件容易的事。

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

• 具有频繁缺陷的测试用例
• 用户更容易看到的功能
• 测试用例验证产品的核心功能
• 所有集成测试用例
• 所有复杂的测试用例
• 边界值测试用例
• 成功测试用例示例
• 测试用例失败

11. 回归测试工具

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

以下是用于回归测试的基本工具：

Selenium

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

Ranorex Studio

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

Quick Test Professional (QTP)

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

Rational Functional Tester (RTF)

RTF是一种 Java 工具，用于自动化软件应用程序的测试用例。RTF 用于自动化回归测试用例，并且它还与 rational 功能测试器集成。

12. 回归测试和配置管理

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

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

13. 重测和回归检验的区别

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

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

回归测试是指在软件应用程序发生代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。

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

重新测试和回归测试之间的差异如下：

14. 回归测试的优势

回归测试的优点是：

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

15. 回归测试的缺点

回归测试有几个优点，但也有缺点：

• 回归测试应该对代码中的微小更改进行，因为即使代码中的微小更改也会在现有功能中产生问题。
• 如果在项目中不使用自动化进行测试，则一次又一次地执行测试将是一项耗时且繁琐的任务。

16. 结论

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

为了自动化回归测试用例，有几种自动化工具可用。工具应该能够更新测试套件，因为回归测试集需要经常更新。