回归测试：防止破坏已经有效的方法

最严重的错误类别不是您在新功能中引入的错误。这就是你复活旧功能的方法，它一直工作得很好，直到有人改变了其他功能。

这是熟悉的场景。团队修复了一个问题，部署了它，庆祝了三天，三天后发现这个修复悄悄地破坏了没有人想到检查的流程。客户首先找到它。对系统和团队的信任受到打击。

这种现象有一个名字：回归。是制度在倒退。为避免这种情况而存在的一组实践是回归测试，它可能是所有测试中最被低估和最有价值的类型。

什么是回归测试

回归测试是对已经存在的功能重新执行测试，以确保最近的更改不会破坏任何已经有效的功能。关键词是“已经存在”。它不会检查您刚刚构建的内容；它会检查您刚刚构建的内容；检查您在构建过程中可能意外损坏的所有内容。

前提是软件的一个令人不安的事实：每个系统都是一个依赖关系网，其中许多是不可见的。更改一个点可能会影响代码中一英里之外的另一个点。没有人能够仅仅通过思考来预测变革的所有后果。回归测试就像一张网，可以捕捉到你的头脑没有预测到的东西。

软件不是静态的。它一直在变化，修复、功能、库更新、配置调整。每一次变化，无论看起来多么小，都可能带来倒退的风险。

危险的是，变化的大小并不能预测损害的大小。如果该线路位于系统许多部分共享的点，则对该线路的更改可能会导致关键流程中断。我见过一些微不足道的修复会导致比整个重写更大的事件。

这就是维护的悖论：系统越成长和成熟，它就变得越有价值，而改变它的风险就越大，因为有更多的东西可能会被破坏。如果没有回归网络，团队就会害怕接触产品本身。系统“冻结”并不是因为它已经准备好了，而是因为它太危险而无法触摸。

可以手动进行回归，在每次更改后手动重新运行主要流程。当系统较小时它可以工作。它很快就停止工作。

问题在于规模和重复性。每次变化都需要在一个只会增长的集合上进行回归。手动重复执行此操作成本高昂、速度缓慢，更糟糕的是，容易造成人体疲劳。手动测试人员在第一百次检查相同的流程时，就不太注意了。这是自然的。

这就是为什么回归是自动化的典型用例。自动化测试不会感到疲倦，不会跳过步骤，并且可以在几秒钟内运行，而手动测试则需要几个小时。这正是机器比人做得更好的重复、客观的检查。自动回归套件使您可以放心地频繁更改系统。

并非所有东西都需要在套房内。试图覆盖每一条可能的路径会产生一个庞大、缓慢且昂贵的维护套件，而团队最终忽略了它。

经验法则是按风险和频率确定优先级。输入企业的关键流程，这些流程的故障会导致真正的损害或丧失信心。还有一些区域在历史上已经被破坏：每个修复的错误都应该成为回归测试，以确保它不会返回。这是团队可以采取的最佳习惯之一。

往往被遗漏或给予较低优先级的是外围的、很少使用的、低影响的功能。全面覆盖不是目标；保护重要的是。

第一个错误是让套件腐烂。回归测试反映了系统的预期行为。当行为合法地改变并且测试没有更新时，它们会失败，因为它们已经过时，而不是因为实际的错误。团队学会了忽略失败，网络就不再捕获任何东西。

二是容忍间歇性测试。有时通过、有时无故失败的回归测试是毒药：它削弱了整个套件的可信度。当红色不再意味着“有东西坏了”时，回归就失去了它的功能。

第三是回归太晚了。如果套件仅在发布前一天运行，问题就会累积并且跟踪成本会变得昂贵。理想的情况是在集成传送带上运行每次更改，以便在修复成本仍然较低的情况下检测到接近原因的中断。

有一种误解，认为回归测试是一种阻碍，是一种延迟交付的官僚机构。事实恰恰相反。一个好的回归套件可以让团队自由地快速交付。

没有它，每一次改变都需要谨慎、手动检查和恐惧。有了它，开发人员可以更改代码，运行套件，并在几分钟内知道是否有问题。这种信任使您能够随着系统的发展保持交付速度。回归不会阻碍速度；这就是速度可持续的原因。

在支持公共或私人关键服务的系统中，这一点甚至更具决定性。发展一个基本系统而不用担心推翻现有系统的能力本质上是一种治理能力。回归测试是实现这一目标的工具之一。

归根结底，所有稳定的软件都是有人有勇气不闲置的系统。回归使这种勇气变得负责任而不是鲁莽。

如果您的团队已经避免接触系统的某些部分，因为担心会破坏某些东西，那么这种恐惧是缺乏回归网络的症状，并且是可以解决的。我在博客上还有其他关于质量、自动化和软件维护的文章与此相关。