先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注软件测试)
正文
3.根据接口的返回值,断言其是否返回期望结果,并查看数据库验证;
4.测试用例涉及多个步骤的,应对涉及的步骤都验证;
5.删除测试过程中产生的结果,确保每个用例执行前都是一个清洁的环境。
7.接口测试用例模板
8.接口数据准备
9.接口测试工具
接口测试工具选择
接口工具:Postman/Jmeter/SouapUI/python,单个接口测试时使用 Postman,多个接口测试时可以使用Jmeter,或者使用python脚本;
Jmeter:可以测试各种类型的接口,不支持的也可以通过网上或自己编写的插件进行扩展。
postman:功能上更简单,组织方式也更轻量级,它主要针对的就是单个的 HTTP 请求。
接口测试工具根据对比
抓包工具
个人比较喜欢Charles嘛,但是也可以使用fiddler或者其他的抓包工具。
jmeter使用dome
10.接口测试原则
基础配置,如域名、环境配置等,单出文件配置,方便不同环境测试、脚本维护;
明确接口实现什么样的功能,实际需要什么样的功能,是否一致;
接口测试数据太多,用该数据驱动模式更有层次,且易于维护;
要在众多测试用例中选出冒烟测试用例及可用于性能测试的用例;
先单接口测试,再多接口业务测试;
测试完成以后,需要清洗脏数据。
11.接口测试执行实例
11.1 使用Jmeter测试接口实例
接口测试环境准备
Jdk1.8 或以上:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Jmeter 下载址址:http://jmeter.apache.org/download_jmeter.cgi
插件的下载安装地址:http://www.jmeter-plugins.org/
12. 如何快速生产脚本生成
既然使用到了jmeter团队又是多人的情况下,那么 jmeter 脚本的生产力是一个很大的问题,再加上团队不是每个人对 jmeter 的熟悉程度都是不一样的,所以脚本的编写和快速生产就是个问题,针对这个个人建议脚本的生产建议从以下几个方面考虑;
使用jemter原生的录制器;
手写jmeter脚本,但是需要对jmeter相对熟悉;
使用fiddles抓包工具导出生产;
针对web页面个人推荐BlazeMeter的谷歌插件。
针对以上五种生产jmeter脚本快速生产的方案,都可以很好的辅助编写jmeter 的脚本,在这里很多同学肯定会问为什么不使用metersphere,这个项目本身很优秀了,但是由于公司的原因,所以最后放弃,很多同学肯定想,录制生成,直接回访就完事,我只能说太简单,这样你的脚本使用一次基本就报废, 会造成脚本的重复编写费时费力,这个时候,需要测试强硬一点了大家采用统一的录制控制方式去录制,同意脚本编写的方案,毕竟在怎么录制都是不行的,所以最好的实践方式就是采用录制为主,修改为辅的解决方式,去编写复用率高的脚本。
13.团队协作落地
相信jmeter很多测试小伙伴都很熟悉,肯定也都熟悉他有一个最大通病,就是case太多的时候,一点都不方便管理。
其实这个问题,我也遇见了,因为现在的团队不只是我一个人单打独斗,我还有队友,所以对jmx脚本的管理,我在团队里面采用的是git管理我们的脚本,我们在团队内部和开发约束,测试环境的时候,所有的部署都走test的一个代码分支,这样做的好处,就是为了减轻jmx脚本的复杂性,同时也避免了在发布生产环境的时候,将脚本发布到生产环境,因为最初的初衷使用jmeter做接口测试的情况下,就是因为团队开发的同学不写单元测试,测试同学会Java的只有一两个,服务又多,公司的迭代速度又快,开发提测的功能一直没有很好的健壮性,所以,我在想能不能在开发部署成功的时候或者定时轮询执行一下每个服务的接口,以达到提测的质量。
在团队实践中也遇到了一些问题如下:
token的时效性原因,导致脚本老是执行失败;
数据的唯一性,例如我每次请求的时间都是不一样的等;
数据库的连接数老是超标,因为团队存在多个项目组,他们之间又是使用相同的数据库,只是不同表;
Jenkins的并发限制,因为大家都是使用同一个Jenkins,不可能你一个老是占用Jenkins的执行。
针对以上的问题,我个人是如下解决的,首先token校验的问题,存在这个问题的根本原因,是因为我们每次登录都是图片验证码的登录,但是我又不能识别,只能求助开发经理,让他在测试环境给我们测试写了一个万能验证码,再拿这个这个验证码去刷新token和或获取对应的op(op参数是内部特有的验证)
数据的唯一性,这个当时头疼了好久,最后只能去百度,最后发现jmeter还有很强大的功能,就是函数助手,里面有各种函数,例如获取时间戳,随机数,生成uuid等,直接开箱即用。
熟悉mysql的小伙伴都知道MySQL的默认最大连接数是200数据库连接池老是超标,最后查看了mysql日志发现连接数占用最大的是开发的代码里面写了很多多表联查的大SQL,尤其是公司大数据那帮人的sql一个SQL语句执行半个小时…因为去年(2020年)MTSC深圳站的时候,听了唯品会的同学分享接触到了,sql扫描检查,当时在sonar扫描代码的时候,加入了sql的扫描,和开发老大商量,去除了项目中大部分的长sql语句,最后去请教了运维的同学和公司dba的大佬,当时运维同学有点不配合的,最后买了一包好烟,在加各种舔,最终终于同意扩大数据库的连接数,最终勉强解决了这个问题。
jenkins并发机制的问题,这个是jenkisn本身就存在的瓶颈,当时给公司运维提了个需求,让他多起几个jenlkins的的节点,测试专门使用一个节点。
14.接口测试结果报告
由于使用了jmeter为了测试的时候,可以实时查看,个人建议使用 influxdb+cadvisor+grafana 搭建一套配合 jmeter 的报告可视化的监控系统。
搭建步骤如下
创建容器挂载目录
mkdir -p /dockerdata/influxdb
mkdir -p /dockerdata/grafana
安装 influxdb 数据库
docker run -d
-p 8083:8083
-p 8086:8086
–expose 8090
–expose 8099
–name influxsrv
-v $PWD:/var/lib/influxdb
influxdb;
安装 cadvisor 容器监控
docker run
–volume=/:/rootfs:ro
–volume=/var/run:/var/run:rw
–volume=/sys:/sys:ro
–volume=/var/lib/docker/:/var/lib/docker:ro
-p 8081:8080
–detach=true --link influxsrv:influxsrv
–name=cadvisor
google/cadvisor:latest
-storage_driver=influxdb
-storage_driver_db=cadvisor
-storage_driver_host=influxsrv:8086;
安装 grafana
docker run
-d
-p 3000:3000
-e INFLUXDB_HOST=localhost
-e INFLUXDB_PORT=8086
-e INFLUXDB_NAME=cadvisor
-e INFLUXDB_USER=root
-e INFLUXDB_PASS=root
–link influxsrv:influxsrv
-v $PWD:/var/lib/grafana
–name grafana
grafana/grafana;
最终结果如下
需要注意的点
既然使用influxdb存储jmeter的数据,那么就不得不提jmeter的Backend Listener后端控制器,的配置,这个超简单,但是我没有使用默认的,因为默认的只能查看 压测的tps这些,再加上脚本的每个场景接口我加入事务控制器,所以我采集的是事务控制器,一个事务代表一个接口或者代表多个接口;
启动了influxdb之后需要进入容器创建对应的数据库,要不数据没办法存储;
为了方便在grafana上面看到了每个接口的请求参数和返回值,这个是因为之前公司每个项目已经接入普罗米修斯的监控,在配置普罗米修斯监控的时候,我们加入了自定义监控,所以这款我直接使用普罗米修斯原有的配置的面板;
还有因为插件的原因当时遇见了influxdb里面没办法失败 “/” 所以控制器的命令 “/” 可以使用下划线代替。
13.接口测试中常见问题
接口测试经常遇到如下的bug和问题:
传入参数处理不当,导致程序 crash;
类型溢出,导致数据读出和写入不一致;
因对象权限为进行校验,可以访问其他用户敏感信息;
状态处理不当,导致逻辑出现错乱;
逻辑校验不完善,可利用漏洞获取非正当利益等。
15.接口自动化适用场景及持续集成
接口自动化框架:Jmeter+maven+Jenkins+git
Jmeter作为执行者的角色,每次负责执行具体的接口/性能测试脚本,并得到结果,生成报表。
Maven和Git是作为管理者角色,前者主要负责项目的依赖管理,而后者主要负责项目的代码管理。
Jenkins作为调度者,主要根据我们设置的build触发条件和事件调用jmeter进行测试 ## maven集成jmeter插件。
org.apache.jmeter ApacheJMeter_components 5.4.1jmeter 镜像的制作
因为在上面我们说了我们使用了自己的Backend Listener插件,由于网络原因,所以在运行docker容器的时候,我们需要将jmeter容器使用-v参数挂在到本地。
再加上网络的原因,我们只能自己制作镜像了,制作镜像的dockerfile如下:
FROM java:8
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
参数挂在到本地。
再加上网络的原因,我们只能自己制作镜像了,制作镜像的dockerfile如下:
FROM java:8
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
[外链图片转存中…(img-xHCs2EJV-1713450606390)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!