关于程序员:为什么我们需要自动化回归

44次阅读

共计 2382 个字符,预计需要花费 6 分钟才能阅读完成。

本文是《微服务治理实际》系列篇的第六篇文章,为大家介绍微服务测试中的自动化回归:基于微服务契约信息疾速编排被测服务、治理自动化测试用例。可视化用例编辑界面,丰盛的预置检查点、内置变量,反对自定义变量、参数传递、继续自动化测试,帮忙您高效治理、回归业务测试场景,帮忙业务疾速验证、疾速交付。该系列文章基于阿里云商业化产品 MSE 的微服务实际,如果您的团队具备较强的微服务治理 + 测试能力,那么心愿咱们在微服务治理 + 测试方面的实际和背地的思考,能够为您提供一些参考。

第一篇:《微服务治理解密》

第二篇:《微服务治理实际:服务查问》

第三篇:《微服务治理实际:金丝雀公布》

第四篇:《微服务治理实际:服务契约》

第五篇:《微服务治理实际:如何升高微服务测试老本》

前言


以后微服务迭代周期短、版本多,服务须要具备独立测试和疾速验证能力,撑持服务测试耗时缩短以及测试流动前移。面临多方面的挑战:

  • 服务不具备独立验证能力;
  • 自动化用例开发效率很低;
  • 在高并发的应用场景下健壮性如何保障;
  • 如何及时发现现网服务出现异常。

本文旨在讲述“自动化用例开发效率很低”的次要解决方案,在具体讲述微服务测试—自动化回归之前,先给大家讲一个场景。

在这个典型的企业微服务利用架构图中,Product Service 利用提供查问商品列表和通过 ID 查问商品详情的性能,Business Service 利用提供增加商品到购车的性能。如果想验证用户操作的从查问商品列表→通过 ID 查问商品详情→将商品增加至购物车这个业务场景,当初咱们个别怎么做呢?

  1. 进入 Product Service 利用部署所在的机器(ECS)或者容器(Pod),通过 curl 命令调用查问商品列表,验证返回的商品列表是否不为空。
  2. 把查问商品列表返回值中的 ID 拼接到 curl 命令的入参中,调用通过 ID 查问商品详情,验证详情中的字段是否合乎预期。
  3. 进入 Business Service 利用部署所在的机器(ECS)或者容器(Pod),把 ID 拼接到 curl 命令入参中调用增加该商品至购物车,验证增加是否胜利。

如果以上场景一次验证不通过,还要重复反复以上操作,至此咱们能够总结出云上微服务测试的几点问题:

  • 云上网络拓扑简单
  • 业务链路场景验证难
  • 反复繁琐操作验证效率低

为什么咱们须要自动化回归


微服务测试自动化回归,联合咱们的研发实际和研发理念,测试用例免代码编写、一键选取被测服务、疾速组装编排、低成本治理自动化测试用例。

MSE 自动化回归实际


前提条件:微服务利用已接入 MSE。
上面围绕前言中形容的场景如何应用微服务测试的自动化回归,从用例设计,用例生成,用例执行,打造简略、高效、业余的微服务测试能力,为微服务上线保驾护航。

用例设计

首先咱们设计被测服务的加购物车业务场景,包含查问商品列表、查问商品详情、增加商品至购物车三步,设定每步的入参和预期。

用例生成

  1. 登录 MSE 控制台,在页面左上角抉择地区;
  2. 左侧导航栏抉择:微服务治理 -> 微服务测试 -> 自动化回归 -> 创立用例;
  3. 第 1 测试步骤查问商品列表,抉择 productservice 利用 -> 抉择 Spring Cloud 框架 -> 抉择 / products 服务 ->(默认)抉择 GET 办法;第 1 测试步骤无需入参,间接点击“拜访一次”查看返回值,再点击“出参提取助手”获取须要校验的查看对象:

  1. 第 1 测试步骤在“断言(选填)”中粘贴刚选取的查看对象,查看条件抉择不是空;在“出参提取(选填)”的出参提取表达式中粘贴须要提取的 id 字段,并定义出参名为 id:

  1. 点击“增加下一步骤”减少第 2 测试步骤查问商品详情,抉择 productservice 利用 -> 抉择 Spring Cloud 框架 -> 抉择 / product/{id} 服务 ->(默认)抉择 GET 办法;Path 切换自定义输出,将 / product/{id}批改为 /product/${id},即把第 1  测试步骤中提取的 id 传入第 2 步骤:

  1. 同时也对第 2 测试步骤设置断言和出参提取:

  1. 点击“增加下一步骤”减少第 3 测试步骤查问商品详情,抉择 cartservice 利用 -> 抉择 Dubbo 框架 -> 抉择 CartService 服务 -> 抉择 addItemToCart 办法;在根本信息中编辑入参数据,传入第 1 和第 2 测试步骤提取的入参,并在断言中设置预期返回值为 true:

  1. 点击“保留配置”。至此已胜利将用例设计的业务场景转化成一个俱备上下文传参、丰盛断言的能力的自动化测试用例。

用例执行

触发立刻执行测试用例,在执行历史查看验证业务的正确性和编排用例的正确性。

查看验证不通过测试步骤的具体失败信息,比方预期价格为 900,理论为 800,校验等于(数字)比拟失败。

咱们还有什么能力


本文介绍了微服务治理下微服务测试 - 自动化回归的能力,补齐了微服务生态测试的能力,但咱们不止于此,咱们行将夯实自动化回归能力,提供多样化的入参能力(零碎函数、环境变量、汇合变量、全局变量、参数化、参数容错主动生成等等),提供测试集治理能力(将测试用例分组、批量执行),丰盛的执行能力(串行执行、并行执行、定时执行),甚至与服务测试、服务巡检、服务压测联合,将服务测试一键生成测试用例,将测试用例一键生成巡检工作、生成压测场景。
除了 MSE(微服务引擎),微服务测试能力还将被 EDAS、SAE 等云产品集成。将微服务测试能力作为一个根底能力被更多云产品集成,另外,将跟更多微服务产品 ARMS (利用实时监控服务)、ACM(利用配置管理)、CSB(网关)造成联动,助力保障云上业务稳定性,让业务永远在线。

如果您在微服务引擎 MSE 应用微服务测试过程中有任何疑难,欢迎您增加 钉钉群号:31180380  退出钉钉群进行反馈。

【阿里巴巴中间件】专一于微服务、容器服务、Serverless……等云原生热门话题,关注同名公众号获取更多精彩内容和福利!
tips:公众号后盾回复【抽奖】有惊喜,流动最初一天~

正文完
 0