一、前期准备
性能测试虽然是核心功能稳定后才开始压测，但是在需求阶段就应该参与，这样可以深入了解系统业务、重要功能的业务逻辑，为后续做准备。
二、性能需求分析（评审）
评审时，要明确性能测试范围、目标；
由于非专业性能测试人员不知道怎么定目标，如果你让他们定，可能定的目标会很离谱，比如，要求单机tps10万、支持1万的并发等等，显然是不合理的，你压测也达不到这个目标；
所以，这个时候，就要体现性能测试人员的专业性了，最好是引导产品、需求或者开发出压测目标（分别是单场景、混合场景、稳定性场景的），自己给建议，大家一起定一个当前合理的目标，达成一致后，让产品或者需求把最终评审的结果以邮件方式发送给领导及项目组成员；
这样，如果最后上线后出问题，还可以避免只有测试背锅，总之目标也不是你一个人定的，是大家一起定的，要背锅一起背锅；
定性能指标，又分为迭代项目和新项目，迭代项目就根据生产监控、日志分析来评估指标，这里需要做容量规划，新项目单独评估；
这里说下性能指标，一般是tps（每秒处理事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资料利用率的要求（cpu、内存、IO、网络等）、各个服务的资源情况。
三、熟悉系统架构，申请性能测试环境
做性能测试，必须要熟悉项目的架构，这样你才知道监控哪些服务器，以及准备监控方案（监控方式及监控的性能指标点）；
包含具体用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等；
主流的技术栈：nginx、dubbo、mysql、redis、jvm等等。
四、制定性能测试方案
项目背景及架构分析
需要的资源
技术策略（比如压测、监控、分析工具选择等）
场景设计
计划什么时候做什么事等等。
五、搭建测试环境，准备测试数据
搭建测试环境是测试必备的技能，当然，如有困难，你也可以找运维、开发一起配合；
测试数据分为基础环境数据和业务数据；
基础环境数据可以从功能测试的库导过来，改一些配置即可；
业务数据包含：存量数据+容量规划数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的；
数据量要参考生产环境，如果是新项目，除了空库压，最好也做一下存量数据压。
六、开发压测脚本
客户端并发工具，推荐用jmeter，主流、开源、轻量、免费、功能强大；
根据实际情况，对脚本调整，比如：参数化、关联、事务、检查点、思考时间、信息头管理器等；
这里再强调一下，jmeter只是客户端并发工具，jmeter≠性能测试。
七、预压测（基准测试）
少量并发（比如1个用户），压测10分钟，
第一：可以看压测环境功能是否通；
第二：估算并发过程中需要多少参数化数据的数据量。
八、执行压测并监控
场景设计好后，就可以执行压测了，然后监控查看测试各项指标是否满足需求；
如果不满足，可以结合表象及根据自己的经验直接去看预估的瓶颈点；
否则，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
经常有测试朋友问我用什么工具监控，我大部分都是用的命令，为了方便，也会写shell脚本来监控；
linux服务器，常用的命令是top、vmstat、free、df、sar、iostat、netstat等，一般是多个命令配合着用；
java应用：jvisualvm、jconsole、jmap、jstat、jstack等，以及自己写的一些shell脚本；
redis、mysql、jvm等等。
九、分析定位
基于上一步的监控数据，对瓶颈进行分析、定位，模块隔离分析、日志分析、内存分析、线程栈分析、代码跟踪等等；
这个真需要实战积累，没有捷径，遇到好几个去参加过性能培训的朋友，他们反馈说还是不会性能，操作起来同样一脸懵逼、无从下手。
十、性能优化
定位到问题了，大部分情况下，优化方案也就有了，测试可以把自己建议的优化方案告诉开发，开发会结合自己的方案，一起做优化方案评估；如果测试没有优化方案，那就把问题反馈给开发吧，但是也好好学学开发的优化思路，这就是成长的过程。
十一、性能回归
优化后，复测。
十二、编写性能报告
测试结果是多少？测试是否通过？
发现了什么性能问题？原因是什么？
如何优化解决的？系统性能提升了多少倍？优化方案务必写详细，以便上线同事知道，把优化同步到其它各个环境。