复杂分布式系统的测试

未分类

摘要： Sarah Wells在2019欧洲测试大会上提出：复杂分布式系统的复杂性并非存在于代码中，而是存在于服务或功能之间；测试意味着寻求在发现问题与提供价值间达成平衡；测试人员通常对系统功能具有最好的理解；他们能很好地设想存在问题隐患之处，并尽快给出验证。

作者： Ben Linders

正文：

在2019欧洲测试大会上，Sarah Wells演讲指出：复杂分布式系统的复杂性并非存在于代码中，而是存在于服务或功能之间；测试就是寻求如何在发现问题与交付价值间达成平衡；测试人员通常具有对系统功能的最好理解；测试人员能很好地设想出存在问题隐患之处，并尽快给出验证。

Wells在她的主题演讲中，探讨了系统在复杂化和分布式后所发生的变化。对于单体系统而言，虽然可能很难定位实现特定功能的代码位置，但是很容易判别系统中请求流的运行情况，并且大多数通信是在进程之间的。Wells认为，分布式系统的复杂性已从系统内部转移到系统之间。

使用微服务可简化代码，但会使基于http或队列实现的路由复杂化。Wells支持在路由上可能会出现更多的问题。用户常常会收到一些表示请求失败的瞬态错误，这些错误会在重复数秒后变为成功。她认为明智的做法建立一种补偿和重试机制，但采用这种做法意味着用户更难以完全掌控发生在响应请求中的情况。

Wells建议用户使用基于风险的方法，让测试工作聚焦于那些真正重要的事情上。她提出，用户需要能够快速确定发生错误的时间，尽快修复错误，并且必须要建立具备观测出错位置能力的系统。

Wells提到，对于复杂分布式系统的测试，用户需在尽早发现问题和尽早交付价值间取得平衡。她认为用户最好应该能接受这一观点，即一些问题是直到系统投入生产后才会被发现的，进而做出优化以快速识别和修复这些问题。

InfoQ报道全程覆盖2019欧洲测试大会。在Sarah Wells主题演讲后，InfoQ就复杂分布式系统的测试问题对她做了一次专访。

InfoQ：您对于复杂分布式系统的测试有哪些建议？

Sarah Wells：我们发现，无论是开发人员还是测试人员，在着手构建复杂分布式系统时，都无法试图在本地启动完整的系统副本。用户花费了大量时间去创建很好的生产系统副本，但却从未对其实现完全管理。

需强调的是，我们这里讨论的是复杂系统。如果你无法评估特定更改的可能影响范围，那么你可以花大量的时间做回归测试。我们发现尽管测试是瓶颈所在，但通常在测试中并不能发现问题。

和许多事情一样，问题主要存在于沟通上。如果开发人员能详细阐述了他们刚完成的工作，那么通常测试人员就能查明变更可能带来的最大风险。

持续交付和微服务是对此最具帮助的做法。许多变更通常非常小型，并且相互独立。微服务具有非常明确的界限。《加速，精益软件和DevOps科学：建立和扩展高绩效技术团队》一书中提及的研究表明，那些频繁发布小型单独变更的组织，通常在这些变更上具有较低的失败率。

我认为应在系统间建立合约。但我不确定的是，维护合约测试的成本是否会高于错误的风险。我考虑瞄准的目标是针对团队间的边界，而非系统内。

InfoQ：监控和日志如何支持测试？甚至它们将如何替代测试？

Wells：分布式系统的许多问题，几乎与最新发布的代码没有关系。这些问题可能与运行代码的环境有关，或是可能是由于服务之间的依赖关系，即更改为另一个可导致意外错误的服务。服务可能属于不同的团队。用户甚至可能不知道某个服务调用了自身的API。

因此一个更改一旦投入生产系统，要求就是尽早发现问题并回滚。

问题的发现可通过综合监控等手段，用户时常测试关键业务功能或是监控业务进展层级，检查事件的真实完成情况。在此给出一个例子，对于内容发布，我们检查自身区域中存储的所有相关数据是否正确更新，否则就给出警告。

我们也在更底层的环境中运行测试。这些测试替代了那些十分脆弱的验收测试。由任何更改所导致的设置修改，都是非常痛苦的。而且对于这类复杂架构，通常会产生很大的更改。

我们所构建的系统必须提供可观测能力，以便在第一时间定位错误。

这意味着，绝对有必要将全部日志汇集于单处日志存储中，并且为了易于查询需要对日志做结构化。在复杂系统中请求会经由多个服务，所需存储的日志规模可能会高于单体系统数个数量级，因此用户可能最终会对日志做抽样。在这种情况下，需要确保任一特定时间的所有日志都得到存储，并且能够通过唯一的事务标识关联所有相关日志。

用户可能还希望获取一些度量，但很容易发生过度获取的问题。用户切实需要的应是那些最高层级服务的度量，即客户呼叫、报告请求率、错误率（可能是请求率的一部分）以及请求持续时间等。这些度量通常称之为RED度量。

InfoQ：在出现错误时，测试人员的作用是什么？他们的价值何在？

Wells：根据我的经验，对系统功能具有最好理解的人，除了产品负责人（PO，product owner）就是测试人员。我已经看到很多测试人员逐渐转型为产品负责人。

这表明了两个问题。第一，测试人员对即将发生的问题具有很好的预判。

其次，测试人员将能够很快地验证假设问题。他们知悉API的调用，网站的流程。

此外，在出现问题前，测试人员也能提供大量价值。我认为，混沌工程当然需要测试人员的参与。因为混沌工程就是开展探索。如果关闭某处系统会发生什么情况？如果密钥过期会发生什么问题？这些假设和弹性测试对于复杂分布式系统是非常重要的，也具有很大的价值。

查看英文原文： Testing Complex Distributed Systems