收单系统性能测试方案1.0_20120224

银行卡收单系统性能测试计划

文档编号：SFPAY-POSP_SPT_01

日期:2012/02/23 

文档修订记录

1    项目概述    4

1.1    项目背景    4

1.2    测试目的    4

1.3    缩略语    4

2    系统架构    4

2.1    系统逻辑架构    4

2.1.1    网络体系结构图    4

2.1.2    逻辑体系结构图    5

2.2    系统功能描述    5

3    测试计划    6

3.1    测试目标    6

3.1.1    测试需求及功能点    6

3.1.2    测试范围    6

3.1.3    测试环境    6

3.2    测试工具    7

3.3    测试方法    7

3.3.1    场景设计    8

3.3.2    监控策略    8

3.3.3    关键指标    8

3.4    时间安排    9

3.5    测试进入/退出标准    9

3.5.1    进入标准    9

3.5.2    退出标准    10

3.6    测试中断标准    10

3.7    测试恢复标准    10

3.8    约束和假设    10

4.    风险分析    10

5.    测试交付物    11

6.    参考文档    12

1.项目概述

1.1.项目背景

泰海网络银行卡收单系统（以下简称POSP系统）是为了更好的支持目前顺丰速运业务，由泰海网络主导实施的满足中国人民银行关于第三方支付相关法规的一套专业的支付体系，供应商为南京银石计算机系统有限公司。POSP系统采用了该公司成熟的产品，能更加有效的支持泰海网络的第三方支付业务。

1.2.测试目的

测试的目的和目标是：在公司提供POSP系统的测试环境中，测试方运用性能测试工具对POSP系统产生模拟真实使用环境的压力负载，重现缺陷发生状态，并监控客户端和服务器性能指标，最终判断性能缺陷所属系统业务模块。

1.3.缩略语

2.1.系统逻辑架构

2.1.1.网络体系结构图

系统采用B/S架构模式，客户端通过WebLogic中间件访问数据库，无线POS通过GPRS连通到应用服务器POSP。中间件和数据库分别部署在两立服务器上。

2.1.2.逻辑体系结构图

2.2.系统功能描述

XXXXX。

3.测试计划

3.1.测试目标

此次性能测试的具体目标为：

1.开发正确、有效的软件性能测试脚本，模拟用户操作行为，作为测试有效实施的基础；

2.通过此次性能测试，判断POSP系统性能缺陷存在的所属业务模块，找到系统的低效进程。

压力测试是为了测试系统在多并发、重复处理以及大业务量情况下，POSP系统的处理能力以及对系统硬件资源的消耗情况。能满足日常生产及特殊事件内生产的需要。

3.1.1.测试需求及功能点

1.平台支持最大联机终端数

2.日支持最大交易笔数、日均交易笔数

3.单笔交易处理速度峰值、均值

4.POSP登陆用户数（最大在线、同一时间并发）

5.页面打开响应时长（最大、最小、均值、异地）

6.数据交互吞吐量（最大、最小、均值）

7.平台连续平稳运行时长

8.数据库和应用服务器运行状况及瓶颈（CPU利用率、磁盘利用率、网络负载；最大、最小、平均）

9.平台自恢复能力

3.1.2.测试范围

本方案主要对泰海网络银行卡收单系统的性能需求提供测试方法、测试脚本及场景设计说明、测试数据准备、测试计划等一系列压力测试执行标准。

3.1.3.测试环境

硬件环境

本次测试使用的测试工具为HP公司的性能测试工具LoadRunner v9.0。 

3.3.测试方法

3.3.1.场景设计

本次测试将建立如下三种演示场景来进行性能测试：

1、POSP系统单场景测试：单独运行POSP场景，银行接口和POS终端全部用模拟器代替，用该场景查找联机交易中POSP系统自身的性能问题； ?

2、银行场景测试：运行POSP系统，POS终端用模拟器代替，银行接口采用真实建行和工行接口，用该场景观测平台整体运行性能，发现瓶颈；

3、POSP系统web并发测试：检验web页面登陆、商户录入、终端录入、交易查询等主要功能在多用户并发状态下的运行状况。

同时，根据以上场景并发用户的加压情况分析系统响应时间以及服务器CPU和内存、磁盘IO的利用情况。

场景1、2并发用户数分析：

系统设计支持同时在线终端数量2000个(?)，交易平均日处理能力300万笔，峰值处理速度200笔/秒。（不考虑年用户增长量）

POSP

场景3并发用户数分析：

并发数可以通过POSP系统收单机构用户在线数去评估：并发数=在线数 *（10%至20%）*（1+年用户增长量（按15%计）），例如：POSP系统预计最大的数据库连接数为1000，则系统并发用户数为1000×10%×（1+15%）= 115，若在线数的20%计算，并发数位230。

注：1.可以在此基础上再加增量，例如增加30%的增量，则最后结果为150～300个并发，可按300测试

    2.web登录的并发用户数可在此基础上再增加30%的增量,则最后结果为195～390个并发,可按390测

试

3.3.2.Web部分

针对POSP系统的各种复杂业务进行分析，根据业务人员和开发经理的综合意见，取得以下该系统性能测试中需要关注的关键业务，包括：

登录

商户录入

终端录入

交易查询

交易统计

……

针对以上关键业务，得出以下POSP_Web性能测试要求：

无

3.3.4.监控策略

        本次性能测试将使用LoadRunner监控业务的性能指标及主机的性能情况，为发现性能缺陷提供准确的参考数据。 

3.3.5.关键指标

在进行性能测试的同时，用测试工具对应用服务器资源进行监控。监控系统资源指标，选取有意义的数据进行分析。下面列出常用的一些参考指标

UNIX性能资源

3.4.1.进入标准

  以下条件具备后，用户验收测试平台XXXXX可以进行本次性能测试：

1)测试环境部署完毕（包括应用服务器、中间件、数据库、客户端）

2)测试范围内模块功能完善

3)数据库测试数据准备完毕

4)运维方提供拥有对应操作权限的操作用户

5)数据库中已具备与日常生产环境同级别的数据量，可以保证性能测试结果的准确性

3.4.2.退出标准

本次性能测试的退出标准为：必要的性能测试用例执行率达100%，获得被测系统性能数据，可以进行性能数据分析。

3.5.测试中断标准

如果发生业务功能问题，并在一定时间段内无法修复，性能测试将被中断；

测试负载机不能访问被测系统，则性能测试中断；

3.6.测试恢复标准

由业务功能问题引起的性能测试中断，将在功能被修复后恢复测试。

由测试负载机不能访问被测系统引起的测试中断，在测试负载机可以访问被测系统后测试恢复。

1.风险分析