简介这份以LoadRunner为核心的负载测试实验报告源自教务管理系统的真实压测实践适合软件测试初学者、高校计算机专业学生及需要开展性能测试的工程师阅读。报告完整呈现了从实验规划、脚本录制、场景定义、运行监控到结果分析的闭环流程并结合25个并发用户触发错误的具体实例说明平均事务响应时间、吞吐量等关键指标的分析方法。预览可见嘉应学院实验报告的原始版式实验环境、操作步骤、结果数据与总结均清晰保留便于对照复现。资源包共1个docx文档大小1.52MB下载后可编辑使用已有97人学习浏览可用于课程实验参考、期末报告模板或性能测试入门讲义。总体内容聚焦工具应用与测试数据呈现能帮助读者掌握负载测试报告的标准写法与常见问题排查思路。1. 为什么 25 个并发用户就能让教务系统出错误负载测试最常被误解的一句话是把工具打开录个脚本设个 1000 并发跑起来看结果。这个思路在真实项目里几乎必然翻车——不是工具不会用而是压力和被测系统之间隔着一层「脚本是否真实、负载模型是否合理」的过滤网。这次用 LoadRunner 对某教务管理系统做负载测试是一个足够典型的样本录制登录流程、在 Controller 里搭场景、逐步加压到 25 个 Vuser 时系统开始报错最终用 Analysis 定位瓶颈。整个过程覆盖了 Vuser 脚本准备、负载生成、实时监控、结果分析四个环节适合刚接触性能测试的 QA也适合想搞明白脚本录制和场景调度之间关系的开发。下面把每一步的选型理由和参数逻辑拆开讲。2. 从录制到可控脚本VuGen 中的协议选择、事务与关联参数2.1 协议选择与录制模式为什么是 Web (HTTP/HTML)VuGen 新建脚本时弹出的第一个选择框就是协议。教务管理系统是典型 B/S 架构浏览器通过 HTTP 与中间件交互所以选 Web (HTTP/HTML) 而不是 Web Services。很多人在这一步直接点确定但录制模式会影响脚本质量和回放稳定性。VuGen 提供两种录制模式HTML-based 模式把页面请求聚合成业务步骤脚本可读性好适合登录、查询这类页面跳转明显的流程URL-based 模式逐条记录浏览器发出的每一个 HTTP 请求不遗漏 Ajax、异步加载和图片请求更接近真实流量但脚本冗长。教务系统的登录页有静态资源加载和简单动态校验HTML 模式录出来的脚本干净回放时容易定位问题如果被测系统是重前端应用HTML 模式经常会漏掉关键请求那就切到 URL-based 再录一次。录制模式脚本粒度适用场景主要缺陷HTML-based按业务步骤聚合 URL页面跳转清晰的传统 Web 应用可能遗漏异步请求URL-based逐条记录 HTTP 请求Ajax/SPA/异步加载密集的应用脚本长调试成本高补充一点录制过程中 VuGen 启动内置浏览器录完生成的脚本带web_url、web_submit_data等 API模拟的是浏览器行为而不是单纯 socket 发包Cookie 维护和响应处理由引擎自动完成。2.2 事务边界、思考时间与关联参数录完的脚本只是把操作回放了一遍还不能直接放进场景加压因为它缺少事务边界、符合真实节奏的思考时间、动态参数处理。登录流程明确直接在登录动作前后加上事务标记就能量化这一操作的时间消耗。// 标记登录事务事务名会在 Analysis 中作为独立曲线出现 lr_start_transaction(login); // 注册关联函数从上一个页面的响应体里提取 session 值 web_reg_save_param(sessionId, LBname\session\ value\, RB\, SearchBody, LAST); // 模拟真实用户在页面上的停留时间8 秒取自录制时的实际操作节奏 lr_think_time(8); // 提交登录表单username/password 使用参数化变量 web_submit_data(login.do, Actionhttp://SERVER_IP:8080/login.do, MethodPOST, RecContentTypetext/html, Refererhttp://SERVER_IP:8080/index.htm, ModeHTML, ITEMDATA, Nameusername, Value{VuserID}, ENDITEM, Namepassword, Value{VuserPwd}, ENDITEM, Namesession, Value{sessionId}, ENDITEM, LAST); // 结束事务LR_AUTO 在请求返回后自动判断 PASS 或 FAIL lr_end_transaction(login, LR_AUTO);这段脚本的动作顺序是先开启事务再注册关联函数然后停 8 秒模拟思考时间最后提交表单并结束事务。关键在web_reg_save_param它本身不发送请求而是在下一个 URL 请求完成后从返回内容中按左右边界提取动态值。教务系统的登录页会在隐藏域或 Cookie 里种一个 session 标识如果直接用录制时的固定值回放服务器会认为会话非法回放结果看着是“通过了”实际事务成功率很低。LB和RB是提取内容的左右边界具体写法取决于响应体实际格式需要先开日志看一次真实返回SearchBody指只搜索响应体能减少匹配开销{sessionId}是提取后存放的参数名在后续请求中用花括号引用。另一个关键是参数化。用户名和密码不要用固定的11111和123在 VuGen 参数属性里创建一个 .dat 文件填入若干组有效账号VuserID和VuserPwd按行读取。这样 25 个 Vuser 各自使用不同账号登录避免服务器把同一账号的反复登录当成异常流量也更接近真实用户分布。2.3 脚本回放验证迭代、日志与结果确认脚本改完不要直接进 Controller先单独回放验证功能。这里有几个实际操作要点迭代次数先设 1。在 Run-Time Settings 的 Pacing 里把 Iteration Count 改为 1避免回放时反复执行造成数据污染。日志级别开到 Extended 参数替换。Run-Time Settings → Log → Extended log勾选 Parameter substitution 和 Server response回放日志里能看到{sessionId}是否被替换成实际值。加一个验证点确认登录成功避免“假通过”。// 在登录后加验证断言响应中包含欢迎页关键字 web_reg_find(Text欢迎张三, SearchBody, FailNotFound, LAST);回放结束后看 Replay Summary 里 Passed 和 Failed 的数量。如果脚本显示通过但验证点没触发FailNotFound会把该迭代标记为失败这样能拦下一类典型问题服务器返回了错误页但没有验证点时 LR 只按 HTTP 200 码判断成功。这个习惯在加压场景里非常关键否则 25 个 Vuser 跑完Analysis 统计出的平均事务响应时间可能是错的因为错误事务根本没被识别。3. Controller 场景构建Vuser 数量规划、Load Generator 与调度策略3.1 场景类型选择手动场景与面向目标场景Controller 打开后默认弹出新建场景对话框两个入口需要区分手动场景Manual Scenario由你指定 Vuser 总数、加载策略、持续时间适合“验证系统在 N 个并发下的表现”这一类问题面向目标场景Goal-Oriented Scenario则相反你定义一个性能基准比如每秒完成的事务数或响应时间上限Controller 自动增加 Vuser 去逼近目标适合容量规划。这次实验的目的是验证教务系统在多少人并发时开始劣化控制变量在并发数本身所以用手动场景。场景设计的第一步不是填 Vuser 数量而是先明确测试目标。性能测试新手常犯的错是“先压再看”还没确定预期响应时间先把几百个 Vuser 丢上去。负载测试开始前必须有一个可量化的基线登录动作要求 90% 响应时间小于 3 秒25 个并发以上系统不应出错。有了基线测试结果才有判定依据。3.2 Load Generator 连接与 Agent 进程机制场景里默认的 Load Generator 是 localhost状态显示为“关闭”这正是没连上 agent 的表现。LoadRunner 架构里Controller 负责调度Vuser 的执行由 Load Generator 上的 agent 进程承接。Controller 把脚本传输给 agentagent 建立 Vuser 进程模拟用户行为所以跑场景前必须把 Load Generator 状态从“关闭”改成“就绪”。连接前先确认 agent 进程在运行。在 Unix/Linux 发压机上进程名通常是 m_agent_daemonWindows 上对应一个后台服务。检查命令# 查看 agent 守护进程是否存在 ps -ef | grep m_agent_daemon # 查看 agent 监听端口是否开放不同版本端口不同用 ss 确认 ss -tnl | grep -E :(443|50500)\sps确认进程是否被启动ss确认端口监听是否正常。部分环境里 agent 服务崩溃但进程还在ss那条命令就能暴露问题。如果端口是空的检查安全组或防火墙是否放行再在 Controller 的 Load Generators 窗口选中 localhost点 Connect状态变为“就绪”即表示通道建立成功Vuser 配置完成后 Controller 会通过这个通道把脚本分发给 agent。3.3 Ramp-up、Pacing 与负载模型设计本次场景的核心参数是 25 个并发用户但 25 个 Vuser 同时启动会产生一个短暂流量尖峰系统可能在启动瞬间被判为失败。实际项目里建议用 Ramp-up 逐步加负载每 30 秒加载 5 个 Vuser在第 2 分半钟左右达到 25 个 Vuser 的稳态。这样做可以先把 Vuser 逐个跑起来观察每个加载批次是否都能完成任务同时减小启动瞬间对系统的冲击测量结果更接近真实的渐进增长场景。负载模型还要考虑 Pacing 和 Think Time。Pacing 是两次迭代之间的间隔决定单个 Vuser 单位时间内的请求频率Think Time 是用户在页面上的真实停留时间已在脚本里用lr_think_time体现。场景级调度参数优先于脚本中的 Run-Time Settings参数推荐配置作用Ramp-up 方式每 30 秒加载 5 个 Vuser分批次建立并发避免瞬时冲击Duration10 分钟让稳定期的测量数据足够多加载后运行策略持续运行直到完成保证稳态区间完整Pacing迭代间隔 10 秒控制单个 Vuser 的请求频率Think Time 策略使用脚本中的思考时间保持真实用户操作节奏场景启动后Vuser 状态栏会依次出现“正在初始化”“就绪”“运行中”“完成”几个阶段。运行中的 Vuser 数量不等于配置的总数Ramp-up 阶段会小于总数等全部人进入“运行中”后才算稳态。4. 负载执行与实时监控从 Vuser 状态到错误码定位4.1 场景启动后监控面板怎么读点击“开始场景”后Controller 自动切到运行模式。左侧是 Vuser 状态图和事务响应时间图右侧是运行中的 Vuser 日志。面板的读取顺序建议固定先看事务失败数再看 Vuser 状态分布最后看错误详情直接盯平均响应时间容易漏掉已经出现的事务失败。实验过程中最值得注意的现象是“当 Vuser 达到 25 时出现错误”。这说明瓶颈不是脚本本身——脚本如果配置错误Vuser 加载到第 2 个或第 3 个就会出现问题而不是等到 25 个才出错。这个现象本身传递了一个信息25 个并发是教务管理系统在处理登录请求时的经验阈值超过这个值触发了服务器端的连接或资源限制。此时要做的不是继续加压而是去确认错误是“连不上”还是“响应慢”。4.2 错误码对照与 Vuser 日志查看LoadRunner 的错误码信息量很大常见几类错误码含义大概率原因-27796Failed to connect to server服务器拒绝新建连接连接数被耗尽-27791超时未收到服务器响应请求排队超时服务端处理不过来-35040Connection reset by peer服务器主动断开常见于防火墙或应用池回收-27492响应头匹配失败关联函数边界与实际响应不符拿到错误码后不要只看 Controller 主窗口提示要翻 Vuser 日志。每个 Vuser 在场景运行目录下有自己的日志文件Controller 最常见部署在 Windows用 PowerShell 遍历# 遍历场景结果目录查找包含 Error 的 Vuser 日志 Get-ChildItem -Recurse -Filter *.log | Select-String -Pattern ErrorGet-ChildItem -Recurse递归查找场景目录Select-String相当于 Linux 的grep输出包含 “Error” 的日志行号。定位错误时间点后再和 Vuser 数量曲线对齐就能判断错误发生在加载阶段还是稳态阶段。本次错误集中在 Vuser 数达到 25 的时刻且都是连接类错误优先怀疑服务器的并发连接数限制而不是应用代码。4.3 被测系统资源监控配置要判断服务器是否真的到达资源瓶颈需要把 Controller 的监控点加到被测系统主机上。负载测试不只是测请求成功与否还要解释为什么失败。LoadRunner 监控 Windows 机器需要在“Windows Resources”图里填写目标机器 IP 和账密监控 Unix/Linux 目标机目标机上要运行 rstatd 服务Controller 通过该服务采集 CPU、内存、磁盘 IO 实时数据。如果不想依赖额外 agent可以用系统自带工具交叉验证Windows 下用性能监视器记录 Processor Time、Available MbytesLinux 下用vmstat 1和sar -q记录运行队列和上下文切换。这里要说明监控边界LoadRunner 监控图是秒级采样能看出趋势但要确认 TCP 连接数这类细节还是在服务器本地执行netstat -s或ss -s看协议统计更可靠。工具之间互相验证比单看一张图靠谱。5. Analysis 进阶用 90% 响应时间与吞吐量定位系统拐点5.1 平均事务响应时间的掩盖效应Analysis 打开后默认展示平均事务响应时间图如果评审会只摆这一张图容易被数据骗。平均值是所有样本的算术平均少数响应时间异常大的事务会把平均值拉高。比如 20 次登录事务里 19 次响应 1.5 秒1 次响应 25 秒平均值变成 2.7 秒看起来系统“不达标”实际绝大多数用户感受正常。反过来如果大部分请求慢而少数快平均值又会掩盖真实劣化。所以我会把百分比事务响应时间图作为主要参考。在 Analysis 左侧图列表新建图选择 Transaction Response TimePercentile按事务分组显示 90% 响应时间曲线。这个值代表 90% 的请求都低于该阈值比平均值更接近真实用户体验。如果 90% 响应时间在 3 秒内但平均值超过 5 秒说明长尾请求拖累了整体排查方向是那 5% 到 10% 的慢请求发生在什么时间段结合 Vuser 数量的时间轴能回答“25 个 Vuser 是不是拐点”这类具体问题。5.2 吞吐量与响应时间曲线交叉验证只分析响应时间不看吞吐量不够。吞吐量图显示服务器每秒返回的字节数反映系统处理请求的能力。健康形态是随着 Vuser 增长吞吐量同步上升响应时间稳定或缓慢上升当错误出现时吞吐量断崖式下跌、响应时间紧接着飙升这是典型的过载形态。推荐的叠加技巧在 Analysis 中右键点击吞吐量图标题选择 Merge Graphs把吞吐量图和运行 Vuser 图合并到同一时间轴再把百分比响应时间图也合并进去。一张图上同时看到三条曲线Vuser 数量、吞吐量、响应时间。找到响应时间开始快速上升且吞吐量不再增长的那个 Vuser 数量就是系统在当前业务模型下的建议并发上限。把 25 个 Vuser 的实测结果对应到图上错误发生点恰好位于吞吐量停止增长的位置说明 25 就是教务管理系统的连接瓶颈不是脚本或参数设置问题。这个步骤可复用每次测试后从 Analysis 导出 CSV 原始数据在 Excel 里绘制叠加图再放进报告。如果时间紧用 Merge Graphs 结果也足够支撑结论。导出 HTML 报告时不需要堆所有图表保留合并曲线图、90% 响应时间图和错误统计表拐点结论直接在图上体现评审时不用再解释数据来路。本文还有配套的精品资源点击获取