软件测试 52 讲
茹炳晟
腾讯 TEG 基础架构部 T4 级专家
71691 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
结束语 (1讲)
软件测试 52 讲
15
15
1.0x
00:00/00:00
登录|注册

24 | 紧跟时代步伐:微服务模式下API测试要怎么做?

基于Spring Cloud Contract的示例演示
解决微服务之间耦合关系
契约的获取
保证API质量、减少测试用例数量
微服务之间的耦合关系
庞大的测试用例数量
特征:轻量级通信机制、围绕具体业务构建、高要求的运维
特点:独立运行、独立开发、独立部署、独立发布
由一系列相互独立的微服务组成
问题:灵活性差、可扩展性差、稳定性差、可维护性差
优点:发布简单、方便调试、架构复杂性低
表示层、业务逻辑层、数据访问层
解决新开发或加功能API的契约获取方法
思考题
基于消费者契约的API测试
API测试挑战
单体架构 vs. 微服务架构
代码实例
原理
概念
挑战
架构风格
架构模式
目的:帮助理解微服务模式下的API测试
作者:茹炳晟
主题:微服务模式下的API测试
思考题
总结
基于消费者契约的API测试
微服务架构下的测试挑战
微服务架构(Microservice Architecture)
单体架构(Monolithic Architecture)
介绍
微服务模式下的API测试要怎么做?

该思维导图由 AI 生成,仅供参考

你好,我是茹炳晟,今天我分享的主题是“紧跟时代步伐:微服务模式下 API 测试要怎么做?”。
通过一个的 Restful API 实例,我介绍了 cURL 和 Postman 工具的基本用法,这样我们对 API 测试有了一个感性认识;在此基础上,我介绍了 API 自动化测试框架发展的来龙去脉,借此我们对 API 测试框架的理解又更深入了一层。
今天,我将更进一步,带你去了解当下最热门的技术领域的 API 测试,即微服务模式下的 API 测试。微服务架构下,API 测试的最大挑战来自于庞大的测试用例数量,以及微服务之间的相互耦合。所以,我今天分享这个主题的目的就是,帮你理解这两个问题的本质,以及如何基于消费者契约的方法来应对这两个难题。
而为了掌握微服务模式下的 API 测试,你需要先了解微服务架构(Microservice Architecture)的特点、测试挑战;而要了解微服务架构,你又需要先了解一些单体架构(Monolithic Architecture)的知识。所以,今天的话题我将逐层展开,目的就是希望你可以真正理解,并快速掌握微服务模式下的 API 测试。

单体架构(Monolithic Architecture)

单体架构是早期的架构模式,并且存在了很长时间。单体架构是将所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中,最终经过编译、打包,并部署在服务器上。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了微服务架构下的API测试方法,重点讨论了基于消费者契约的API测试和微服务之间的依赖解耦。作者首先指出微服务架构下的测试挑战主要来自于庞大的测试用例数量和微服务之间的耦合关系。针对这一问题,作者提出了基于消费者契约的API测试方法,通过该方法可以减少测试用例数量,同时解耦微服务之间的依赖关系。文章通过实际例子和图示生动地阐述了微服务架构下的测试挑战和解决方法。此外,文章还介绍了微服务测试的依赖解耦和Mock Service的实现原理,并提供了基于Spring Cloud Contract的实际代码示例。总结指出,基于消费者契约的API测试方法能够有效解决微服务架构下的测试挑战,同时强调了该方法的优势和应用场景。整体而言,本文内容深入浅出,为读者提供了全面了解微服务模式下的API测试方法的机会。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件测试 52 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(38)

  • 最新
  • 精选
  • 小明同学
    你好,我想问下接口测试下这个代码覆盖率是怎么统计的?

    作者回复: 和代码级覆盖率统计使用一样的方法和工具,比如jacoco

    2018-08-22
    2
    12
  • 楚耳
    api gateway 并不是每个服务间都存在的,只有面向客户端的服务才会有这一层。内部服务间是不存在在这一层的。所以这种方式去过滤不是很全面

    作者回复: 很好的点,内部调用主要靠splunk来获取

    2018-12-29
    9
  • 假装乐
    期待文末问题的答案

    作者回复: 答案是需要两部分结合起来,老的功能走契约测试,新的功能和api继续沿用老的方法

    2018-08-22
    5
  • 口水窝
    现在待得的公司还是传统的单体架构,没有接触到微服务架构,这篇文章给我打开了一个全新的视角,思路上也有很多。

    作者回复: 感谢支持

    2019-04-12
    1
  • emilymeng
    老师,能详细讲解一下代码覆盖率的测试方法和使用到的工具?

    作者回复: 主要取决于开发代码的语言,如果是java就可以直接使用jacoco

    2018-08-22
    1
  • johnny
    这篇文章也有助于理解文中提到的的实例代码。 http://www.bubuko.com/infodetail-2317705.html

    作者回复: 感谢分享

    2019-01-23
  • yinyin
    如果依赖的服务是中间件,能用mock代替吗?

    作者回复: 这要具体问题具体分析了,理论上是可以的

    2018-09-05
  • 和你一起搬砖的胡大爷
    api gateway一般是作为整个微服务的入口,做一些权限校验,路由功能,服务间的内部调用不走api gateway。spring cloud的例子 zuul作为api gateway,load balancer是ribbon。要去抓取调用记录在被测服务记录访问日志。这个作为audit log本来就是要记录的。我们的契约测试是调用放手写在被调用服务,拥有者是调用方。以此来确保api的兼容。
    2018-08-22
    23
  • ghost
    这个问题有点尴尬的是,如果开发的代码进行了变动,以前测试的契约文件(mock)就错了。茹老师我想知道,这块怎么能把开发的代码变动和mock文件关联起来。
    2020-03-17
    9
  • 图·美克尔
    感觉基于消费者契约这种方式也没有显著降低case的数量啊
    2018-08-29
    8
收起评论
显示
设置
留言
38
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部