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

最新推荐文章于 2024-10-11 11:42:07 发布

置顶 JSon liu

最新推荐文章于 2024-10-11 11:42:07 发布

阅读量322

点赞数

分类专栏：笔记合集文章标签：性能测试理论软件测试

本文链接：https://blog.csdn.net/weixin_45912307/article/details/120106621

版权

笔记合集专栏收录该内容

2 篇文章 0 订阅

订阅专栏

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

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

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 测试结果是否通过

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

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 每秒查询数
每秒响应请求数，也就是最大吞吐能力