转载自：https://www.cnblogs.com/imyalost/p/7733386.html
1、性能测试需求
| 需求 | 对库存查询功能迁移后的服务器处理能力做一次压力测试 |
| 响应时间 | ≤20S |
| 网络环境 | 公司100M内网 |
| 压测环境 | 生产环境压测：模拟综合业务场景 |
| 业务场景 | 库存查询功能由后台迁移至移动端：后台有800个查询入口，移动端变为6400个入口 |
| 服务器配置 | 云服务器 |
2、需求分析
需求如上，性能测试最关注的三个指标分别是：响应时间、TPS、资源使用情况。
根据需求来看，要求响应时间不能超过20S的前提下，通过压力测试得到服务器的最大处理能力；且只是一个库存查询功能，因为是在线上压测，所以业务场景可以保证是真实可靠的。
3、场景建模
压测环境是生产环境，所以交叉的业务场景较复杂，库存查询功能是针对云服务器，其他的部分业务是通过应用服务器到数据库的，且数据库做了读写分离，故暂不考虑数据库的性能问题。
4、测试数据准备
测试数据的来源一般有这几种方式：
①、将生产的数据完全备份过来：优点是完全真实可靠，不足之处在于测试数据在测试中容易造成数据污染，最好进行数据隔离，以尽量保证数据的可用性。
②、通过模拟业务场景跑脚本或者调度任务来产生数据：在测试数据量不大的情况下可以通过这种方式来准备测试数据。
这里的前提是在测试环境进行压力测试，而本次的压测是直接在生产环境，故测试数据的问题已经算是解决了。
5、脚本开发&调试
测试工具是jmeter，因为只针对查询库存的功能，故只需要进行单接口压测即可。
利用测试工具设计测试脚本的好处是省却了很多繁琐的过程，脚本的调试，首先需要进行接口测试，保证测试的接口是正确可用，然后进行单接口基准测试，最后进行压力测试。
6、脚本执行&记录监控
脚本执行：
在脚本执行过程中，需要由小到大逐渐加大并发数，且记录每次的测试结果，由于网络等情况影响，最好的办法是同一并发数执行多次测试，然后加权平均到的的数值相对来说较可靠。
通过记录不断加压测试后的测试数据，可以观察到响应时间、TPS、资源使用情况等数值的变化，然后进行分析。
记录监控：
每次测试执行的结果进行记录，监控数据库响应时间、连接数，服务器内存、磁盘使用等数值。
PS：由于是在生产环境直接压测，故需要实时监控，以免压测造成服务宕机等严重情况（我执行测试时候开发随时待命，准备重启服务和扩容233）。
性能测试最重要的三个数值：响应时间、TPS、内存、磁盘使用率————监控（jmeter插件、serveragent）
关于jmeter插件：serveragent的使用，后续的博客会进行介绍。
7、结果分析&瓶颈定位
通过上面测试得到的测试数据，可以进行针对性的分析，比如在压测过程中，资源、内存、连接数等是否使用饱和，是否有线程等待，数据库响应时间等，然后利用排除法和优先级进行调优。
排除法：针对可能影响到性能的几个因素，一个个分析排除；
优先级：根据实际情况，对调优的投入和时间等需要花费的时间和资源进行评估，排优先级，选择最合适的方案。
8、调优&验证
调优方法：
内存、磁盘：简单粗暴的做法，直接加服务器吧
数据库：更改配置的连接数，加索引、读写分离、分库、分区、分表、物理视图等手段
连接池：优化连接池配置，增加连接数等，具体请看链接博客的介绍（https://www.cnblogs.com/imyalost/p/7189455.html）
前端：减少请求连接，数据包尽量放在body中，图片压缩、异步加载、JavaScript脚本放在HTML最后等等手段，具体请看链接博客的介绍（https://www.cnblogs.com/imyalost/p/6843622.html）
末尾：性能测试水太深，真正的性能测试，也就大公司做得起（性能测试投入成本很大），大公司有这个需求（小公司哪来的线上流量）。