文章转自微信公众号：全栈测试笔记，作者：全栈测试笔记，https://mp.weixin.qq.com/s/4b2ZcMpXOwSg7DhUlgeuew
每天做着点点点测试有没有危机感？
突然有一天，领导说：“小王，今天把996福报系统压一下，下班前把压测报告发我邮箱。”
啥？压测？今天？报告？怎么压？怎么写？从来没做过啊，心里一万匹草泥马奔跑而过，别说996了，估计明天都下不了班了；
好歹也像功能测试，给个压测需求吧！没法，你遇到了一个不懂性能测试的领导；
下面大概介绍下一个完整的项目是怎么做性能测试的，看完，你也知道怎么和领导沟通性能测试、以及该怎么做性能测试了，至于欠缺的性能知识，自己努力挤时间补吧。
性能测试虽然是核心功能稳定后才开始压测，但是在需求阶段就应该参与，这样可以深入了解系统业务、重要功能的业务逻辑，为后续做准备。
由于非专业性能测试人员不知道怎么定目标，如果你让他们定，可能定的目标会很离谱，比如，要求单机tps10万、支持1万的并发等等，显然是不合理的，你压测也达不到这个目标；
所以，这个时候，就要体现性能测试人员的专业性了，最好是引导产品、需求或者开发出压测目标（分别是单场景、混合场景、稳定性场景的），自己给建议，大家一起定一个当前合理的目标，达成一致后，让产品或者需求把最终评审的结果以邮件方式发送给领导及项目组成员；
这样，如果最后上线后出问题，还可以避免只有测试背锅，总之目标也不是你一个人定的，是大家一起定的，要背锅一起背锅；
定性能指标，又分为迭代项目和新项目，迭代项目就根据生产监控、日志分析来评估指标，这里需要做容量规划，新项目单独评估（后续详细介绍）；
这里说下性能指标，一般是tps（每秒处理事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资料利用率的要求（cpu、内存、IO、网络等）、各个服务的资源情况。
做性能测试，必须要熟悉项目的架构，这样你才知道监控哪些服务器，以及准备监控方案（监控方式及监控的性能指标点）；
包含具体用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等；
主流的技术栈：nginx、dubbo、mysql、redis、jvm等等（后续专项介绍）。
项目背景及架构分析，
搭建测试环境是测试必备的技能，当然，如有困难，你也可以找运维、开发一起配合；
基础环境数据可以从功能测试的库导过来，改一些配置即可；
业务数据包含：存量数据+容量规划数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的；
数据量要参考生产环境，如果是新项目，除了空库压，最好也做一下存量数据压。
主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行）；
客户端并发工具，推荐用jmeter，主流、开源、轻量、免费、功能强大；
根据实际情况，对脚本调整，比如：参数化、关联、事务、检查点、思考时间、信息头管理器等；
www.cnblogs.com/uncleyong/p/10530261.html
这里再强调一下，jmeter只是客户端并发工具，jmeter≠性能测试。
第二：估算并发过程中需要多少参数化数据的数据量（具体估算方式后续介绍）。
场景设计好后，就可以执行压测了，然后监控查看测试各项指标是否满足需求；
如果不满足，可以结合表象及根据自己的经验直接去看预估的瓶颈点；
否则，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
经常有测试朋友问我用什么工具监控，我大部分都是用的命令，为了方便，也会写shell脚本来监控；
linux服务器，常用的命令是top、vmstat、free、df、sar、iostat、netstat等，一般是多个命令配合着用；
java应用：jvisualvm、jconsole、jmap、jstat、jstack等，以及自己写的一些shell脚本；
redis、mysql、jvm等等，后续文章会专项介绍。
基于上一步的监控数据，对瓶颈进行分析、定位，模块隔离分析、日志分析、内存分析、线程栈分析、代码跟踪等等；
这个真需要实战积累，没有捷径，遇到好几个去参加过性能培训的朋友，他们反馈说还是不会性能，操作起来同样一脸懵逼、无从下手。
定位到问题了，大部分情况下，优化方案也就有了，测试可以把自己建议的优化方案告诉开发，开发会结合自己的方案，一起做优化方案评估；如果测试没有优化方案，那就把问题反馈给开发吧，但是也好好学学开发的优化思路，这就是成长的过程。
测试是否通过？
优化方案务必写详细，以便上线同事知道，把优化同步到其它各个环境。
声明：封面或正文部分图片来源于网络，如有侵权，请联系删除。
