先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注软件测试)
正文
另外,后端响应时间涉及的环节:
等待(前端请求)
接收信息流
返回响应数据
这其实就是一个比较完整的web端请求所需要的环节,而**响应时间就是指的这个请求的过程所花费的时间。**这部分时间就是一个用户在操作的时候所等待的时间,所以用户所能接受的时间范围恰好是性能测试所关注的时间范围。通常用户所能接受的系统响应时间是3-5s,若大于这个时间节点,将会使用户失去耐心,取消对系统的操作。
web性能测试之Jmeter
Jmeter属于一个非常实用的测试工具,在性能测试当中也占有一个非常重要的位置。通常jmeter在性能测试过程中,涉及到的基本是直接对接的后端服务,针对前端的响应基本不会涉及,所以用jmeter来对一个web系统进行性能测试时,很难去捕获到前端的响应数据。但是后端响应数据获取起来非常的便捷,其中就包括:并发数、平均响应时间、错误率、吞吐量等等,如下图:
那么,关于前端的响应数据,我们该用什么方法去获取呢?接下来讲的一种方法,就是利用LR来进行。
web性能测试之Loadrunner
Loadrunner则是属于企业软件,这就奠定了它功能繁多,用途广泛的基础。LR算是一个大型的性能测试工具了,但是平常使用也还是其基本的一些功能。LR在用户界面交互上进行了注重,也就是我们之前提到的前端的响应数据,利用LR能够弥补jmeter无法涉及到的前端响应时间这部分,通过更接近用户对界面的交互,得出前端发起请求到请求发送到后台服务这个过程的响应时间。所以,这前后端两部分的响应时间之和,就是我们基本能够判定一个系统真正响应时间的依据。
web性能测试之响应时间
结合以上提及到的响应时间,它所涉及到的有两个部分,一是前端,二是后端:
关于整体系统压测策略
那提及到系统压测的策略,其实是想提一下怎样去利用单节点和集群这两种方案。通常的压测,都是采用的单节点来进行的,这样“以小见大”的方法不为一个不可采取的方法,但是这其中还是会造成很多的误差。还有就是,单节点的压测容易压低整个系统的性能指标,因为无法充分的利用系统资源
而集群压测,在环境部署上是一个复杂点,但是能够充分利用系统已有资源,这样得出的数据能够更加真实有效。在有过量的时间时,可以讲单节点和集群的压测数据进行对比,这样就能发现其中存在的差异。
关于性能测试日志
关于性能测试日志
性能测试中,日志是非常能够反应出测试工作中问题所在的一个环节,通过查看日志来定位问题是一个繁杂但是极为可靠的方式。
此类测试中,都会涉及到哪些日志呢?
Jmeter端日志
HTTP端打到Nginx端的日志,这层会涉及到来源IP、请求地址、响应时间等。
Tomcat层日志
Server层日志
关于OS层数据监控
- CPU监控
通常的指标是CPU使用率不能超过80%,这样给系统预留一个缓冲的范围。这里提及一点,就是其中涉及到多核CPU的情况,严谨的人会去关注每核CPU的使用情况,因为很多时候多核CPU的利用并不是均衡的,整体的CPU使用情况不能反映出单核的使用情况,容易造成误导。
- JVM层监控
这主要是去监控线程,其中包含单线程、多线程,同步线程、异步线程。关于同步线程和异步线程,是一个系统中比较关注的点,假如:一个系统处理事务时,采用的是同步线程,很多事务会等待处理造成阻塞,那么这样的系统处理速度就会受到很大的限制,会被视为一个不合格的系统。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
9472917)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!