压力测试报告.docx

《压力测试报告.docx》由会员分享，可在线阅读，更多相关《压力测试报告.docx（13页珍藏版）》请在三一办公上搜索。

1、目录1.引言21.1 编写目的21.2 系统概述21.2.1 项目名称21.2.2 总体目标21.2.3 技术目标22.测试环境32.1 软硬件环境32.1.1网络拓扑结构42.4 测试环境约束43.测试范围及测试要求43.1测试43.1.1测试内容43.1.2测试通过标准54.测试工具55.测试结果56.1测试时间及人员66.2测试结果分析66.结论131. 引言1.1 编写目的本文档是对(项目名称)性能测试所做的说明，为充分利用已有的软硬件资源，配合对各系统应用模块的运行测试方案,查缺补漏完善系统的各项具体功能,保证项目的顺利进行，本测试报告有助于实现以下目标： 明确本次性能测试的测试资源

2、； 明确本次性能测试的测试内容； 明确本次性能测试的测试方法； 明确本次性能测试的系统性能。1.2 系统概述1.2.1 项目名称项目名称: 小象工程项目简称: 小象工程项目单位: 扑像文化传播有限公司1.2.2 总体目标网站支持100个以上并发客户端访问1.2.3 技术目标1.2.3.1技术目标使用测试工具实现虚拟用户并发的压力测试，要求系统满足用户并发量在100以上，并能正常工作。2. 测试环境2.1 软硬件环境 硬件环境应用服务器数据库服务器客户端硬件配置CPU：Intel(R) Pentium(R) DCPU 3.40GHz Memory： 2GHD: 360GSATACPU：Intel

3、(R) Pentium(R) DCPU 3.40GHz Memory： 2GHD: 360GSATACPU：Intel(R) Core(TM)CPU 2.20GHz Memory： 2GHD: 360GSATA软件配置OS：Windows 2003JDK 1.5.0_06Tomcat 6OS：Windows 2003MySQL 5.0.17 LinuxWindow xpProfessional （ SP3 ）2.1.1网络拓扑结构2.4 测试环境约束 本次测试结果依据目前被测系统的软/硬件环境。 本次测试结果依据目前被测系统的程序版本。 本次测试结果依据目前被测系统的网络环境。 本次测试结果依

4、据目前被测系统的测试数据量。3. 测试范围及测试要求3.1测试3.1.1测试内容根据需求，对登录操作进行并发的压力测试，对主要业务模块中的主要业务（下点单、制作相册）进行压力和负载测试。3.1.2测试通过标准 系统在并发用户100时，系统表现稳定4. 测试工具测试工具：Loadrunner8.0（美国Mercury公司）使用Web（http/html）协议。主要思想是使用虚拟用户（Virtual users）来模拟实际用户对系统施加压力。模拟图如下：5. 测试结果6.1测试时间及人员时间：2011.08.09人员：玲地点：深圳扑象文化传播有限公司6.2测试结果分析LoadRunner进行100

5、用户场景模拟测试结果收集后，显示的该结果的一个摘要信息，如图5- 1所示。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。图5- 1性能测试结果摘要图场景执行情况该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 2所示。从该图我们知道，本次测试从16:17:08开始，到16:54:38结束，共历时37分30秒。图5- 2场景执行情况描述图Statistics Summary（统计

6、信息摘要）该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 3所示。从该图我们得知，本次测试运行的最大并发数为200，总吞吐量为960,974,180字节，平均每秒的吞吐量为426910字节，总的请求数为117,105，平均每秒的请求为52.024。图5- 3统计信息摘要图Transaction Summary（事务摘要）该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图5- 4所示。从该图我们得到每个Action的平均响应时间与业务成功率。图5- 4事务摘要图HTTP Responses Summary（HTTP

7、响应摘要）该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5- 5所示。从图中可以看到，在本次测试过程中LoadRunner共模拟发出了117105次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是117105次，说明在本次过程中，经过发出的请求全部分都能正确响应了（“HTTP 200”表示请求被正确响应）。图5- 5 HTTP响应摘要并发数分析“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与

8、事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。图5- 6显示了在系统业务性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。ColorScaleMeasurementGraph Min.Graph Ave.Graph Max.Graph MedianGraph SD1Run0.0105.120012978.21

9、9图5- 6运行的并发数图我们本次测试Running Vusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，系统测试服务器能够应付200个并发用户的业务操作。响应时间“Average Transaction Response Time（平均事务响应时间图）”（图5- 7），这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。ColorScaleMeasurementMin.Ave.Max.SD1login_Action_Transaction0.45247.115109.3830.2571select_allAction_Transact

10、ion8.71926.648144.70411.2311select_oneAction_Transaction24.48493.983329.97439.9331vuser_end_Transaction0.00.0111.2970.0971vuser_init_Transaction0.0010.050.4180.095图5- 7平均事务响应时间图从图形下部我们可以看到，登录部分对应的Action是“login_Action”，批量查询对应的Action是“select_allAction”，选择信息查询对应的Action是“select_oneAction”，他们的“Average Ti

11、me（平均响应时间为）”分别是47.115秒与26.648秒与93.983秒，从这三个数值来看，都过大，不符合要求。实际事物时间应为登录：47.115/5 5 = 4.423 （减5登录时包含了一个用户信息查询）批量查询：26.648 /5 = 5.3296选择信息查询：93.983 /5/7 = 2.685 (除7做了7次点击选择信息)注：除5 所有的事物都被重复执行5次看完了“Average Time”，我们再看“90 Percent Time”，表示90%的事务登录：95.711/5 5 = 14.142 （减5登录时包含了一个用户信息查询）批量查询：39.125/5 = 7.825选择

12、信息查询：146.797 /5/7 = 4.194 (除7做了7次点击选择信息)注：除5 所有的事物都被重复执行5次从图5- 7可以看出，所有Action平均事务响应时间的趋势有较大的波动，所以使用“90 Percent Time”。根据上面的计算，本次测试结果记录如表5- 1所示。测试项实际值是否通过登录业务响应时间14.142秒Y批量查询响应时间7.825秒Y选择信息响应时间4.194秒Y登录业务成功率100%考勤业务成功率100%登录查询总数1000批量查询总数1000选择信息总数1000CPU使用率维持100%内存使用率20%表5- 1测试结果对照表一每秒点击数图5- 8显示的是“Hi

13、ts per Second”与“Average Throughput (bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。图5- 8每秒点击数与每秒吞吐量复合图业务成功率。在“Transaction Summary”中我们可以很明确的看到每个事务的执行状态，如图5- 9所示。ColorScaleMeasurement1Pass图5- 9事务状态统计图从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就

14、表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表5- 2所示。测试项实际值是否通过登录业务响应时间14.142秒Y批量查询响应时间7.825秒Y选择信息响应时间4.194秒Y登录业务成功率100%Y考勤业务成功率100%Y登录查询总数1000Y批量查询总数1000Y选择信息总数1000YCPU使用率内存使用率表5- 2测试结果对照表二系统资源系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU

15、使用率与内存使用率，以及处理器队列长度，具体的数据如图5- 10所示。ColorScaleMeasurementMin.Ave.Max.SD1% Processor Time (Processor _Total):192.168.0.1084.16763.81391.4067.0810.1Available MBytes (Memory):192.168.0.108486500.59657013.53610Processor Queue Length (System):192.168.0.1080.01.962313.204图5- 10测试服务器系统资源监控结果图从图中可以看出，CPU使用率、

16、内存使用率、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：63.813 %、500.596、1.962，根据本次性能测试要求的：CPU使用率不超过75%,内存使用为130M。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是1.962接近2, 而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。获得上述数据后，最新的测试结果记录表如表5- 3所示。测试项实际值是否通过登录业务响应时间14.142秒Y批量查询响应时间7.825秒Y选择信息

17、响应时间4.194秒Y登录业务成功率100%Y考勤业务成功率100%Y登录查询总数1000Y批量查询总数1000Y选择信息总数1000YCPU使用率63.813 %内存使用率130M表5- 3测试结果对照表三从上表数据来看，本次测试总体上已经达到了预期的性能指标，但从其他的数据，比如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。通过tomcat 检测工具probe ,内存使用130M。6. 结论测试中，系统在大量用户使用和长时间反复运行中，系统未出现不良反应，包括cpu、内存占用过高、内存泄露等，系统反应良好，在大吞吐量情况系统响应时间令人满意，系统稳定性比较可靠。另：测试250到300用户的情况下系统表现情况。结果发现系统在250 以上出现连接超时等现象，故在本次测试环境下并发用户峰值在250。