接触了一段时间loadrunner，但一直没有运用到实际中来。刚开始学习的时候使用loadrunner自带的Demo程序录制的脚本，整体感觉非常的轻松，基本上不要我去做什么，工具自己完全搞定了。so easy! 现在自己的经理要求我给公司新来的实习生做性能测试分享，OMG！既然是分享总不能一直将理论吧，也要来一些干货吧。我就准备以QQ邮箱的登陆为例，做一个简单的性能测试脚本。但是一切远没有那么简单，因为loadrunner脚本中的关联阻挡住了我。
开始吧！我使用的loadrunner12.53最新版本哦。首先录脚本要选择你用什么协议，网页本QQ邮箱登陆，使用http/html协议。这个简单。然后设置录制模式，该选用html模式呢还是url模式呢？我自己在网上搜索发现，如果是普通的网站使用html录制方式，但是如果使用了javascript以及applet或者是https开头的就使用url协议。于是我听从网友的推荐使用过了url协议。不过后来我又采取了html录制模式，使用其高级选项中的Record in separate steps and use concurrent group。（我请教了公司内一位有经验的老同事，他说这样将有利于关联点的寻找）设置过录制首页以及录制启动的浏览器就开始录制吧！整个过程非常简单，首先插入事物例如1_登录，然后输入用户名密码，点击登录。结束事物1_登录。插入事物2_退出，点击退出登录，结束事物2。结束录制，就是这么简单！一个基本的脚本已经录制好了。
接下来回放一下，发现脚本顺畅的回放了。并且提示脚本回放通过。别高兴，这个时候距离脚本成功还差的远呢。因为涉及到登录问题，服务器一般会返回可以标识登录用户身份的信息，而这些信息很可能会以cookie的方式储存在你的电脑中。当你再次登录的时候，服务器将会再次向你发送一些标识身份的信息，而这些动态变化的信息就是你登录和后续操作的凭证。当时当你直接回放的时候，loadrunner直接使用了你第一服务器返回的信息，不是服务器真正返回给你的信息，这个时候你自然就被拒之门外了。那么为什么我的回放仍然成功了呢？这是因为我们所选择的Http协议是没有状态的，没有状态就意味着，它不能够区分你给它的东西是不是正确的，只要返回给它信息，http协议自然就认为通过了。
这里我自己想了个描述关联问题的例子：A(客户端)，B(服务器)，C(loadrunner)。
C具有的特性：它能够复制A的行为（录制），它不能自己做出判断（http无状态特性）
一天C跟着A去B家里卖猪肉，A问B猪肉多少钱一斤啊？B说15块。A说给我来一斤猪肉，B说给我15块钱。接下来A给了B 15块钱，B给了A一斤猪肉。A说我买到了一斤猪肉。
C学习了A买猪肉的过程（相当于录制），C去B家里买猪肉，C问B猪肉多少钱一斤啊？B说30块。（市场变动，价格上浮）C说给我来已经猪肉，B说给我30块钱。接下来C给了B 15块钱，B一看对不起你钱不够我只能给你半斤猪肉，于是B给了C半径猪肉。C说我买到了一斤猪肉。
这个过程中C和A的动作是完全一致的，不同的是B的反应不同，但是这直接导致了我们所要的结果发生了变化。而这种变化就是我们关联的目标，如果C能够根据B说的价钱给钱，我们最终还是能够买到猪肉的！
当然我们可以通过loadrunner中的snapshot layout对比在登录后录制与回放的page view就可以直观的发现，你的回放并没有登录进去了。
那这个时候怎么办呢，需要我们在上面页面中的http data标签页中对比每一个url中的request和response的不同。至少我现在还没有找到，这是个漫长的过程。
后来请教那位大神，他建议我先补齐resques中缺少的cookie，使用web_add_cookie函数，保存版本。之后补齐request中的hearder使用web_add_header和web_add_auto_header函数。之后进行关联。现在cookie和header我已近补齐，但是关联在哪里呢？
未完待续。。。
