Jmeter --性能测试实施

Jmeter 在测试工作中，是一款（同postman）常用的接口测试工具，在测试工作任务中除了做简单的接口测试之外，时常也会同Loadrunner一样被选择用来做性能压力测试测试，

  	Jmeter做性能压力测试，在测试工作中，有几个层面可以来做压力， 一种是直接从业务层面，
 直接用接口来做压力，看业务功能所能承受的压力 以及 性能； 另一种直接通过页面操作录制脚本，
 整理优化脚本然后做压力测试。这两种方式都可以，工作中会灵活性的选择 
    那么我们在做压力测试的时候，我们会有那些考虑点，也是我们如何来设计自己的性能压力测试

那么我们在做压力测试的时候，我们会有那些考虑点，也是我们如何来设计自己的性能压力测试，考虑下测试环境有多少个服务器负载机，产品的使用群体的用户量预估有多少，性能指标大概在什么范围可以接受（如事物响应时间）；用户量的并发改如何设置（200、500、800、1000这样梯度试的增长），根据业务我们在设置场景的时候可以考虑适当加入一些集合点，如果在单台电脑上运行压力测试不够，可以在多台同事电脑同时运行jmeter ，同步实施压测
那么OK，压测OK后，，我们如何判断这个功能模块是否有性能问题，我们的参考点在那？

参考点：
通过jmeter 工具在压测完毕后输出的结果分析报告，如：聚合报告（Aggregate Graph） 、概要报告(Summary Report)，事物响应时间图（Response Time Graph）等；那么通过这些报告里的数据，我们能够清晰的了解到，事物响应时间的曲线图是否正常（是否会出现波动性跳跃），事物请求事物响应时间是否过长，吞吐量多少根据这些可以做一个综合性的判断
同时在压测的过程，我们还可以通过，监控服务器系统资源的使用情况，这个我们可以通过不同的命令，比如服务器是Linux系统，我们有很多命令 vmstat 、 uptime、top等,也可以用比如运维常用的系统资源监控可视化工具 grafana 或者 tomcat+probe这样的工具监控系统资源的使用情况。

结合之前讲的:
Jmeter（一）-使用http proxy代理录制脚本

https://blog.csdn.net/qq_21422005/article/details/84070584

Jmeter(二)变量参数化:

https://blog.csdn.net/qq_21422005/article/details/84070584

我们开始实际操作下，性能压力测试
1：脚本已录制完毕
2：脚本已初步整理（改删除的图片、js、css 加载请求都已删除）
3：性能压力测试，如登入模块，不希望用一个用户来做压测，所以可以做好
参数化变量（参数化变量已完毕）
有些模块功能如果需要大批量数据提供支撑，可在数据库写存储，调用存储

场景设置：
步骤1：
设置模拟用户并发数

步骤2：
参数化变量，给模拟的用户有数据循环选择

步骤3：

这个可根据需要灵活设置，可设置也可不设置 （上面设置10用户做一个集合）

步骤4：添加设置–事物响应时间图（Response Time Graph）、添加Summary Report 概要报告

步骤5：设置添加 聚合报告


场景设置基本完毕（根据需要可自己添加其他的一些设置）

1：打开自电脑的任务管理器

其实基本可以不打开，自己做性能压力测试的时候，运行的程序应该不会开很多，配置应该够用，保证工具能正常运行（所以这个基本可以略）

2：负载机，环境的服务器，性能压测的过程，监控负载机的系统资源使用情况

方法很多：
vmstat

top

还有其他命令

同时可以使用工具辅助查看

步骤6：运行性能压测

运行的过程查看下负载机的系统资源情况（某个时间点出现 内存、cup 、load使用很大的时候要做好标准分析，看是否有问题），可结合后面的jmeter运行报告一起分析

重要点，查看分析报告
1：概要报告 （Summary Report）

2：聚合报告

3：事物响应时间 （Response Time Graph）

波动性很大，事物响应时间瞬间拉高，而且前面可以看到，错误率也很大，重点分析这几个时间点的事物请求

a,结合工具反馈的负载机资源 这几个时间点的情况
b.日志信息查看，看是否有报错日志和具体情况
c.从结果树看写信息，如

看返回的错误信息

以上可以看出，性能有问题！
基本上就这样，后面就是对问题的处理，性能调优要整个部门的协同合作处理！

PS：其他知识点

数据库连接池查看：
命令：SHOW PROCESSLIST;

调优的东西还涉及很多，这里就不一 一列举

文章为做简单的个人理解和记录，不足之处，还恳请大家多多指出与指导~！！！