说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
接着上一篇博客继续往下写 ：https://blog.csdn.net/qq_41782425/article/details/104233274
文章目录
五、场景设计
1.集合点
- 通过定时器完成。
- Synchronizing Timer（同步定时器）
✔ 用来保证我们的取样器在同一时刻向服务器发起负载。
✔ Number of Simulated Users to Group by
★ 设置同步的线程数量。
✔ Timeout in milliseconds
★ 超时时间，单位为毫秒。
【例】参数化登录，为登录设置集合点，运行负载测试（取消每人订 3 张票）
- 首先是在登录事务下添加参数配置
- 紧接着将提交用户登录数据的url参数中的用户名密码替换参数化
- 然后在登录断言中也要进行替换
- 订票信息进行替换
- 在登录事务之前添加一个同步定时器（相当于loadrunner集合点）
- 然后配置30个并发用户，10秒超时时间
- 设置线程组，200个用户跑，90S跑完
- 为了不让服务器压力那么大，设置一个用户不再订票3次，并且将不必要的打印禁用掉
- 运行脚本，说明如下一点
- 运行完毕，查看结果，有一部分是提示错误，大致原因则是服务器承受不了那么大的并发导致打开网站事务则就出错了，那么后续事务肯定也是报错的
- 点击查看日志，可以将日志复制放在记事本中进行查看，可以搜索关键字比如error等
2.IP 欺骗
-
在 jmeter 所在计算机中添加多个 IP
✔ netsh interface ip add address “本地连接” 172.16.0.2 255.255.0.0 -
创建参数化文件，存储多个 ip 地址
✔ IP 地址必须跟上面添加的计算机 IP 完全一致。 -
配置元件
✔ 指定参数化信息
✔ 放在所有请求的最前面 -
HTTP 请求
✔ Basic
★ Implementation→选择 Java 以外的内容，否则可能看不到 IP
✔ Advanced
★ SourceAddress→IP/HOSTNAME
■ ${ip 参数名}
✔ 查看"请求"
★ X-LocalAddress 后面的即为 IP
★ cmd→netstat -au | find “你自己的 ip 网段号” -
在桌面上创建一个批处理文件，向本地连接追加199个IP地址加上本身的192.168.88.207一共200个IP，并向当前目录创建txt文本里面追加写入200个IP
-
运行批处理，成功完成向本机本地连接中追加199个IP
-
在线程组下添加IP参数，并禁用集合点，配置如下
-
配置线程组，1秒跑10个用户，这样服务器压力不大
-
这里以第一个url为例，如果要实现IP欺骗所有的url要进行如下设置，首先设置实现为空白
-
切换到高级，设置主机名
-
运行脚本，随便点一个1开头的url请求，就能看到使用的IP地址了
3.多机联合负载
【例 1】使用多机联合负载运行 200 用户的负载测试。
- 两台计算机：控制机（192.168.88.207也可以充当负载机）、负载机（192.168.88.208），配置同网段 IP 且连通，双向关闭防火墙
- 每台计算机机各设置 100 个 IP，每台计算机准备一份 ip 参数文件，各含 100 个 ip，不重复，不冲突，博主因之前设置了控制机200个IP所以需要删除掉102~201这100个IP，然后分别向桌面写入100个server_ips服务器IP以及100个client_ips服务器IP
- 运行批处理文件，成功实现
- 然后回到负载机中，创建批处理添加102~200这个99个IP加上本身的192.168.88.208一共100个IP
- 运行批处理，成功为负载机添加99个IP
- 文件名必须相同，每台计算机准备一份 users.txt 账号密码文件，需要对控制机和负载机中的server_ips.txt以及client_ips.txt都命名为ips.txt，然后需要将控制机上的users.txt分成2个文件，每个文件中只有100个用户数据，然后拷贝第二部分的用户数据到负载机中
- 修改脚本和参数文件的目录为 jmeter\bin，在bin目录下创建一个文件夹，用于存储webtours订票脚本相关的所有文件
- 打开Jmeter，因为上一步文件路径改变了，所以在脚本中需要进行修正，因为默认Jmeter查找文件路径为bin目录下，所以可以不填写绝对路径，写成相对路径
- 刚博主忘记将出发地目的地文件flights.txt拷贝到bin了
- 设置计划1S中上3个人
- 删除cdtaogang1、cdtaogang2以及cdtaogang3用户数据
- 运行测试，结果没有报错，事务及断言全部通过
- 查看cdtaogang1、cdtaogang2、cdtaogang3用户订票数据，都是没有问题的，说明一点这里三个用户订票都是同一航班原因是博主循环订票之前已经设置为1了，所以只会订Denver到London
- 负载机搭建 jmeter 环境（至少安装 Jre）
- 然后安装Jmeter，同样在bin目录下创建WebtoursScript目录，复制脚本所需的文件，负载机不需要脚本
- 在 JMeter 控制机运行远程负载机
✔ 控制机
★ 打开 jmeter.properties 文件，搜索“remote_hosts”，加上远程 JMeter 负载机的“IP：1099”，重启 jmeter 生效，本机直接写 ip 或 127 均可
★ 控制机要执行测试的话，需要打开 jmeter-server.bat
✔ 负载机
★ 打开 jmeter-server.bat；
✔ 每个负载机均衡负担设置的线程数
★ 重新启动 jmeter
★ 控制机上线程数设置为：总并发数/负载数。
- 重启Jmeter后，点击运行——远程启动，可以看到在控制机jmeter配置中生效的IP地址，也就是控制机本机（负载机）以及远程的负载机，这就是为什么要将控制机中的所有文件以及文件名称配置成一样的原因了
- 当然这里博主肯定是让这两个负载机一起跑，所以选择运行远程全部启动
- 结果报错了，提示连接被拒绝，连接异常
- 解决方法：修改控制机所在jmeter配置文件中远程的负载机的端口改为1099
- 重启jmeter，运行没有出错，成功运行本机和远程负载机
- 查看本机jmter服务器运行日志以及远程负载机jmeter服务器日志，连接都是成功的
- 运行负载测试完毕，所有事务以及断言全部通过，没有任何报错
- 两台负载机服务器日志均显示完成
- 随便点击一个用户都成功写入订票数据
六、场景监控与结果分析
1.添加监听器
- 图形结果、用表格察看结果、聚合报告
- 关闭本地负载机以及远程负载机，只用本机跑压力测试，设置并发用户数
- 运行负载测试完成后，查看这三种图表
2.监控硬件资源
- 解压 ServerAgent-2.2.1.zip 到被监控计算机中
✔ Windows 服务器运行 startAgent.bat 文件
✔ Linux 服务器运行 startAgent.sh 文件
- 将 JMeterPlugins-Standard.jar 包复制到 jmeter 安装目录下的\lib\ext 下
- 重启 jmeter
✔ 选择监听器 jp@gc-PerfMon Metrics Collector
✔ 单击 Add Row，添加服务器的 ip，选择要监控的 CPU、内存、硬盘、网络等资源
- 添加监控硬件的CPU、内存以及磁盘
- 运行完负载测试，监控的性能、内存以及磁盘情况如下
3.结果分析
3.1 察看结果树-取样器结果
- Thread Name
✔ 线程组名称 - Sample Start
✔ 启动开始时间 - Load time
✔ 加载时长 - Connect time
✔ 连接时长 - Latency
✔ 等待时长 - Size in bytes
✔ 发送的数据总大小 - Headers size in bytes
✔ 发送数据的头部部分大小 - Body size in bytes
✔ 发送数据的正文部分大小 - Sample Count
✔ 发送统计 - Error Count
✔ 错误统计 - Response code
✔ 状态码 - Response message
✔ 响应信息 - Response headers
✔ 响应的头部信息
3.2 聚合报告
- Label
✔ 线程组中的步骤名 - #Samples
✔ 表示一共发出的请求数 - Average
✔ 平均响应时间，默认情况下是单个 Request 的平均响应时间（ms） - Median
✔ 中间值，有一半的服务器响应时间低于该值而另一半高于该值。 - 90%line
✔ 90%请求的响应时间。 - Min
✔ 服务器响应的最短时间。 - Max
✔ 服务器响应的最长时间。 - Error%
✔ 测试出现的错误请求数量百分比。
✔ 确认是否允许错误的发生或者错误率允许在多大的范围内。
✔ 若出现错误就要看服务端的日志，配合开发查找定位原因。 - Throughput
✔ 简称 tps，吞吐量
✔ 默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps 越高说明服务器处理能力越好。
✔ 吞吐量默认以 requests/second 来衡量，即每秒多少个请求。 - Kb/sec
✔ 以 KB/seond 来衡量的吞吐量。
3.3 用表格查看结果
- Sample#
✔ 每个请求的序号 - Start Time
✔ 每个请求开始时间 - Thread Name
✔ 每个线程的名称（代表一个虚拟用户） - Label
✔ Http 请求名称 - Sample Time
✔ 每个请求所花时间，单位毫秒 - Status
✔ 请求状态，如果为勾则表示成功，如果为叉表示失败。 - Bytes
✔ 请求的字节数 - Latency
✔ 等待时长 - Connect time
✔ 连接时长 - 样本数目
✔ 也就是请求个数，成功的情况下等于你设定的并发数目乘以循环次数 - 最新样本
✔ 表示服务器响应最后一个请求的时间 - 平均
✔ 每个线程请求的平均时间 - 偏离
✔ 服务器响应时间变化、离散程度测量值的大小
七、非 GUI 运行测试
1.修正脚本和设置
1.1 修改请求名称
- 为方便将来的结果分析，建议修改请求名称
- 首先博主将webtours_book.jmx脚本复制保存一份为webtours_book_2.jmx
- 删除IP参数，然后并清除第一个url所用到的cip参数
- 整理脚本，将不相关的全部删除，并设置并发为1个人
- 运行脚本，确保没有问题
- 修改请求名称
- 运行脚本，确保无误
1.2 解决察看结果树中的汉字乱码问题
- 修改 jmeter-properties 文件
✔ sampleresult.default.encoding=utf-8
1.3 日志中显示参数和断言信息
-
修改 jmeter-properties 文件
✔ log_level.jmeter=DEBUG
-
日志中的部分文本含义
✔ ResponseAssertion
★ 断言
✔ FileServer: Read
★ 读文件 -
注意
✔ 运行负载测试时不显示
✔ 在调试的时候可以调整日志级别来看输出，但是正常情况下要将日志的级别调高（INFO），减少日志输出，以提高 jmeter 本身性能 -
运行测试，明显将日志模式改为DEBUG后会有点卡顿，并输出的日志数据要比INFO的多
-
将日志全选放到记事本中，查看用户信息或者是参数名，都是能找到的，如果日志级别为INFO则不会记录这些数据的（只限于脚本调试，所以要进行负载测试也就是用户数不止一人时还是修改INFO）
1.4 设置资源监控图的保存位置
- 察看结果树
✔ 无需设置保存文件
✔ 可以删除“察看结果树” - jp@gc - PerfMon Metrics Collector
✔ 设置保存文件
★ 直接输入路径，不点“浏览”
2.非 GUI 运行脚本
-
进入 jmeter/bin 命目录后，输入如下命令
✔ jmeter -n -t jmx 脚本文件名 -r -l 结果文件名.jtl
★ -n：非 GUI 方式运行。nongui
★ -t：指定运行的测试脚本地址与名称，可以使用相对路径。
★ -r：开启远程负载机
● 远程机器列表在 jmeter.properties 中指定 remote_hosts
● 若使用-r，则必须事先开启 jmeter-server.bat
● 若省略-r，表示不使用远程负载机
★ -l：记录测试结果到文件，指定文件地址与名称，可以是相对路径，也可以是绝对路径。 -
首先对脚本并发数进行设置，然后保存脚本退出jmeter
-
注释掉配置文件中的负载机配置
-
打开cmd窗口，执行如下命令
-
回车运行命令
-
执行测试完成，在WebtoursScript目录下生成资源文件以及测试结果文件
3.导出测试结果
3.1 导出图形结果
- jmeter -g 结果文件名.jtl -o 图形结果存储目录
✔ 无需选监听器（硬件资源监控器需要保留）
✔ 不要导出硬件资源图
- 打开生成报告的test目录
3.2 性能结果图
- 打开结果目录中的 index.html 即可查看，IE 浏览器如果看不了，可以换更高版本或换浏览器。
3.3 解决导出结果中的汉字乱码问题
- 替换文件
✔ apache-jmeter-3.0\lib\ext\ApacheJMeter_core.jar
- 删除test目录以及WebtoursScript目录下的resource.jtl文件和result.jtl文件，重新生成一下就正常了
3.4 硬件资源图
- 非 GUI 运行结束正常导出结果，不用导出 PerfMon Metrics Collector
✔ 运行结束后打开 PerfMon Metrics Collector 视图，“浏览”数据文件，再将图存为图片
- 保存在WebtoursScript\test目录下
- 编辑index.html文件，将保存的硬件资源图添加到网页中，为了好看，博主按照其他图表的方式进行修改
- 打开页面，界面好看多了
4.测试结果图
4.1 dashboard 仪表盘
- Apdex(Application Performance Index)
应用程序性能满意度的标准
✔ APDEX 是由 APDEX 公司推出的衡量企业应用程序性能满意度标准的计算方式，将用户的满意度用数字衡量，范围在 0-1 之间。
★ 0 表示所有用户均不满意
★ 1 表示所有用户都满意
★ 设定请求样本目标响应时间为 t，则可容忍的响应时间上限设定为目标响应时间 t 的 4 倍即 4t，Apdex 计算公式定义为：(满意的样本数量+可容忍样本数量的一半)/总样本数量
● 如：总样本数量为 1000，目标时间 t=3s，假设有 750 个样本响应时间小于等于 t，150 个样本响应时间在 3s-12s 之间，100 个样本响应时间超过 12s，则用户满意度为：(750+150/2)/1000=0.825
★ Satisfied（满意）
★ Toleration threshold（可容忍门槛/上限）
★ Frustrated threshold（烦躁上限）
- Request Summary
✔ 样本请求的成功、失败百分占比图表。
- Statistics
✔ 此部分结果展示的是每个样本事务的一些常见的性能测试指标，跟我们通常看到的聚合报告的表格展示非常相近，多了成功与失败的占比。
- Errors
✔ 执行结果的错误情况，根据不同的错误类型进行展示。
✔ 四列分别对应：发生错误的类型、错误数量、类型错误占比（相对于错误总数）、类型错误样本占比（相对于所有的请求样本数量）。
4.2 Charts
- Over Time
✔ Response Times Over Time
★ 随时间推移，样本请求响应时间的变化。
✔ Bytes Throughput Over Time
★ 随时间推移，网络数据传输（发送、接收，单位：字节）速率的变化。
✔ Latencies Over Time
★ 随时间推移，请求样本延迟响应的变化。
- Throughput
✔ Hits Per Second
★ 每秒点击数。
✔ Codes Per Second
★ 随时间推移，每秒响应的状态码数量。
✔ Transactions Per Second
★ 每秒响应的事务数。
✔ Response Time Vs Request
★ 每秒请求总样本数量的响应时间分位数分布。
✔ Latency Vs Request
★ 随每秒样本请求数量变化，延迟请求的成功、失败响应时间。
- Response Times
✔ Response Time Percentiles
★ 响应时间百分位数分布。
✔ Active Threads Over Time
★ 随时间变化，激活线程数变化。
✔ Time Vs Thread
★ 随活动线程数变化，平均响应时间变化曲线。
✔ Response Time Distribution
★ 响应时间分布。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
