简介：这份LoadRunner性能测试报告面向软件测试初学者、高校课程实验学生及需要撰写性能测试文档的测试人员，围绕HP Web Tours订票系统展开完整的性能测试实践。资源以单份doc文档交付，压缩包大小约677KB，内含1个Word文件，结构上依次覆盖前言、系统功能与性能指标定义、三层架构与业务流程说明、测试环境与数据准备、虚拟用户脚本与测试场景设计、运行状况记录以及测试分析与结论等章节。报告具体给出了吞吐量TPS、响应时间、并发用户负载与CPU、内存、磁盘I/O资源利用率等指标，并设定1000并发下平均响应时间2秒内、TPS达500的测试目标，同时整理登录验证、数据库查询与支付处理等关键测试点，提供响应时间过长与资源占用过高的优化思路。目前已有1304人学习下载，适合用作性能测试课程报告的写作参考或测试流程模板。
1. LoadRunner 性能测试报告到底交付了什么
压测跑完，Controller 窗口里满是颜色各异的曲线，但这堆实时视图没法直接发给产品经理。评审桌上真正流转的，往往是 Analysis 导出的那份 .doc：带封面、带事务汇总表、带响应时间分布图，产品和运维能直接在 Word 里批注、圈红、回传意见。这也是「LoadRunner 性能测试报告.doc」这个文件名的由来，它是压测工作的交付物，而不是执行过程本身。
它要回答的问题很集中：系统在当前并发下扛不扛得住、瓶颈在应用还是数据库或中间件、扩容到多少节点能撑住目标 TPS、哪些事务是拖后腿的长尾。.doc 只是载体，里面的事务摘要、TPS 曲线、90% 响应时间、错误分布才是干货。
做性能测试的工程师、负责容量规划的运维、被拉来确认 SLA 的后端开发，都会围着这份文档来回改。下面从结果落盘讲到报告排错。
2. 从 Analysis 把 .lrr 结果导出成 .doc 报告的完整路径
2.1 Controller 执行结束后结果落在哪里
Controller 跑完场景，结果按你指定的路径落盘。根目录通常是.lrr（结果定义）加.lra（Analysis 会话），data/子目录里是采样点、事务明细和错误日志。.lra双击就能进 Analysis，.lrr更偏执行侧，两者都能被 Analysis 识别，但日常用.lra更省事。需要留意的是，压测结束后不要再手动往结果目录里丢文件，Analysis 重新加载时会对目录做一致性校验，多出来的文件可能导致会话打不开。
# 查看一次压测结果目录里都有什么 ls -lh ./scenario_res/ # 结果根目录：.lrr / .lra / 错误日志 ls -lh ./scenario_res/data/ # 采样数据与事务明细，报告里每条曲线都取自这里 ls -lh ./scenario_res/HTMLReport/ # 曾经导出过 HTML 报告时会出现.lra是 Analysis 会话文件，保存了当前打开的图和筛选状态；data/是原始采样，报告里的平均值、分位数、错误率全部从这里算出来；HTMLReport/只是历史产物，不影响新报告生成。把这三层结构记住，后面排查「报告里数字对不上」的问题时会省很多时间。
| 文件 / 目录 | 作用 | 能否直接双击打开 |
|---|---|---|
.lra | Analysis 会话，含已配置的图与筛选 | 能，默认关联 Analysis |
.lrr | 结果文件，Controller 与 Analysis 共用 | 能，但建议用.lra |
data/ | 原始采样与事务明细 | 不能，仅供 Analysis 读取 |
HTMLReport/ | 历史 HTML 导出 | 能，浏览器打开 |
*.eve | 场景事件日志 | 不能，文本查看即可 |
2.2 Reports 菜单导出 Word 的选择顺序
手动导出是最常见也最可靠的方式，步骤本身不复杂，但每一步的取值都会影响最终 .doc 的内容：
- 用 Analysis 打开
.lra，先确认左侧树里的事务、图都加载完整； - 菜单
Reports → Word Report，弹出报告向导； - 选择模板，默认模板够用，要改封面和章节顺序就换自定义模板；
- 选择数据集，
All Data导全量，Selected Data只导当前筛选后的区间； - 指定输出路径与文件名，扩展名保持
.doc； - 点击生成，等 Analysis 把图表逐张渲染进文档。
这里最容易被忽略的是第 4 步。压测场景通常包含 ramp up、稳态、ramp down 三段，如果选All Data，报表里的平均值会被爬坡阶段的低并发拉低，看着很漂亮，但和稳态表现对不上。更稳的做法是在 Analysis 里先用时间范围筛选出稳态区间，再选Selected Data导出。第 3 步的模板决定了报告里出现哪些章节，默认模板一般包含 Summary、Transaction Summary、Statistics、Graphs 四块，如果业务方还想要错误明细或资源监控，需要提前在模板里勾上。
提示：导出前把 Analysis 的图都刷新一遍，图缓存过期时生成的 .doc 里可能出现空白占位框，而不是曲线图。
2.3 模板分区与常见调整
模板不是只有封面样式，它决定了报告的结构。Analysis 的模板管理入口在Tools → Template Management，可以复制一份默认模板再改，不要直接改原模板，否则下次换项目时容易串味。
| 模板分区 | 数据来源 | 常见的调整动作 |
|---|---|---|
| Summary | 场景信息 + 全局统计 | 加项目名、版本号、测试环境说明 |
| Transaction Summary | 事务级汇总 | 只保留核心事务，删掉初始化脚本产生的噪声事务 |
| Statistics | 采样统计 | 补充 90%/95% 分位，默认模板往往只给平均 |
| Graphs | 各类曲线图 | 固定输出 TPS、响应时间、错误率、资源监控四张 |
| Errors | 错误日志聚合 | 按错误码分组，避免同一类错误刷满整页 |
把分区和数据来源对上号，改模板时就知道该动哪一块。模板改完存成独立文件，跟着项目走，比每次都手工勾选要稳定得多。
3. .doc 报告里四个核心指标怎么读才算读对
3.1 Transaction Summary：平均值会骗人
事务汇总表是报告里被看得最多、也最容易被误读的一页。平均值只反映分布的中心，不反映尾部。一个事务平均值 200ms，但如果 90% 分位是 1.8s、最大值 12s，用户体验照样崩。看这张表时的顺序应该是：先扫错误率，再看 90% 分位，最后才看平均。最大值偶尔冒尖可以接受，但 90% 分位高说明慢是常态，不是偶发。
另外一个容易被忽略的点是事务粒度。VuGen 录制时会自动生成vuser_init、Action、vuser_end三个默认事务，其中vuser_init包含登录，往往耗时最长。很多报告里排名第一的「慢事务」其实就是登录，这属于正常现象，要在报告里单独说明，别让业务方误判成接口有问题。
3.2 TPS 和 Throughput 不是一回事
TPS 统计的是事务完成速率，单位是笔/秒；Throughput 统计的是网络字节吞吐，单位通常是字节/秒或 KB/秒。两者经常被混着写进结论里，但它们回答的问题完全不同。TPS 反映业务的处理能力，Throughput 反映的是数据传输量，一个下载类接口的 Throughput 可以很高，但 TPS 可能很低，因为每个事务本身就很慢。
判断系统是否已经到瓶颈，要看 TPS 曲线是否出现平台期。随着并发增加，TPS 先线性上升，然后趋平，再往后可能掉头向下。平台期那个点的并发数，就是当前架构的拐点。报告里最好把 TPS 曲线和响应时间曲线叠在同一张时间轴上，看到「TPS 停涨且响应时间开始抬头」的那个交叉位置，才是真正要写进结论的数字。
3.3 错误率：别只看总数
总错误率 0.5% 听起来可以接受，但如果这 0.5% 全部集中在某一个事务上，那个事务实际上已经不可用了。所以错误率要按事务拆开看，并且按错误码再拆一层。常见的分类方式是：连接超时、HTTP 5xx、业务校验失败、断言失败四类。前三类指向被测系统，第四类往往是脚本写法问题，比如关联没取到值。
分析时把错误发生的时间点和并发曲线对齐，如果错误全部出现在某个并发台阶之后，那就是容量问题；如果错误均匀地散布在整个稳态区间，那更可能是脚本或数据问题。
import pandas as pd # transaction_summary.csv 由 Analysis 导出的事务明细整理而来 df = pd.read_csv("transaction_summary.csv") # 只保留稳态区间，掐掉 ramp up 和 ramp down steady = df[(df["elapsed_s"] >= 300) & (df["elapsed_s"] <= 1500)] for txn, g in steady.groupby("transaction"): total = g["total"].sum() failed = g["failed"].sum() print( txn, "avg=%.3f" % g["resp_s"].mean(), "p90=%.3f" % g["resp_s"].quantile(0.90), "max=%.3f" % g["resp_s"].max(), "err=%.2f%%" % (100 * failed / total) if total else "err=n/a", )这段脚本做四件事：按elapsed_s切出稳态区间，避免爬坡阶段污染统计；按事务分组；对每个事务同时算出平均值、90% 分位、最大值和错误率；错误率用failed / total现算，而不是直接读报告里已经四舍五入过的百分比。阈值 300 和 1500 需要按实际压测时长调整，原则是两端各留出至少 5 分钟的爬坡和收尾，中间的平稳段才参与统计。
3.4 指标口径与常见误读对照
| 指标 | 计算口径 | 参考判断 | 常见误读 |
|---|---|---|---|
| 平均响应时间 | 全部样本算术平均 | 只作趋势参考 | 当成 SLA 承诺值 |
| 90% 响应时间 | 90% 样本不超过该值 | 核心 SLA 指标 | 与平均混淆 |
| TPS | 事务完成数 / 稳态时长 | 看平台期拐点 | 用峰值代替稳态值 |
| 错误率 | 失败事务数 / 总事务数 | 按事务、按错误码拆分 | 只看全局总数 |
| Throughput | 字节数 / 时长 | 判断带宽是否打满 | 与 TPS 混写 |
| 并发用户数 | 同时在线 vuser 数 | 结合业务模型换算 | 直接把线程数当并发 |
4. 批量生成 LoadRunner 性能测试报告的自动化路径
4.1 命令行调用 Analysis 做无人值守导出
一次版本迭代往往有多个场景要跑，手工一份份导出 .doc 很耗时间。Analysis 提供了命令行入口，配合批处理就能把整个目录的结果一次性转成报告。参数名在不同版本之间略有出入，动手前先用-?确认一遍。
@echo off REM 批量把一个目录下所有 .lra 会话导出为 Word 报告 set ANALYSIS="C:\Program Files (x86)\HP\LoadRunner\bin\AnalysisUI.exe" set RESULT_DIR=D:\perf\results set OUT_DIR=D:\perf\reports if not exist "%OUT_DIR%" mkdir "%OUT_DIR%" for %%F in ("%RESULT_DIR%\*.lra") do ( echo 正在导出 %%~nF ... %ANALYSIS% -RR "%%~fF" -SO "%OUT_DIR%\%%~nF.doc" if errorlevel 1 ( echo [失败] %%~nF 导出异常，检查会话是否完整 ) )-RR指定要导出的结果会话，-SO指定输出文件路径，%%~nF取不含扩展名的文件名，%%~fF取完整路径。errorlevel判断用来捕获导出失败，避免脚本一路绿到底而实际有报告是空文件。批处理跑完之后，建议随机抽两三份 .doc 打开确认图表不是空白，因为命令行模式下 Analysis 不会弹窗提示模板缺失。
注意：命令行导出期间不要同时用 GUI 打开同一份
.lra，文件锁会导致导出结果为空或直接报错退出。
4.2 把关键指标落成 CSV 供流水线消费
.doc 适合人看，不适合流水线判断。建议在导出报告的同时，把关键指标另存一份结构化数据，供 CI 做阈值卡点。
import json import pandas as pd # 从整理后的事务明细里抽取核心事务的稳态指标 df = pd.read_csv("transaction_summary.csv") steady = df[(df["elapsed_s"] >= 300) & (df["elapsed_s"] <= 1500)] result = {"build": "nightly-0421", "transactions": []} for txn, g in steady.groupby("transaction"): if txn in ("vuser_init", "vuser_end"): continue # 排除脚本自带事务 result["transactions"].append({ "name": txn, "p90_s": round(g["resp_s"].quantile(0.90), 3), "err_rate": round(g["failed"].sum() / g["total"].sum(), 4), }) with open("perf_gate.json", "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2)这段脚本的输出是一份可以直接被流水线读取的 JSON。p90_s用来卡响应时间红线，err_rate用来卡错误率红线，vuser_init和vuser_end被显式排除，避免登录耗时干扰判断。阈值判断放在流水线侧而不是脚本里，脚本只负责产出事实，规则变化时不用改代码。
4.3 报告归档的命名规范
批量生成最容易失控的是文件命名，几十份report.doc堆在同一个目录里，过两周谁也认不出哪份对应哪个场景。
| 命名段 | 取值示例 | 说明 |
|---|---|---|
| 项目 | order-center | 被测系统简称 |
| 场景 | mix-200u | 业务模型 + 并发规模 |
| 日期 | 20250421 | 执行日期，固定 8 位 |
| 版本 | v2.7.3 | 被测版本号 |
| 序号 | 01 / 02 | 同一轮多次执行时区分 |
拼起来就是order-center_mix-200u_20250421_v2.7.3_01.doc。批处理里用变量拼接，别手工改。
5. 报告打不开、无法预览 doc 的几个排查点
5.1 先确认这个文件到底是不是真 .doc
遇到「无法预览 doc」时，第一步不是换 Word 版本，而是确认文件格式。有的导出工具会把 HTML 或 RTF 内容直接存成.doc扩展名，文件本身并不是 OLE2 二进制文档，Word 打开时会报格式异常，某些在线预览组件更是直接拒绝加载。
# 看文件头判断真实格式 file report.doc # 期望输出：Composite Document File V2 Document（真正的二进制 doc） # 若输出 HTML document，说明内容是 HTML，只是改了扩展名 # 若输出 Rich Text Format，说明实际是 RTF # 若输出 Zip archive data，说明是 docx 被改名成了 doc5.2 编码、字体与 Word 版本的组合问题
确认格式没问题之后，再排查内容层面的兼容性。报告里包含大量中文事务名和参数名时，如果导出时用的字符集和打开端不一致，会出现整段乱码。稳妥的做法是导出后立刻在目标环境的 Word 里打开一次，而不是只在自己机器上验证。字体缺失也会造成排版错位，模板里尽量用系统自带字体，别引用项目组内部安装的特殊字体。
跨版本是另一个高频问题。高版本 Word 生成的文档，用低版本打开时部分图表对象可能显示为红叉。报告交付给外部团队之前，问清楚对方的 Office 版本，必要时导出为兼容模式，或者干脆附一份 PDF 作为只读副本，PDF 用来保证排版一致，.doc 保留下来供批注。
5.3 体积过大导致打开卡死
压测规模上来之后，报告里动辄几千个采样点，每张图都渲染成矢量对象，一份 .doc 做到几百兆并不罕见。这种文件打开慢、翻页卡，发给别人还会被邮件网关拦下来。
处理思路是降采样和拆图。在 Analysis 里把图的采样间隔调大，比如从 1 秒改成 10 秒，曲线形状基本不变，点数直接降到十分之一；再把非核心的图从报告模板里去掉，只保留 TPS、响应时间、错误率、资源监控四张。拆分方面，把错误明细单独导成附件，正文报告只留聚合结果。做完这两步，一份完整的性能测试报告通常能压到十几兆以内，邮件和在线预览都不会再出问题。
提示：降采样只影响图的显示密度，不影响事务汇总的统计结果，汇总值仍然基于全量采样计算。
本文还有配套的精品资源，点击获取
