【JMeter】测试带流水和随机参数

本文介绍如何使用JMeter生成流水号和随机数,包括配置流水号计数器的具体步骤以及通过函数助手生成随机数的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

为了能够区别测试数据所以在很多的时候都需要用到流水号和随机数进行区分,还好在JMeter中带有这两个数的解决方案

流水号

在这里插入图片描述

通过Add -> Config Element -> Counter可以创建一个流水号的计数器
在这里插入图片描述
Starting value:起始位置
Increment:递增号码
Maximum value:最大流水数值
Number format:流水号的格式
Exported Variable Name:外部变量引用名称
Track counter independently for each user:每个线程都从起始位置生成流水
在这里插入图片描述
在接口传递参数的时候采用${idCounter}获取到流水变量,结果如下:
在这里插入图片描述

随机数

随机数的生成可以通过Tools -> Function Helper Dialog打开生成器窗口
在这里插入图片描述
在Function Helper中先选择_Random
在这里插入图片描述
The minimum value allowed for a range of values:随机数最小值
The maximum value allowed for a range of values:随机数最大值
Name of variable in which to store the result(optional):变量名称
填写完成之后点击Generate & Copy to clipboard就能够生成随机数变量${__Random(0,9999999999,rdm)}
将表达式粘贴会需要放入的接口参数中
在这里插入图片描述
结果如下
在这里插入图片描述

<think>嗯,用户要求用JMeter为轻商城项目编写测试用例,这个需求很具体。从历史记录看,用户已经对性能测试方案有基本了解,现在需要落地到具体的测试用例设计。用户提到的三个站内引用其实都是关于测试基础知识的,但JMeter关联性不强,可能需要更聚焦。用户可能是测试工程师或开发人员,负责轻商城的性能测试工作。ta的真正诉求应该是如何将理论方案转化为可执行的测试用例,特别是JMeter特有的实现方式。用户之前提供的性能测试方案很专业,说明ta有一定经验,但可能缺乏JMeter实际操作细节。需要特别注意几个关键点:第一是测试用例的覆盖维度,用户引用里提到“全面的、系统的”这个原则很重要,但JMeter用例普通功能测试用例不同,要侧重性能场景。比如登录接口不仅要验证成功情况,还要设计不同并发下的性能验证。第二是用户引用的自动化测试示例(引用[2])其实是用Python+Selenium的,这JMeter的实现方式完全不同。需要帮用户转换思维:JMeter用线程组模拟并发,用CSV参数化实现数据驱动,而不是写for循环。第三是引用[3]提到的线程启动机制非常重要,这直接关系到测试场景的真实性。比如模拟秒杀场景时,用DelayThreadcreationuntilneeded会更接近真实用户涌入场景。针对轻商城特性,用例设计要突出电商典型场景:-商品搜索在高并发下的响应时间-下单流程在库存竞争时的处理-支付回调的异常模拟(这点用户之前问过,看来是重点)测试数据设计是难点,特别是参数化部分。比如测试购物车接口时,不同用户要有不同的商品组合,这需要准备关联数据(用户A的商品不能出现在用户B的购物车里),用JMeter的CSV+函数组合可以实现。用户没说清楚是否需要包含非功能测试用例。考虑到ta之前关注性能指标,应该重点设计性能验证点的用例,比如在HTTP请求里添加响应时间断言。同时要提醒监控服务器资源,这纯功能测试不同。</think> 下面是为轻商城设计JMeter测试用例的完整方案,结合性能测试业务特性: --- ### 一、测试用例设计维度(覆盖轻商城核心模块) | **测试类型** | **实现方案** | **JMeter组件组合** | **验证指标** | |-------------|-------------|-------------------|-------------| | **用户登录** | 1. 正常登录<br>2. 错误密码重试<br>3. 并发令牌获取 | CSV数据驱动 + HTTP请求<br>响应断言 + 定时器<br>JSON提取器存储token | 响应时间 ≤ 500ms<br>错误率 ≤ 0.5% | | **商品搜索** | 1. 高频关键词搜索<br>2. 空关键词检测<br>3. 分页压力测试 | CSV参数化关键词<br>边界值测试<br>吞吐量控制器 | TPS ≥ 800<br>90% Line ≤ 1s | | **购物流程** | 1. 加购并发操作<br>2. 库存超卖验证<br>3. 订单创建峰值 | 同步定时器模拟并发<br>BeanShell断言校验库存<br>事务控制器封装流程 | 事务成功率 ≥ 99.9%<br>MySQL线程数 ≤ max_connections*80% | | **支付回调** | 1. 正常回调处理<br>2. 模拟超时重试<br>3. 异常数据验证 | HTTP请求模拟第三方<br>固定定时器延迟响应<br>JSR223断言校验数据 | 回调延迟 ≤ 3s<br>幂等性校验100%通过 | --- ### 二、JMeter关键组件配置说明 #### 1. 登录模块参数化实现 ```mermaid graph LR A[CSV文件] -->|读取账号密码| B(HTTP请求) B -->|提取token| C(JSON提取器) C -->|存储变量| D(HTTP头管理器) D -->|后续请求携| E(购物车操作) ``` #### 2. 高并发下单场景配置 - **同步定时器**:模拟50用户同时点击结算 ```bash 线程组 → 同步定时器(Timeout=0, Number=50) → 事务控制器 → HTTP请求 ``` - **库存校验脚本**(BeanShell断言) ```java if (vars.get("response").contains("库存不足")) { Failure = true; FailureMessage = "库存超卖!当前库存:" + vars.get("stock"); } ``` #### 3. 支付超时模拟方案 ```java // 使用JSR223定时器模拟延迟 if (ctx.getPreviousResult().getResponseDataAsString().contains("callback")) { Thread.sleep(5000); // 强制延时5秒 } ``` --- ### 三、测试数据管理策略 | **数据类型** | **生成方式** | **示例** | **维护要点** | |-------------|-------------|---------|-------------| | 用户账号 | CSV文件轮询 | user${__counter}@test.com | 定期清理测试订单 | | 商品ID | 数据库预埋 | SELECT id FROM items LIMIT 100 | 隔离测试环境数据 | | 支付流水号 | 函数生成 | ${__Random(100000000,999999999)} | 保持唯一性约束 | | 搜索关键词 | 权重分配法 | "手机":60%, "电脑":30%, "":10% | 符合真实分布 | --- ### 四、测试执行流程 1. **环境预热**:先运行10分钟低并发(20%负载) 2. **梯度增压**:按50用户/分钟递增至目标并发 3. **峰值保持**:在目标并发量持续运行30分钟 4. **故障注入**:在稳定性阶段随机中断支付服务节点 --- ### 五、结果分析要点 1. **性能拐点定位** 观察资源利用率曲线,当出现: $$ \frac{ΔTPS}{ΔConcurrency} < 0.2 $$ 说明达到系统瓶颈[^3] 2. **数据库诊断建议** ```sql -- 轻商城高频慢SQL排查 SELECT * FROM mysql.slow_log WHERE query_time > 1 AND db='lightmall' ORDER BY start_time DESC; ``` ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Kida 的技术小屋

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值