一、测试目的验证登录页、首页、题目列表页、比赛列表页、讨论列表页在常规访问与并发场景下的响应速度、页面加载稳定性。检测系统接口请求、数据渲染、榜单刷新等核心流程的吞吐量与耗时定位性能瓶颈。评估多用户同时访问时系统CPU、内存、网络等资源占用情况确保无资源泄漏与服务异常。验证页面在持续访问压力下的可用性、错误率保障系统稳定运行。为系统容量规划、前端渲染优化、后端接口优化提供数据支撑。二、测试范围一页面功能性能范围登录页账号密码输入、登录验证、登录跳转、错误提示的响应与稳定性。首页公告加载、统计数据展示、最新题目列表、近期竞赛信息渲染。题目列表页题目数据查询、分页加载、题目信息展示、筛选/搜索响应。比赛列表页竞赛状态、时间、类型、排名数据加载与刷新性能。讨论列表页帖子列表加载、评论数展示、发布时间渲染、列表滚动性能。二非功能性能范围响应性能各页面打开耗时、接口请求响应时间。并发性能多用户同时访问页面的并发承载能力。稳定性持续访问下服务可用性、页面报错率。资源占用服务器/前端资源使用率无异常飙升。三、测试工具1JMeterJMeter 是开源的性能测试工具用于模拟多用户并发请求并生成性能报告。2PostmanPostman 是 API 接口测试工具支持接口功能验证与请求调试。四、测试步骤1准备工作使用jmeter之前会用postman对接口进行简单测试这里列举了登录接口2添加线程组和http请求3http请求默认值4http信息头管理器如果不设置http信息头管理器运行后会出现错误那么原因是什么呢5CSV数据文件设置6登录接口7用户信息8题目列表注意消息数据体里的文本格式9比赛列表10排名列表11讨论列表五、测试执行1 启动 JMeter 测试计划jpgc - Stepping Thread Group按照配置的阶梯压测线程组逐步增加并发用户数。2实时监控jpgc - Active Threads Over Time并发用户趋势、jpgc - Response Times Over Time响应时间趋势、jpgc - Transactions per Second吞吐量趋势等监听器记录测试过程中的关键性能表现。3查看结果树和聚合报告4测试结果收集Active Threads Over Time活跃线程数含义模拟的并发用户数随时间的变化曲线。关键观察线程数阶梯式上升最终稳定在 20并发用户持续了约1分钟然后阶梯下降。说明这是一个逐步加压、稳定负载、然后减压的负载测试不是一次性冲满的压力测试。Response Times Over Time响应时间随时间变化含义每个接口的响应耗时单位ms随时间的变化。关键观察排名列表接口红色线 表现最差出现多次明显峰值最高冲到 2100ms2.1s还有多次1500ms以上的尖刺。大部分时间在300-900ms之间波动是明显的性能瓶颈点。其他接口登录、题目列表、比赛列表、讨论列表、用户信息响应时间基本都稳定在 200ms以内表现非常平稳没有明显波动。Transactions per SecondTPS每秒事务数含义每秒成功处理的请求数代表系统的吞吐量。关键观察所有接口的TPS曲线趋势一致随线程数增加逐步上升稳定期峰值在 30-40 TPS 之间波动。没有出现持续下跌或断崖式下降说明系统在20并发下没有出现严重的“吞吐量崩溃”。 测试结束阶段TPS随线程数下降而回落符合预期。综合分析结论 ✅系统表现好的方面1大部分接口性能良好登录、题目/比赛/讨论列表、用户信息接口在20并发下响应稳定耗时都在200ms以内满足基础使用需求。2 系统稳定性尚可20并发持续压测1分钟没有出现服务崩溃、5xx错误吞吐量也没有持续下降说明系统基础抗压能力合格。⚠️ 核心性能问题 排名列表接口是明显瓶颈响应时间远高于其他接口峰值达到2.1s多次超过1s用户体验会明显卡顿。响应时间波动大说明接口在高并发下不稳定可能存在数据库查询未优化如未建索引、全表扫描、关联查询过慢数据量大时排序/分页效率低- 缓存缺失每次请求都要重新计算/查询排名虽然整体TPS没有明显下跌但该接口的高耗时会拖慢用户体验甚至可能引发超时。六、生成测试报告jmeter测试报告是一个全面而详细的文档它提供了关于测试执行结果的详细信息帮助用户全面评估系统的性能并进行性能优化。七、个人总结本次我以 20并发用户、阶梯加压的负载场景 为核心对OJ系统的登录、用户信息、题目列表、比赛列表、排名列表、讨论列表六大核心接口进行了完整的性能压测结合JMeter的活跃线程、响应时间、TPS及聚合报告数据完成了对系统性能的全面验证。现将个人测试收获与反思总结如下1.测试工作成果回顾完成了完整的性能测试闭环从测试计划搭建、场景设计、脚本录制到执行压测、数据分析我独立完成了全流程操作验证了系统在20并发下的功能稳定性与性能表现。- 所有接口异常率为0%无服务宕机、请求报错系统基础抗压能力合格。- 总体吞吐量达到139.3 TPS平均响应时间128ms大部分接口性能优秀满足基础使用需求。精准定位了系统的核心性能瓶颈通过多维度数据交叉分析我发现 排名列表接口 是本次测试中最突出的性能短板- 该接口平均响应时间385ms99%分位达2086ms最大响应时间高达8763ms远高于其他接口是影响用户体验的关键卡点。- 同时也排查出登录、比赛列表接口存在偶发高耗时问题为后续优化提供了明确方向。2.测试过程中的收获与成长掌握了JMeter性能测试的完整流程本次测试让我从理论走向实操熟练掌握了阶梯加压线程组、HTTP请求配置、结果树查看、聚合报告分析、响应时间/TPS等关键指标解读的方法理解了并发数、吞吐量、响应时间三者之间的关系不再局限于“能跑起来”而是学会了“读得懂、分析得透”。建立了“数据交叉验证”的性能分析思维我学会了结合活跃线程数、响应时间曲线、TPS曲线与聚合报告数据进行多维度验证避免单一指标误判。例如通过响应时间折线图发现排名接口的尖刺再用聚合报告的分位值和最大值确认问题的严重性形成了完整的证据链让性能分析更具说服力。深化了对系统性能瓶颈的理解本次测试让我明白OJ系统的性能短板往往集中在“数据量大、计算复杂”的接口上比如排名列表需要频繁的排序、统计操作是天然的性能瓶颈点。这也让我理解了缓存、异步计算、数据库索引优化等方案在实际场景中的价值为后续的开发与优化提供了实践认知。3.不足与改进方向测试场景仍需扩展本次仅完成了20并发的基础负载测试未进行更高并发如50/100用户的压力测试和长时间稳定性测试无法验证系统的性能上限与长期运行的稳定性后续需要补充这部分场景。问题定位的深度有待加强目前仅定位了排名接口的性能问题但未深入排查具体的根因如SQL执行效率、缓存命中率等。后续我将学习结合服务器监控、数据库慢查询日志等工具进一步定位问题根源提出更具针对性的优化方案。测试方案的设计可以更完善本次测试的场景较为单一后续可以增加“用户登录多页面混合访问”的真实用户场景测试更贴近线上实际使用情况让测试结果更具参考价值。