性能测试报告(模板)

1、xxxxxxxxxx性能测试报告MERCURY美科利2013年4月18日1前言11第一章XXXXXXXX 核心业务系统性能测试概述 11.1被测系统定义11.1.1功能简介11.1.2性能测试指标 21.2系统结构及流程21.2.1系统总体结构21.2.2功能模块描述 21.2.3业务流程31.2.4系统的关键点描述（KP） 41.3性能测试环境41.3.1硬件及网络环境 错误！未定义书签。1.3.2系统装配描述 错误！未定义书签。1.3.3系统启动和管理 错误！未定义书签。2第二章性能测试52.1压力测试52.1.1压力测试概述52.1.2测试目的52.1.3测试方法及测试用例 62.1.4

2、测试指标及期望 72.1.5测试数据准备 92.1.6运行状况记录93第三章 测试计划及方案 92.2测试步骤 错误！未定义书签。2.2.1被测系统调研 错误！未定义书签。2.2.2测试环境的部署 错误！未定义书签。2.2.3脚本的录制和调试 错误！未定义书签。2.2.4准备测试场景 错误！未定义书签。2.2.5准备测试数据 错误！未定义书签。2.2.6执行性能测试 错误！未定义书签。2.2.7生成测试报告 错误！未定义书签。2.3测试时间进度及人员安排 错误！未定义书签。2.3.1人员安排 错误！未定义书签。3第四章测试报告19美科利公司解决方案第1页共21页MERCURY 美辑利丄 、F亠

3、一1刖言目前，XXXX的XXXXXXXX 核心业务系统（以下简称新业务系统）已先后在 XXXX、成功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续，XXX等34家分公司的XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信息大量增长的态势。随着新业务系统在生产状态下日趋稳定、 成熟，系统的性能问题也逐步成为了我们 关注的焦点：XXXX大数据量的“冲击”，在XXXX信息进入时，系统能稳定在什么样 的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。本性能测试规划书即是基于上述考虑，参考科学的性能测试方法而撰写的，用 以

4、指导即将进行的XXXXXXXX核心业务系统的性能测试。1第一章XXXX系统性能测试概述1.1被测系统定义XXXX业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针 对XXXXXXXX 核心业务系统进行的），该业务系统的主要功能包括：XXXXX在本次测试中，将针对上述的功能进行压力测试， 检查并评估在模拟环境中， 系统 对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，1.1.1功能简介XXXXXX主要功能如下：XXXXXXXX1.1.2性能测试指标本次测试是针对XXXXXXXX 核心业务系统的性能特征和系统的

5、性能调优而进行 的，主要需要获得如下的测试指标。1系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户 端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时 间内，应用系统针对不同的负载压力，所能完成的交易数量。3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应 时间中，系统能够支持的最多的客户端的数量。1.2系统结构及流程XXXX业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样 的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性

6、能测试的硬件平台跟 实际生产环境略有不同。1.2.1系统总体结构描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。1.2.2功能模块本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在XXX业务系统中，各种交易及其包含的功能模块关系如下：1 . XXX2. xxxx3. xxxx本次压力测试主要设计的功能模块以及所属的路径如下表名称所属交易路径1.2.3业务流程本次性能测试中，选择的各类交易的业务流程如下:1 . XXXXXX2. xxxxxxx3. xxxx

7、xx :4. xxx :5. xxxxx6. xxxx查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事物处理，交易流程图略。1.2.4关键点描述（KP）本次性能测试的关键点，就是查看xxxx业务系统在并发压力下的表现，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找 出各类交易的性能瓶颈。1.3性能测试环境本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都 是通过浏览器访问应用系统。其中具体的硬件和网络环境如下

8、：服务器设备：IBM 570（DBserver）， IBM 690（APserver）操作系统：AIX网络环境：LAN （ 10M）数据库：Oracle客户端：PC （ Windows ）网络拓扑和结构图如下：2第二章性能测试从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测 试等。在不同应用系统的性能测试中， 需要根据应用系统的特点和测试目的的不同来选 择具体的测试方案，本次XXXXXXXX核心业务系统的性能测试主要是采用通常的压力 测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。在本次性能测试中，也将使用美科利的新产品性能测试诊断工具(D

9、iagnostic)对测试应用的各层进行监控，判断 J2EE各层次的各类方法和类的调用使用时间和效率，并帮 助开发人员分析J2EE应用的各类交易的性能瓶颈点。2.1压力测试在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。2.1.1压力测试概述本次压力测试是指针对现行的 XXX核心业务系统的联机交易处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对XXXXX，检查在日间交易高峰时期，并发用户数较多的时候的处理能力等等。2.1.2测试目的压力测试的目的就是检验系统的最大吞吐量，检验现行的XXXX业务系统

10、在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。本次针对XXXX核心业务系统所进行的压力测试的测试目的为：给出XXXX系统当前的性能状况定位新业务系统性能瓶颈或潜在性能瓶颈总结一套合理的、 可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。2.1.3测试方法及测试用例使用美科利公司（Mercury）的性能测试软件LoadRunner,对现行的xxxx业务系统 进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和 返回给客户端的运行结果。

11、使用的测试用例包括： 联机处理交易和查询交易， 其中联机交易测试试用的交易包 括：xxxx 查询类交易包括： xxxx测试用例列表包括:交易种类案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%本次测试将依照如下场景进行测试:、用户数 功能模块、业务操作交易配比（%）2004007001000000002410172451021365271327476751121375351021375271429517251019344811224578112142856981406122441595112238556

12、13264564204080141201针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：*每隔2秒增加1个用户连接，最多增加到 200个用户，查看并记录运行情况每隔2秒增加2个用户连接，最多增加到 200个用户，查看并记录运行情况 一次性连接10个用户，查看记录运行情况 一次性连接100个用户，查看记录运行情况2.1.4测试指标及期望在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，

13、贝V测试已经达到目的，即可终止压力测试。2141应用软件级别的测试指标：1）联机交易类的执行情况交易的平均响应时间（期望值：<15s）交易的最大响应时间（期望值：<30s）平均每秒处理交易数量（分别记录单位时间内成功、失败和停止的交易数量）交易成功率 （期望值：>95%）不同并发用户数的状况下的上述记录值2）测试结果分析情况单笔记录的处理时间（期望值：<15s）单位时间内的处理交易笔数（期望值：>10个）某个时间段内的交易处理数量单笔能处理的最大数据量在每个交易处理中最大（最耗时）的模块在不同数量的测试数据基础上的上述记录值2.1.4.2网络级别的测试指标：吞吐量

14、：单位时间内网络传输数据量冲突率：在以太网上监测到的每秒冲突数2.1.4.3操作系统级别的测试指标：进程/线程交换率：进程和线程之间每秒交换次数CPU利用率：即CPU占用率（）系统CPU利用率：系统的CPU占用率（）用户CPU利用率：用户模式下的 CPU占用率（）磁盘交换率：磁盘交换速率中断速率：CPU每秒处理的中断数读入内存页速率：物理内存中每秒读入内存页的数目写出内存页速率：每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目内存页交换速率：每秒写入内存页和从物理内存中读出页的个数进程入交换率：交换区输入的进程数目进程出交换率：交换区输出的进程数目2.1.4.4数据库级

15、别的测试指标：数据库的并发连接数：客户端的最大连接数数据库锁资源的使用数量2.1.5测试数据准备2.1.5.1案例数据：满负荷压力根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在 90%左右的状况下，测试 XXX核心业务系统的处理能力。数据准备工作包括：1 . XXXXX2.1.6运行状况记录记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。主要包括：硬件环境资源服务器操作系统参数网络相关参数数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录3第三章测试过程及结果描述XXXX务系统的性能测试

16、共计执行了2次，两次执行的脚本流程作了调整，其他的环境和数据都一样。在测试数据准备完备以后，第一次测试中，操作流程为每次交易都执 行用户登录操作，第二次测试中，操作流程为先进行用户登录，然后每次交易都不再执行用户登录。3.1测试描述两次测试都是在12月22日凌晨进行的。第一次测试执行了 30分钟左右，执行脚本都是采用每次交易都执行登录操作，测 试过程中，交易的执行速度随着测试的进行，越来越慢，交易的响应时间越来越长，交易出错（超时）情况也越来越严重，交易在执行到30分钟左右，用户登录交易开始大量失败（超时）并导致后续的交易都无法完成，于是终止本次测试。第二次测试执行了 50分钟左右，在第一次测

17、试的基础上，调整交易流程，让每次 交易都只登录一次，然后顺序执行交易逻辑。测试开始初期，交易的响应时间随着交易 并发量的增加而快速增加，在测试执行了10分钟左右，所有的用户登录操作都基本完成，此后交易响应时间开始减少，并比较平稳的执行，绝大部分交易执行比较平稳成功 率也很高，除了两个交易：xxx（Audit_Transaction）和 xxx（ClaimRegister_Transaction），这 两个交易的执行速度特别慢，交易相应时间一直都维持在190秒左右和160秒左右，这两个交易超时现象严重，交易成功率很低，很多交易都因为超时而失败。3.2测试场景测试中，使用逐步加压的模式，采用：每隔

18、 2秒启动1个并发用户（Vuser）的方 式，即：每隔1秒，启动1个Vuser，在7分钟左右启动所有的 Vuser（200 个），执行 登录，并根据设置的时间间隔发起交易。这次测试都部署在如下的场景中。运行的脚本部署在 3台PC机，主要目的就是检查在较大压力的情况下，xxxxx心业务系统的性能表现。选择了 2台PC,每台PC机部署了 70个左右并发用户，选择1台PC，部署60个左右的并发用户，并运行 LoadRunner的控制器（Con troller）3.3测试结果两次测试AP服务器主机上的 CPU利用率如下:美科利公司解决方案第10页共21页MERCURY 美辑利CPU Total APP

19、4厂 User% 厂 Sys% Wait%zb- 374 - 3003- 3002- 3001- 390- 39D. 305 - 3HU4 - 303 - 311- 32U- 3100806040200美科利公司解决方案第10页共21页MERCURY 美辑利Time of Day可以看出在两次测试执行中第一次(1:52 -2:20)测试过程中CPU的利用率都几乎达到了 100%，第二次测试中(2:45- 4:00) CPU的利用率也达到了 95%以上。两次测试在数据库(Oracle)服务器上主机上的 CPU利用率如下：CPU Total REQDB1厂 User% 厂 Sys% Wait%3D

20、. 300- 32I-340- 314-3H0. 3OI. 391- 392 - 393 - 3oeo- 3Time of Day可以看出两次测试执行中第一次(1:52 -2:20)测试过程中CPU的利用率很低，第二次测试中(2:45-4:00) CPU的利用率较高也达到了 75%以上，但两次测试的 CPU的IO等待时间却都比较高，IO和CPU利用率对照表如下：美科利公司解决方案第10页共21页MERCURY 美辑利REQDB1O OSLeLX ksb oooTime of DayCPU% IO/secO640O OOO O5O OOO OOO OO O di222034- O美科利公司解决方

21、案第10页共21页MERCURY 美辑利可以看出两次测试执行中第一次 (1:52 -2:20)测试过程中CPU的10等待率较低, 因为大多数的交易都是用户登录，都压在 AP服务器上了，第二次测试中(2:45- 4:00) CPU的10等待率较高，都达到了 80%以上。两次测试的网络压力并不大，网络流量如下：oo53oo30oo52o o 202H-3 o oo5匚 Total-Writei Total-Read2- 32U- 3lz-303 - 3or. 3OD. 305. 3001- 37- 3美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERC

22、URY 美辑利AP服务器监控的网络流量005 - 3ow393 - 392 - 391. 3o-3nD. 315- 314-340- 3of-32I-300- 3005- 336 5 4 3 2 1 0匸 Total-Write-Total-Read美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利DB服务器上监控的网络流量从图中可以看出，在 10M的局域网中，网络流量并不大美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利3.3.1第一次测试第一次测试使用了 200个并

23、发用户，并发用户的启动信息如下:RunningElapsed scenario lime miTi:ssnwqLunN各类交易的交易相应时间（秒）ColorScale交易名称最小平均最大H1AutoUW_Tra nsactio n0.023.73387.8711Con firm_Tra nsactio n210.203210.203210.20381CTDetail_Tra nsacti on105.878151.032199.477H1EdorNosca nApp In put_Tr an sacti on60.704153.425259.2341Gen eralQuery_Tra nsac

24、t0.06713.62339.094ionB1In dividualQuery_Tra ns actio n0.78128.04264.9841Issue_Tra nsact ion5.14530.660.22B1Logi n_Tran sact ion4.265115.433246.736口1Ma nualUW_Tra nsacti on77.09477.09477.094n1NBQuery Tra nsact ion0.33422.34849.6251Payln_Tran sact ion1.50359.944112.639O1PayOut_Tra nsact ion5.25629.178

25、60.2791PayOutQuery_Tra nsacti0.0781.2916.872on1PEdorTypeAC_Tra nsacti111.253160.054213.544on口1PosNoSca nApp Tra nsact9.254158.276271.381ion1POSQuery_Tra nsacti on29.602122.815212.931PrtNoI nput_Tra nsactio n1.722146.879263.0941Relogin_Tra nsactio n30.1670.939105.24-1Report In put_Tra nsacti on1.1551

26、01.387184.783'-1Review_Tra nsactio n5.091112.682387.0871Risk In put_Tra nsact ion2.821113.049211.427O1vuser_e nd_Tra nsactio n0.00.00.01vuser_i ni t_Tra nsactio n0.00.1582.41712.084112.373267.65910.2786.31215.39413.7513.5625.925H10.226.24315.939H18.531109.639210.746H|11.2818.55315.47410.09319.46

27、959.271各类交易的平均响应时间图:Number of vussrsTnnsnctionTune 山*討曰 Lend6Gooo2086o o o o26242220*4D(Ep clouwm) -E-H swusdw国tt.美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。美科利公司解决方案第10页共21页MERCURY 美辑利测试中，每秒的点击率如下:pudues出 s；一hHits per Secoiwlri iI I：| ,!； | ! “ ！： !|丄

28、Id 卩 i i i i I *"01 ：0002：ODU3：0D04:0005:0006:0007:00 DS：O0 09:0010:00T1：0012:00Elaipsed scanario lime mnn:ss美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利测试中每秒页面的下载速度如下:Pages Downloqded n«i Second050 5 050SO S050877 6 6 55443322pm 8 -lCDdOTIDB 再 d美科利公司解决方案第10页共21页MERCURY 美辑利美科利公

29、司解决方案第10页共21页MERCURY 美辑利Ii7 、*,01 ：00(J2.0DQ3：0004:0005:0006:0007：OD06:0009:0010:0011 ：0012:0()Elapsed scanario lime mm:ss根据上面两组数据，即： 每秒的点击率和每秒下载页面的速度，可以看出，在测试执行开始4分钟以后，核心业务系统用户登录的并发数量不断在增加，但是用户登录后的数据下载量却变化不大，这样将最终导致大量的用户登录因为交易处理超时而失败。3.3.2第二次测试第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执行一次用户登录，然后执行对应的交易处理

30、，交易过程中不再执行用户登录操作。运行的并发用户数目如下图：口2qLLmNRnnnihfj VipersElapsed scenario lim hh:mmQOOOOOOOQDOOOOD4 3 2 4 0 9 8 7 6 .4 3 2 1美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利在用户登录过程中，交易的平均响应时间如下图:2B0 -200iao16014CM120-1100-602002040500100120i140160100200Number of VusersT hwsactjnn Response Time Und

31、ei l "勒I美科利公司解决方案第10页共21页MERCURY 美辑利美科利公司解决方案第10页共21页MERCURY 美辑利从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一直稳定在这个数值左右。在第二次测试中，各类交易的平均响应时间如下表:（单位：秒）ColorScale交易最小平均最大1Audit_Transaction19.481162.12207.6271AutoUW_Transaction0.013.00149.4941ClaimRegister_Transaction75

32、.599143.641163.9781Confirm_Transaction1.13151.42794.5851CTDetail_Transaction37.25765.967148.3341EdorNoscanApplnput_Transa ction16.50479.919169.2391EndCase_Transaction11.8846.54685.6581GeneralQuery_Transaction0.15211.01735.3211IndividualQuery_Transaction0.87514.45540.578ri1Issue_Transaction4.26914.32

33、630.4961Login_Transaction8.36390.998151.3441ManualUW_Transaction3.26281.311171.2841NBQuery_Transaction0.42212.08236.2971PayIn_Transaction0.55932.01274.4621PayOut_Transaction2.20411.12132.3971PayOutQuery_Transaction0.0791.2555.328i1PEdorTypeAC_Transaction37.38466.606137.3821PosNoScanApp_Transaction15.89285.482164.1561POSQuery_Transaction10.19357.825132.6771PrtNoInput_Transaction5.16277.07164.4581Relogin_Tran