收单系统性能测试方案100224.docx
- 文档编号:16278493
- 上传时间:2023-07-12
- 格式:DOCX
- 页数:16
- 大小:51.44KB
收单系统性能测试方案100224.docx
《收单系统性能测试方案100224.docx》由会员分享,可在线阅读,更多相关《收单系统性能测试方案100224.docx(16页珍藏版)》请在冰点文库上搜索。
收单系统性能测试方案100224
泰海网络
银行卡收单系统性能测试计划
文档编号:
SFPAY-POSP_SPT_01
日期:
2012/02/23
文档修订记录
版本号
日期
撰写人
审核人
批准人
变更摘要&修订位置
1.0
2012/02/20
黎奋勇
初稿,描述系统性能测试方案及计划
1.项目概述
1.1.项目背景
泰海网络银行卡收单系统(以下简称POSP系统)是为了更好的支持目前顺丰速运业务,由泰海网络主导实施的满足中国人民银行关于第三方支付相关法规的一套专业的支付体系,供应商为南京银石计算机系统有限公司。
POSP系统采用了该公司成熟的产品,能更加有效的支持泰海网络的第三方支付业务。
1.2.测试目的
测试的目的和目标是:
在公司提供POSP系统的测试环境中,测试方运用性能测试工具对POSP系统产生模拟真实使用环境的压力负载,重现缺陷发生状态,并监控客户端和服务器性能指标,最终判断性能缺陷所属系统业务模块。
1.3.缩略语
词汇
相关描述
Loadrunner
测试工具,用来编写测试脚本和产生压力负载
WebLogic11g
DELLR710
高性能服务器
POSP系统
泰海网络银行卡收单系统
2.系统架构
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.测试环境
硬件环境
硬件类型
IP地址
CPU数
内存数
用途
DELLR710
10.0.56.114
8
64G
中间件服务器
DELLR710
10.0.56.115
8
64G
数据库服务器
软件环境
软件类型
软件版本
操作系统
RedHat
中间件
WebLogic11g
数据库
Oracle11g
人力资源环境
公司
角色
姓名
人员职责
研发经理
XXXXX
配合协调测试工作
配合协调测试工作
研发人员
XXXXX
测试组长
XXXXX
测试工程师
XXXXX
测试工程师
测试人员
3.2.测试工具
本次测试使用的测试工具为HP公司的性能测试工具LoadRunnerv9.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
联机交易
并发量计算结果一:
主要工作时间段8:
00~24:
00,共16小时
16小时*3600=57600秒
交易平均日处理300万笔,得出平均并发数
300万/57600秒=52
每秒交易52笔,得到使用POS终端模拟器交易发送的时间间隔
1000ms/52=19ms
并发量计算结果二:
高峰期:
10:
00-12:
00,15:
00-18:
00,共5小时
5小时*3600=18000秒
交易平均日处理300万笔,得出平均并发数
300万/18000秒=166
每秒交易166笔,得到使用POS终端模拟器交易发送的时间间隔
1000ms/166=6ms
并发量计算结果三:
峰值处理速度200笔/秒,得到使用POS终端模拟器交易发送的时间间隔
1000ms/200=5ms
由上表可得到,主要工作时间并发数52,高峰期并发数166,峰值处理速度200,故本次性能测试采用发送1000笔交易,分别每隔5ms、6ms、19ms测试得出测试结果。
场景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性能测试要求:
系统
功能
操作步骤
系统用户数
并发用户数
响应时间
(秒)
POSP
登录
输入用户名、密码、验证码后,点登录按钮
1000
390
≤3
商户录入
在商户管理中点击“商户录入”
300
≤5
在商户管理中点击“商户查询”
……
……
……
终端录入
在本行终端管理中点击“终端录入”
在本行终端管理中点击“终端查询”
……
附:
响应时间参考值:
业务复杂性
平均响应时间值(秒)
行业平均响应时间参考值(秒)
峰值响应时间参考值(秒)
日常交易、
简单查询
0.5~2秒
小于3
一般业务高峰期建议在2秒内,极端情况下小于4秒
中等交易、
一般查询
3
3~5
小于10秒
复杂交易、
复杂查询
8
5~10
小于20秒
批量交易、
15
10~30
小于30秒
3.3.3.接口部分
无
3.3.4.监控策略
本次性能测试将使用LoadRunner监控业务的性能指标及主机的性能情况,为发现性能缺陷提供准确的参考数据。
3.3.5.关键指标
在进行性能测试的同时,用测试工具对应用服务器资源进行监控。
监控系统资源指标,选取有意义的数据进行分析。
下面列出常用的一些参考指标
UNIX性能资源
度量
描述
CPUutilization
CPU的使用时间百分比
Diskrate
磁盘传输速率
Incomingpacketsrate
每秒钟传入的以太网数据包数
Interruptrate
每秒内的设备中断数
Outgoingpacketsrate
每秒钟传出的以太网数据包数
Page-inrate
每秒钟读入到物理内存中的页数
Page-outrate
每秒钟写入页面文件和从物理内存中删除的页数
Pagingrate
每秒钟读入物理内存或写入页文件的页数
Swap-inrate
正在交换的进程数
Swap-outrate
正在交换的进程数
SystemmodeCPUutilization
在系统模式下使用CPU的时间百分比
UsermodeCPUutilization
在用户模式下使用CPU的时间百分比
3.4.人员和时间安排
阶段
日期
时间
任务
如何完成
负责人
完成情况
备注
测试
准备
2月25日
9:
00-18:
00
测试方案评审
测试方案评审
项目全体人员
100%
2月26日
测试方案确定
测试方案确定
项目全体人员
100%
录制脚本,调试脚本
使用压力测试工具进行
测试
执行
进行第一轮压力测试
按测试方案设计场景逐个进行
数据库及服务器监控
监控数据库的运行情况,监控数据库服务器的资源使用情况(CPU和内存利用率)
应用及服务器监控
监控应用的运行情况,测试完成后要登录POSP首页看是否可以正常登录;监控应用服务器的资源使用情况(CPU和内存利用率)
提供第一轮压力测试结果
各场景响应时间,各服务器、数据库的分析结果等
程序优化
程序优化
进行第二轮压力测试
按测试方案设计场景逐个进行
应用、数据库及存储监控
同第一轮
提供第二轮压力测试结果
各场景响应时间,各服务器、数据库的分析结果等
程序优化
程序优化
进行第三轮压力测试
按测试方案设计场景逐个进行
应用、数据库及存储监控
同第一轮
提供完整的测试报告
各场景响应时间,各服务器、数据库的分析结果等
测试
完成
10:
00-18:
00
测试结果评审
讨论最终测试结果,分析上线风险
3.5测试进入/退出标准
3.4.1.进入标准
以下条件具备后,用户验收测试平台XXXXX可以进行本次性能测试:
1)测试环境部署完毕(包括应用服务器、中间件、数据库、客户端)
2)测试范围内模块功能完善
3)数据库测试数据准备完毕
4)运维方提供拥有对应操作权限的操作用户
5)数据库中已具备与日常生产环境同级别的数据量,可以保证性能测试结果的准确性
3.4.2.退出标准
本次性能测试的退出标准为:
必要的性能测试用例执行率达100%,获得被测系统性能数据,可以进行性能数据分析。
3.5.测试中断标准
如果发生业务功能问题,并在一定时间段内无法修复,性能测试将被中断;
测试负载机不能访问被测系统,则性能测试中断;
3.6.测试恢复标准
由业务功能问题引起的性能测试中断,将在功能被修复后恢复测试。
由测试负载机不能访问被测系统引起的测试中断,在测试负载机可以访问被测系统后测试恢复。
1.风险分析
风险因素
可能结果
可能发生时间
风险
级别
应对措施
工具缺陷
测试工具和监控工具无法全部支持信贷业务系统的测试和监控
随时
中
评估被测系统,分析所有需求。
通过其它工具实现对需求的支持程度。
测试数据的准备备份及恢复无法正常完成
测试过程中数据用尽或不满足测试需求,将导致测试无法实施。
测试执行时
高
运维方配合完成数据的准备、备份和恢复
测试环境有其他用户连接进行操作,服务器产生性能缺陷
a)测试方获得最大负载压力与实际最大负载有差距
b)服务器出现性能缺陷的现象,运维方定位性能缺陷模块并非真正性能缺陷的模块
测试执行时
高
测试方进行负载测试时,保证测试环境无其他连接和用户操作
测试服务器访问状态不稳定
测试准备和测试执行中断,测试计划时间延后
随时
高
保证测试期间测试环境访问畅通
2.测试交付物
步骤
测试实施内容
阶段提交物
测试准备阶段
1
整理现有系统测试需求和相关参考资料,与运维方沟通,明确本次性能测试的测试目标
2
与XXXXX沟通,明确被测试系统的技术架构和通信协议
3
XXXXX完成准生产环境的搭建
4
XXXXX配合完成测试数据准备工作
5
测试团队确认数据的可用性
6
搭建测试环境:
网络、硬件、软件、系统应用以及监控工具,测试工具安装等
测试方案设计阶段
XXXXX性能测试计划
XXXXX性能测试方案
7
定义测试模型,抽取典型交易,确认交易配比
8
完成人员及资源的规划安排
9
确定测试实施的方案及策略
脚本开发阶段
10
验证压力测试实施的技术可行性
11
完成脚本增强和必要的脚本开发
场景设计阶段
场景说明(包含在测试方案内)
12
根据业务调研确定典型业务,进行业务建模
13
在测试工具中进行业务配比
14
设计测试执行场景
15
编写测试场景、测试案例
16
测试执行前的准备工作检查确认
测试执行阶段
测试结果数据(html格式)
17
根据已定义的性能测试场景,执行性能测试
18
性能测试过程中,监测所有相关设备资源的使用情况
19
收集测试数据与监控数据
测试分析总结阶段
信贷业务系统性能测试报告
20
整理性能测试结果数据和过程中出现的问题
21
进行数据分析并出具性能测试评估报告
3.附加
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 性能 测试 方案 100224