如何在复杂的分布式系统中做测试

\u003cblockquote\u003e\n\u003cp\u003e在\u003ca href=\"https://europeantestingconference.eu/\"\u003e2019欧洲测试大会\u003c/a\u003e上，Sarah Wells演讲指出：复杂分布式系统的复杂性并非存在于代码中，而是存在于服务或功能之间；测试就是寻求如何在发现问题与交付价值间达成平衡；测试人员通常具有对系统功能的最好理解；测试人员能对可能出现问题做出很好的假设，然后非常快速地进行验证。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eWells在她的主题演讲中，探讨了系统在复杂化和分布式后所发生的变化。对于单体系统而言，虽然可能很难定位实现特定功能的代码位置，但是很容易判别请求在系统中的流转，并且大多数通信是在进程之间的。Wells认为，分布式系统的复杂性已从系统内部转移到系统之间。\u003c/p\u003e\n\u003cp\u003e使用微服务可简化代码，但会使基于http或队列实现的路由复杂化。Wells支持在路由上可能会出现更多的问题。用户常常会收到一些表示请求失败的瞬态错误，这些错误会在重复数秒后变为成功。她认为明智的做法建立一种补偿和重试机制，但采用这种做法意味着用户更难以完全掌控发生在响应请求中的情况。\u003c/p\u003e\n\u003cp\u003eWells建议用户使用基于风险的方法，让测试工作聚焦于那些真正重要的事情上。她提出，用户需要能够快速确定发生错误的时间，尽快修复错误，并且必须要建立具备观测出错位置能力的系统。\u003c/p\u003e\n\u003cp\u003eWells提到，对于复杂分布式系统的测试，用户需在尽早发现问题和尽早交付价值间取得平衡。其实，一些问题直到系统投入生产后才能被发现，进而做出优化以快速识别和修复这些问题，她认为用户最好能接受这一点。\u003c/p\u003e\n\u003cp\u003eInfoQ报道全程覆盖\u003ca href=\"https://europeantestingconference.eu/\"\u003e2019欧洲测试大会\u003c/a\u003e。在\u003ca href=\"https://www.infoq.com/profile/Sarah-Wells\"\u003eSarah Wells\u003c/a\u003e主题演讲后，InfoQ就复杂分布式系统的测试问题对她做了一次专访。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：您对于复杂分布式系统的测试有哪些建议？\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eSarah Wells\u003c/strong\u003e：我们发现，无论是开发人员还是测试人员，在着手构建复杂分布式系统时，都无法试图在本地启动完整的系统副本。用户花费了大量时间去创建很好的生产系统副本，但却从未妥善管理它们。\u003c/p\u003e\n\u003cp\u003e需强调的是，我们这里讨论的是复杂系统。如果你无法评估特定更改可能会影响到的范围，那么就得花大量的时间做回归测试，我们发现这是个瓶颈，而且往往并不能发现问题。\u003c/p\u003e\n\u003cp\u003e和许多事情一样，问题主要存在于沟通上。如果开发人员能详细阐述了他们刚完成的工作，那么通常测试人员就能准确地找出变更可能带来的最大风险。\u003c/p\u003e\n\u003cp\u003e持续交付和微服务是对此最具帮助的做法。许多变更通常非常小型，并且相互独立。微服务具有非常明确的界限。《\u003ca href=\"https://www.infoq.com/articles/book-review-accelerate\"\u003e加速，精益软件和DevOps科学：建立和扩展高绩效技术团队\u003c/a\u003e》一书中提及的研究表明，那些频繁发布小型单独变更的组织，通常这些变更的失败率也比较低。\u003c/p\u003e\n\u003cp\u003e我认为应在系统间建立契约。但我不确定的是，维护契约测试的成本是否会高于错误的风险。我的想法是，将目标锁定为团队间的边界，而非系统内。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：监控和日志如何支持测试？甚至它们将如何替代测试？\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eWells\u003c/strong\u003e：分布式系统的许多问题，几乎与最新发布的代码没有关系。这些问题可能与运行代码的环境有关，或是可能是由于服务之间的依赖关系，即更改为另一个可导致意外错误的服务。服务可能属于不同的团队。用户甚至可能不知道某个服务调用了自己的API。\u003c/p\u003e\n\u003cp\u003e因此一个更改一旦投入生产系统，至少能够尽早发现问题并回滚。\u003c/p\u003e\n\u003cp\u003e可以通过类似于综合监控的手段，不断测试关键的业务功能，或者监控业务能力水平，也就是检查事件的实际完成情况。以内容发布为例，我们可以检查在我们的区域中存储的所有相关数据是否正确更新，否则就给出警告。\u003c/p\u003e\n\u003cp\u003e我们也在更底层的环境中运行测试。这些测试替代了那些十分脆弱的验收测试。当做任何变更时都要修改设置，这是件非常痛苦的事。而且很多变更是做架构类的调整。\u003c/p\u003e\n\u003cp\u003e我们所构建的系统必须提供可观测能力，以便在第一时间定位错误。\u003c/p\u003e\n\u003cp\u003e这意味着，绝对有必要将全部日志汇集于单个日志存储中，并且需要对日志做结构化以易于查询。在复杂系统中请求会经由多个服务，所需存储的日志规模可能会高于单体系统几个数量级，因此用户可能最终会对日志做抽样。在这种情况下，需要确保任一特定时间的所有日志都得到存储，并且能够通过唯一的事务标识关联所有相关日志。\u003c/p\u003e\n\u003cp\u003e用户可能还希望获取一些度量，但很容易发生过度获取的问题。用户切实需要的应是那些最高层级服务的度量，即客户呼叫、报告请求率、错误率（可能是请求率的一部分）以及请求持续时间等。这些度量通常称之为RED度量。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eInfoQ：在出现错误时，测试人员的作用是什么？他们的价值何在？\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eWells\u003c/strong\u003e：根据我的经验，对系统功能具有最好理解的人，除了产品负责人（PO，product owner）就是测试人员。我已经看到很多测试人员逐渐转型为产品负责人。\u003c/p\u003e\n\u003cp\u003e这表明了两个问题。第一，测试人员对即将发生的问题具有很好的预判。\u003c/p\u003e\n\u003cp\u003e其次，测试人员将能够很快地验证假设问题。他们知悉API的调用，网站的流程。\u003c/p\u003e\n\u003cp\u003e此外，在出现问题前，测试人员也能提供大量价值。我认为，很显然混沌工程需要测试人员的参与。因为混沌工程就是开展探索。如果关闭某处系统会发生什么情况？如果密钥过期会发生什么问题？这些假设和弹性测试对于复杂分布式系统是非常重要的，也具有很大的价值。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e查看英文原文：\u003c/strong\u003e \u003ca href=\"https://www.infoq.com/news/2019/02/testing-distributed-systems\"\u003eTesting Complex Distributed Systems\u003c/a\u003e\u003c/p\u003e\n