一、性能测试常用术语
1. 并发：跑到里参加赛跑的人
2.迭代：每个人跑多少圈
3.循环：一次迭代里面，反复执行其中一段脚本，就是反复来回跑其中一段跑道
4.参数值：发请求时候用的数据
5.参数化：是一种策略，可以根据参数策略获取参数值
6.思考时间：模拟用户等待的时间
7.关联：下一个请求入参依赖上一个请求的某个返回值
8.检查点：判断请求是否成功，一般只有查询请求才加检查点
9.集合点：同一时刻去发起请求，主要应用场景是秒杀
10.事务：一般把被测的某个或者某几个请求一起定义为一个事务，是人为的测试定义
11.负载：服务器的繁忙程度，如果一个8c的服务器，每次可以同时处理8个请求。如果请求量大，后面的请求就需要排队，排队的请求越多，服务器的负载就越高
12.平均响应时间（art）：每个事务的处理时间，从发送请求到接收响应
13.tps：每秒处理的事务数
14.每秒点击率（数）：每秒处理的请求数，而不是用户每秒发送的请求数
15.场景：设置并发策略，模拟用户使用的场景
16.分析：场景运行完，生成各种维度的结果
17.压力测试（stress testing）：在一定的软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作
18. 负载测试（Load testing）：在一定的软件、硬件及网络环境下，通过运行一种或多种业务在不同虚拟用户数量情况下，测试服务器的性能指标是否在用户的要求范围内，用于确定系统所能承载的最大用户数、以及不同用户数下的系统响应时间及服务器的资源利用率，强调系统的稳定性
二、性能测试流程
压测任务如下：
| 1.前期准备 | 需求阶段就加入项目，可以深入了解业务、重要功能的需求和逻辑 |
| 2.性能需求分析（评审） | 明确性能测试范围、目标： 1.引导产品、需求或开发出目标，避免测试背锅； 2.基于接口或场景（流程）的性能测试指标，一般是tps（每秒事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资料利用率的要求（cpu、内存、IO、网络等） |
| 3.熟悉系统架构，申请性能测试环境 | 用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等 |
| 4.指定性能测试方案 | 时间，资源，技术策略（比如监控分析工具选择等）、用例设计 |
| 5.搭建测试环境，准备测试数据 | 数据库的存量数据+增量数据： 比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果不一样的，这个数据量根据生产环境获取； 数据量最好是有标识、有规律的数据 |
| 6.主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行） | 参数化、关联、事务、检查点、思考时间等 造参数化测试数据 |
| 7.预压测（基准测试） | 少量用户（比如1个用户），看压测环境功能是否通； 估算并发过程中需要多少参数化数据的数据量 |
| 8.执行压测并监控服务器资源等 | 看测试指标是否满足要求，从请求开始，一步步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘IO、网络）是否存在性能瓶颈、各种连接等是否存在性能瓶颈 |
| 9.分析定位 | 基于上一步的监控数据，对瓶颈进行分析、定位，全流程排查，模块隔离分析，日志分析 |
| 10.性能优化 | |
| 11.性能回归 | |
| 12.编写性能报告 | 测试结果，测试是否通过； 发现、解决什么问题，系统性能提升了多少倍； 如何调优，修改的内容，以便上线同事悉知 |
备注：
常见的性能问题：
1.服务器问题：
cpu：us & sy
内存：使用率和交换率
磁盘IO：读写慢
磁盘容量
2.网络带宽：看当前收、发速度及有没有丢包、端口使用情况
3.cpu 高：看线程信息；是否 fgc 等
4.队列问题（负载高）：磁盘IO队列（物理读高）；线程队列（线程阻塞、锁竞争）
5.各种连接池问题：不足、未释放（以及半释放）
6.死锁问题：线程死锁、数据库死锁
7.sql问题：索引（未加、使用不当）、慢sql （全表扫描、查询结果未分页展示、sql逻辑）、长事务
8.应用log级别：设置不正确
9.缓存设置问题
10.业务不合理