记录一次loadrunner脚本调试过程

进入一个网址，对其中的某个功能进行一次添加数据操作，以此录制脚本

首先使用fiddler进行抓包，打开fiddler，然后按照流程操作一遍来获得抓包数据，之后切换另一个账号，按照同样的步骤再操作一次，用来进行比对。

将抓到的saz文件在loadrunner里面打开

将内容复制下来，用文本对比工具进行比对，找出需要关联或者参数化的部分。

重点来了，这里的userguid，一个是有数据的，一个是空值。非常关键，待会会说。

 找到需要关联/参数化的数据后，回到fiddler里面，找到这些数据第一次出现的地方，然后在loadrunner里面进行关联/参数化操作。

使用reg_save_param 函数

 找到脚本中所有的140E62903DB969C609D274520902BB30，替换成{epointloginid}

对用户名进行参数化

添加账号2的加密用户名，这里要注意的是，因为用户名使用了加密算法，所以即使是同一个用户名，分别录制两次脚本的话，数据虽然看上去不一样，但是还原之后还是一样的，所以要注意选择不同的用户名来进行参数化

 然后就是出现问题的guid，按理说应该找它第一次出现的位置进行关联，但是在fiddler中找到的是这样的

之前我们在对比工具那里看到过，test02账号的guid应该是空值，但是为什么这里却又出现了呢。

看看最后新增成功的脚本那里是什么情况

 果然test02是没有userguid的，这里应该是一个程序的bug，也就是说，如果我们在guid首次出现的地方进行关联，那么对于test02，最后返回的结果就不是空值，而是

 我们找到的值，这样一来关联就失败了。到这一步，我们应该去找开发沟通，看看是不是账号权限，或者是设置的问题。

但是假如我们想让脚本就这样跑通，那该怎么设置呢？

那么我们需要找到test02的userguid第一次为空值时，出现的位置，然后在那里设置关联就行。

用test01中存在的userguid来做跳板，找到test02中userguid出现的位置

发现是在这里，我们就在这里进行关联。

 

这样关联就完成了

最后设置一下检查点、事务、集合点。

设置一下日志和代理，跑一下看看情况

主要是看test02有没有问题

 

 都成功了，接下来就可以开始正式压测了。

打开controller，设置一下压测配置

 

 

 完成

中途有个小插曲，第一次跑的时候报错了，说是参数不匹配，回去看了之后发现，原来是之前设置的test02先跑的问题，改回来就行了

 

 完成压测

总结：这次的情况比较特殊，一般来说需要关联的数据不会像这种样子的，都是在第一次出现的位置关联就好了，总之需要和开发沟通好之后再进行测试