性能测试入门知识
- 当需求文档中有一个性能测试需求，应该怎么动手？
- 性能需求的准确性能把握吗？ ---流量采集和流量回放
- 第一阶段：
- 第一步：先怀疑需求准确性
- 第二步：拿运维的数据来确定需求准确性
- 第三步：和产品人员沟通来确定性能目标
- 第二阶段：性能脚本编写
- 第三阶段：场景设计、搭建环境、
- 第四阶段：搭建监控
- 第五阶段：性能测试执行、问题分析调优
- （做不了的：涉及到代码的调优
- 做的了的：涉及到参数的修改，比如服务器的参数，数据库里的参数配置（重灾区））
性能概念
- IT中的性能概念：
- 最明显的感受：响应时间、稳定性、同时支持多少人使用
- 性能：用不同的角度来衡量被测对象，给出一些数据，通过这个数据判断性能好坏
- 后端的性能测试就是通过接口采用协议来传递数据到服务器，看服务器能够承受多少的数据，把相关的指标给体现出来
性能测试
- 概念：通过工具，找出或获得系统在不同情况下的性能指标值
- 做性能测试的时间只需要几分钟到十几分钟
- 性能测试要通过工具对服务器发起多用户请求，如果发起用户只有1个，就不是性能测试
- 100个人，请求1次=======性能测试
- 1个人，请求100次 ======不是性能测试
- 性能测试工具
- Jmeter工具，使用线程来模拟多用户
- Loadruner工具，使用线程或进程方式模拟多用户
- ngrinder工具，使用进程+线程组合方式来模拟多用户
- Loust工具，使用的是协程来模拟多用户
- 找出或获得：
- 第一次做性能测试，找出性能数据
- 不是第一次做性能测试，获取新的性能测试数据
- 性能测试完成，得到一批性能指标数据:
- 从不同的角度衡量服务器的性能数据
- 时间：平均响应时间数据
- 并发用户数数据：同一时间有多少并发用户数请求
- TPS数据：服务器每秒能处理多少个事务数
- 资源利用率数据：服务器再一段时间中，资源使用情况
- 网络：吞吐量、吞吐率
- 多少在线用户：
- 在线，但是不请求
- 在线，同时有请求
- 行业中，一般用在线用户的5%-10%作为并发用户数
- 二八法则：来自于前端性能测试，调用前端接口来请求服务器，
- 80%的请求发生在20%的请求里：比如一天访问量100w，80w的请求发生在20%（24h/天）的时间里
- 80W/（24h*3600s*0.2）=46个/s
负载测试：
-
- 通过逐步增加并发用户数，来找出我们最大并发用户数区间
- 并发：同一时间有多少个请求
- 并行：在不同通道上，有多少个在做，可以是不同的线程处理
- 所以，在不知道系统的最大能支持多少并发用户数时，先通过负载测试得到最大并发用户数后，使用工具来模拟最大用户数的线程来做性能测试，就可以得到性能测试的指标值
- 一般而言，如果产品大概在百万级别，要求的并发只有几十到小几百并发用户数
- 一般负载测试的时候，每测一段并发用户数的持续时长只需要十几秒到几分钟
- 怎么判断最大并发用户数区间？====一般用最大可接受的并发用户数来进行性能测试
- 1.看请求的结果是否有连续性报错出现
- 2.平均响应时间（在当前并发用户数时的平均时间）不超过1.5s
- A.如果在20并发用户数的时候，平均响应时间没有超过1.5s，但是30的时候超过了，说明并发用户数的区间是20~30
- B.并发用户数，在一段时间内发送多少请求与频率有关
- C.请求数！=并发用户数
- 总的请求数=并发用户数*频率*时间
- D.不超过1.5s是行业对接口的默认标准
- 1.5s是用户能接受的响应时间（如果没有报错，就看有没有超过1.5s）
- 3.tps趋势是否有明显下降（服务器每秒处理的请求数在下降）
- A.找具体值
- 用区间下沿与区间上沿在设计一个负载场景，假设区间是【20~30】，就从20开始1个1个的往上加并发数，找到具 体值
压力测试:
- 使用一定量的并发用户数，持续运行一段时间（一般以小时为单位），看服务器的稳定性
- 一定量的并发用户数，来自于产品的最大可接受的并发用户数的20~80%并发数
性能概念
广义的性能测试是包括服务器性能的所有概念
稳定性测试是压力测试的一种，
- 企业中说的压测：
- 第一步：通过负载测试找到最大可接受的并发用户数
- 第二步：然后用最大可接受的并发用户数做性能测试
- 第三步：才能得到性能指标值
- 如果环境有宕机的情况，需要去做一个压测就是：负载测试+性能测试+压力测试
容量测试
- 数据库的数据量级别在万级、十万级、百万级就会差异了（万级之前可以忽略不计）
- 查询接口响应的时间与索引有关系
- 性能测试的时候，用的数据库表的数据量级别最好与生产环境的一致或者更高
- 性能测试的前提：
- 核心功能：用户使用量最多的优先级靠前
- 架构调整
- 重大缺陷修复
- 性能指标量化
- A.产品出的需求不一定专业，跟产品沟通清楚需求
- B.需求重性能指标一定要量化为数字
- 多少的并发用户数、平均响应时间多少以内、错误率在多少以内、资源利用在 多少以内...tps要能达到多少===都需要有明确的数据出来
