dubbo服务接口如何mock_小程聊微服务-基于dubbo的mock测试系统
一、说在前面
基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的,我今天就主要介绍一下,我们研发的一套mock测试系统。
二、目前面临的问题
1、测试人员面临的测试问题
我公司目前用的是基于Dubbo的微服务改造,服务之间的调用链路冗长,每个服务又是单独的团队在维护,每个团队又在不断的演进和维护各个服务,那么对测试人员将是非常大的挑战。
测试人员每次进行功能测试的时候,测试用例每次都需要重新写一遍,无法将测试用例的数据沉淀,尤其是做自动化测试的时候,测试人员准备测试数据就需要很长时间,效率非常低。
目前接口自动化测试框架也多种多样,testng,junit,Fitnesse等,但都需要测试人员具备测试代码编写能力,如果要做好和手工接口测试一样效果的自动化测试更是需要大量的代码堆积,后期维护代码成本非常大。因此做成简单配置用例流,无需编写测试代码的系统是更贴合实际工作要求。
举个例子:拿互联网支付系统来说,某个团队新增了支付交易的需求,这时候要进行测试,测试人员除了要测试支付交易需求本身是否正确,同时也要结合上下游的服务整体进行回归测试,这时候开发人员往往在支付交易系统中采用“硬编码”的方式对上下游的系统进行“挡板”,如果测试人员对测试数据有所调整那么“挡板”也要跟着调整,同时在项目正式上线的时候,如果开发人员没有将“挡板”程序去除干净,将面临严重的线上问题。
2、测试人员如何验证数据
接口返回值
通过肉眼分析比对接口返回值的内容,判断业务逻辑正确性。
数据库验证
测试接口的输入值需要通过手工编写数据库SQL查询获取,接口调用完成后,需要通过大量的SQL验证数据库值的正确性。
日志验证
通过返回值和数据库不能确保代码走到了预期的逻辑,只能通过肉眼观察日志确认代码的实际运行逻辑
测试报告
人工记录用例结果,人工编写报告,耗时耗力,难以准确定位代码问题
三、Mock模拟系统的产生
业务系统调用众多其他系统完成功能逻辑,而想要得到其他系统接口的特定输出,需要做相应的运营配置,增加很多的沟通成本;甚至偶发性bug只能在特定的环境状况下复现,只能作为不可测的逻辑。
以风控系统为例,如果业务系统需要测试某个商编某个商品类别下的累积限额,需要风控的同事配合不断修改限额阈值,目前的情况是多个业务系统都在接入风控,配合测试的人力成本和时间成本是很高的。为此设计了挡板模拟系统,其功能结构如下:
1049928-12fa1aaf24d93b1b.png
针对测试人员测试用例数据无法沉淀和复用的问题,我们将采用“用例与日志锚点库”方案:
用例库的建立可以实现对以往测试规则的记录与复用,改变每次回归测试都要重复编写用例与准备数据的现状。
日志锚点库是对代码执行流程的有效验证,除了可以应用在测试环境中,还可基于大数据日志中心对生产代码的运行做日常监控。
交易与支付系统业务逻辑复杂,靠人脑和文档记忆功能关系难免疏漏,而用例库和日志锚点库会随着业务的变更测试而随即维护,是一部活文档。
1049928-e5a82c38d75e750e.png
四、Mock系统的技术方案
1、系统的功能点
1049928-245e02a287b7e298.png
说明: 上图罗列了整个Mock测试系统的功能点有哪些,共分为:配置接口数据、创建测试用例、创建测试集、创建测试计划、执行测试计划以及生成测试报告等大功能。
配置接口数据界面图
PastedGraphic-2.png
创建测试用例配置图
PastedGraphic-3.png
挡板请求路由配置图
PastedGraphic-4.png
测试执行结果
PastedGraphic-5.png
2、系统的功能流程图
1049928-0d21192efe358762.png
说明:
依据上下文环境,利用工厂类动态注入spring对远程接口的依赖,保持线上与测试的代码一致。在测试环境中,通过mock系统管理端,可以随时调整请求的流向,“指哪打哪”
1049928-6c9662846b90d4e8.png
说明:
执行某项测试用例, 利用mock将被测试接口与底层依赖接口隔离开来,可以方便的模拟数据,并监控输入输出。用例执行完毕后,使用返回断言、SQL查询、日志标记等多种手段验证。
五、感谢与后续
在整个mock测试系统的设计和开发过程中,要特别感谢我的同事刘洋洋,给与的大力支持,目前系统正在部门内推广使用中。自动测试的目的是模拟人的行为,用机器代替人工,高效而且便捷,节省人工成本并且有效的解决目前业务系统频繁升级导致的大量回归测试。
目前的系统处在1.0的版本中,后续我们会继续推出升级版本,待系统的稳定性和性能完善后我们可以开源出来,供大家使用和参考。
dubbo服务接口如何mock_小程聊微服务-基于dubbo的mock测试系统相关推荐
- 小程聊微服务--微服务思想
前言 一直对微服务非常感兴趣,因为公司的架构改造正好有机会能够接触微服务,买来一些书,请教了很多微服务大牛同时自己也做了很多总结,写成了80页ppt,算是我对微服务的一个认识吧,微服务本身不同的人有不 ...
- 小程聊微服务-数据抽取那点事(一)
一.前言 我们在<微服务是在双刃剑 http://blog.csdn.net/u013970991/article/details/73195907 >中提到了当我们将应用服务化以后,很多 ...
- 小程聊微服务-自己动手扩展分布式调用链
一.说在前面 微服务是当下最火的词语,现在很多公司都在推广微服务,当服务越来越多的时候,我们是否会纠结以下几个问题: 面对一笔超时的订单,究竟是哪一步处理时间超长呢? 数据由于并发莫名篡改,到底都谁有 ...
- 跟着小程学微服务-Mock自动化系统的原理及实现
一.前言 在之前的文章 http://blog.csdn.net/u013970991/article/details/54862772 中已经介绍了"自动化Mock系统0.9版本" ...
- 放弃Dubbo,选择最流行的Spring Cloud微服务架构实践与经验总结
Spring Cloud 在国内中小型公司能用起来吗?从 2016 年初一直到现在,我们在这条路上已经走了一年多. 在使用 Spring Cloud 之前,我们对微服务实践是没有太多的体会和经验的.从 ...
- dubbo协议_阿里P8架构师谈微服务架构:Dubbo+Docker+SpringBoot+Cloud
微服务架构 什么是微服务架构呢?简单说就是将一个完整的应用(单体应用) 按照一定的拆分规则(后文讲述)拆分成多个不同的服务,每个服务都能独立地进行开发.部署.扩展.服务于服务之间通过注入RESTful ...
- 传统行业是否使用微服务的讨论——不够痛就别微服务
一.微服务落地是一个复杂问题,牵扯到IT架构,应用架构,组织架构多个方面 在多家传统行业的企业走访和落地了微服务之后,发现落地微服务是一个非常复杂的问题,甚至都不完全是技术问题. 当时想微服务既然是改 ...
- 一篇文章带你快速理解微服务架构,由浅入深带你走进微服务架构的核心
戳蓝字"CSDN云计算"关注我们哦! 文章来自:Java和Android架构 什么是微服务 首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应 ...
- 关于微服务,这些你都了解吗-微服务介绍
文章目录 一 认识微服务 1.1 什么是微服务 1.2 微服务的特点 1.3 微服务诞生背景 1.4 微服务架构的优势 二 微服务生态 1.1 硬件层 1.2 通信层 1.3 应用平台层 1.4 微服 ...
最新文章
- 表示“总结”、“断定”“概括”、“归纳”的词语
- Kubernetes使用Jenkins服务器存储所有的kube.config文件
- php Heredoc应用说明
- 小程序的防盗链 VS 反盗链 - 总结篇
- 最近自学 Asp.net MVC 小总结
- python3指定目录所有excel_如何用python遍历文件夹下的所有excel文件
- acegis连接使用方法_铝型材配件间隔连接块的分类与使用方法
- C++教程:C++开发的四重境界是什么?
- python手写计算器
- CSDN版主考核方案
- Liferay门户应用前景分析
- 安卓刷java_安卓逆向刷题(攻防世界)
- Win10怎么设置不进入屏保也不关闭显示器
- RabbitMQ入门学习笔记
- ARM公版架构迭代迅速 国产ARM架构落伍
- 【致敬世界杯】球迷(我)和足球的故事
- Nginx 基本理论和安装
- android多线程讲解与实例
- linux造字程序,巧借“系统工具”,完成仓颉造字
- “Why Should I Trust you ?”Explaining the Predictions of Any Classififier.-对分类预测进行解释