性能测试报告材料(实用模板).pdf

《性能测试报告材料(实用模板).pdf》由会员分享，可在线阅读，更多相关《性能测试报告材料(实用模板).pdf（21页珍藏版）》请在三一文库上搜索。

1、实用标准文案 精彩文档 xxxxxxxxxx 性能测试报告 2019 年 5 月 9 日 实用标准文案 精彩文档 目录 1 前言 . 1 1 第一章 XXXXXXXX 核心业务系统性能测试概述 1 1.1 被测系统定义. 1 1.1.1 功能简介 . 1 1.1.2 性能测试指标. 2 1.2 系统结构及流程. 2 1.2.1 系统总体结构. 2 1.2.2 功能模块描述. 2 1.2.3 业务流程 . 3 1.2.4 系统的关键点描述（KP ） . 4 1.3 性能测试环境. 4 1.3.1 硬件及网络环境. . 错误！未定义书签。 1.3.2 系统装配描述. . 错误！未定义书签。 1.3

2、.3 系统启动和管理. . 错误！未定义书签。 2 第二章性能测试 . . 5 2.1 压力测试 . 5 2.1.1 压力测试概述. 5 2.1.2 测试目的 . 5 2.1.3 测试方法及测试用例. 6 2.1.4 测试指标及期望. 7 2.1.5 测试数据准备. 9 2.1.6 运行状况记录. 9 3 第三章测试计划及方案 9 2.2 测试步骤 . . 错误！未定义书签。 2.2.1 被测系统调研. . 错误！未定义书签。 2.2.2 测试环境的部署. . 错误！未定义书签。 2.2.3 脚本的录制和调试. . 错误！未定义书签。 2.2.4 准备测试场景. . 错误！未定义书签。 2.2

3、.5 准备测试数据. . 错误！未定义书签。 2.2.6 执行性能测试. . 错误！未定义书签。 2.2.7 生成测试报告. . 错误！未定义书签。 2.3 测试时间进度及人员安排. . 错误！未定义书签。 2.3.1 人员安排 . . 错误！未定义书签。 3 第四章测试报告 . 19 实用标准文案 精彩文档 1 前言 目前， XXXX的 XXXXXXXX 核心业务系统（以下简称新业务系统）已先后在XXXX 、成 功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续，xxx 等 34 家分 公司的 XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信息大量增 长的态势。

4、 随着新业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们 关注的焦点： XXXX大数据量的“冲击” ，在 XXXX 信息进入时， 系统能稳定在什么样的性 能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整 的性能测试来给出答案。 本性能测试规划书即是基于上述考虑，参考科学的性能测试方法而撰写的，用 以指导即将进行的XXXXXXXX 核心业务系统的性能测试。 1 第一章 xxxx 系统性能测试概述 1.1 被测系统定义 xxxx 业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针 对 XXXXXXXX 核心业务系统进行的） ，该业务系

5、统的主要功能包括：xxxxx 在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统 对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预 计的数据容量中，系统能够容忍的最大用户数， 1.1.1功能简介 xxxxxx 主要功能如下： xxx xxxxx 实用标准文案 精彩文档 1.1.2性能测试指标 本次测试是针对XXXXXXXX 核心业务系统的性能特征和系统的性能调优而进行的， 主要需要获得如下的测试指标。 1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户 端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务

6、器处理 时间。 2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时 间内，应用系统针对不同的负载压力，所能完成的交易数量。 3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应 时间中，系统能够支持的最多的客户端的数量。 1.2 系统结构及流程 xxxx 业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样 的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟 实际生产环境略有不同。 1.2.1系统总体结构 描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织 体系结构和功能模块的组织体系结构。

7、 1.2.2功能模块 本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点 分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在 xxx 业务系统中， 各种交易及其包含的功能模块关系如下： 1xxx 2xxxx 3xxxx 实用标准文案 精彩文档 本次压力测试主要设计的功能模块以及所属的路径如下表 名称所属交易路径 1.2.3业务流程 本次性能测试中，选择的各类交易的业务流程如下： 1xxxxxx 2xxxxxxx 3xxxxxx ： 4xxx： 实用标准文案 精彩文档 5xxxxx 6xxxx 查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此

8、在 本次性能测试中只作为一个事物处理，交易流程图略。 1.2.4关键点描述（ KP ） 本次性能测试的关键点，就是查看xxxx 业务系统在并发压力下的表现，即：支持 的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找 出各类交易的性能瓶颈。 1.3性能测试环境 本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中， 数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都 是通过浏览器访问应用系统。 其中具体的硬件和网络环境如下： 服务器设备： IBM 570（DBserver ） ， IBM 690 （APserver ） 操

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

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

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

12、器端的运行情况和 返回给客户端的运行结果。 使用的测试用例包括：联机处理交易和查询交易，其中联机交易测试试用的交易包 括： xxxx 查询类交易包括：xxxx 测试用例列表包括： 交易种类案例一案例二案例三案例四 30% 40% 25% 10% 10% 10% 25% 0% 20% 10% 15% 0% 20% 20% 15% 10% 30% 20% 20% 80% 本次测试将依照如下场景进行测试： 用户数 功能模块 业务操作交易配比（ %) 200 400 700 1000 0 0 0 0 0 2 4 10 17 24 5 10 21 36 52 7 13 27 47 67 5 11 21

13、37 53 5 10 21 37 52 7 14 29 51 72 5 10 19 34 48 11 22 45 78 112 14 28 56 98 140 实用标准文案 精彩文档 6 12 24 41 59 5 11 22 38 55 6 13 26 45 64 20 40 80 141 201 针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看 服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下： 每隔 2秒增加 1 个用户连接，最多增加到200 个用户，查看并记录运行情况 每隔 2秒增加 2 个用户连接，最多增加到200 个用户，查看并记录运行情

14、况 一次性连接10 个用户，查看记录运行情况 一次性连接100 个用户，查看记录运行情况 2.1.4测试指标及期望 在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能 指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出 了业务需求的要求范围，则测试已经达到目的，即可终止压力测试。 2.1.4.1应用软件级别的测试指标： 1) 联机交易类的执行情况 交易的平均响应时间（期望值：95% ） 不同并发用户数的状况下的上述记录值 2）测试结果分析情况 单笔记录的处理时间（期望值：10 个） 某个时间段内的交易处理数量 单笔能处理的最大数据量 在每个交易处

15、理中最大（最耗时）的模块 实用标准文案 精彩文档 在不同数量的测试数据基础上的上述记录值 2.1.4.2网络级别的测试指标： 吞吐量：单位时间内网络传输数据量 冲突率：在以太网上监测到的每秒冲突数 2.1.4.3操作系统级别的测试指标： 进程 / 线程交换率：进程和线程之间每秒交换次数 CPU利用率：即CPU占用率（） 系统 CPU 利用率：系统的CPU占用率（） 用户 CPU 利用率：用户模式下的CPU占用率（） 磁盘交换率：磁盘交换速率 中断速率： CPU每秒处理的中断数 读入内存页速率：物理内存中每秒读入内存页的数目 写出内存页速率：每秒从物理内存中写到页文件中的内存页数目或者从物理内

16、存中删掉的内存页数目 内存页交换速率：每秒写入内存页和从物理内存中读出页的个数 进程入交换率：交换区输入的进程数目 进程出交换率：交换区输出的进程数目 2.1.4.4数据库级别的测试指标： 数据库的并发连接数：客户端的最大连接数 数据库锁资源的使用数量 实用标准文案 精彩文档 2.1.5测试数据准备 2.1.5.1案例数据：满负荷压力 根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90% 左右的状况下，测试xxx 核心业务系统的处理能力。 数据准备工作包括： 1 xxxxx 2.1.6运行状况记录 记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应

17、该结合测试实时记录系统各个层次的资源和参数。主要包括： 硬件环境资源 服务器操作系统参数 网络相关参数 数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录 3 第三章 测试过程及结果描述 xxxx务系统的性能测试共计执行了2 次，两次执行的脚本流程作了调整，其他的环 境和数据都一样。在测试数据准备完备以后，第一次测试中，操作流程为每次交易都执 行用户登录操作，第二次测试中，操作流程为先进行用户登录，然后每次交易都不再执 行用户登录。 3.1 测试描述 两次测试都是在12 月 22 日凌晨进行的。 第一次测试执行了30 分钟左右，执行脚本都是采用每次交易都执行登录操作，测 试过

18、程中，交易的执行速度随着测试的进行，越来越慢，交易的响应时间越来越长，交 实用标准文案 精彩文档 易出错（超时）情况也越来越严重，交易在执行到30 分钟左右，用户登录交易开始大 量失败（超时）并导致后续的交易都无法完成，于是终止本次测试。 第二次测试执行了50 分钟左右，在第一次测试的基础上，调整交易流程，让每次 交易都只登录一次，然后顺序执行交易逻辑。测试开始初期，交易的响应时间随着交易 并发量的增加而快速增加，在测试执行了10 分钟左右，所有的用户登录操作都基本完 成，此后交易响应时间开始减少，并比较平稳的执行，绝大部分交易执行比较平稳成功 率也很高，除了两个交易：xxx(Audit_Tr

19、ansaction)和 xxx(ClaimRegister_Transaction)，这两个交易的执行速度特别慢，交易相应时间一直 都维持在 190 秒左右和 160 秒左右，这两个交易超时现象严重，交易成功率很低，很多 交易都因为超时而失败。 3.2 测试场景 测试中，使用逐步加压的模式，采用：每隔2秒启动1个并发用户（ Vuser）的方 式，即：每隔1秒，启动 1 个 Vuser ，在 7 分钟左右启动所有的Vuser（200个） ，执行 登录，并根据设置的时间间隔发起交易。 这次测试都部署在如下的场景中。 运行的脚本部署在3 台 PC机，主要目的就是检查在较大压力的情况下，xxxxx 心

20、业 务系统的性能表现。 选择了 2 台 PC ，每台 PC机部署了 70 个左右并发用户， 选择 1 台 PC ，部署 60 个左右的并发用户，并运行LoadRunner 的控制器 （Controller） 3.3 测试结果 两次测试 AP服务器主机上的CPU利用率如下： 实用标准文案 精彩文档 CPU Total APP4 0 20 40 60 80 100 1 : 4 2 1 : 5 2 2 : 0 2 2 : 1 1 2 : 2 1 2 : 3 0 2 : 4 0 2 : 5 0 2 : 5 9 3 : 0 9 3 : 1 8 3 : 2 8 3 : 3 8 3 : 4 7 3 : 5

21、7 Time of Day User%Sys%Wait% 可以看出在两次测试执行中第一次（1:52 2:20 ）测试过程中CPU的利用率都几 乎达到了 100% ，第二次测试中（2:45- 4:00）CPU 的利用率也达到了95% 以上。 两次测试在数据库（Oracle ）服务器上主机上的CPU利用率如下： CPU Total REQDB1 0 20 40 60 80 100 1 : 4 3 1 : 5 3 2 : 0 3 2 : 1 2 2 : 2 2 2 : 3 1 2 : 4 1 2 : 5 1 3 : 0 0 3 : 1 0 3 : 1 9 3 : 2 9 3 : 3 9 3 : 4

22、8 3 : 5 8 Time of Day User%Sys%Wait% 可以看出两次测试执行中第一次（1:52 2:20 ）测试过程中CPU的利用率很低， 第二次测试中（2:45- 4:00）CPU的利用率较高也达到了75% 以上，但两次测试的CPU 的 IO 等待时间却都比较高，IO 和 CPU利用率对照表如下： 实用标准文案 精彩文档 REQDB1 0 20 40 60 80 100 1 : 4 3 1 : 5 3 2 : 0 3 2 : 1 2 2 : 2 2 2 : 3 1 2 : 4 1 2 : 5 1 3 : 0 0 3 : 1 0 3 : 1 9 3 : 2 9 3 : 3 9

23、 3 : 4 8 3 : 5 8 Time of Day u s r % + s y s % 0 500 1000 1500 2000 2500 3000 3500 4000 D i s k x f e r s CPU%IO/sec 可以看出两次测试执行中第一次（1:52 2:20 ）测试过程中CPU的 IO 等待率较 低， 因为大多数的交易都是用户登录，都压在 AP服务器上了，第二次测试中（2:45- 4:00 ） CPU的 IO 等待率较高，都达到了80% 以上。 两次测试的网络压力并不大，网络流量如下： 0 500 1000 1500 2000 2500 3000 3500 1 : 4

24、2 1 : 5 2 2 : 0 2 2 : 1 1 2 : 2 1 2 : 3 0 2 : 4 0 2 : 5 0 2 : 5 9 3 : 0 9 3 : 1 8 3 : 2 8 3 : 3 8 3 : 4 7 3 : 5 7 Total-Write Total-Read AP服务器监控的网络流量 0 1 2 3 4 5 6 1 : 4 3 1 : 5 3 2 : 0 3 2 : 1 2 2 : 2 2 2 : 3 1 2 : 4 1 2 : 5 1 3 : 0 0 3 : 1 0 3 : 1 9 3 : 2 9 3 : 3 9 3 : 4 8 3 : 5 8 千 Total-Write To

25、tal-Read DB服务器上监控的网络流量 从图中可以看出，在10M的局域网中，网络流量并不大。 实用标准文案 精彩文档 3.3.1第一次测试 第一次测试使用了200 个并发用户，并发用户的启动信息如下： 各类交易的交易相应时间（秒） Color Scale 交易名称最小平均最大 1 AutoUW_Transaction 0.0 23.733 87.871 1 Confirm_Transaction 210.203 210.203 210.203 1 CTDetail_Transaction 105.878 151.032 199.477 1 EdorNoscanAppInput_Tr an

26、saction 60.704 153.425 259.234 1 GeneralQuery_Transact ion 0.067 13.623 39.094 1 IndividualQuery_Trans action 0.781 28.042 64.984 1 Issue_Transaction 5.145 30.6 60.22 1 Login_Transaction 4.265 115.433 246.736 1 ManualUW_Transaction 77.094 77.094 77.094 1 NBQuery_Transaction 0.334 22.348 49.625 1 Pay

27、In_Transaction 1.503 59.944 112.639 1 PayOut_Transaction 5.256 29.178 60.279 1 PayOutQuery_Transacti on 0.078 1.291 6.872 1 PEdorTypeAC_Transacti on 111.253 160.054 213.544 1 PosNoScanApp_Transact ion 9.254 158.276 271.381 实用标准文案 精彩文档 1 POSQuery_Transaction 29.602 122.815 212.93 1 PrtNoInput_Transac

28、tio n 1.722 146.879 263.094 1 Relogin_Transaction 30.16 70.939 105.24 1 ReportInput_Transacti on 1.155 101.387 184.783 1 Review_Transaction 5.091 112.682 387.087 1 RiskInput_Transaction 2.821 113.049 211.427 1 vuser_end_Transaction 0.0 0.0 0.0 1 vuser_init_Transactio n 0.0 0.158 2.417 1 2.084 112.37

29、3 267.659 1 0.278 6.312 15.394 1 3.75 13.56 25.925 1 0.22 6.243 15.939 1 8.531 109.639 210.746 1 1.281 8.553 15.474 1 0.093 19.469 59.271 各类交易的平均响应时间图： 可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。 测试中，每秒的点击率如下： 实用标准文案 精彩文档 测试中每秒页面的下载速度如下： 根据上面两组数据，即：每秒的点击率和每秒下载页面的速度，可以看出，在测试 执行开始 4 分钟以后， 核心业务系统用户登录的并发数量不断在增加

30、，但是用户登录后 的数据下载量却变化不大，这样将最终导致大量的用户登录因为交易处理超时而失败。 实用标准文案 精彩文档 3.3.2第二次测试 第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执 行一次用户登录，然后执行对应的交易处理，交易过程中不再执行用户登录操作。 运行的并发用户数目如下图： 在用户登录过程中，交易的平均响应时间如下图： 从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在 加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一 直稳定在这个数值左右。 在第二次测试中，各类交易的平均响应时间如下表：（单位：秒）

31、实用标准文案 精彩文档 Color Scale 交易最小平均最大 1 Audit_Transaction 19.481 162.12 207.627 1 AutoUW_Transaction 0.0 13.001 49.494 1 ClaimRegister_Transaction 75.599 143.641 163.978 1 Confirm_Transaction 1.131 51.427 94.585 1 CTDetail_Transaction 37.257 65.967 148.334 1 EdorNoscanAppInput_Transa ction 16.504 79.919

32、169.239 1 EndCase_Transaction 11.88 46.546 85.658 1 GeneralQuery_Transaction 0.152 11.017 35.321 1 IndividualQuery_Transacti on 0.875 14.455 40.578 1 Issue_Transaction 4.269 14.326 30.496 1 Login_Transaction 8.363 90.998 151.344 1 ManualUW_Transaction 3.262 81.311 171.284 1 NBQuery_Transaction 0.422

33、 12.082 36.297 1 PayIn_Transaction 0.559 32.012 74.462 1 PayOut_Transaction 2.204 11.121 32.397 1 PayOutQuery_Transaction 0.079 1.255 5.328 1 PEdorTypeAC_Transaction 37.384 66.606 137.382 1 PosNoScanApp_Transaction 15.892 85.482 164.156 1 POSQuery_Transaction 10.193 57.825 132.677 1 PrtNoInput_Trans

34、action 5.162 77.07 164.458 1 Relogin_Transaction 16.103 61.116 74.896 1 ReportInput_Transaction 4.88 66.869 138.372 1 Review_Transaction 8.67 61.846 302.131 1 RiskInput_Transaction 9.317 49.871 123.788 1 vuser_end_Transaction 0.0 0.0 0.016 1 vuser_init_Transaction 0.0 0.0 0.008 1 7.792 54.317 183.40

35、9 1 0.694 2.419 8.553 1 1.481 7.267 24.725 1 0.777 2.532 6.638 1 8.971 72.21 145.923 1 1.384 3.977 11.539 1 0.296 7.433 28.666 交易相应时间时序图如小： 实用标准文案 精彩文档 图中最上方的两条曲线 （即交易相应时间最慢的） 分别是：xxx (Audit_Transaction) 和 xxx(ClaimRegister_Transaction)，除了这两类交易，其他各类交易都是在测试初 期执行较慢， 随着用户登录完成以后， 各类交易的平均响应时间都稳定在对应的数值上，

36、并都保持在90 秒以内。 测试中每秒的点击率如下： 途中，从 20 分钟开始到35 分钟，点击率下降的原因是部分查询交易循环600 次已 经成功结束，在35 分钟左右重新启动，所有出现了途中点击率下滑的现象。 下面的几幅图中，数据线下滑的原因相同。 交易的吞吐率（每秒处理数据量）如下图： 实用标准文案 精彩文档 其中数据线下滑的原因同上。 4 第四章 测试报告 在 xxxxx 核心业务系统的性能测试过程中，将分别撰写测试计划和性能测试报告，其 中测试计划将在测试开始之前完成，用以指导测试、并做好各个阶段的计划和任务分配 工作，在测试结束之后，根据测试结果，将生成测试报告。 两份对应的文档名称如下： 性能测试计划书 性能测试报告