既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
接口测试是在真实运行的服务中测试,若想自动化生成用例,理想的情况下,便是要自动化生成真实数据的接口测试用例,那么首先需要的就是真实的接口数据,数据从何而来呢?自然而然的,我们便会想到到线上去录制(无论是测试环境或者正式环境的)。
下面为「通用流程」讲述如何为服务接入goreplay流量录制流程。
2.2 「通用流程」服务流量录制
2.2.1 「通用流程」上传pb文件至协议中台用于解析二进制流量
首先我们需要一个能够管理协议的系统,它能够对协议文件(如pb文件等)进行管理,这样当协议有更新时,依然能够对新的协议生成的流量进行解析。
能够将goreplay录制的二进制数据进行解析:
只需要将依赖的proto文件进行打包(注意依赖多个proto文件时保持相对目录正确)并上传到协议中台即可,并且生成对应此版本pb的版本号,用于我们后续生成goreplay命令。
2.2.2 「通用流程」生成并执行goReplay命令
在上述协议中台获取了版本号之后,我们已知后台服务的ip和端口,已经最新的协议版本。将这些填入我们的goreplay命令中,如下图所示:
将上述命令在对应的容器中执行。
部分参数说明:
--input-raw-logreplay// 这个其实是rawInput插件的参数, 开启这个参数后, 必须ip和port都要填
--output-logreplay-cache-size 200// LogReplayOutPut插件 需要的缓存大小, 可以不设置, 有默认值
--output-logreplay-track-response// 跟--input-raw-track-response含义一样
--input-raw-protocol // 必填需要解析的协议
--output-logreplay-protocol-service-name "app.server" // 协议文件对的服务名
--output-logreplay-commitid "1.0.1" // 必填,如果是http协议, 可以自定义
--output-logreplay-qps-limit 100// 限制录制的qps, 非必填, 有默认值
--output-logreplay-env formal // 选填,默认formal,需要注册到logreplay测试环境可填test
在容器中执行ps -ef|grep goreplay
看到如图进程便表示成功了:
2.2.3「通用流程」查看录制流量
当服务在对应环境有流量的话,很快我们就可以查看到通过goreplay录制到并解析成功的流量了。
里面的request和respond等数据都一目了然(此处是demo所以数据很少,真实环境中,可能有非常多的参数及数据),根据这些录制的数据,我们下来就可以自动生成接口测试用例了。
三、生成用例
当录制好流量后,我们会有一个筛选机制来过滤流量,不过这个操作对于用户是无感知的。对于使用方来说,接下来就能够自动化生成流量了。
3.1 px-cmdline工具简介
我们提供了px-cmdline工具,这是一个命令行工具,它可以将goreplay录制的流量,通过proto文件,自动获取相关依赖后生成符合代码规范的接口测试文件。
3.2 px-cmdline使用
使用方式也很简单,命令行格式为:
px-cmdline generate -p <proto gomod> [-f] [--env test]
常用参数介绍:
- -p 指定proto依赖路径,从go.mod中拷贝
- -f 是否强制更新,开启后,会替换掉即将生成的同名接口测试文件
- –env 指定拉取流量的环境变量,默认test环境
- –dest 指定生成的目录,默认tests文件夹
- -j 指定是否切换json文件模式。默认使用json文件独立模式;开启后,用例写入到*_test.go里
示例:
px-cmdline generate -p git.code.oa.com/xxxxprotocol/hello/world
运行后,如果未发生异常,会在当前目录下生成tests子目录,根据每个RPC接口生成独立的__test.go文件,以及一个唯一的suite_bvt_base_test.go用于启动接口测试。testdata目录存放json格式的用例数据。如图:
当服务有多个运行节点的时候,还支持选择运行节点,以便用于本地调试接口用例时请求该目标。建议优先选择test环境或者开发者的特性环境
[Info] 请选择本地测试目标服务:可只选择环境,或指定节点
[Info] (1) 测试环境 test --------
[Info] (└ 11 ) 9.2.3.4:16916, Development, 权重100, 健康
[Info] (2) 特性环境 sdfdfe --------
[Info] (└ 21 ) 11.1.2.3:11389, Development, 权重100, 健康
[Info] (3) 特性环境 dfadfb --------
[Info] (└ 31 ) 9.3.4.5:11042, Development, 权重100, 健康
[Info] (4) 特性环境 c9d193e8 --------
[Info] (└ 41 ) 11.3.4.5:11222, Development, 权重100, 健康
为了符合代码规范,用例数据目前以json数据的形式进行存储,展示其中一条数据如下:
{
"request": "{\"pp\":[\"1dfa\"]}",
"response": "{\"sdf\":{\"TPDKH\":{\"basic\":{},\"cosume\":{},\"data\":{\"type\":\"NotSettle\",\"pll\":[733],\"tpl\":\"UG\"}",
"trace_id": "394729374872934"
},
如此一来就成功生成了接口测试用例了,当我们本地调试OK后,就可以将其mr进代码主干,在日常流水线运行时都能对接口进行自动化测试。
当然了,如果有同学喜欢用更直观的IDE工具,我们也提供了IDE插件供大家使用。
3.3 px-cmdline 工具(IDE版) Jetbrains 插件使用
如果用户希望通过IDE插件,可以通过如下操作
第一步:我们有相关的插件供安装
弹出窗里面选择刚才下载的ZIP包,然后确定;
第二步:安装完成后重启IDE,启用插件通过插件简单右键选择来生成接口测试文件可以达到与命令行工具同样的效果:
img
然后便可以顺利生成接口和用例在特定的文件夹中,用于接口测试执行。
四、流量频次筛选策略
本章节补充说明,当我们数据量较大的时候,如何进行筛选与分析,保留下相对有价值的流量用于生成接口测试用例的。
4.1 流量筛选背景
本章节内容讲述我们的流量筛选策略,这部分内容对于使用用户是无感知的,但是有助于对我们工具的完整链路有更好的理解。
当我们为服务接入goreplay后,在服务上有成千上万的流量录制进来,有时候甚至更多,那么怎么知道哪些流量是重复的,哪些流量值得记录下来用于生成用例呢?
由于正式线上环境流量较大,可能存在很多流量数据的重复率和相似度较高的情况,对此,我们不会简单的将所有流量都直接存储到数据后用于后续生成接口测试(毕竟我们也不可能用成千上万个接口用例来测试一条数据),而是会通过一定的策略进行频次筛选,符合我们相似度区分要求的流量我们才会存储到我们的数据库中。
这样做的好处有:
- 防止某些服务流量过大,存储数据过大。
- 剔除重复流量,对于相似度高的流量不重复存储,同时保证了接口测试的数据多样化。
4.2 相似度对比简述
4.2.1 相似度比较总体流程
如下图,例子中有两个流量的response,我们是如何对response或者request的数据进行相似度计算的呢,大致流程为:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!