性能测试类型
1、基准测试
测试系统是否存在线程安全性问题，并得到一定测试条件下的系统的性能基线数据。目的是得到系统的性能基线数据，并对响应时间、TPS和其他与时间相关的需求进行评估。
************翻译************
俗话说的好，“凡事都有个第一次，再丑的媳妇也要见公婆”。这个类型就是针对之前没有做过性能测试，或者是根据新需求而刚刚开发完成的新系统来说的。这时，您就需要来一份“基准测试”啦！先给自己留个底儿，有了性能基线，我们才能继续后面的“调优”不是？
对比测试
对比不同测试条件下的性能差距，常用于系统优化，技术选型，通过相同的用例对比性能数据。测试方式和负载测试类似。
************翻译************
多说无益，我们“举几个比方，打几个栗子”：
我们对系统的某功能进行了优化，需要验证该功能在优化前后的性能对比数据时，可以进行对比测试；
老板让我说出两种系统架构或者实现方法下，哪一种更好，可以进行对比测试；
老板让我说出这两款设备，哪一款更优秀，可以进行对比测试。
说白了，就是各种比较，没有对比就没有伤害；不对比你怎么能知道你有多胖呢，对不对？！（观众：扔砖头！！！）
2、容量规划
测试系统在软硬件上的扩展能力，常用于测试软件扩容，硬件扩容。容量规划也是对比测试的一种。
************翻译************
就如定义中所说，容量规划也是对比测试的一种。这个类型主要使用场景有：
软件扩容：我们用多线程来代替原有的单线程处理请求；
硬件扩容：我们增加了两台redis，加大了weblogic server的内存或者直接增加了4台服务器。
在这里也要额外说一点：我们扩容，特别是硬件扩容，是不能按照倍数来放大扩容效果的。例如，我们2台server时TPS为100，我们增加到4台同样配置的server时，TPS并不是增加到200了。有可能是160、170、180……这其中并没有一个线性的关系，这点很重要需要知悉。所以，很多时候项目组找到我们做性能测试，说我们生产环境与测试环境配置相同，只是数量不同，是否能直接换算性能指标呢？答案是否定的！我们只能说，你在测试环境中如果满足了预期性能指标，那生产环境理论上是没有问题的，no more！
3、稳定性测试
采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续运行一段时间。目标是检测系统能否持续稳定工作。
************解释************
其实，我们在用Jmeter压测的时候，至少都要持续10~15min以上，为什么呢？我们要让TPS稳定下来，这时采集的数据才有效；当然，并不是说15分钟就一定够了，某些情况下需要更长时间的压测才能发现性能问题。
稳定性测试多用于对“系统稳定性”有“强需求”的系统，比如金融类的银行、证券等等。如系统要求3*24小时运行，测试当系统在一定的压力情况下（如CPU资源使用率维持在50%左右），选取复合场景的案例，持续运行3x24小时，观测系统的稳定性状态数据。
还有一种是：测试人员发现，系统在短时间（1个小时、8个小时甚至1天）内都是正常的，但一超过一定时间后就会CPU利用率徒增，或者内存持续增高（疑似内存泄露），这也需要来一场轰轰烈烈的稳定性测试……
4、负载测试
负载测试是通过逐渐增加用户量来观察在不同的负载下系统的指标，以检验系统的行为和特性，以发现系统可能存在的性能问题，并可以检测系统的伸缩性。
也可以确定在什么负载条件下系统性能处于失效状态，目标是获得系统能提供的最大服务级别。
************解释************
负载测试是大家平时做性能测试使用最多的一种类型，甚至有些时候大家嘴里所说的性能测试，就是指的负载测试。说的直白点，就是你写好脚本跑个100并发，发现对于系统来说“洒洒水啦”，监控显示内存和CPU指标都懒得波动一下。那我们加到400试试，加到500呢，1000……？所以，这就是一个“试”的过程，直到系统“失效”！这里的“失效”不一定是指系统宕机，监控显示CPU、Memory利用率超过80%了也叫失效，系统响应时间超过预期的3秒了也叫失效，就看哪个条件先被打破了……
性能测试流程
①. 需求分析及评审
Ø 明确测试目的：
根据需求来选取一种或者多种性能测试类型，比如“针对以前未进行过性能测试的系统，在本次版本发布前，需要对系统进行性能的评估”，这时我们至少就需要选取“基准测试”；
Ø 明确测试内容：
选取待测功能点时可以根据三个原则：“核心功能或流程”、“使用人数”和“数据量”。
************解释************
核心功能点或流程：按照重要性先后顺序，对系统的核心功能和核心流程进行排序，优先压测重要性较高的功能点或流程；
使用人数：假设系统有100个用户&两个功能点，其中A功能95人用，B功能5人使用，那么优先压测A功能；
数据量：根据功能点在后台存取数据的大小，以及历史数据累积的多少进行排序，数据量大的功能点优先测。
Ø 明确通过标准
在系统不会出现线程锁，资源竞争，内存泄露等程序问题后，基本服务端性能指标需要达到下面常用标准:
判断维度 | 常用标准
超时错误率 小于万分之一
TPS 大于目标值：TPS = （总业务量*80%）/ （总时间*20%）；或者达到40个/秒
响应时间 接口类：90%line小于500ms
页面类：参考2-5-8原则，90%line小于 2s 或者 5s
CPU使用率 小于80%
CPU Load 小于CPU核心数
内存 小于80%
IO磁盘使用率 小于80% [使用iotop命令]
带宽使用率 小于80% [iftop]
*********************
②. 性能测试策略
a.环境分析
在介绍“容量规划”的时候，我们说过“不能将测试环境的测试结果直接映射到生产环境上”，也“没有一个准确的公式或方法，可以根据系统在测试环境的性能表现准确推导出生产环境的性能表现”。那我们压测试环境是不是做无用功呢？（肯定不是啊，否则我写这篇文章干嘛……）我们可以通过对比的方式来推断和估计生产和测试环境的性能差异，但需要先采集以下数据：（可根据项目具体情况自行删减）
Ø WEB（APP）Server：服务器的数量，每台服务器的CPU数量、CPU频率、主板频率、内存数量、磁盘速度、磁盘已用空间、磁盘可用空间；（想省事的就记录一下CPU、Memory、DISK也将就用）
Ø DB Server：CPU的数量、CPU频率、主板频率、内存数量、网络速度、磁盘速度、可用表空间、已用表空间、主要数据表的记录数；（想省事的就记录一下CPU、Memory、DISK也将就用X2）
Ø 负载均衡：硬件还是软件（软件常见的Nginx和硬件常用的F5）、采用什么负载分发策略；（轮询？随机？最小响应时间？最小并发数？哈希？具体这五种啥意思，不在本文讨论范围内，请自行查阅资料）
Ø 部署及网络状况：带宽如何？待压环境部署在内网还是DMZ区？是否为云主机？（这些太重要了，因为你根本无法想象我曾经为了不同压测环境到处“借”不同环境执行机的痛苦……所以，早了解，早准备！）
Ø 其它：除了上述环境数据，你还需要知道你的测试环境里部署了多少个“其它系统”，甚至有多少系统与你的系统是共享DB的？（我就遇到一个任务是多系统共享一套DB，而且上游系统里的SQL有问题，我这边压测，它那边抽疯；后来让我们组的数据库大神研究了AWR报告，才发现不是我们系统的性能问题╮(╯﹏╰)╭）
b.数据准备
测试数据分为“基础数据”和“测试输入数据”两部分。
Ø 基础数据：基础数据是指保证系统正常运行所必需的数据，如部门与机构基本信息，系统基本配置信息，名单类型代码表，业务代码基础表等，基础数据一般通过适当的方式直接导入数据库，此部分数据通过常规请求导入即可。
Ø 测试数据：测试输入数据指在测试过程中所涉及到的各类业务数据，此部分数据会直接对业务功能产生影响，准备此类数据需要考虑实际业务数据分布维度和系统表本身的结构。（通常会从生产环境将数据脱敏后导出/导入的比较多）
************解释************
说到测试数据，我们可以举个栗子：假设我们有个需求，要测一套你从开发商手里买的新的毛坯房，能装下多少海洋球（负载）。客厅、卧室、卫生间（基础数据）都给你建好了，后续想在客厅、卧室、卫生间分别放多少个海洋球（测试数据），就是你自己的事儿了。这里要说一下数据分布维度的问题：你将客厅用5W个海洋球装满了，然后你就说这套房子的上限就是5W……那卧室、卫生间就被忽略了！这样的统计结果是不准确的，我们应该让海洋球充满每一个角落（数据分布）近乎于平均！
这里插播一个跟数据准备无关但又非常重要的步骤——测试执行机的准备！除了大家项目组内有可用的执行机资源以外，我们还可以去付费申请云平台主机作为执行机，也可以用Power平台进行执行。这里要注意的是，除了Power平台，我们直接在执行机上压测前，一定要注意防火墙问题；建议选择与测试环境同一网段内的执行机，尽可能的降低网络环境对性能评估的影响。除了单并发单次循环的脚本调试外，我们非常不建议使用办公网络进行性能压测。（道理很简单，我就问问你，用办公环境长时间高并发发送请求，把网络阻塞了，这个锅你背不背？！）
C.场景设计
根据之前选择的性能测试类型，我们需要构造不同的“适用场景”和“脚本场景”：
基准测试：
适用场景：缺陷发现，能力验证
脚本场景：单点场景，流程场景
对比测试：
适用场景：性能调优
脚本场景：单点场景，流程场景
稳定性测试：
适用场景：能力验证
脚本场景：复合场景
负载测试：
适用场景：缺陷发现，能力验证
脚本场景：单点场景，流程场景
在经过前期的各种准备后，就可以开始制定性能测试计划。先进行系统分享，确定使用的协议，熟悉相关功能的业务流程，确定系统相关信息；然后再定义测试目标，先了解业务的用户需求，分解测试模板。了解完成后，就可以明确测试各个功能点在特定的场景下最终需要达到的相关指标。最后要确定好环境（容量的规划）和准备必要的测试数据，最终完成性能测试计划。
五. 性能测试执行（三分钟教会你用Jmeter进行性能压测）
本文主要以“如何做性能测试”为主，压测工具只是个“过客”，所以我们只抽取其中一个最简单的单接口测试脚本来演示，想看介绍jmeter的，可以自行百度。现在打开jmeter，跟我一起完成一个脚本……
a.我用的“Jmeter3.0”，打开jmeter，
b.新建个线程组（“线程数：1”、“循环次数：1”——方便调试）
c.在线程组下新建个HTTP请求
d.我们将“主机”、“路径”、“请求的内容”填好，保存这条HTTP请求
e.添加断言
f.添加监听（察看结果树&聚合报告）并运行脚本
一个简单的单接口单场景的论坛登录脚本就跑完了，是不是跟写“Hello World！”一样简单？不同的场景使用不同的功能、发送不同的请求、设置不同的断言、使用不同的监听；Jmeter更多的功能需要大家自行体会，在此我们就不细说了。
至此，你已经可以完成一些简单的性能测试了，Congratulations！
六、结果查看及分析
根据之前的压测，我们可以取得相关的性能测试结果，具体如下：
通过Jmeter的“聚合报告”，我们可以直观的看到“请求数”、“各种响应时间”、“错误率”、“吞吐量”、“每秒从服务器端接收的数据量”等各项性能指标。通过公司监控平台（RSMS、Dolphin、Zabbix等）或者直接通过监控各服务器系统资源，我们可以收集到系统各项性能指标的数值。具体可通过如下这些维度和方法进行分析：
a. CPU分析（当应用服务器CPU使用率大于80%）
1) CPU使用率细分占比分析: ( sys% cpu, usr% cpu, wa% cpu所占比例)
2) Linux下可通过top命令找出哪一个进程占用了较高的cpu
3) 通过pstack或jstack打印出线程堆栈（操作多次），查看当时线程的调用堆栈是执行到哪一步
4) 通过profiling工具（如Jprofiler,HPDiagnosis等），定位哪个方法消耗了大部分的cpu时间，可与第三步的分析结果进行相互印证。
b. 内存分析（判断当前系统有无内存瓶颈）
当存在内存瓶颈时，有如下两种情况：
1) 确定内存本身是否存在不足的情况（linux下可通过查看swap区的使用情况来判断），此种情况下可能需要增加内存。
2) 确定内存是否存在泄漏的情况（通过vmstat判断free,buffer,cache是否存在逐渐下降的情况或swapd出现逐渐升高的情况）。
c. JVM内存分析
我们通过JVM内存分析各个代的设置是否需要调整，分析JVM内存是否存在泄露的情况，具体操作如下：
1) 通过打印gc日志详情来判断各个代发生gc的频率和所花费时间，以及每次回收的内存大小来判断各个代的设置是否合理。
2) 通过JvisualVM观察堆内存在发生major gc后是否能够回到一个较平稳的位置来判断堆是否存在内存泄漏。
d. IO分析
磁盘监控主要是通过Iostat命令分析util%使用率是否超过80%来判断磁盘是否存在瓶颈。
e. 竞争分析
随着并发数的增加，系统压力却上不去，TPS开始维持不变但却低于预期；这时响应时间开始增加，但服务器的CPU等资源使用率却较低，资源上未见到瓶颈，这又是为什么呢？
“压力上不去”通常说明存在锁竞争或进程阻塞，又或者是容器的相关配置值（比如线程池，连接池的配置）较小。需要调整锁竞争或进程阻塞的情况可通过JvisualVM的进程运行状态进行查证。在进程阻塞的情况下，通常可见线程运行的时间较少而阻塞或等待的时间较多，相互争用，程序的并行性弱。