明确目的
{描述本次性能测试的主要目的，例如：评估系统性能，为性能调优提供依据和建议，或者做对比分析的性能测试等，或对系统的未来容量等作出预测和规划等}
性能测试目的：
- 验证改进性能效果，需要和以前的测试结果进行比对；
- 新的业务上线，验证新系统能够满足系统的上线指标。
- 验证系统稳定性；
- 验证系统的架构是否存在瓶颈。
性能测试目标：
1、 系统新上线、测试明确的数字标准对比情况下，验证系统是否可以上线。测试系统的极限，如：系统某些资源已经耗尽，CPU、句柄、内存、数据库出现大量的slow query、或者系统有些处理已经变量）或者证明系统能否根据硬件水平扩展的。
2、 没有可以比较的测试结果，但是产品已经上线一段时间（一般3个月以上），有一些运营数据，则分析运营数据来作为比对基准，只要测试系统达到3个月内系统并发峰值的4倍就可以认为是可以接受的。（如果是接口为测试对象，则需要混合主要的接口来进行性能测试）
3、 有以往测试结果进行对比，只要证明类似的测试条件下，此次的结果比以往的测试结果更好即可（每秒处理个数更多、单次请求的处理速度更快等）
4、 开发人员提供经验值作为对比的基准，则被测对象只需要证明满足开发人员提出的经验值。
一般出现瓶颈点：
硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。
应用软件上的性能瓶颈：
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。
例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。
应用程序上的性能瓶颈：
一般指的是开发人员新开发出来的应用程序。
例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。
操作系统上的性能瓶颈：
一般指的Linux等操作系统，我们用的是CentOS
例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。
网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。
例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。
一、运行环境要求（注：性能测试必须是单独的干净测试环境）
描述性能测试对象的环境要求：
1、 硬件环境需求（描述数据库服务器，应用服务器，接口后台服务器配置说明）（依据实际情况，有则写，没有则待定）；
2、 软件环境需求（依据实际情况，有则写，没有则待定）；
a、操作系统要求（描述各个硬件服务器安装的操作系统）；
b、应用软件要求（描述各应用软件的名称、安装位置、版本信息）；
c、客户端要求（描述对客户端IE、第三方软件的版本信息）；
3、运行模式（描述该系统的运行模式，如：B/S或者C/S或APP）
4、其他环境需求（如有其他环境需求则描述清楚，否则写无）
二、初始化参数
1.用户量基础数据
测试时需要在用户表增加多少用户量，作为用户基础数据
举例：对平台压测，需要准备一定数据的用户、用户详情等相关数据
2. 业务数据
课程基础数据：在业务表导入多少数据量作为业务基础数据，举例：college_lesson等关联表数据
心理FM数据：在业务表导入多少数据量作为业务基础数据，举例：fm_broadcast等关联表数据
。。。。
三、举例
1、架构技术；举例：
Web服务--描述是否使用nginx应用还是其他web应用，是否有做静态分类技术把常用的css、js等样式、图片文件部署在nginx服务器上，目的是减轻tomcat应用服务性能压力。
Nginx是否做了请求访问软负载均衡等等。
2、测试环境硬件资源
列出对应的表格，按照真实实际的情况设计填写；举例表格：
| 服务器类型 |
配制要求 |
服务器名 |
IP |
用途 |
备注 |
|
| CPU |
内存 |
|||||
3、测试目标
如果是并发测试，这需要大致估算用户量；举例：
根据《XX项目需求说明书》得知总用户数1000，因为系统没有真实上线使用，根据2/8原则进行推算，80%的时间里都是20%用户在操作，（总用户数*20%）为在线用户数（即200人），在线用户数的20%定为并发用户数（即40）。
得出结论：在线用户：12000人，并发量为：600~2400。（注：此2/8原则只是我依照着之前公司的数据得出，不一定具备普遍性，故推算数据时，需要开发、运维等协助）
| 基线 |
用户量(人) |
（估算）在线用户数 |
（估算）并发用户数 |
| 系统设计用户量 |
1000 |
200 |
40 |
| 系统上线用户量 |
…… |
||
| 未来三年用户量 |
…… |
4、测试场景
列出系统需要测试的业务场景，作为性能测试脚本录制依据；业务场景举例：
| 主要业务操作 |
并发量 |
是否常用 |
业务重要性 |
| 系统登录 |
500 |
是 |
中 |
| 参加课程 |
1000 |
是 |
高 |
| 点击播放课程 |
500 |
是 |
中 |
| 课程留言查询 |
300 |
是 |
低 |
| …… |
5、响应时间要求（用户最直接感受标准）
业务操作尽可能详细描写，系统响应时间需要项目负责人与客户沟通确认；以下标准可以参考
没有明确响应时间指标，则按3-5-8原则进行填写
普通业务操作响应时间：5秒内
万级数据量查询业务响应时间：8秒内
百万级数据量业务查询响应时间：10秒内
千万级别数据量业务查询响应时间：20秒内
最为正确的统计做法是用百分比分布统计。
6、网络带宽及硬件（我们用的阿里云可以省略）
网络需要注意：描述性能测试环境各应用服务器之间的局域网网络带宽多少？互联网出口的网络带宽多少？测试客户端所在的网段带宽多少？
7、通过准则
1) 通过准则由产品、开发、测试一起制定。
2) 针对不同测试目的确定测试通过准则。
举例：服务器可靠性，在保持高并发情况下长时间提供服务（XX并发XX时间不宕机），性能曲线是否下降。
3) 明确本次测试关注点；举例：
| 类别 |
判断准则 |
不通过 |
通过 |
备注 |
| 服务端性能 |
举例：链接访问超时率 |
大于5% |
小于5% |
1）计算公式： |
| 举例：高并发情况下，事务失败率(必填) |
大于5% |
小于5% |
1）计算公式： |
。。。。。。。。