企业官网建设流程全解析

简介：这是一份面向软件测试学习者与性能测试初学者的LoadRunner负载测试实验报告资料，包体内仅含1个docx文档，大小约1.52MB。报告以教务管理系统登录业务为对象，完整记录了负载测试全流程：从规划测试目标、在VuGen中录制Vuser脚本，到Controller中定义场景并配置本地Load Generator，再逐步加压至25个并发用户运行并实时监控Vuser状态，最后用Analysis分析平均事务响应时间、吞吐量等指标。内容还涵盖实验环境（Windows 7+LoadRunner）、实验目的与要求、操作步骤及总结，其中包含加压过程中出现错误时的系统表现记录，适合软件测试课程实训、自考复习或毕业设计时对照参考。已有97人学习下载，该文档能帮助初学者理解LoadRunner核心组件的配合方式，并快速形成可复用的性能测试报告框架。

1. 一份LoadRunner测试报告到底要给谁看

性能测试做到最后，最难交付的往往不是脚本，而是那一份Word报告。场景跑完，Controller里几十条曲线，Analysis里上百张图，全导出来两百页文档，领导翻两页就问你一句话：系统到底行不行？这句话才是LoadRunner测试报告真正要回答的问题。报告不是截图合集，它的核心是四个判断：系统能扛多少并发、响应时间能不能达标、瓶颈卡在哪一层、需要加机器还是改代码。读者是项目经理、架构师和运维负责人，不是测试组自己，所以每个数字都要能向上解释、向下追溯到具体场景和日志。

2. 报告数据从哪来：LoadRunner Controller场景与Analysis指标

很多报告写得单薄，根子不在写作水平，而是场景数据本身就没设计好。LoadRunner测试报告里每一个结论，都来自Controller里跑出来的场景和Analysis里算出来的统计量。这一章先把报告的数据生产线讲清楚。

2.1 场景设计直接影响报告结论，先定这四个参数

报告里最重要的“测试负载”段落，本质上是在描述场景定义。不要等跑完再回忆，场景在执行前就应该把下表里这些参数定死并记录在案，因为它们决定了报告里的并发数、TPS和响应时间是否可信。

我一般会建议用阶梯式加压而不是一次性压满。一次性把 200 个 Vuser 全部拉起来，报告里只能看到一个撞墙点；按 50、100、150、200 分阶段加载，才能看出哪个并发区间开始出现响应时间拐点。这个拐点就是报告里“最大建议并发”的直接依据。

场景类型的选择也要写进报告。如果是目标场景（Goal-Oriented），LoadRunner 会自动调整 Vuser 数量去追逐设定 TPS，报告结论要写明“系统未达到 X TPS 时自动增加并发”，而不是“系统在 X 并发下没问题”。

2.2 用命令行跑场景，结果目录要固定

场景在GUI里跑没问题，但报告归档时需要固定结果路径。我习惯用LoadRunner的命令行模式跑回归场景，这样结果目录名带时间戳，报告里的环境信息可追溯。以 LoadRunner 12 以后版本为例：

lr -cmd -run -project_path "E:\LRProj\BankingApp" \ -test_path "E:\LRProj\BankingApp\Test01_Login.lrs" \ -result_name "E:\LRProj\BankingApp\Results\Login_20250115_1000"

逻辑说明：这条命令调用 LoadRunner 的 Controller 无界面引擎，执行指定场景文件.lrs，并把本次运行结果写到固定目录。途中如果脚本里使用了参数化文件或关联规则，只要场景文件引用了它们，命令行执行时同样生效，不需要额外配置。

参数说明：-project_path是项目目录，-test_path是场景文件路径，-result_name是结果集名称。-result_name建议包含日期时间和压测批次，避免多轮压测后结果目录互相覆盖，报告里引用的原始数据也能迅速找到。

这里有个容易踩的坑：如果场景文件里勾选了“每次运行前清理结果”，而result_name又写成了固定值，那么第二次跑会把第一次的结果直接覆盖。报告里如果引用了旧的截图，数据就对不上了。

2.3 Analysis里报告必用的三张图和三张表

场景跑完后，Analysis 是 LoadRunner 生成报告数据的核心工具。打开.lrr结果文件后，左侧的图列表很多，但不是每张都要进报告。我通常只保留能支撑结论的内容。

Analysis.exe -i "E:\LRProj\BankingApp\Results\Login_20250115_1000.lrr" \ -o "E:\LRProj\BankingApp\Reports\Login_20250115_1000.html"

逻辑说明：-i指定结果文件，-o指定导出的 HTML 报告路径。生成后可以得到一个自带图表和数据表的 HTML 文档，方便保存和二次处理。不过要注意，自动生成的 HTML 报告包含全部图，篇幅很长，直接转 Word 会被评审嫌啰嗦。

进正式文档的，我只挑下面这些关键项：

另一个推荐做法是用 Analysis 的导出功能把事务统计数据导出为 CSV，方便做更长周期的趋势报表和后续对比。指标怎么解读，在报告里怎么写，是下一章的重点。

3. 读懂 LoadRunner 报告里的关键性能指标

Analysis 默认给出的 Summary 表里，每一行是一个事务，列包含平均响应时间、最大响应时间、90%响应时间、标准差、TPS、失败数。很多人直接把这张表截图放进报告，却解释不了其中任何一个数。这一章把最容易被问住的几个指标讲透。

3.1 事务响应时间：为什么报告里要写90%而不是平均值

这是 LoadRunner 报告评审时被问得最多的问题。平均响应时间容易被极端值拉偏，比如 1000 个请求里 990 个响应 0.5 秒，10 个响应 15 秒，平均值 0.65 秒，看起来完全正常，但实际体验已经有十分之一的用户卡顿了。90%响应时间的含义是：按响应时间从小到大排序，去掉最慢的 10% 样本之后，剩余样本中的最大值。

Analysis 的 Summary 表已经直接给出这个列，不需要自己算。但如果你从原始事务日志做二次分析，用 Python 计算 90 百分位的代码如下：

import pandas as pd # Analysis导出的CSV，每一行是一个事务样本 df = pd.read_csv("trans_detail.csv", encoding="utf-8") resp_times = df["Response Time"].dropna() # 去除最大的10%样本后，取剩余样本的最大值 p90 = resp_times.quantile(0.9) print(f"90%响应时间: {p90:.3f} 秒")

逻辑说明：quantile(0.9)是把响应时间样本按升序排列后，取 90% 分位点的数值，这与 LoadRunner Analysis 里 Percentile 算法的口径一致。为什么要去掉最慢的 10%？因为那部分样本可能包含网络闪断、首次连接、DNS 解析等非业务因素，报告里用 90% 描述“绝大多数用户的实际体验”更贴近真实。

参数说明：如果被测系统对响应时间非常敏感，我会同时把 95% 和 99% 分位点算出来放在报告附录里。注意，Analysis 里的事务采样粒度默认是每 15 秒一个聚合点，导出明细时需要选择“每个样本”粒度，否则算出的百分位是粗粒度近似值。

3.2 吞吐量与TPS：两个指标在报告里的分工

吞吐量（Throughput）和每秒事务数（TPS）是报告里最容易混淆的一对指标。吞吐量单位是字节，衡量的是网络层传输的数据量；TPS 单位是个数，衡量的是应用层完成的事务数。遇到大请求体时，吞吐量高但 TPS 低很正常。

报告里的描述方式我一般这么写：“系统在 100 并发下平均 TPS 为 812，吞吐量 6.8 MB/s”，这里 TPS 说明业务处理能力，吞吐量说明带宽消耗。如果 TPS 没有明显回落但吞吐量持续上涨，说明请求体变大或响应体膨胀，需要进一步查报文大小。

3.3 事务失败率和错误类型必须列进报告

LoadRunner 的事务失败不只是 HTTP 500。事务中如果包含了多个请求，只要其中一个请求断言失败，整个事务就被标记为 Failed。所以报告里看到失败率 1% 时，不能简单说“系统可用性 99%”，要写清楚具体错误类型。

常见的错误类型和报告里的处理建议：

3.4 资源指标的解读边界

Windows Resources 图在报告里不可少，但很多人在这一步下错结论。CPU 利用率 50%、内存还有剩余，不代表系统没有瓶颈。需要结合处理器队列长度（Processor Queue Length）和磁盘队列长度一起看。

如果报告里要描述资源状况，我推荐用下面这组判断顺序：先看 CPU 是否持续超过 85%，再看 Available MBytes 是否低于总内存的 20%，最后看 PhysicalDisk 的 % Disk Time 是否接近 100%。三步都正常，才能写“资源未成为瓶颈”；任何一步异常，都要继续下钻，这个下钻过程就是下一章要展开的瓶颈识别逻辑。

4. 从 LoadRunner 报告定位瓶颈的四个步骤

报告里不能只写“平均响应时间 3.2 秒，不达标”，评审方会追问：为什么不达标？瓶颈在哪里？这一章讲怎么从 LoadRunner 报告本身的图表出发，一步步把问题定位到具体层面。

4.1 先确认压测结果有效性，否则报告没有意义

在分析任何曲线之前，先检查一个前提：场景是否真的按设计跑完了。打开 Running Vusers 图，看 Vuser 数曲线是否稳定在设计值附近。如果曲线一直抖动，说明脚本或参数化存在问题，报告里的数据畸形，后面的分析全部失效。

另一个有效性检查是看场景运行期间是否有大量错误堆积在 Controller Output 窗口。常见情况是测试脚本没有做参数化，50 个 Vuser 同时用同一个账号登录，导致服务端踢掉前一个会话，产生错误。这种数据写进报告，评审一眼就能看出压测准备工作不到位。

最后还要检查压测机本身是不是已经饱和。如果 LoadRunner 压力机 CPU 或内存跑满，虚拟用户的运行节奏会失真，报告里的“系统瓶颈”其实是压测机瓶颈。检查方式是在 Windows 任务管理器里看 LoadRunner Agent 进程占用，超过 80% 就需要增加压力机。

4.2 看响应时间曲线的形态，判断排队还是泄漏

确认结果有效后，第一张要看的图是 Average Transaction Response Time。曲线形态本身就提供信息：

写报告时不要只贴曲线，要把“形态对应了哪种可能性”写进去。比如响应时间线性上涨且 CPU 没有明显变化，我通常会写“内存或会话对象持续累积，需结合 JVM 堆曲线验证”，这个结论比单纯写“响应时间变慢”更有价值。

4.3 资源指标与响应时间交叉验证

单看服务器 CPU 平均 40% 就断言“资源充裕”，在 LoadRunner 报告里站不住脚。正确的做法是把响应时间曲线和资源曲线放到同一时间轴对比。

重点看三层：第一层是网络连接数，如果 ESTABLISHED 连接数持续增长而 TPS 不涨，说明连接没有被及时释放；第二层是中间件线程池，线程池打满时响应时间会快速上升但 CPU 未必高；第三层是数据库等待事件，比如锁等待和 log file sync。LoadRunner 的 UNIX/Windows Resources 监控能覆盖前两层，数据库和中间件指标需要借助监控插件或外部监控接入。

常见误判是：CPU 不高，就排除应用瓶颈。实际上单线程应用或频繁锁等待的系统，CPU 就是上不去，但响应时间已经恶化。报告里遇到这种情况，要写“资源利用率无法覆盖服务处理链路，建议接入数据库和 JVM 监控后复测”。

5. 把 LoadRunner 报告写成 Word 文档的落地技巧

5.1 报告的骨架顺序，我固定用这套结构

分析做得再透彻，文档结构混乱一样会被打回来。我交付 LoadRunner 测试报告时，Word 文档的目录基本是：文档信息（版本、作者、测试时间）、测试目标与通过标准、被测环境描述、场景设计与脚本说明、测试结果与指标分析、结论与建议、附录（原始数据与工具版本）。标题里的“(完整word版)”指的是文档要素完整，而不是页数多。

5.2 图表信息的呈现规范

Analysis 导出的 HTML 报告直接转 Word 会失真，我统一使用两种方式处理：趋势图用“截图+时间轴标注”，表格数据用“CSV 处理后重新生成的三线表”。截图上要用文本框标注出拐点时间和对应并发数，表格里保留平均值、90%、TPS、失败率四列，小数点统一保留两位。

Word 文档里不建议粘贴 Analysis 的树形图目录和所有默认指标，那会让报告显得没有取舍。每一张图进文档都要有明确作用，无关图放附录。结论部分的表述建议用模板化的句式：“在 X 并发下，Y 事务平均响应时间 Z 秒，90% 响应时间 W 秒，达到/未达到既定目标”，并同步写出对应的环境差异说明，比如“本报告数据基于 4C8G 单节点，生产环境为 8 节点集群，实际容量需按比例折算但不超过线性扩容上限”。

把环境信息、脚本版本、LoadRunner 版本和压力机配置写进附录，这样同一项目的下一次测试可以直接复用这份报告的基线数据做回归对比。

本文还有配套的精品资源，点击获取