PS： 头条的不好调整word格式，有需要的自行copy+调整吧

用途：

即可用于质量团队自身的性能测试方案参考。

也可用于性能测试的验收，有些公司的性能测试是外包给了第三方。

性能测试简介：

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

Tips：本次生产集群指标TPS=5万/3600秒x8倍系数=112tps；

单机环境测试指标TPS=112/（3x0.8）=47tps；

2.3相关人员

2.4计划安排

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 测试监控策略

3.2 测试用例

3.3测试准备

3.3.1 测试环境

测试环境布局如下：(同测试架构图)，测试环境硬件信息如下：

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 测试数据

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 阈值要求

3.5过程准则

4 附录

4.1相关术语

4.2其他

无