性能测试阶段1之性能测试理论

https://blog.csdn.net/weixin_45912307/article/details/120106621

01 基本概念

1. 基本目的:

  • 测试系统性能是否达标(性能:系统处理能和运行能力)
  • 找到性能瓶颈

2. 基本方法: 基准 负载 压力

02核心原理

基本原理:基于协议通过多线程方式模拟用户并发,在不同的场景下施压服务器
1. 基于协议(http tcp udp https mq dubbo socket websocket)发起请求

2. 通过多线程的方式模拟并发用户,施压服务器

3. 设计场景:方法,元件,关联,断言,思考时间,集合点

03应用领域

能力验证: 系统能否在固定条件下具有声明的能力

  • 通过性能测试得到测试结果,给予测试报告

瓶颈发现: 通过一系列的性能测试手段发现瓶颈和缺陷
性能调优: 针对发现的性能瓶颈对系统性能的调优

  • tps瓶颈
  • 响应时间
  • 服务资源瓶颈
  • sql瓶颈

容量规划: 系统能否支持未来一段时间内的用户增长?

  • 针对未来可能存在的业务量爆发
  • 以预计的用户量为基数,做对应的性能测试;
  • 提前调整硬件设施

04测试思路

4.1 测什么?

1. 前端:更多关注加载和响应时间

  • web端
  • app端

2. 服务端

  • 工具层面:错误率和吞吐量
  • 服务器层面:cpu、内存、io、jvm

3. 数据库:慢sql、死锁

4.2 怎么测

1. 需求分析与测试设计

  • 1.根据具体的性能测试需求,确定测试类型以及压测的模块(web/mysql/redis/系统整体)
  • ⒉.前期要与相关人员充分沟通,初步确定压测方案及具体性能指标
  • 3.QA完成性能测试设计后,需产出测试方案文档发送邮件到项目组,并且再次与相关人员沟通(或者组织性能测试评审),确认是否满足需求

2. 环境设计与搭建

  • promethus + Grafana(node_exporter,mysqld_exporter,redis_exporter,自定义exporter,全家桶)

3. 测试数据准备

  • 1.接口请求参数:自己构造/日志获取/上下关联;
  • ⒉数据表的数据填充﹔
  • 3.如果是多接口,则需结合业务场景设计请求比例。

4. 性能指标预期

  • 1.每秒请求数(QPS)
  • ⒉请求响应时间(最小、最大、平均)
  • 3.错误率
  • 4.机器性能: cpu idle 30%、memory无剧烈抖动或者飙升
  • 5.压测过程接口功能是否正常

注:不同性能测试方式下指标预期会有差异

5. 发压工具配置及脚本编写

  • 1.JMeter工具介绍
    ⑴集成包,解压即可使用,Windows、Linux通用(依赖java环境)
    (2)jmx脚本为xml文件,Win、Linux环境均可直接运行
    ⑶多线程并发
    (4)运行完脚本会生成jtl日志,可在Win环境界面工具中查看、统计
  • 2.脚本的编写
    (1)http、https请求
    (2)其它
  • 3.命令∶
    • 启压: ./jmeter -n -t hb.jmx -l hb.jtl

6. 数据监控

  • 1.测试前环境检查:记录机器参数
  • 2.起压:根据被压情况,调节并发量到适合的情况
  • 3.查看记录各项性能指标
    • (1) nginx日志查看每秒请求数
    • (2)查看nginx错误请求
    • (3)查看机器参数: cpu、 idle、memory、io等
    • (4)查看db、cache等数据是否写入正常
    • (5)访问接口,查看功能是否正常

7. 结果分析

  • 1.根据测试过程中记录的各项参数,结合压测工具产生的日志,对测试结果进行分析,并产出测试报告
  • 2.测试完成后,及时与相关人员沟通,确认是否满足需求

8. 性能调优

  • 根据测试结果分析给出明确的性能优化依据

9. 提交报告

  • 发送测试报告邮件

4.3 测试结果是否通过

  1. 有需求: 测试结果符合预期
  2. 无需求:测试页面/服务器最大并发数

05性能指标

5.1 前端性能指标

1.响应时间RT(response time)

  • 258原则:2s内很满意;5s一般;8s不能接受
  • 前端响应时间:前端将后端查询到的数据在页面呈现出来
    • 前端资源加载渲染的时间
    • 前后端交互的时间
  • 网络连接时间:请求发出到服务端接收到的中间时间
    • latency:延迟
      • latency = 网络连接时间 + 服务处理返回的时间
    • connect time:连接时间
  • 服务端响应时间
    • latency - connect_time = 服务处理时间
  • 补充:响应时间划分
    • 用户通过客户端向服务端发出请求的时间为:T1
    • 服务端接收到请求,处理该请求的时间为:T2
    • 服务端返回数据给客户端时间为:T3
    • 客户端接收到响应数据,处理数据呈现给用户时间- 为:T4

2.错误率
银行、金融、税务
3.点击率
用户点击按钮,发送请求的次数
4.吞吐量

  • 1.hps(hit persecond) 每秒点击数

  • 2.tps(transaction persecond)
    每秒完成响应的请求数(每秒处理事务数)

    • 单接口业务:单位时间内完成响应的请求数
    • 多接口业务:单位时间完成的事务数(多个接口连在一起,一整个流程的完成视为一个事务
  • 3.rps(request persecond) 单位时间发起的的请求数

    • rps是发起请求,tps是处理请求
    • rps 并发 直接从服务端衡量压力值
    • 压力是由用户决定;处理能力是由服务端决定
    • rps衡量压力,tps衡量服务端/系统的性能
    • 优化服务端性能,让tps去匹配rps
    • qps(tps)= 并发数/平均响应时间
  • 4.qps 每秒查询数
    每秒响应请求数,也就是最大吞吐能力

5.2 服务端性能指标

1. cpu
2. 内存
3. io
4. JVM
5. 中间件:redis、ngnix、tomcat

06性能视角

6.1 用户视角

  1. 响应时间
  2. 系统稳定性
  3. 上传下载文件资源
  4. 项目运行一段时间,系统宕机

6.2 开发视角

1. 代码是否需要优化
2. sql优化
3. 系统架构优化

6.3 运维视角

1. 硬件设施是否需要更换

2. 资源利用是否达标

  • 利用率超标
  • 利用率过低

3. 系统容量

  • 一个用户在线,保持session,大概消耗10k内存
  • 4g内存 能保证10w用户同时挂机

07测试类型

1.基准测试
每一次版本迭代都需要做基准测试
目的:对比上一次测试结果,给出调优依据

2.负载测试 持续不断的施加压力:找到系统瓶颈点(tps、资源)
保证压力连续性

  • 并发用户模型:持续不断的增加并发用户
  • rps模型:持续不断的增加请求数

3.压力测试
资源:

  • 当资源处于一个饱和状态
  • cpu利用率超过90%
  • 在资源饱和情况下持续运行服务,考察系统稳定性

负载:

  • 负载处于一个高峰
  • 在500rps负载下最大tps达到400/s,此时以500rps压力持续运行一段时间

稳定性测试:

  • 最大压力的80%持续运行

破坏性测试:

  • 知道最大压力值,依然不断增加压力,让系统崩溃

4.失效恢复测试
系统异常之后,能否及时恢复正常

5.容量测试
考察系统在未来时间段内支撑的用户数
测试大容量下,系统需要的硬件设施

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值