【loadrunner】录制socket协议

今天我们来对Loadrunner下socket协议的录制和录制后的脚本的简单设置

 

首先我们来简单的认识一下windows socket 协议

Winsock协议是作用于windows与TCP/IP协议之间的接口协议，通过下面的图表来描述：

由此可见，winsock是一个windows app与TCP/IP之间的传递者，windows app告诉winsock.dll它想做些什么，然后winsock将其翻译成TCP/IP指令，然后通过TCP/IP传递到网络上。

从此可见，winsock相对于其他LR协议作用于更底层，所以基本大多数有网络通信的应用都可以使用winsock进行录制和执行。也相对的解决了LR协议限制的问题。

下面我们来制作一个最简单的winsock协议脚本

首先，打开loadrunner12的Generator，选择windows sockets协议，在目标程序中选择需要录制的程序

 

但是我们仍然可以用winsock协议来录制脚本实现相同的功能。

然后我们就可以通过LR进行脚本的录制了，脚本录制过程如下：

点击录制→

对你要录制的程序进行选择

点击start recording开始录制

 

一段标准的winsock协议脚本可能是下面这个样子：

lvuser_init() {     lrs_create_socket("socket0", "TCP", "LocalHost=0", "RemoteHost=192.168.1.1:8080", LrsLastArg);     lrs_send("socket0", "buf0", LrsLastArg);     lrs_receive("socket0", "buf1", LrsLastArg);     lrs_receive("socket0", "buf2", LrsLastArg);     lrs_create_socket("socket1", "TCP", "LocalHost=0", "RemoteHost=192.168.1.1:2001", LrsLastArg);     lrs_receive("socket0", "buf3", LrsLastArg);     lrs_send("socket1", "buf4", LrsLastArg);     lrs_receive("socket0", "buf5", LrsLastArg);     lrs_send("socket1", "buf6", LrsLastArg);     lrs_receive("socket0", "buf7", LrsLastArg);     lrs_receive("socket0", "buf8", LrsLastArg);     lr_think_time(5);

数据内容存储在data.ws文件内

send  buf1 4          "0239"   send  buf2 265         "002BA123456Y000014QFFDFE000000000000000O99622278000000020012=002BA123456Y000014QFFDFE000000000000000O99622278000000020012=1234567890=1234512345=002BA123456Y000014QFFDFE000000000000000O99622278000000020012=002BA123456Y000014QFFDFE000000000000000O99622278000000020012"   recv  buf3 1024          "111s"

这样一个简单的winsock脚本就录制完成了

 

其实这样的一个脚本就已经可以执行了，为了增加脚本的交互性我们还需要对脚本进行一些调整来进行优化：

下面列出脚本优化的步骤和必须动作

1.       代码调整

2.       定义参数（可选）

3.       创建关联（可选）

4.       配置运行时设置（run-time setting）

5.       预执行

 

1.       代码调整

首先，如果是通过VGen录制的脚本，我们的脚本中可能会出现很多类似lrs_receive("socket0", "bufXX", LrsLastArg);这样的代码，而在实际的操作中，这些都是Server返回的应答信息，而绝大部分这样的信息是我们不必须关注的，往往我们可以通过注释掉这些不必要的信息来提高脚本运行速度，因为如果实际返回的结果和预期的结果长度不一致的话，就会进行验证，而往往这个验证的时间可能会很长时间，如果运气不好的话每个receive都来验证一把，那你的脚本可能会执行很久哦~

举个例子 ： 有的时候我喜欢用pipi作为登录名，有的时候也会用pipi99 这样在server进行应答的时候如果带入了登陆信息，那么返回的报文长度就会不一致，那么如果对一个安全性很高的系统，对每次用户操作均需要对用户权限进行验证的话，很可能每次的receive都会带有用户名信息，那么很杯具的情况就是每次receive我都需要浪费10秒。 Osz

 

我们注意到，每一个bufX后面都会有一个数字 例如 buf3 1024，这里1024表示发送或接收到报文的长度，在报文的发送阶段，LR会根据实际发送的报文长度进行填写该数值，所以完全不必担心前面我举例的情况。而在报文的接收部分，LR判断的机制仅仅是针对于收到的报文长度，而不是其内容，也就是说如果我data.ws中接收报文的长度定义为4，内容是pipi，而我执行脚本实际返回的内容是pppp，LR仍然会认为这个是一个预期的返回。

所以在上面的脚本中，在recv  buf3 1024 而内容为"111s"的情况下我们完全不必担心，LR根本不会去关心receive的内容是什么。

 

如果我们必须要接收一个超级大的返回报文，报文内容可能有1M，那么可能在只接收了500kb的时候就发生了接收超时的情况，这时候我们需要更改LR接收报文的超时时间（默认超时时间为10秒），用lrs_set_recv_timeout方法来进行超时时间的设定，这个方法是全局的，一旦设定，在这之后的接收超时时间均会改变。

 

还有另外一种情况，我们必须接受一个超大的返回报文，但是只有前100个字节是我们需要的，那么我们可以再这个接收前加入ltr_receive_ex方法，这样就可以控制接收的字节数，即得到了我们需要的数据，也节约了接收时间。

 

然后我们需要在脚本内加入必要的transaction和 rendezvous来使脚本更具可读性以及后期进行数据分析做准备，强烈建议在录制脚本的过程中进行这些动作，否则在一段很长的代码中去寻找需要的部分是一件很恼人的事情。

 

2.       定义参数（可选）

定义参数的好处是，可以通过参数的调用来实现相同业务逻辑下的不同数据的执行，具体的参数定义操作这里就不赘述，大家可以参考我之前的一篇关于lr参数设计的博文。

 

3.       创建关联（可选）

如果在有录制脚本中，有些数据是根据输入的值进行变化的，也就是说数据是存在关联的，那么我们就需要将这些数据进行关联，在下一参数进行执行时，关联点会根据实际情况进行取值，例如在用户登录时系统会为用户创建一个session，每次登陆的session均不同，如果不进行关联的话，就会在脚本的执行过程中造成执行失败。

创建关联的方法是lrs_save_param("socket2", NULL, "param1", 67, 5)；

Socket2：表示需要捕捉的socket名

Null：表示捕捉最近一条receive到的buffer，如果需要执行buffer，这里就为指定的buffer名

Param1：为捕捉到的值命名

67：偏移量(表示从第67个字节开始捕捉)

5：表示需要捕捉的部分的长度

* 偏移量的单位为字节，这里提供一个简便的计算方法，选中需要捕捉的报文，然后F7，会出现一个对话框如下，然后嘛，数数就ok了

4.       Runtime-setting 中可以设置脚本的循环，thinking time，log输出控制等

5.       以上动作都设置完毕后，在vgen中编译并执行该脚本，执行成功后，就可以进行场景设计了。

 

祝各位在winsock使用愉快！