性能测试流程

帮助大家了解性能测试流程
提高性能测试意识，识别、排查性能隐患
完善公司性能测试流程

二、性能测试简介

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、测试，并抄送上级领导。