简介：这份资源面向移动端性能测试工程师与后端开发人员，聚焦APP后台服务器的压力测试场景，解决LoadRunner无法直接录制手机APP脚本的痛点。核心思路是借助LoadRunner12的代理录制能力抓取APP请求，再将调试好的脚本放到LoadRunner11上执行，从而利用其免费license实现最高6.5万并发，兼顾脚本录制与高并发压测两方面需求。资源包内为1个docx文档，约691KB，内容涵盖LoadRunner简介、安装手册与完整使用教程，包括代理设置、脚本录制、回放调试、错误行处理以及LR11安装破解与脚本执行等关键环节，并配有操作截图辅助理解。目前已有555人学习下载，适合希望低成本搭建APP压测环境、快速掌握脚本录制与并发执行流程的测试人员参考。
1. 拆开一套「12 录制 + 11 压测」的 APP 后端压测组合拳
移动端后端压测最尴尬的地方在于：脚本录制和并发执行往往被拆在两个工具里。LoadRunner12 能通过代理抓取手机 APP 的真实 HTTP 请求，但社区版只给 50 个并发，跑不出有参考价值的曲线；LoadRunner11 有免费的超大 license，6.5 万并发随便压，可它偏偏不支持手机 APP 的脚本录制。这套资源的核心思路就是取长补短——用 12 录脚本，把脚本拿到 11 上跑。听起来像绕路，实际是当前成本最低、落地最快的一条路。适合手里有 APP 后端接口、需要做并发验证又不想掏 license 钱的测试和运维同学。下面按「录制 → 迁移 → 压测 → 排错」的顺序拆一遍，参数和坑都标清楚。
2. 录制端环境搭建：代理、端口与脚本生成
2.1 为什么选 LoadRunner12 社区版做录制
LoadRunner12 相比 11 最大的变化是加入了移动端协议支持，能识别手机 APP 发出的 HTTP/HTTPS 请求。社区版虽然并发被锁在 50，但录制功能没有阉割，脚本生成质量跟商业版一致。这就意味着你可以把它当成一个「免费的脚本采集器」来用，压测执行交给 11。
安装前有两个硬性条件必须满足：一是系统选 Win7 64 位，二是安装路径不能带中文。这两条不是建议，是硬门槛。中文路径会导致部分组件注册失败，装完打开 VuGen 直接报错。安装过程本身没什么好说的，一路下一步，装完桌面会出现三个图标——Virtual User Generator（录制脚本）、Controller（执行压测）、Analysis（结果分析）。社区版只用得上第一个。
2.2 手机代理配置与录制参数
录制原理是 LoadRunner12 在本机起一个代理服务，手机通过 Wi-Fi 连到同一网段后，把 HTTP 代理指向这台电脑，所有请求就会经过 VuGen 被记录下来。
具体操作分三步：
第一步，在录制用的电脑上开一个 Wi-Fi 热点，让手机连上来，确保手机和电脑在同一局域网。记下电脑的 IP，后面代理要填。
第二步，手机 Wi-Fi 设置里找到代理选项，改为手动，主机名填电脑 IP，端口填一个四位数（比如 8899）。端口不要选 80、443 这类常用端口，避免冲突。
第三步，打开 VuGen，新建脚本时协议选「Web-HTTP/HTML」，然后点录制按钮。录制模式选「Remote Application via LoadRunner Proxy」，端口填手机上设的那个 8899，点开始录制。
# 录制前的网络连通性自检（在录制电脑上执行） # 确认手机能 ping 通电脑 ping 192.168.0.103 # 确认代理端口没有被占用 netstat -ano | findstr 8899 # 如果端口被占用，换一个端口，比如 8898这里的关键参数是代理端口，它必须和手机端填的完全一致，差一位都录不到包。录制模式选 Remote Application 而不是默认的本地模式，是因为请求来源是手机而不是本机浏览器。
2.3 录制后的脚本清理
录制完成后 VuGen 会生成一份脚本，点回放按钮跑一遍。大概率会报错，这很正常。报错的行基本是调用第三方插件或外部资源的请求，比如统计 SDK、广告接口、推送服务，这些在脱离 APP 环境后无法执行。
处理原则很简单：找到报错行，直接注释或删除，只要不影响主业务流程的请求链路就行。判断标准是看这行请求的 URL 是不是你后端服务器的域名，不是就删。删完再回放一次，直到脚本能完整跑通主流程。
提示：录制时尽量只操作核心业务路径，比如登录 → 浏览列表 → 下单 → 支付，不要把所有页面都点一遍。脚本越长，后期参数化和关联的工作量越大。
3. 脚本迁移到 LoadRunner11：兼容性处理与参数化
3.1 跨版本脚本兼容的底层逻辑
LoadRunner12 和 11 的脚本底层都是基于 C 语言的 VuGen 脚本结构，核心的 web_url、web_submit_data 等函数在两个版本间是通用的。12 录制出来的脚本之所以能拿到 11 上跑，就是因为这些基础函数没有变。差异主要出现在少数新版本才支持的函数和头文件引用上，迁移时把不兼容的部分替换掉即可。
迁移操作就是把 12 生成的脚本目录整个拷贝到装了 LoadRunner11 的机器上，用 11 的 VuGen 打开。打开时如果提示脚本版本不匹配，选择继续打开就行，VuGen 会自动做一次格式转换。
3.2 参数化：让脚本从「单次回放」变成「并发压测」
录制出来的脚本是死的，每次请求都发同样的数据。压测时必须做参数化，否则所有虚拟用户发一模一样的数据，后端缓存一命中，压测结果就失真了。
参数化的核心是把请求里的用户凭证、订单号、搜索关键词等替换成变量。在 VuGen 里选中要参数化的值，右键选择「Replace with a Parameter」，新建一个参数名，然后配置数据源。
// 参数化前的登录请求 web_submit_data("login", "Action=http://api.example.com/login", "Method=POST", ITEMDATA, "Name=username", "Value=testuser001", ENDITEM, "Name=password", "Value=Pass123456", ENDITEM, LAST); // 参数化后的登录请求 web_submit_data("login", "Action=http://api.example.com/login", "Method=POST", ITEMDATA, "Name=username", "Value={username}", ENDITEM, "Name=password", "Value={password}", ENDITEM, LAST);参数 {username} 和 {password} 的数据源可以是一份 CSV 文件，里面放几百组测试账号。在参数属性里设置「Select next row」为 Sequential 或 Random，「Update value on」为 Each iteration，这样每个虚拟用户每次迭代都会取不同的账号。
3.3 关联：处理动态 token 和 session
APP 后端接口通常会在登录后返回一个 token，后续请求都要带上这个 token。录制时 token 是写死的，压测时每个用户的 token 都不一样，必须做关联——把服务器返回的动态值提取出来，存成变量，在后续请求里引用。
// 从登录响应中提取 token web_reg_save_param("auth_token", "LB=\"token\":\"", "RB=\"", "Search=Body", LAST); // 后续请求中引用提取到的 token web_add_header("Authorization", "Bearer {auth_token}");web_reg_save_param 必须写在产生该响应的请求之前，这是 VuGen 的注册机制决定的。LB 和 RB 是左右边界，要跟实际响应报文完全匹配，差一个字符就提取不到。提取失败时脚本不会报错，但后续请求会因为 token 为空而返回 401，这种问题排查起来很费时间，建议每次改完关联都单独回放验证一次。
4. 压测执行与场景设计：并发、持续时间和监控
4.1 Controller 场景配置
脚本调通后，打开 LoadRunner11 的 Controller，把脚本加载进来，开始设计压测场景。场景设计主要定三个参数：虚拟用户数、加压方式、持续时间。
虚拟用户数根据后端服务器的承载预期来定，第一次压测建议从 50 或 100 起步，观察系统表现后再逐步往上加。加压方式选「Gradual」渐进式，比如每 15 秒增加 10 个用户，这样能看到系统在不同负载下的响应曲线，而不是一上来就被打满。
持续时间一般设 10 到 30 分钟。太短了系统还没进入稳定状态就结束了，太长了浪费资源。如果要做稳定性测试，可以拉到 1 到 2 小时。
# Controller 场景关键参数参考 # 初始用户数：10 # 每 15 秒增加：10 个用户 # 最大用户数：200 # 持续时间：15 分钟 # 停止方式：每 15 秒停止 10 个用户4.2 压测期间要盯的指标
压测跑起来后，不能只看最后的结果报告，过程中要实时盯几个关键指标。Controller 自带的监控面板能看到 TPS、响应时间、错误率，但这些还不够，后端服务器的 CPU、内存、数据库连接数、慢查询也要同步看。
常见做法是在压测机上开一个终端跑 top 或 nmon，同时让 DBA 那边盯着数据库的活跃连接和慢日志。压测出问题往往不是 LoadRunner 本身的问题，而是后端某个环节先扛不住了。
| 监控项 | 正常范围 | 异常信号 |
|---|---|---|
| TPS | 随并发上升后趋于平稳 | 上升到某点后骤降 |
| 平均响应时间 | 200ms 以内 | 超过 1s 且持续上升 |
| 错误率 | 低于 0.1% | 超过 1% |
| 服务器 CPU | 低于 70% | 持续 90% 以上 |
| 数据库连接数 | 低于最大连接数的 80% | 接近或达到上限 |
4.3 结果分析：从 Analysis 报告里找瓶颈
压测结束后用 Analysis 打开结果文件，重点看三张图：TPS 趋势图、响应时间分布图、错误率趋势图。TPS 曲线如果在某个并发点开始走平甚至下降，说明系统达到了处理上限。响应时间分布图能看出是大部分请求都慢，还是少数请求拖了后腿。
有个容易被忽略的点：Analysis 里的响应时间包含了网络传输时间。如果压测机和被测服务器不在同一机房，网络延迟会混进结果里。判断方法是看最小响应时间，如果最小值都有几十毫秒，那基本是网络开销，不是后端处理慢。
5. 避坑与排查：录制、迁移、压测中的常见翻车点
5.1 录制时抓不到包
现象：手机操作了 APP，但 VuGen 里没有任何请求记录。
原因通常有三个：手机代理没设对、端口被防火墙拦了、APP 走了 HTTPS 但证书没装。先检查手机代理的 IP 和端口是否和 VuGen 里填的一致，再确认录制电脑的防火墙有没有放行该端口。如果是 HTTPS 请求，需要在手机上安装 LoadRunner 的代理证书，否则请求内容会被加密，VuGen 只能看到 CONNECT 请求而看不到具体报文。
5.2 脚本迁移后回放报「函数未定义」
现象：12 录的脚本在 11 里打开，回放时报某个函数找不到。
原因是 12 的脚本里可能引用了新版本才有的函数或头文件。解决办法是找到报错的那行，查一下这个函数在 11 里有没有替代写法。大部分情况下是 web_add_header 或 web_reg_save_param 的参数格式差异，把多出来的参数删掉就能兼容。如果实在找不到替代，就把那行注释掉，看是否影响主流程。
5.3 压测时错误率飙升但服务器指标正常
现象：Controller 里错误率超过 10%，但后端 CPU、内存、数据库都很闲。
这种情况大概率是脚本本身的问题，不是服务器扛不住。常见原因是参数化数据不够，几百个虚拟用户循环取几十组账号，导致大量请求因为账号重复被服务端拒绝。另一个可能是关联没做好，token 过期后没有重新获取，后续请求全部 401。排查方法是把虚拟用户降到 1 个，单独回放脚本，看是否报错。
5.4 并发上不去，TPS 卡在某个值
现象：虚拟用户数加到 500，但 TPS 和 100 用户时差不多。
先确认 LoadRunner 的 license 是否支持这么多并发。LoadRunner11 的免费 license 虽然标称 6.5 万，但实际部署时受机器性能和网络带宽限制。压测机本身的 CPU 和内存如果不够，生成不了那么多并发请求。另外检查一下脚本里是否有 think time，如果每个请求之间等了 5 秒，那并发数再高 TPS 也上不去。在 Controller 里把 think time 忽略掉再跑一次对比。
5.5 压测结果波动大，每次跑都不一样
现象：同样的脚本和场景，两次压测的 TPS 差了一倍。
压测结果受环境影响很大。如果压测机和被测服务器之间有其他流量，或者数据库同时在跑其他任务，结果就会不稳定。建议压测前确认环境干净，关掉不必要的后台任务。另外，第一次压测往往受缓存影响偏乐观，第二次才是真实水平。我一般会连续跑三次，取后两次的平均值作为参考。
6. 把脚本跑稳的几个进阶习惯
脚本调通只是第一步，真正让压测结果可信的是后面这些细节。第一个习惯是给脚本加检查点。不要只看 HTTP 返回码是不是 200，很多接口出错时也返回 200，但响应体里是错误信息。在关键请求后面加 web_reg_find 检查特定字符串，找不到就标记失败，这样错误率才真实。
// 在登录请求后加检查点，确认返回了 token web_reg_find("Text=\"token\"", "SaveCount=token_found", LAST); // 后续判断 if (atoi(lr_eval_string("{token_found}")) == 0) { lr_error_message("登录失败，未返回 token"); lr_exit(LR_EXIT_ITERATION_AND_CONTINUE, LR_FAIL); }第二个习惯是分阶段加压。不要一上来就 500 并发，先跑 50 看基线，再跑 100 看线性度，再跑 200 看拐点。每次只改一个变量，这样才能定位到瓶颈出现在哪个量级。
第三个习惯是记录每次压测的完整参数。脚本版本、并发数、持续时间、参数化数据量、后端服务版本，这些都要记下来。不然过两周回头看结果，根本想不起来当时的环境是什么样。
第四个习惯是压测完立刻导出 Analysis 报告并备份原始结果文件。LoadRunner 的结果文件很大，但删了就真没了。我吃过一次亏，压测跑完觉得结果不理想，想调整参数重跑，结果把原始结果覆盖了，后来想对比都找不到基准。
最后一个习惯是关于 think time 的。真实用户操作 APP 时，每个请求之间是有间隔的，但压测时如果保留这个间隔，并发数就要设得很大才能压出效果。我的做法是压测时把 think time 设为 0，先测出系统的极限处理能力，然后再按真实用户行为模型折算需要的并发数。这样既能摸到天花板，又能推算出实际部署需要多少资源。
从那以后我每次做压测，都会先把脚本在单用户下跑通、加好检查点、确认参数化和关联都生效，再开始上并发。这个顺序反过来做，后面全是坑。希望帮到你。
本文还有配套的精品资源，点击获取
