少做端到端自动化测试！

端到端自动化测试（E2E测试）是软件测试中比较常见的方法之一。

当大多数组织谈论端到端自动化测试时，他们的意思通常是：在某些环境中测试整个系统，这个环境更像生产环境的镜像。

这的确是一个好想法。我们希望能够在逼真的环境中测试系统的部署，检查可能影响系统行为的配置和任何基础结构变更，以及验证我们添加的新功能是否有效，并让自己确信：我们没有破坏以前的任何功能。

端到端自动化测试最大的挑战在于：我们如何才能做到？

在实际工作过程中，我们常常看到的端到端自动化测试的工作流程是：

1、  创建一个模拟的生产环境，特别是在构建大型软件的团队中。这样做的目的是维护一种生产系统的影子副本。

2、  团队对正在开发的应用软件进行一些变更。

3、  作为发布流程的一部分，在正式发布之前，将这个新版本部署到模拟的生产环境中，在那里通常通过手动测试对其进行评估，与其他团队开发的软件新版本一起检查所有的工作是否正常，通常所有这些都是由与软件创建无关的团队中的人员执行的。

4、  然后，由运维人员部署这些变更，他们很多时候甚至并不知道在某些地方做了哪些变更。

而且，当测试人员让开发人员评估一下这些改动的风险时，开发人员通常会说：“我也不知道，你有时间就都测试一下吧。”

然而，除了一些很简单的系统之外，端到端自动化测试可能都非常复杂且脆弱，无法真正控制变数，从而无法正确控制被测系统，因此无法正确执行测试，或得到正确的测试结果。所以，这种端到端自动化测试对环境的控制比较复杂，系统比较脆弱，因此，系统维护和用例执行成本都比较高。

所以，假如我们一旦接受：对系统进行自动化测试的最佳方法是将它与交互的所有东西全部一起部署，然后尝试与整个系统进行很广泛的交互操作，那么，很快就会失控。

为了做好质量检验工作，我们要能进行更细粒度的控制。而如上所述，端到端自动化测试无法做细粒度的变数控制，所以，要尽可能少做一些端到端自动化测试。

通常来说，端到端自动化测试活动发生得太晚了，无法帮助构建产品的质量。

正如我所说，测试人员有充分的理由感到紧张，因为此时出现问题的可能性非常高。如果这是第一次把这么多这么大的漏洞聚在一起，无论多么努力，一切都不可能顺利地按计划进行。

在这种工作方式的组织中工作，软件开发工程师可能出错的方式也会多种多样，他们几乎不可避免地工作得很慢，所以每次发布之间的时间间隔可能也会越来越大。这意味着每个版本的更改量都是巨大的，也就意味着出现错误的可能性会增加，发现错误和纠正错误的成本也会随着变更的数量呈指数级增长。当然，也许发布时间间隔没变，但测试压力变大，测试范围因时间问题而被迫变小了。

如果我们维护的是一个微服务架构下的应用系统，则存在另一个问题，那就是：无法建立系统镜像副本。现在很多微服务系统就是这样的状态，这使得测试人员很难再像十年之前那样，进行端到端自动化测试了。

然而，好的测试是确定性和原子性的，它将使我们的系统处于一个精确可预测的状态，即我们需要它所在的状态。为了运行测试，每次我们都为同一版本的软件运行这个测试，无论在什么情况下，无论一天中的什么时间，无论系统中发生了什么。

同时，我们希望每次都得到相同的结果，以保持测试的稳定性，我们也希望它在不依赖其它任何东西的情况下做到这一点。

在我们的测试和它所测试的系统之外，我们希望测试具有针对性和特定性。

测试应该简明扼要，这样就不需要做太多的工作来编写。

测试应该明确且专注于一个单一的结果。

测试应该表述准确，以便能够清楚地指定系统应该做什么。

测试应该易被理解，这样我们就可以使用它来帮助与系统开发相关的每个人，让他们方便地了解系统需要做什么。让他们知道，如果测试通过了，那么就说明他们做得没错。

测试应该有持久性，这意味着这些测试不会轻易被系统的变更破坏。测试永远不会因为系统的变化而出错，除非用户不再需要这个测试所提供的东西时，它们才失败。

在编写自动化测试时，首先要回答的问题是：

1. 决定我们的被测系统是由哪些部分组成的。

2.  这个测试负责测试被系统的哪个部分。

而持续交付部署流水线有助于帮你回答这两个问题。

“持续交付”的工作方式是指：我们所开发和维护的软件始终处于可发布状态。

那么，如何来评估这个“持续交付”的工作状态呢？如果业务人员要求你把最新的代码立即部署上线，而此时，你的回答是：“我还要再评估一下，还需要做哪些测试工作”，那么，这个软件就是不可发布状态。

从这个角度来说，持续部署部署流水线的所有工作就是完整的质量检验。

很多同学说，这很难。的确是这样的，但并不是没有办法。

在部署流水线中，应该包含各种类型的自动化测试。端到端的验收测试的确也应该是其中的一部分，但不应该是其中的绝大部分。在端到端的验收测试之前，应该包含各种已被分离关注点的更小粒度的测试，包含单元测试，组件测试，接口测试和契约测试，等等。

如果有了这些小粒度的自动化测试，那么，验收测试只需要关注它所需要关注的点（即整个系统的业务连通性），而不是关注所有功能的方方面面。

只有这样，也才让端到端的自动化测试变少，以减少因它的复杂性与脆弱性所带来的不稳定和高昂的成本。

契约测试是一种非常重要的部分代替端到端测试的测试类型。它关注于系统之间或子系统之间的契约，也就是系统连通性的一部分。

契约测试通常用于不同团队（系统）之间。当你使用（或依赖）第三方（其它团队所开发的）系统时，你应该编写契约测试，预先定义了你希望第三方给你的响应信息，用于验证第三方系统的确按你的要求进行了回应。这样的契约测试应该即可以运行于第三方的部署流水线中，也可以运行于你自己的部署流水线中。

这种方法还意味着，即使是与外部系统的复杂的长时间交互，有时也可以在极短的时间内（微秒）进行模拟，而且更具确定性。这些契约测试也比使用一个真正的系统要快得多。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）