一、开发人员掌握性能测试的必要性
一说起测试，大部分想到的是业务功能测试。其实功能测试只是测试的一部分，另外还有性能测试、自动化测试、全链路测试、安全测试，不同规模、不同业务类型的的公司各有选择。自动化测试借助自动化工具代替人工按照预设条件进行测试，也可用于持续集成（比如和jenkins整合），目的提高测试效率；全链路测试通过一次测试尽可能将系统的所有业务链路全部验证完成；安全测试验证产品符合安全需求；性能测试对系统的各项性能指标进行测试，在不同场景下系统的性能表现，能够发现深层次的问题，而这些问题恰恰是大部分开发人员忽视、经验匮乏的地方，因此开发人员应该掌握性能测试，去主动的发现系统性能问题并改进。
二、功能测试与性能测试的区别
功能测试：系统提供的对应功能能否正常使用，是否复合原型设计；一件事有没有做，能不能用。
性能测试：不同情况下的性能表现；系统能否在极端情况下使用；一件事做的好不好，用的爽不爽。
举个例子：汽车厂造了一辆车，测试员开始测试这辆车：
功能测试：轮胎能不能跑；方向盘转弯了，车子是否转弯；刹车踩下去车辆是否能减速或刹住；车座位能不能做人等等；
性能测试：轮胎在下雪天、沙漠里、乡村道路、坑洼路面、被子弹击中、地雷炸等场景下行驶是否还能跑；刹车在速度100KM/h、200KM/h下能否刹住；座位能否承受住100KG、200KG的重量等。侧重同样的功能，在不同的场景下的性能表现。
三、性能测试3个主要步骤
1、性能需求分析：客户希望的程序性能标准是什么？
一般来说性能需求有三类：
1）没有明确需求的基准性能测试，用于摸底这个系统目前的性能指标数据，一般常见于小公司，常见的说法：给一个测试报告；
2）明确的性能需求：给定性能指标，看是否达标，一般是中型公司；
3）出于性能优化的性能测试，一般是大公司，就是边测边改进，先测出性能数据，发现哪些指标不太理想，然后进行瓶颈分析并给出调优建议；
一般小规模系统基本不会做性能测试；中等规模系统做的比较简单；大规模系统一定会做专业的性能测试。一般测试人员会找项目经理、产品经理、业务人员、架构师、开发沟通，有些产品经理说的很笼统，XXX场景不要太慢，1s内出结果；或者只有一句话：做一下测试，看看系统性能怎么样？而大规模系统一般会有专业的性能测试方案。从这些岗位的视角主要关注的是并发量和响应时间，不太了解专业的性能测试指标，我们需要跟他们不断地沟通中分析出来真实的性能需求，要把这些诉求转化为专业性能测试指标，最后产出制定性能测试计划或测试方案。
（1）核心性能指标-并发量
单就性能指标而言，系统的并发用户数是指系统可以同时承载的、正常使用系统功能的用户总数量。
客户经常会问：我们的系统最多能处理多少并发？能不能抗住1000并发？
回答这个问题，先要明确问题里的并发指的是绝对并发还是相对并发？
a、绝对并发：同一时间有多少请求给服务器处理，在一些长连接的场景中更容易出现，发生绝对并发概率会高一些。比如实时聊天室、websocket通信等等，但也不会保证同时给服务器，比如每秒多少个请求，传输过程中有损耗等原因，没法保证这些请求是同时被服务器处理，所以不存在真正意义上的并发。
b、相对并发：一段时间内，服务器需要处理的请求数量，常用单位是1s：比如web应用，基本都是短连接的http请求，请求-->响应，然后就结束了。
请求基本上是离散的到达服务器，基于这种事实，我们所说的并发一般指相对并发。有的人可能说使用jmeter的同步定时器，通过集合点方式控制请求一并发出。这也不是一定会产生绝对并发：首先设置1s内集合1000个请求发出，实际上结果第一秒内不一定发出1000个请求，可能第1s发出600个第2s发出400个，为什么？因为这需要压力机有足够的资源才能做到这一点；其次即使同时发出1000个请求，受到网络带宽、网络质量等原因，这些请求也不一定会同时到达服务器。集合点会提升并发数的概率，但并不一定实现定量请求的绝对并发。另外有人会在性能测试时加上思考时间用以模拟现实中人工操作，思考时间对性能测试的结果不会有本质意义的影响，不会因为增加了思考时间之后，系统该有的那些瓶颈就不会暴漏出来，所以不必太过纠结是否要加思考时间。
（2）核心性能指标-响应时间
计算的是端到端的时间，通俗讲是指从客户端发出交易请求到得到响应的整个过程。
（3）核心性能指标-QPS、TPS
QPS：每秒查询率（QPS = req/sec = 请求数/秒），是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：系统每秒处理交易的数量，单位是笔/秒。通常表示一次交易申请和响应返回的过程。
（4）核心性能指标-吞吐量
吞吐量指单位时间内通过网络成功传输的数据量。单位为Byte/s。
2、进行性能测试：检查程序在不同场景下的性能表现？
（1）用例设计
a、用户量增多场景（梯度压测）
通过不断地增加用户数（1个、10个、100个...）,不断的消耗系统的资源，以达到系统的瓶颈。
b、用户操作流程
单接口、多接口测试
（2）用例执行
使用工具jmeter、loadrunner(收费)、locust
a、1个用户 单接口 压测时长30s
b、10个用户 单接口 压测时长30s
c、10个用户 多接口 压测时长30s
（3）执行结果收集
a、jmeter监视器：查看结果数、聚合报告、Hits per Second(每秒点击数HPS)、Transactions per Second（每秒事务数TPS）、Response Times Over Time（响应时间）、Active Threads Over Time（每秒活跃线程数）、Composite Graph（可以将上述四个图表整合在一张图上的复合图查看器）、PerfMon Metrics Collector+ServerAgent(服务器资源监控插件)
b、生产中一般用：jmeter无界面压测 + influxdb + Prometheus + Grafana,可以进行横向数据对比、直观、漂亮
c、监控程序，比如java程序就要监控JVM，mysql、nginx、redis、MQ，可借助阿里的Arthas深层次的监控java程序各项数据。
3、性能问题分析：在不满足性能要求的情况下，识别性能瓶颈
a、结果分析
比如：平均响应时间5s > 客户要求3s,性能测试结果不符合要求【瓶颈】
为什么程序会有性能问题？性能问题怎么出现的？举个例子：
b、【瓶颈分析定位】非常重要：
1）什么是系统瓶颈？系统为什么会有性能瓶颈？系统的瓶颈在哪里（拐点）？
程序运行是需要占用系统资源的（CPU、内存、网络、磁盘等），而资源是有限的，当某一个资源被用光之后就会碰到瓶颈。 补充一个带宽的小知识：通常服务商所说的100Mbps指的是bit/s，而我们生活中通常所说的都是Byte/s，所以转化为我们理解的带宽要除以8，那么100Mbps/8=12.5MBps。从广义的角度来讲，系统瓶颈不单单指系统资源用光了，比如响应时间超过客户要求，也可以称之为达到了系统瓶颈，这个瓶颈的概念不绝对，只是大家常用来指系统资源的消耗。
2）系统是否到了瓶颈？
----如果没到，什么原因导致出现了性能问题？
如果系统资源未被完全消耗完，就出现了性能问题。那就要从程序着手分析，结合程序监控数据，比如java程序就要看JVM、mysql、nginx、redis、MQ等指标数据，借助Arthas等工具深入分析程序中资源利用情况，线程、堆内存、连接数、缓存、索引、超时时间等等，导致性能问题的原因各种各样，没有规律，这个地方是难点，需要具备丰富的技术积累（广度+深度）。
----如果到了，什么原因导致系统到了瓶颈？
监控系统的资源使用情况，比如压测过程中发现CPU使用率到达100%，其他资源使用未达到极限值，这个时候系统就到达了瓶颈值。
c、调优建议
如果是未到达系统瓶颈而出现性能问题，就要根据JVM、mysql、nginx、redis、MQ监控数据分析得出的原因结论给出优化程序的建议；
如果是到达了系统瓶颈导致了性能问题，两个方面建议：
1）提高机器配置：比如CPU资源是第一个被消耗完的资源，那么就要增加CPU，原先是2核，建议增加到4核；
2）优化代码：如果公司觉得提高机器资源成本高，那就让开发人员从代码角度提升程序性能；