LoadRunner APP压测实战：LR12录制+LR11并发组合方案详解

简介针对APP后台服务器进行性能压测的实战文档面向测试工程师、性能测试新手及移动应用后端开发者。该方案巧妙结合LoadRunner12的App脚本录制能力与LoadRunner11的免费高并发支持先用LR12录制、调试脚本再放到LR11执行压测LR11破解版最高可支撑6.5万并发弥补了单版本工具在移动端压测上的短板。文档从LoadRunner简介、环境准备、手机WiFi代理设置、Remote Application via LoadRunner Proxy录制、脚本Debug与异常行处理到LR11安装破解、运行脚本及结果分析形成完整操作链路。整套资源以1个docx文档提供共1个文件压缩包约691KB步骤清晰适合边看边操作。目前已有555人学习下载可帮助读者快速搭建APP后端压测环境并掌握关键排错思路。1. 双版本组合压测这套 LoadRunner APP 压测方案为什么值得一试多数人以为 LoadRunner 是 Web 压测的专属工具碰到移动端 APP 后台接口就直接转投 JMeter 或自研脚本。但如果你手里只有 LoadRunner 授权、团队也习惯了 LR 的操作流那这套「LR12 录脚本 LR11 跑并发」的组合方案就是一条性价比极高的野路子。它的核心思路很简单LR12 社区版免费、能录手机 APP 的代理请求虽然只支持 50 个并发LR11 有通用 license、能跑到 6.5W 虚拟用户但不支持 APP 录制。把两者拼在一起等于用免费工具补上了付费工具的功能缺口。这套流程我在模拟项目X的实际压测里完整跑过对后端接口的请求抓取、脚本清洗、并发施压和结果分析都有可复现的路径适合正在做移动端服务端性能验证的测试和开发人员。2. 环境准备与链路搭建先把代理录制这条数据管道打通2.1 为什么要用代理模式录制 APP 请求移动端 APP 和 Web 页面的最大区别在于Web 端可以通过浏览器插件或网关直接捕获 HTTP/HTTPS 流量而 APP 的请求大多走 HTTPS 加密通道普通录制工具只能看到一堆乱码或直接断连。LR12 社区版提供的解决思路是「中间人代理」——在电脑上开一个监听端口手机把代理指向这台电脑所有 APP 请求都会经过这个端口转发到后端服务器LR12 在这个过程中把请求内容解析并记录成脚本。这套录制链路里三个角色缺一不可电脑端的代理监听服务、手机端的代理设置、以及 APP 本身可操作的业务流程。我一般会在开始录制前先确认手机和电脑在同一网段并且电脑防火墙放行了代理端口否则会出现「录制启动但抓不到任何包」的典型症状。2.2 在 LR12 里创建 APP 录制脚本的完整步骤先装好 LR12 社区版安装路径不要带中文这个版本安装完成后会有 Virtual User Generator、Controller、Analysis 三个独立入口。社区版的 Controller 和 Analysis 因为并发限制基本用不上整个方案里只有 Virtual User Generator 是核心工具。下面是我在 64 位 Windows 7 环境里的操作步骤第一步打开 Virtual User Generator点击 Create 新建脚本时选择Web - HTTP/HTML协议不要选 Mobile 协议——后面会解释为什么。第二步点击 Record 按钮后在弹出窗口里把 Recording Mode 切换到Remote Application via LoadRunner Proxy端口填一个不冲突的四位数比如 8899。第三步把手机 Wi-Fi 代理设置为电脑的局域网 IP 和同样的端口号然后启动录制在手机上完整操作一遍 APP 的核心业务路径点 Stop 结束录制。# 验证电脑端口是否已监听Win 7 下用 netstat 命令 netstat -ano | findstr 8899 # 预期输出中出现 LISTENING 状态说明 LR12 代理已就绪第四步录制完成后的脚本会在 Vugen 里以树形结构展示每个请求先点击 Replay 跑一遍冒烟回放确认事务能否通过。第五步回放失败的话打开 Replay Log 定位报错的行多数情况下是请求了第三方统计 SDK 或推送通道这些在测试环境没有回包可以直接从脚本里删掉不影响主流程。这里有个关键点选择 Web - HTTP/HTML 协议而不是 Mobile 协议。LR12 的 Mobile 录制协议依赖模拟器或真机调试通道配置成本高且不稳定而通过代理方式录制时APP 请求本质上是 HTTP/HTTPS 报文Web 协议恰好能完整捕获并解析。我在实测中发现Mobile 协议在部分安卓机型上会出现握手失败而 Web 协议走代理反而稳定得多。2.3 录制链路中容易翻车的三个前置条件录制链路有三个前置条件任何一个不满足都会导致录制失败或脚本缺请求按重要性排序如下第一手机和电脑必须在同一局域网内且电脑的局域网防火墙对代理端口放行。操作路径是「控制面板 → Windows 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口」把 8899 加入允许列表。第二代理端口不要用 8080、8000 这类常见端口部分 APP 或系统组件会默认走 8080 而不是走代理设置一个生僻的四位数端口能避开这类冲突。第三APP 证书信任问题。如果 APP 做了 SSL Pinning证书锁定代理方式抓到的请求会被客户端直接拒绝。测试环境可以要求开发提供一份关闭 Pinning 的调试包这个问题无解。注意录制出来的脚本里数字签名或加密字段的请求体可能是乱码这类请求在 LR11 回放时也大概率失败。如果只是压测核心业务链路优先删掉如果是压测上传接口需要开发配合把加密改成可配置的测试密钥。3. 脚本整理把录制产物从「能回放」整到「能压测」3.1 清洗脚本中的杂散请求与动态参数录制完成的脚本通常包含三类请求核心业务请求、资源文件请求图片、CSS、JS、第三方 SDK 上报请求。这三类在压测场景里的地位完全不同——核心业务请求才是测试目标资源请求会在并发时制造大量无意义的流量干扰指标SDK 上报请求则因为缺少真实服务器而频繁报错。我的清洗策略是这样的先把录制日志里的 URL 列表导出来按域名或路径前缀做一次粗分类业务接口保留、静态资源直接删除、第三方域名全部剔除。删除操作在 Vugen 的 Tree View 里勾选对应节点执行 Delete 即可。动参处理是另一个重点。同一个用户操作里token、sessionId、时间戳、随机数都会变化录制脚本里的值是写死的并发回放时必然出现鉴权失败或业务校验失败。处理方式分两步第一步用 Vugen 的 Scan for Correlations 功能自动扫描动态值第二步手动把扫描结果里的关键参数特别是鉴权头里的 token替换成关联函数生成的变量。// LR 脚本中动态 token 的关联写法示例 web_reg_save_param(token_param, LBAuthorization: Bearer , RB\n, SearchHeaders, LAST);这段代码的意思是把上一个请求响应头里Authorization: Bearer到换行符之间的内容存入token_param变量后续请求的 Headers 里直接引用{token_param}。我在多个项目里验证过登录接口的 token 用这种方式关联后回放成功率能稳定在 90% 以上排除验证码拦截的情况。3.2 对加密和签名参数做全局替换如果 APP 对请求体做了整体加密比如 JSON 字段被 AES 或 RSA 包裹录制脚本里看到的就是一段密文回放时这段密文大概率已经过期或签名校验失败。这种场景下常规关联手段是不够的我会和开发确认一下加密逻辑确认能否支持「测试模式」绕过或固定密钥。常见的做法是让开发在测试环境里把加密开关关掉或者提供一个预置的协议头标记比如X-Test-Mode: 1让服务端跳过签名校验。如果这两条路都走不通还有一条退路用代码里自己算出的签名替换掉录制脚本里的签名。// 用 LR 内置加密函数重新计算签名以 MD5 为例 sprintf(sign_value, %s%s%s, app_keytest, timestamp{time}, saltsalt123); md5_hash(sign_value, sign_result); lr_save_string(sign_result, sign); web_add_header(X-Sign, {sign});这段脚本在实际项目中能解决很大一部分签名问题难点在于 MD5 前的拼接规则必须和 APP 源码里的完全一致否则就会产生「回放成功但业务失败」的假象。我会拿着这份拼接逻辑找开发对一遍确认无误后再进入压测。3.3 脚本在 LR12 录制、LR11 回放的兼容性验证LR12 录制的脚本默认保存格式是 .usr但脚本内部的事务函数、web_url、web_custom_request 等核心 API 和 LR11 是兼容的我实测验证过可以直接运行。唯一的坑在于LR12 生成的脚本里可能会引用新版本才有的函数库LR11 打开时会报「function not found」。处理对策比较直接在 LR12 里把脚本里的这些函数替换成 LR11 通用的等价函数。最常遇到的是web_cache_cleanup和web_cleanup_auto_cookies这两个函数在 LR11.0 的某些补丁包里不可用直接删掉或注释掉即可它们只负责缓存清理和 Cookie 状态维护不影响基本压测逻辑。4. 载荷与场景配置把并发数、迭代时长和思考时间调成合理值4.1 理解虚拟用户数、迭代次数和持续时间的关系LR11 的 Controller 里压测场景有三个核心旋钮很多人拧错方向就是没搞清这三者的逻辑关系虚拟用户数Vusers决定的是同一时刻的并发请求数迭代次数Iterations决定每个虚拟用户循环执行脚本的次数持续时间Duration则规定了整个压测跑多久。三者互相影响比如设定 100 个用户持续 30 分钟后系统吞吐量除了受用户数影响还受每个用户的思考时间Think Time影响——思考时间越短单用户的请求密度越高后端承受的压力也就越大。实际压测中我通常把场景配成「按持续时间跑」而不是「按迭代次数跑」因为持续模式能让负载曲线更平滑结果也更稳定。设置入口在 Controller 的 Schedule Builder 里把 Duration 设置为 15 到 30 分钟并勾选「持续直到完成」。4.2 运行时设置里有三个最值得改动的参数进入 Vugen 的 Runtime Settings 后我基本只动三个页签General里的 Think Time、Internet Protocol里的 Preferences、以及Pacing里的迭代间隔。先说 Think Time录制时 LR 会把你在 APP 里慢悠悠操作的时间差都记录成思考时间压测时如果保留这个值虚拟用户按下单按钮后可能会等上几秒钟才发下一个请求后端根本看不到压力。压测执行时我一般把思考时间设置为「忽略Ignore」让请求以最快的节奏打过去。如果你想模拟更真实的用户行为可以把思考时间压缩到录制值的 20%~50% 之间。再说Pacing这个参数控制每次迭代结束到下一次迭代开始之间的间隔。压测时我会设置成「不等待As soon as possible」除非你明确要做固定速率加压测试。最后说Internet Protocol里的Preferences这个页签里可以设置 HTTP 请求的超时时间在弱网或慢接口的压测场景里默认的 120 秒超时可能掩盖真正的响应延迟。我一般会把连接超时设置为 10 秒数据接收超时设置为 30 秒这样能更快暴露接口异常。4.3 场景加载策略从少量用户起步再逐步加压场景配置里最常见的失误是一上来就拉满 6000 个用户结果服务端直接雪崩,连错误日志都来不及记录。我的习惯是先跑一轮 10 用户的冒烟场景确认脚本回放通过率和业务成功率都正常后再按阶梯式加压50 → 200 → 500 → 1000。每个台阶维持 3 到 5 分钟观察吞吐量和错误率的变化。LR11 的 Controller 里配置阶梯加压的地方在Schedule Builder的Ramp Up区域设置好初始用户数、每步增加的用户数以及步长间隔后工具会自动生成一个负载曲线。我一般把 Ramp Up 设置为每 30 秒增加 100 个虚拟用户这样后端有充分的时间做连接池扩容和缓存预热不会因为瞬时流量过大而误报「服务不可用」。5. 执行与避坑LR11 跑并发时的 Licence、报错和结果解读5.1 安装破解与并发上限的边界LR11 的安装流程比 LR12 更敏感我遇到的第一个坑是安装路径带中文导致安装直接回滚换成纯英文路径后一次通过。第二个坑是替换 .dll 文件时操作系统自带杀毒软件把补丁文件直接隔离导致启动时报找不到 license。解决方法是安装前先把实时防护关掉替换完成后再打开并把补丁文件所在目录加入白名单。license 这块需要特别冷静地看待网上流传的「6.5W 并发」是一个理论峰值实际达到这个规模需要 License 里有足够数量的 Virtual User 授权。我在实际项目中用到的最大的并发规模是 8000超过这个量级后 LR11 Controller 本身所在机器的内存和网络连接数会成为瓶颈。CI 环境压测时Controller 机器和 Load Generator 机器最好分开部署。5.2 高频踩坑回放失败、压测白屏、请求响应全乱码我在多个项目里总结出的高频踩坑记录如下坑一LR12 录制好的脚本在 LR11 回放时 HTTP 500 或 502现象脚本在 LR12 里回放通过在 LR11 里跑到一半突然报 HTTP 500重启 Load Generator 后又恢复正常但过几分钟再报同样错误。 原因LR11 自带的 Load Generator 和 Controller 之间通过 socket 通信当并发数攀升时 Controller 和 Generator 的 TCP 连接数达到系统上限触发服务端反压。 解决在 Load Generator 所在机器上调整注册表里的 TCP 连接数限制TcpNumConnections项并确保防火墙放行了 LR 的通信端口同时把多个 Generator 做负载均衡不要把并发全部压在一台机器上。坑二压测跑完后 Analysis 报告里的响应时间呈直线上升现象平均响应时间从 50ms 一路涨到 5000ms但错误率一直是 0。 原因持续压测导致后端连接池或线程池耗尽请求在排队而没有被拒绝所以错误率为 0 但有明显的「响应时间拐点」。 解决把场景的持续时间拉长到 20 分钟以上再去观察响应时间的分位数90th/95th/99th单纯看平均值会被少量长尾拖垮建议把 95th 响应时间作为主要判定指标。坑三并发一超过 50 个就报「License 不够」——明明用的 LR11现象LR11 控制台里已经导入了 license但只要设置超过 50 个虚拟用户就报错提示 No license available。 原因Controller 默认连接到了 LR12 社区版的 Load Generator 组件而社区版 License 的硬限制就是 50 用户。 解决把压测任务的 Generator 指定到 LR11 安装目录下的bin\mdrv.exe服务或者干脆卸载 LR12 的 Controller 组件只保留 Vugen再重新指定 Generator。这是我踩过最狠的坑连着两版 PRESS 任务都栽在这里。坑四录制的 HTTPS 请求是加密乱码现象脚本里看到的核心业务请求不是正常 URL而是一串看不懂的二进制密文回放后 APP 端直接登出。 原因录制时 APP 的 SSL 层与 LR12 代理未能完成证书信任握手LR12 只能录制到加密套接字内容。 解决把 APP 的测试包切换到 HTTP 明文协议或者在手机里安装 LR12 自带的根证书录制盒里有 Import CA Certificate 入口。强烈建议压测环境用 HTTP 明文省去大半证书烦恼。5.3 如何把 Analysis 里的指标转换成有说服力的压测报告压测执行完毕后Analysis 工具会自动汇总出 Hits/Sec、Transaction Response Time、Errors 等指标。但直接把这些原始图表丢给开发或领导基本没说服力。我自己的做法是先导出 Transactions 和 Web Resources 两个页签的数据做三组关键对比第一组是「并发数 vs 吞吐量」曲线观察在哪个并发点出现瓶颈第二组是「并发数 vs 响应时间 95th 分位」曲线找出性能拐点第三组是「错误率 vs 时间」曲线确认压测全程没有阶段性的抖动。// 导出后按时间戳对齐的示例指标数据真实数据脱敏 时间,虚拟用户数,吞吐量(byte/s),平均响应时间(ms),95th响应时间(ms),错误率(%) 00:00,50,1024,82,120,0.0 05:00,200,4096,150,360,0.2 10:00,500,5200,880,2400,1.8把这三组数据整理成表格后报告的结论自然就出来了哪个接口是瓶颈、系统能支持多少并发、最大吞吐是多少。比粘贴一张原始趋势图直观得多。6. 两个高阶技巧把 LR 这套组合方案用得更顺手6.1 用参数化文件模拟多用户真实负载录制脚本里如果存在用户维度的数据比如每个用户有自己的订单号和收货地址直接并发时会因为数据冲突产生大量业务失败。解决思路是准备一个 CSV 参数文件让每个虚拟用户从文件里读取自己的凭证同一用户的数据在整个压测过程中保持一致。// 参数化文件 parm_user.csv 的内容格式 user_id,token u1001,a1b2c3 u1002,d4e5f6 u1003,g7h8i9 // 脚本中的引用方式 web_add_header(Authorization, Bearer {token}); web_url(order, URLhttp://api.test.internal/order/{user_id}, TargetFrame, Resource0, LAST);参数化文件里放多少行数据决定了虚拟用户最多有多少个「独立身份」。压测 5000 并发时如果只准备了 100 个用户文件LR 会在第 11 轮迭代开始循环使用 u1001 的数据订单号就会冲突。因此参数文件行数最好大于用户数否则就得在测试环境里允许重复下单。6.2 脚本回放率与事务成功率的双重验证脚本可以回放不代表压测结果可信——这是我在某个图像处理 Demo 的压测里学到的最深刻的一课。当时脚本回放成功率 100%但压测报告里事务成功率只有 40%原因是脚本虽然发出请求了但业务逻辑并没有真正跑通比如下单流程因为库存不足而失败但 HTTP 层面返回仍然是 200。从那以后我每次压测前都强制走一遍「双率验证」先在单用户回放时检查响应体里的业务状态码不是 HTTP 状态码确认 Error Code 为成功再用 10 并发的小场景压 5 分钟观测事务成功率是否稳定在 95% 以上全部通过后才进入正式压测。现在的 LR11 脚本里我会在事务块后插入校验逻辑lr_start_transaction(下单事务); web_reg_save_param(resp_code, LB\code\:\, RB\, SearchBody, LAST); web_url(create_order, URLhttp://api.test.internal/create_order, LAST); if (strcmp(lr_eval_string({resp_code}), 0) 0) { lr_end_transaction(下单事务, LR_PASS); } else { lr_end_transaction(下单事务, LR_FAIL); }这段脚本是给事务判定装的「照妖镜」——只有业务响应码为 0 的事务才算通过HTTP 200 但业务失败的事务会被如实标记为失败。压测执行过程中我还会打开 Controller 的 Online Monitor实时盯着事务成功率的曲线一旦跌到阈值以下就立即调低并发数而不是等压测结束再去翻报告。这套「LR12 录制 LR11 压测」的组合方案是我在资源有限的项目里最常用的一条捷径它绕过了 LR12 商业许可的高昂价格也避开了 LR11 无法录制移动端脚本的硬伤。唯一的代价是两次脚本微调一次是清洗录制产物里的第三方请求另一次是处理 LR11 不兼容的新函数。只要把这些步骤按上面说的顺序走通再用参数化和事务校验把脚本加固一遍后端服务在 2W 并发以下的表现基本都能摸到底。希望帮到你。本文还有配套的精品资源点击获取