上一章节中我们对性能的需求进行了分析，知道了测试对象，了解了测试需求，那么下面就需要制定一份详细的计划，来规划和指导性能测试工作的进行。为了使你对性能测试计划更清晰明白，这里以测试计划的格式来描述。

　　一、简介

　　简介部分就不用过多描述了，无非项目的背景，进行此次性能测试的原因，以及性能测试覆盖的范围等等，几乎所有项目文档都在开端对项目进行简单的阐述。

　　二、性能测试需求

　　寻找的被测试对象和压力点

　　要测试的对象不是凭空想象出来，而是经过分析与系统数据收集得到。下取几个典型的压力点

　　登录：对于一般的系统来说，登录是用户操作系统的前提，如果用户根本就登录不了，那么其它功能将毫无用处。例如网游戏，开新服的时候，玩家挤破了脑袋只为登录。

　　查询：查询一般比较消耗系统和数据库资源。搜索引擎的查询功能就是典型，如果你在输入框内输入内容，很久就得不到结果。我想被称为“互联网入口”的搜索引擎就不会存在。

　　交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话。我宁愿去超市买东西了。当然，除了交易速度外，对交易的成功率要求也是非常高的。不然，造成的损失也是不可估量的。

　　被测的系统应该是最重要的最基本的功能，也是用户使用最频繁的功能。

　　一般的性能要求包括：

　　系统容量：系统最大容纳多少个用户注册。

　　访问数：同时访问系统的用户数。

　　并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。

　　系统的最大用户数与最佳用户数：系统在承受的最大并发用户数量，系统在最佳状态下承受的并发用户数据。

　　响应时间：用户提交一个操作到得到响应的时间间隔。

　　吞吐率：系统每秒钟处理的TPS

　　性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。

　　在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算：（真实用户数×每个真实用户请求数）/（总请求响应时间+真实用户总思考时间）=（虚拟用户数×每用户请求个数）/（总请求响应时间+虚拟用户总思考时间）=吞吐量。

　　三、测试环境

　　这里的测试环境主要指的软件硬件环境和网络环境。

　　笔者认为性能测试最好在一个独立的环境内进行，这样不会受到外界的干扰，能够保证测试的数据是独立有效的。如果现你对某个已经上线的网站进行压力测试，那么你得到的数据不是独立的，因为你在做压力测试的时候，其它散户也在访问系统。

　　软件环境：

　　这里的软件环境主要指项目运行的环境，比如采用什么样的操作系统、中间件、和数据库。

　　硬件环境：

　　这里的硬件环境除了主要包括主机内部部件，cpu、内存、磁盘以及主板、网卡等，传输介质和路由器也应该考虑在内，

　　网络环境：

　　网络环境除了考虑测试机与被系统服务器在一个局域网中进行，还应该保证这个网络的独立性。如果在在性能测试的过程中，其它机子也在消耗着路由器资源。那么路由器也会影响到数据库的传输速度。