7年经验之谈 —— 浅谈web性能测试

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

什么是性能测试？

web性能应该注意些什么？

性能测试，简而言之就是模仿用户对一个系统进行大批量的操作，得出系统各项性能指标和性能瓶颈，并从中发现存在的问题，通过多方协助调优的过程。而web端的性能测试应该注意的指标有：用户操作的响应时间、系统的吞吐量（TPS）、系统的硬件资源情况（CPU、硬盘、磁盘）、网络资源占用情况等

web性能测试之HTTP请求

关于性能测试中，HTTP请求类的性能指标都需要我们去关注些什么？

响应时间，这里的响应时间一定得是前端+后端的响应时间，我们惯性的思维都是只关注后端服务的响应时间，其实前端的响应时间也是须考虑在内的。

并发测试的相应数据，这部分也得考虑前端数据，这只是一个大概的补充，因为具体的系统需要的数据不一样，其中也不乏包括响应时间。

其中，前端的响应时间都涉及到哪些环节呢？

DNS解析

各种请求的连接

TLS的建立

字节流的发送

另外，后端响应时间涉及的环节：

等待（前端请求）

接收信息流

返回响应数据

这其实就是一个比较完整的web端请求所需要的环节，而**响应时间就是指的这个请求的过程所花费的时间。**这部分时间就是一个用户在操作的时候所等待的时间，所以用户所能接受的时间范围恰好是性能测试所关注的时间范围。通常用户所能接受的系统响应时间是3-5s，若大于这个时间节点，将会使用户失去耐心，取消对系统的操作。

web性能测试之Jmeter

Jmeter属于一个非常实用的测试工具，在性能测试当中也占有一个非常重要的位置。通常jmeter在性能测试过程中，涉及到的基本是直接对接的后端服务，针对前端的响应基本不会涉及，所以用jmeter来对一个web系统进行性能测试时，很难去捕获到前端的响应数据。但是后端响应数据获取起来非常的便捷，其中就包括：并发数、平均响应时间、错误率、吞吐量等等，如下图：

那么，关于前端的响应数据，我们该用什么方法去获取呢？接下来讲的一种方法，就是利用LR来进行。

web性能测试之Loadrunner

Loadrunner则是属于企业软件，这就奠定了它功能繁多，用途广泛的基础。LR算是一个大型的性能测试工具了，但是平常使用也还是其基本的一些功能。LR在用户界面交互上进行了注重，也就是我们之前提到的前端的响应数据，利用LR能够弥补jmeter无法涉及到的前端响应时间这部分，通过更接近用户对界面的交互，得出前端发起请求到请求发送到后台服务这个过程的响应时间。所以，这前后端两部分的响应时间之和，就是我们基本能够判定一个系统真正响应时间的依据。

web性能测试之响应时间

结合以上提及到的响应时间，它所涉及到的有两个部分，一是前端，二是后端：

关于整体系统压测策略

那提及到系统压测的策略，其实是想提一下怎样去利用单节点和集群这两种方案。通常的压测，都是采用的单节点来进行的，这样“以小见大”的方法不为一个不可采取的方法，但是这其中还是会造成很多的误差。还有就是，单节点的压测容易压低整个系统的性能指标，因为无法充分的利用系统资源

而集群压测，在环境部署上是一个复杂点，但是能够充分利用系统已有资源，这样得出的数据能够更加真实有效。在有过量的时间时，可以讲单节点和集群的压测数据进行对比，这样就能发现其中存在的差异。

关于性能测试日志

关于性能测试日志

性能测试中，日志是非常能够反应出测试工作中问题所在的一个环节，通过查看日志来定位问题是一个繁杂但是极为可靠的方式。

此类测试中，都会涉及到哪些日志呢？

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

opics/618631832)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！