JMeter使用与结果分析_使用jmeter抖音系统软件测试分析测试结果

1.如何得到可靠的测试报告？

以上我们便完成了一次简单的测试案例，但我们的测试还未结束。我们需要对测试结果进行分析，但是在真实项目中上述的测试结果是不可靠的，只能用作调试。你如果细心的话，应该能在运行Jmeter的命令行里找到这句话

它这里就直接说明了不建议我们在真实测试中使用gui界面，尤其是图表形式，为什么呢？

在负载测试期间不得使用图形结果，因为它消耗了大量资源（内存和CPU）。仅用于功能测试或测试计划调试和验证期间。

大多数UI监听器非常适合调试/测试目的。不要期望达到高负荷（> = 500个用户），谨慎使用它们。这些侦听器设计用于在JMeter UI中运行负载测试时快速获取指标，以实现轻负载。（<= 50个并发用户）

即使是中等负载（100-500个并发用户）也可以使用它们，但不要期望使用JMeter UI运行分布式JMeter测试。这不是目的。记住JMeter默认配置512MB堆内存，相当低。虽然你可以增加JMeter分配的内存，但它会感觉不会再漂浮在船上了。

那么在运行实际负载测试时我们可以使用哪些监听器？

①简单数据写入器

简单数据写入器：可以将监听器配置为将不同的项目保存到结果日志文件（JTL）。

这是JMeter中最有用的监听器。它根据外部文件中的配置保存性能指标：JTL文件。JMeter JTL文件是分析结果的最佳方式，但有一个缺点：您需要另一个工具来执行数据挖掘。

一般我们采取以下两种方案

• 简单数据写入器+excel

• 简单数据写入器+HTML报告DashBoard

这里推荐使用HTML报告DashBoard，这也是官方支持的方式。后文我也会演示利用HTML报告DashBoard来生成性能测试报告。

②后端监听器

后端监听器：后端监听器是一个异步监听器，使您可以插入BackendListenerClient的自定义实现。默认情况下，提供Graphite实现。

JMeter的Backend Listener允许插入外部数据库来存储测试结果和性能指标。

因此我们可以选择InfluxDB+Grafana+JMeter的后端监听器来实现

• InfluxData：用作存储性能指标的临时指标存储的数据库

• Grafana：Grafana是一个时间序列分析的开源平台，允许您根据时间序列数据创建实时图表

• JMeter的后端监听器：后端监听器收集JMeter指标并将它们发送到临时指标存储

③其他解决方案

kylinTOP测试与监控平台（商用版）

LoadRunner（商用版）

NeoLoad（商用版）

Load impact（免费使用）

....市场上还有一些解决方案，但是大多都要收费，所以不再赘述了。

2.简单数据写入器+HTML报告DashBoard案例演示

这里我还是拿之前的测试案例来演示

①修改合适的测试规模

这里我加大测试压力，将线程数改为1000，循环30次

​现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：485187702【暗号：csdn11】

②添加简单数据写入器

新增一个简单数据写入器

修改输出路径到合适的目录下，同时保存的文件以jtl结尾

 

③运行生成文件

点击运行图标，运行完成后在对应目录下你应该能找到这个jtl文件

 

④生成HTML报表

点击工具->Generate HTML report

在result files 一栏，我们选择之前导出的jtl文件。

在用户配置文件一栏我们可以选择bin目录下有的user.properties文件，也可以根据官网用户手册去配置一个。这里我们选择bin目录下的文件即可。

输出目录我们选择一个合适的空目录即可。

 点击generate report 即可生成报告

点击index.html即可看到测试结果

 

 

3.结果分析

报告图表很多，以下几个我们需要特别注意：

①成功率

在仪表盘，我们可以清楚看到成功请求的占比，在本次测试中，成功率99.9%,这是完全可以接受的

 

②响应时间变化

 

在这里我们可以看到测试中响应时长的变化，最小值一般不值得参考，值得参考的响应时长一般是90%-99%的响应时长，我们需要保证至少90%的请求响应时长在用户可接受范围内（具体可容忍时长视具体的业务场景而变化）

在这次测试中请求时长达到了恐怖的9000ms，一般用户是没办法忍受的，所以，在1000个用户下（1000个模拟线程），系统响应没法达到用户期望。

③TPS

TPS 即 Transactions Per Second的缩写，每秒处理的事务数目。

这个是我们经常拿来当做系统性能好坏的指标之一，也是在微服务架构中最常提到的词。

 

这里我们可以看到我们测试的接口TPS大概在138左右。 

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 希望能帮助到你！【100%无套路免费领取】