文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

详解微服务的五种测试策略

2024-12-01 13:56

关注

译者 | 朱钢

策划 | 信远 

在测试方面,微服务需要不同的方法。

微服务应用程序是一组通过网络进行通信的分布式程序,并且与第三方服务和数据库接口进行交互。微服务就其网络性质而言,比传统的整体架构具有更多的故障点。因此我们需要一种不同的、更广泛的测试方法。

那么,我们如何测试微服务应用程序呢?测试金字塔是否仍然有效呢?当涉及第三方服务并且可能出现网络中断时,我们如何进行测试?我们将尝试在这篇文章中回答所有这些问题。

测试微服务的挑战

微服务架构是一个如此深刻的范式转变,我们必须对传统的测试技术进行重新思考。微服务在很多方面与经典的整体式架构不同:

所有这些特征迫使我们思考新的测试策略。

微服务的测试金字塔

测试金字塔是自动化软件测试的规划工具。在传统形式中,金字塔使用三种类型的测试:

微服务金字塔添加了两种新类型:组件测试和协定测试。

这是微服务测试金字塔的一个版本。在其他情况下,顺序可能会有所不同。有些可能包括集成层中的合约测试。金字塔更像是一个指导方针,而不是写在石头上的东西。

让我们更详细地了解每个金字塔图层的工作原理。

微服务的单元测试

单元测试是最细粒度且数量众多的测试形式之一。一个单元由可以单独测试的类、方法或函数组成。单元测试是开发实践不可分割的一部分,如测试驱动开发或行为驱动开发。

与整体架构相比,微服务中的单元需要网络调用来实现其功能的概率要高得多。当这种情况发生时,我们可以让代码访问外部服务(接受一些延迟和不确定性),或者用Mock 替换调用,这为我们提供了两种处理微服务依赖关系的方法:

我们可以使用Mock单独运行单元测试。或者我们可以允许测试的代码调用其他微服务,在这种情况下,我们谈论的是社交化测试。

正如你看到的,平衡信心与稳定性将是贯穿整篇文章的主题。模拟使测试变得更快并减少了不确定性,但是你模拟得越多,你就越不能相信结果。社交化测试尽管有缺点,但更现实。因此,你可能需要在这两种类型之间取得良好的平衡。

合约测试

每当两个服务通过接口耦合时,就会形成契约。该协定指定了所有可能的输入和输出及其数据结构和副作用。服务的消费者和生产者必须遵守合约中规定的规则,以便进行通信。

协定测试确保微服务遵守其协定。它们不会彻底测试服务的行为;它们仅确保输入和输出具有预期特征,并且服务在可接受的时间和性能限制内执行。

根据服务之间的关系,合约测试可以由生产者和/或消费者运行。

合约测试可以在上游或下游中运行。生产者测试检查服务没有实现会因服务而中断的更改。消费者测试针对上游生产者的模拟版本(不是真正的生产者服务)运行消费者端组件,以验证消费者可以发出请求并使用来自生产者的预期响应。我们可以使用 WireMock 等工具来重现 HTTP 请求。 

如果合约双方测试通过了,则生产者和消费者是兼容的,应该能够通信。合约测试应始终运行在持续集成中,以便在部署前检测兼容性。

你可以在 《Pact 5-minute getting started guide》中进行在线合约测试。 Pact 是一个基于 HTTP 的测试工具,用于编写和运行基于消费者和生产者的合约测试。

微服务集成测试

微服务集成测试的工作方式与其他架构略有不同。它的目标是通过使微服务交互来识别接口缺陷。与合约测试总是模拟一侧不同,集成测试使用真实的服务。

集成测试对评估服务的行为和业务逻辑不感兴趣。相反,我们希望确保微服务能够相互通信,而且可以正确和它们自己的数据库进行通信。我们正在寻找例如丢失 HTTP 请求头或不匹配的请求/响应对之类的问题。因此,集成测试通常在接口级别实现。

使用集成测试来检查微服务是否可以与其他服务、数据库和第三方端点进行通信。

微服务的组件测试

组件是在较大系统内完成一个角色的一个微服务或一组微服务。

组件测试是一种验收测试,在这种测试中我们通过用模拟资源或模拟替换服务来检查组件的行为。组件测试比集成测试更彻底,因为它们会经历“快乐”和“不快乐”的路径 。 例如组件如何响应模拟的网络中断或格式错误的请求。我们想知道组件是否满足其消费者的需求,就像我们在验收或端到端测试中所做的那样。

组件测试对一组微服务执行端到端测试。组件范围之外的服务被模拟。

有两种执行组件测试的方法:进程内和进程外。

进程内组件测试

在此组件测试子类中,测试运行程序与微服务存在于同一线程或进程中。我们在“离线测试模式”中启动微服务,其中模拟其所有依赖项,从而允许我们在没有网络的情况下运行测试。

在与微服务相同的进程中运行的组件测试。该测试在适配器中注入模拟服务,以模拟与其他组件的交互。 

仅当组件是单个微服务时,进程内测试才有效。乍一看,组件测试看起来与端到端或验收测试非常相似。唯一的区别是组件测试选择系统的一个部分(组件),并将其与其他部分隔离。该组件经过全面测试,以验证它是否执行其用户或消费者所需的功能。

组件测试和端到端测试可能看起来很相似。但不同之处在于,端到端在类似生产的环境中测试整个系统(所有微服务),而组件在整个系统的隔离部分上进行测试。这两种类型的测试都从用户(或消费者)的角度检查系统的行为,遵循用户将要执行的操作。我们可以用任何语言或框架编写组件测试,但最受欢迎的可能是Cucumber和Capybara。

进程外组件测试

进程外测试适用于任何大小的组件,包括由许多微服务组成的组件。在这种类型的测试中,组件部署在测试环境中,其中所有外部依赖项都被模拟或存根。

在这种类型的组件测试中,复杂性被推到测试环境中,测试环境应该复制系统的其余部分。

为了完善合约测试的概念,您可以探索《Java Spring上合约测试的示例代码》。此外,如果您是Java开发人员,那么这篇文章提供了用于在各个级别测试Java微服务的代码示例

微服务中的端到端测试

到目前为止,我们已经对系统进行了零碎的测试。单元测试用于测试微服务的各个部分,合约测试涵盖API兼容性,集成测试检查网络调用,组件测试用于验证子系统的行为。只有在自动化测试金字塔的最顶端,我们才能测试整个系统。

端到端(E2E)测试确保系统满足用户的需求并实现业务目标。E2E 套件应使用与用户相同的接口覆盖应用程序中的所有微服务,通常结合使用 UI 和 API 测试。

应用程序应在尽可能靠近生产环境中运行。最理想情况是测试环境将包括应用程序通常需要的所有第三方服务,但有时这些服务可以被模拟,以降低成本或防止滥用。

端到端是模拟用户交互的自动化测试。只有外部第三方服务可能会被嘲笑。

正如测试金字塔所描述的那样,E2E测试是数量最少的,因为它们通常是最难运行和维护的。只要我们专注于用户的操作和他们的需求,我们只需要几个端到端的测试就可以提取很多资源价值。

结论

不同的模式要求改变测试策略。在微服务架构中进行测试比以往任何时候都更加重要,但我们需要调整技术以适应新的开发模型。系统不再由单个团队管理。相反每个微服务所有者都必须尽自己的一份力量,以确保应用程序作为一个整体工作。

一些组织可能会认为单元、合约和组件测试就足够了。其他不满足于没有端到端和集成测试的人可能会选择建立一个 QA 团队来促进跨团队的测试覆盖。

译者介绍

朱钢,51CTO社区编辑,2021年IT影响力专家博主,阿里云专家博主,2019年CSDN博客之星20强,2020年腾讯云+社区优秀作者,11年一线开发经验,曾参与猎头服务网站架构设计,企业智能客服以及大型电子政务系统开发,主导某大型央企内部防泄密和电子文档安全监控系统的建设,目前在北京图伽健康从事医疗软件研发工作。

原文Testing Strategies for Microservices,作者:Tomas Fernandez

链接:https://dzone.com/articles/testing-strategies-for-microservices

来源:51CTO内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯