压测任务具体包含：

0.前期准备

业务需求评审就加入项目，可以深入了解业务、重要功能的需求和逻辑

1.性能需求分析（评审）

明确性能测试范围、目标，由于非专业性能测试人员也不知道怎么定目标，所以最好是引导产品、需求或者开发出目标，避免只有测试背锅；
　　基于接口或者场景（流程）的性能测试指标，一般是tps（每秒事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资源利用率的要求（cpu、内存、IO、网络等）。

2.熟悉系统架构，申请性能测试环境

用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等，画出系统架构图，理解其中的逻辑；对需要监控的服务提前做技术准备

3.制定性能测试方案，构建测试模型

计划什么时候做什么事，需要的资源，技术策略（比如监控分析工具选择等等）、用例设计、模型构建、场景设计

4.搭建测试环境，准备测试数据

数据库的存量数据+增量数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的，这个数据量根据生产环境获取；数据最好是有标识、有规律的数据；

5.主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行）

参数化、关联、事务、检查点、思考时间等，造参数化测试数据
　　另外，这里涉及到场景的设计：单场景、混合场景、稳定性场景、异常场景

6.预测试（环境确认测试）

跑1个用户，看压测环境功能是否通
　　估算并发过程中需要多少参数化数据的数据量

7.执行压测并监控服务器资源等

看测试指标是否满足需求，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、各种连接等是否存在性能瓶颈

常见性能问题：
　　常见的性能问题（有些只是表象，需要深层次定位）：
　　a.服务器
　　　　cpu：us & sy
　　　　内存：使用率及交换率
　　　　磁盘io：读写慢
　　　　磁盘容量
　　b.网络带宽：看当前收、发速度及有没有丢包、端口使用情况
　　c.cpu高：看线程信息；是否fgc等
　　d.队列问题（负载高）：磁盘io队列（物理读高）；线程队列（线程阻塞、锁竞争）
　　e.各种连接池问题：不足、未释放
　　f.死锁问题：线程死锁、数据库死锁
　　g.sql问题：索引（未加、使用不当）、慢sql（全表扫描、循环插入 or 更新、查询结果未分页展示、sql逻辑）、长事务
　　h.应用log级别：设置不正确
　　i.缓存设置问题、没有利用好缓存
j.缺乏消息中间件
k.代码：业务逻辑代码冗余、遍历Map

8.分析定位

基于上一步的监控数据，对瓶颈进行分析、定位，全流程排查，模块隔离分析，日志分析

9.性能优化

10.性能回归

11.编写性能报告

测试结果，测试是否通过；发现、解决什么问题，系统性能提升了多少倍；如何调优的，改了什么东西，以便上线同事知道。

从上面可以看到：

1、没提到jmeter，因为jmeter≠性能，jmeter只是一个主流客户端并发工具，当然，你也可以用loadrunner、locust、或者自己写并发代码，对于大部分测试来说，代码能力是短板，所以，如果有轮子，我们就不要花时间去造轮子了，直接用，先学会并发工具的常用功能，然后系统架构中各个技术栈的监控、分析等等；

2、性能要求的知识面比较广，不仅需要知识积累，也需要实战经验积累；