简介一份面向WEB-Tours订票系统的完整性能测试报告以Word文档形式呈现适合软件测试工程师、性能测试初学者、高校软件测试课程学习者阅读用于掌握压力测试、负载测试以及LoadRunner工具的实际应用。报告内容覆盖被测系统定义、功能简介、系统结构与流程、性能测试指标、性能测试概述与测试目的并针对并发压力场景进行了重点说明在15个并发用户下设计10个用户不并发注册、5个用户不并发登录浏览网页的测试场景实测得到平均事务响应时间20ms、吞吐量30TPS的关键结论同时汇总了性能测试重要性、并发用户测试、吞吐量与响应时间、系统结构对性能影响、性能优化等知识点方便读者快速提炼核心要点。资源为单个docx文档容量1.32MB包含完整的性能测试环境描述、硬件网络拓扑及数据库、服务器配置背景结构清晰便于按章节查阅测试方案、测试数据与结论分析。当前已有539人浏览学习是一份可用于课程设计、毕业设计或性能测试入门实操的参考资料。1. WEB-Tours 性能测试的边界与起点WEB Tours 是 LoadRunner 自带的一个航空订票练习系统界面简陋、功能也简单但绝大多数压测新手第一次真正跑全流程都是从它开始的。我最近拿它做了一轮完整的性能测试15 个并发用户注册与登录组合场景四轮执行最终平均事务响应时间 20ms、吞吐量 30TPS。测试本身不复杂复杂的是把这个结果讲清楚——为什么定这四个场景、逐步加压怎么配、并发和不并发到底差在哪。我会把这次测试的完整逻辑拆开从指标定义到场景配置再到结果解读最后落到用 JMeter 复现时最容易踩的三处设置。适合刚接触性能测试、准备在 WEB-Tours 或类似 Web 系统上做全流程压测的测试工程师和运维工程师。2. 指标定义与测试环境压测前先想清楚三件事2.1 三个核心指标决定测试方案性能测试开始之前第一件事不是录脚本而是把指标定义清楚。本次测试围绕三个指标组织场景它们分别是系统的响应水平、吞吐率和负载水平。响应时间从客户端发起交易到服务端应答返回的耗时包含网络传输时间和服务端处理时间。它是最直观的体验指标业务方最关心。本次期望值设置为平均响应时间小于 15 秒、最大响应时间小于 30 秒。注意这个期望值来自业务需求而不是技术理想值压测的目标是验证系统能否达到达不到就要定位原因而不是反过来把期望值调大。吞吐量应用系统在单位时间内完成的交易量本质上衡量服务端的处理能力。本次用 TPS 作为单位并分别记录成功、失败、停止的数量。只看成功数量会漏掉问题例如注册事务大面积失败时成功 TPS 可能不变但业务已经不可用所以失败事务必须单独统计。负载水平系统在正常响应时间内能够容忍的最大用户数量。它不是一次性压到某个数而是通过逐步加压观察系统什么时候出现响应时间拐点、什么时候开始丢弃请求。三个指标的关系如下指标定义本次口径响应时间客户端交易发起到应答返回的耗时平均 15s最大 30s记录成功/失败/停止数量吞吐量单位时间完成的交易量以 TPS 和每秒点击数衡量负载水平正常响应时间内可承载的最大用户数每 2 秒增加 1 个用户观察拐点这三个指标之间互相牵制响应时间上升时吞吐量通常下降负载水平则是两者的平衡点它代表系统在不至于让用户体验崩溃的前提下能扛住多少并发。后续分析结果时所有结论都会回到这三个指标的关系上来不会单独看某一个数否则很容易被单条曲线误导方向。2.2 被测系统结构WEB-Tours 与生产环境的关系WEB-Tours 的功能边界很清晰注册和登录用户信息、订票办理、退票办理、查询客户已订票信息。测试脚本就围绕这四类操作录制其中订票和查询是核心注册是前置条件退票在压力场景里出现频率最低所以四轮压测的重点放在注册、登录和订票上。从压测角度理解被测系统结构比理解代码更重要。客户端通过浏览器访问应用服务器应用服务器连接独立部署的数据库服务器这是一个典型的三层交互模型。测试环境硬件用 IBM 570 做数据库服务器、IBM 690 做应用服务器操作系统是 Windows Server 2003数据库用 Oracle办公网络带宽为 1M/10M 以太网。这套配置在今天看已经偏旧但它和生产环境保持了相同的体系结构和交易流程数据库是生产库的复制或按比例缩小这保证了测试结果具备推演价值。我见过不少测试环境配置比生产还高的情况压测结果一片绿上线就被打垮。WEB-Tours 这种低配复刻反而是最接近真实的做法。如果生产环境的数据量远大于测试环境那就要在测试数据准备阶段把核心表的数据量按比例放大到接近生产水平否则响应时间和吞吐量都会被低估。2.3 工具选型LoadRunner 与 JMeter 的取舍选 LoadRunner 跑这套流程除了 WEB-Tours 是它自带的示例系统之外还在于它对多场景组合、资源监控和结果分析的支持比较完整一套界面里能完成脚本增强、加压调度、Windows 与数据库监控、结果曲线叠加。尤其是 Windows 资源监控器场景启动前勾选几项就能采集到 CPU、内存、网络字节数省去不少后期对齐数据的功夫。JMeter 的设计思路不同它更适合轻量、快速、可版本化的压力测试。最近几年网络上讲 jmeter 性能测试步骤的资料非常多从线程组、监听器到聚合报告一步步照做的门槛很低。但做 WEB-Tours 这类多轮、分角色的业务压测时JMeter 需要自己管理多个线程组和定时器分布式压测还要搭建 Master-Slave 环境如果想快速验证一个测试模型LoadRunner 的图形化操作更直接。提示工具选型决定不了测试成败成败在场景设计。如果团队只有 JMeter 或只有 LoadRunner并不需要为了这套测试额外采购工具第 5 部分会给出用 JMeter 复现同一套场景的具体配置。3. 脚本录制与场景设计四轮测试是怎么配出来的3.1 事务包装与参数化脚本录完后第一件事是给每个关键操作加事务。LoadRunner 事务函数包裹请求统计完整业务过程的响应时间。订票事务的脚本结构大致是这样// Action.c 订票事务从发起订票到页面返回的完整过程 lr_start_transaction(book_ticket); // 提交订票表单WEB-Tours 的表单字段包含航班与座位数 web_submit_data(reservations.pl, Actionhttp://web-tours:1080/cgi-bin/reservations.pl, MethodPOST, TargetFramebody, NameoutboundFlight, Value232;330, NamenumSeats, Value1, ENDITEM, LAST); lr_end_transaction(book_ticket, LR_AUTO);逻辑说明事务必须完整包裹一次业务操作而不是一个 HTTP 请求。WEB-Tours 订票动作包含航班选择、座位数量和表单提交中间一旦混入关联请求事务测出的就是混合值无法定位是网络慢还是服务器处理慢。LR_AUTO 参数表示事务结果由内部验证自动判断如果返回页面中没有预期内容事务会被标记为失败不会混入成功事务的平均响应时间。注册操作必须做参数化否则并发注册会全部失败。给用户名字段设一个参数每次迭代取不同值模拟不同用户// 用户名参数化避免多用户并发注册撞唯一约束 web_submit_data(login.pl, Actionhttp://web-tours:1080/cgi-bin/login.pl, MethodPOST, Nameusername, Value{NewUser}, Namepassword, Value{NewPassword}, ENDITEM, LAST);参数说明花括号里的 {NewUser} 和 {NewPassword} 是参数占位符实际取值来自 Controller 的参数表或随机函数。这个细节如果不做第一轮 10 个并发注册的测试结果会全部失败不仅 TPS 失真连平均响应时间都会指向错误方向。3.2 四轮测试的业务组合四轮测试的差异点设计在并发和登录后动作两个维度上目的是拆分不同因素对性能的影响。具体组合如下轮次注册用户数登录用户数登录后动作是否并发第一轮105浏览网页并发第二轮105浏览网页不并发第三轮105订票并发第四轮105订票不并发第一轮和第三轮对照看登录后动作从浏览变成订票后服务器处理时间怎么变化第二轮和第四轮对照看不并发时被误判为瓶颈的环节是否恢复。这里的并发通过集合点实现不并发则通过思考时间错开请求两种模式对应不同的业务含义。3.3 加压策略与思考时间场景采用逐步加压每隔 2 秒启动 1 个 Vuser1 分 30 秒内启动全部 15 个用户。对应到 LoadRunner 场景配置中关键参数如下Vuser 数量: 15 Ramp-up: 2 秒/个 Duration: 全部启动后保持运行 集合点: 注册与登录事务起始处参数说明Ramp-up 间隔决定压力增长速度。2 秒一个用户15 个用户全部加载完约需 28 秒剩余时间用来观察稳定期表现。如果间隔太长会拉长测试总耗时太短则近似瞬间加压无法观察逐步逼近瓶颈的过程。分析响应曲线时务必把加载段和稳定段分开看加载段的响应时间上升可能是集合点同步后的并发抢占不代表系统整体变慢。思考时间的设置要按场景区分。启用思考时间模拟用户阅读页面和输入信息的停顿响应曲线更接近生产但会拉低吞吐量禁用思考时间让脚本连续发压突出服务器处理能力。本次只在并发轮次启用思考时间用来观察真实用户体验下的表现不并发轮次禁用思考时间让请求连续发送对照出并发对系统造成的额外压力。日志记录默认开启但正式压测建议关闭避免日志写入造成额外 I/O 干扰测试数据。3.4 监控项配置资源监控要在场景启动前配置重点有两块Windows 资源监控器采集应用服务器的 Processor Time、Available Mbytes 和 Network Interface Bytes Total数据库侧记录 Oracle 会话数与等待事件。配置完成后先在 1 个用户下试跑一遍确认监控曲线有数据再正式执行。提示监控项宁可多开不要事后发现缺数据重跑。压力测试最贵的是按人头重跑一轮的时间成本特别是多轮场景组合的测试补一轮可能就要多花半天。4. 四轮执行结果数据为什么是这个数4.1 结果概览四个数字怎么放进一个表格四轮测试每轮运行约 1 分 30 秒。第一轮的结果是整个报告的基准平均事务响应时间 20ms吞吐量 30TPS。后续三轮与第一轮对比结论如下表轮次组合平均事务响应时间吞吐量相对值第一轮10 并发注册 5 并发浏览20ms基准基准 30TPS第二轮10 不并发注册 5 不并发浏览与基准持平略高第三轮10 并发注册 5 并发订票出现抬升下降第四轮10 不并发注册 5 不并发订票回落回升表格传递的最重要信息是吞吐量不是固定的它随并发模型和业务动作变化。如果只看第一轮会得出系统能稳定在 30TPS的结论加上第三轮的下降才能说明订票事务比浏览事务成本高系统在并发订票时触及了数据库层面的竞争点。4.2 用户运行曲线与事务响应时间的关系用户负载方案图展示 Vuser 加载与运行过程。我通常把 Running Vusers 和事务响应时间放在同一个时间轴上对照分三段看加载段前 30 秒、稳定段中间 30 秒、收尾段。加载段的响应时间上升不一定代表瓶颈可能是集合点同步后大量线程同时抢占资源稳定段才是系统在固定负载下的真实表现。本次第一轮稳定段的平均响应时间维持在 20ms 上下没有出现持续拉升说明 15 并发没有击穿系统。第三轮并发订票时稳定段响应时间明显抬升点击率同步下降两条曲线形成典型的剪刀差——点击数下降而用户数不变意味着请求开始排队这是数据库锁等待的典型特征。4.3 吞吐量与每秒点击数的交叉验证每秒点击数Hits per Second表示服务端接收到的每秒页面请求数它和吞吐量 TPS 不是同一个东西但可以交叉验证。点击率上升、响应时间不变说明系统排队深度没有增加点击率下降、响应时间上升说明请求在服务端堆积处理不过来了。本次测试中第一轮点击率与 Vuser 数同步上升全部用户启动后进入平台期没有出现点击率逆向下行的拐点。这验证了 15 并发范围内系统还有余量本轮压测是负载验证而不是压力发现。要找到最大吞吐量还需要继续加大并发数直到拐点出现这也是性能测试报告和压力测试报告的区别所在。4.4 从平均响应时间和吞吐量估算容量报告要回答的问题是这套 WEB-Tours 到底能支撑多少用户我用第一轮数据做一个粗略推演单用户每秒事务数 30TPS / 15 用户 2 事务/秒 单用户事务间隔 1 / 2 500ms 预计 100 用户时 100 × 2 200TPS计算说明这里的 200TPS 是线性外推前提是所有用户行为均匀且系统未到瓶颈。实际运行时100 用户产生的数据库锁竞争、内存压力和网络排队都会使吞吐量增速放缓所以 200TPS 是理想上限不是承诺值。这类估算的意义在于给业务方一个性能余量的数量级概念如果日常并发只有 20 人那现在的 30TPS 支撑有余如果业务冲刺时会到 100 人就必须重跑一轮 100 用户的压力测试来验证真实拐点。5. 用 JMeter 复现这套测试需要注意的三处设置5.1 线程组的 Ramp-Up 先换算再填写LoadRunner 的逐步加压对应 JMeter 线程组的 Ramp-Up Period 字段。LoadRunner 每 2 秒启动 1 个用户、共 15 个用户的模型在 JMeter 里要换算成15 个线程共用 30 秒完成加载也就是线程数填 15Ramp-Up Period 填 30 秒。这里最容易配错的是直接填 0填 0 等于瞬时加压得到的响应时间曲线会明显高于逐步加压的结果和 LoadRunner 压出的 20ms 没有可比性。5.2 同步定时器与思考时间的语义差异LoadRunner 的集合点对应 JMeter 的同步定时器Synchronizing Timer要放在注册和登录请求之前并将同步用户数设置为当前线程数也就是 15才能实现所有用户在同一时刻压向接口。思考时间用固定定时器或高斯随机定时器模拟但注意 JMeter 的定时器作用于整个采样过程与 LoadRunner 的 think time 在时间轴上覆盖的范围略有不同复现时优先用高斯随机定时器给用户停顿加一点随机性更接近真实行为。5.3 用成功样本数计算 TPS 再做对比JMeter 聚合报告默认对所有采样点取平均会把失败样本也计算在内。要统计成功事务 TPS需要在非 GUI 模式下运行并手动处理结果文件# 运行 JMeter 非 GUI 模式生成结果与 HTML 报告 jmeter -n -t web-tours.jmx -l result.jtl -e -o report/ # 统计成功样本数量TPS 成功样本数 / 运行时长秒 grep -c success result.jtl # 查看最大响应时间用于与 LoadRunner 最大响应时间对照 awk -F, {print $2} result.jtl | sort -n | tail -1参数说明-n 表示非 GUI 模式-t 指定测试计划文件-l 输出原始结果到 jtl 文件-e 和 -o 生成 HTML 可视化报告。最终拿成功样本数除以全部线程运行完成的实际秒数得到 TPS与 LoadRunner 压出的 30TPS 对照。偏差在 10% 以内说明场景模型一致超出 10% 优先检查 Ramp-Up 是否换算错、同步定时器是否真正生效、Cookie 管理器是否缺少导致登录请求失败。本文还有配套的精品资源点击获取 WEB-Tours全流程性能测试：LoadRunner场景设计与JMeter复现
简介一份面向WEB-Tours订票系统的完整性能测试报告以Word文档形式呈现适合软件测试工程师、性能测试初学者、高校软件测试课程学习者阅读用于掌握压力测试、负载测试以及LoadRunner工具的实际应用。报告内容覆盖被测系统定义、功能简介、系统结构与流程、性能测试指标、性能测试概述与测试目的并针对并发压力场景进行了重点说明在15个并发用户下设计10个用户不并发注册、5个用户不并发登录浏览网页的测试场景实测得到平均事务响应时间20ms、吞吐量30TPS的关键结论同时汇总了性能测试重要性、并发用户测试、吞吐量与响应时间、系统结构对性能影响、性能优化等知识点方便读者快速提炼核心要点。资源为单个docx文档容量1.32MB包含完整的性能测试环境描述、硬件网络拓扑及数据库、服务器配置背景结构清晰便于按章节查阅测试方案、测试数据与结论分析。当前已有539人浏览学习是一份可用于课程设计、毕业设计或性能测试入门实操的参考资料。1. WEB-Tours 性能测试的边界与起点WEB Tours 是 LoadRunner 自带的一个航空订票练习系统界面简陋、功能也简单但绝大多数压测新手第一次真正跑全流程都是从它开始的。我最近拿它做了一轮完整的性能测试15 个并发用户注册与登录组合场景四轮执行最终平均事务响应时间 20ms、吞吐量 30TPS。测试本身不复杂复杂的是把这个结果讲清楚——为什么定这四个场景、逐步加压怎么配、并发和不并发到底差在哪。我会把这次测试的完整逻辑拆开从指标定义到场景配置再到结果解读最后落到用 JMeter 复现时最容易踩的三处设置。适合刚接触性能测试、准备在 WEB-Tours 或类似 Web 系统上做全流程压测的测试工程师和运维工程师。2. 指标定义与测试环境压测前先想清楚三件事2.1 三个核心指标决定测试方案性能测试开始之前第一件事不是录脚本而是把指标定义清楚。本次测试围绕三个指标组织场景它们分别是系统的响应水平、吞吐率和负载水平。响应时间从客户端发起交易到服务端应答返回的耗时包含网络传输时间和服务端处理时间。它是最直观的体验指标业务方最关心。本次期望值设置为平均响应时间小于 15 秒、最大响应时间小于 30 秒。注意这个期望值来自业务需求而不是技术理想值压测的目标是验证系统能否达到达不到就要定位原因而不是反过来把期望值调大。吞吐量应用系统在单位时间内完成的交易量本质上衡量服务端的处理能力。本次用 TPS 作为单位并分别记录成功、失败、停止的数量。只看成功数量会漏掉问题例如注册事务大面积失败时成功 TPS 可能不变但业务已经不可用所以失败事务必须单独统计。负载水平系统在正常响应时间内能够容忍的最大用户数量。它不是一次性压到某个数而是通过逐步加压观察系统什么时候出现响应时间拐点、什么时候开始丢弃请求。三个指标的关系如下指标定义本次口径响应时间客户端交易发起到应答返回的耗时平均 15s最大 30s记录成功/失败/停止数量吞吐量单位时间完成的交易量以 TPS 和每秒点击数衡量负载水平正常响应时间内可承载的最大用户数每 2 秒增加 1 个用户观察拐点这三个指标之间互相牵制响应时间上升时吞吐量通常下降负载水平则是两者的平衡点它代表系统在不至于让用户体验崩溃的前提下能扛住多少并发。后续分析结果时所有结论都会回到这三个指标的关系上来不会单独看某一个数否则很容易被单条曲线误导方向。2.2 被测系统结构WEB-Tours 与生产环境的关系WEB-Tours 的功能边界很清晰注册和登录用户信息、订票办理、退票办理、查询客户已订票信息。测试脚本就围绕这四类操作录制其中订票和查询是核心注册是前置条件退票在压力场景里出现频率最低所以四轮压测的重点放在注册、登录和订票上。从压测角度理解被测系统结构比理解代码更重要。客户端通过浏览器访问应用服务器应用服务器连接独立部署的数据库服务器这是一个典型的三层交互模型。测试环境硬件用 IBM 570 做数据库服务器、IBM 690 做应用服务器操作系统是 Windows Server 2003数据库用 Oracle办公网络带宽为 1M/10M 以太网。这套配置在今天看已经偏旧但它和生产环境保持了相同的体系结构和交易流程数据库是生产库的复制或按比例缩小这保证了测试结果具备推演价值。我见过不少测试环境配置比生产还高的情况压测结果一片绿上线就被打垮。WEB-Tours 这种低配复刻反而是最接近真实的做法。如果生产环境的数据量远大于测试环境那就要在测试数据准备阶段把核心表的数据量按比例放大到接近生产水平否则响应时间和吞吐量都会被低估。2.3 工具选型LoadRunner 与 JMeter 的取舍选 LoadRunner 跑这套流程除了 WEB-Tours 是它自带的示例系统之外还在于它对多场景组合、资源监控和结果分析的支持比较完整一套界面里能完成脚本增强、加压调度、Windows 与数据库监控、结果曲线叠加。尤其是 Windows 资源监控器场景启动前勾选几项就能采集到 CPU、内存、网络字节数省去不少后期对齐数据的功夫。JMeter 的设计思路不同它更适合轻量、快速、可版本化的压力测试。最近几年网络上讲 jmeter 性能测试步骤的资料非常多从线程组、监听器到聚合报告一步步照做的门槛很低。但做 WEB-Tours 这类多轮、分角色的业务压测时JMeter 需要自己管理多个线程组和定时器分布式压测还要搭建 Master-Slave 环境如果想快速验证一个测试模型LoadRunner 的图形化操作更直接。提示工具选型决定不了测试成败成败在场景设计。如果团队只有 JMeter 或只有 LoadRunner并不需要为了这套测试额外采购工具第 5 部分会给出用 JMeter 复现同一套场景的具体配置。3. 脚本录制与场景设计四轮测试是怎么配出来的3.1 事务包装与参数化脚本录完后第一件事是给每个关键操作加事务。LoadRunner 事务函数包裹请求统计完整业务过程的响应时间。订票事务的脚本结构大致是这样// Action.c 订票事务从发起订票到页面返回的完整过程 lr_start_transaction(book_ticket); // 提交订票表单WEB-Tours 的表单字段包含航班与座位数 web_submit_data(reservations.pl, Actionhttp://web-tours:1080/cgi-bin/reservations.pl, MethodPOST, TargetFramebody, NameoutboundFlight, Value232;330, NamenumSeats, Value1, ENDITEM, LAST); lr_end_transaction(book_ticket, LR_AUTO);逻辑说明事务必须完整包裹一次业务操作而不是一个 HTTP 请求。WEB-Tours 订票动作包含航班选择、座位数量和表单提交中间一旦混入关联请求事务测出的就是混合值无法定位是网络慢还是服务器处理慢。LR_AUTO 参数表示事务结果由内部验证自动判断如果返回页面中没有预期内容事务会被标记为失败不会混入成功事务的平均响应时间。注册操作必须做参数化否则并发注册会全部失败。给用户名字段设一个参数每次迭代取不同值模拟不同用户// 用户名参数化避免多用户并发注册撞唯一约束 web_submit_data(login.pl, Actionhttp://web-tours:1080/cgi-bin/login.pl, MethodPOST, Nameusername, Value{NewUser}, Namepassword, Value{NewPassword}, ENDITEM, LAST);参数说明花括号里的 {NewUser} 和 {NewPassword} 是参数占位符实际取值来自 Controller 的参数表或随机函数。这个细节如果不做第一轮 10 个并发注册的测试结果会全部失败不仅 TPS 失真连平均响应时间都会指向错误方向。3.2 四轮测试的业务组合四轮测试的差异点设计在并发和登录后动作两个维度上目的是拆分不同因素对性能的影响。具体组合如下轮次注册用户数登录用户数登录后动作是否并发第一轮105浏览网页并发第二轮105浏览网页不并发第三轮105订票并发第四轮105订票不并发第一轮和第三轮对照看登录后动作从浏览变成订票后服务器处理时间怎么变化第二轮和第四轮对照看不并发时被误判为瓶颈的环节是否恢复。这里的并发通过集合点实现不并发则通过思考时间错开请求两种模式对应不同的业务含义。3.3 加压策略与思考时间场景采用逐步加压每隔 2 秒启动 1 个 Vuser1 分 30 秒内启动全部 15 个用户。对应到 LoadRunner 场景配置中关键参数如下Vuser 数量: 15 Ramp-up: 2 秒/个 Duration: 全部启动后保持运行 集合点: 注册与登录事务起始处参数说明Ramp-up 间隔决定压力增长速度。2 秒一个用户15 个用户全部加载完约需 28 秒剩余时间用来观察稳定期表现。如果间隔太长会拉长测试总耗时太短则近似瞬间加压无法观察逐步逼近瓶颈的过程。分析响应曲线时务必把加载段和稳定段分开看加载段的响应时间上升可能是集合点同步后的并发抢占不代表系统整体变慢。思考时间的设置要按场景区分。启用思考时间模拟用户阅读页面和输入信息的停顿响应曲线更接近生产但会拉低吞吐量禁用思考时间让脚本连续发压突出服务器处理能力。本次只在并发轮次启用思考时间用来观察真实用户体验下的表现不并发轮次禁用思考时间让请求连续发送对照出并发对系统造成的额外压力。日志记录默认开启但正式压测建议关闭避免日志写入造成额外 I/O 干扰测试数据。3.4 监控项配置资源监控要在场景启动前配置重点有两块Windows 资源监控器采集应用服务器的 Processor Time、Available Mbytes 和 Network Interface Bytes Total数据库侧记录 Oracle 会话数与等待事件。配置完成后先在 1 个用户下试跑一遍确认监控曲线有数据再正式执行。提示监控项宁可多开不要事后发现缺数据重跑。压力测试最贵的是按人头重跑一轮的时间成本特别是多轮场景组合的测试补一轮可能就要多花半天。4. 四轮执行结果数据为什么是这个数4.1 结果概览四个数字怎么放进一个表格四轮测试每轮运行约 1 分 30 秒。第一轮的结果是整个报告的基准平均事务响应时间 20ms吞吐量 30TPS。后续三轮与第一轮对比结论如下表轮次组合平均事务响应时间吞吐量相对值第一轮10 并发注册 5 并发浏览20ms基准基准 30TPS第二轮10 不并发注册 5 不并发浏览与基准持平略高第三轮10 并发注册 5 并发订票出现抬升下降第四轮10 不并发注册 5 不并发订票回落回升表格传递的最重要信息是吞吐量不是固定的它随并发模型和业务动作变化。如果只看第一轮会得出系统能稳定在 30TPS的结论加上第三轮的下降才能说明订票事务比浏览事务成本高系统在并发订票时触及了数据库层面的竞争点。4.2 用户运行曲线与事务响应时间的关系用户负载方案图展示 Vuser 加载与运行过程。我通常把 Running Vusers 和事务响应时间放在同一个时间轴上对照分三段看加载段前 30 秒、稳定段中间 30 秒、收尾段。加载段的响应时间上升不一定代表瓶颈可能是集合点同步后大量线程同时抢占资源稳定段才是系统在固定负载下的真实表现。本次第一轮稳定段的平均响应时间维持在 20ms 上下没有出现持续拉升说明 15 并发没有击穿系统。第三轮并发订票时稳定段响应时间明显抬升点击率同步下降两条曲线形成典型的剪刀差——点击数下降而用户数不变意味着请求开始排队这是数据库锁等待的典型特征。4.3 吞吐量与每秒点击数的交叉验证每秒点击数Hits per Second表示服务端接收到的每秒页面请求数它和吞吐量 TPS 不是同一个东西但可以交叉验证。点击率上升、响应时间不变说明系统排队深度没有增加点击率下降、响应时间上升说明请求在服务端堆积处理不过来了。本次测试中第一轮点击率与 Vuser 数同步上升全部用户启动后进入平台期没有出现点击率逆向下行的拐点。这验证了 15 并发范围内系统还有余量本轮压测是负载验证而不是压力发现。要找到最大吞吐量还需要继续加大并发数直到拐点出现这也是性能测试报告和压力测试报告的区别所在。4.4 从平均响应时间和吞吐量估算容量报告要回答的问题是这套 WEB-Tours 到底能支撑多少用户我用第一轮数据做一个粗略推演单用户每秒事务数 30TPS / 15 用户 2 事务/秒 单用户事务间隔 1 / 2 500ms 预计 100 用户时 100 × 2 200TPS计算说明这里的 200TPS 是线性外推前提是所有用户行为均匀且系统未到瓶颈。实际运行时100 用户产生的数据库锁竞争、内存压力和网络排队都会使吞吐量增速放缓所以 200TPS 是理想上限不是承诺值。这类估算的意义在于给业务方一个性能余量的数量级概念如果日常并发只有 20 人那现在的 30TPS 支撑有余如果业务冲刺时会到 100 人就必须重跑一轮 100 用户的压力测试来验证真实拐点。5. 用 JMeter 复现这套测试需要注意的三处设置5.1 线程组的 Ramp-Up 先换算再填写LoadRunner 的逐步加压对应 JMeter 线程组的 Ramp-Up Period 字段。LoadRunner 每 2 秒启动 1 个用户、共 15 个用户的模型在 JMeter 里要换算成15 个线程共用 30 秒完成加载也就是线程数填 15Ramp-Up Period 填 30 秒。这里最容易配错的是直接填 0填 0 等于瞬时加压得到的响应时间曲线会明显高于逐步加压的结果和 LoadRunner 压出的 20ms 没有可比性。5.2 同步定时器与思考时间的语义差异LoadRunner 的集合点对应 JMeter 的同步定时器Synchronizing Timer要放在注册和登录请求之前并将同步用户数设置为当前线程数也就是 15才能实现所有用户在同一时刻压向接口。思考时间用固定定时器或高斯随机定时器模拟但注意 JMeter 的定时器作用于整个采样过程与 LoadRunner 的 think time 在时间轴上覆盖的范围略有不同复现时优先用高斯随机定时器给用户停顿加一点随机性更接近真实行为。5.3 用成功样本数计算 TPS 再做对比JMeter 聚合报告默认对所有采样点取平均会把失败样本也计算在内。要统计成功事务 TPS需要在非 GUI 模式下运行并手动处理结果文件# 运行 JMeter 非 GUI 模式生成结果与 HTML 报告 jmeter -n -t web-tours.jmx -l result.jtl -e -o report/ # 统计成功样本数量TPS 成功样本数 / 运行时长秒 grep -c success result.jtl # 查看最大响应时间用于与 LoadRunner 最大响应时间对照 awk -F, {print $2} result.jtl | sort -n | tail -1参数说明-n 表示非 GUI 模式-t 指定测试计划文件-l 输出原始结果到 jtl 文件-e 和 -o 生成 HTML 可视化报告。最终拿成功样本数除以全部线程运行完成的实际秒数得到 TPS与 LoadRunner 压出的 30TPS 对照。偏差在 10% 以内说明场景模型一致超出 10% 优先检查 Ramp-Up 是否换算错、同步定时器是否真正生效、Cookie 管理器是否缺少导致登录请求失败。本文还有配套的精品资源点击获取