loadrunner使用教程之动态Token相关内容来了。所谓动态Token，核心并不是将值改成参数这么简单，而是需要找到它出现在哪一次响应里，在决定用边界、正则还是JSON方式去提取，本篇文章将为大家介绍。

loadrunner怎么处理动态Token

1. 先用“Design Studio”“Correlation”扫描动态值

   官方文档说明，这个页签可以扫描、关联并查看脚本里的动态值，扫描来源还分成rule、record、replay和manual几类。先将候选token扫出来，再决定怎么抓，会让手动全脚本翻值更快。

2. 先确认Token出现在“前一个响应”还是“下一次请求体”里

   `web_reg_save_param_ex`、`web_reg_save_param_regexp`和`web_reg_save_param_json`都是注册到“下一条action function”去抓值的，官方还特别说明，这类搜索不适用于异步下载或跨步骤返回的数据。所以你如果把提取语句放错位置，常见结果就是脚本能回放，但参数一直抓不到。

3. 文本规则清楚时优先用边界提取

   如果Token左右两边的文本很稳定，优先用`web_reg_save_param_ex`。官方说明里写得很直接，它就是抓左右边界之间的内容，而且保存的是边界内部、不含边界本身的值。对sessionId、csrfToken、隐藏域value这类典型Token，这种方式通常最直观。

4. 结构不稳定时改用正则或JSON

   如果左右边界会变，或者Token在JSON里、字段层级又很清楚，就不要硬写边界。官方说明中，正则提取用`web_reg_save_param_regexp`，支持捕获组；JSON提取用`web_reg_save_param_json`，按QueryString也就是JSONPath取节点。规则选对以后，脚本会比硬凑左右边界稳很多。

loadrunner动态Token提取规则怎么写

1. 边界规则先写唯一左边界和右边界

   官方在New Rule里将Boundary Based单独列出来，左边界是最左定位点，右边界可以设成字符串结尾、换行或用户自定义文本。实际写规则时，左右边界越唯一，误抓概率越低；如果边界数字经常变，还可以用“User#for any digit”将数字当通配位处理

2. 正则规则要先想清楚抓“整段”还是“分组”

   “Web_reg_save_param_regexp”支持0-10个捕获组。官方说明里写到，默认抓Group=1；如果表达式没有捕获组，就必须写Group=0.也就是说，正则规则不是只要可以匹配到就行，还是要提前决定自己到底要保存整段Token，还是只要中间那一截动态值。

3. JSON规则按字段路径写，不要套边界

   如果响应本身就是JSON，官方建议直接用“web_reg_save_param_json”的QueryString去取节点。它还支持“SelectAll=Yes”,一次抓多个匹配值，并自动生成参数数组和“_count”计数参数。对accessToken、id列表、对象数组里的字段，这种写法通常比边界和正则更干净。

4. 规则名和参数前缀最好提前统一

   官方在Correlation Rules里支持新增应用、导入导出规则，也支持给自动生成的参数加prefix。这个细节很重要，因为规则一多以后，参数前缀如果不统一，脚本里很快会出现一场难辨认的临时名，后面维护就会比较乱。

以上便是关于loadrunner使用教程之动态Token的相关内容，想获取更多信息欢迎随时与我们取得联系。