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