压力测试报告.docx
- 文档编号:11683492
- 上传时间:2023-03-30
- 格式:DOCX
- 页数:12
- 大小:501.93KB
压力测试报告.docx
《压力测试报告.docx》由会员分享,可在线阅读,更多相关《压力测试报告.docx(12页珍藏版)》请在冰豆网上搜索。
压力测试报告
压力测试报告
引言
1.1编写目的
本文档是对(项目名称)性能测试所做的讲明,为充分利用已有的软硬件资源,配合对各系统应用模块的运行测试方案,查缺补漏完善系统的各项具体功能,保证项目的顺利进行,本测试报告有助于实现以下目标:
明确此次性能测试的测试资源;
明确此次性能测试的测试内容;
明确此次性能测试的测试方法;
明确此次性能测试的系统性能。
1.2系统概述
1.2.1项目名称
项目名称:
小象工程
项目简称:
小象工程
项目单位:
扑像文化传播有限公司
1.2.2总体目标
1.2.3技术目标
1.2.3.1技术目标
使用测试工具实现虚拟用户并发的压力测试,要求系统满足用户并发量在100以上,并能正常工作。
测试环境
2.1软硬件环境
硬件环境
应用服务器
数据库服务器
客户端
硬件配置
CPU3.40GHz
Memory:
2G
HD:
360G
SATA
CPU3.40GHz
Memory:
2G
HD:
360G
SATA
CPU2.20GHz
Memory:
2G
HD:
360G
SATA
软件配置
OS:
Windows2003
JDK1.5.0_06
Tomcat6
OS:
Windows2003
MySQL5.0.17Linux
Windowxp
Professional(SP3)
2.1.1网络拓扑结构
2.4测试环境约束
此次测试结果依据目前被测系统的软/硬件环境。
此次测试结果依据目前被测系统的程序版本。
此次测试结果依据目前被测系统的网络环境。
此次测试结果依据目前被测系统的测试数据量。
测试范畴及测试要求
3.1测试
3.1.1测试内容
按照需求,对登录操作进行并发的压力测试,对要紧业务模块中的要紧业务(下点单、制作相册)进行压力和负载测试。
3.1.2测试通过标准
系统在并发用户100时,系统表现稳固
测试工具
测试工具:
Loadrunner8.0(美国Mercury公司)
使用Web(http/html)协议。
要紧思想是使用虚拟用户(Virtualusers)来模拟实际用户对系统施加压力。
模拟图如下:
测试结果
6.1测试时刻及人员
时刻:
2011.08.09
人员:
玲
地点:
深圳扑象文化传播有限公司
6.2测试结果分析
LoadRunner进行100用户场景模拟测试结果收集后,显示的该结果的一个摘要信息,如图5-2所示。
概要中列出了场景执行情形、“StatisticsSummary(统计信息摘要)”、“TransactionSummary(事务摘要)”以及“HTTPResponsesSummary(HTTP响应摘要)”等。
以简要的信息列出此次测试结果。
图5-2性能测试结果摘要图
场景执行情形
该部分给出了此次测试场景的名称、结果存放路径及场景的连续时刻,如图5-3所示。
从该图我们明白,此次测试从16:
17:
08开始,到16:
54:
38终止,共历时37分30秒。
图5-3场景执行情形描述图
StatisticsSummary(统计信息摘要)
该部分给出了场景执行终止后并发数、总吞吐量、平均每秒吞吐量、总要求数、平均每秒要求数的统计值,如图5-4所示。
从该图我们得知,此次测试运行的最大并发数为200,总吞吐量为960,974,180字节,平均每秒的吞吐量为426910字节,总的要求数为117,105,平均每秒的要求为52.024。
图5-4统计信息摘要图
TransactionSummary(事务摘要)
该部分给出了场景执行终止后有关Action的平均响应时刻、通过率等情形,如图5-5所示。
从该图我们得到每个Action的平均响应时刻与业务成功率。
图5-5事务摘要图
HTTPResponsesSummary(HTTP响应摘要)
该部分显示在场景执行过程中,每次HTTP要求发出去的状态,是成功依旧失败,都在那个地点体现,如图5-6所示。
从图中能够看到,在此次测试过程中LoadRunner共模拟发出了117105次要求(与“统计信息摘要”中的“TotalHits”一致),其中“HTTP200”的是117105次,讲明在此次过程中,通过发出的要求全部分都能正确响应了(“HTTP200”表示要求被正确响应)。
图5-6HTTP响应摘要
并发数分析
“RunningVusers(运行的并发数)”显示了在场景执行过程中并发数的执行情形。
它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息,将这些图与事务图结合使用能够确定Vuser的数量对事务响应时刻产生的阻碍。
图5-7显示了在系统业务性能测试过程中Vusers运行情形,从图中我们能够看到,Vusers的运行趋势与我们场景执行打算中的设置是一样,表明在场景执行过程中,Vusers是按照我们预期的设置运行的,没有Vuser显现运行错误,如此从另一个侧面讲明我们的参数化设置是正确的,因为使用唯独数进行参数化设置,如果设置不正确,将会导致Vuser运行错误。
Color
Scale
Measurement
GraphMin.
GraphAve.
GraphMax.
GraphMedian
GraphSD
1
Run
0.0
105.1
200
129
78.219
图5-7运行的并发数图
我们此次测试RunningVusers与集合点是一致,讲明整个场景执行过程中,并发数用户的执行正确,系统测试服务器能够应对200个并发用户的业务操作。
响应时刻
“AverageTransactionResponseTime(平均事务响应时刻图)”(图5-10),这张图是平均事务响应时刻与结果摘要中的“TransactionSummary”合成的。
Color
Scale
Measurement
Min.
Ave.
Max.
SD
1
login_Action_Transaction
0.452
47.115
109.38
30.257
1
select_allAction_Transaction
8.719
26.648
144.704
11.231
1
select_oneAction_Transaction
24.484
93.983
329.974
39.933
1
vuser_end_Transaction
0.0
0.011
1.297
0.097
1
vuser_init_Transaction
0.001
0.05
0.418
0.095
图5-10平均事务响应时刻图
从图形下部我们能够看到,登录部分对应的Action是“login_Action”,批量查询对应的Action是“select_allAction”,选择信息查询对应的Action是“select_oneAction”,他们的“AverageTime(平均响应时刻为)”分不是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次
看完了“AverageTime”,我们再看“90PercentTime”,表示90%的事务
登录:
95.711/5–5=14.142(减5登录时包含了一个用户信息查询)
批量查询:
39.125/5=7.825
选择信息查询:
146.797/5/7=4.194(除7做了7次点击选择信息)
注:
除5所有的事物都被重复执行5次
从图5-10能够看出,所有Action平均事务响应时刻的趋势有较大的波动,因此使用“90PercentTime”。
按照上面的运算,此次测试结果记录如表5-1所示。
测试项
实际值
是否通过
登录业务响应时刻
14.142秒
Y
批量查询响应时刻
7.825秒
Y
选择信息响应时刻
4.194秒
Y
登录业务成功率
100%
考勤业务成功率
100%
登录查询总数
1000
批量查询总数
1000
选择信息总数
1000
CPU使用率
坚持100%
内存使用率
<20%
表5-1测试结果对比表一
每秒点击数
图5-11显示的是“HitsperSecond”与“AverageThroughput(bytes/second)”的复合图,从图中能够看出,两种图形的曲线都正常同时差不多一致,讲明服务器能及时的同意客户端的要求,并能够返回结果。
图5-11每秒点击数与每秒吞吐量复合图
业务成功率
。
在“TransactionSummary”中我们能够专门明确的看到每个事务的执行状态,如图5-12所示。
Color
Scale
Measurement
1
Pass
图5-12事务状态统计图
从图中能够看出,所有的Aciton差不多上绿色的,即表示为Passed,同时除了vuser_init与vuser_end两个事务,其他的事务通过数为2163,也就表明在30分钟的时刻里,共完成了2163次登录考勤业务操作。
那么按照这些能够判定此次测试登录业务与考勤业务的成功率是100%,再次更新测试结果记录表如表5-2所示。
测试项
实际值
是否通过
登录业务响应时刻
14.142秒
Y
批量查询响应时刻
7.825秒
Y
选择信息响应时刻
4.194秒
Y
登录业务成功率
100%
Y
考勤业务成功率
100%
Y
登录查询总数
1000
Y
批量查询总数
1000
Y
选择信息总数
1000
Y
CPU使用率
内存使用率
表5-2测试结果对比表二
系统资源
系统资源图显示了在场景执行过程中被监控的机器系统资源使用情形,一样情形下监控机器的CPU、内存、网络、磁盘等各个方面。
此次测试监控的是测试服务器的CPU使用率与内存使用率,以及处理器队列长度,具体的数据如图5-13所示。
Color
Scale
Measurement
Min.
Ave.
Max.
SD
1
%ProcessorTime(Processor_Total):
192.168.0.108
4.167
63.813
91.406
7.081
0.1
AvailableMBytes(Memory):
192.168.0.108
486
500.596
570
13.536
10
ProcessorQueueLength(System):
192.168.0.108
0.0
1.962
31
3.204
图5-13测试服务器系统资源监控结果图
从图中能够看出,CPU使用率、内存使用率、CPU的队列长度三个指标的曲线逗较为平滑,三者的平均值分不为:
63.813%、500.596、1.962,按照此次性能测试要求的:
CPU使用率不超过75%,内存使用为130M。
按照Windwos资源性能指标的讲明,一样情形下,如果“ProcessorQueueLength(处理器队列长度)”一直超过二,则可能表示处理器堵塞,我们那个地点监控出来的数值是1.962接近2,而且总体上保持平稳,那么由此推断,测试服务器的CPU也可能是个瓶颈。
获得上述数据后,最新的测试结果记录表如表5-3所示。
测试项
实际值
是否通过
登录业务响应时刻
14.142秒
Y
批量查询响应时刻
7.825秒
Y
选择信息响应时刻
4.194秒
Y
登录业务成功率
100%
Y
考勤业务成功率
100%
Y
登录查询总数
1000
Y
批量查询总数
1000
Y
选择信息总数
1000
Y
CPU使用率
63.813%
内存使用率
130M
表5-3测试结果对比表三
从上表数据来看,此次测试总体上差不多达到了预期的性能指标,但从其他的数据,例如CPU的队列长度、内存使用率来看,被测服务器的硬件资源需要提升。
通过tomcat检测工具probe,内存使用130M。
结论
测试中,系统在大量用户使用和长时刻反复运行中,系统未显现不良反应,包括cpu、内存占用过高、内存泄露等,系统反应良好,在大吞吐量情形系统响应时刻令人中意,系统稳固性比较可靠。
另:
测试250到300用户的情形下系统表现情形。
结果发觉系统在250以上显现连接超时等现象,故在此次测试环境下并发用户峰值在250。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 压力 测试报告