什么是回归测试?

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

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

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

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

回归测试示例

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

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

我们什么时候可以执行回归测试?

只要生产代码被修改，我们都会进行回归测试。

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

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

例：

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

2.有变更要求时。

例：

记住以前从登录页面删除的密码。

3.修复缺陷时

例：

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

4.修复性能问题时

例：

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

5.环境发生变化时

例：

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

如何执行回归测试?

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

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

1.重新测试所有：

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

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

2.回归测试选择：

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

3.测试用例的优先顺序：

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

什么是回归测试工具?

回归测试是质量检查流程的重要组成部分。在执行回归时，我们可能面临以下挑战：

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

回归测试过程

可以跨构建和发行版执行回归测试过程。

整个版本的回归测试

每当修复了错误后，我们都会重新测试该错误，并且如果有任何依赖的模块，我们将进行回归测试。

例如，如果我们有不同的构建(例如Build 1，Build 2和Build 3) ，它们具有不同的方案，那么我们如何执行回归测试。

版本1

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

Build2

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

版本3

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

注意：

• 测试稳定的功能部件，以确保其因更改而损坏。此处的更改表示修改，添加，错误修复或删除。
• 在不同的内部版本或发行版中重新执行相同的测试用例是为了确保更改(修改，添加，错误修复或删除)不会在稳定的功能中引入错误。

整个版本中的回归测试

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

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

第1步

版本1中没有回归测试，因为版本本身是新版本，因此在版本1中没有进行任何修改。

第2步

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

第三步

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

步骤4

了解新要求后，我们将进行一轮影响分析以避免主要风险，但是这里出现了一个问题，谁来进行影响分析?

步骤5

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

注意：如果一个人这样做，则他/她可能不会覆盖所有影响区域，因此我们将所有人员包括在内，以便我们可以覆盖最大影响区域，并且应该在发布的早期阶段进行影响分析。

步骤6

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

步骤7

完成影响分析后，开发人员，客户和测试工程师会将影响区域文档的Reports＃发送给测试负责人。同时，测试工程师和开发人员正在忙于开发新的测试用例。

步骤8

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

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

步骤9

之后，测试负责人将利用RTM的帮助，从测试用例存储库中选择必要的回归测试用例，并将这些文件放置在回归测试套件中。

注意：

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

步骤10

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

步骤11

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

回归测试的类型

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

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

单位回归测试[URT]

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

例1

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

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

例2

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

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

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

区域回归测试[RRT]

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

例如：

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

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

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

问题：

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

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

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

同样，客户将邮件发送到测试团队以获取影响区域列表。因此，测试负责人将从客户，开发团队和测试团队收集影响列表。

该影响列表将发送给所有查看该列表的测试工程师，并检查其功能是否被修改，如果是，则进行区域回归测试。撞击区域和修改区域均由各自的工程师进行测试。每个测试工程师仅测试他们的功能，这些功能可能由于修改而受到影响。

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

解

要解决以上问题，我们将遵循以下过程：

当新版本附带最新功能和错误修复时，测试团队将安排会议，他们将讨论由于上述修改其功能是否受到影响。因此，他们将进行一轮影响分析并生成影响列表。在此特定列表中，测试工程师尝试将最大可能的冲击区域封闭起来，这也减少了获得缺陷的机会。

当有新的版本出现时，测试团队将遵循以下过程：

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

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

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

• 我们可能会错过一些影响领域。
• 我们可能会确定错误的影响区域。

注意：可以说，我们在区域回归测试中所做的主要工作将导致我们获得更多的缺陷。但是，如果我们将全力以赴地致力于全面回归测试，那么缺陷数量将会减少。因此，我们可以在此处确定测试工作的增强不会帮助我们获得更多的缺陷。

全面回归测试[FRT]

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

因此，可以说测试修改后的功能和所有其余(旧)功能称为完全回归测试。

当我们执行完全回归测试时?

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

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

注意：

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

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

• 当给出测试应用程序时，测试工程师将测试第一个10-14周期，并执行RRT 。
• 然后在第15个周期，我们进行FRT。同样，在接下来的10-15个周期中，我们进行区域回归测试，在第31个周期中，我们进行完整的回归测试，我们将继续这样。
• 但是对于该发行版的最后十个周期，我们将仅执行完整的回归测试。

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

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

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

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

自动化回归测试过程

通常，只要有多个版本或多个回归周期或存在重复性任务，我们就会寻求自动化。

自动化回归测试过程可以按照以下步骤进行：

注意1：

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

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

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

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

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

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

Issues	Handle by
New features	Manual test engineer
Regressing testing features	Automation test engineer
Remaining ( 110 feature + Release#1)	Manual test engineer

第1步

当新版本开始发行时，我们不追求自动化，因为在上面的过程中我们没有理解回归测试和回归测试用例的概念。

第2步

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

第三步

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

步骤4

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

步骤5

在他们(自动化团队)开始自动化测试用例之前，他们还将分析哪些情况下可以自动进行。

步骤6

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

步骤7

在此过程中，他们将利用回归案例，因为他们不具备产品知识以及工具和应用程序知识。

步骤8

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

步骤9

执行完成后，我们将获得不同的状态，例如Pass / fail 。

步骤10

如果状态失败，则意味着需要手动重新确认，并且如果该错误存在，则它将报告给相关的开发人员。开发人员修复该错误时，需要由手动测试工程师对Bug和Impact区域进行重新测试，并且还需要由自动化测试工程师重新执行脚本。

步骤11

这个过程一直进行到所有新功能和回归功能都通过为止。

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

• 精度始终存在，因为任务是由工具完成的，并且工具永远不会感到无聊或疲劳。
• 该测试脚本可以在多个版本中重复使用。
• 使用自动化即可以批量执行。所有书面测试脚本可以并行或同时执行。
• 即使回归测试用例的数量增加了每个版本的发布，我们也不必增加自动化资源，因为某些回归案例已经从上一版本开始实现了自动化。
• 这是一个节省时间的过程，因为执行总是比手动方法快。

如何选择测试用例进行回归测试?

它是通过行业检查发现的。客户报告的一些缺陷归因于最新的错误修复。这些产生副作用，因此选择测试用例进行回归测试是一门艺术，而不是一件容易的事。

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

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

回归测试工具

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

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

Selenium

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

Ranorex工作室

使用内置的Selenium Web驱动程序对台式机，Web和移动应用程序进行一体式回归测试自动化。 Ranorex Studio包括完整的IDE以及用于无代码自动化的工具。

快速测试专家(QTP)

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

Rational Functional Tester(RTF)

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

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

https://www.javatpoint.com/automation-testing-tool

什么是回归测试和配置管理?

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

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

重新测试和回归测试之间有什么区别?

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

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

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

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

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

Re-testing	Regression Testing
Re-testing is performed to ensure that the test cases that are failed in the final execution are passing after the defects fixed.	Regression Testing is done to confirm whether the code change has not affected the existing features.
Re-Testing works on defect fixes.	The purpose of regression testing is to ensure that the code changes adversely not affect the existing functionality.
Defect verification is the part of the Retesting.	Regression testing does not include defect verification
The priority of Retesting is higher than Regression Testing, so it is done before the Regression Testing.	Based on the project type and availability of resources, regression testing can be parallel to Retesting.
Re-Test is a planned Testing.	Regression testing is a generic Testing.
We cannot automate the test-cases for Retesting.	We can do automation for regression testing; manual testing could be expensive and time-consuming.
Re-testing is for failed test-cases.	Regression testing is for passed Test-cases.
Re-testing make sure that the original fault is corrected.	Regression testing checks for unexpected side effect.
Retesting executes defects with the same data and the same environment with different input with a new build.	Regression testing is when there is a modification or changes become mandatory in an existing project.
Re-testing cannot do before start testing.	Regression testing can obtain test cases from the functional specification, user tutorials and manuals, and defects reports in regards to the corrected problem.

回归测试的优点是什么?

回归测试的优点是：

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

回归测试的缺点是什么?

回归测试有很多优点，尽管也有缺点。

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

结论

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

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