每个涉及生产代码更改的场景都需要进行回归测试。以下所有场景都有此测试的需求。
· 向应用程序添加新功能：具有登录功能的网站。用户只能通过电子邮件使用此功能。一项新功能是使用 Facebook 凭据执行登录。
· 更改要求：例如删除以前适用的记住密码功能。
· 修复缺陷：登录按钮无法正常工作的登录页面。测试人员提供了一份报告，指出存在错误，即登录按钮已损坏。一旦开发人员修复了这个错误，QA 工程师就会执行测试，确保登录按钮按预期工作。同时，测试人员测试与登录按钮相关的其他功能。
· 性能问题修复：例如，主页需要五秒钟才能加载。现在，此持续时间减少到两秒。
以上几点可以归纳为以下几种情况：
·配置进行了修改。
· 增加了补丁修复。
· 对源代码进行了优化以提高性能。
· 修复了用于解决缺陷的代码库。
· 添加了新功能或特性。
· 对现有功能添加了新要求。
有些软件产品需要几个月的时间才能完成。所以对于这些产品，建议每天进行回归测试。每周都会发布一些版本。对于此类产品，回归测试在功能测试结束后开始。
让我们考虑一下当您测试特定功能时的场景，并且测试在一天结束时还没有结束。现在，你必须中途停止这个过程。第二天，你回来重新从头开始测试。此操作称为“重新测试”。您出于特定原因再次进行测试。一个原因可能是特定测试用例在最终执行中失败，因此必须重新运行测试用例。第二个原因可能是源代码有一个缺陷已被修复。
回归测试可以被认为是重新测试的微小变化。仅当产品或代码发生变化时才安排回归测试。这种变化可以是设计、代码或任何其他导致产品整体框架发生变化的问题。这种更改的最常见原因是修复了错误或创建了产品的新版本。
在通常的软件测试生命周期（STLC）中，较早的过程是重新测试，然后可以进行回归测试。在中，只关注失败的测试用例。在回归测试中，注意力集中在以前已经通过的测试用例上，但有可能出现新的和意想不到的错误。
在回归测试中你应该做什么？
软件测试生命周期 (STLC) 是一个包含多个阶段的连续过程。冒烟或健全测试结束后或在最后一个功能测试阶段，您需要开始回归测试。
您需要执行的操作主要有两种：
· 重新运行之前进行的测试。
· 将测试用例的当前结果与先前执行的测试结果进行比较。
有效回归测试的第一步是概述回归测试计划。该计划必须详细说明您的回归测试策略和退出标准。您还可以在此计划中包括性能测试。此包含旨在确保产品组件的更改不会影响产品性能。
必须遵守回归测试的最佳实践。您需要在接近一天结束时运行自动化测试用例。此外，如果检测到任何回归副作用，您可以与开发人员共享它们以在第二天的构建中修复它们。通过这种做法，您可以在早期阶段而不是在发布周期结束时解决大部分回归缺陷。以这种方式，释放风险被最小化。
回归测试的类型
您可以根据要部署的功能或更新实施各种回归测试。但是，了解几种回归测试类型以选择正确的一种至关重要。
回归测试有以下几种类型。
· 完全或完全回归
· 偏回归
· 单位回归
· 校正回归
· 选择性回归
· 重新测试回归
完全或完全回归
当许多模块上的代码发生变化时，您应该选择这种类型，而这种变化对其他模块的影响是未知的。因此，决定是检查整个产品以检测是否有任何其他由于代码更改而产生的修改。
对于第二次产品发布，客户建议增加四五个新功能，并修复第一次发布的一些缺陷。测试团队实施影响分析并得出结论，必须针对这些修改对整个产品进行测试。简而言之，这种类型意味着测试所有更改的和旧的功能。
让我们考虑一个以Java 虚拟机 (JVM) 作为根文件的 Java 应用程序。如果更改对 JVM 文件来说必不可少，则必须测试 Java 应用程序。
偏回归
开发人员进行一些代码更改后，将更改的代码单元与现有（即未更改的）代码集成在一起。您必须验证更改后的代码是否按预期工作。
单位回归
您必须在单元测试阶段进行时执行此操作。在这种情况下，一个单元的代码被隔离测试。此类测试的目标是必须在个人级别对单元进行测试。因此，被测试单元上的所有依赖项都被阻止了。
校正回归
它是需要较少工作量的简单回归测试之一。纠正性回归测试涉及对现有代码库进行零更改并向软件应用程序添加新功能。您需要测试现有功能和随之而来的测试用例，而不是开发新功能。
选择性回归
选择性回归测试确定现有代码库以及新代码和现有代码的影响。变量和函数等通用元素被实施到应用程序中，以在不影响整个过程的情况下识别结果。
重新测试回归
重新测试回归涉及重新执行所有测试用例，以确保不会因软件中的代码更改而导致缺陷。这种类型的测试需要 QA 方面的更多手动工作。
回归测试过程的分类
回归测试过程可以按另一个标准分为两种类型：“跨发布”和“跨构建”。
跨发布
这是关于同一项目的新版本。先前版本中的旧元素可能会受到最新版本中新功能的影响。该类型包括以下步骤：
· Release 1 是第一个版本。它没有修改。因此，此版本中没有回归测试。
· 客户提出了一些新的要求。因此，从第 2 版开始，回归测试就开始了。
· 新要求提供给开发人员和 QA 工程师。他们了解需求。
· 进行影响分析，防范重大风险。这是由客户使用业务知识、开发人员使用编码知识以及 QA 工程师使用产品知识完成的。由于所有相关人员都参与了影响分析，因此完成了影响分析的最大测试范围。
· 客户、开发人员和 QA 工程师与测试主管共享他们的影响区域文档。
· 开发人员和 QA 工程师开始处理新的测试用例。
· 测试负责人合并三个影响区域文档，并将合并后的文档保存在版本 1 的测试用例需求存储库中。
· 测试负责人参考需求可追溯性矩阵（Requirement Traceability Matrix，RTM），从测试用例需求库中选择相关的回归测试用例，并将测试用例文件存储在回归测试套件中。
· 在 QA 工程师完成新测试用例的工作后，测试负责人将回归测试用例分配给 QA 工程师。
· 所有的回归测试用例都必须通过，所有的新特性都必须稳定才能做下一步。
· 使用测试用例来检查影响区域，直到它对产品的新旧功能而言是持久的。
· 向客户提供产品。
跨项目构建
bug 修复后，重新测试 bug，如果 bug 有依赖模块，则进行回归测试。让我们考虑一个示例，其中有三个构建（构建 1、构建 2 和构建 3），所有这些都有不同的场景。这种类型包括以下步骤。
构建 1
· 客户共享业务需求。
· 开发人员开始开发功能。
· 测试人员开始编写测试用例。让我们假设他们为 Build 1 编写了 500 个测试用例。
· 测试人员开始执行测试用例。
· 产品发布给客户。
· 客户实施一轮验收测试。
· 产品保存在生产服务器上。
构建 2
· 客户建议了四个新功能并分享了这些功能的业务需求。
· 开发人员开始开发功能。
· 测试人员开始为四个新特性编写测试用例。让我们假设他们为 Build 2 编写了 300 个测试用例。因此，测试用例的总数为 800。
· 测试人员开始执行四个新功能的 300 个测试用例。
· 测试人员开始执行 Build 1 的 500 个测试用例，以确认这四个新功能没有妨碍旧功能。
· 在测试新旧功能后，将产品发布给客户。
· 客户执行验收测试。
· 产品保存在生产服务器上。
构建 3
· 客户决定删除一个功能，“功能 1”。
· 测试人员删除与功能 1 的模块相关的所有测试用例（让我们假设这些是 150 个用例）。
· 测试人员测试所有剩余的功能，以确认在删除功能 1 后，其余功能可以正常工作。
如何确定回归测试的数量
您可以根据新添加的功能的范围来决定回归测试的数量。
让我们考虑一个功能或修复的范围很大。受影响的产品面积也很大。您必须获得开发人员关于更改的数量、性质和范围的输入。因此，您可以决定需要回归的产品区域。
在回归测试中，测试一次又一次地重复。因此，您可以自动化一组测试用例。然后，这个集合在每个新构建上执行。您必须谨慎选择测试用例，同时牢记最少数量的测试用例必须覆盖产品最大功能的目标。
让我们考虑一下产品范围是巨大的，并且正在向系统添加连续的补丁或增量。在这种情况下，您可以通过选择选择性测试来节省测试的时间和成本。您需要考虑产品的增强功能以及这些增强功能可以产生最大影响的部分，以最终确定选择性测试用例。
回归测试技术
以下是回归测试中使用的技术：测试用例优先级排序、回归测试选择、重新测试所有和混合。
测试用例优先级
根据案例的关键性、对产品的影响以及产品特定功能的频率，为每个测试案例分配优先级。新增功能和面向客户方面的测试用例属于高优先级类别。优先级高的先执行。优先级中等的紧随其后，最后执行优先级低的。
回归测试选择
根据模块中的代码修改，您可以从测试套件中选择一些测试用例。然后，您重新执行这些选定的测试用例。不需要重新执行整个测试套件。测试用例分为两类：过时的测试用例和可重用的测试用例。
在即将到来的回归周期中，您不应该执行过时的测试用例，而必须执行可重用的测试用例。在这种技术中，您只实施相关的测试用例，这些用例的数量是有限的。这减少了回归测试的时间和精力。
重新测试所有
您必须重新执行测试套件中的所有测试用例。这是为了确保代码中所做的更改没有引入任何错误。这种类型比其他技术需要更多的时间和资源。这是最昂贵的技术。
然而，这是最安全的方法，因为它确保所有错误都已被识别和修复。当操作系统有重大更新或应用程序针对新语言或平台进行修改时，此方法通常适用。
混合型
这种技术是测试用例优先级排序和回归测试选择的混合。不会重新执行完整的测试套件。根据优先级，您必须选择要重新执行的测试用例。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
