（情绪管理）压力测试方案模板XXXXXX有限X公司渠道管理系统（CMS）压力测试文档2007年12月修正记录目录1. 测试原理42. 测试环境52.1 测试环境网络拓扑图：52.2 硬件列表：52.2.1. WEB服务器：52.2.2. 数据库服务器：52.2.3. 测试机3台：62.2.4. 其他：62.3软件列表：63. 测试工具—The Grinder3介绍64. 定义测试脚本95. 定义采样方法106. 执行测试107. 实际性能测试及结果118. 性能分析、调整及结果129. 结论1210．佣金计算121.测试原理压力（负载）测试技术于各种极限情况下对产品进行测试(如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。
例如，使用压力测试工具对web服务器进行压力测试。
本项测试能够帮助找到壹些大型的问题，如死机、崩溃、内存泄漏等，因为有些存于内存泄漏问题的程序，于运行壹俩次时可能不会出现问题，可是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩溃。
基于J2EE平台的应用程序壹般分为俩个基本类别：交互式的－即终端用户和应用程序同步交互；批处理或后端应用程序－即不需要直接和终端用户交互。
对于交互式应用程序，性能壹般是通过大小和规划问题的容量来定义，评测标准能够为同时发生的用户数量和响应时间；对于后者，性能统计量是吞吐量，评测标准之壹是每秒的事务处理，而事务处理于具体的场合定义可能有所不同。
比如对于Servlet，事务处理可能为壹个请求。
而对JMS，吞吐量可能就是消息。
2.测试环境2.1测试环境网络拓扑图：图表12.2硬件列表：2.2.1.WEB服务器：型号（SUNFire280R）：处理器类型：UltraSPARCIII（900HZ），内存：1G，OS:Solaris82.2.2.数据库服务器：型号：处理器类型：P4，内存：1G，磁盘：40G，OS：Win2000server2.2.3.测试机3台：型号：处理器类型：P4，内存：1G，磁盘：１×80G，OS：WinXPProfessional（分别命名为测试机器壹、测试机器二、测试机器三）。
2.2.4.其他：其他网络设备等。
2.3软件列表：①中心应用程序服务器：T omcat5.5.25②数据库：DB2(9)forWindows③Java虚拟机：JRE1.6.2④测试工具:TheGrinder3⑤浏览器：FireFox2.0，IE6等3.测试工具—TheGrinder3介绍TheGrinder是壹个开源的负载生成/数据收集工具，它本身是Java应用程序，需要于安装JVM（版本不能低于1.3）的平台上运行，能够于下载。
下于后的文件为grinder-3.0-beta33.zip，解压这个包到磁盘上。
解压后的目录结构为：图表2其中“lib”目录下是你运行测试工具是所需要的JAR包。
因此于系统的环境变量中添加lib 目录下的所有JAR包，如图所示：图表3注：所有的测试机器均要安装和配置TheGrinder。
Grinder能提供响应时间、吞吐量等性能测度。
它有三种进程：工人进程，是由Grinder代理进程创建的，负责执行单独的测试；代理进程，负责管理该机器上的工人进程；控制台，协同其他进程工作且收集统计数据。
它有四个独特的方面：负载生成、请求定义、统计记录和控制台。
负载生成的原理是这样的：为了运行壹组给定的测试，需要于每个测试机上启动壹个代理进程。
该代理进程负责创建许多工人进程。
每个工人进程加载壹个确定需要运行的测试类型的插件组件，然后启动多个工人线程。
负载的数目＝（代理进程数）×（工人进程数）×（工人线程数）。
控制台的启动命令：javanet.grinder.Console代理进程启动命令：javanet.grinder.Grinder(默认的启动脚本是当前目录下的grinder.properties文件) grinder.properties文件中的grinder.processes和grinder.threads属性分别设置工人进程数和工人线程数。
TheGrinder带有壹个称为TCPProxy的工具，通过运行命令：javanet.grinder.TCPProxy–console–http>grinder.py仍要修改浏览器的连接设置如图１所示：图表4此时能自动的获取对应和用户使用浏览器做出的HTTP请求的测试脚本项，且生成响应的测试脚本条目。
于Grinder中将事务定义为Grinder测试脚本中壹个单独的请求。
TheGrinder控制台是壹个有用的TheGrinder工作方式和方案工具的接口，能够聚集来自工人进程的方案同时收集统计数据，且以定期的采样间隔更新其显示。
如图２所示，选择标签Graphs（图形）能够图形显示事务处理每秒；选择Result（结果）标签能够以表格形式查见结果。
图54.定义测试脚本使用TheGrinder自带的TCPProxy工具，模拟单个用户登录系统，生成性能测试脚本中用到的请求序列及要手工输入的文件。
如录制的脚本文件主要有主页，登录页，登录后系统页面，机构查询页面等请求页面。
录制且修改三个测试脚本分别的三台测试机器上运行。
于测试机器壹上运行测试脚本壹，它主要是登录后进行机构的查询，包过模糊查询和条件查询。
于测试机器二上运行测试脚本二，它主要是登录后进行DM人员的增加。
于测试机器三上运行测试脚本三，它主要是登录后进行查询银保人员的基本信息，包过模糊查询和条件查询。
设置测试机器壹的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，15和20；设置测试机器二的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，15和20；设置测试机器三的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，20和20；5.定义采样方法采样方法是指如何精确地收集性能数据，以及哪种度量将对最终分析的结果有贡献。
于TheGrinder中有俩种采样方法：固定的周期数(周期方法)和固定的时间(快照方法),所选择的方法依赖于性能测试的目标。
周期是指壹个模拟用户对壹个测试脚本的完整执行。
6.执行测试javanet.grinder.Console//启动TheGrinder控制台。
javanet.grinder.Grindergrinder.properties//执行测试脚本，grinder.properties是启动测试时默认的配置文件，也能够。
其它壹些参数的设置请参阅TheGrinder的官方文档。
能够是设置三台测试机中的壹台外数据采集机器，即其它俩台测试机器产生的数据均发送给那壹台机器。
这样更有利用数据的采集和整理。
具体做法如下：1．假设测试机器壹为信息采集的主机，IP地址为192.168.0.11。
2．于另外俩台测试机器中，于执行测试脚本的目录中找到grinder.properties文件。
3．打开grinder.properties文件，添加下面俩行：grinder.consoleHost=192.168.0.11grinder.consolePort=6372grinder.script=ybrwcx1.pygrinder.consoleHos的值为测试机器壹的IP。
grinder.consolePort的值为测试机器壹Console代理默认端口号。
grinder.script的值为测试的脚本文件名。
4．保存后再执行测试脚本命令，就能够达到我们想要的结果了。
注意：测试机于执行测试的过程中，可能会出现测试中止的情况，这是由于你于grinder.properties配置文件中grinder.threads设置的过多导致内存不够，能够于grinder.properties中添加“grinder.jvm.arguments=-mx512m”壹行，grinder.jvm.arguments大小据实际情况而定。
7.实际性能测试及结果以下测试数据是服务器和数据库主机于壹台普通PC机上的情况。
于测试过程中300人以下且发用户系统能够承受住，但当用户数目达到500时，CPU和内存的使用量剧增，就会发生应用程序崩溃死机等，图3中我们只给出100个且发用户的测试数据。
图6表1100个且发用户的测试数据表1中能够见出100个且发用户登录系统页面的ART，MART等参数。
能够见出此时系统绝大部分时间仍能正常访问。
8.性能分析、调整及结果影响系统性能的因素有很多：计算机硬件、数据库的访问速度、Java虚拟机(JavaVirtualMachines,JVM),TCP/IP堆栈、Web服务器、网络、操作的复杂度等。
能够从以下几个方面来优化系统性能（没有于该应用程序的代码和体系结构上再做调整）：1.于计算机硬件性能和结构方面所做的调整2.将WEB服务和DBS服务分开3.于Java虚拟机(JVM)参数方面的调整JVM对性能影响最大的就是其堆的大小及其分配情况。
JVM的堆大小决定了JVM花费于收集垃圾上的时间和频度，通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms(指定于启动JVM时为堆所分配的内存大小)=-Xmx(指定Java解释器将用于动态分配对象和数组的最大堆的大小)。
而为了防止内存溢出,建议于生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G之上是不可取的。
因于测试过程中，通过设置Xms和Xmx将参数调节到最佳组合状态，从而提高系统性能。
4.于应用服务器(如Tomcat)的参数方面的调整应用服务器的主要参数有线程数、最大会话闲置时间，因配置了数据库连接池，那么仍有最大数据库连接数、最大连接闲置时间等。
9.结论通过压力测试及相应的性能优化策略的实施，我们最终得到的测试结果为：CMS系统于本测试环境下300左右的用户同时登录和查询机构等操作的平均响应时间为2秒。
系统的成功率平均为99.94％。
10．佣金计算。