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