目录
八、jp@gc - Response Times Over Time
九、jp@gc - PerfMon Metrics Collector
在使用 Jmeter 进行性能效率测试时,通常主要需要添加以下组件:测试计划、线程组、Runtime 控制器、事务控制器、HTTP 请求、HTTP 信息头管理器、聚合报告、jp@gc-Response Times Over Time、jp@gc-PerfMon Metrics Collector、察看结果树。下面将详细介绍这些组件。

一、线程组
1. 概念
线程组用于控制 Jmeter 执行测试的一组虚拟用户。可以把它理解为模拟真实用户的集合,通过设置不同的参数来模拟各种用户场景。
2. 添加位置
在线程组的添加位置在测试计划下,具体操作路径为:测试计划 → 添加 → 线程组。在添加时,还可以看到多种类型的线程组可供选择,如 bzm-Arrivals Thread Group、bzm-Concurrency Thread Group 等 ,一般选择默认的线程组类型即可满足基本测试需求。

3. 参数讲解
- 线程数:即虚拟用户数量。例如,若要模拟 100 个用户并发访问,此处就填写 100。
- Ramp-Up 时间(秒):指虚拟用户启动完成的时间。假设虚拟用户数量为 100,Ramp-Up 时间设置为 10 秒,那么意味着每秒启动 10 个用户,10 秒完成全部 100 个虚拟用户的启动。
- 循环次数:一般填写 1 次,表示每个虚拟用户只运行 1 次测试场景。若勾选 “永远”,则代表虚拟用户会一直循环运行测试场景。
- 每次迭代都是同一个用户:勾选该选项时,在多次循环中始终使用相同的虚拟用户;不勾选时,每次迭代可能会切换不同的虚拟用户(具体取决于 Jmeter 的调度机制)。
- 延迟创建线程直到需要:启用该选项后,线程不会在测试开始时立即全部创建,而是在需要时才创建,这样可以减少系统资源的初始消耗。
- 调度器:包括 “持续时间(秒)” 和 “启动延迟(秒)”。“持续时间” 用于设置测试场景的运行时长;“启动延迟(秒)” 表示在测试计划启动后,延迟指定的秒数再开始创建和启动线程。

二、Runtime 控制器
1. 概念
Runtime 控制器用于控制其下测试元件的运行时间,它规定了在多长时间内执行嵌套的测试元素。
2. 添加位置
Runtime 控制器的添加位置在测试计划 → 线程组下,具体操作路径为:测试计划 → 线程组 → 添加 → 逻辑控制器 → Runtime 控制器。

3. 参数讲解
- 名称:默认为 “Runtime 控制器”,可根据测试需求进行修改,方便识别和管理。
- 注释:用于对该控制器进行说明,可填写一些关于测试场景或该控制器作用的描述信息。
- Runtime (seconds):运行时间,单位为秒。若要运行 5 分钟(300 秒),则在此处填写 300。

三、事务控制器
1. 概念
事务控制器会生成一个额外的示例,用于测量执行嵌套测试元素所花费的总时间。它就像是一个 “时间记录器”,可以帮助我们统计某个特定事务(一组相关的测试操作)完成所需的总时长。
2. 添加位置
事务控制器的添加位置在测试计划 → 线程组 → Runtime 控制器下(若有 Runtime 控制器),操作路径为:测试计划 → 线程组 → [Runtime 控制器] → 添加 → 逻辑控制器 → 事务控制器。

3. 参数讲解
- 名称:需要修改为性能效率测试项的具体名称,比如 “100 个用户并发查询 XXXXXX” ,这样便于清晰地识别该事务代表的测试场景,同时也方便在后续的测试结果分析中快速定位和查看相关数据。
- 注释:同样用于对该事务控制器进行详细说明,记录与该事务相关的重要信息。
- Generate parent sample:勾选此选项后,事务控制器会生成一个父样本,该样本包含了其下所有子样本的执行时间总和,方便从整体上查看事务的执行情况。
- Include duration of timer and pre - post processors in generated sample:若勾选,生成的样本时间将包含定时器以及前置、后置处理器的执行时间,更全面地反映事务的实际执行耗时。

四、HTTP 请求
1. 概念
HTTP 请求用于编写针对目标系统的 HTTP 请求,模拟用户在浏览器中进行的各种 HTTP 操作,如访问网页、提交表单等。
2. 添加位置
HTTP 请求的添加位置在测试计划 → 线程组下,操作路径为:测试计划 → 线程组 → 添加 → 取样器 → HTTP 请求。

3. 参数讲解
在进行 HTTP 请求配置时,首先打开浏览器的开发者工具(F12),执行需要测试的性能操作,然后在 “Headers” 中获取关键信息。主要使用的信息有 “Request URL”(请求的网址)、“Request Method”(请求方法,如 GET、POST 等)、“Remote Address”(服务器的地址和端口)。具体填写方式如下:
- 基本设置:
- 协议:一般为 http 或者 https,根据目标服务器的实际情况选择,例如百度搜索使用的是 https 协议。
- 服务器名称或 IP:填写目标服务器的域名或 IP 地址,如百度搜索的服务器名称为 “www.baidu.com”。
- 端口号:对应服务器开放的端口,https 协议默认端口通常为 443。
- 路径:即请求 URL 中除去协议、服务器名称和端口号后的部分,例如百度搜索的路径可能是 “/s?ie=UTF-8&wd=123” ,其中 “ie=UTF-8&wd=123” 是传递的参数。
- 内容编码:一般填写 utf - 8,或者根据实际情况不填写。

另外需要在payload中将添加消息体,但具体还是要看请求的情况,比如百度这里已经把相应的payload带到了URL后面,所以百度这个请求是不需要添加的。
如果 URL 中没有带相关数据,就需要根据情况添加消息体数据或者参数!
如果 URL 中没有带相关数据,就需要根据情况添加消息体数据或者参数!
如果 URL 中没有带相关数据,就需要根据情况添加消息体数据或者参数!

如果URL里面没有带的话,你可以选择添加消息体,也可以添加参数,相比之下,我个人更喜欢添加消息体,注意哦,两种方式选择其中一种就可以啦
1.添加消息体
从浏览器开发者工具在Payload里面这个数据粘贴到消息体数据内,一般需要将数据转换成 join 字符串格式。例如,获取到的参数为 “ie=UTF-8&wd=123”,则将其粘贴到消息体数据中。
点击这个,2个来回切换


2.添加参数
这里比较麻烦,因为可能需要一点一点粘贴,虽然可以直接复制后,点击从剪贴板添加,但是有时候识别还是错误的,需要再次手动进行调整,所以我比较喜欢上面这种方式


五、HTTP 信息头管理器
1. 概念
HTTP 信息头管理器用于管理 HTTP 请求中发送的信息头(Headers),通过设置这些信息头,可以模拟浏览器的请求行为,让服务器正确识别请求来源和类型等信息。
2. 位置
HTTP 信息头管理器的添加位置在测试计划 → 配置元件下,操作路径为:测试计划 → 添加 → 配置元件 → HTTP 信息头管理器。

3. 参数讲解
配置 HTTP 信息头管理器时,从浏览器开发者工具的 “Headers” 中复制 “Request Headers” 部分的内容(注意不要复制第一行)。然后在 Jmeter 的 HTTP 信息头管理器中,点击 “从剪贴板添加”,即可完成信息头的添加。例如,复制的部分信息如下:

添加完成后,在 HTTP 信息头管理器中可以看到各个信息头的名称和对应的值,也可以手动添加、删除或修改信息头内容。

六、察看结果树
1. 概念
察看结果树用于查看测试过程中每个请求的详细信息,包括请求的内容、服务器的响应数据、响应头信息等,方便检查测试脚本是否正确执行以及服务器的返回结果是否符合预期。
2. 位置
察看结果树的添加位置在测试计划 → 监听器下,操作路径为:测试计划 → 添加 → 监听器 → 察看结果树。

3. 参数讲解
在察看结果树中,可以清晰地看到每个请求的具体情况。在 “请求” 部分,可以查看编写的 http 请求内容;在 “响应数据” 部分,可以看到服务器返回的结果,常见的返回值有 200(表示请求成功)、500(服务器内部错误)、501(未实现的功能)等。如果返回值为 200,通常表示脚本编写正确,请求成功执行。
此外,还可以通过设置 “显示日志内容” 选项,选择仅查看错误日志、仅查看成功日志或全部日志;通过 “查找” 功能,按照区分大小写或正则表达式的方式搜索特定的内容。

七、聚合报告
1. 概念
聚合报告是 Jmeter 中用于汇总和展示测试结果的重要组件,它以表格形式呈现各种关键性能指标,帮助测试人员快速了解测试场景的整体性能表现。
2. 位置
聚合报告的添加位置在测试计划 → 监听器下,操作路径为:测试计划 → 添加 → 监听器 → 聚合报告

3. 参数讲解
- 样本:表示被执行的请求次数,每一个请求都被视为一个样本,通过该指标可以了解测试过程中总共发送了多少个请求。
- 平均值:指每个请求的平均响应时间,通过计算所有样本的响应时间总和并除以样本数量得到。平均响应时间是评估应用程序性能的关键指标之一,反映了系统处理请求的平均速度。
- 最小值:代表所有请求中响应时间最短的那次请求的响应时间,展示了系统在最佳情况下的响应速度。
- 最大值:表示所有请求中响应时间最长的那次请求的响应时间,体现了系统在最差情况下的响应性能。
- 错误率:指在测试期间发生错误的请求占总请求数的百分比,是评估应用程序稳定性和可靠性的重要指标。错误率越高,说明系统在处理请求过程中出现问题的可能性越大。
- 吞吐量:表示单位时间内的请求数量,通过计算总请求数量与测试运行时间的比值得到(单位通常为每秒请求数)。吞吐量越高,说明系统的处理能力越强。
- 接收 KB/sec:表示服务器每秒接收的数据量,单位是 KB / 秒。该指标用于评估网络带宽的使用情况以及服务器处理数据的能力,数值越大表示服务器接收数据的速度越快。
八、jp@gc - Response Times Over Time
1. 概念
jp@gc - Response Times Over Time 组件主要用于以折线图的形式展示事务的响应时间随时间的变化情况,让测试人员直观地观察到在整个测试过程中响应时间的波动趋势。
2. 位置
jp@gc - Response Times Over Time 的添加位置在测试计划 → 监听器下,操作路径为:测试计划 → 添加 → 监听器 → jp@gc - Response Times Over Time。

3. 参数讲解
在测试运行完成后,通过查看 jp@gc - Response Times Over Time 生成的折线图,可以清晰地看到事务响应时间的变化情况。横坐标表示时间,纵坐标表示响应时间。折线的走势可以反映出系统在不同时间点的负载情况和响应性能,例如,如果折线在某个时间段内突然上升,可能意味着在该时间段内系统负载过高,导致响应时间变长。

九、jp@gc - PerfMon Metrics Collector
1. 概念
jp@gc - PerfMon Metrics Collector 用于监控服务器或本地计算机的系统资源使用情况,如 CPU 使用率、内存使用情况、网络输入输出等,帮助测试人员了解在测试过程中系统资源的消耗情况,以便评估系统性能和发现潜在的性能瓶颈。
2. 位置
jp@gc - PerfMon Metrics Collector 的添加位置在测试计划 → 监听器下,操作路径为:测试计划 → 添加 → 监听器 → jp@gc - PerfMon Metrics Collector。

3. 参数讲解
若要使用 jp@gc - PerfMon Metrics Collector 监控系统资源,需要借助 ServerAgent 工具。首先确保 ServerAgent 工具已启动,默认端口为 4444。在 jp@gc - PerfMon Metrics Collector 的配置界面中,填写要监控的主机 IP(如localhost表示监控本地计算机)和端口号(默认为 4444),然后选择要监控的指标,如 CPU、网络输入输出、内存等。例如:

通过上述对 JMeter5.3 各关键组件的详细介绍,相信大家已经对使用 JMeter 进行性能测试有了初步且全面的认识。从模拟用户行为的线程组,到设置运行时间的 Runtime 控制器;从记录事务时间的事务控制器,再到处理 HTTP 请求及管理信息头的相关组件,还有用于查看结果和分析性能指标的各种监听器,每个部分都在性能测试流程中发挥着不可或缺的作用。
JMeter 的功能十分强大,这次以百度搜索为例的入门讲解只是冰山一角。在实际应用场景中,大家可以根据不同的测试需求,灵活调整各组件的参数,组合出多样化的测试方案。无论是测试 Web 应用程序、移动应用接口,还是其他基于网络的服务,JMeter 都能为我们提供有效的性能测试支持。
希望大家在学习和实践过程中不断探索,遇到问题多思考、多尝试。也欢迎大家在评论区分享自己的使用心得与遇到的问题,共同进步。期待大家能够熟练运用 JMeter,为各类项目的性能优化保驾护航。
1690

被折叠的 条评论
为什么被折叠?



