综合实践之诊断分析与调优

一、需求分析

针对性能测试需求分析,重点完成两项工作
1. 采集性能测试测试需求
1) 系统架构(系统网络架构图,物理架构图,设备->设备)
2) 采集业务并发量(业务流程图)
3) 了解业务扩展趋势(业务流程图)
4) 业务发生时段(周一~周五晚7点)
5) 采集在线用户数,活动用户数,业务分布
6) 采集业务性能指标
7) 采集系统硬件指标(硬件范围是否符合用户需求)
根据需求文档中有关非功能性需求的说明,明确性能指标
1)吞吐量:是指单位时间内系统处理的请求数量,能直接反应服务器承受的压力,需要重点关注的指标。
a. 当系统没有遇到性能瓶颈时,可采用公式:F=NvuR/T
(F为吞吐量,Nvu为虚拟用户个数,R为在T时间内每个VU发出的请求字节数,T为性能测试所有的时间)。
b.
2)响应时间:是用户感受到软件系统为其请求耗费的时间
a. 响应时间:2-5-8原则
b. 响应时间=网络传输(请求时间)+服务器处理时间(一层或多层)+网络传输(响应)时间+页面前端解析渲染时间。
3)成功率:99%以上
4)TPS:每秒通过事务数:是直接反映系统性能的指标,该值大时,系统性能会比较艰险,当然每个系统都有它的上限,不可能无限大。将它与平均事务响应时间进行比对,可以分析事务数量对响应时间的影响。
5)并发数:并发测试可以理解为很多的用户按照预定的场景并发某个业务或功能时是否出现并发问题,如:内存泄露、线程锁、资源争用等。
a. 80-20 原则:并发数=在线用户数
20%
b. 并发数=PV/PV Time页面连接次数HTTP 响应时间因数/web 服务器数量
(PV:页面浏览量;PV Time:PV 的统计时间,换算成秒;页面连接次数:包括外部的 JS\CSS\图片等,一般为 10;HTTP 响应时间:一般可以为 1s 或者更少;因数:一般为 5)
【假设】有一个网站每天有 6 万 PV,其余参数保持黑认,那么推算出来的并发数大致公式如下:
60000/86400
1015/1=35
2.分析性能测试需求

  • 业务名称 高峰业务量 TPS 并发数 响应时间 事务成功率
  • 登录 1300PV/小时 1.44 20 ❤️ 秒 >99%
  • 浏览帖子 2706PV/小时 3.0 40 ❤️ 秒 >99%
  • 发新帖 526 PV/小时 0.58 7 ❤️ 秒 >99%
  • 回复帖子 676 PV/小时 0.75 10 ❤️ 秒 >99%
    合计 5.8 77

二、测试模型

1.业务模型:业务流程(各业务在哪个时间段运行,业务种类,业务占比)
2.测试模型:从业务中挑选出高资源
3.性能测试场景:按照用户使用习惯设计负载场景(比如哪些业务一起运行,哪些业务有先后顺序,运行多少并发用户)

三、测试计划

1.系统概述(详细清晰)
2.测试环境(开发环境,测试环境,硬件环境)
3.需求分析(采集性能测试需求,确认性能测试范围)
4.测试策略(测试手段LR)
5.测试场景(组合场景)
6.测试准备(环境和数据准备)
7.时间计划
8.测试组织架构
9.交付物清单
10.系统风险(风险和应对方案)

四、环境搭建

  1. 登录
  2. 浏览帖子
  3. 回复帖子
  4. 发帖

五、脚本开发(JMeter/LR)

六、数据准备

七、场景设计

八、测试监控

九、测试执行

十、结果分析

十一、测试报告

发布了18 篇原创文章 · 获赞 13 · 访问量 2313

猜你喜欢

转载自blog.csdn.net/m0_37518413/article/details/103336679