十分钟理解回归测试（Regression Testing）
1. 什么是回归测试（Regression Testing）
回归测试是一个系统的质量控制过程，用于验证最近对软件的更改或更新是否无意中引入了新错误或对以前的功能方面产生了负面影响（比如你在家中安装了新的空调系统，发现虽然新的空调系统可以按预期工作，但是本来亮的等却不亮了）。其主要目标是确保旨在改进的修改不会破坏软件的既定性能和可靠性。回归测试是软件开发过程质量控制措施的一个重要方面。每次进行更改时，都会将其付诸实践，以确保它不会无意中导致任何功能或性能问题。
那我们为什么需要回归测试呢？
当软件开发人员修复错误、添加新功能或修改现有特性或功能时，他们必须更改程序代码。即使是微小的更改也可能导致大量新错误。在这种情况下，测试工程师可以通过回归测试来揭示和查明不良副作用。正确执行的回归测试套件至关重要。至关重要的一点是，在错误修复后原始产品不会停止工作。
回归测试是软件开发生命周期的基本组成部分。ProtoTech Solutions用这张图很好地说明了这个概念：
2. 什么时候进行回归测试
将新功能或增强功能部署到现有代码库或应用程序时，需要进行回归测试。它确保现有应用程序的任何新功能或更新都能正常工作，而不会出现任何错误或缺陷。开发人员和测试人员通常难以跟踪每个代码线程，因此很有可能出现代码不兼容问题。因此，对他们的代码库（或应用程序）执行回归测试使他们能够更早地检测到缺陷，并以更低的风险交付应用程序。
当部署花费的时间比预期的要长时，可以使用它。在这种情况下，测试人员应每天运行回归测试。此外，最好在每周发布的功能测试之后运行回归测试。
当某些功能被大修时，回归测试变得更加重要，因为它可能会危及代码库的现有功能。此外，修复一个缺陷有时会导致另一个缺陷。在这种情况下，可以混合使用调试和回归测试，以确保一切按预期工作。
3. 回归测试的种类
根据软件开发生命周期 （SDLC） 和要部署的新功能或更新，可以实现各种类型的回归测试。但是，必须了解几种回归测试类型才能选择正确的回归测试类型。
以下是不同类型的回归测试——
纠正性回归测试
纠正性回归测试是更简单的回归测试形式之一，需要最少的工作量。纠正性回归测试不涉及对现有代码库的更改，也不涉及向应用程序添加新功能。您只需要测试现有功能和与之相关的测试用例，而不是创建新功能。
单元回归测试
单元回归测试是回归测试的一个组成部分，在回归测试中，代码是单独测试的。在执行单元回归测试时，所有其他交互、集成和依赖项都将被禁用，重点是单个单元代码。通常，此测试在低流量和非高峰时段进行。
选择性回归测试
选择性回归测试分析现有代码的影响以及新代码和现有代码的影响。变量和函数等常见元素被合并到应用程序中，以便在不影响过程的情况下快速识别结果。
渐进式回归测试
测试用例是根据渐进式回归测试的要求创建的。当只有微小的产品改进时，设计新的测试用例时不会影响产品的现有代码。
完全回归测试
一些微小或重大的更改可能会对产品产生巨大影响。在这种情况下，当对当前代码进行重大修改时，将使用完整的回归测试。它有助于修复在测试过程中所做的任何修改。
部分回归测试
将新代码添加到现有代码库时，将执行部分回归测试。这有助于发现现有代码中的关键错误，并允许在不影响系统的情况下对其进行测试。
重测所有回归测试
重新测试所有 回归测试是重新执行所有测试用例的过程，以确保没有由于应用程序中的代码更改而导致的错误。这种类型的测试需要 QA 方面付出巨大的努力。
4. 重测试和回归测试之间的区别
重测试是测试特定测试用例的持续过程，以确保错误得到修复，并且 Web 产品的功能在最终执行中运行良好。在重测试中重复同一组单元测试，以验证代码的功能。换句话说，重新测试是执行相同的手动或自动测试，以验证新版本是否完美运行。
回归测试是一种在发生任何代码提交时验证新生成的技术。在这个过程中，测试人员的工作是验证代码中没有由于软件修改和调整而包含新的错误。开发回归测试套件后，您可以使用自动化测试工具将其自动化。但是，这不适用于重测试。
以下是重测试与回归测试的详细比较
| 重测试 | 回归测试 |
|---|---|
| 是一种确保测试用例没有错误并在错误修复后的最终执行中完美运行的技术。 | 是一种确保代码功能在应用程序调整或修改后不受影响的技术， |
| 是针对失败的测试用例执行的。 | 是对通过的测试用例执行的。 |
| 确保修复构建中的原始错误。 | 测试代码是否存在意外的副作用。 |
| 无法对测试进行自动重新测试。 | 自动回归测试是可能的。 |
| 也称为计划测试。 | 也称为通用测试。 |
| 由于其高优先级，它不能与回归测试并行执行。 | 它可以与重新测试并行执行，因为它在少数实例中的优先级较低，并且资源可用性较低。 |
| 不包括 bug 验证作为测试的一部分。 | 把错误验证作为测试的一部分。 |
| 在所有软件版本中执行。 | 是在一些最新版本的软件中执行的。 |
5. 回归测试的策略
- 再次执行所有现有测试：产品发布后，测试工程师必须再次检查问题区域。很多时候，这可能是一个挑战，尤其是在执行手动测试时。此处建议进行自动化测试。
- 首先运行高优先级测试：在回归测试上花费的大约 50% 的时间应该用于重复与应用程序基本功能相关的测试。
- 接下来检查复杂的功能：许多应用程序都有精密而复杂的部件，这可能会导致问题。尽管该功能很难理解，但其功能的质量必须非常出色。
- 执行探索性测试：在学习软件版本的新功能的同时，为它们设计新的测试并执行它们。在这次测试过程中，会发现许多新的错误。
- 借助自动化测试：提高生产力并减少运行测试所花费的时间/精力。使用自动化脚本，可以更快、更有效地执行测试。
最后，必须进行随机测试。软件测试人员扮演用户的角色并随机测试。因为总是存在一些问题，所以进行随机测试很重要。
6. 选择用于回归测试的测试用例
端到端测试对于在所有浏览器和操作系统上顺利运行应用程序至关重要。但是，据观察，在部署阶段，大量缺陷会泄漏到应用程序中。从客户的角度来看，这可能至关重要，因为它可能会增加营业额并造成糟糕的客户体验。因此，根据客户要求明智地选择测试用例至关重要。
以下是选择回归测试用例的步骤 -
- 选择具有频繁错误的测试用例：简单的代码提交有时会破坏应用程序的完整功能。因此，测试人员在选择涉及频繁缺陷的测试用例时应牢记这些因素。他们还可以根据他们在回归测试周期中的先验知识和经验来选择测试用例。
- 选择具有关键核心功能的测试用例：为确保应用程序在多个平台上顺利运行，测试人员应首先专注于选择涵盖应用程序基本关键功能的测试用例。例如，电子商务应用程序必须包括多种支付方式、网站导航、广泛的搜索功能等。
- 选择具有最近代码更新的测试用例：当新代码或功能合并到应用程序中时，缺陷的可能性会增加，并且必须多次修改代码。因此，确定测试用例的优先级并选择那些涉及频繁代码库调整和升级的测试用例至关重要。
- 根据用户界面选择测试用例：测试人员需要根据用户可见的区域来选择测试用例。用户界面的可见元素包括品牌徽标、图像、按钮文本等。然而，这些问题的优先级较低，但从用户的角度来看，它们至关重要。
- 选择基于集成的测试用例：端到端测试可确保应用程序在不同平台上平稳运行。在某些情况下，一个组件的功能可能依赖于另一个组件。例如，如果组件 C2 的功能依赖于 C1 并且修改了 C2，则 C1 的行为可能会受到影响。因此，对此类 bug 运行回归测试对于验证基于集成的测试方案至关重要。
- 选择复杂的测试用例：执行复杂的测试用例可能会导致应用崩溃和性能不佳。测试人员必须使用各种技术来测试复杂性，并确保解决所有复杂的测试场景。
- 合并基于风险的测试：在基于风险的测试方法中，测试人员根据最近的代码更改确定测试用例的优先级，从而减少回归时间和工作量。
回归测试用例的优先级可以分为三类——
- 高优先级：它涵盖了应用程序的关键和核心功能、最近的代码修改以及很有可能出现错误的组件。
- 中等优先级：它涉及现场验证和其他负面测试场景等方面。
- 低优先级：它包括其他功能，如用户界面区域，如品牌徽标、按钮文本等。
7. 回归测试示例
以下是 Apple 网站所需的回归测试示例。该公司通过其网站产生数十亿美元的年收入。因此，他们的网站必须始终正常运行——功能、可靠且性能良好。
示例 – 苹果
在 apple.com的首页上，您可以看到苹果的所有产品。
当苹果发布他们的下一个产品，也许是iPhone 16时，苹果的开发人员将在网站上添加一个新条目，很可能在iPhone 15 Pro上面。但是，需要非常小心地确保：将新的 UI 流添加到主页上的新“iPhone 16”条目中后，其余的产品 UI 流仍能像以前一样继续正常工作。为此，我们执行了回归测试套件。这些回归测试用例可以手动执行，也可以使用称为 Selenium 的流行测试自动化框架自动执行。
假设其中一个回归测试失败;这意味着在添加新的产品流时，网站的现有功能中断了。此错误需要立即记录并修复。每次对网站进行次要或重大的 UI 流程添加/更改时，都应执行此回归测试套件。
同样，回归测试套件也应该得到增强，以在较新的测试用例的帮助下覆盖更多的 UI 流。这确保了网站始终正常运行;每当出现破损时，都会在回归测试套件的帮助下立即检测并标记。
