---

前言

1、测试背景

首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。

比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。

核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。

2、测试目的

测试的目的要根据测试背景来分析设定，比如：

线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；

运营做了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否满足新的线上业务；

系统架构由集群技改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；

3、测试范围

通过需求调研，分析用户使用场景，对业务数据量增长变化趋势及峰值活跃用户等数据做定量分析，确定被测系统的应用范围，比如订单+购物车+商品+支付服务。

业务归属模块	业务涉及场景
订单	创建订单，取消订单
购物车	添加购物车，删除购物车
商品	商品列表，商品详情
支付	余额支付，支付宝支付，微信支付

4、术语约定

这里的术语指的是：涉及本次性能测试相关的一些专业术语说明，目的是统一口径，做解释说明，便于参与本次性能测试的相关人员理解。

常见术语如下：

术语名称	术语释义
并发	单位时间内（S）模拟客户端发起的请求数量
稳定性	验证系统在长时间（24h/48h）负载情况下的性能表现
高可用	验证系统在一部分服务宕机后能否正常提供服务以及服务恢复速率
TPS	每秒事务数，即系统单位时间内（S）的请求处理能力
RT	响应时间，及系统处理一笔请求所耗费的时间
请求成功率	在测试过程中，系统成功处理请求占总请求数的百分比

PS：术语约定以实际情况为准，还要考虑性能测试计划的受众对于性能测试的了解程度，本约定旨在统一描述的口径，降低沟通成本。

5、环境说明

一般来说，进行性能测试的环境都是在UAT或者独立的性能测试环境，但为了准确描述环境类型和配置，以及测试环境和生产环境的区别，建议对生产环境和测试环境进行对比说明。

生产环境
①系统架构

PS：上图只是一个简略的微服务类型系统架构，只做示意，理解即可。

②服务配置

服务名称	数量	配置	备注
gateway server	10	2C3G	网关服务，身份验证和请求转发
web server	3	2C3G
app server	5	2C3G
Redis	3	4G	哨兵模式，一主两从
DB	2	8C16G	一主一从

测试环境
①系统架构

②服务配置

服务名称	数量	配置	备注
gateway server	5	2C3G	网关服务，身份验证和请求转发
web server	2	2C3G
app server	2	2C3G
Redis	2	4G	哨兵模式，一主一从
DB	2	8C16G	一主一从

负载机配置
负载机（machine）即模拟客户端发送请求的机器，一般情况下，说明负载机的硬件配置，数量，IP，发压策略即可。

网络
即负载机和性能测试环境的网络状况，比如国内公网/同一VPC内网，防火墙策略等。

6、需求分析

需求分析一般有这几个阶段：需求接入→需求收集→需求分析，主要内容如下：

业务模型
如下是一个典型的电商平台核心业务链路图，涉及到登录、首页、商品、购物车、支付、分享等模块。

性能指标
这里的性能指标包含如下两项：
①业务性能指标
即预期的TPS、RT、请求成功率（一般默认请求成功率≥99.99%）。

②硬件性能指标
即服务端资源耗用指标，常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。

7、测试策略

本次性能测试所采用的测试策略。

比如：
探测系统性能拐点，需要阶梯式压测；
探测系统在可接受的性能指标下最大的处理能力，需要采用负载、容量测试策略；
验证系统的稳定性和高可用，需要采用稳定性、高可用测试策略；
验证系统在不同配置下的性能表现，一般采用配置测试策略；

测试策略及场景
①容量测试

场景名称	执行时间	业务配比	测试策略	测试目的
01_登录	10min	100%	容量测试	不断增加负载，验证系统单节点的最大性能表现
02_首页	10min	100%	容量测试	不断增加负载，验证系统单节点的最大性能表现

②稳定性测试

场景名称	执行时间	业务配比	测试策略	测试目的
混合场景	24h	按生产业务配比，等比缩放	稳定性测试	验证系统长期运行的稳定性以及是否存在OOM之类的问题

PS：如上表格描述，依然作为一个示例来说明，主要内容包括：场景编号、测试类型、涉及业务场景、业务配比、执行时间、测试目的。

测试监控策略

监控对象	指标范围	监控工具
CPU	≤90%	nmon、zabbix
Memory	≤70%	nmon、zabbix
网络IO	无明显IO瓶颈	nmon、zabbix
JVM	无频繁FGC情况	jmap、jstat

8、准备工作

准备工作主要包含如下几项：

准备事项	准备内容	责任人	预计完成时间
工具准备	负载工具、监控工具、分析工具	测试/运维	0.5工作日
脚本准备	测试脚本	测试	0.5工作日
环境准备	机器配置、服务部署联调、脚本调试	运维/开发	1工作日
数据准备	铺底数据、测试数据、参数化数据、缓存数据	DBA/开发/测试	1工作日

9、组织架构

组织架构即本次性能测试涉及到的团队各角色成员，主要包含这些：PM角色、测试、开发、运维、DBA、网络、基础架构。示例：

10、风险分析

罗列开始执行前会影响本次性能测试工作开展的风险项以及应对方案，比如：

风险类型	风险描述	风险级别	应对方案
交付风险	UAT阶段发现较严重的功能缺陷	高	测试时间顺延，或增加对应人员
变更风险	临时需求变更、新增需求	高	需求评审是否加入本次测试范围，阶段性交付
数据风险	数据脱敏耗时较长、测试数据不可用	中	重新拟定数据准备方案，小范围数据验证
环境风险	部署出现问题，联调进度缓慢、网络带宽瓶颈	中	更换环境、增加资源配置、扩展带宽

11、交付清单

在性能测试计划中，需要说明本次性能测试各阶段的交付物，主要包含这几项：性能测试计划&方案、测试脚本、性能缺陷统计、轮次小节、性能测试报告。

12、阶段进度

这里主要指的是从需求阶段到结束，各个阶段的工作进展以及资源安排，建议采用看板的方式，及时更新进度，方便推进工作的开展。
示例如下：

阶段	事项	开始时间	结束时间	状态	责任人
需求阶段	需求评审	无	无	完成	多方参与
需求阶段	系统架构图	无	无	完成	开发
需求阶段	需求调研	无	无	完成	性能测试人员
准备阶段	环境交付	无	无	完成	运维、开发
准备阶段	应用部署	无	无	完成	运维、开发
准备阶段	数据准备	无	无	完成	开发、DBA、测试
准备阶段	脚本开发	无	无	完成	性能测试人员
实施阶段	执行压测	无	无	未完成	性能测试人员
实施阶段	服务监控	无	无	未完成	运维、测试
实施阶段	数据收集	无	无	未完成	性能测试人员
结束	报告评审	无	无	未完成	多方评审

如上，就是一个较为完整的性能测试计划内容，当然，完成性能测试计划并评审通过后，就可以进入测试执行阶段了。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

在人生的道路上，不要害怕迎接挑战，因为只有经历了困难才能赢得更多的成长和收获。相信自己的能力，坚持不懈地追求自己的理想和目标，每一步都是向前的力量，让我们勇往直前、不断奋斗！

只有不停地努力和坚持，才能实现自己的梦想。面对任何挑战，都要勇往直前，永远不要放弃。只有这样，你才能成为你想成为的那个人。

只有不断奋斗，才能让自己变得更加优秀和出色。无论遇到多大的挫折和困难，都要坚定信心，勇往直前，相信自己一定能够战胜所有的困难，迎来属于自己的辉煌成功！