LoadRunner命令行怎么启动场景，LoadRunner在Jenkins里怎么自动运行，核心是把场景运行、结果落盘、日志留痕三件事一次固定。
一、LoadRunner命令行怎么启动场景
命令行跑场景时先把环境口径对齐，再选wlrun或CLIControllerApp.exe执行，最后把结果目录与输出日志一起归档，避免跑完无结果或结果不可复现。
1、先把运行环境做成可被脚本稳定调用的状态
（1）把.lrs场景与脚本放到命令执行机可直读的路径，尽量用本机磁盘短路径，减少网络盘拷贝不全与权限失败
（2）确认执行账号与手工打开Controller一致，尤其是访问脚本路径、写结果目录、连接负载机所需权限
（3）提前规划结果输出目录，按日期与轮次分文件夹，保证并发或多次回归不会互相覆盖
2、用wlrun跑现成.lrs，先把最小闭环跑通
（1）核心口径是让wlrun能定位到场景文件，并在启动后真正触发运行
（2）把结果路径用-ResultName写死到固定目录，避免结果落到默认位置导致找不到或被清理
（3）需要无人值守时可启用静默相关参数，必要时再加自动分析，让结果生成与分析动作串成一条线
3、用CLIControllerApp.exe把运行、汇总、分析拆成可控步骤
（1）用-TestPath指向.lrs场景，用-Run触发执行；需要跑完自动汇总或分析时改用-Collate或-CollateAndAnalyze
（2）跨环境替换负载机清单时，优先用-OverrideLgs外置负载机列表，避免改动场景文件本体带来版本漂移
（3）同样把-ResultName固定为可归档路径，保证Jenkins或人工都能按路径定位同一轮结果
4、把日志与结果一起保存，后续定位更快
（1）命令行输出建议重定向到独立日志文件，并与结果目录同名存放，便于按时间点对齐故障
（2）遇到负载机连不上、脚本失败、写盘失败时，先看日志时间线，再回到网络与权限层定位，不要直接重跑
二、LoadRunner在Jenkins里怎么自动运行
把LoadRunner接入Jenkins时，先解决跑在哪台机器、结果落哪、用什么规则判定失败，再决定走插件执行还是命令行执行，两条路线都能稳定落地。
1、先固定执行节点与安装口径，避免任务被调度到错误机器
（1）在Jenkins创建专用agent节点并打标签，确保压测任务只在装了Controller与工具链的节点运行
（2）agent节点用具备管理员权限的账号登录，避免访问脚本路径、写结果目录或调用组件时权限不足
（3）把结果目录放在workspace之外的固定盘符路径，并按Job名与Build号分层，避免工作区清理把结果带走
2、插件路线更省心，命令行路线更通用
（1）若环境允许，可用Application Automation Tools一类插件在构建步骤里直接执行Controller场景，并把报告状态回写到构建结果
（2）若插件受版本或权限限制，用构建步骤调用wlrun或CLIControllerApp.exe同样可跑，关键是把场景路径与-ResultName标准化
（3）构建后动作用归档制品保存结果目录与日志，必要时再同步到制品库或共享目录，保证历史可追溯
3、把SLA做成门禁，自动化才有意义
（1）在场景里给关键事务配置响应时间与错误率阈值，并保持事务命名稳定，避免阈值对不上
（2）让SLA失败直接映射为构建失败，超阈值就阻断发布，而不是靠人工翻图表决定
（3）对环境抖动可设置基线与白名单规则，但要留下备注与依据，避免门禁失真
三、LoadRunner结果归档怎么统一LoadRunner流水线失败怎么快速定位
把结果目录结构、归档范围与排障顺序固定下来，才能让每次压测都像回归测试一样可对比、可复盘、可追责。
1、统一结果目录结构与命名规则
（1）结果目录包含场景名、环境、Build号与轮次，任何人看到路径就能定位是哪一次运行
（2）结果目录与命令行日志必须成对归档，保证图表、摘要与故障证据在同一处
2、把失败定位做成对照法
（1）先对照成功与失败构建的场景参数、负载机数量、网络域与应用版本差异，再判断是环境还是应用回归
（2）按顺序排查连通与权限、脚本错误、应用错误码与资源瓶颈，避免一上来就重跑浪费窗口期
3、把复用做成基线
（1）把命令行参数口径、负载机清单、结果目录规则与SLA阈值写进团队基线，新人照做就能跑出同口径结果
总结
LoadRunner命令行怎么启动场景，LoadRunner在Jenkins里怎么自动运行，先把场景运行、结果落盘、日志留痕做成可复现闭环，再在Jenkins里固定执行节点、结果归档与SLA门禁，压测才能稳定进入持续集成节奏并具备自动判定与快速定位能力。
