回归测试？
什么是回归测试？
回归测试是一种黑盒测试技术。它用于验证软件中的代码更改不会影响产品的现有功能。回归测试确保产品在新功能、错误修复或任何更改
回归测试是一种软件测试。重新执行测试用例以检查应用程序以前的功能是否正常工作，并且新的更改没有产生任何错误。
当有重大更改时，可以在新构建上执行回归测试在原始功能中。它确保即使发生更改，代码仍然有效。回归是指重新测试应用程序中没有改变的部分。
回归测试也称为验证方法。测试用例通常是自动化的。 测试用例需要多次执行并且手动一遍又一遍地运行相同的测试用例，既耗时又乏味.
回归测试示例
这里我们将通过一个案例来有效地定义回归测试:
考虑一个产品 Y ，其中一项功能是触发确认、接受和发送电子邮件。它还需要进行测试以确保代码中的更改不会影响它们。回归测试不依赖于任何编程语言，例如 Java、C++、C#等，此方法用于测试产品进行修改或任何更新。它确保产品的任何更改都不会影响产品的现有模块。验证修复的错误和新添加的功能在软件的先前工作版本中没有造成任何问题。
我们什么时候可以进行回归测试？
每当修改生产代码时，我们都会进行回归测试。
我们可以在以下时间进行回归测试以下场景，它们是:
1.向应用程序添加新功能时。
示例:
网站具有登录功能，允许用户仅使用电子邮件登录.现在提供使用 Facebook 登录的新功能。
2.当有更改要求时。
示例:
记住从以前适用的登录页面中删除的密码。
3.当缺陷修复
示例:
假设登录按钮在登录页面中不起作用并且测试人员报告了一个错误，指出登录按钮坏了。一旦开发人员修复了错误，测试人员就会对其进行测试以确保登录按钮按预期结果工作。同时，测试人员测试与登录按钮相关的其他功能。
4.当出现性能问题时修复
示例:
加载主页需要 5 秒，将加载时间减少到 2 秒.
5.当环境发生变化时
示例:
当我们将数据库从 MySql 更新到 Oracle 时。
如何执行回归测试？
当软件维护包括增强、纠错、优化和删除现有功能时，就需要进行回归测试。这些修改可能会影响系统功能。在这种情况下需要进行回归测试。
可以使用以下技术进行回归测试:
1.重新测试所有:
重新测试是进行回归测试的方法之一。在这种方法中，所有的测试用例都应该重新执行。在这里，我们可以将重新测试定义为测试失败时，我们确定失败的原因是软件故障。报告了故障，我们可以期待修复缺陷的新版本软件。在这种情况下，我们需要再次执行测试以确认故障已修复。这称为重新测试。有些人将此称为确认测试。
重新测试非常昂贵，因为它需要大量的时间和资源。
2.回归测试选择:
在这种技术中，将执行选定的测试用例套件，而不是整个测试用例套件。
所选的测试用例套装分为两种情况 可重复使用的测试用例。 过时的测试用例。
可重复使用的测试用例可用于后续回归周期。
过时的测试用例不能用于后续的回归周期。
3.测试用例的优先级:
根据业务影响、关键和常用功能确定测试用例的优先级。测试用例的选择将减少回归测试套件。
什么是回归测试工具？
回归测试是 QA 过程的重要组成部分；在执行回归时，我们可能会面临以下挑战:
耗时
回归测试需要大量时间才能完成。回归测试再次涉及现有测试，因此测试人员不会很高兴重新运行测试。
复杂
当需要更新任何产品时，回归测试也很复杂；测试列表也在增加。
沟通业务规则
回归测试可确保现有产品功能仍处于正常工作状态。与非技术领导者就回归测试进行沟通可能是一项艰巨的任务。该高管希望看到产品向前发展，并在回归测试上投入大量时间以确保现有功能正常工作。
确定影响区域
测试用例逐个增加发布
更少的资源
不准确
重复性任务
单调的工作
回归测试过程
回归测试过程可以跨构建和发布执行。
跨构建的回归测试
每当错误修复时，我们都会重新测试错误，如果有任何依赖模块，我们会进行回归测试。
例如，我们如何进行回归测试，如果我们有不同的版本，如版本 1、版本 2 和版本 3，它们具有不同的场景。
Build1
首先由客户提供业务需求。
然后开发团队开始开发功能。
之后，测试团队将开始编写测试用例；例如，他们为产品的第 1 版发布了 900 个测试用例。
然后，他们将开始实施测试用例。
产品发布后，客户会进行一轮验收测试。
最后，产品被转移到生产服务器。
Build2
现在，客户要求添加 3-4 个额外(新)功能，并提供新功能的要求。
开发团队开始开发新功能。
之后，测试团队将开始为新功能编写测试用例，他们编写了大约 150 个新测试用例。因此，两个版本的测试用例总数均为 1050 个。
现在测试团队开始使用 150 个新测试用例测试新功能。
完成后，他们将在 900 个测试用例的帮助下开始测试旧功能，以验证添加新功能是否损坏了旧功能。
在这里，测试旧功能称为回归测试。
在测试完所有功能(新旧功能)后，将产品移交给客户，然后客户将进行验收测试。
验收测试完成后，产品将移至生产服务器。
Build3
在第二次发布后，客户想要删除销售等功能之一。
然后他/她将删除属于销售模块的所有测试用例(大约 120 个测试用例)。
然后，测试其他功能以验证在删除销售模块测试用例后所有其他功能是否都正常工作，此过程在回归测试下完成。
注意:
测试稳定功能以确保它因更改而损坏。此处的更改意味着修改、添加、错误修复或删除。
在不同的构建或发布中重新执行相同的测试用例是为了确保更改(修改、添加、错误修复或删除) 不会在稳定功能中引入错误。
整个版本的回归测试
每当同一项目有新版本时，回归测试过程就会开始，因为新功能可能会影响以前的旧元素
要了解回归测试过程，我们将按照以下步骤进行:
Step1
没有回归测试在 Release#1 中，因为 Release#1 中没有发生任何修改，因为该版本本身是新的。
Step2
当客户提出一些新要求时，回归测试的概念从发布#2开始。
Step3
首先获得新需求(修改功能)后，他们(开发人员和测试工程师)会在进行影响分析之前了解需求。
Step4
了解新要求后，我们将执行一轮d 影响分析以避免重大风险，但这里出现了谁来做影响分析的问题？
Step5
影响分析由客户根据他们的业务知识完成，开发人员根据他们的编码知识完成，最重要的是，它由测试工程师完成，因为他们拥有产品知识。
注意: 如果一个人这样做，他/她可能不会覆盖所有的影响区域，所以我们包括所有的人，以便我们可以覆盖最大的影响区域，并且影响分析应该在发布的早期阶段完成。
Step6
一旦我们完成了影响区域，那么开发人员将准备 >影响区域(文档)，客户也会准备影响区域文档，以便我们达到影响分析的最大覆盖范围.
Step7
完成影响分析后，开发人员、客户和测试工程师将发送报告# 将影响区域文档发送给测试主管。与此同时，测试工程师和开发人员正忙于处理新的测试用例。
Step8
一旦测试主管收到报告# ，他/她将整合报告并将其存储在测试用例需求存储库中以供发布#1使用。
注意: Test case Repository: 在这里，我们将保存所有发布的测试用例。
Step9
之后，Test Lead 将借助 RTM 选择必要的回归测试用例 来自测试用例存储库，这些文件将放置在回归测试套件中。
注意:
测试负责人会将回归测试用例存储在回归测试套件中，以免进一步混淆。
回归测试套件: 在这里，我们将保存所有影响区域的测试文档。
回归测试用例: 这些是旧版本文本文档的测试用例，需要重新执行，如下图所示:
Step10
之后也就是说，当测试工程师完成新测试用例的工作后，测试负责人会将回归测试用例分配给测试工程师。
Step11
当所有回归测试用例和新特性稳定并通过时，然后使用测试用例检查影响区域，直到它持久旧功能加上新功能，然后交给客户。
回归测试的类型
回归测试的不同类型如下:
单元回归测试 [URT]
区域回归测试[RRT]
完整或完整的回归测试 [FRT]
单元回归测试[URT]
在这里，我们将只测试更改的单元，而不是影响区域，因为它可能会影响同一模块的组件。
Example1
在下面的应用程序和第一个构建中，开发人员开发了接受 1-15 个字符的搜索按钮。然后测试工程师在测试用例设计技术的帮助下测试搜索按钮。
现在，客户端对需求做了一些修改，并要求搜索按钮可以接受1-35个字符。测试工程师将仅测试"搜索"按钮以验证它需要 1-35 个字符，并且不会检查第一个构建的任何其他功能。
示例 2
在这里，我们有 Build B001，并且发现了一个缺陷，并将报告提交给开发人员。开发人员将修复该错误并随同在第二个 Build B002 中开发的一些新功能一起发送。之后，测试工程师将在修复缺陷后进行测试。
测试工程师会发现点击提交按钮会转到空白页面。
这是一个缺陷，它被发送给开发人员进行修复。
当新版本与错误修复一起出现时，测试工程师将只测试提交按钮。
在这里，我们不会检查第一个版本的其他功能，而是测试新功能并在第二个版本中发送。
我们确信修复提交按钮不会影响其他功能，因此我们只测试修复的错误。
因此，我们可以说只测试改变的特征称为单元回归测试。
区域回归测试 [RRT]
在这里，我们将测试修改以及影响区域或区域，称为区域回归测试。在这里，我们正在测试影响区域，因为如果有可靠的模块，它也会影响其他模块。
例如:
在下面正如我们所看到的，我们有四个不同的模块，例如模块 A、模块 B、模块 C 和模块 D，这些模块由开发人员在第一次构建期间提供用于测试。现在，测试工程师将识别模块 D 中的错误。错误报告发送给开发人员，开发团队修复这些缺陷并发送第二个构建版本。
在第二次构建中，修复了以前的缺陷。现在测试工程师了解到模块 D 中的错误修复影响了模块 A 和模块 C 中的一些功能。因此，测试工程师首先测试已修复错误的模块 D，然后检查模块 A 和模块 C 中的影响区域。因此，这种测试被称为区域回归测试。
在进行区域回归测试时，我们可能会面临以下问题:
问题:
在第一次构建中，客户发送了一些需求修改，还想在产品中添加新功能。需求发送给两个团队，即开发和测试。
在得到需求后，开发团队开始进行修改，并根据需求开发新功能。
现在，测试负责人向客户发送邮件，并询问他们在进行必要的修改后将受到影响的所有区域。因此，客户会得到一个想法，即所有功能都需要再次测试。并且他/她还将向开发团队发送邮件，了解应用程序中的哪些区域将因新功能的更改和添加而受到影响。
同样，客户发送一封邮寄给测试团队以获取影响区域的列表。因此，测试负责人将从客户、开发团队和测试团队那里收集影响列表。
这个影响列表被发送给所有查看的测试工程师在列表中检查他们的功能是否被修改，如果是，则他们进行区域回归测试。影响区域和修改区域均由各自的工程师进行测试。每个测试工程师只测试他们可能因修改而受到影响的功能。
上述方法的问题在于测试负责人可能无法全面了解影响区域，因为开发团队和客户可能没有太多时间回复他/她的邮件。
解决方案
为了解决上述问题，我们将按照以下步骤进行过程:
什么时候一个新版本伴随着最新的功能和错误修复，测试团队将安排会议，他们将讨论他们的功能是否因上述修改而受到影响。因此，他们将进行一轮影响分析并生成影响列表。在这个特定的列表中，测试工程师试图将最大可能的影响区域包围起来，这也降低了获得缺陷的机会。
当新版本到来时，测试团队将遵循以下程序:
他们将进行冒烟测试以检查应用程序的基本功能。
然后他们将测试新功能。
之后，他们将检查更改的功能。
在检查完更改的功能后，测试工程师将重新测试错误。
然后他们将通过执行区域回归测试来检查影响区域。
使用单元和区域回归测试的缺点
以下是使用单元和区域回归测试的一些缺点:
我们可能会错过一些影响区域。
我们可能确定了错误的影响区域。
注意: 我们可以说我们在区域回归测试上所做的主要工作会导致我们得到更多的缺陷。但是，如果我们对完全回归测试进行同样的工作，我们将得到更少的缺陷。因此，我们可以在此确定测试工作的增强不会帮助我们获得更多缺陷。
Full Regression testing [FRT]
在产品的第二和第三次发布期间，客户要求添加3-4个新功能，还有一些缺陷需要从以前的版本中修复。然后测试团队会进行影响分析，并确定上述修改将导致我们测试整个产品。
因此，我们可以说测试修改后的功能和
<强>
所有剩余(旧)功能称为完全回归测试。
什么时候进行Full Regression testing？
当我们有以下条件时，我们会进行FRT:
当产品的源文件中发生修改时。 例如，JVM是JAVA应用的根文件，如果JVM有任何变化，那么整个JAVA程序都会被测试。
当我们必须执行 n 次更改时。
注意:
区域回归测试是回归测试的理想方法，但问题是，我们在执行区域回归测试时可能会遗漏很多缺陷回归测试。
这里我们将借助以下方法解决这个问题:
在提交测试申请时，测试工程师将测试前 10-14 个周期，并进行RRT。
然后在第 15 个周期，我们进行 FRT。同样，对于接下来的 10-15 个周期，我们会进行区域回归测试，而对于第 31 个周期，我们会进行完整的回归测试，我们将继续这样.
但对于发布的最后十个周期，我们将仅执行完整的回归测试。
因此，如果我们按照上面的方法，我们会得到更多的缺陷。
手动重复进行回归测试的缺点:
生产力会下降。
这是一项艰巨的工作。
测试执行没有一致性。
测试执行时间也增加了。
因此，我们将通过自动化来解决这些问题；当我们有 n 个回归测试周期时，我们将进行自动化回归测试流程。
自动化回归测试流程
一般来说，每当有多个版本或多个回归周期或重复性任务时，我们都会进行自动化。
自动化回归测试过程可以通过以下步骤完成:
注意 1:
使用某些工具测试应用程序的过程称为自动化测试。
假设我们以一个 登录模块，那么我们如何进行回归测试。
这里，登录可以通过两种方式完成，如下所示:
手动: 在这里，我们将只执行一次和两次回归。
自动化: 在这里，我们将多次进行自动化因为我们必须编写测试脚本并执行。
注意: 注2: 在实时中，如果我们遇到一些问题，例如:
| 问题 |
处理 |
| 新功能 |
人工测试工程师 |
| 回归测试功能 |
自动化测试工程师 |
| 剩余(110 个功能 + 版本#1) |
人工测试工程师 |
Step1
当新版本开始时，我们不去自动化，因为我们没有回归测试和回归测试用例的概念
Step2
当新版本和增强开始时，我们有两个团队，即手动团队和自动化团队
Step3
手动团队将检查需求并确定影响区域并移交需求测试套件 strong> 自动化团队。
Step4
现在，手动团队开始研究新功能，自动化团队将开始开发测试脚本并开始自动化测试用例，这意味着回归测试用例将被转换为测试脚本。
Step5
在他们(自动化团队)开始自动化测试用例之前，他们还将分析哪些所有案例都可以自动化。
Step6
基于分析，他们将开始自动化，即转换每个回归
Step7
在这个过程中，他们会借助回归案例，因为他们没有产品知识以及工具和应用程序。
Step8
一旦测试脚本准备就绪，他们将开始在新应用程序[旧功能]上执行这些脚本。因为，测试脚本是在回归特性或旧特性的帮助下编写的。
Step9
一旦执行完成，我们得到一个不同的状态，如通过/失败。
Step10
如果状态失败，这意味着它需要重新手动确认，如果存在Bug，则会向相关开发人员报告。当开发者修复那个bug时，这个bug需要手动测试工程师和Impact area一起重新测试，脚本也需要自动化测试工程师重新执行。
Step11
这个过程一直持续到所有的新特性，并且回归特性将通过。
通过自动化测试进行回归测试的好处:
准确性始终存在，因为任务是由工具完成的，工具永远不会感到无聊或疲倦。
测试脚本可以在多个版本中重复使用。
批量执行可以使用自动化，即；所有编写的测试脚本可以并行或同时执行。
即使回归测试用例的数量增加了每个版本的发布，我们也不必增加自动化资源，因为一些回归案例已经从上一个版本开始自动化。
这是一个节省时间的过程，因为执行总是比手动方法快。
回归测试如何选择测试用例？
行业检测发现。客户报告的几个缺陷是由于最后一刻修复了错误。这些会产生副作用并因此为回归测试选择测试用例是一门艺术，而不是一项容易的任务。
回归测试可以通过:
经常出现缺陷的测试用例
用户更容易看到的功能。
测试用例验证产品的核心功能。
所有集成测试用例
所有复杂的测试用例
边界值测试用例
成功的测试用例示例
测试用例失败
回归测试ng 工具
如果软件经常变化，回归测试成本也会增加。在这些情况下，手动执行测试用例会增加测试执行时间和成本。在这种情况下，自动化测试是最好的选择。自动化的持续时间取决于在连续回归周期中保持可重用的测试用例数量。
以下是用于回归测试的基本工具:
Selenium
Selenium 是一个开源工具。此工具用于自动测试 Web 应用程序。对于基于浏览器的回归测试，使用了 selenium。 Selenium 用于基于 Web 的应用程序的 UI 级回归测试。
Ranorex Studio
适用于桌面、Web 和移动应用程序的多合一回归测试自动化带有内置的 Selenium Web 驱动程序。 Ranorex Studio 包括完整的 IDE 和用于无代码自动化的工具。
Quick Test Professional(QTP)
QTP 是用于回归和功能测试的自动化测试工具.它是一个数据驱动的、基于关键字的工具。它使用 VBScript 语言进行自动化。如果我们打开 QTP 工具，我们会看到三个按钮，分别是录制、播放和停止。这些按钮有助于记录在计算机系统上执行的每一次点击和操作。
Rational Functional Tester( RTF)
Rational 功能测试器是一种 Java 工具，用于自动化软件应用程序的测试用例。 RTF 用于自动化回归测试用例，它还与理性功能测试仪集成。
什么是回归测试和配置管理？
回归测试中的配置管理在代码不断修改的敏捷环境中变得势在必行。为确保回归测试有效，我们必须遵循以下步骤:
在回归测试阶段不允许更改代码。
回归测试用例必须不受开发人员更改的影响。
用于回归测试的数据库必须是隔离的；数据库中不允许更改。
重新测试和回归测试有什么区别？
重新测试是指再次测试功能或错误以确保代码固定。如果未设置，则不需要重新打开缺陷。如果修复，则缺陷关闭。
重新测试是一种测试，用于检查在最终执行中不成功的测试用例在缺陷修复后是否成功通过。
回归测试是指在软件应用程序发生代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。
回归测试是为了检查代码是否没有改变应用程序的现有功能而执行的一种测试。
重新测试和回归测试之间的区别是如下:
| 重新测试 |
回归测试 |
| 重新测试是为了确保在最终执行中失败的测试用例在修复缺陷后通过。 |
进行回归测试以确认代码更改是否未影响现有功能。 |
| 重新测试可修复缺陷。 |
回归测试的目的是确保代码更改不会对现有功能产生不利影响。 |
| 缺陷验证是重新测试的一部分。 |
回归测试不包括缺陷验证 |
| Retesting的优先级高于Regression Testing，所以在Regression Testing之前进行。 |
根据项目类型和资源的可用性，回归测试可以与重新测试并行。 |
| 重新测试是有计划的测试。 |
回归测试是一种通用测试。 |
| 我们无法自动化重新测试的测试用例。 |
我们可以做回归测试的自动化；手动测试可能既昂贵又耗时。 |
| 重新测试是针对失败的测试用例。 |
回归测试是针对通过的测试用例。 |
| 重新测试确保原来的故障被纠正。 |
回归测试检查意外的副作用。 |
| 重新测试使用相同的数据和相同的环境以不同的输入和新的构建执行缺陷。 |
回归测试是指对现有项目进行修改或更改成为强制性的。 |
| 不能在开始测试之前重新测试。 |
回归测试可以从功能规范、用户教程和手册中获取测试用例，以及关于更正问题的缺陷报告。 |
回归测试的优点是什么？
优点回归测试是:
回归测试可提高产品质量。
它确保任何错误修复或更改都不会影响产品的现有功能。
自动化工具可用于回归测试。
它确保已修复的问题不会再次发生。
回归测试的缺点是什么？
回归测试有几个优点，但也有缺点。
应对代码中的微小更改进行回归测试，因为即使代码中的微小更改也会在现有功能中产生问题。
如果项目中没有使用自动化进行测试，则一次又一次地执行测试将是一项耗时且乏味的任务。
结论
回归测试是必不可少的方面之一，因为它有助于交付高质量的产品，从而节省组织的时间和金钱。通过确保代码中的任何更改不会影响现有功能，它有助于提供高质量的产品。
对于自动化回归测试用例，有多种自动化工具可用。工具应该能够更新测试套件，因为回归测试套件需要经常更新。
