性能测试流程
- 帮助大家了解性能测试流程
- 提高性能测试意识，识别、排查性能隐患
- 完善公司性能测试流程
二、性能测试简介
1、概念
模拟并发用户访问系统，根据监控的指标来评估系统的性能。
2、目的
- 验证上线功能点是否满足性能指标
- 找出服务器的承压能力，作为优化和扩展的评估资料
- 减少宕机风险，提高用户体验
3、分类
|
类别 |
含义 |
|
压力测试 |
模拟大量用户向服务器产生负载，使服务器资源处于极限状态并长时间运行 |
|
容量测试 |
一定用户数，测试数据在不同数量级的情况下，系统承受的最佳容量 |
|
负载测试 |
测试服务器在满足用户要求的范围内，能承载的最大用户数 |
如上表格是根据不同的测试目的来划分性能测试，我认为更简单的概括应该是：前端性能和后端性能
前端性能：主要表现在页面加载，一般会通过优化加载方式，减少数据传输量来进行。
后端性能：主要涉及到接口的处理逻辑优化、服务器参数配置、硬件资源消耗等。
三、性能需求
1、需求来源
性能需求一般是在需求评审会议上由产品、架构师、开发一起讨论决定的，可以从以下两个点来展开：
- 新系统
- 产品、架构师在前期需求调研时，预估出可能造成大并发的点（大量用户同时请求，大量计算型任务、频繁操作数据库等场景）；
- 旧系统
- 根据生产环境日志（ELK），统计出高频访问接口（动态资源），以此确定对应的业务场景
- 线上曾经出现过性能问题的点，可作为参考
- 大型活动，例如抢红包，直播，秒杀活动等
- 主观感受，功能测试时请求时间较长的点
2、并发量
- 名词解释
TPS：服务器每秒处理的事务数，在大多数情况下和QPS可以等同；
并发数（VU）：系统同时处理的请求/事务数
响应时间（RT）：等于网络传输时间+应用服务器处理时间+数据库服务器处理时间，一般取90%时间
思考时间（TT）：从业务角度来看，用户在进行操作时，每次请求之间的时间间隔
- 计算公式
经常会遇到“设置多大并发用户数合适”的问题，在没有任何思考时间（TT）的情况下，这里有个公式：
VU（并发压测用户数） = TPS（每秒执行事务数） × RT（响应时间）
TPS计算方法（两种）：
1、ELK中kibana组件可以实时统计出线上接口访问情况，选取三个月内访问量最大的一天，然后缩小时间范围，精确到半小时以内，进而计算出每秒最大峰值访问量
2、 以半年或者三个月为区间，提取某一天中接口的峰值访问量，根据现网网卡的流量，分析一天中用户的活跃时间段，然后采用二八原则（即80%的访问是在20%的时间内完成），随后计算出每秒的访问量，即TPS
举例：
假设理财社区半年内浏览帖子的日访问量峰值是500万（从日志中提取）；
现网网卡流量来看，每天社区活跃时间区间为早上八点到晚上十点（08:00-22:00），共计14小时。
根据二八原则，400万（500*80%）的访问量是在2.8小时（14*0.2）内完成的，转化成秒，
即TPS = 4000000/（2.8*3600) = 396
假设用户每次打开帖子的响应时间是2秒，那么此时并发数为792
注：实际测试过程中，为了模拟更多用户，会在脚本中加大思考时间，这样得到的并发用户数就会变大，也更加仿真。
第一种方法更为精确（推荐使用），第二种可能会有一定误差。
3、接口文档
在确定了具体的业务场景后，开发人员需要提供该业务的接口文档，以便测试人员预估脚本的开发难度，准备测试数据等；
四、性能指标
- 响应时间，理想情况，单个接口响应时间低于1秒，最多不能超过3秒
- TPS是否达到预期值
- 事务成功率不能低于98%
- 服务器资源利用率
|
指标 |
阈值 |
备注 |
|
CPU |
<70% |
过高会导致系统服务不稳定 |
|
内存使用率 |
<70% |
同上 |
|
磁盘使用率 |
<70% |
同上 |
|
网络带宽 |
<70% |
过高会导致网络延迟，响应时间变长 |
五、系统架构
后端性能测试是基于接口来进行，了解系统架构，有利于我们知道接口的处理逻辑、数据流向，大概知道哪些地方可能会有瓶颈，因此也会在相应的地方添加监控。
graph TD
A[客户端]-->B[HTTP服务器]
B -->C[应用服务器]
C -->D[缓存]
D -->E[数据库]
六、测试计划
性能测试是一个团队协作完成的项目，需要各个部门配合，因此在测试前充分沟通、做好排期非常重要。
|
任务 |
具体内容 |
责任人 |
开始时间 |
完成时间 |
目前进展 |
备注 |
|
测试方案 |
||||||
|
测试环境 |
||||||
|
测试数据 |
||||||
|
脚本开发 |
||||||
|
执行测试 |
||||||
|
分析调优 |
||||||
|
测试报告 |
七、测试方案
根据具体的需求分为单场景和混合场景，单场景主要是测试某个接口的性能极限，混合场景主要是更加仿真，尽最大可能模拟真实环境。
1、单场景
对单个业务场景进行基准测试，采用压力逐步递增的方式，找到性能拐点。
举例：
|
场景 |
并发数 |
加压时间（分） |
平均时间（秒） |
90%时间（秒） |
TPS |
|
浏览帖子 |
10 |
10 |
1 |
1.5 |
10 |
|
浏览帖子 |
20 |
10 |
|||
|
浏览帖子 |
30 |
2、混合场景
对所有业务场景进行阶梯式压力发起，得到最佳处理能力（需要保持背景压力和实时业务压力不变）。
举例：
|
场景 |
并发数 |
加压时间（分） |
平均时间（秒） |
90%时间（秒） |
TPS |
|
浏览帖子 |
10 |
10 |
1 |
1.5 |
10 |
|
发帖 |
20 |
10 |
|||
|
回复帖子 |
20 |
举例：一个系统除了浏览帖子这个场景外，还有其他的访问压力（发帖，回帖），在逐步对浏览帖子这个场景施压的时候，需要把其他的压力加上
3、稳定性测试
以混合场景，日常交易量的压力对系统进行长时间（24小时以上）的稳定性测试，考察系统长期稳定运行情况。
八、评审
测试计划、测试指标、测试方案需要拿出来让各个部门共同讨论决定，如果通过则可以进行下一步。
九、被测环境
1、环境要求
- 独立
1、排除其他应用干扰，防止资源竞争；最好是实体机，若是虚拟机需要保证压测时，带宽足够，其他虚拟机最好停用。
2、压测不能在生产上进行。
3、建立挡板，如若有涉及到外围系统，可根据实际情况，考虑屏蔽或者使用mock接口来模拟
- 和生产环境架构、软件版本保持一致
1、现实情况中，测试环境很难和线上配置保持一致，此时应当保持测试环境的架构和生产上一样，再按照环境配置的比例大致估算出性能差异。配置比例一般以机器数量、CPU核数、内存数作为衡量指标；
参考公式:n =公倍数（（生产环境web服务器/测试环境web服务器），（生产环境app服务器/测试环境app服务器））*（生产服务器内存/测试服务器内存）
2、服务器软件版本和生产环境保持一致（nginx,tomcat,jdk,redis,mysql等）
- 压测时限制条件去掉
1、为了模拟大并发，我们的请求全部都是从一台机器上发送的，可能为了防止DDos攻击，对访问的IP的次数和频率都有限制，此时应该从代码层将限制去掉
2、短信、图形验证码校验需要屏蔽，（目前短信验证通过工具无法绕过，简单的图形验证可以通过OCR技术识别，复杂的可借助于深度学习）
2、部署环境
需要开发、运维、DBA协助来进行，部署最新的代码（功能测试通过后的），并加上相应监控项。
3、环境清单
需要从运维那里拿到生产环境和测试环境的配置信息。
举例：
|
IP |
机器用途 |
操作系统 |
软件版本 |
机房 |
配置 |
||
|
192.168.1.100 |
数据库 |
centos |
mysql5.6 |
北京 |
CPU: E5-2620 2.0GHz 6核 *2 \ |
内存：8*24G \ |
硬盘：8*300G |
|
192.168.1.101 |
... |
... |
... |
... |
|||
|
... |
|||||||
|
... |
|||||||
|
... |
九、压力发起环境
1、压力发起方式
- 使用工具来发送大量HTTP请求，如Jmeter，Loadrunner，Locust
- 依赖第三方的jar包或者库，用Java或者Python编写代码
- 实时拷贝线上流量，借助于TCPCopy、gor等，将线上流量导入到被测环境中
2、机器配置
- 一台机器的带宽、最大文件句柄数都有系统级限制，为了能发起更大压力，测试过程中可能需要多台机器组建集群来同时施加压力
压测开始时中先使用一台机器，如若压测机cpu和内存被占满、或者TPS上不去，则再考虑搭建集群，现在我们普遍用的配置是8核16G， windows2008操作系统。
- 机器应当尽量和被测环境在同一网段内，这样才能避免因网络延迟导致并发压力上不去的状况。
3、搭建环境
- 配置jdk
- 安装jmeter及其插件
- 调整jvm参数
- 部署集群
十、测试账号和数据
1、测试账号
压测过程就是模拟大量用户访问系统的行为，因此必然涉及到用户登录的问题，那么就需要足够的测试账号。
避免只使用一个账号来模拟多用户，一个用户发送多次请求和多个用户发送一次请求，因为缓存的原因，对系统压力是不一样的。
2、服务器账号
在了解系统架构后，为了监控服务器的各项指标，需要找运维同事申请服务器账号（操作系统、数据库、redis等），如若因为权限问题不能给到账号，则需要运维同事帮忙看监控。
3、数据
- 测试数据
测试数据应当尽量模拟用户的真实操作
举例：用户在论坛发帖，假设发帖的字数平均在100字左右，但是脚本中发送的却只有10个字，那么在数据传输过程中，对带宽以及数据库存储空间的消耗是不一样的。
脚本模拟的是多个用户的操作，因此对于有些参数不是唯一的，就不应该写死，而需要动态传入不同的值
举例：模拟用户浏览帖子的接口（http://bbs.feidee.com/thread-718207-1-1.html），718207是帖子ID，
因为每个用户看的帖可能不一样，且社区帖子有很多个，那么此处每次请求的参数应该是不同的帖子ID，可提前在数据库中将帖子ID导出到本地文件中，然后每次请求时依次读取。
- 数据库数据
数据库中应该用足够的数据，避免“空库测性能”，可依据生产环境中的数据存量按照一定的缩小比例来决定数据量。
十一、测试脚本
分析完压测需求后，拿到对应的压测接口文档，根据对应的Url、参数，通过工具来模拟大量用户发送请求；本文中以jmeter举例；
- 搭建jmeter运行环境
- 部署分布式压测集群
- 设置并发线程、脚本运行时间
- 使用jmeter发送http请求
- 添加监听器（聚合报告、TPS）
- 调试接口
- 脚本试运行。
注：接口调试成功后，可以设置多个线程，运行时间设置为5分钟，打开查看结果树，运行脚本，看是否有报错。没有的话则压测脚本编写完成。
十二、服务端监控项
在实际压测过程中，因测试人员没有权限的问题，很多监控项是需要运维、DBA同事来协助，因此这个环节需要大量的沟通工作。
1、服务器硬件资源
1、使用监控系统:Zabbix，Cacti，NMON, jmeter-Agent，监控cpu，内存，IO，网络等使用情况
2、使用命令行，top,iostat ,vmstat，sar
前端nginx作为高性能的反向代理服务器，一般很少有瓶颈，故此处不加监控
2、应用
1、tomcat连接池配置
2、jvm堆内存使用情况，fullGC次数以及时间
3、部署jvisualvm或者jprofiler
3、数据库
1、慢sql
2、缓存命中率
3、全表扫描数
4、连接数
4、缓存
1、内存使用率
2、命令处理数
3、慢命令
4、连接数
十三、执行测试
运行测试脚本， 实时观察聚合报告，如若出现大量错误，需要立即停止，并分析原因，重新调试；
特殊情况下，有些压测时间需要在凌晨进行，那么可以借助于jmeter的调度器定时启动脚本；
十四、结果分析、调优
将测试结果与用户预期指标进行对比，如果达到则测试通过；如果达不到，则需要提交bug，并进一步分析原因，待开发修复后，重新执行测试，直到符合指标为止。
1、接口响应时间
从jmeter的聚合报告中看平均时间和90%响应时间
2、 TPS
1、jmeter聚合报告中的吞吐量
2、jmeter插件：Transactions per Second 看TPS的走势
3、服务端资源利用率
从Zabbix监控上看服务器的资源利用率（包括应用、数据库、缓存）
4、事务成功率
从聚合报告上看各个接口的错误率，不能超过2%
5、分析步骤
- 如果响应时间过长，那么可以按照下面的思路逐步分析：
1、查看tomcat和nginx日志，如有报错，分析错误原因
2、网络原因，用sar命令或者Zabbix监控查看网络出口、入口流量，排查是否是网络延迟
3、查看数据库慢sql日志，看是否有耗时较长的sql
4、查看redis慢命令以及命令处理数，看是否有耗时较长的命令
5、查看jvm使用情况，看是否有fullGC情况
6、查看tomcat与nginx、redis、mysql的连接数是否设置足够
7、使用jvisualvm、jprofiler的热点分析（或者线程dump），找出耗时最长的代码
8、各个服务器硬件资源是否达到瓶颈
- 如果TPS上不去：
1、压测机的资源消耗情况
2、查看压测环境jmeter堆内存设置、最大文件句柄数
3、聚合报告中带宽消耗是否达到瓶颈
4、考虑搭建集群
6、常见性能问题
1、数据库过多调用
2、数据库资源泄露
3、连接池太小
4、sql未加索引、锁表
5、写log影响IO性能
6、jvm参数设置不合理
7、服务端未启用长连接
十五、性能测试流程
十六、测试报告
1、测试结论
根据结果分析的结论，得出此次压测是否满足用户预期指标。
性能测试采用的测试策略是：在测试环境用脚本模拟用户的操作，进而向服务器发起压力，预估是否有性能问题。即使各个测试环节都正确，也和正式环境上用户行为有一定误差，因此很多情况下，测试结果只能作为参考，不能完全作为依据。
2、输出报告
将以上性能测试的全流程（包括压测结果、相应服务器截图、发现的性能bug、遇到的问题）整理好文档后，用邮件的方式发送给相对应开发、产品、运维、DBA、测试，并抄送上级领导。
