5--性能测试报告(模板)

1、迦试时代T e 卜，芒 e lh版权所有测试时代（T北京慧灵科技有限公司XXX系统性能测试报告文档编号:编 写:批 准:文档名称: 审 核: 批准日期:北京慧灵科技有限公司http:www.testage cn第2页共16页迦试时代T e 卜，芒 e lh版权所有测试时代（T北京慧灵科技有限公司第3页共16页迦试时代T e 卜，芒 e lh第#页共16页迦试时代T e 卜，芒 e lh1前言32被测系统定义 32.1功能简介32.2性能测试指标43系统结构及流程 43.1系统总体结构 43.2功能模块43.3业务流程53.4关键点描述63.5性能测试环境 64性能测试64.1性能测试概述74.

2、2测试目的74.3测试方法及测试用例 74.4测试指标及期望 84.5测试数据准备 104.6运行状况记录 105测试过程及结果描述 105.1测试描述115.2测试场景115.3测试结果114测试分析和结论 16第#页共16页迦试时代版权所有测试时代（T北京慧灵科技有限公司丄 、F亠一1刖言目前，XXXX的XXXXXXXX 核心业务系统（以下简称新业务系统）已先后在XXXX、成功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续， xxx等34家分公司的XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信 息大量增长的态势。随着新业务系统在生产状态下日趋稳定、成熟，系

3、统的性能问题也逐步成为了我们关注的焦点：XXXX大数据量的“冲击”，在XXXX信息进入时，系统能稳定在什么样的性 能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。本性能测试规划书即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的 XXXXXXXX 核心业务系统的性能测试。2被测系统定义xxxx业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXXXXXXX 核心业务系统进行的），该业务系统的主要功能包括：xxxxx在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对 负载的承受能力，

4、在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的 数据容量中，系统能够容忍的最大用户数，2.1功能简介xxxxxx主要功能如下：xxxxxxxx版权所有测试时代（T北京慧灵科技有限公司2.2性能测试指标本次测试是针对XXXXXXXX 核心业务系统的性能特征和系统的性能调优而进行的， 主要需要获得如下的测试指标。1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交 易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间 内，应用系统针对不同的负载压力，所能完成的

5、交易数量。3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。3系统结构及流程xxxx业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生 产环境略有不同。3.1系统总体结构描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。3.2功能模块本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在xxx业务系统中

6、，各种交易及其包含的功能模块关系如下：1. xxx2. xxxx3. xxxx本次压力测试主要设计的功能模块以及所属的路径如下表名称所属交易路径版权所有测试时代（T北京慧灵科技有限公司3.3业务流程本次性能测试中，选择的各类交易的业务流程如下:1. xxxxxx2. xxxxxxx3. xxxxxx :4. xxx :5. xxxxx6. xxxx查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此在本 次性能测试中只作为一个事物处理，交易流程图略。版权所有测试时代（T北京慧灵科技有限公司3.4关键点描述本次性能测试的关键点，就是查看xxxx业务系统在并发压力下的表现，即：支

7、持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找出各类 交易的性能瓶颈。3.5性能测试环境本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数 据库是真实环境数据库的一个复制（或缩小），本系统采用标准的 CS结构，客户端都是通过浏览器访问应用系统。其中具体的硬件和网络环境如下：服务器设备：IBM 570 （ DBserver）， IBM 690 （ APserver）操作系统：AIX网络环境：LAN （ 10M）数据库：Oracle客户端：PC （ Windows）网络拓扑和结构图如下：4性能测试从广泛意义上讲性能测试包括：压力测试、稳定性测

8、试、负载能力测试和可扩展性测试 等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具 体的测试方案，本次 XXXXXXXX 核心业务系统的性能测试主要是采用通常的压力测试模 式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并 实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。版权所有测试时代（T北京慧灵科技有限公司4.1性能测试概述本次压力测试是指针对现行的XXX核心业务系统的联机交易处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对XXXXX，检查在日间

9、交易高峰时期，并发用户数较多的时候的处理能力等等。4.2测试目的压力测试的目的就是检验系统的最大吞吐量，检验现行的XXXX业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。本次针对XXXX核心业务系统所进行的压力测试的测试目的为：给出XXXX系统当前的性能状况定位新业务系统性能瓶颈或潜在性能瓶颈总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能 测试工作提供基本思路。4.3测试方法及测试用例使用性能测试软件 LoadRunner,对现行的xxxx业务系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调

10、用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。使用的测试用例包括：联机处理交易和查询交易，其中联机交易测试试用的交易包括: XXXX 查询类交易包括：XXXX测试用例列表包括:交易种类案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%版权所有测试时代（T北京慧灵科技有限公司本次测试将依照如下场景进行测试：、用户数 功能模块业务操作交易配比（%）20040070010000255111465620针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进

11、行，查看服 务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：每隔2秒增加1个用户连接，最多增加到 200个用户，查看并记录运行情况每隔2秒增加2个用户连接，最多增加到 200个用户，查看并记录运行情况 一次性连接10个用户，查看记录运行情况 一次性连接100个用户，查看记录运行情况4.4测试指标及期望在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指 标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业 务需求的要求范围，则测试已经达到目的，即可终止压力测试。应用软件级别的测试指标：1）联机交易类的执行情况交易的平均响应时间

12、（期望值： <15s）版权所有测试时代（T北京慧灵科技有限公司交易的最大响应时间（期望值：<30s）平均每秒处理交易数量（分别记录单位时间内成功、失败和停止的交易数量）交易成功率（期望值：>95%）不同并发用户数的状况下的上述记录值2）测试结果分析情况单笔记录的处理时间（期望值：<15s）单位时间内的处理交易笔数（期望值：>10个）某个时间段内的交易处理数量单笔能处理的最大数据量在每个交易处理中最大（最耗时）的模块在不同数量的测试数据基础上的上述记录值网络级别的测试指标：吞吐量：单位时间内网络传输数据量冲突率：在以太网上监测到的每秒冲突数操作系统级别的测试指标：进

13、程/线程交换率：进程和线程之间每秒交换次数CPU利用率：即CPU占用率（）系统CPU利用率：系统的 CPU占用率（）用户CPU利用率：用户模式下的 CPU占用率（）磁盘交换率：磁盘交换速率中断速率：CPU每秒处理的中断数读入内存页速率：物理内存中每秒读入内存页的数目写出内存页速率：每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目内存页交换速率：每秒写入内存页和从物理内存中读出页的个数进程入交换率：交换区输入的进程数目进程出交换率：交换区输出的进程数目版权所有测试时代（T北京慧灵科技有限公司数据库级别的测试指标：数据库的并发连接数：客户端的最大连接数数据库锁资源的使用数量

14、4.5测试数据准备案例数据：满负荷压力根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况下，测试 xxx核心业务系统的处理能力。数据准备工作包括：1. xxxxx4.6运行状况记录记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应该 结合测试实时记录系统各个层次的资源和参数。主要包括：硬件环境资源服务器操作系统参数网络相关参数数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录5测试过程及结果描述xxxx务系统的性能测试共计执行了2次，两次执行的脚本流程作了调整，其他的环境和数据都一样。在测试数据准备完备以后，第一次测试中

15、，操作流程为每次交易都执行用户 登录操作，第二次测试中，操作流程为先进行用户登录，然后每次交易都不再执行用户登 录。版权所有测试时代（T北京慧灵科技有限公司5.1测试描述两次测试都是在12月22日凌晨进行的。第一次测试执行了 30分钟左右，执行脚本都是采用每次交易都执行登录操作，测试过 程中，交易的执行速度随着测试的进行，越来越慢，交易的响应时间越来越长，交易出错（超时）情况也越来越严重，交易在执行到 30分钟左右，用户登录交易开始大量失败（超 时）并导致后续的交易都无法完成，于是终止本次测试。第二次测试执行了 50分钟左右，在第一次测试的基础上，调整交易流程，让每次交易 都只登录一次，然后顺

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

17、动1个Vuser，在7分钟左右启动所有的 Vuser（ 200 个），执行登录，并 根据设置的时间间隔发起交易。这次测试都部署在如下的场景中。运行的脚本部署在 3台PC机，主要目的就是检查在较大压力的情况下，xxxxx心业务系统的性能表现。选择了 2台PC,每台PC机部署了 70个左右并发用户，选择1台PC，部署60个左右的并发用户，并运行LoadRunner的控制器（Controller）5.3测试结果两次测试AP服务器主机上的 CPU利用率如下：第13页共16页版权所有测试时代(T北京慧灵科技有限公司CPU Total APP4100806040200厂 User% 厂 Sys% Wait

18、%2U- 303 - 3or3OD. 305. 390- 30QI- 30Q2- 3003 - 3第14页共16页Time of Day可以看出在两次测试执行中第一次(1:52 -2:20)测试过程中 CPU的利用率都几乎达到了 100%，第二次测试中(2:45- 4:00) CPU的利用率也达到了 95%以上。两次测试在数据库(Oracle)服务器上主机上的 CPU利用率如下:CPU Total REQDB1厂 User% 厂 Sys% Wait%3D. 300- 32I-340- 314-3H0. 3OI. 391- 392 - 393 - 3oeo- 3Time of Day可以看出两次

19、测试执行中第一次(1:52 -2:20)测试过程中CPU的利用率很低，第二次测试中(2:45-4:00)CPU的利用率较高也达到了75%以上，但两次测试的 CPU的10等待时间却都比较高，IO和CPU利用率对照表如下：第#页共16页北京慧灵科技有限公司版权所有测试时代(T迦试时代T"芒卜 6，芒 a l i t IhREQDB1SLeLX ksboo o oo o 0 5 0 4 3 3oo o oo o 5 0 5 2 2 1oo oo o15 0CPU% 10/secoeo- 3 ow3 93 - 392 - 391- 3ol. 3no. 3is- 314- 340- 302 -

20、 321- 300- 33U-. 3 nu o o o o o 0 8 6 4 2%SVS.LSU第15页共16页Time of Day可以看出两次测试执行中第一次( 1:52 -2:20)测试过程中CPU的10等待率较低，因 为大多数的交易都是用户登录，都压在 AP服务器上了，第二次测试中(2:45-4:00) CPU 的IO第一次测试第一次测试使用了 200个并发用户，并发用户的启动信息如下：各类交易的交易相应时间(秒)Color Scale交易名称最小平均最大1AutoUW_Tra nsactio n0.023.73387.8711Con firm_Tra nsactio n210.20

21、3210.203210.2031CTDetail_Tra nsacti on105.878151.032199.4771EdorNosca nApp In put_Tr an sacti on60.704153.425259.2341Gen eralQuery_Tra nsact ion0.06713.62339.09431In dividualQuery_Tra ns actio n0.78128.04264.9841Issue_Tra nsact ion5.14530.660.2218.531109.639210.74611.2818.55315.47410.09319.46959.271

22、各类交易的平均响应时间图:第#页共16页测试肘代版权所有 测试时代（T北京慧灵科技有限公司22020018016014012010060eo40240260-Tvnsaction Re&pioim Time Under Lo勒I20401S060 100 120Number of Vusers第16页共16页可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。第二次测试第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执行一次用户登录，然后执行对应的交易处理，交易过程中不再执行用户登录操作。运行的并发用户数目如下图：在用户登录过程中，交易的平均响应

23、时间如下图：第17页共16页第#页共16页020406000' 100 120Number of Vusers140ISO100200TMnsctjon Response Tinie Under loail(spuclLJwtf)】 -E-H swuodw血tt第#页共16页迦试时代版权所有测试时代（T北京慧灵科技有限公司从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一直稳定在这个数值左右。在第二次测试中，各类交易的平均响应时间如下表：（单位：秒）Response im电20D-19018017Q160140-1301109Q-8070SSl4000:05O0：1O00-15 0tt2O 00:2500.3000:350O.4U00:4500:5000-5501:0001:05Ehpsed scenario limeE-H ®WLI udwWHOL>E®a><Colo