干了十年性能测试，用LoadRunner踩过的坑，比写过的脚本还多。这份避坑手册是我从无数个不眠夜里提炼出来的，希望能帮你绕过那些最要命的陷阱。

脚本开发：

脚本是性能测试的基础，很多问题都源于此。

坑一：协议选错，万事皆休：LoadRunner支持上百种协议。对于B/S架构系统，选错协议（如用Web(HTTP/HTML)去录Socket应用）会导致脚本无法录制或回放失败。对策：开始前必须和开发确定系统使用的应用层协议，这是脚本开发的第一步。

坑二：脚本 = 录制 + 回放：这是最常见的误解。录制的脚本是“死”的，包含大量硬编码的固定值。对策：将脚本视为程序去开发。必须进行参数化（Parameterization）和关联（Correlation）。

坑三：关联失效，脚本秒变“一次性”：Session ID、Token等动态数据如果不处理，回放必然失败。对策：

第一选择VuGen的自动关联功能扫描。

自动关联失效时，手动编写函数（如 web_reg_save_param_ex）提取动态数据。

对于加密的动态参数，需和开发沟通加密思路，在脚本中模拟。

坑四：乱码问题，数据全乱：回放时中文乱码，导致请求或证实失败。对策：

在录制和回放设置中，统一脚本和服务器的字符集（如UTF-8）。

可用 lr_convert_string_encoding 函数在脚本中进行编码转换。

坑五：不设检查点：只要不报错，就认为业务成功，这是致命的。对策：在重点业务步骤后插入检查点（Checkpoint），测试服务器返回的特定内容或状态码，保证业务真正成功。

场景设计和执行：

场景设计决定了压力能否真实、可控地施加到系统上。

坑六：盲目追求用户数，压测机先垮：虚拟用户数超过负载机承受能力，导致初始化失败、大量错误。对策：按照 “测算-小试-中试-全量” 原则，逐步加压，同时监控负载机资源，保证其CPU、内存等不成为短板。

坑七：单账号并发，数据思路冲突：用单一账号模拟大量并发，极易触发业务思路限制（如登录互斥）或数据冲突，导致大量失败。对策：准备充足的测试数据池，为每个虚拟用户分配不同账号。测试前必须重置数据到已知状态。

坑八：Think Time为0，压力失真：思考时间 模拟了真实用户的操作间隔，完全去掉会使压力超过实际。对策：录制时保留思考时间，或用 lr_think_time() 函数插入符合业务场景的、带随机区间的思考时间。

坑九：场景配置错误，调度全乱：集合点、 ramp-up/down 时间设置错误，导致压力释放不符合预期。对策：仔细设计负载模型，确定用户增长方式、峰值不断时间等。执行前多次检查场景配置。

环境和监控：

没有有效的监控，性能测试就失去了方向。

坑十：权限不足，监控盲人摸象：因权限或防火墙问题，无法监控服务器重点标准。对策：测试前和运维团队确定监控方案，开通所需权限和端口，保证能获取CPU、内存、磁盘I/O、网络及数据库等数据。

坑十一：只盯平均响应时间：平均值会掩盖长尾问题。对策：重点重视 90/95/99分位响应时间，这更能反映绝大多数用户的真实体验。

坑十二：测试环境和生产不一致：硬件、网络、软件配置的差别会导致结果无法反映生产真实情况。对策：尽量保证测试环境和生产环境架构一致。如无法完全一致，需对差别进行分析和考虑。

结果分析：

坑十三：孤立看标准，误判短板：单看TPS或响应时间很容易误判。对策：关联分析。将响应时间、TPS、吞吐量和服务器资源利用率等标准放在一起看。如，TPS下降伴随CPU飙升，大概率是计算短板。

坑十四：结果波动，归因系统不稳：波动可能源于网络抖动、其他程序抢占资源，甚至是脚本自身问题。对策：控制变量，多轮测试。在相对稳定、独立的环境中进行多轮测试，对比结果，排除偶然原因。

建议

安装部署：安装途径不要有中文或空格；关闭杀毒软件，防止误拦截；使用管理员权限运行。

日常维护：定期清理负载机的临时文件和日志；测试前清空浏览器缓存。

性能测试不是会用工具，而是理解业务、设计场景、分析数据。