性能测试计划模板
性能测试介绍
性能测试的目标
性能测试是一种信息的收集和分析过程，它考察在不同的用户负载下，系统对用户请求做出的响应情况，以确保将来系统运行的安全性、可靠性和执行效率。
性能测试可以看作是一种“黑盒测试”，测试的主要目标表现在六个方面，分别为：
1、在系统可以接受的性能水平下，系统可以支持的最大的并发用户数目；
2、在系统崩溃前的临界情况下，系统可以支持的并发用户数目；
3、应用体系中的瓶颈位置；
4、软、硬件配置的更改对系统整体性能上带来的影响；
5、系统的可伸缩性（在用户可忍受的范围内可以处理的最大数据量等）；
6、系统在不同用户负载下各种资源的利用情况。
性能测试的目的
1、验证性：验证系统在具体的并发下，能否满足指定的需求指标；
2、探测性：测试接口及整个系统的稳定性及负载压力承受值；
3、调优性：发现系统的性能瓶颈。
性能测试的分类
1、负载测试
获取性能拐点；是一种主要为了测试软件系统是否达到需求文档设计的目标，比如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能
2、压力测试
获取极限性能指标；强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，比如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同
3、稳定性测试
7*24小时征程运行
4、容灾测试
确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等
性能测试计划包含哪些
性能测试目标
根据对需求的分析，确定本次压测的目标，再根据目标去设定需要关注的相关指标
性能测试方案
1、压测模块分析
算法模型类的模块，对CPU要求比较高，我们需要重点关注cpu指标
大量数据传输模块，对网络IO占比比较高，我们需要重点关注IO网络
缓存数据存储模块，对内存占比比较高，我们需要重点关注内存
大量日志记录模块，对磁盘占比比较高，我们需要重点关注磁盘
2、压测工具选型
针对压测模块的分析，确定压测工具的选择
常见的压测工具：
tcpcopy、jmeter、 Apache ab、loadRunner、Grinder、Locust
3、压测方案流程
根据模块和工具选型，确定详细的压测流程图，使大家明确本次压测的详细过程
4、压测场景分析
针对压测模块分析，确定需要压测的场景
5、压测数据构造
针对不同场景，构造对应压测数据
6、压测环境搭建
搭建压测环境
性能测试环境
1、硬件环境
| 服务 | 机器 | 磁盘 | 内存 | cpu核数 |
|---|---|---|---|---|
| service1 | 10.126.92.2 | 64G | 64G | 16 |
| service2 | 10.126.92.3 | 64G | 64G | 16 |
2、软件环境
使用的起压工具是什么，什么版本，在哪里部署着
eg：
1、Tcpcopy 0.9 版本
客户端机器：10.126.101.1 10.126.82.3
客户端工具目录：/opt/soft/tcpcopy
操作命令：
sudo tcpcopy -x 10080-10.9.193.69:10080-s 10.9.193.69 -n 1 -d
sudo tcpcopy -d
服务端机器：10.9.193.69
服务端工具目录：/opt/soft/intercept
操作命令：
sudo intercept -i 10080
sudo intercept -d
sudo intercept -q
性能数据准备
1、基础数据
依赖的相关数据准备
2、压测数据
接口对应的请求参数等
关注指标
1、机器维度
以下是经验值，大家可以参考
| 指标 | 好 | 坏 | 糟糕 |
|---|---|---|---|
| cpu | user%+sys%<60% | user%+sys%=85% | user%+sys%>=90% |
| 内存 | si=0;so=0 | Per CPU with 10 page/s | MoreSwap in &swap Out |
| 磁盘 | iowait%<20% | iowait%=35% | iowait%>50% |
常用命令见性能数据分析文章
2、被测服务维度
吞吐量
抛弃量
异常量
响应情况（平均、99%、99.9%、99.99%）
目标与风险
1、测试目标
服务对外承诺的响应数据以及机器的负载情况
2、测试风险
相关服务依赖的服务是否会成为瓶颈，影响上游被压测的服务性能评估
排期和任务分解
1、测试任务
性能测试任务拆解，可以从数据构造、环境搭建、起压工具、压测执行、数据统计、数据分析等方面进行
2、测试排期
按照任务给出最终测试排期
数据统计以及分析
数据统计：
| 压测服务 | 服务平均QPS | Cpu占比 | 内存占比 | 磁盘占比 | 服务超时量 | 请求抛弃量 | 平均响应情况 | 99.9%响应情况 | 99.99%响应情况 |
|---|---|---|---|---|---|---|---|---|---|
| service1 | 1000qps | ||||||||
| service1 | 2000qps | ||||||||
| service2 | 1000qps | ||||||||
| service2 | 2000qps |
数据分析：
1、不同测试场景多轮次测试，对比数据结果
2、分析输出数据，通过对数据的分析，获得测试报告
3、系统调优后，回归测试，验证优化效果
优化建议
网络方面优化：
1、考虑传输的数据量（尽量压缩处理，不要占用太多字节）
2、传送实体
磁盘方面优化：
1、减少不必要的日志；
2、定时清理日志
cpu方面优化；
1、线程池优化：线程池选择，非cpu类型的
2、如果逻辑与顺序无关，并行代替串行
其他时间方面优化：
1、如果超时或者请求错误，则快速结束失败，避免继续等待执行
2、代码实现过程中尽量减少JSON类型处理，这种解析消耗时间较大