如果您在质量检查中工作或使用质量检查，则可能会听到“回归测试”一词。对于大多数应用程序和网站，在每个新版本之前都进行回归测试。在敏捷质量检查过程，这是常规的一部分QA测试词汇。但是什么是回归测试，您如何做？
回归测试的定义
简而言之，回归测试意味着虚拟测试一切都在软件。不仅是一个新功能，不仅是每个一般部分，还包括应用程序或网站中的每个按钮，流量和交互。
“回归”一词的官方定义是：
返回以前或更少发达的状态
在软件中，“回归”是以前工作的应用程序或网站区域中的错误。
回归测试是最彻底的软件测试类型，可以通过手动和自动测试来完成。
何时进行回归测试
回归测试应随时进行新功能或更新。这是为了确保代码中的更改不会引起现有功能的问题。
例如，假设应用程序具有视频播放器。对于即将发布的版本，该团队添加了一个功能，该功能允许用户下载视频。开发人员在视频播放器部分中更新代码，并在所有视频中启用“下载”选项。
听起来很简单，对吗？但是，这种新代码可能最终会无意中影响视频播放器的其他领域（或一般应用程序）。例如，新的“下载”功能可能会阻止视频在应用程序内播放。
软件取决于编程语言）告诉它如何处理每次互动。许多代码行还引用了整体代码的其他部分。结果，一个微小的变化会带来巨大的后果。
回归测试与烟雾测试
烟雾测试是另一种常见的软件测试类型。与回归测试不同，烟雾测试不需要彻底测试每个部分。取而代之的是，烟雾测试主要关注应用程序/网站中的流行流。
可以随时进行烟雾测试。但是，通常有一些主要情况下进行的情况：
1.当新版本（应用程序或网站的版本）准备好进行测试时。如果质量保证首先可以进行快速烟雾测试，他们可以确保构建已准备好进行更深入的测试。如果他们最终发现诸如登录或订阅之类的基本功能无效，则可以在浪费时间之前将其发送回开发。
2.完成回归测试后，就在启动之前或之后。理想情况下，回归测试应该已经出现任何潜在的错误。但是，没有人是完美的 - 无论是手动测试仪还是自动脚本。结果，通常认为在推出新版本之前立即进行最终烟雾测试是一个好主意。（这也经常在用户验收测试）
一旦正式生活，最好进行一次烟雾测试。这可以帮助确保部署不会在生产环境中引起任何问题。
在我们的指南中了解更多烟雾测试。
测试案例的回归测试
涉及测试用例时，回归测试最容易。测试用例解释了与应用程序或网站的任何给定互动中预期的行为。当质量保证有一个详细的测试步骤列表时，它可以确保重要领域不会被排除在外。
要了解更多信息，请参阅我们的指南测试用例。
烟雾测试与回归测试：测试案例比较
回归测试的测试用例与烟雾测试的测试案例不同。
例如，这些应用测试用例是烟雾测试登录功能的一个示例：
- 左导航菜单中的“登录/注册”应列出登录屏幕。
- 如果用户输入有效的凭据和TAPS“登录”，则应将其登录并带到仪表板。
- 如果用户输入无效的凭据并点击“登录”，则应出现错误消息，以提示用户输入准确的电子邮件和/或密码。
但是，通过回归测试，登录测试用例也可能包括：
- 如果用户已经登录到以前的版本，则在安装新构建版本时仍应登录。
- 登录时，在左NAV菜单中点击“注销”应将用户注销。
- 如果用户输入不存在的电子邮件地址（使用任何密码）并选择登录名，则应出现相关的错误消息。
- 如果用户使用不正确的密码输入有效的现有帐户电子邮件地址并选择登录名，则应出现错误消息。
- 当用户登录并关闭应用程序或重新启动设备然后重新打开时，仍应登录他们。
- 电子邮件地址字段不应对情况敏感。
- 密码字段应对案例敏感。
- 登录按钮应为灰色，直到用户输入凭据（无论是否有效），此时应该变成绿色。
在许多情况下，还有更多场景。
没有测试案例的回归测试
在一个快节奏的敏捷团队中，您可能不会总是有时间编写测试用例。但是，这并不意味着没有回归测试。
即使在紧迫的截止日期，质量保证金通常也可以花几分钟的时间列出部分/功能。然后，他们可以将此列表用作整个回归测试的参考。该列表可能无法涵盖所有可能的行为。但是至少它可以保证没有完全跳过的部分。
回归测试时间表
有时，预计质量保证会在不允许完整回归的时间范围内完成测试。实际上，这一点并不少见。在大多数敏捷的团队中，冲刺很少有足够的时间从上到下对应用程序进行全面测试。
那么，在这些情况下，您会做什么？这些步骤可以帮助：
1.与您的经理或客户交谈。您需要（谨慎地）明确表明您将无法在给定时间内对所有可能的互动进行全面测试。但是，您还可以传达您会尽力而为，并在时间允许的范围内彻底彻底。准备估算值也是一个好主意，以防他们问您需要多少时间进行全面测试。
2.进行回归和烟雾测试的组合。也就是说，比常规烟雾测试更彻底，但没有检查一切边缘外壳。
如果您是团队的新手怎么办？
当您已经知道像手背部之类的软件时，回归测试是最简单的。但是有时候您会成为团队或项目的新手。因此，实际上，这种熟悉程度并不总是可能。
如果您是团队的新手，并且负责进行回归测试，请不要惊慌！您有选项：
1.如果尚不存在，则创建一套测试用例。即使您没有验收标准，你仍然可以写没有要求的测试用例。这样，您将为您需要测试的每个动作提供指南。
2.如果团队中还有其他质量检查测试人员，请要求进行演练，以查看他们如何解决。如果没有其他测试人员，您通常可以要求开发人员对每个部分的功能进行更彻底的细分。
3.询问过去的问题。该应用程序过去是否有对错误特别敏感的区域？您应该特别注意的问题吗？
4.与您的经理或客户交谈。与上面的“时间表”部分中的步骤一样，这可以帮助设定期望。让他们知道，您仍在使用软件的所有部分加快速度。
5.列出问题。如果您不确定某项功能的特定部分或方面，则可以尝试找出答案。问问可能会感到艰巨，但是最好根据准确的信息进行测试。（如果您不这样做，它也可以回来咬您！）
错误报告
如果您在质量检查方面有经验，那么您可能会精通编写错误报告。（如果没有，请参见我们的指南报告错误的最佳实践。但是，可以优化该过程用于回归测试。
当您进入大量测试中时，它可能会放慢脚步，以便停下来为每件事的每一件事制作正式的门票。但是您也不想跳过报告潜在问题 - 无论它们有多小。那你如何继续呢？
最好的方法之一是在测试时保留简单的笔记列表。这样，您可以同时返回并创建所有错误票。如果您碰巧注意到您认为可以从中受益的区域用户体验改进，您也可以包括其中。回归测试是评估应用程序或网站的整体用户体验的绝佳机会。
也就是说，在遇到它们时，您仍然需要提出任何关键问题。上述方法非常适合似乎是“中等优先级”或较低的错误。（有关此的更多信息，请参阅我们的指南如何优先考虑错误修复。
还要记住，在新版本中找到错误并不意味着该错误本身是新版本。如果您不是积极的，并且有时间，那么检查旧版本也很有帮助。这样，您可以查看该问题是否也可以重现。这还可以帮助确定问题是在后端（例如，使用API）还是前端代码。
如何进行回归测试
您可以使用上面的步骤和建议来遵循回归测试的最佳实践。但是，如果您试图进入质量检查领域并首先需要经验，请记住，您可以回归测试任何内容！您无需为软件公司工作即可执行自己的回归测试。
例如，您可以选择任何应用程序或网站，并挑战自己进行回归测试。虽然您不会获得时间的报酬，但从长远来看，学习经验可以回报。
如果您不确定从哪里开始或要进入什么顺序，请不用担心。你可以从烟雾测试，然后在每个功能和部分的每个区域中更深入。
回归测试估计
即使用于测试单个功能，创建估计值也很难。更不用说需要多长时间完成整个应用程序的完整回归测试了！无法保证您的估计是正确的。但是，您可以遵循一些最佳实践，以尽可能接近。
要了解更多信息，请查看我们的指南估计技术。
在错误修复后重新测试
如果您发现错误并创建了新的错误修复构建，会发生什么？您是否必须重做所有以前的回归测试？毕竟，对代码的更新可能会在您已经检查的区域中引起问题。答案是肯定的。这完全取决于时间（见上文），预算和风险评估。
在一个完美的世界中，您将重新测试完整的软件以确保安全。但实际上，通常没有时间到了。至少，质量检查应：
- 测试错误修复本身，以确保其正常工作。
- 回归测试该错误先前已影响。
- 烟雾测试主要流量，例如登录/注册。
遵循这些步骤是时间，预算和风险的良好平衡。
自动回归测试
自动测试永远无法覆盖QA测试的100％。但是，它可以帮助的最好的领域之一是回归测试。
创建新的自动化脚本需要时间。因此，认为在发布之前可以通过自动化对每个新功能进行测试并不总是现实的。但是回归测试涉及每次检查许多相同方面。结果，这是自动化的绝佳候选人。
对于一个很好的起点，请参阅自动化的前5个测试用例。
软件工程中的回归测试
如您所见，回归测试在软件工程中起着重要作用。它会在软件中找到所有可能的错误吗？不一定 - 没有人是无误的。但这是您可以真正获得的最接近的软件测试类型。