性能测试简介：
性能测试包括的范围非常广泛， 简单来说可以分为后台性能测试（Linux服务器，mysql服务器，文件服务器等等）， 客户端性能测试（WEB前端，移动端等）
一般企业的性能测试指的是狭义的后台性能测试，性能测试整个流程如下:
1. 性能测试需求与调研
2. 设计性能测试方案，并出具文档
3. 审核方案，确定后准备性能测试数据， 测试环境
4. 按照测试方案执行性能测试
5. 出具性能测试报告
性能测试需要测试具备的能力（后续博客会持续更新）：
1. 常规性能测试工具的使用（Jmeter，Zabbix，jvisualvm，Monyog 等等）
2. 对性能测试的各层进行测试的能力（一般指的是： OS层，应用层，DB层）
3. 设计合理的测试方案的能力（熟悉性能基准指标验证， 逐步加压原则， 混合压测稳定性验证等方法）
4. Linux等后台系统独立搭建后台测试环境的能力
下面是一个性能测试方案的实例：
目录
1 概述... 3
1.1 测试目的... 3
1.2 适用范围... 3
1.3 参考资料... 3
2 测试需求... 4
2.1测试架构... 4
2.2测试范围... 4
2.3相关人员... 5
2.4计划安排... 5
3 测试方案... 6
3.1 测试策略... 6
3.1.1 压测策略... 6
3.1.2 测试监控策略... 7
3.2 测试用例... 8
3.3测试准备... 8
3.3.1 测试环境... 8
3.3.2 相关工具... 9
3.3.3 测试脚本... 9
3.3.4 测试数据... 9
3.4达标出口... 10
3.4.1 软件达标出口... 10
3.4.2 阈值要求... 11
3.5过程准则... 12
4 附录... 13
4.1相关术语... 13
4.3其他... 13
1 概述
1.1 测试目的
本方案用以描述 XXX系统 的性能测试过程内容，用以指导测试人员准备并执行性能测试，发现系统中可能存在的性能问题，提出优化建议并解决，以降低或避免由于性能问题带来的系统风险，为系统的稳定运行提供保证。主要关注点如下：
- 明确测试范围和目标。
- 确认测试过程细则：测试环境、测试场景、测试策略、过程关注等。
- 性能出口要求及风险预估。
1.2 适用范围
本文档适用于参与 XXXX系统 性能测试项目的相关人员。
1.3 参考资料
2 测试需求
2.1测试架构
- 生产环境物理架构：未提供架构图，架构保证测试环境部署与生产一致（区别仅在机器的数量）
- 压测环境架构：单机环境
2.2测试场景
本次测试包含6个场景，对应场景和TPS指标如下：
场景
编号
接口名称
接口描述
协议类型
生产指标
TPS/RT
测试指标
TPS/RT
备注
S01
/XXX-info
获取会话
Http
112/0.3s
47/0.3s
S02
/XXX
获取XXX
Http
112/0.3s
47/0.3s
S03
/XXX
获取当前用户信息
Http
112/0.3s
47/0.3s
S04
/XXX/all?userId=123456
获取所有应用列表
Http
112/0.3s
47/0.3s
S05
/XXX/app/fixed
获取常用应用
Http
112/0.3s
47/0.3s
S06
home
访问首页
Http
112/0.5s
47/0.5s
Tips：本次生产集群指标TPS=5万/3600秒x8倍系数=112tps；
单机环境测试指标TPS=112/（3x0.8）=47tps；
2.3相关人员
角色
姓名
备注
架构
项目经理
开发
测试
2.4计划安排
序号
阶段
执行人
时间计划
1
性能调研和确认
2
性能方案产出
3
脚本和数据准备
4
执行性能压测
5
性能测试报告产出
3 测试方案
3.1 测试策略
3.1.1 压测策略
本次测试将采用Jmeter工具，通过控制线程数来模拟用户并发。
- 压测策略说明：
1、指标验证： 验证被测交易在测试环境中是否能达到指标要求的TPS/RT，每个轮次持续10分钟。
（单接口指标验证，如果单接口都无法达到指标，无需再进行负载和稳定性测试，不满足最基础的交付目标，需要重点优化。）
注：如接口性能较差时，在压测指标前，先使用1个并发(不加thinktime)压测3分钟，得出一组基准数据，可作为参考依据。
2、负载测试：在指标验证基础至上，对每个接口逐步增大并发，每个轮次持续10分钟。（阶梯性的加压测试，找出性能拐点，压测出当前系统下最大的处理能力，便于对后续容量和风险预估。）
3、稳定性测试：对核心场景按照指标要求进行并发配比后压测，持续时长5-10小时。（混合场景稳定性测试，验证系统整体的资源使用情况、处理能力是否平稳。）
- 测试执行策略如下：
1、拿到基准数据后，先进行指标验证测试，查看是否可以达到目标TPS；
2、在达标基础之上，使用不同并发，进行多次阶梯性负载验证，找到性能拐点；
3、针对重点场景进行混合，进行稳定性验证。
3.1.2 测试监控策略
监控层面
监控工具
说明
OS层
Zabbix/top命令
关注硬件的实时使用情况
应用层
Zabbix/jvisualvm
关注java应用线程和堆内存情况
DB层
Monyog
关注mysql在压测过程中出现的慢查询和锁
3.2 测试用例
所属
策略
用例
编号
用例名称
并发
配置
重点关注
指标
验证
C01
session-info
47
47并发，配置thinktime（控制QPS），压测结果满足47/0.3s。
C02
appkey
47
C03
getUserCurrent
47
C04
list all
47
C05
fixed
47
C06
home
47
47并发，配置thinktime（控制QPS），压测结果满足47/0.5s。
负载
测试
C01
session-info
逐步增加并发
基于指标验证用例，进行阶梯性并发压测（如50、100、150），每个阶梯压测10分钟，关注系统在各个并发下实际处理能力。
C02
appkey
C03
getUserCurrent
C04
list all
C05
fixed
C06
home
稳定性
M01
C01-C06，6个场景，各47并发
282
根据指标要求将所有场景进行混合，持续压测10小时，关注整个压测过程中系统的稳定性和资源使用情况。
3.3测试准备
3.3
3.3.1 测试环境
测试环境布局如下：(同测试架构图)，测试环境硬件信息如下：
类型
生产环境配置
测试环境配置
备注
应用1
x4
4C4G x1
Nginx，
应用2
x3
4C8G x1
IT门户
应用3
x4
4C8G x1
应用服务
应用4
x4
4C8G x1
租户服务
中间件
x1
4C8G x1
Redis
DB
x1
24C32G x1
Mysql
网络环境
公网
内网环境
所有测试应用在同一网段
Tips：应用配置相同，机器数量不同情况下，测试环境单机指标折算公式为
T测单=T生集/(N生产 x 0.8折算系数)
3.3.2 相关工具
性能测试工具：Jmeter
资源监控工具：APP--ZIBBIX、资源监控器（windows自带的）、Jmeter工具
3.3.3 测试脚本
此次测试的接口均为Http协议的（get方式），故采用Jmeter http请求sampler设计测试脚本。
- 检查点配置：在脚本中设置合理的检查点，保证接口返回的正确性（事务成功率的统计）。
- QPS控制（加thinktime）：使用JMeter插件Throughput Shaping Timer控制QPS（LR的话配置pacing time），便于进行并发压测。
3.3.4 测试数据
类型
库名
表名
测试
数据量
预估生产
数据量
是否
需要铺底
说明
Mysql
XXX-service-XXXX-auth
XXX_user
1
20万
是
压测前铺底数据20万
XXX_app
18
18万
否
配置表无需铺底
XXX_user
1
15万
是
压测前铺底数据15万
XXX_user
1
15万
是
压测前铺底数据15万
XXX-service-user
user_info
1
15万
是
压测前铺底数据15万
3.4达标出口
3.4
3.4.1 软件达标出口
1、 指标验证：压测持续10分钟，达到目标TPS指标且成功率达到100%(成功率可根据实际业务场景调整)，实际响应时间<=指标要求RT；
2、 负载验证：每个阶梯压测持续10分钟，成功率>=99.9%。
n 指标阈值：指标响应时间要求内的最大处理能力，也是最优处理能力；
n 资源阈值：资源占用（cpu/IO/mem）在80%左右时的处理能力；
n 性能拐点值：随着并发增加TPS无法增加甚至出现下降时的点。
（负载压测目的就是至少可以得到以上3个值中的某1个。）
3、 稳定性测试：运行5-10hours+，事务成功率要高于99.9%，硬件资源占用在阈值要求内。
3.4.2 阈值要求
监控类型
监控指标
阈值要求
资源监控
Load average
<CPU核数*2
CPU利用率
物理机<80%，虚机/容器<75%
系统内存使用
占用<80%
磁盘Util%
占用<80%
网络带宽
占用<70%
Java
进程监控
Younggc
Younggc频率不超过1s
Younggc时间不超过200ms
Fullgc
FullGC的频率不大于1小时，FullGC时间不超过2s。
线程状态
大量的线程blocked
currentThreadsBusy监控
数据库
慢查询
出现慢查询语句
死锁
出现死锁
中间件
Redis
Redis操作耗时<1ms
Memcache
缓存命中率>80%
日志监控
错误日志
出现严重级别的Error或Exception
业务指标
响应时间
测试结果RT<=指标要求
TPS
测试结果TPS>=指标要求
成功率
测试结果成功率>=99.99%
3.5过程准则
过程
条件
准入准则
压测环境和机器准备完成（压测机、待测应用服务和数据库、网络环境等）
待测流程的功能测试通过，版本稳定。
待测流程的测试数据和测试脚本准备完毕。
暂停准则
测试中发现问题，需要项目组修改代码或更换版本；
测试中发现服务规划及部署问题，需要重新调整部署方案；
需要调整测试环境资源配置，如加减CPU数目，增加存储等等。
测试环境使用受到干扰，如服务器被临时征用或非压测流量进入性能环境
准出准则
所有测试场景完成执行，对应各场景的测试过程数据和监控数据均已保存和记录。
性能指标达到《性能测试方案》的要求，无遗留性能问题（或评估后可暂时遗留）
测试报告完成。
4 附录
4.1相关术语
术语简写
说明
TPS/QPS
每秒事务数或每秒请求数，指服务器在单位时间内能处理的请求的数量。
如100tps，表示系统1秒处理了100个请求。
响应时间
指一个用户的从发起请求到收到响应所用的时间。
并发数
指某一时刻同时发起的请求数量（一般以秒为时间粒度）。
RT
响应时间英文简写，我们所说的RT都是指平均响应时间
PV
page view，即页面浏览量。用户对网站中的某个网页访问1次均被记录1PV。用户对同一页面的多次访问，访问量累计。一般对web测试时关注。
4.2其他
无