LoadRunner关联的参数怎么去找，LoadRunner关联参数保存使用，很多人一遇到脚本回放失败，就先去改请求体里的动态值，结果越改越乱。真正有效的处理方式，不是盯着报错行死改，而是先把“动态值从哪里来、在哪一步被返回、在哪一步被再次提交”这一条链路找出来。

　　一、LoadRunner关联的参数怎么去找

　　做LoadRunner关联参数查找时，最怕的不是不会写函数，而是根本没有找对动态值。很多脚本失败，并不是所有字段都要关联，而是少数关键值在前后请求之间发生了变化，例如会话标识、隐藏域、令牌、时间戳或分页序号。

　　1、先用Design Studio找动态值

　　（1）录完脚本后先打开Design Studio的Correlation页，不要急着手工在代码里搜索整份脚本；

　　（2）官方说明里写得很清楚，Design Studio会扫描脚本里的动态值，并把候选值列在表格中，方便你判断哪些值需要做LoadRunner关联参数；

　　（3）这种方式最大的好处，是它不只是告诉你“哪个值变了”，还会同时告诉你这个值来自哪里、要替换到哪里。

　　2、再按规则、录制、回放三条线缩小范围

　　（1）官方自动关联文档说明，VuGen支持规则扫描、录制后扫描和回放后扫描三类自动关联；

　　（2）规则扫描适合处理常见环境里的已知动态值，录制扫描适合在代码生成后快速补出大部分候选项，回放扫描则更适合继续追查脚本失败前后的动态值；

　　（3）所以LoadRunner关联参数怎么去找，最稳的顺序往往是先录制扫描，再回放扫描，最后把还没处理掉的少量值手工补齐。

　　3、重点看“前面返回、后面提交”的值

　　（1）真正需要做LoadRunner关联参数的值，通常是先由服务器在响应中返回，再被客户端在后续请求里带回去；

　　（2）如果一个值只出现一次，或者只是展示性文本，通常就不是优先级最高的关联对象；

　　（3）因此查找时不要被所有差异值干扰，而应先盯住登录后令牌、隐藏域、会话编号、链接参数这类会跨步骤流转的数据。

　　4、找不到时再回到响应里定边界

　　（1）如果自动扫描没有把关键值抓出来，就要回到服务器响应内容里手工找这个值前后的边界；

　　（2）官方web_reg_save_param_ex文档明确写到，这类函数就是用左右边界把动态数据提出来并保存为参数；

　　（3）所以当自动关联不够用时，LoadRunner关联参数的核心就变成了“先找准返回位置，再准确定边界”。

　　二、LoadRunner关联参数保存使用

　　把动态值找出来以后，真正决定脚本能不能跑通的，是LoadRunner关联参数保存使用这一步是否做完整。很多人以为把web_reg_save_param_ex写进去就结束了，实际上参数保存、参数替换、参数校验和参数二次处理往往缺一不可。

　　1、先把参数正确保存下来

　　（1）手工关联时，先在返回值出现之前注册web_reg_save_param_ex，让它去抓取下一步响应中的动态数据；

　　（2）官方说明里写得很清楚，这个函数会在指定左右边界之间查找内容，并把结果存到参数名里；

　　（3）也就是说，LoadRunner关联参数保存时最关键的不是函数名，而是参数名、左右边界和查找范围是否真的对应到目标值。

　　2、再用花括号把参数替换进后续请求

　　（1）参数保存后，不能把原来的动态值留在后续请求里，而是要用{参数名}的形式替换掉原值；

　　（2）官方文档明确写到，关联时后续函数调用要用花括号引用保存好的参数；

　　（3）这一步如果漏了，就会出现“参数明明抓到了，脚本还是失败”的典型情况。

　　3、保存多个值时要知道怎么取

　　（1）如果同一段响应里会命中多个结果，官方文档说明可以用Ordinal=All把它们保存成数组；

　　（2）保存后会形成ParamName_1、ParamName_2这类下标形式，同时还会有ParamName_count记录命中总数；

　　（3）因此LoadRunner关联参数保存使用不只是单值替换，遇到批量值时还要知道自己取的是哪一个。

　　4、用lr_eval_string做一次有效性验证

　　（1）官方属性文档和lr_eval_string文档都给出了判断参数是否真正被设置的方法；

　　（2）最实用的做法，是在关键步骤前后打印参数值，或直接判断lr_eval_string返回的内容是不是预期结果；

　　（3）这一步很重要，因为很多LoadRunner关联参数问题并不是替换错了，而是前面根本没抓到。

　　三、LoadRunner关联参数提取后怎么验证和复用

　　真正成熟的脚本处理方式，不是把参数抓出来就算完成，而是继续验证这个参数在后续请求里是否稳定可用，并且尽量让同类动态值以后不必重复手工处理。官方Design Studio文档明确写到，你可以在关联后继续点Replay&Scan再找新的动态值，也可以把当前规则Add as Rule作为后续同类场景的识别依据。

　　1、先回放验证参数链路有没有闭环

　　（1）参数提取完成后，先做一次回放，看脚本是否能顺利穿过原来失败的步骤；

　　（2）如果仍然失败，就继续用Replay&Scan去找剩余没被处理的动态值；

　　（3）很多脚本并不是只缺一个LoadRunner关联参数，所以验证时一定要按失败点继续追。

　　2、需要加工时再做参数二次处理

　　（1）有些抓到的值并不能原样使用，例如要加减一位编号，或拼成新的提交格式；

　　（2）官方“修改已保存参数”文档说明，先用atoi或atol转成整数，改完后再用sprintf转回字符串；

　　（3）这类处理说明LoadRunner关联参数不只是提取，还可能涉及二次加工后再提交。

　　3、稳定后把经验固化成规则

　　（1）如果某类动态值在同一系统里反复出现，就不要每次都手工重新找；

　　（2）Design Studio支持Add as Rule，把当前识别方式沉淀成规则，后续录制时更容易自动命中；

　　（3）这样做的价值，不只是省时间，还能让LoadRunner关联参数的处理越来越标准化。

　　总结

　　LoadRunner关联的参数怎么去找，LoadRunner关联参数保存使用，真正高效的做法不是看到动态值就立刻手改，而是先用Design Studio和自动关联把候选值找出来，再回到响应里定边界，用web_reg_save_param_ex把值保存成参数，随后用花括号替换进后续请求，并借助lr_eval_string做校验，最后再通过Replay&Scan和Add as Rule把这套逻辑稳定下来。