什么是回归测试？
Thomas Hamilton 
Yumani Ranaweera 
什么是回归测试？
回归测试是指一种软件测试，用于确认最近的程序或代码更改并未对现有功能产生不利影响。我们也可以说它就是对已执行过的测试用例的全部或部分选择性地重新执行，以确保现有功能正常工作。
这种测试是为了确保新的代码更改不会对现有功能产生任何副作用。它确保在进行最新的代码更改后，旧代码仍然能够正常工作。
为什么要做回归测试？
回归测试过程在测试范围内至关重要。因为它可以识别代码更改或增强是否引入了新的缺陷或破坏了现有的功能测试。
没有回归测试过程，即使是微小的代码更改也可能导致代价高昂的错误。因此，它是一种系统性的实践，有助于保持软件质量。这种方法有助于防止已知问题的重复出现，并增强对软件的信心。
何时可以进行回归测试？
以下是您可以应用回归测试过程的场景。
向应用程序添加了新功能：当应用程序或网站中创建了新功能或模块时，就会发生这种情况。进行回归测试以查看在引入新功能时现有功能是否正常工作。
在需求变更的情况下：当系统中发生任何重大变更时，就会使用回归测试。进行此测试是为了检查这些变化是否影响了已有的功能。
修复缺陷后：开发人员在修复任何功能中的错误后会进行回归测试。这样做是为了确定修复错误时所做的更改是否影响了其他相关的现有功能。
性能问题修复后：在修复任何性能问题后，将触发回归测试过程，以查看它是否影响了其他现有的功能测试。
集成新外部系统时：每当产品与新的外部系统集成时，都需要进行端到端回归测试过程。
如何在软件测试中进行回归测试
如前所述，回归测试是基于对软件进行的任何更改触发的。它可以是 bug 修复、新功能集成等。每当发生此类工作时，QA 团队会执行下面给出的活动。这些任务在开始回归测试执行周期之前执行。
- 与开发团队讨论在更改期间涉及的具体模块和库
- 与产品负责人讨论新功能的变化，并了解其如何跨越或影响其他功能。
- 从现有测试套件中识别测试人员需要执行以回归现有功能的测试。
可以通过各种回归测试技术来确保有效的软件质量保证
重新测试所有
这是回归测试的一种方法，特别采用了回归测试套件。在这种情况下，应该重新执行现有的测试存储桶或套件中的所有测试。这是一种昂贵的方法，因为它需要大量的时间和资源。
回归测试选择
回归测试选择是一种技术，其中执行测试套件中的一些选定测试用例。它有助于测试修改后的代码是否会影响软件应用程序。这里，测试用例分为两部分。可重用测试用例可用于进一步的回归周期，而过时测试用例不能用于后续周期。
测试用例的优先级排序
测试用例的优先级取决于业务影响、关键性和常用功能测试。此外，基于优先级的测试用例排序大大减少了执行回归测试的精力。
为回归测试选择测试用例
行业数据显示，客户报告的大部分缺陷是由于最后一刻的 bug 修复造成的。这导致了副作用，因此，选择测试用例进行回归测试并非易事。
可以通过选择以下类型的测试用例来构建有效的回归测试套件 –
- 来自频繁出现缺陷的功能/模块的测试用例。
- 用户可见度更高的功能
- 验证产品核心功能的测试用例
- 近期更改过功能功能的测试用例。
- 所有集成重新测试
- 所有复杂的测试用例
- 边界值测试用例
- 选定的典型路径和负面测试用例
回归测试工具
如果您的软件经常发生更改，回归测试成本将会增加。因为手动执行测试用例会增加测试执行时间以及成本。在这种情况下，自动化回归测试是一个明智的选择。自动化程度取决于可重用于后续回归周期的测试用例数量。
以下是软件工程中用于功能和回归测试自动化的最重要工具
1) testRigor
testRigor 帮助您直接用普通英语将测试表达为可执行的规范。所有技术能力的用户都可以构建任何复杂度的端到端测试，涵盖移动、Web 和 API 步骤。测试步骤是以最终用户级别表达的，而不是依赖于 XPath 或 CSS 选择器等实现细节。
功能
- 免费永久公开版
- 测试用例为英文
- 无限用户和无限测试
- 学习自动化的最简单方法
- Web 步骤记录器
- 与 CI/CD 和测试用例管理集成
- 电子邮件和短信测试
- Web + 移动 + API 步骤在一个测试中
Selenium：Selenium 是用于自动化 Web 应用程序的最常用的开源工具。Selenium 可用于基于浏览器的回归测试。它支持 Java、Ruby、Python 等编程语言。
Quick Test Professional (QTP)：HP Quick Test Professional 是一款自动化软件，用于自动化功能和回归测试用例。它使用 VB Script 语言进行自动化。它是一个数据驱动、关键字驱动的工具。
Rational Functional Tester (RFT)：IBM 的 Rational Functional Tester 是一个 Java 工具，用于自动化软件应用程序的测试用例。它主要用于自动化回归测试用例，并且还与 Rational Test Manager 集成。
回归测试的类型
以下是不同类型的回归测试
1) 单元回归测试 (URT)
这是一种高度集中的方法，其中只有修改过的部分而不是受影响的区域会进行回归测试。这样，模块的其他部分就不会受到影响。
示例
例如，在 Build 1 中，发现了一个问题并报告给了开发人员。
假设登录功能存在 bug。因此，开发人员修复了它，在 Build 2 中添加了 bug 修复并提交。测试团队只检查登录功能是否按预期工作，而不是检查其他功能。
2) 区域回归测试 (RRT)
在区域回归测试中，会对修改和影响区域进行测试。检查此区域是为了找出任何依赖模块是否可能受到更改的影响。
示例：在此示例中，在第一个构建中，开发人员发送了模块 A、B、C 和 D 进行测试。测试人员在模块 B 中发现错误，因此将应用程序退还给开发人员进行修复。
开发人员在第二个构建的模块 B 中修复了错误后，它会被再次发送给测试工程师。测试工程师了解到修复模块 B 影响了 A 和 C。
因此，测试人员在第二次发布中检查模块 B 的修改。然后，还测试 A 和 C 中的受影响区域，以确定它们受到何种影响。
注意：在进行回归测试时，可能会出现以下问题。
问题
- 在构建 1 中，客户通常会要求进行更改、修改和添加功能。
- 此请求随后发送给开发和测试团队。
- 开发团队随后进行修改。接下来，测试工程师通过电子邮件通知客户，告知他们修改将影响哪些区域。
- 然后，测试负责人从客户、开发人员和测试部门收集受影响区域的列表。
- 然后将影响列表发送给测试工程师，他们开始进行回归测试。
这种测试方法会造成沟通不畅。开发人员和客户无法始终回复电子邮件；因此，对影响区域没有正确的概述。
解决方案：要消除此类问题，测试团队可以在新版本（在 bug 修复、新功能和修改之后）到来时安排一次会议。举行这次会议是为了讨论模块是否因修改而受到影响。
将进行一轮测试以查找影响，以便他们可以创建影响列表。测试负责人在此列表中添加尽可能多的受影响区域。
以下是该过程的外观
- “构建验证测试”以检查应用程序的主要功能。
- 测试所有新功能。
- 检查已更改或修改的功能。
- 重新测试 bug。
- 然后，最后，使用区域回归测试进行影响区域分析。
3) 完全回归测试 (FRT)
此测试涵盖应用程序的所有功能。完全回归测试通常在后期版本中执行。因此，您可以在前几个版本之后，并在最终发布之前进行 FRT。
在第二个或第三个版本中，客户或业务所有者可能会要求进行修改。他们也可能需要新功能或报告缺陷。然后，测试团队会进行影响分析，进行所有修改，并执行最终的完整产品测试。
例如，第四个版本是发布前的最终版本。因此，在此版本中，测试团队将对产品进行完整测试或重新测试，而不仅仅是影响区域或功能。这是在构建 1、2 和 3 的修改和测试之后进行的。
要执行完整的回归测试，您必须考虑以下情况
- 对应用程序的核心组件进行了更改。例如，如果应用程序的根文件或核心模块发生了修改，那么整个应用程序都需要进行回归。如果进行了大量更改。
4) 校正回归测试
此测试在功能未进行修改时进行。这些测试可以使用现有用例执行。
5) 重新测试所有回归测试
在这种测试形式中，从最初版本或构建 1 开始对应用程序所做的所有小到大的更改都会被重新测试。
当所有其他回归测试都无法识别问题的根本原因时，就会进行此测试。
6) 选择性回归测试
为了检查在添加新代码到程序时代码的反应，将进行此测试。为了进行此测试，使用现有用例的一个子集，使其高效且具有成本效益。选择子集的标准基于修改后的代码模块、依赖项、受影响功能的关键性以及历史缺陷数据。
7) 渐进式回归测试
当程序发生特定更改并创建新测试用例时，此类回归测试会产生重要输出。
它有助于确保旧版本中的任何组件都没有在最新版本中受到影响。
8) 部分回归测试
部分回归测试用于验证新的代码更改或增强不会对现有功能产生负面影响。然而，与涉及整个应用程序重新测试的完全回归测试不同，在部分回归测试中，我们只关注受近期更改影响的软件特定部分。
因此，部分回归测试的主要目的是通过避免重新测试应用程序未更改的部分来节省时间和资源。部分回归测试的测试用例是根据代码更改的影响分析仔细选择的。识别要包含在部分回归测试套件中的正确测试用例至关重要。遗漏关键测试用例可能导致忽略问题。
自动化回归测试
如前所述，当存在多个版本时，自动化回归测试是必要的。它也适用于多个回归周期和大量的重复活动。因为跨版本执行多个测试周期非常耗时。
然而，通过自动化，您可以测试多次。这需要编写自动化测试脚本以供执行，这需要相关的计划和设计。在这种测试中，团队不能直接开始自动化。因此，我们需要让手动测试和自动化测试团队都参与进来以涵盖这个范围。以下是自动化回归测试的执行方式
步骤 1) 手动测试团队检查所有需求并确定影响区域。在此过程之后，他们将需求测试包转发给自动化团队或自动化工程师。
步骤 2) 手动测试团队开始测试新模块，而自动化测试团队编写脚本并自动化测试用例。
步骤 3) 在使用这种回归测试方法之前，自动化团队会确定哪些用例可以支持自动化。
步骤 4) 他们根据可以自动化的用例将这些回归测试转换为脚本。
步骤 5) 在脚本编写过程中，自动化团队会参考回归测试用例。他们这样做是因为他们可能不具备产品或工具和应用程序的知识。
步骤 6) 测试脚本完成后，自动化团队将在新应用程序上执行它们。
步骤 7) 执行后，结果会告知测试是成功还是失败。
步骤 8) 如果测试失败，将使用手动测试方法重新检查，如果问题仍然存在，则会报告给相应的开发人员。
注意：错误修复后，问题和影响区域将发送给手动测试人员进行重新测试，自动化团队将重新执行脚本。
步骤 9) 此过程将继续进行，直到所有新添加的回归功能都获得“通过”状态。
以下是自动化回归测试的好处
- 可重用：其测试脚本可跨多个版本重用。
- 准确性：自动化工具会冗余地执行任务，从而减少出错的可能性。
- 节省时间：它比手动功能测试过程更快，并且节省时间。
- 批量执行：在自动化测试中，可以同时并行执行所有脚本。
- 无需增加资源：每次新版本发布，回归测试都会增加。但是，您无需为自动化添加新资源。
如何选择回归测试的测试用例？
以下是如何选择正确的回归测试用例。
- 了解更改的范围并确定已修改、添加或修复的应用程序部分。然后，您可以将这些区域作为回归测试的重点。
- 拥有一个涵盖关键功能的套件，并将其作为回归测试的基线。如前所述，强烈建议实现这些测试的自动化。
- 根据功能的关键性、对最终用户的影响以及历史缺陷数据对测试进行优先级排序。
回归测试最佳实践
以下是维护回归测试时应遵循的一些关键实践。
尽可能自动化
自动化回归测试可减少测试工作量，并允许快速执行大量测试用例。
持续集成
将回归测试整合到 CI/CD 管道中可确保在每次提交代码更改时自动运行测试。
测试用例选择
识别并维护代表核心功能和高风险区域的测试用例子集。您还可以选择与正在进行的更改直接相关的测试用例，因为运行所有之前的测试用例可能不切实际。
定期执行
定期执行回归测试，尤其是在每次代码更改之后。这有助于在开发过程的早期发现问题。
测试数据管理
确保用于回归测试的测试数据一致且可管理，因为与数据相关的问题可能会影响测试结果。
环境管理
维护一致且可重现的测试环境。这包括使用与生产相同的操作系统、浏览器和设备配置。
记录和跟踪缺陷
在回归测试期间发现的任何缺陷都应被记录、跟踪和管理。根据严重性确定其解决的优先级。
可重用性
创建可重用的测试脚本和测试数据，以减少重复并提高可维护性。
回归测试和配置管理
在敏捷环境中，回归测试中的配置管理变得至关重要，因为代码会不断被修改。为确保有效的回归测试，请观察以下几点
- 正在进行回归测试的代码应在配置管理工具下。
- 在回归测试阶段不允许对代码进行任何更改。回归测试代码必须不受开发人员更改的影响。
- 用于回归测试的数据库必须是隔离的。不允许对数据库进行任何更改
重新测试与回归测试的区别
重新测试是指对缺陷或 bug 进行功能测试，以确保代码已修复。如果未修复，则缺陷需要重新打开。如果已修复，则关闭该缺陷。
回归测试是指在软件应用程序进行代码更改时对其进行测试。这样做的目的是确保新代码没有影响软件的其他部分。
以下是这两种测试之间的主要区别
| 重新测试 | 回归测试 |
|---|---|
| 它是专门为修复缺陷而设计的。 | 回归测试主要用于验证代码更改是否影响了其他功能。 |
| 重新测试不检查其他版本，只验证损坏的功能是否已恢复。 | 侧重于之前的版本，并测试之前的函数是否仍然按预期工作。 |
| 每次测试都是特定的 | 回归是一种通用测试。 |
| 这是针对失败的测试用例。 | 这是针对通过的测试用例。 |
| 它检查特定缺陷，因此无法自动化。 | 可以自动化。而且正如我们之前讨论的，高度建议自动化。 |
| 重新测试并非总是测试周期的一部分，因为它仅在发现 bug 时才需要。 | 回归测试始终是测试的一部分，因为每次更改代码时，都必须进行此测试，以了解产品功能是否稳定。 |
| 这是高优先级测试，因为它侧重于已知问题。 | 这是低优先级测试，因为它对潜在缺陷进行了整体测试。 |
| 这项测试不耗时，因为它针对的是特定缺陷。 | 由于它涉及软件的很大一部分，因此非常耗时。 |
| 它使用不同的输入和新版本，在相同数据和环境中确定缺陷。 | 此测试可以从用户手册、缺陷报告和功能规范中获取用例。 |
| 没有第一次测试就无法进行重新测试。 | 当现有项目中需要进行更改和修改时，就会进行此测试。 |
还可以在此处查看完整差异列表 此处。
回归测试的优缺点
优点
- 回归测试提高了产品质量。
- 通过此测试，您可以确保修改和 bug 修复没有改变现有功能和特性。
- 由于回归测试在现有功能上运行，我们可以保证旧的缺陷也得到了覆盖。
- 它促进了高效的产品开发。
- 通过这种测试，您可以实现高用户满意度。
- 总体而言，它保持了软件的稳定性。
缺点
- 每次进行微小更改时都应进行此测试，因为最微小的更改都可能在现有模块中引起问题。
- 手动执行此测试可能耗时，需要重复测试。
回归测试中的挑战
以下是进行回归测试的主要测试问题
- 随着回归运行的不断进行，测试套件会变得相当庞大。由于时间和预算限制，无法执行整个回归测试套件
- 在实现最大收益的同时最小化测试套件仍然是一个挑战
- 确定回归测试的频率，即每次修改后还是每次构建更新后，还是在一堆 bug 修复后，这是一个挑战。
回归测试的实际应用示例（附视频）
如果视频无法访问，请点击此处
回归测试示例 – 亚马逊
以电子商务巨头亚马逊为例，这是一家价值数十亿美元的企业，其收入来源依赖于其网站。为了维护其功能、可靠性和性能，回归测试起着至关重要的作用。
让我们以“添加新产品类别”为例。
想象一下，亚马逊决定扩大其产品范围，在现有类别“电子产品”和“服装”之外，引入一个名为“智能家居设备”的新类别。
可能的回归用例将是
主页功能：验证主页在显示现有类别旁边显示新的“智能家居设备”类别，并且没有显示问题。
类别导航：确保用户可以流畅地导航到“智能家居设备”类别页面并无故障地返回主页。
搜索功能：确保搜索栏在用户搜索智能家居设备时准确返回结果，并且不会与其他产品混淆。
用户帐户：验证用户帐户可以创建、更新和用于购买智能家居设备和其他产品。
支付处理：测试特定于购买的支付网关，并保证交易安全无误。
移动响应能力：检查网站是否保持移动响应能力，允许用户在各种设备上访问和购买智能家居设备。
如果这些回归测试用例中的任何一个失败，则表示由于添加了新产品类别，网站的现有功能存在问题。应立即记录并解决此问题。此外，随着亚马逊不断扩展其产品范围并对其网站进行更改，应执行这些回归测试以维护可靠的在线购物体验。自动化测试工具可以简化此过程。
结论
- 回归测试的含义 – 回归测试是一种软件测试，可确保应用程序在改进、代码更改或 bug 修复后仍能按预期运行。
- 有效的回归策略可以为组织节省时间和金钱。
- 根据案例研究，回归测试可节省高达 60% 的后期 bug 修复。
