Jmeter正则表达式提取器的使用方法

下面简单介绍一下Jmeter正则表达式提取器的使用方法。

1、添加Jmeter正则表达式提取器:在具体的Request下添加Jmeter正则表达式提取器(Jmeter正则表达式在“后置处理器”下面)
例1如下:

引用名称: tokenid(自己定义)

正则表达式:

模板:$1$

匹配数字(0代表随机):

缺省值:

例2如下: 在生成的值是在cell中的时候,特别是有很多明细的。

引用名称: partDetailId(自己定义)

正则表达式:(.+?)

模板:$1$

匹配数字(0代表随机):5 (代表是第6个,从0开始算起)

缺省值:

位置1:名称及注释
位置2:正则表达式提取内容的范围。(关于各字段的详细说明请查阅协议的相关说明)
位置3:正则表达式提取的相关设置

引用名称:其他地方引用提取值的变量名称,如填写的是:str,具体的引用方式是${str}
正则表达式:提取内容的正则表达式【稍注意一下:()表示提取,对于你要提前的内容需要用小括号括起来】
模板:用$$引用起来,如果在正则表达式中有多个提取表达式(多个括号括起来的东东),则可以是$1$,$2$等等,表示解析到的第几个值给str,正则表达式的提取模式,值从1开始,值0对应的是整个匹配的表达式 如对于表达式s(.*) 值0对应str,值1对应tr
匹配数字(0代表随机):0代表随机,-1代表所有,其余正整数代表将在已提取的内容中,第几个匹配的内容。
缺省值:正则匹配失败时,取的值
一个符合要求的正则表达式:name = “file” value = “(.+?)”>。
():封装了待返回的匹配字符串。
.:匹配任何字符串。
+:一次或多次。
?:不要太贪婪,在找到第一个匹配项后停止

使用LR的socket协议进行进行性能测试

在公司的产品基本的功能测试做的差不多了之后,该做性能测试了,但发现一个问题,因为产品是属于嵌入式的产品终端的和B/S架构的软件结合使用的,而软件使用最容易造成瓶颈的地方不是系统B/S架构部分,而是在来源于终端对前置服务器和数据处理中心的压力。
我们又不可能有那么多的终端来同时产生压力,终端软件又是运行于ARM平台上的,连录制脚本的机会都没有。于是找终端开发的人员进行了了解,从他们那里了解到这边终端和前置服务器的连接采用的是tcp/ip协议进行通信。通过查找资料,发现我们LR的windows sockets协议可以模拟tcp/ip协议和前置服务器进行数据交互,这样便可以模拟终端来进行性能测试了。
还好几大中心集成测试的时候都是让开发给了他们的设计文档,对各个模块通信的数据格式还是比较了解,开着抓包工具,很快抓到了他们通信的数据包。
根据资料将数据分别填写到脚本中
user_init部分
/*********************************************************************
* Created by Mercury Interactive Windows Sockets Recorder
*
* Created on: Thu Jul 05 14:19:06
*********************************************************************/
#include “lrs.h”

vuser_init()
{
lrs_startup(257);
lrs_create_socket(““, “TCP”, “LocalHost=0″,”RemoteHost=192.168.1.9:9999”, LrsLastArg);//选择协议方式,接收数据的前置服务器IP:端口 与服务器建立socket连接。

return 0;
}
****************************************************************
//action 部分

Action()
{
lrs_send(““, “buf5”, LrsLastArg);//发送buf5中的数据到服务器,开始公话认证
return 0;
}
*************************************************************** //user_end 部分

vuser_end()
{
lrs_cleanup();//断开建立的TPC连接
return 0;
}

****************************************************************
//data.ws 部分

;WSRData 2 1

send buf5 44 //定义发送的内容变量buf5和信息的长度
“xaax00x1cx00x00x00x00x00xcax10x05x00x07x00x00xacx00x00x00xd3x00x00x00x34x00x00x00x03x00x00x00x03x00x00x00x00x00x00x00x00x27xfbx1fxee”//因为发送数据为16进制所以每个数据字段前需要添加x
弄好脚本后dubug了几次发现都能收到前置服务器的回应,但现在又面临了其他问题,如果每次发送的费用流水到数据处理中心都一样的话,数据处理中心会认为是重复流水,并不会进入数据处理流程进行处理。
这样就需要我们自己来生成发送的数据,除开消息的报文头,经历过一系列操作的随机变量转为16进制后,发送到前置竟然得不到回复信息了。检查了多次消息格式都是正确,找来开发的同事一问结果消息中还有信息的验证字段。因为生成的信息格式虽然正确但是效验不过,被认为是出错的数据包,前置服务器直接将数据包丢弃。又调用了他们的生成验证字段的dll生成效验字段后总算再次得到了回复,经过dba修改存储过程中对数据的效验后跑通了整个流程。

开启性能测试后对多个节点进行了跟踪,发现前置服务器这里收到数据后一段时间后不在对我们的消息进行回复,然后就前置就崩溃了,进过分析发现,前置服务器,因为数据处理中心接收处理数据缓慢,将数据都堆积到了缓存中,结果数据太多后,内存溢出程序崩溃。
最后在接收中心和处理中心分别添加缓存机制,数据处理中心先将数据接收过来在由另外的线程进行处理,同时前置将数据进行打包发送,不在一条一条的进行发送后,在进行压力测试,前置服务器崩溃的问题虽然解决了,但数据处理中心调用存储过程来处理数据依然缓慢,达不到系统的业务需求,又增加数据处理线程,几经周折终于达标了。
性能测试,想说爱你不容易啊。