OJ系统性能测试报告

一、测试目的

1. 验证登录页、首页、题目列表页、比赛列表页、讨论列表页在常规访问与并发场景下的响应速度、页面加载稳定性。
2. 检测系统接口请求、数据渲染、榜单刷新等核心流程的吞吐量与耗时，定位性能瓶颈。
3. 评估多用户同时访问时，系统CPU、内存、网络等资源占用情况，确保无资源泄漏与服务异常。
4. 验证页面在持续访问压力下的可用性、错误率，保障系统稳定运行。
5. 为系统容量规划、前端渲染优化、后端接口优化提供数据支撑。
   二、测试范围
   （一）页面功能性能范围

• 登录页：账号密码输入、登录验证、登录跳转、错误提示的响应与稳定性。
• 首页：公告加载、统计数据展示、最新题目列表、近期竞赛信息渲染。
• 题目列表页：题目数据查询、分页加载、题目信息展示、筛选/搜索响应。
• 比赛列表页：竞赛状态、时间、类型、排名数据加载与刷新性能。
• 讨论列表页：帖子列表加载、评论数展示、发布时间渲染、列表滚动性能。
  （二）非功能性能范围
• 响应性能：各页面打开耗时、接口请求响应时间。
• 并发性能：多用户同时访问页面的并发承载能力。
• 稳定性：持续访问下服务可用性、页面报错率。
• 资源占用：服务器/前端资源使用率，无异常飙升。
  三、测试工具
  （1）JMeter
  JMeter 是开源的性能测试工具，用于模拟多用户并发请求并生成性能报告。
  （2）Postman
  Postman 是 API 接口测试工具，支持接口功能验证与请求调试。
  四、测试步骤
  （1）准备工作：使用jmeter之前会用postman对接口进行简单测试（这里列举了登录接口）
  
  （2）添加线程组和http请求
  
  （3）http请求默认值
  
  （4）http信息头管理器
  如果不设置http信息头管理器，运行后会出现错误，那么原因是什么呢？
  
  
  （5）CSV数据文件设置
  
  （6）登录接口
  

（7）用户信息

（8）题目列表

（注意消息数据体里的文本格式）
（9）比赛列表

（10）排名列表

（11）讨论列表

五、测试执行
（1） 启动 JMeter 测试计划，jp@gc - Stepping Thread Group按照配置的阶梯压测线程组逐步增加并发用户数。
（2）实时监控
jp@gc - Active Threads Over Time（并发用户趋势）、
jp@gc - Response Times Over Time（响应时间趋势）、
jp@gc - Transactions per Second（吞吐量趋势）等监听器，记录测试过程中的关键性能表现。
（3）查看结果树和聚合报告

（4）测试结果收集

1. Active Threads Over Time（活跃线程数）

• 含义：模拟的并发用户数随时间的变化曲线。
• 关键观察：
  线程数阶梯式上升，最终稳定在 20并发用户，持续了约1分钟，然后阶梯下降。
  说明这是一个逐步加压、稳定负载、然后减压的负载测试，不是一次性冲满的压力测试。

2. Response Times Over Time（响应时间随时间变化）

• 含义：每个接口的响应耗时（单位ms）随时间的变化。
• 关键观察：
  排名列表接口（红色线） 表现最差：出现多次明显峰值，最高冲到 2100ms（2.1s），还有多次1500ms以上的尖刺。大部分时间在300-900ms之间波动，是明显的性能瓶颈点。
  其他接口（登录、题目列表、比赛列表、讨论列表、用户信息）：响应时间基本都稳定在 200ms以内，表现非常平稳，没有明显波动。

3. Transactions per Second（TPS，每秒事务数）

• 含义：每秒成功处理的请求数，代表系统的吞吐量。
• 关键观察：
  所有接口的TPS曲线趋势一致，随线程数增加逐步上升，稳定期峰值在 30-40 TPS 之间波动。没有出现持续下跌或断崖式下降，说明系统在20并发下没有出现严重的“吞吐量崩溃”。 测试结束阶段TPS随线程数下降而回落，符合预期。

4. 综合分析结论 ✅
   系统表现好的方面
   （1）大部分接口性能良好：登录、题目/比赛/讨论列表、用户信息接口在20并发下响应稳定，耗时都在200ms以内，满足基础使用需求。
   （2） 系统稳定性尚可：20并发持续压测1分钟，没有出现服务崩溃、5xx错误，吞吐量也没有持续下降，说明系统基础抗压能力合格。
   ⚠️ 核心性能问题 排名列表接口是明显瓶颈：

• 响应时间远高于其他接口，峰值达到2.1s，多次超过1s，用户体验会明显卡顿。
• 响应时间波动大，说明接口在高并发下不稳定，可能存在：
  数据库查询未优化（如未建索引、全表扫描、关联查询过慢）
  数据量大时排序/分页效率低- 缓存缺失，每次请求都要重新计算/查询排名
  虽然整体TPS没有明显下跌，但该接口的高耗时会拖慢用户体验，甚至可能引发超时。
  六、生成测试报告
  jmeter测试报告是一个全面而详细的文档，它提供了关于测试执行结果的详细信息，帮助用户全面评估系统的性能并进行性能优化。
  
  
  
  
  
  
  七、个人总结
  本次我以 20并发用户、阶梯加压的负载场景 为核心，对OJ系统的登录、用户信息、题目列表、比赛列表、排名列表、讨论列表六大核心接口进行了完整的性能压测，结合JMeter的活跃线程、响应时间、TPS及聚合报告数据，完成了对系统性能的全面验证。
  现将个人测试收获与反思总结如下：
  1.测试工作成果回顾
  完成了完整的性能测试闭环从测试计划搭建、场景设计、脚本录制到执行压测、数据分析，我独立完成了全流程操作，验证了系统在20并发下的功能稳定性与性能表现。- 所有接口异常率为0%，无服务宕机、请求报错，系统基础抗压能力合格。- 总体吞吐量达到139.3 TPS，平均响应时间128ms，大部分接口性能优秀，满足基础使用需求。
  精准定位了系统的核心性能瓶颈通过多维度数据交叉分析，我发现 排名列表接口 是本次测试中最突出的性能短板：
  - 该接口平均响应时间385ms，99%分位达2086ms，最大响应时间高达8763ms，远高于其他接口，是影响用户体验的关键卡点。
  - 同时也排查出登录、比赛列表接口存在偶发高耗时问题，为后续优化提供了明确方向。
  2.测试过程中的收获与成长
  掌握了JMeter性能测试的完整流程本次测试让我从理论走向实操，熟练掌握了阶梯加压线程组、HTTP请求配置、结果树查看、聚合报告分析、响应时间/TPS等关键指标解读的方法，理解了并发数、吞吐量、响应时间三者之间的关系，不再局限于“能跑起来”，而是学会了“读得懂、分析得透”。
  建立了“数据交叉验证”的性能分析思维我学会了结合活跃线程数、响应时间曲线、TPS曲线与聚合报告数据进行多维度验证，避免单一指标误判。例如，通过响应时间折线图发现排名接口的尖刺，再用聚合报告的分位值和最大值确认问题的严重性，形成了完整的证据链，让性能分析更具说服力。
  深化了对系统性能瓶颈的理解本次测试让我明白，OJ系统的性能短板往往集中在“数据量大、计算复杂”的接口上，比如排名列表需要频繁的排序、统计操作，是天然的性能瓶颈点。这也让我理解了缓存、异步计算、数据库索引优化等方案在实际场景中的价值，为后续的开发与优化提供了实践认知。
  3.不足与改进方向
  测试场景仍需扩展本次仅完成了20并发的基础负载测试，未进行更高并发（如50/100用户）的压力测试和长时间稳定性测试，无法验证系统的性能上限与长期运行的稳定性，后续需要补充这部分场景。
  问题定位的深度有待加强目前仅定位了排名接口的性能问题，但未深入排查具体的根因（如SQL执行效率、缓存命中率等）。
  后续我将学习结合服务器监控、数据库慢查询日志等工具，进一步定位问题根源，提出更具针对性的优化方案。
  测试方案的设计可以更完善本次测试的场景较为单一，后续可以增加“用户登录+多页面混合访问”的真实用户场景测试，更贴近线上实际使用情况，让测试结果更具参考价值。