写点什么

为什么我们需要自动化回归?

发布于: 2021 年 01 月 13 日
为什么我们需要自动化回归?

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


前言


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


  • 服务不具备独立验证能力;

  • 自动化用例开发效率很低;

  • 在高并发的使用场景下健壮性如何保证;

  • 如何及时发现现网服务出现异常。


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


image.png


在这个典型的企业微服务应用架构图中,Product Service 应用提供查询商品列表和通过 ID 查询商品详情的功能,Business Service 应用提供添加商品到购车的功能。如果想验证用户操作的从查询商品列表→通过 ID 查询商品详情→将商品添加至购物车这个业务场景,现在我们一般怎么做呢?


  1. 进入 Product Service 应用部署所在的机器(ECS)或者容器(Pod),通过 curl 命令调用查询商品列表,验证返回的商品列表是否不为空。

  2. 把查询商品列表返回值中的 ID 拼接到 curl 命令的入参中,调用通过 ID 查询商品详情,验证详情中的字段是否符合预期。

  3. 进入 Business Service 应用部署所在的机器(ECS)或者容器(Pod),把 ID 拼接到 curl 命令入参中调用添加该商品至购物车,验证添加是否成功。


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


  • 云上网络拓扑复杂

  • 业务链路场景验证难

  • 重复繁琐操作验证效率低


为什么我们需要自动化回归


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

image.png


MSE 自动化回归实践


前提条件:微服务应用已接入 MSE。


下面围绕前言中描述的场景如何使用微服务测试的自动化回归,从用例设计,用例生成,用例执行,打造简单、高效、专业的微服务测试能力,为微服务上线保驾护航。

用例设计


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


image.png

用例生成

1、登录 MSE 控制台,在页面左上角选择地域;

2、左侧导航栏选择:微服务治理 -> 微服务测试 -> 自动化回归 -> 创建用例;

3、第 1 测试步骤查询商品列表,选择 productservice 应用 -> 选择 Spring Cloud 框架 -> 选择/ products 服务 -> (默认)选择 GET 方法;第 1 测试步骤无需入参,直接点击“访问一次”查看返回值,再点击“出参提取助手”获取需要校验的检查对象:


image.png


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


image.png


image.png


5、点击“添加下一步骤”增加第 2 测试步骤查询商品详情,选择 productservice 应用 -> 选择 Spring Cloud 框架 -> 选择/ product/{id} 服务 -> (默认)选择 GET 方法;Path 切换自定义输入,将/ product/{id}修改为/product/${id},即把第 1  测试步骤中提取的 id 传入第 2 步骤:


image.png


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


image.png


image.png


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


image.png


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


image.png


用例执行


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


image.png


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


image.png

我们还有什么能力


本文介绍了微服务治理下微服务测试-自动化回归的能力,补齐了微服务生态测试的能力,但我们不止于此,我们即将夯实自动化回归能力,提供多样化的入参能力(系统函数、环境变量、集合变量、全局变量、参数化、参数容错自动生成等等),提供测试集管理能力(将测试用例分组、批量执行),丰富的执行能力(串行执行、并行执行、定时执行),甚至与服务测试、服务巡检、服务压测结合,将服务测试一键生成测试用例,将测试用例一键生成巡检任务、生成压测场景。


除了 MSE(微服务引擎),微服务测试能力还将被 EDAS、SAE 等云产品集成。将微服务测试能力作为一个基础能力被更多云产品集成,另外,将跟更多微服务产品 ARMS (应用实时监控服务)、ACM(应用配置管理)、CSB(网关)形成联动,助力保障云上业务稳定性,让业务永远在线。


原文链接:为什么我们需要自动化回归?


用户头像

还未添加个人签名 2020.12.09 加入

还未添加个人简介

评论

发布
暂无评论
为什么我们需要自动化回归?