性能测试目的：观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能。
程序性能体现
- 执行速度：程序反应是否迅速，响应时间是否短
- 内存分配：内存分配是否短，是否存在过多消耗内存或者内存泄露
- 启动时间：从启动到可以正常处理业务所需时间
- 负载承受能力：当系统压力上升时，系统执行速度、响应时间上升曲线是否平缓
性能的参考指标
- 执行时间：一段代码从开始运行到结束所需要的是时间
- CPU时间：函数或者线程占用cpu时间
- 内存分配：程序在运行中占用的内存空间
- 磁盘吞吐量：磁盘IO使用
- 网络吞吐量：网络使用
- 响应时间：系统对某用户行为或事件作出相应的时间。时间越算，性能越强。
最有可能成为瓶颈的计算资源
- 磁盘IO：磁盘读写速度比内存要慢，如果程序运行中需要等待磁盘IO完成，那么IO操作会成为瓶颈
- 网络操作：网络环境具有极大的不确定性，若对数据没有进行处理，此处可能成为瓶颈
- CPU：对计算资源要求较高的应用，长时间不间断使用CPU，会对CPU资源造成争抢，导致CPU成为瓶颈
- 异常：对于JAVA程序，异常捕获处理也非常费资源，若高频次进行异常处理，则整体性能就会有下降
- 数据库：海量数据读写操作非常耗时，应用程序可能需要等待数据库操作完成或者返回请求结果集，缓慢同步操作会成为瓶颈
- 锁竞争：锁竞争会增加线程上下文切换的开销，这些开销与应用程序无关，但是会占用大量CPU资源，成为瓶颈
- 内存：程序设计不合理，对内存使用不当，高频次的进行内存交换和扫描，使内存可能成为瓶颈
性能优化步骤

响应时间

C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server 所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；
N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。
并发用户数 ≠ 每秒请求数
当在性能测试工具或者脚本中设置了100并发用户数后，并不意味一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
环境需求
- 测试环境架构与生产环境架构完全相同
- 测试环境机型与生产环境机型尽量相同，云化的资源确保是同规格ECS或者容器
- 测试环境软件版本与生产环境软件版本完全相同，版本主要包括：操作系统、中间件相关、数据库、应用等
- 测试环境参数配置与生产环境完全相同，参数主要包括：操作系统参数、中间件参数、数据库参数、应用参数
- 测试环境基础数据量与生产环境基础数据量需在同一个数量级上。
- 只能减少测试环境机器台数，并且需要同比例缩小，而不能只减少某一层的机器台数。
- 理想的测试环境配置是生产环境的1/2，1/4。
测试指标
测试指标一般分为业务指标、资源指标、应用指标、前端指标。
业务指标：如：并发用户数、TPS（每妙处理请求数）、成功率、响应时间。
业务响应时间(Response Time):一般情况下，不同系统的业务响应时间期望值是不同的，具体业务具体分析
业务处理能力（Transaction Per Second）:这个指标是衡量系统的处理能力的一个非常重要的指标
成功率:这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。资源指标：如：CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等。
应用指标：如：空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。
前端指标：如：页面加载时间，网络时间（DNS，连接时间、传输时间等）。
压测场景选取
一般是选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务。已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。
数据尽量参数化、数据量尽可能的多。