压力测试报告.docx

压力测试报告.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。