上一篇我们介绍了
一、什么是性能测试
二、术语
三、性能测试类型
在这一篇中，我们主要介绍：
四、性能测试流程
五、性能测试执行（三分钟教会你用Jmeter进行性能压测）
六、结果查看及分析
四. 性能测试流程
①. 需求分析及评审
Ø 明确测试目的：
根据需求来选取一种或者多种性能测试类型，比如“针对以前未进行过性能测试的系统，在本次版本发布前，需要对系统进行性能的评估”，这时我们至少就需要选取“基准测试”；
Ø 明确测试内容：
选取待测功能点时可以根据三个原则：“核心功能或流程”、“使用人数”和“数据量”。
************解释************
核心功能点或流程：按照重要性先后顺序，对系统的核心功能和核心流程进行排序，优先压测重要性较高的功能点或流程；
使用人数：假设系统有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%
带宽使用率 小于80%
*********************
②. 性能测试策略
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.场景设计
根据之前选择的性能测试类型，我们需要构造不同的“适用场景”和“脚本场景”：
基准测试：
适用场景：缺陷发现，能力验证
脚本场景：单点场景，流程场景
对比测试：
适用场景：性能调优
脚本场景：单点场景，流程场景
稳定性测试：
适用场景：能力验证
脚本场景：复合场景
负载测试：
适用场景：缺陷发现，能力验证
脚本场景：单点场景，流程场景
************名词歪解************
Ø 缺陷发现：等同于查看你是不是有酒精过敏的毛病，得了这个病，基本上你就废了，喝不成……
Ø 能力验证：来，喝了这杯，还有三杯……（25杯之后不省人事了~！@#￥%……）
Ø 性能调优：加强体育锻炼、增强人民体质……然后继续喝~
Ø 单点场景：只喝啤的……
Ø 复合场景：啤酒、白酒、红酒同时来！
Ø 流程场景：先干三杯啤酒漱漱口，再来两杯红酒开开胃，最后吹了这瓶白的；一鼓作气，完美！
③. 性能测试计划制定
在经过前期balabalabala的各种准备后，就可以开始制定性能测试计划。先进行系统分享，确定使用的协议，熟悉相关功能的业务流程，确定系统相关信息；然后再定义测试目标，先了解业务的用户需求，分解测试模板。了解完成后，就可以明确测试各个功能点在特定的场景下最终需要达到的相关指标。最后要确定好环境（容量的规划）和准备必要的测试数据，最终完成性能测试计划。
五. 性能测试执行（三分钟教会你用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的进程运行状态进行查证。在进程阻塞的情况下，通常可见线程运行的时间较少而阻塞或等待的时间较多，相互争用，程序的并行性弱。
七、最后
（看到这里，肯定不止十分钟啦~我只是希望大家多一点自信，多一点涉猎，多几个“十分钟”，就没有什么是不会的了！）
至此，您已简单了解了性能测试从“前期准备”到“中期执行”再到“后期分析”的概念和具体操作步骤，希望此篇文章能够带您窥探到性能测试的冰山一角。性能测试的领域博大精深，这需要大家在具体的项目中进行进一步的学习和实践。俗话说，“实践才是检验真理的唯一标准”，大家赶紧对照着自己手中的业务系统，行动起来吧！
网友评论