转载：https://www.cnblogs.com/imyalost/p/11312376.html
最近有些同学找我咨询关于性能测试计划相关的问题，原因是他们公司要做性能测试，Leader要求写一份性能测试计划，苦于之前没做过相关工作，无从下手。
这篇博客，结合我个人的一些经验和总结，聊聊如何制定一份较为全面的性能测试计划。。。
一、测试背景
首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。
比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。
核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。
二、测试目的
测试的目的要根据测试背景来分析设定，比如：
1、线上服务由于流量过高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；
2、运营做了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否满足新的线上业务；
3、系统架构由集群技改为微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；
三、测试范围
通过需求调研，分析用户使用场景，对业务数据量增长变化趋势及峰值活跃用户等数据做定量分析，确定被测系统的应用范围，比如订单+购物车+商品+支付服务。
| 业务归属模块 | 业务涉及场景 |
| 订单 | 创建订单 |
| 取消订单 | |
| 购物车 | 添加购物车 |
| 删除购物车 | |
| 商品 | 商品列表 |
| 商品详情 | |
| 支付 | 余额支付 |
| 支付宝支付 | |
| 微信支付 |
四、术语约定
这里的术语指的是：涉及本次性能测试相关的一些专业术语说明，目的是统一口径，做解释说明，便于参与本次性能测试的相关人员理解。常见术语如下：
| 术语名称 | 术语释义 |
| 并发 | 单位时间内（S）模拟客户端发起的请求数量 |
| 稳定性 | 验证系统在长时间（24h/48h）负载情况下的性能表现 |
| 高可用 | 验证系统在一部分服务宕机后能否正常提供服务以及服务恢复速率 |
| TPS | 每秒事务数，即系统单位时间内（S）的请求处理能力 |
| RT | 响应时间，及系统处理一笔请求所耗费的时间 |
| 请求成功率 | 在测试过程中，系统成功处理请求占总请求数的百分比 |
PS：术语约定以实际情况为准，还要考虑性能测试计划的受众对于性能测试的了解程度，本约定旨在统一描述的口径，降低沟通成本。
五、环境说明
一般来说，进行性能测试的环境都是在UAT或者独立的性能测试环境，但为了准确描述环境类型和配置，以及测试环境和生产环境的区别，建议对生产环境和测试环境进行对比说明。
1、生产环境
①、系统架构
PS：上图只是一个简略的微服务类型系统架构，只做示意，理解即可。
②、服务配置
| 服务名称 | 数量 | 配置 | 备注 |
| gateway server | 10 | 2C3G | 网关服务，身份验证和请求转发 |
| web server | 3 | 2C3G | |
| app server | 5 | 2C3G | |
| Redis | 3 | 4G | 哨兵模式，一主两从 |
| DB | 2 | 8C16G | 一主一从 |
2、测试环境
①、系统架构
②、服务配置
| 服务名称 | 数量 | 配置 | 备注 |
| gateway server | 5 | 2C3G | 网关服务，身份验证和请求转发 |
| web server | 2 | 2C3G | |
| app server | 2 | 2C3G | |
| Redis | 2 | 4G | 哨兵模式，一主一从 |
| DB | 2 | 8C16G | 一主一从 |
3、负载机配置
负载机（machine）即模拟客户端发送请求的机器，一般情况下，说明负载机的硬件配置，数量，IP，发压策略即可。
4、网络
即负载机和性能测试环境的网络状况，比如国内公网/同一VPC内网，防火墙策略等。
六、需求分析
需求分析一般有这几个阶段：需求接入→需求收集→需求分析，主要内容如下：
1、业务模型
如下是一个典型的电商平台核心业务链路图，涉及到登录、首页、商品、购物车、支付、分享等模块。
2、性能指标
这里的性能指标包含如下两项：
①、业务性能指标
即预期的TPS、RT、请求成功率（一般默认请求成功率≥99.99%）。
②、硬件性能指标
即服务端资源耗用指标，常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。
七、测试策略
本次性能测试所采用的测试策略，比如：
探测系统性能拐点，需要阶梯式压测；
探测系统在可接受的性能指标下最大的处理能力，需要采用负载、容量测试策略；
验证系统的稳定性和高可用，需要采用稳定性、高可用测试策略；
验证系统在不同配置下的性能表现，一般采用配置测试策略；
1、测试策略及场景
①、容量测试
|
场景名称 |
01_登录 02_首页 |
|
执行时间 |
10min |
|
业务配比 |
100% |
|
测试策略 |
容量测试 |
|
测试目的 |
不断增加负载，验证系统单节点的最大性能表现 |
②、稳定性测试
|
场景名称 |
混合场景 |
|
执行时间 |
24h |
|
业务配比 |
按生产业务配比，等比缩放 |
|
测试策略 |
稳定性测试 |
|
测试目的 |
验证系统长期运行的稳定性以及是否存在OOM之类的问题 |
PS：如上表格描述，依然作为一个示例来说明，主要内容包括：场景编号、测试类型、涉及业务场景、业务配比、执行时间、测试目的。
2、测试监控策略
| 监控对象 | 指标范围 | 监控工具 |
| CPU | ≤90% | nmon、zabbix |
| Memory | ≤70% | |
| 网络IO | 无明显IO瓶颈 | |
| JVM | 无频繁FGC情况 | jmap、jstat |
八、准备工作
准备工作主要包含如下几项：
| 准备事项 | 准备内容 | 责任人 | 预计完成时间 |
| 工具准备 | 负载工具、监控工具、分析工具 | 测试/运维 | 0.5工作日 |
| 脚本准备 | 测试脚本 | 测试 | 0.5工作日 |
| 环境准备 | 机器配置、服务部署联调、脚本调试 | 运维/开发 | 1工作日 |
| 数据准备 | 铺底数据、测试数据、参数化数据、缓存数据 | DBA/开发/测试 | 1工作日 |
九、组织架构
组织架构即本次性能测试涉及到的团队各角色成员，主要包含这些：PM角色、测试、开发、运维、DBA、网络、基础架构。示例：
十、风险分析
罗列开始执行前会影响本次性能测试工作开展的风险项以及应对方案，比如：
| 风险类型 | 风险描述 | 风险级别 | 应对方案 |
| 交付风险 | UAT阶段发现较严重的功能缺陷 | 高 | 测试时间顺延，或增加对应人员 |
| 变更风险 | 临时需求变更、新增需求 | 高 | 需求评审是否加入本次测试范围，阶段性交付 |
| 数据风险 | 数据脱敏耗时较长、测试数据不可用 | 中 | 重新拟定数据准备方案，小范围数据验证 |
| 环境风险 | 部署出现问题，联调进度缓慢、网络带宽瓶颈 | 中 | 更换环境、增加资源配置、扩展带宽 |
十一、交付清单
在性能测试计划中，需要说明本次性能测试各阶段的交付物，主要包含这几项：性能测试计划&方案、测试脚本、性能缺陷统计、轮次小节、性能测试报告。
十二、阶段进度
这里主要指的是从需求阶段到结束，各个阶段的工作进展以及资源安排，建议采用看板的方式，及时更新进度，方便推进工作的开展。示例如下：
|
阶段 |
事项 |
开始时间 |
结束时间 |
状态 |
责任人 |
|
需求阶段 |
需求评审 |
|
|
完成 |
多方参与 |
|
系统架构图 |
|
|
完成 |
开发 |
|
|
需求调研 |
|
|
完成 |
性能测试人员 |
|
|
准备阶段 |
环境交付 |
|
|
完成 |
运维、开发 |
|
应用部署 |
|
|
完成 |
运维、开发 |
|
|
数据准备 |
|
|
完成 |
开发、DBA、测试 |
|
|
脚本开发 |
|
|
完成 |
性能测试人员 |
|
|
实施阶段 |
执行压测 |
|
|
未完成 |
性能测试人员 |
|
服务监控 |
|
|
未完成 |
运维、测试 |
|
|
数据收集 |
|
|
未完成 |
性能测试人员 |
|
|
结束 |
报告评审 |
|
|
未完成 |
多方评审 |
如上，就是一个较为完整的性能测试计划内容，当然，完成性能测试计划并评审通过后，就可以进入测试执行阶段了。。。
标签：指南,测试计划,服务,请求,性能,系统,从零开始,测试 From： https://www.cnblogs.com/ceshi2016/p/17221676.html