LoadRunner脚本录制如何提升效率，LoadRunner脚本录制参数化配置步骤这个问题其实常常出现在项目刚启动不久的时候。测试人员通常会把注意力集中在测试场景设计上，或者直接追求并发压测效果，结果忽视了最基本的脚本质量。一套脚本如果从一开始录制就出错，或者参数配置粗糙，最后往往回放不稳定，事务统计不全，还一堆500错误。这时候再回头改脚本，效率低得可怕。为了避免这种反复返工的情况，本文将从录制优化、参数化配置和调试三个方面，讲讲脚本怎么录，怎么配，才能一次成型、稳得住。

　　一、LoadRunner脚本录制如何提升效率

　　脚本录制这件事，最怕的不是不会操作，而是没意识到操作方式对后续工作影响有多大。想提高效率，有些基础准备和录制技巧是绕不过去的。

　　1、先别急着点录制，流程一定要提前过一遍

　　不少人打开VuGen就开始点“Start Recording”，结果录了一半发现流程走错了，只好重新来一遍。更稳妥的做法，是在浏览器中先走一遍完整流程，熟悉每个页面的跳转逻辑、涉及的表单字段和系统反应时间。有了这个预演，再录制时心里就有谱了，不容易误操作，也不会漏掉关键步骤。

　　2、录制协议别乱选，系统特性决定选择方式

　　LoadRunner支持很多协议，但并不是每种都通用。比如传统Web系统用“Web-HTTP/HTML”没问题，但如果是SPA架构的页面（Vue、React类的），普通协议录不全请求，建议选“TruClient-Web”。接口测试时选“HTTP”或“Web Services”更合适，脚本更清爽干净。别看只是个协议选择，错一步可能录出来的脚本根本不能用。

　　3、过滤规则提前设好，别让图片和JS充满脚本

　　在录制前，进入“Recording Options”，把`.jpg`、`.png`、`.js`、`.css`等静态资源加到过滤列表里。这些资源对功能测试没意义，只会增加脚本体积和维护成本。一个干净的脚本，能让你一眼看出业务逻辑在哪里，有利于定位问题，也方便插入事务。

　　4、操作节奏要自然，别狂点猛点

　　录制时的点击节奏直接影响LoadRunner捕捉请求的完整性。如果操作太快，可能请求还没发送完就已经进入下一个页面，导致中间部分缺失。最好的方式是，每点击一个操作后稍微停顿1~2秒，确保页面加载完成，再进行下一步操作。

　　5、在关键业务节点插入事务，结构要清晰

　　不插事务的脚本，就像一条没有站点的地铁线。LoadRunner只能告诉你从头到尾花了多长时间，却无法告诉你每一站耗时情况。建议在登录、查询、下单、支付等操作前后用`lr_start_transaction`和`lr_end_transaction`包起来，比如：

　　每个事务名要简洁明确，方便后期分析报告。事务写在Action段，不要放Init或End里，否则控制器不会统计。

　　6、脚本录完不要直接保存，先检查逻辑和结构

　　录完之后，建议先浏览一下脚本内容，看有没有乱码、异常的请求堆叠、或者是明显录错的内容。如果发现问题，趁着录制流程还在脑子里，及时删除或重新补录。不要怕浪费时间，这一步做扎实了，后面调试会轻松很多。

　　二、LoadRunner脚本录制参数化配置步骤

　　脚本录完能跑通只是第一步，能否支持多个用户并发，关键还得看参数化做得够不够严谨。参数化不是可选项，而是稳定压测脚本的必备动作。

　　1、识别哪些字段要改成参数，这一步别嫌麻烦

　　打开脚本，从上到下扫一遍，重点查找这些值：用户名、密码、手机号、订单号、商品ID、地址、金额、时间等。凡是用户输入的内容，或者带有明显业务特征的字段，几乎都需要做参数化处理。避免多个虚拟用户用同一套数据，导致请求被服务端拒绝。

　　2、替换参数前，准备好数据源文件

　　建议使用CSV格式的纯文本文件，每行代表一组数据。比如：

　　如果参数比较多，也可以一列一个字段，统一管理。在VuGen里打开Parameter List，添加新参数，然后导入CSV文件，设置读取路径即可。

　　3、设置参数读取方式，让每个用户数据不冲突

　　参数读取有几种方式，比较推荐的是“Unique”，确保每个用户都拿到不同数据；如果只是单用户脚本测试，“Sequential”也可以接受；“Random”适合用在不要求顺序的查询类操作。场景不同，方式也要灵活选择，别一概而论。

　　4、确认变量是否替换成功，日志里能看出来

　　打开Run-time Settings，把日志设置为“Standard log+Parameter substitution”，然后运行一遍脚本。在日志窗口能看到类似：

　　这表示参数读取和替换都成功了。如果是空值或还是原来的固定值，说明配置出了问题，检查CSV路径、文件编码、参数命名是否一致。

　　5、复杂数据结构就用拼接方式组装

　　有些请求体是JSON格式，或者多个参数要组合到一块发送，这时可以用`sprintf`或`lr_save_string`先拼好。例如：

　　这样结构清晰，避免请求体格式错误造成脚本回放失败。

　　6、参数文件够不够用，记得按并发数量准备

　　如果你打算模拟50个用户，就准备至少50行数据。别拿5组数据跑几十个虚拟用户，那样不是数据污染就是账号冲突，脚本肯定报错。文件准备充足，脚本跑起来才稳。

　　三、LoadRunner脚本录制后的关联与调试技巧

　　参数化能解决一部分变量的问题，但系统返回的动态数据，比如token、session ID这些，是参数文件里无法提供的。这时候就要靠关联来动态提取，脚本才能稳定跑下去。

　　1、找出那些字段是系统动态返回的

　　回放失败的常见原因之一就是用了录制时的token，而当前系统返回的token已经变了。打开Replay日志，看错误的请求是哪一条，往前查它依赖的字段是不是在之前的响应中返回了新的值。如果有，那就该做关联了。

　　2、用web_reg_save_param提取值，记得写在请求前

　　比如你要从登录响应中提取session ID，就在`web_submit_data("login",...)`前面写：

　　左右边界一定要准确，Ord默认是1，适用于只匹配一次的字段。如果有多个结果，要设`Ord=All`或指定位置。

　　3、提取成功没成功，看日志就知道

　　开启“Extended log”后，跑脚本时在日志中搜索“Saving Parameter”，如果看到：

　　说明抓取成功。如果是空的，要回去看边界是不是写错了，或者响应内容本身就没有你要提取的字段。

　　4、提取变量在后面请求中怎么用

　　把原来写死的字段替换成变量，比如：

　　别忘了花括号，这是引用变量的标准方式，直接写变量名或者少个符号都会导致替换失败。

　　5、一次只改一个地方，调通了再继续

　　不要一次改太多变量，尤其是刚接触关联提取的时候。建议一边调一边验证，每成功提取一个变量，就跑一次确认无误，然后再处理下一个。这样不会一改一大片，反而更难找问题。

　　6、脚本运行不稳定时，先检查是不是提取失败

　　很多人调了一上午，还以为是服务器不稳定，其实就是token没提取对。只要你用的是系统每次都变的字段，就必须做关联。别指望它不会变，今天不变明天也可能出问题。

　　总结

　　回过头来看，LoadRunner脚本录制如何提升效率，LoadRunner脚本录制参数化配置步骤这个话题，关键点其实在于“流程、细节、习惯”。流程走顺了，脚本就录得快；细节控制好，脚本就跑得稳；而习惯，决定你是不是一个能写出高质量压测脚本的人。录制、参数、关联，每一步都不是“录完再调”的事，而是要在录的时候就考虑清楚。把脚本当成项目的一部分去管理，而不是一段临时工具代码，这才是做好性能测试的前提。