项目测试之Jmeter

基础-页面

线程组

在这里插入图片描述

Ramp-Up表示多少时间内启动线程,比如线程数100Ramp-Up设置为10,表示10秒内启动100线程,不一定是每秒启动10个线程;
是在Ramp-up时间内,启动x个线程,但不能保证x个线程同时对服务器发起请求;

HTTP请求

案例

使用BeanShell

参数配置:使用变量${xxx}
在这里插入图片描述
消息体参数:
在这里插入图片描述

http请中body data不能选中

jmeter默认 参数与消息体参数两者只能存在其一,前者有参数,后者就不能使用;

参数案例:
在这里插入图片描述

消息体案例:
在这里插入图片描述

使用HTTP信息头管理器

可以设置http信息头内容,比如Content-Type的值,来设定http请求的参数传递方式。
在这里插入图片描述

本机jmeter加密方式

sm3:

import cn.hutool.crypto.SmUtil;

String[] appIdList = new String[]{"1c7aad9cd3abc01268c4ecfdac248a3b912073d6"};
String[] reqIdList = new String[]{"1234567"};
String[] secretList = new String[]{"806ec0000170a169"};

String ct = String.valueOf(System.currentTimeMillis());
String appId = appIdlist[0];
String reqId = reqIdList[0];
String secret = secretList[0];
String sceneId = "0001";

String ss1 = String.join("&","appId=" + appId, "ct=" + ct, "reqId=" + reqId);
log.info(ss1);

String sign = SmUtil.sm3WithSalt(secretList[0].getBytes()).digestHex(ss1);

vars.put("reqId",repId);
vars.put("appId",appId);
vars.put("sceneId",sceneId);
vars.put("ct",ct);
vars.put("sign",sign);
//vars.get("reqId");
//vars.get("appId");
//vars.get("sceneId");
//vars.get("sign");
//vars.get("ct");

md5:

import org.apache.commons.codec.digest.DigestUtils;

String apiKey = "wuxi";
String transId = "20240412150606100335423";
String code = "28f09d127a745d97b82b8d9259ce3a79";
// String ip = "127.0.0.1"; // 异常ip
String ip = "127.2.2.12";
String apiSecret = "bv78g4f38ofb";

String checkParam = "apiKey"+ apiKey +"apiSecret" + apiSecret + "transId" + transId;
String token = DigestUtils.md5Hex(checkParam);

vars.put("apiKey",apiKey);
vars.put("transId",transId);
vars.put("code",code);
vars.put("ip",ip);
vars.put("token",token);

重定向

概念:

自动重定向(状态码一般是20020X):当重定向时,自动跳转时,只针对GET和Head请求,自动重定向可以自动跳转到最终目标页面,但是jmeter不记录重定向过程内容【在查看结果树中只能看到重定向后的响应内容】

跟随重定向(状态码一般是30230X):当重定向时,自动跳转时,自动重定向可以自动跳转到最终目标页面,但是jmeter记录重定向过程内容【在查看结果树中既能看到重定向后的响应内容,也能看到重定向前的响应内容】

请求参数构建错误

🍇 1.0 接口
@RequestMapping("/v1.0/xx")
public Result function(HttpServletResponse response, HttpServletRequest request, @RequestJson BaseParams baseParams){}
现象:
java代码:
采用post请求,参数中含有+;
使用new HttpPostUrlEncodedFormEntity的utf-8编码entity对象;可以正常执行;
jmeter:
将其中的参数摘录出来,post请求,body携带参数,可以执行;

🍇 2.0 接口
@RequestMapping("/v2.0/xx")
public Result function(HttpServletResponse response, HttpServletRequest request, BaseParams baseParams) {}
现象:
java代码:
采用post请求,参数中含有+;
使用new HttpPostUrlEncodedFormEntity的utf-8编码entity对象;可以正常执行;
jmeter:
将其中的参数摘录出来,并且将含有+的参数,将其转换为%2B,才能执行;
并且不能通过body携带参数,只能通过key-value键值对传递;

🍇 3.0 接口
@RequestMapping("/v3.0/xx")
@ResponseBody
public Result function(HttpServletResponse response, HttpServletRequest request, @Valid BaseParams baseParams) {}
现象:
java代码:
采用post请求,参数中含有+;
使用new HttpPostUrlEncodedFormEntity的utf-8编码entity对象;可以正常执行;
jmeter:
将其中的参数摘录出来,并且将含有+的参数,将其转换为%2B,才能执行;
并且不能通过body携带参数,只能通过key-value键值对传递;

核心点:
参数绑定和编码不同;

参数便捷构建

在这里插入图片描述

该界面中,创建key-value数据,快捷方式是直接复制key=value的数据,然后选择下方的“从剪贴板添加”即可。
但是存在一个问题,它会消除value中的“=”。
案例:
剪贴板对象为:
1 apikey=xxx=xxx
2 a = xxx=
3 a = =xxx
真实效果如下:
1 value中=后的内容没有被输入
2 value中空格可以正常识别,但是=后会消失
3 value中=前的空格被输入,=后的文字没有被识别

在这里插入图片描述

nacos测试-服务发现

🍇 http请求构建
在这里插入图片描述

参数介绍:
namespaceId = 命名空间id
serviceName = 服务名
ip = 服务的ip地址
port = 服务端口号
weight = 该服务的权重
healthy = 服务的健康状态
enable = 是否是临时实例
groupName = 服务所述组名

🍇 HTTP消息头管理器
在这里插入图片描述

Authorization:认证信息,nacos的鉴权token
Content-Type:请求中数据的格式

🍇 计数器
在这里插入图片描述

多个服务发起注册,测试的时候,只针对端口port做处理,即针对port做递增处理;
假设4个请求,起始端口是8081,那么所有的请求就是8081 8082 8083 8084 

🍇 BeanShell预处理程序
在这里插入图片描述

为实现将计数器里面的数值,读取到参数列表中;
其中vars.get("xx")参数名与计数器中的引用名称保持一致;

🍇 聚合报告
在这里插入图片描述

列表字段含义:
label = 请求的名称
样本 = 请求的个数
针对响应时间长短,设置了参数:
中位数 = 表示所有请求时长的中位数
90% = 表示90%的请求时长
95% = 表示95%的请求时长
99% = 表示99%的请求时长
最小值 = 表示请求的最短响应时间
最大值 = 表示请求的最长响应时间
异常 = 表示异常请求的占比
吞吐量 = 

在这里插入图片描述

字段含义:
timeStamp = 每个请求的时间戳
elapsed = 耗时时间
label = 请求的标签
responseCode = 响应码
responseMessage= 响应信息
threadName = 线程名
dataType = 响应数据类型
success = 请求是否成功
failureMessage = 断言失败信息
bytes = 响应接收字节数
sentBytes = 请求发送字节数
grpThreads = 当前线程组的线程数
allThreads = 所有线程组的线程数
URL = 请求URL
Latency = 请求发送到接收到第一个响应的时间
IdleTime = 请求再队列中等待的时间
Connect = 建立TCP请求的时间

🍇 查看结果树
在这里插入图片描述

nacos测试-配置读取

🍇 线程组配置
在这里插入图片描述
🍇 HTTP请求
在这里插入图片描述

参数介绍
show:展示信息 =all
dataId:nacos中唯一标识配置信息的标识符
group:nacos中区分不同微服务或应用组件
tenant:命名空间
namespaceId:命名空间
content:={"server":{"port":"$ser_port"},"database":{"url":"$sql_url","username":"$sql_name"}}
port:使用port服务的端口号;url:服务使用的数据库地址;username:访问数据库的用户名

🍇 BeanShell预处理程序
在这里插入图片描述
🍇 查看结果树
在这里插入图片描述
🍇 聚合报告
在这里插入图片描述
在这里插入图片描述

字段含义:
timeStamp = 每个请求的时间戳
elapsed = 耗时时间
label = 请求的标签
responseCode = 响应码
responseMessage= 响应信息
threadName = 线程名
dataType = 响应数据类型
success = 请求是否成功
failureMessage = 断言失败信息
bytes = 响应接收字节数
sentBytes = 请求发送字节数
grpThreads = 当前线程组的线程数
allThreads = 所有线程组的线程数
URL = 请求URL
Latency = 请求发送到接收到第一个响应的时间
IdleTime = 请求再队列中等待的时间
Connect = 建立TCP请求的时间

问题

修改字体大小

参考:
https://blog.csdn.net/qq_44084906/article/details/121717542 修改jmeter字体大小

jmeter启动

分析:
	apache-jmeter-5.6.2中的apacheJmeter.jar和jmeter.bat有什么区别么 对于jmeter的启动而言
apache-jmeter.jar 
	是JMeter的核心组件,是一个Java归档文件(JAR文件),包含了JMeter的所有类和资源文件。
	它本身不能直接运行,需要通过Java虚拟机(JVM)来执行。
	可以通过命令行使用java命令来启动JMeter,指定apache-jmeter.jar作为主类路径。java -jar apache-jmeter.jar
	是一个Windows批处理脚本文件,用于在Windows操作系统上启动JMeter。
	负责设置JMeter运行所需的各种环境变量和参数,然后调用Java虚拟机(JVM)来启动JMeter。
	简化了启动JMeter的过程,用户不需要手动设置复杂的命令行参数。

最后

<think>我们正在比较Apifox和JMeter这两个工具。根据引用内容,Apifox是一个集API设计、调试、Mock、测试于一体的工具,而JMeter则主要用于性能测试。首先,我们需要明确两个工具的定位:-Apifox:更侧重于API的全生命周期管理,包括设计、文档、调试、Mock、自动化测试等。-JMeter:主要是一个性能测试工具,支持多种协议,但API文档管理和Mock功能较弱。接下来,我们将从功能对比和使用场景两个方面进行分析。功能对比:1.接口设计与管理:-Apifox:支持API设计,可生成文档,类似Swagger,但功能更全面。-JMeter:没有接口设计功能,主要用于测试已有的接口。2.接口调试:-Apifox:提供类似Postman的调试功能,支持环境变量、前置脚本、后置脚本等。-JMeter:也可以进行接口调试,但操作相对复杂,界面不如Apifox直观。3.Mock功能:-Apifox:内置Mock功能,支持零配置生成智能Mock数据(如引用[2]所述)。-JMeter:没有内置的Mock功能,需要配合其他工具使用。4.性能测试:-Apifox:支持基本的性能测试,但功能相对简单。-JMeter:专注于性能测试,支持高并发、分布式测试,功能强大(引用[1]提到Jmeter在性能测试方面很强,但学习曲线陡峭)。5.自动化测试:-Apifox:支持自动化测试,可以编写测试用例并集成到CI/CD流程中。-JMeter:同样支持自动化测试,通过编写测试计划并配合命令行使用。6.学习曲线:-Apifox:界面友好,学习曲线平缓。-JMeter:学习曲线较陡峭(引用[1])。7.其他功能:-Apifox:支持数据库操作、代码生成等。-JMeter:支持多种协议(HTTP,FTP,JDBC等),可以用于测试各种类型的应用。使用场景:1.Apifox适用场景:-前后端分离开发:前端可以使用Apifox的Mock功能模拟后端接口,加速开发。-团队协作:提供统一的API文档和接口管理,方便团队协作。-接口调试与自动化测试:适合开发人员和测试人员进行接口调试和自动化测试。-轻量级性能测试:当需要进行简单的压力测试时,可以使用Apifox。2.JMeter适用场景:-性能测试:需要对系统进行高并发、分布式压力测试时,JMeter是更专业的选择。-复杂测试场景:需要模拟多种协议、复杂的测试逻辑(如条件分支、循环等)。-非GUI环境测试JMeter可以在无界面环境下运行,适合集成到持续集成流程中。总结:-如果你需要全生命周期的API管理工具,包括设计、文档、Mock、调试和自动化测试,那么Apifox是更好的选择。-如果你主要关注性能测试,特别是高并发和复杂的性能测试场景,那么JMeter更合适。另外,根据引用[4],Apifox和Eolink的对比中提到Eolink在自定义方面更强,但这里我们比较的是Apifox和JMeter,所以不展开。不过可以看出,Apifox在国内API工具中是一个功能全面的选择。因此,在实际项目中,两者可以结合使用:用Apifox进行接口设计、调试和Mock,用JMeter进行专业的性能测试。相关问题:1.Apifox和JMeter在性能测试方面具体有哪些差异?2.如何将Apifox和JMeter结合使用以提高测试效率?3.Apifox的Mock功能在实际开发中如何应用?</think>### Apifox vs JMeter 功能对比及使用场景分析 #### **1. 核心定位差异** - **Apifox** 定位为 **API全生命周期管理工具**(设计+调试+Mock+测试),覆盖: - API设计文档生成(类Swagger) - 接口调试(类Postman) - 零配置Mock服务(自动生成仿真数据) - 自动化测试(支持CI/CD集成) - 团队协作(权限管理/版本控制) - **JMeter** 定位为 **专业性能测试工具**,核心能力: - 高并发压力测试(支持分布式部署) - 多协议支持(HTTP/HTTPS/FTP/JDBC等) - 性能指标监控(响应时间/吞吐量/错误率) - 复杂测试场景构建(参数化/逻辑控制器) #### **2. 功能对比矩阵** | **功能维度** | **Apifox** | **JMeter** | |--------------------|---------------------------------------|-------------------------------------| | **接口设计** | ✅ 可视化编辑/自动生成文档 | ❌ 不支持 | | **Mock服务** | ✅ 智能零配置Mock(近真实数据)[^2] | ❌ 需额外工具配合 | | **调试体验** | ✅ 类Postman的交互式调试 | ⚠️ 需配置Sampler/断言 | | **性能测试** | ⚠️ 基础并发测试 | ✅ 专业级负载模拟(支持万级并发) | | **学习曲线** | 较低(图形化界面) | 陡峭(需掌握元件逻辑)[^1] | | **自动化测试** | ✅ 测试用例管理/CI集成 | ✅ 脚本录制/命令行执行 | | **数据库操作** | ✅ 内置SQL查询功能 | ❌ 需JDBC插件扩展 | #### **3. 典型使用场景** - **选择Apifox的场景**: - **前后端协作开发**:前端使用Mock数据独立开发,后端同步实现接口 - **API文档标准化**:自动生成统一文档,替代Swagger+Postman组合[^3] - **轻量级自动化测试**:快速验证接口功能逻辑(如登录/支付流程) - **快速排查问题**:实时调试接口+查看网络请求详情 - **选择JMeter的场景**: - **系统性能瓶颈检测**:模拟电商秒杀/API网关等高并发场景 - **服务容量规划**:通过阶梯加压测试确定服务器承载极限 - **协议级深度测试**:需要测试WebSocket/MQ等非HTTP协议 - **持续性能监控**:集成Jenkins实现每日性能基线校验 #### **4. 互补使用建议** 在实际项目中可组合使用: ```mermaid graph LR A[需求分析] --> B{测试目标} B -->|功能验证/Mock| C[Apifox] B -->|性能压测| D[JMeter] C --> E[生成接口文档] D --> F[输出性能报告] ``` > **典型案例**:开发阶段用Apifox设计API并Mock数据 → 联调用Apifox调试接口 → 上线前用JMeter执行压力测试 → 运维阶段用JMeter定期巡检性能[^4] #### **5. 总结建议** - **Apifox优势**:提升团队协作效率,解决API碎片化管理问题,**推荐给前后端分离团队** - **JMeter优势**:专业性能测试能力,**适合性能工程师和运维团队** - **决策关键点**: - 是否需要统一管理API全流程? → 选Apifox - 是否需要模拟>1000并发用户? → 选JMeter - 预算有限且需多功能集成? → Apifox性价比更高[^4] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值