性能测试简介：
性能测试包括的范围非常广泛， 简单来说可以分为后台性能测试（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其他
无
