LoadRunner性能测试报告分析.docx

LoadRunner性能测试报告分析.docx

《LoadRunner性能测试报告分析.docx》由会员分享，可在线阅读，更多相关《LoadRunner性能测试报告分析.docx（14页珍藏版）》请在冰豆网上搜索。

LoadRunner性能测试报告分析

xxx系统性能测试报告

姓名：

班级：

学号：

1前言

目前，随着WebTours订票系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：

随着订票过程中大数据量的“冲击”，在客户信息信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。

本报告前部分即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的WebTours订票系统的性能测试。

2HPWebTours系统定义

HPWebTours订票系统作为本次测试的被测系统，该业务系统的主要功能包括：

搜索航班，预订机票并查看航班路线。

在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。

2.1功能简介

HPWebTours主要功能如下：

Ø用户注册

Ø登录

Ø查询航班

2.2性能测试指标

本次测试是针对HPWebTours订票系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。

1、系统的响应能力：

即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。

2、应用系统的吞吐率：

即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。

3、应用系统的负载能力：

即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

3系统结构及流程

HPWebTours订票系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。

不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。

3.1系统总体结构

HPWebTours订票系统系统由用户注册、登录、查询航班等这些功能构成。

3.2功能模块

本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在HPWebTours订票系统中，各种交易及其包含的功能模块关系如下：

1．注册

2．登录

3．查询航班

本次压力测试主要设计的功能模块以及所属的路径如下表

名称

所属交易

路径

3.3业务流程

本次性能测试中，选择的各类交易的业务流程如下：

4．注册

5．登录

6．查询航班

查询交易的业务流程只是单一步骤的，即：

输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事务处理，交易流程图略。

3.4关键点描述

本次性能测试的关键点，就是查看HPWebTours订票系统在并发压力下的表现，即：

支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找出各类交易的性能瓶颈。

3.5性能测试环境

本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都是通过浏览器访问应用系统。

其中具体的硬件和网络环境如下：

Ø服务器设备：

IBM570（DBserver），IBM690（APserver）

Ø操作系统：

Windows2003

Ø网络环境：

LAN（10M）

Ø数据库：

MYSQL

Ø客户端：

PC（Windows）

网络拓扑和结构图如下：

4性能测试

从广泛意义上讲性能测试包括：

压力测试、稳定性测试、负载能力测试和可扩展性测试等。

在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次HPWebTours订票系统的性能测试主要是采用通常的压力测试模式来执行的，即：

逐步增加压力，查看应用系统在各种压力状况小的性能表现。

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。

4.1性能测试概述

本次压力测试是指针对现行的HPWebTours订票业务系统的联机交易处理能力的测试，检验系统的吞吐率。

本系统的压力测试主要是针对HPWebTours订票系统，检查在日间交易高峰时期，并发用户数较多的时候的处理能力等等。

4.2测试目的

压力测试的目的就是检验系统的最大吞吐量，检验现行的HPWebTours订票系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。

本次针对HPWebTours订票业务系统所进行的压力测试的测试目的为：

✧给出HPWebTours订票系统当前的性能状况

✧定位新业务系统性能瓶颈或潜在性能瓶颈

✧总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。

4.3测试方法及测试用例

使用性能测试软件LoadRunner，对现行的HPWebTours订票系统进行脚本录制、测试回放、逐步加压和跟踪记录。

测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。

本次测试将依照如下场景进行测试：

用户数

功能模块

业务操作

200

400

700

1000

注册

注册

登录

登录

业务

查询航班

针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：

∙每隔2秒增加1个用户连接，最多增加到200个用户，查看并记录运行情况

∙每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况

∙一次性连接10个用户，查看记录运行情况

∙一次性连接100个用户，查看记录运行情况

4.4测试指标及期望

在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，则测试已经达到目的，即可终止压力测试。

✧应用软件级别的测试指标：

1）联机交易类的执行情况

✓交易的平均响应时间（期望值：

<15s）

✓交易的最大响应时间（期望值：

<30s）

✓平均每秒处理交易数量（分别记录单位时间内成功、失败和停止的交易数量）

✓交易成功率（期望值：

>95%）

✓不同并发用户数的状况下的上述记录值

2）测试结果分析情况

✓单笔记录的处理时间（期望值：

<15s）

✓单位时间内的处理交易笔数（期望值：

>10个）

✓某个时间段内的交易处理数量

✓单笔能处理的最大数据量

✓在每个交易处理中最大（最耗时）的模块

✓在不同数量的测试数据基础上的上述记录值

✧网络级别的测试指标：

✓吞吐量：

单位时间内网络传输数据量

✓冲突率：

在以太网上监测到的每秒冲突数

✧操作系统级别的测试指标：

✓进程/线程交换率：

进程和线程之间每秒交换次数

✓CPU利用率：

即CPU占用率（％）

✓系统CPU利用率：

系统的CPU占用率（％）

✓用户CPU利用率：

用户模式下的CPU占用率（％）

✓磁盘交换率：

磁盘交换速率

✓中断速率：

CPU每秒处理的中断数

✓读入内存页速率：

物理内存中每秒读入内存页的数目

✓写出内存页速率：

每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目

✓内存页交换速率：

每秒写入内存页和从物理内存中读出页的个数

✓进程入交换率：

交换区输入的进程数目

✓进程出交换率：

交换区输出的进程数目

✧数据库级别的测试指标：

✓数据库的并发连接数：

客户端的最大连接数

✓数据库锁资源的使用数量

4.5测试数据准备

前期准备工作包括：

（1）录制好一段完整的脚本,包括（注册，登录，查询航班）

（2）进行相关的设置

4.6运行状况记录

记录可扩展性测试中的测试结果及其系统的运行状况。

除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。

主要包括：

✓硬件环境资源

✓服务器操作系统参数

✓网络相关参数

✓数据库相关参数：

具体数据库参数有所不同，结合各个数据库独有的特点记录

5测试过程及结果描述

HPWebTours订票系统的性能测试共计执行了2次，两次执行的脚本流程作了调整，其他的环境和数据都一样。

在测试数据准备完备以后，第一次测试中，操作流程为每次交易都执行用户登录操作，第二次测试中，操作流程为先进行用户登录，然后每次交易都不再执行用户登录。

5.1测试描述

两次测试都是在12月22日凌晨进行的。

第一次测试执行了30分钟左右，执行脚本都是采用每次交易都执行登录操作，测试过程中，交易的执行速度随着测试的进行，越来越慢，交易的响应时间越来越长，交易出错（超时）情况也越来越严重，交易在执行到30分钟左右，用户登录交易开始大量失败（超时）并导致后续的交易都无法完成，于是终止本次测试。

第二次测试执行了50分钟左右，在第一次测试的基础上，调整交易流程，让每次交易都只登录一次，然后顺序执行交易逻辑。

测试开始初期，交易的响应时间随着交易并发量的增加而快速增加，在测试执行了10分钟左右，所有的用户登录操作都基本完成，此后交易响应时间开始减少，并比较平稳的执行，绝大部分交易执行比较平稳成功率也很高，除了两个交易：

xxx（Audit_Transaction）和xxx（ClaimRegister_Transaction），这两个交易的执行速度特别慢，交易相应时间一直都维持在190秒左右和160秒左右，这两个交易超时现象严重，交易成功率很低，很多交易都因为超时而失败。

5.2测试场景

测试中，使用逐步加压的模式，采用：

每隔2秒启动1个并发用户（Vuser）的方式，即：

每隔1秒，启动1个Vuser，在7分钟左右启动所有的Vuser（200个），执行登录，并根据设置的时间间隔发起交易。

这次测试都部署在如下的场景中。

运行的脚本部署在3台PC机，主要目的就是检查在较大压力的情况下，xxxxx心业务系统的性能表现。

Ø选择了2台PC，每台PC机部署了70个左右并发用户，

Ø选择1台PC，部署60个左右的并发用户，并运行LoadRunner的控制器（Controller）

5.3测试结果

两次测试AP服务器主机上的CPU利用率如下：

可以看出在两次测试执行中第一次（1:

52–2:

20）测试过程中CPU的利用率都几乎达到了100%，第二次测试中（2:

45-4:

00）CPU的利用率也达到了95%以上。

两次测试在数据库（Oracle）服务器上主机上的CPU利用率如下：

可以看出两次测试执行中第一次（1:

52–2:

20）测试过程中CPU的利用率很低，第二次测试中（2:

45-4:

00）CPU的利用率较高也达到了75%以上，但两次测试的CPU的IO等待时间却都比较高，IO和CPU利用率对照表如下：

可以看出两次测试执行中第一次（1:

52–2:

20）测试过程中CPU的IO等待率较低，因为大多数的交易都是用户登录，都压在AP服务器上了，第二次测试中（2:

45-4:

00）CPU的IO

✧第一次测试

第一次测试使用了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_Transaction

60.704

153.425

259.234

1

GeneralQuery_Transaction

0.067

13.623

39.094

1

IndividualQuery_Transaction

0.781

28.042

64.984

1

Issue_Transaction

5.145

30.6

60.22

1

8.531

109.639

210.746

1

1.281

8.553

15.474

1

0.093

19.469

59.271

各类交易的平均响应时间图：

可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。

✧第二次测试

第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执行一次用户登录，然后执行对应的交易处理，交易过程中不再执行用户登录操作。

运行的并发用户数目如下图：

在用户登录过程中，交易的平均响应时间如下图：

从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一直稳定在这个数值左右。

在第二次测试中，各类交易的平均响应时间如下表：

（单位：

秒）

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_Transaction

16.504

79.919

169.239

1

EndCase_Transaction

11.88

46.546

85.658

1

GeneralQuery_Transaction

0.152

11.017

35.321

交易相应时间时序图如小：

图中最上方的两条曲线（即交易相应时间最慢的）分别是：

xxx（Audit_Transaction）和xxx（ClaimRegister_Transaction），除了这两类交易，其他各类交易都是在测试初期执行较慢，随着用户登录完成以后，各类交易的平均响应时间都稳定在对应的数值上，并都保持在90秒以内。

途中，从20分钟开始到35分钟，点击率下降的原因是部分查询交易循环600次已经成功结束，在35分钟左右重新启动，所有出现了途中点击率下滑的现象。

6测试分析和结论

（根据具体的测试过程和结果，结合测试目标，进行相应的分析，给出结论和建议）

在xxxxx核心业务系统的性能测试过程中，将分别撰写测试计划和性能测试报告，其中测试计划将在测试开始之前完成，用以指导测试、并做好各个阶段的计划和任务分配工作，在测试结束之后，根据测试结果，将生成测试报告。