性能测试工具--jmeter（一)

给服务器发送压力的测试工具
基于java语言开发的测试工具

1.为什么用jmeter?

①优缺点

优点
1)开源
2）可以进行二次开发，对功能进行扩展
3）免费
4）多系统兼容，基于java开发的，进行跨平台
5)轻量
6)易用，通过就metergui界面可以快速创建出需要的脚本
6)插件丰富
7)功能强大（接口功能测试、接口自动化测试、接口性能测试就是压测接口）
8）功能强大还体现在代理功能，jmeter可以实现录制抓包(了解即可）
缺点
1）性能限制，①线程数量限制，jmeter使用java编写，而java处理大量线程时可能会遇到性能瓶颈，默认情况，jmeter可能无法搞笑处理数千个线程。导致测试结果不准确或者测试过程崩溃。②资源消耗，运行大量线程时，jmete会占用大量的内存和cpu资源，可能导致测试环境性能下降。
2）图形界面的局限性，复杂场景处理困难，虽然Jmeter的Gui界面直观，但在处理复杂的测试逻辑（如动态参数化、条件判断）时，可能需要编写大量代码或使用插件，增加了 学习和维护成本。脚本不够直观，基于xml，对于复杂的逻辑可能不够直观，维护起来比较困难。
3)分布式测试复杂：虽然支持分布式测试，但设置和管理多个节点比较复杂，容易出现同步问题或通信延迟。
4）协议支持有限，jmeter对非http协议，如websocket的支持有限，可能需要插件或者自定义代码，增加了复杂性。
5）高并发测试的挑战：性能瓶颈，在处理高并发测试时，jmeter可能会遇到性能瓶颈，导致测试结果不准确。

②是否可以从前端页面进行压测

从前端页面进行压测是可以获取到html资源，是看不到前端页面的渲染。

演示：

第一步：添加线程组、添加取样器中的http请求,添加监听器查看结果树
请求百度

第二步：设置一下，获取前端资源，并行下载也勾选一下

第三步：运行，再点响应数据，获取到html

有好几个子请求，html中有图片和css，请求1中是css，请求2是图片

结论

通过上面例子可以得出，因为真正想要展示出百度页面那种效果，是需要进行页面渲染，而上面演示只是将百度页面数据获取到而已。即结论就是：如果是从前端压测，页面渲染的时间，不包括在响应时间中。
即就是jmeter主要用来测服务端性能，即接口性能。

、

③前端性能在什么情况下会对服务器有压力？

前端性能和服务端性能分开测，这样才能更方便分析定位问题。

性能一般都是服务端性能。前端性能，只是在从服务器拉起静态资源时会对服务器产生压力，检测到前端资源都不一致了，加载本地的，看一下本地资源的渲染的情况。前端性能，只是在从服务器拉起静态资源时会存在并发，这些静态资源一般不会放在自己公司的服务器上，一般都是放在cdn上。这样拉起静态资源，产生的压力不会对公司内部搭建的服务器造成影响，有的公司的静态资源是放在阿里云的cdn上。如果静态资源是放在阿里云的cdn上，基本上不会出现拉取静态资源造成性能问题，若静态资源、并发量很大，会不会跟带宽造成影响，一般来说都是按流量收费，带宽是足够。

2.其他性能测试工具：

①apacheAB：不接收服务器返回的数据，用命令进行，只关注httpcote。httpcode是200，服务器只是给了你正确的响应，并不代表业务正确，错误的用户名和密码登录，httpcode也是200，，不接收服务器返回的数据，只关注httpcote，测出来的数据会比jmeter高很多。压测时是在接口层模拟用户真实的操作，是需要接收服务器返回的真实数据，jmeter是需要接收服务器返回数据，接收返回数据后判断是否正确，返回的code是否正确、业务字段是否正确，即apacheAB的测试数据的参考性意义不大。不接收返回器的真实数据，没有参考价值。
②loadrunner
③locust：基于python
④gatling

java项目建议用Jmeter

3.官网:https://jmeter.apache.org

1）要求是需要安装jdk8以上的环境

2）各个组件相关

4、安装及配置

5、目录结构：

5.1、启动：

window上启动jmeter是jmeter.bat
linux上启动jmeter是jmeter.sh

启动后会有cmd的黑框
不要使用gui进行压测，仅用于创建和调试脚本才用这个gui界面
若要进行压测试，使用非gui模,使用脚本:jmeter -n -t 脚本 -l -o 输出的路径（html报告路径）,实际压测都是用这种方式
-n是以非gui模式运营jmeter
-t指定要运行的jmeter测试计划文件的路径。
-l 是指定日志文件的路径，用于记录测试过程中的日志信息。
-o指定输出结果的目录，用于保存测试结果和生成的html报告。

5.2、jmeter.properties（源的配置）

要看一些jmeter的配置的话可以到这个文件中jmeter.properties看
配置文件一旦修改，需要重启jmeter

5.3、bin

jmeter的jar包，启动脚本，配置文件和日志文件等

5.4、docs

jmeter的官方API文档,主要于二次开发

5.5、lib

该目录发生变更，jmeter必须重启才有效
lib/ext目录，存放的是第三方的组件和插件，包括二次扩展

5.6、extras

存放一些附件组件，主要是用于jmeter和ant的集成所需要的一下文件

5.7、printable_docs

存放的是jmeter的帮助文档，就是官网内容

6、jmeter的六大组件：

配置元件、定时器、前置处理器、后置处理器、断言、监听器（都可以添加到测试计划、线程组、逻辑控制器、取样器）

6.1组件的作用

1)配置元件

类似于项目的配置文件，初始化变量

主要：
①CSV 数据文件设置(参数化用到）
②计数器（做参数化要用到）
③HTTP信息头管理器（头信息里发送请求的类型content_type、前后端分离模式中传的是json，在信息头里指定）
④HTTP Cookie管理器
⑤HTTP请求默认值（有很多http取样器，ip一样，可以把它取出来，放到默认值里）
⑥JDBC Connection Configuration

2）前置处理器(Pre Processors)

在取样器请求之前执行一些操作。

测接口时：比如某个参数（密码用MD5）加密,发请求之前，将对应的参数（密码）进行加密，就用BeanShell 预处理程序。

3)定时器(Timer)

延缓发送请求的频率，把请求发送的频率降低，服务器也能进行处理，只是后面测试出来的tps不同，又是另外一回事,一般用来指定请求发送的延时策略，不建议使用。若服务器性能好，批量数据也能进行处理，jmeter的线程数是没有参考意义,不是说需要500并发，线程数就设置500，tps就500

若真的只关注并发数500，也是可以通过定时器进行延缓他的发送请求。
主要:固定定时器,同步定时器（集合点），秒杀和抢购场景使用。

4）后置处理器(Post Processors)

在取样器请求完成后执行一些操作，通常用于处理响应数据，从中提取需要的值。

比如A请求要作为b请求的入参，就需要用到关联，不管是正则还是jsonpath将数据提取到。

主要：

①正则表达式提取器
②调试后置处理程序
③jp@gc - JSON/YAML Path Extractor（返回的数据是json用)
④BeanShell 后置处理程序

5）断言

主要用于判断请求的结果是不是期望的业务结果。
http是200，业务不一定正确
判断业务是否正确，通过断言中的业务code+关键字段

主要：

响应断言、断言持续时间、BeanShell断言。

6) 监听器(Listener)

监听器可以在 JMeter 执行测试的过程中搜集相关的数据，并展示。

主要：

jp@gc - Transactions per Second
jp@gc - Response Times Over Time
jp@gc - Active Threads Over Time.

监听器主要用来调试脚本，压测时需要将其禁用。
怎么监听jmeter的结果，比如tps和响应时间，用jmeter的可视化监控

7、jmeter的其他组件：

7.1、测试计划(Test Plan):性能测试被测的项目

7.2、线程

下面有线程组

①线程组怎么理解？

添加多个线程组

这里的线程组理解为性能测试不同的场景（单场景、混合场景、稳定性场景）,每一个线程组代表一个单场景,线程组名字都可以进行改,比例可以有多个，混合场景可能有多个

主要：

①线程组(重要）
②jp@gc - Stepping Thread Group（重要）
③ setUp线程组
④ tearDown线程组）
⑤ 性能测试不同的场景（单场景、混合场景、稳定性场景）

3）逻辑控制器(Logic Controller)（重要）

吞吐量控制器，通过它来控制业务比例
主要：

①事务控制器
②吞吐量控制器（控制业务模型）
③仅一次控制器
④ForEach控制器
只能添加到线程组下。

4）取样器(sampler)

① HTTP请求（90%以上都是http协议）
②jp@gc - Dummy Sampler
③调试取样器（调式用到）
④ BeanShell 取样器
⑤JDBC Request
⑥其他( java、tcp、websocket)

8、组件执行顺序：

8.1、各个组件是一个时：

①顺序

运行，需要加载配置，配置元件先执行。
　1）配置元件　　
　2）前置处理器　　
　3）定时器　　
　4）取样器　　
　5）后置处理器
　6）断言　　
　7）监听器

②验证

**第一步：BeanShell 断言，就不需要发请求了，直接设置结果。
log.info打印内容，测试一下失败的信息
第二步：添加后置处理器，就用BeanShell

第三步：添加取样器就选beanshell

第四步：添加前置处理器beanshell

第五步：添加直接来一个固定定时器，为了效果更明显，设置10s

第六步：添加配置元件，常用的是csv

第七步：运行，看效果。**

执行顺序，可以先看日志，打印顺序看到
先执行的配置文件，打印bs前置时，停顿一下，等10s，表示定时器在取样器之前执行，定时器会延缓取样器器的发送频率，每次执行取样器时都先等10秒，取样器后是断言

还需要确定断言和监听器的顺序
后置和断言的顺序,加休眠，5000ms，即是5s

每一次都是后置后才断言

上面验证了执行的顺序

8.2、各个组件是两个：

8.3、关于前置后置的建议

不管是前置还是后置，需要放在对应的取样器下面，这个正则表达式是要提取http请求，就需要放在它的下面，否则就会出现问题

演示（此处需要涉及到foreach）

应用场景：把参数取到后循环的给后面请求用，就需要用到逻辑控制器foreach

第一步:添加后置处理器正则（需要提取东西））
有多个name，将name提取出来

第二步：再加一个调式取样器，再运行，看一下调式取样器是否能获取到
总共获取17个

第三步：添加foreach
结束循环字段，循环多少个，从1-17，将17个都获取到

第四步：再加一个取样器
为了方便看，名称这里显示变量，就直接可以在查看结果树看到

获取到17个值

9、作用域：

1）取样器（sampler）

不和其它元件相互作用，因此不存在作用域的问题

2)逻辑控制器（LogicController）

只对其子节点中的取样器和逻辑控制器作用

3)6大组件

可以在测试计划、线程组、事务控制器、取样器下添加
总结：如果是某个sampler 的子节点（放在取样器下面），则该元件对其父子节点起作用（这个父节点就是取样器）
如果其父节点不是sampler（比如是：测试计划、线程组、逻辑控制器、取样器），则其作用域是该元件父节点下的其他所有后代节点（包括子节点，子节点的子节点等）
和java变量作用域类似：局部没有，就用全局的
全部放局部，但是会耗费很多客户端资源
公共的：放全局，比如断言的内容相同
特有的：放局部，就是放对应的组件（线程组）或者取样器下面，比如取样器的断言内容不一样