回归测试是一种系统范围的测试，旨在确保系统某个部分的微小变化不会破坏系统中其他地方的现有功能。这很重要，因为没有回归测试，很有可能将预期的修复程序引入到一个系统中，这个系统会产生比他们解决的问题更多的问题。

让我们看一个虚构的例子，说明在不使用回归测试时会发生什么。

什么可能出错？

有一天，Acme Widgets应收账款部门的经理发现了公司财务系统中的一个错误。事实证明，负责报告逾期发票的模块未列出所有逾期发票。编写了一张Jira票据，描述了该错误以及有关如何复制问题的说明。该错误已分配给进行修复的开发人员。

开发人员遵循公司政策和单位测试新代码。单元测试证明该修复工作符合预期的效果。

一旦开发人员在Jira中报告错误被修复，QA就会查看通过单元测试，以确保开发人员遵循公司的代码覆盖策略。此外，QA测试人员还运行了安装新代码的测试系统，以确保修复按预期工作。测试代码按预期在测试系统上运行。

修复程序已发布到生产中。到现在为止还挺好。

一周过去了。然后，当会计部门试图运行公司的月末损益表时，会发生奇怪的行为。每当系统尝试发出老化报告时，系统就会超时。（年龄报告根据年龄 - 当前，逾期30天，逾期60天，逾期90天，超过90天）对发票金额进行分类和汇总。）

混乱在Acme Widgets爆发。如果没有月末的损益表，该公司不知道它是赚钱还是赔钱。会计部门很不高兴。该系统在上个月运作良好。现在它已经坏了。会计经理与软件开发经理联系以报告问题并尽快寻求补救措施。

软件开发经理通过Jira查找在运行月末损益表之前指示任何代码更改的票证。解决过期发票问题的Jira机票瞪着他。软件开发经理致电Tech Lead，他们一起讨论代码和单元测试。一切看起来都很好，似乎。然后他们打电话给质量保证经理，让他们对这个问题有另一种看法。从表面上看，QA经理似乎也很好。

然后QA经理有预感。她看了一下单元测试，并注意到测试是针对一个小型测试数据库运行的，该测试数据库包含了今年第一季度发票的数据。该数据足以复制错误，因此可以修复错误并成功进行单元测试。但是，代码从未使用生产数据进行过测试。

技术负责人联系了进行修复的开发人员。他们一起审视修复，发现当应用于小数据集时，更改看起来是良性的。技术主管针对生产数据集的副本运行代码。事实证明，封装在函数getPastDueInvoices（dueDate）中的新代码需要5秒钟才能对生产数据执行。

在进行单元测试时，代码修复需要1.5秒才能运行。因此，它似乎很好，但在生产中，它不是。会计系统配置为对发票模块的调用超时时间为2秒。回归测试确保系统的一部分中的新代码不会在整个系统中引起不必要的副作用。

事实证明，开发人员确实通过单元测试重新测试了代码修复。QA进行了高级别检查，但未进行回归测试。修复工作在单元测试下达到预期，但在生产中运行时它破坏了系统。如果将修复程序合并到使用生产中运行的数据副本的系统范围的回归测试中，则在发布到生产之前发现该问题的可能性非常大。因此，回归测试的价值和重要性。

回归测试不仅仅是重新测试

回归测试很有价值。可悲的是，有时一家公司会认为它正在进行回归测试，而实际上它正在进行重新测试。重新测试是为了确保特定的代码更改按预期工作。回归测试旨在确保一旦引入变更，整个系统就能达到预期效果。因此，设计和实施回归测试比重新测试具有更广泛的活动范围。

如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以175317069，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。

通常，重新测试快速发生，在创建时间代码或非常接近代码。当有更多时间可用于满足执行测试所需的更长时间跨度时，回归测试在SDLC中进一步发生。是的，一些重新测试可能非常复杂且耗时，但远不及执行全面回归测试所需的时间长度。请记住，充分的回归测试意味着必须对系统的所有方面进行测试，同样重要的是，进行监控。在没有适当的系统范围监控的情况下执行回归测试会将测试工作转变为猜谜游戏。正如我们在开放场景中所展示的那样，系统的某个部分可能会发生错误，但这可能是由另一部分的行为引起的。

将回归测试纳入迭代模型

回归测试的情况很好。但是，在敏捷下实施一个可能很难。Agile和DevOps的目标是在短暂，快速的发布周期内尽快将工作软件交到用户手中。然而，回归测试需要时间，可能比单次迭代所允许的时间更长。那要做什么？

一种解决方案是在迭代之间错开回归测试。每次迭代都会发布代码版本。但是，在迭代过程中创建的代码的回归测试在迭代开始的一半开始，并继续进行下一次迭代。在迭代中途开始回归测试允许测试从业者在迭代期间新代码“稳定”时发现问题。然后，可以在以下迭代中实现和吸收修复。

将回归测试仅限于迭代中正在开发的当前版本的代码会产生创建瀑布动态的风险。在执行修复之前，开发团队可能会陷入停滞状态，等待回归测试完成。然后，一旦问题被开发人员发现并解决，回归测试人员需要等到新代码可用后才能采取进一步行动。显然，这种“切换和等待”模式与敏捷的软件开发方法是对立的。对迭代进行错综复杂的回归测试可以为测试人员提供执行所需测试范围所需的时间，同时允许开发人员在此期间创建新代码。

把它放在一起

代码在初始发布时很难完美。现代软件开发已经开始接受发布软件更多的是让它随着时间的推移而变得更好，而不是从一开始就让它变得更好。

这并不是说公司只是将代码推出门，并将发布的质量留给机会。恰恰相反。具有前瞻性思维的公司竭力做到这一点，以便在软件开发生命周期的所有阶段进行测试。此外，具有前瞻性思维的公司也明白，随着系统变得越来越大，软件创建的速度越来越快，副作用的出现机会也越来越多。因此，在整个软件开发生命周期中采用全面测试的公司特别强调回归测试。回归测试是风险缓解的第一道也是最好的防线，并确保组成软件部分的代码确实能够使整个系统更好。

这就是为什么mabl可以帮助团队为他们的应用程序创建自动化测试，并自动化回归测试。使用机器智能，mabl分析测试输出以监控整体健康状况下降，视觉变化和性能下降。