JMeter能做那些性能测试？

Posted 2023-04-18

参考技术A     Apache JMeter™是Apache组织开发的一款开源软件，它是 功能和性能测试 的工具，是典型的 纯Java开发 的应用程序，可以在不同平台比如Windows、Linux或macOS系统上进行软件测试。

1、基准测试：

即单用户测试，测试环境确定以后，对 业务模型 中的 重要业务 做单独的测试，获取 单用户运行时的各项性能指标 ，为多用户并发测试和综合场景测试等性能分析 提供参考依据。

[个人理解：分别模拟单用户使用某个重要业务场景； 业务即功能 ，如何去实现它，是业务逻辑的实现；例如登录业务，登录的过程是业务逻辑的实现；添加、修改、删除定时任务都是业务]

我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以；如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些。 详细分析

2、并发测试

主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如 内存泄漏、线程锁、资源争用问题 ，几乎所有的性能测试都会涉及并发测试。

是多用户执行某一操作，形成瞬时压力（精确到毫秒），是一种严格的测试，主要考察系统对瞬时较大压力的承受能力。

注： 同步定时器 实现并发

3、负载测试

模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察 不同负载下 系统的 响应时间 和 数据吞吐量 、 系统占用的资源（如CPU、内存 ）等，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。

4、压力测试

又称为强度测试：是在强负载（ 大数据量、大量并发用户 等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。

压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

一直重复长时间给系统极限压力，看系统是否能承受

 压力测试时，系统内存溢出解决方案：

修改 apache-jmeter-2.11\bin\jmeter.bat 

5、稳定性测试：

主要测试 持续一段时间 访问接口，测试接口的稳定性。

主要涉及的配置为：

1）线程组设置循环次数永久，持续时间设置为15分钟（根据自己的项目要求而定）

2）必要的时候，添加统一随机定时器元件

主要有两个参数：

随机的最大时间（ms）：在这个范围内进行随机

常量延时时间（ms）：固定的延时时间

最后的延时时间=随机的时间+常量延时时间

6、业务场景测试：

主要测试多个接口联动，模拟真实接口的调用，增加统一随机定时器模拟用户真实操作

比如添加购物的流程涉及到：登录接口–搜索商品接口–浏览商品接口–添加到购物车接口

其中主要最难的是：登录接口提交的验证码处理，我之前的项目是开发给定了一个固定的万能验证，进行提交登录，添加HTTP Cookie管理器（用于自动保存登录之后的信息，下面的请求就可以使用同一个登录状态进行访问：https://blog.csdn.net/baidu_39372836/article/details/91442231）。

使用事务控制器元件（https://blog.csdn.net/baidu_39372836/article/details/99445618）进行管理这些接口，这些接口就属于一个事务流程，只要一个测试失败，则事务通过失败。

一般情况下JMeter元素按照如下顺序依次执行：

一个简单的例子：

其中①为取样器、②为配置元件、③为定时器、④为监听器、⑤为前置处理器、⑥为后置处理器、⑦为断言。

执行顺序为：②-->③-->⑤-->①-->⑥-->⑦-->④

参考资料：

https://blog.csdn.net/baidu_39372836/article/details/101194892

Fine原创JMeter分布式测试中踩过的那些坑

最近因为项目需要，研究了性能测试的相关内容，并且最终选用了jmeter这一轻量级开源工具。因为一直使用jmeter的GUI模式进行脚本设计，到测试执行阶段工具本身对资源的过量消耗给性能测试带来了瓶颈，一般线程加到100左右就会出现工具本身无法支撑的问题，广泛了解解决办法后，发现分布式部署测试机仍是首选方案。

 

关于如何配置jmeter分布式部署测试机很多博客上已经描述得很详细了，这里就不再赘述，可以参考虫师的博客：

http://www.cnblogs.com/fnng/archive/2012/12/29/2839420.html

 

现在单纯记录一下在部署分布式测试机的过程中踩过的那些坑。

 

五星坑：远程启动测试，响应数据为空。

controller运行jmeter脚本后，GUI无性能数据返回。

 

 

 

 

agent的jmeter server显示连接后立即结束。看似执行实则响应数据为空。

 

 

 

出现以上情况原因及解决办法：

 

1、jmeter脚本和测试数据（如果有的话）主机和从机两边都要存放。且controller中jmeter脚本、测试数据的存放路径和agent中jmeter脚本、测试数据的存放路径一致。

 2、在原因1的基础上，controller的测试数据地址要用绝对路径，agent的测试数据绝对路径或相对路径均可。

 

 

解决办法：文件地址修改统一后，运行成功。（run是自己打的log）

（注意：也因为路径一致的原因，目前我也没办法把windows和mac电脑混合配置成分布式测试机，这里是清一色的windows系统）

 

 

四星坑：agent的VM或共享盘符会干扰远程连接

agent如果安装有vm或将某个盘设置了共享权限的时候，controller在配置该agent时除IP地址外，虚拟机ip或者共享盘ip也会出现在远程连接待选列表中，连接时报错。

 

 

 

解决办法：关闭或卸载虚拟机，撤销盘符共享

 

三星坑：jmeter运行时报内存溢出outfmenmory错误。

 

该问题博客上已经有很多同行给出了解决办法，比如修改jmeter.bat的预设内存大小。参考疯狂的tiger的博客吧：

http://www.cnblogs.com/yang-hao/p/5319720.html

 

 

二星坑：由于防火墙未关闭或测试controller和agent不在同一个网段会影响远程连接。

 

 

 

解决办法：关闭agent的防火墙。contrller和agent在同一网段，比如我这里就选择了同一个WIFI，配置同一个DNS等方法解决。

 

 

至此，jmeter分布式测试算是勉强进入正确轨道，将踩过的坑做个备忘。感谢团队的努力，也希望能和大家一起学习、分享、进步。