回归测试策略概览

本文要点

• 回归测试不同于其他类型的测试。
• 回归测试分为多种类型，因为不同的原因，采取不同的方法。
• 建立回归测试的策略，重点是要考虑上下文和其他一些因素。
• 回归测试有很多方式和方法。
• 不同的方法论需要采用不同的回归测试方法。

成本高、耗时长的回归测试对整个交付团队来说是一个令人烦恼的难题。幸运的是，我们有机会让回归测试变得更轻松、更有效。要做到这一点，应该设计一个有效的回归测试策略，充分满足产品的需求，以最佳的成本保证产品质量。这需要了解回归测试的本质，采用它的原因以及执行它的方法。

为什么要进行回归测试

软件的回归是指某个事件（例如，一个软件补丁或升级）发生后出现的一个缺陷。回归测试则确保了最近变更的代码不会影响其他代码，从而防止软件回归。

变更是回归测试中的关键概念。变更的原因通常分为四大类：

• 新的功能。这是运行回归测试最常见的原因，新旧代码必须完全兼容。当开发人员开发新的代码时，他们不会完全专注于兼容现有代码，这就需要利用回归测试来找出潜在的问题。
• 功能修改。有时候，开发人员会修改现有功能、丢弃或修改某些特性。在这样的情况下，回归测试可以检查相关特性是否被删除或修改，确保不会损害其他功能。
• 集成。在这种情况下，回归测试确保软件产品在与其他产品集成后可以完美工作。
• 错误修复。令人惊讶的是，开发人员努力修补发现的错误可能会产生更多的错误。因为修复错误需要修改源代码，这就需要重新测试和回归测试。

了解这两种测试之间的差异很重要。重新运行功能测试用例，然后产生错误报告。测试工程师再次执行它们以检查错误状态（已修复、未修复等）。如果错误仍然存在，开发团队会收到一个错误报告以进一步排错。排错完成后，测试团队运行回归测试来确保应用程序仍可正确工作。

回归测试类型

根据测试目的的不同，回归测试可分为三种类型：

1. 新错误修复：验证最近发现的错误是否修复成功。
2. 旧错误修复：确保一个错误一旦被发现并修复，就不会再出现。
3. 副作用：验证最近的错误修复没有破坏旧的功能。

回归测试策略：基本因素

分析了回归测试的原因及其类型后，我们可以开始制定一个有效的回归测试策略。在设计回归测试策略时，团队依赖于两个因素：

1. 产品的本质。这是一个关键因素，让我们能选择合适的回归测试策略，以及周到的回归测试计划。例如，测试一个登录页面和测试综合专业门户的方法有很大的不同。登陆页面的回归测试主要针对用户界面和可用性方面的测试用例，而对于门户网站来说，会考虑到更多安全性、性能、兼容性等方面的测试用例。
2. 产品的规模。大、中、小型的产品要采用不同的回归测试方法。对于小型产品而言，单轮的手工回归测试可能就足够了；而对于具有丰富功能的大中型产品，通常手工和自动两种回归测试都要采用。

如果考虑到这些因素，测试团队就可以选择到合适的回归测试方式和方法。

回归测试方法

回归测试遵循两种实现方法：手工和自动。

手工回归

无论采用何种方法论（瀑布、敏捷和其他），手工回归测试是对产品进行回归测试的基本方法。回归测试套件包含了应用程序最近发生变更及其相关部分的测试案例。这种类型的测试总是先于自动化测试，在某些情况下比后者更有效。例如，想要测试与应用程序发生变更部分相关的功能，通过编写自动化测试脚本是不可能做到的。

手工回归测试，在产品交付过程的早期阶段是有效的。我们开发的一个产品，比如 iOS 图像处理应用程序，手动回归测试可以帮助检测出影响应用程序用户体验的多个错误。手工回归测试发现该应用无法正确地生成图像，当用户改变屏幕方向时会发生崩溃。

尽管如此，测试团队仍然试图采用自动化的回归测试，因为手工回归测试的主要问题是费时、费力。对于复杂的产品，手工运行回归测试套件，不可避免地影响了测试工程师的注意力和效率。因此，在这种情况下，团队更喜欢借助自动化。

自动回归

一个大中型项目（时长六个月或更久），当项目处于稳定阶段（预期的业务逻辑和用户界面已不会发生重大变化），自动化回归测试是典型的方法。有了全面的回归测试规划，自动化降低了测试团队花费在繁琐、重复任务上的精力，省下时间去参与那些需要人工介入的测试，比如探索性和用户体验测试。

然而，现今的团队往往在早期阶段就开始自动化回归测试。它适用于敏捷开发，团队至少每周部署一个产品，没有时间准备手动回归测试。通过与整个团队（利益相关者、管理者、业务分析师等）沟通并研究用例文档，测试人员可以了解利益相关者的需求、产品业务逻辑以及测试的预期结果。在项目早期，自动化的主要任务是选择测试框架，它应该提供简单的脚本和低成本的测试维护。创建的基础架构可以重用于未来的产品，并能加速测试自动化。

在某些情况下，自动化可以帮助检测手动回归测试未发现的错误。最能说明问题的例子，是那些随机出现的错误。当我们测试上面描述的图像处理应用程序时，自动化超时有助于检测出一些随机错误。如果一个脚本发生超时，它会自动被标记为失败。结果是，同一个脚本一次又一次地运行，直到通过，这样就可以发现出现在某个确定位置的随机错误。

回归测试实现方式

回归测试提供了两种可能的实现方式：

完全回归

这种回归测试方法包含了覆盖所有产品的回归测试案例。质量团队通常在产品交付流程的最后阶段，或主要版本发布前执行此操作。当产品需要进行显著的功能性或非功能性变更，或这些变更影响基础代码时，也会使用完全回归测试。幸运的是，测试团队不需要编写完整的回归测试套件。他们通常会修改功能性、非功能性、单元和集成测试套件，并选择那些在整个产品交付过程中不断发现错误的测试用例，这些测试用例构成了一个回归测试套件。

虽然冗长、乏味，但这种重新测试的方法非常有效，因为它有助于发现整个应用程序中可能存在的问题。然而，经常进行这类测试是没有意义的，团队通常会在改变开发环境之前运行这类测试。例如上面的图像处理程序，该应用最初是为 iOS8 开发的，因此该团队使用了 XCode6 IDE。但后来客户要求用户在 iOS9 的新设备上运行该产品，这需要切换到 Xcode7。切换后，测试工程师必须运行完整的回归测试，确保在 Xcode6 下的所有特性能继续工作。

而当客户希望拥有完全稳定、满足需求的产品时，可以要求进行完全回归测试。

部分回归

部分回归测试的特征是只包含产品的修改部分和可能受到影响的相关部分。测试团队使用特定的策略，来确保部分回归测试能产生良好的结果。它的主要策略是以风险作为依据，测试工程师挑选出应用程序受到最近变更影响的部分，并从测试套件中选择相关的测试用例。

当产品获得任何类型的新功能时，质量团队可以进一步将这种基于风险的方法应用于回归测试套件。这种方式大大减少了测试时间和工作量，对于以敏捷方式来交付产品的团队来说，如果他们时间紧迫，那么这种方式不失为一种很好的迭代回归测试方案。部分回归还有助于在最终开发阶段重新考虑完整的回归测试套件，并丢弃那些没用的测试用例。

要选择哪一种方法，取决于产品交付过程中变化的范围、方法和阶段。在测试实践中，我们会尽可能坚持基于风险的部分回归测试。

主流方法论中的回归测试

选择合适的回归测试策略，产品开发方法论是要考虑的关键因素之一。对于瀑布方法论，测试是在产品完全开发完毕之后才开始进行的。瀑布过程中的测试通常分为三个阶段：

• 标准的测试。测试团队开始工作并运行所有测试套件、脚本。测试完成后，团队会将错误报告发送给开发团队，然后由开发团队来修复这些错误。
• 稳定性。当错误被修复时（假定），测试团队运行回归测试来检查错误修复情况及其相关部分。要达到稳定可能需要很长时间，因为修复错误时往往产生新的错误。测试团队需要根据严重程度（关键、重大、中等、不重要）对其进行评估。当产品有重大缺陷时，开发团队将进行另一轮修复。
• 回归测试。当关键和重大错误被修复时，稳定性确保不会再出现类似的错误，测试团队将运行完全回归测试来对产品进行最终的修补。

因此，在瀑布方法论中，稳定性和完全回归是测试的最关键和耗时的部分。

在敏捷开发中，回归测试通常属于上述两种子类型：部分（迭代）回归，覆盖了迭代期间和相关部分的特性；以及在主要版本和部署之前执行完全（主要）回归。然而，为了提高效率，回归测试套件需要进行这样的维护：测试团队应该添加新的相关测试用例，并及时地删除已废弃的测试用例。这种方法大大减少了乏味的测试所花费的时间和精力，并且不会损害产品质量。

无论他们遵循何种方法论（瀑布或敏捷），产品团队还可以选择一些特定的优化方法。

优化的回归测试：看板和 DevOps

看板方法包括使用产品的仪表板，有助于清晰地可视化工作，并跟踪进度和改进。这样，每个团队成员可以估算他们的工作量，与团队工作联系起来，设定最后期限并确保效率。在瀑布过程中，看板有助于估计达到稳定性所需的时间，并更仔细地规划测试工作。看板仪表板帮助选择迭代回归的测试用例，以及需要进行完全回归的关键时间点。

DevOps 包括持续集成（CI）、持续交付（CD）和持续部署。这种方法很大程度上依赖于自动化：一小部分代码被发送到存储库，其中 CI 确保将代码部分自动集成到一个部署（build）。然后这次部署被发布到临时（staging）环境（CD），然后测试人员运行自动化测试。这种方法极大地减少了与回归有关的问题，从而加速了敏捷项目中的测试和部署。

回归测试和其他测试类型

软件产品包含功能性和非功能性特性，代码的变更会和这两种类型都有关，回归测试也可以被分为两类：

功能回归测试
功能测试包括客户需求、业务逻辑以及产品规格，并验证应用程序是否按预期工作。在这种情况下，回归测试的目的是验证最近的变更没有破坏或影响已经存在的功能特性。

非功能回归测试
回归测试也可以成为非功能测试工作的一部分，以下是几类最常见的需要回归测试的非功能性测试工作：

• 用户界面测试
  用户界面是用户在运行应用程序时看到的内容，这种类型的测试包括验证应用程序菜单、图标、条形图、对话窗口等是否显示正确。用户界面测试可确保应用程序良好的观感，通常这可以预先确保产品的受欢迎程度。
  当产品功能不断增加时，需要进行用户界面的回归测试，多个新的用户界面元素会导致用户的混淆。为了提升用户体验，产品所有者和业务分析员需要努力分析应用程序并决定哪些旧功能可以与新功能合并，哪些可以被完全替换。任何更改都会涉及代码变更，需要进行回归测试。
  这也发生在我们的 iOS 移动应用程序上，该应用程序实现了几个版本，有时边栏不再能满足最近添加的关键功能。所以产品所有者决定升级边栏功能，而接下来的回归测试发现用户界面功能被弄乱了。当关键功能还没有实现的时候，应该先实现关键功能而不是重要性不那么高的侧边栏功能。
• 兼容性测试
  这种类型的测试用于检验在各种硬件或操作系统中是否能容易地使用产品。因此，兼容性测试的类型包括跨浏览器和跨平台测试。根据产品的不同，测试团队可能会针对不同的配置执行兼容性回归测试。
• 安全性测试
  安全测试检测应用程序是否存在外部安全漏洞，从安全的角度检查代码质量，这是最常见的安全测试方法。但是，对于需要高安全级别的 Web 应用程序（医疗、银行等），安全测试还涉及到用户授权。这些应用程序提供基于角色的访问，一个典型的案例是医院的 Web 应用，医生只能访问与其工作活动相关的数据。如果某些角色的权限发生了变化或某位员工辞职，测试工程师将运行回归安全测试，以确保其他员工的访问权保持不变。
• 本地化和国际化测试
  这类型的测试通常在应用程序全球化时执行。本地化测试将验证应用程序的行为是否符合目标区域中能接受的文化规范，并用支持的语言正确显示信息。无论区域、语言或文化特点如何，国际化测试要验证应用程序是否正常工作。
  令人惊讶的是，这种类型的测试也会涉及到回归测试。例如，我们的一个产品旨在覆盖大量的用户。因此，它支持多种语言，通过翻译服务提供相关翻译。在运行功能回归测试时，测试团队也要注意以各种语言正确显示信息。有时，由于开发的缘故，代码变更导致翻译被清除了。因此，团队需要执行本地化回归测试，来验证开发工作不会影响现有的非功能性特性。

总结

应对回归测试的最好方法，是设计一个适当的测试策略。它应该包含三个关键要素：

• 测试方法（手动和自动的适当比例）。
• 回归测试方式（在产品交付过程中完全和部分的分配）。
• 质量回归测试套件。该套件可能涉及功能测试用例和非功能测试用例，它们涵盖了在产品交付过程的特定阶段发生变更的特性。

利益相关者需求支配产品的这一特点，为选择正确的回归测试策略奠定了基石。另一个重要的因素是产品规模（小、中、大）。一个好的回归测试策略能减少测试时间和精力、提高产品质量，并使之完全符合顾客的需要。

关于作者

Tatiana Bessonova 是一位精益功能测试工程师，有 14 年的瀑布和敏捷项目经验。她拥有 11 个领域的工作经验，并将出色的分析能力和实用的商业方法，广泛应用在医疗保健、制造业、娱乐业、零售业和其它各种具有挑战性的项目中。

查看英文原文： Regression Testing Strategies: an Overview

感谢薛命灯对本文的审校。