性能测试基础

概念、术语

并发：tps
线程数：跑道里参加赛跑的人数
迭代（jmeter中叫循环次数）：每个人跑多少圈
循环（jmeter中是循环控制器）：一次迭代里，反复执行其中一段脚本，就是反复来回跑其中一段跑道
参数值：发请求时用的数据
参数化：是一种策略，可根据参数策略获取参数值
关联：下一个请求入参依赖上一个请求的某个返回值
思考时间：模拟用户等待的时间
检查点：判断去请求的是否成功，一般只查询请求才加检查点
集合点：同一时刻去发起请求，主要应用场景是秒杀
事务：一般被测的某个或者某几个请求一起定义为一个事务，是认为的测试定义
负载：服务器的繁忙程度，如果一个8c的服务器，每次可以同时处理8个请求，如果请求量大，后面的请求就排队，排队的请求越多，服务器的负载就越高
平均响应时间（art）：每个事务的处理时间，从发送请求到接收到响应
tps:每秒处理的请求数
场景：设置并发策略，模拟用户使用的场景
分析：场景运行完，生成各种维度的结果

性能测试流程

1.前期准备
业务需求评审就加入项目，深入了解业务、重要功能的需求和逻辑
2.性能需求分析（评审）
明确性能测试范围、目标，由于非专业性能测试人员不知道如何定目标，所以最好引导产品、需求或者开发出目标，避免只有测试背锅。
基于接口或者场景（流程）的性能测试指标，一般是tps(每秒事务数，这里都是通过的事务)、art(平均响应时间)及并发数，加上服务器资源利用率的要求（cpu、内存、IO、网络等）。
3.熟悉系统架构，申请性能测试环境
用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等，画出系统架构图，理解其中的逻辑;对需要监控的服务提前做技术准备。
4.制定性能测试方案
计划什么时候做什么事，需要的资源，技术策略（比如监控分析工具的选择等等）、用例设计
5.搭建测试环境，准备测试数据
数据库的存量数据+增量数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的，这个数据量根据生产环境获取；数据最好是有标识、有规律的数据
6.主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行）
参数化、关联、事务、检查点、思考时间等，造参数化测试数据。
另外，这里涉及到场景的涉及：单场景、混合场景、稳定想场景、异常场景
7.预测试（环境确认测试）
跑一个用户，看压测环境功能是否通
估算并发过程中需要多少参数化数据的数据量
8.执行压测并监控服务器资源等
看测试指标是否满足需求，从请求开始，一步一步排查请求流经的节点，包含服务器资源（cpu、内存、磁盘IO、网络）是否存在性能瓶颈、各种连接等是否存在性能瓶颈
9.分析定位
基于上一步的监控数据，对瓶颈进行分析、定位。全流程排查、模块隔离分析、日志分析
10.性能优化
11性能回归
12.编写性能报告
测试结果，测试是否通过；发现、解决什么问题，系统性能提升了多少被；如何调优的，改了什么东西，以便上线同事知道

性能测试场景用例

举例：某性能测试需求
核心业务接口：查询礼品、兑换礼品、查询订单
业务模型：查询礼品:兑换礼品:查询订单=2:1:1
总tps>=100
每个业务的rt<500ms
持续稳定跑50万业务量

单场景
目的：找到单场景的性能问题，为容量场景提供参考，如果低于容量场景中此接口的目标tps，那肯定要先优化
根据性能需求，单场景中
查询礼品 tps>=50
兑换礼品 tps>=25
查询订单 tps>=25

数据库存量数据
礼品：10000
库存：10000
订单：100000

参数化数据设计
查询礼品：10000
查询订单：10000

开启慢查询及设置阈值
vim my.cnf
开启慢查询
slow_query_log=1
slow_query_log_file=/mysql/logs/slow.log

阈值
long_query_time=0.05 （注：0.05及对应rt的500ms）

混合场景
目的：通过业务模型模拟线上的真实业务场景
设计方式：
1.每个场景设置一个线程组
2.使用if控制器
通过if控制器，设置条件判断随机数大于20，就执行http1接口

设置条件判断随机数小雨等于20，就执行http2接口

汇总采样查看执行的情况

3.使用吞吐量控制器
线程组总共设置100线程，
添加吞吐量控制器，场景1设置80吞吐量

场景2设置20吞吐量

执行线程组，查看执行情况

稳定性场景
目的：系统长时间运行，业务数据积累对系统的影响
性能需求期望稳定跑业务量是50万，最大tps是100，则最少需要跑的时间是：50万/100=5000秒，可适当多加10%-20%的时间

异常场景