结合日常工作，与性能测试相关的内容，主要通过三个部分展开：
- 接触性能测试
- JMeter快速入门
- 性能测试全过程
1、接触性能测试
1.1定义及目的
性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。我们听到较多的就是“压测”，压测属于性能测试。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
目的：
1.评估当前系统。了解系统当前性能情况。
2.寻找瓶颈，优化性能。解决优化性能问题。
3.预测未来性能。如何应对未来业务量的增长
1.2性能指标
性能指标主要分业务指标和服务器指标，其中：
业务指标主要包括：并发数、RT、TPS等；
服务器指标主要包括：CPU、Memory、网络等。
1.2.1并发数
并发的概念，一般有两种理解方式：一种为所有用户在同一时刻做同一操作，主要是为了验证程序或数据库对并发的处理能力；另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一操作，也可以是不同操作，类似混合场景的概念。以扶摇系统为例：
系统用户数：有扶摇权限的用户数。
在线用户数：登录扶摇的用户数。
并发用户数：登录扶摇并进行操作的用户数。
确定并发用户数常见的有四种方式，其中2-8原则用的较多：
1.取在线用户的数10%-20%，作为并发用户数
2.公式估算：
C = nL/T
（C:平均的并发用户数 n:总在线用户数 L:平均在线时长 T:总在线时间）
3.2-8原则： 80%的业务量在20%的时间内完成
例如：登录模块预计一天的登录人数是50万，登录响应时间2s左右，估算并发用户数。
C=（500000*0.8）/[（24*0.2*3600）/2]≈46
4.对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数作
为并发，之后可根据实际情况梯阶式增加。
1.2.2响应时间（RT）
通常，响应时间我们就理解为网路响应时间和应用的响应时间：
响应时间=网络响应时间+应用程序响应时间
下面是一个完整的请求链路：
响应时间=网络传输（请求）时间+服务器处理时间+网络传输（响应）时间+页面前端解析渲染时间
（前端页面的解析展示时间一般不太会关注，因为每个浏览器解析页面方式不一样，时间也不一样）
1.2.3TPS/QPS
TPS：Transactions Per Second，意思是每秒事务数
QPS：Queries Per Second，意思是每秒查询率
QPS是Query Per Second，是数据库中的概念，每秒执行条数（查询），被引申到压测中来了，但是不包括插入、更新、删除操作，所以不建议用qps来描述系统整体的性能；建议用tps，这个t，你可以随意的定义，可以是一个接口，也可以是一个业务流程等等。
如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps;
如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tps具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一
1.2.4资源利用率
CPU：反应出系统的繁忙程度，一般分系统CPU和用户CPU，其中系统CPU是处理系统本身所占的资源， 用户CPU则是处理程序所占的资源。
Memory：数据从内存中读取要比从磁盘中读取更快，内存经常发生内存泄漏活内存溢出的现象。
网络：重点关注网络的流量，看是否存在网络带宽的瓶颈。
IO：与磁盘的交互，重点关注交换频率和磁盘队列的长度。
队列：队列长，说明处理能力可能达到了极限或者遇到了阻塞。
1.3性能测试分类
基准测试：类似功能测试的冒烟测试，例如单用户的响应时间超过目标响应时间，就没有必要进行后面的 测试了，通常容易被忽略。
并发测试：按照预定的场景并发请求某个业务或功能时是否出现并发问题，主要目的是找出并发引起的问 题。
负载测试：确定所要测试的业务或系统的负载范围，然后对其进行测试，主要验证业务或系统在给定的负 载条件下的处理能力。此外还要关注各项指标。
压力测试：没有预期的性能指标，不断加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能被接 受的性能拐点，以获得系统的最佳并发数、最大并发数。
稳定性测试：系统长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。一般都会进行所谓 的7*24小时的稳定性测试。
以上分类中，基准测试通常容易被忽略；负载测试我们常从比较小的负载开始，逐渐增加模拟用户的数量（增加负载），观察不同负载下应用程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标；稳定性测试需要在系统成型后进行，且没有严重的bug存在，且场景的设计以模拟真实用户的实际操作为准（混合场景）。
1.4曲线拐点模型
通过分析曲线拐点模型：
1.随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加的不是很 明显，处于比较好的状态。
2.随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和。
3.随后吞吐量急剧下降，造成响应时间急剧增长。
4.轻压力区与重压力区的交界点时系统的最佳并发用户数，因为各种资源都利用充分，响应也很快。
5.重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统的性能将会急剧下降甚 至崩溃。
2.JMeter快速入门
2.1性能测试工具对比
目前市面上使用度最高的工具就是JMeter和LoadRunner
| JMeter |
LoadRunner |
|
| 优势 |
1、开源免费、安装简单； 2、帮助测试者很方便地模拟出多用户同时访问服务器的环境； 3、应用范围广； 4、丰富的逻辑控制器； 5、强大的监控组件。 |
1、运行稳定； 2、监控指标齐全； 3、性能测试结果细致； 4、模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。 |
| 劣势 |
1、无法判断测试“正确性”。JMeter虽然有断言机制，但在模拟多用户操作时发出请求后得到的响应是不可预测的； 2、没有很好的BeanShell测试机制。 |
1、收费，且价格较贵； 2、安装程序繁杂，操作较难。 |
| 学习 |
学习JMeter 的一般大家都会选择自学或参加一些培训，不过这款软件安装比较简单，下载后可以在CSDN或者其他论坛上找个使用指南，基本操作都能够自学。 |
LoadRunner的学习具有一定的门槛，很多初学LoadRunner的朋友认为自学就能掌握LoadRunner这款性能测试工具，其实进入了一个误区。因为这款工具是商用工具，对于它的学习也是比较复杂的，而网上对于这款工具的介绍往往不够全面。 |
2.2测试计划
测试计划是使用JMeter进行测试的起点，它是其他JMeter测试元件的容器，每个测试场景/脚本都包含一个测试计划，也可以说，每个测试场景/脚本都叫一个测试计划。
2.3场景设计
在测试计划基础上新建线程组，JMeter的场景设计以及Vuser都是在线程组下设计完成的。在需要输出压测结果的场景中，通常使用 jp@gc-Stepping Thread Group插件来设置负载场景。
右键测试计划->添加->Threads(Users)->jp@gc - Stepping Thread Group
以上设置中：
This group will start：总加载线程数100
Fist，wait for：等待多长时间开始运行，相当于延时多少秒开始执行
Then start：初次加载多少个线程
next add 、threads every、using ramp-up：每过30秒加载10线程，10个线程在5秒加载完成，可以理 解为总共花费35秒时间，再多10个线程再跑
then hold load for：所有线程加载完之后，运行60秒
fianlly，stop /threads every :每1秒停止5个线程，20秒则停止100个线程数
2.4参数化
常用的参数化有以下三种：用户自定义变量、函数助手-随机函数、配置元件-CSV Data Set Config。
2.4.1用户自定义变量
测试计划---添加---配置元件---用户定义的变量
2.4.2函数助手-随机函数
工具---函数助手对话框---配置元件---用户定义的变量
使用中会发现拷贝并粘贴函数字符串”被置灰了，无法拷贝并粘贴到需要的地方，实际上，当点击“生成”按钮时，Jmeter已经自动帮你复制过了，只需Ctrl+v到合适的地方就复制过去了。
2.4.3配置元件-CSV Data Set Config
线程组---添加---配置元件---CSV Data Set Config
如上设置，线程循环时，取csv值时，也算入迭代，如qqq第一次取456，第二次取333，第三次取322。
2.5结果分析
在进行结果分析中，通常会添加聚合报告、查看结果树、以及用户/TPS/RT图表。
2.5.1聚合报告
线程组---添加---监听器---聚合报告
2.5.2查看结果树
线程组---添加---监听器---查看结果树
在调试时，可以通过查看结果树查看请求和响应，压测时注意勾选仅错误日志。
2.5.3用户/TPS/RT图表
需要先安装插件，然后才能添加，线程组---添加---监听器---
jp@gc - Active Threads Over Time
jp@gc - Transactions per Second
jp@gc - Response Times Over Time
jp@gc - Active Threads Over Time
jp@gc - Transactions per Second
jp@gc - Response Times Over Time
jp@gc - Actiive Threads Over Time 不同时间活动用户数量展示 展示阶梯加压测试的图标
jp@gc - Transactions per Second 即TPS：每秒事务数 监控查看服务器的TPS表现，比如整体趋势、实 时平均值走向、稳定性等。
jp@gc - Response Times Over Time 即RT：事务响应时间 该插件的主要作用是在测试脚本执行过程中，监控查看响应时间的实时平均值、整体响应时间走向等。
3.性能测试全过程
完整的性能测试全过程包括以下全部内容，但在小型项目中，更主要体现在测试方案、执行分析
及测试报告这几个环节。
3.1项目分析
项目分析包括两个方面：系统架构和业务流程
3.2需求确定
什么样的场景该被优先考虑?
1.用户访问量比较大的功能
2.与钱相关比较重要的场景
3.影响业务主流程的场景
4.开发人员认为可能存在性能问题的场景
5.应该考虑综合场景，防止线程争用导致死锁等
6.应该做稳定性测试场景，防止长时间运行导致内存泄漏
3.3测试计划
3.4测试方案
测试方案主要就是性能测试具体如何开展，包括以下内容：
3.5环境准备
优先考虑是否能用生产环境做性能测试，通常情况下需要额外申请，但应该遵循以下原则：
1.硬件环境尽可能保持与生产一致
2.若集群环境太庞大，可能通过折算得到业务指标
3.性能环境配置低于生产环境，也要求满足指标才可行，反之则不行
4.被调用系统，可以直接使用mock
3.6工具选型
压测工具:JMeter
监控分析工具
监控分析要求非常高，细化可以分cpu、内存、网络、数据库、中间件，队列、堆栈等。
3.7数据准备
基础数据：比如菜单、省市区、等等，此类数据可能通过导入功能数据库或线上数据库。
业务数据：如扶摇中，用户、中奖记录等，此类数据必须要造数据，而且数据量要满足未来的业务规划。
3.8脚本开发
3.9执行分析
分析包括业务指标及服务器资源：
业务指标
服务器资源
常见的性能问题分类：
硬件：CPU、内存、IO、磁盘配置过低
网络：带宽太小
网络波动导致业务指标波动
应用：JVM配置，堆内存分配不合理，垃圾回收机制不合理
代码逻辑，不合理的线程引用及内存分配，实在过于复杂的业务逻辑
数据库：索引缺失
慢SQL
中间件：连接数太小
负载均衡有问题
3.10测试报告
测试报告：主要体现：压测过程、压测结果、优化调优明细、监控数据、压测结论。