当前位置:文档之家› 性能测试报告 V1.1

性能测试报告 V1.1

<第一阶段性能测试报告>

张良友

[说明:

1.本文件中“[]”中内容为举例和说明文字,请在文件拟制时替换或删除;

2.若文中某章节内容可省略、不需要或适用,请保留该标题,并根据实际在内容部

分写明“略”、“勿需”或“不适用”等,同时适当说明原因。

3.请作者注意在文档右上角修改该文档的密级。]一帐通卡性能测试报告

文件修订历史

修订时间修订概要作者审核批准2009-12-

新建张良友

10

模板修订历史

版本生效时间变更概要作者审核批准

目录

1. 概述 (5)

1.1 背景 (5)

1.2 目标 (5)

1.3 范围 (5)

1.3.1 业务范围 (5)

1.3.2 系统范围 (5)

1.4 术语和缩略语 (5)

2. 测试内容及测试方法 (6)

2.1 测试内容 (6)

2.2 测试方法 (6)

2.2.1 性能测试流程 (6)

2.2.2 性能测试模型分析 (7)

2.2.3 评估测试和性能管理方案的规划实施 (8)

2.3 工作目标 (8)

3. 测试环境 (8)

3.1 测试环境拓扑图 (8)

3.2 测试环境配置 (9)

3.3 测试工具及监控工具部署 (10)

4. 测试场景 (10)

4.1 基准测试场景 (11)

4.2 单交易场景 (11)

4.3 单系统场景 (12)

4.4 疲劳测试场景 (12)

4.5 混合交易场景 (13)

5. 角色和职责 (13)

6. 性能测试总体报告 (14)

6.1 单业务场景性能分析 (14)

6.1.1 KISS系统交易分析 (14)

6.1.2 IST交易分析 (15)

6.1.3 ESB交易性能分析 (16)

6.2 综合业务场景性能分析 (16)

6.2.1 系统吞吐量TPS分析 (17)

6.2.2 交易响应时间分析 (18)

6.2.3 系统资源分析 (19)

7. 问题和建议 (21)

7.1 问题一 (21)

7.2 问题二 (22)

7.3 问题三 (22)

7.4 问题四 (22)

7.5 问题五 (23)

8. 附录 (23)

1.概述

本文档为XX银行XX系统性能测试方案,其内容用于描述本次性能测试服务的实施方案,以及测试项目组织实施的技术规范。

本文档中描述的内容,旨在

为XX系统的性能状态进行客观评估,提供性能数据;

为性能测试工作规定有效、完整的实施方案;

为性能测试工作规定具体的任务、角色分工、进度计划上的安排;

1.1背景

满足集团的“一个客户,一个账户,多个产品,多种服务”的战略,XX将以标准的金融卡为基础,加载其他产品服务, XX卡与其它非银行产品的关联,将通过现有集团客户信息管理系统(CIF2)关联。系统要上线前对XX系统做性能检验和评估。

1.2目标

要求系统能支持并满足目前AS/400主机、信用卡系统的最大发卡量(4500万)及交易性能指标,不影响系统整体的交易性能。

电话银行IVR及人工客服能支持最大发卡量的服务。

程序没有大的性能漏洞;

系统性能能够满足基本上线要求

1.3范围

1.3.1 业务范围

XX业务

1.3.2 系统范围

XX银行业务处理系统

XX接入平台系统

XX业务受理系统

1.4术语和缩略语

术语/缩略词说明

响应时间

TPS

IST

2.测试内容及测试方法

此次压力测试实施是对XXXX 系统性能进行测试评估的过程,我们将依据系统(生产环境)的实际运行现状,抽取对系统性能产生较大影响的业务交易,模拟最终用户的操作行为,构建一个与生产实际相近的压力仿真模型(场景),对系统实施压力测试,以此评判系统的整体性能的实际性能表现。

2.1测试内容

根据与相关人员的沟通和交流,此期工程上线的目标和期限,通过对现有系统运行数据的统计,结合系统的设计目标和业务特点,遵循着发生频率高、对系统或数据库性能影响大、关键和核心业务等原则,本期测试内容重点为银联交易操作及ESB验密功能,以及后台批处理业务。

2.2测试方法

此次压力测试通过构建与真实环境相同数据规模的压力测试环境,采用业界成熟的自动化性能测试工具Loadrunner,通过创建压力测试程序、构建压力测试模型,对被测试系统实施自动化压力测试,最后形成压力测试结果分析报告。

2.2.1性能测试流程

通过自动化测试工具模拟最终用户向服务器发起业务请求,进行性能测试。通过测试工具对测试过程中系统各点进行监控,每一次测试结束后工具自动生成结果报告供分析使用。

2.2.2性能测试模型分析

系统是否能够稳定运行具有重要意义。因此,必须要采取科学的方法对XX系统进行全面的性能验收测试。 XX系统的性能测试模型分析应当按照下面几个步骤来实施: 业务模型建立

分析XX系统上线后所面临的性能压力的来源和类别,并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例,后台自动批处理的数据数量和类别等。最终目的是建立一个能够逼真模拟帐户管理系统实际运行场景的业务模型。

测试数据模型建立

根据业务模型准备测试数据和基础数据,确保系统数据库中数据容量和真实性符合实际运行情况。

监控模型建立

性能测试的目的不仅仅是获得关键业务的性能指标,同时也要通过性能测试监控主机、数据库、中间件的各个性能指标,从而发现性能瓶颈,为进一步的性能调优提供准确的参考数据。

测试模型建立

对帐户管理系统的测试,因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处,在单业务负载测试是就可以发现各个系统本身的性能缺陷,而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。

执行模型建立

XX系统的性能测试要测试人员、开发人员和运维人员紧密配合,才能保证整个测试工作的成功。因此,只有建立一套规范的性能测试流程,明确各个角色的工作职责,才能使性能测试工作有序、高效的开展。

风险模型建立

由于性能测试的特殊性,因此在整个测试过程中,会遇到很多导致整个性能测试失败的风险。

2.2.3评估测试和性能管理方案的规划实施

?测试用例的建立

在性能评估的规划阶段,通过把以文档形式所指定的关键业务转化为实际可实施的测试用例,同时分配所采集的业务数据。

?测试场景的设置

把关键业务的分布转化为评估测试的具体实施设置。

?环境配置和系统就绪

在实施的开始之前,有必要保证被测应用系统是可用和经历了功能和稳定性测试的,同时功能支持必须贯穿在整个可能影响测试实施的过程。

?测试实施和性能监控

按指定的流程事实评估测试,并根据关键业务对整个应用系统的影响和已有的性能参照点,在评估测试当时进行实时的性能监控。

?实时预警和被测试系统的避险

针对在线系统的特定,在对被测试系统实施评估时必须有严格的实时预警和保护的自动控制,一旦被测试应用有异常的趋势和可能,必须有及时的避险机制。

2.3工作目标

构建与实际环境相匹配的基础数据环境

根据系统性能需求设计性能测试方案,定义业务模型及测试场景

执行性能测试,获取参测系统的各项性能指标

对比各参测系统的性能指标,制作综合评测报告,为评测系统性能及性能

优化提供参考依据。

检验系统上线前,程序是否有大的并发漏洞,和性能瓶颈

3. 测试环境 3.1

测试环境拓扑图

第一阶段测试采用挡板程序,交易不发送到AS400和V+:详细信息如下图:

10.31.102.10

10.31.102.11

KISS APP

HA

D Switch

挡板程序

ExternalSys

JDBC/OCI:1534

10.31.180.1010.31.180.11

压力服务器

Storage

IST 系统DB

HSM

Socket:8

TCP/IP

Node2

IST 系统AppServer

Node1

AS400

VisionPlus

10.39.100.11

10.39.100.10

JDBC:1534

T3:30010

TCP/IP

IST 系统测试环境架构图 V1.0

Oracle

TCP/IP

TCP/IP

Socket

HTTP

Proxy

Socket

ESB

Web 服务器

3.2 测试环境配置

本次测试环境都是单机模式,和真实环境有区别,生产环境是双机; 服务器类型

IP 地址

硬件

操作系统信息 应用软件信息 CP U

内存

存储 操作系统 版

应用软件 版本

Web-Logic 10.31.10

2.11 4 *

2

GH

z

16Gb

80

Gb

RedHat

Linux

AS

4

JDK

j2sdk1.

4.2_

weblog-

ic8.x

Oracle

Client

10g Re-

10.2.0.

2 10.31.10

2.10 2 *

2

GH

z

16Gb

80

Gb

RedHat

Linux

AS

4

JDK

j2sdk1.

4.2_

weblog-

ic8.x

Oracle

Client

10g Re-

lease

10.2.0.

2

Web 服务器10.39.10

0.10

2 *

2

GH

16Gb 80

Gb

RedHat

Linux

AS

4

10.39.10

0.11

2 *

2

GH

z

16Gb

80

Gb

RedHat

Linux

AS

4

数据库服务器10.31.22.

27/kissst

g

8 *

3.5

GH

z

32Gb

16

0G

b

AIX

5.3.

Oracle

10g

Server

10.2.0.

2

IST 服务器

4 *

1.6

GH

z

16Gb

80

Gb

AIX

5.3.

10.37.17

4.18

PACES-

KISS1.5.

10.37.1

74.19

Oracle

Client

10g Re-

lease

10.2.0.

2

3.3测试工具及监控工具部署

测试工具采用Loadrunner8.1,数据库监控采用I3,系统资源监控采用OPVM。具体信息如下:

工具名称许可

证要

IP地

服务器配置要求操作系统要求应用软件信息

CPU

操作系统

应用软件

HP Loa dRu nne 支持

Web

协议

sock

10.31

.180.

10

4 * 2

GHz

8Gb

160

Gb

Windows

2003 En-

terprise

Edition

SP1

LoadRun-

ner Con-

troller

8.1

r

N/A 10.31

.180.

11/13

2 * 2

GHz

4Gb

80G

b

Windows

2003 En-

terprise

Edition

SP1

LoadRun-

ner Load

Generator

8.1

I3 Oracl

e监

https://www.doczj.com/doc/de14300330.html,:20720/index.html

OVP M 系统

监控

https://www.doczj.com/doc/de14300330.html,:8080/OVPM/PMLogin.jsp?aut

henticate=4

4.测试场景

分析XX系统上线后所面临的性能压力的来源和类别,并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例,后台自动批处理的数据数量和类别等。最终目的是建立一个能够逼真模拟帐户管理系统实际运行场景的业务模型。选择如下交易类型:

●ATM查询

●ATM取现

●CDM存现

●POS消费

●查询协议

●查询状态

●更新协议

●更新状态

●修改重置密码

◆验证密码

4.1基准测试场景

基准测试场景用来验证系统功能完整性和可用性,以及测试脚本的可重复性:

序号功能名称功能点并发循环次

操作间隔循环间

(Think-

Time)

1

IST ATM查询 1 5 5 0

2 ATM取现 1 5 5 0

3 CDM存现 1 5 5 0

4 POS消费 1

5 5 0

5

ESB 修改重置密码 1 5 5 0

6 验证密码 1 5 5 0

7

KISS 查询协议 1 5 5 0

8 查询状态 1 5 5 0

9 更新协议 1 5 5 0

合计更新状态 1 5 5 0

4.2单交易场景

单交易测试场景主要是为了检验各功能模块是否有严重的性能障碍,以及检验各自交易单独的性能处理能力的最大值:

序号功能名称场景

子序

并发人数

循环

时间

1 ATM查询 1 30 50 100 200 15分钟

2 ATM取现 2 30 50 100 200 15分钟

3 CDM存现 3 30 50 100 200 15分钟

4 POS消费 4 30 50 100 200 15分钟

5 查询协议 5 30 50 100 200 15分钟

6 查询状态 6 30 50 100 200 15分钟

7 更新协议7 30 50 100 200 15分钟

8 跟新状态8 30 50 100 200 15分钟

9 修改重置密

9 30 50 100 200

15分

10 验证密码10 30 50 100 200 15分钟

11 ……

合计

用户调度方式:

采用每秒钟增加5个用户,场景结束时每秒钟退出5个用户。每笔交易间隔

时间5秒,即设置think time时间;

4.3单系统场景

分别执行经过Proxy程序对IST测测试,通过ESB的测试场景和KISS应用的测试场景:

序号功能

名称

功能点并发

操作间隔循环间

(Think-

Time)

1 IST ATM查询1

2

5

50

5 0 ATM取现1

2

5

50

5 0 CDM存现1

2

5

50

5 0 POS消费

1

2

5

50

5 0

2 ESB 修改重置

密码

2

5

5

100 5 0 验证密码

2

5

5

100

5 0

3

KISS 查询协议1

2

5

50

5 0

合计查询状态1

2

5

50

5 0 更新协议1

2

5

50

5 0 更新状态

1

2

5

50

5 0

4.4疲劳测试场景

采用100用户并发,持续执行8小时。

序号功能名

称功能点所占比例循环

次数

操作间隔执行时

(Think-

1 IST ATM查询15% 1 5 8小时

2 ATM取现10% 1 5 8小时

3 CDM存现8% 1 5 8小时

4 POS消费20% 1

5 8小时

5 ESB 查询协议4% 1 5 8小时

6 查询状态4% 1 5 8小时

7 更新协议2% 1 5 8小时

8 更新状态2% 1 5 8小时

9 KISS 修改重置

密码5% 1 5 8小时

10

验证密码30% 1 5 8小时合计

4.5混合交易场景

按照分析的业务模型,对不同交易按照一定比例,分别执行不同压力的下的测试场景:

序号功能

名称功能点所占比

并发操作间隔循环间

5

10

15

20

(Think-

Time)

1 IST ATM查询15% 5 0

2 ATM取现10% 5 0

3 CDM存现8% 5 0

4 POS消费20%

5 0

5 KISS 查询协议4% 5 0

6 查询状态4% 5 0

7 更新协议2% 5 0

8 更新状态2% 5 0

9 ESB 修改重置

密码5% 5 0

10

验证密码30% 5 0 合计

5.角色和职责

部门和角

色职责

人员

测试人员监督项目执行过程和执行结果,推进和执行质量保障体系工作流程,对项目中重大问题进行决

策,协调项目所需的软硬件资源和人力资源。

搭建测试开发环境,测试数据准备、被测系统(生

产环境)的数据备份和清除、并提供技术支持和

配合,解决测试过程中出现的各种技术问题

开发人员同测试项目进行沟通,解决应用程序出现的各种问题,协调相关技术人员。

性能测试专家需求调研分析,参与设计测试模型和方案,指导测试工程师开展工作;

对测试中的问题进行分析和定位,协调组织整个性能测试过程,制定测试计划和方案;

负责对测试案例的业务流程进行指导、评审和确认。测试范围的指定,测试需求确认;

性能测试

工程师

进行测试准备和测试执行工作

数据库专

协助解决数据库相关问题

6.性能测试总体报告

XX系统第一阶段性能测试,共执行了85个场景,其中包括单业务场景,混合业务场景,单系统场景,和疲劳测试场景;

IST系统在目前硬件环境和数据环境下,最大吞吐量TPS达到10个,最大并发用户数达到200个,当用户并发100个时,系统交易响应时间3秒左右。下一章会有详细介绍;

系统在压力测试过程中主要是IST系统CPU利用率过高,当并发达到100时,系统CPU利用率就达到80%,其他指标正常;另外数据库服务器主要表现为IO过高,持续压力半小时系统IO就维持在100%,导致不能及时响应,出现交易失败,压力测试过程中,交易成功率一直在98%以上;

分别从单业务场景和混合业务场景对系统性能状况做详细的分析;

6.1单业务场景性能分析

6.1.1KISS系统交易分析

最大并发用户数为100,响应时间均在1秒以内,查询客户协议交易响应时间最长为0.187秒,TPS 值在37左右,而且还有继续提升的潜力;没有发现系统资源异常。其中查询卡状态交易有少量错误,错误返回代码 1001;

具体信息如下表:

6.1.2 IST 交易分析

分别测试了25用户、50用户、100用户和150用户并发的场景,其中50个并发的时候平均响应时间3秒,TPS 是5个;IST 服务器CPU 利用率在60%左右;成功率都在90%左右(和挡板程序设置有关);

在100用户并发数据如下表内容,CPU 利用率饱和、TPS 为10个左右、平均响应时间6秒左右。此时系统吞吐量达到最高;

场景名称 执行并

IST 系统资源异常情备注

编号 场景名称

执行时间

并发用户数 平均响应时间

平均TPS 正确率 IST 系统资源情

况 异常情况 备注

CPU MEM IO

S_001 单业务测试-查询客户协议 2009-11-30 100 0.187 36.8 100% 正

常 正常 正常

S_002 单业务测试-更新客户协议

2009-11-30 100 0.035 36.6 100% 正

常 正常 正常

S_003 单业务测试-查询卡状态 2009-11-30 100 0.037 37.3

98% 正

正常 正常 错误代码

1001

S_004 单业务测试-更新卡协议 2009-12-1 100 0.078 37.6 100% 正

常 正常 正常 S_005 KISS(HTTP)

测试场景

2009-11-30

100 0.053 30.7

99% 正

正常

正常

号时间发

数均

TPS

情况况

CPU

ME

M

IO

S_ 00 6 单业务测

试-ATM查

2009

-12-

4

100 6.3

10.

9

85%

异常

(备

注)

CPU利

用率超

过90%

成功

率和

挡板

程序

设置

有关

S_ 00 7 单业务测

试-POS消

2009

-12-

4

100 6.1 9.7 90%

异常

(备

注)

CPU利

用率超

过90%

S_ 00 8 单业务测

试-ATM取

2009

-12-

4

100 6.8 9.2 90%

异常

(备

注)

CPU利

用率超

过90%

S_ 00 9 IST

(proxy

)测试场

2009

-12-

4

100 5.7 9.3 90%

异常

(备

注)

CPU利

用率超

过90%

6.1.3ESB交易性能分析

并发用户数分别50、100、200;其中用户并发200个时,平均响应时间3秒左右,TPS为11个左右,CPU利用率平均在90%以上;IST服务器达到饱和;当并发用户超过250时,IST出现拥堵(mblook –t 查看)

编号场景名称执行

时间

平均

TPS

正确

IST系统资源情

异常

情况

CPU MEM IO

S_01单业务测2009200 3.1 11.2 100% 异常正正CPU

0 试-密码

验证-12-

7

(备

注)

常常利用

90%

S_01 1 单业务测

试-重置

密码

2009

-12-

7

200 3.1 10.8 100%

异常

(备

注)

CPU

利用

90%

S_01 2 ESB场景

2009

-12-

7

200 100%

异常

(备

注)

CPU

利用

90%

IO

表:ESB交易性能数据

6.2综合业务场景性能分析

综合业务场景是本次测试的所有交易,按照业务场景模型进行一定配比组合成的测试场景,并发用户分别为50、100、150、200;具体交易和比例如下节详细表;

分别对系统吞吐、交易响应时间和系统资源利用情况在不同压力下的表现进行横向和纵向的分析;

6.2.1系统吞吐量TPS分析

TPS 是系统每秒交易数,衡量系统性能的重要指标;下表是不同压力下系统TPS的表现;

交易名用户比

例0用户50用

100用

150用

200用

ATM取现10% 0 0.68 0.93 1.28 0.93 ATM查询15% 0 0.95 1.23 1.76 1.36 POS消费25% 0 1.35 1.76 2.37 2.07

修改卡状态4% 0 0.58 1.1 1.56 2.07

修改客户协议4% 0 0.59 1.1 1.57 1.94

查询卡状态2% 0 0.52 1.14 1.57 1.93

查询客户协议2% 0 0.66 1.19 1.54 1.94

密码修改重置8% 0 0.3 0.54 0.62 0.63

密码校验30% 0 0.92 1.48 2.04 2.18

合计TPS0 6.55 10.47 14.31 15.05

表:综合场

景TPS

从下图我们可以分析出,ATM 取现、ATM 查询和POS 消费三个交易在并发用户达到150的时候,TPS 值最高,用户并发在200时,吞吐量反而下降,说明这三支交易性能出现瓶颈,主要是由于IST 服务器CPU 资源消耗殆尽导致;

密码验证和密码修改两只交易在并发150和200时变化不大,说明也基本达到饱和状态,接近系统最大处理能力;

查询卡状态、查询客户协议、修改卡状态和修改客户协议四个交易的TPS 随着用户数的增加一直在提高,说明这四个交易的处理能力还有很大提升空间,回顾上面单业务测试场景我们可以解释,这四个交易的TPS 可以达到30个;

混合场景TPS

0.5

1

1.5

2

2.5

50

100150

200

并发用户

T P S 值

ATM取现ATM查询POS消费修改卡状态修改客户协议查询卡状态查询客户协议密码修改重置密码校验

图:综合场景TPS 分析 6.2.2 交易响应时间分析

通过系统不同压力下,分析每支交易的响应时间,下表是具体数据: 交易名 用户比例 0用户 50用户 100用户 150用户 200用户

ATM 取现 10% 0 1.709 3.036 5.098 8.43 ATM 查询

15% 0 1.718 3.043 5.016 8.363

相关主题
相关文档 最新文档