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

更多软件测试资料请访问领测软件测试网泰海网络银行卡收单系统性能测试计划文档编号：SFPAY-POSP_SPT_01日期:2012/02/23 领测软件测试论坛/性能测试报告项目编号：文档修订记录版本号日期撰写人审核人批准人变更摘要 & 修订位置1.02012/02/20黎奋勇初稿，描述系统性能测试方案及计划国家开发银行版权所有 第2页 共7页POSP系统泰海网络银行卡收单系统性能测试计划目 录1项目概述41.1项目背景41.2测试目的41.3缩略语42系统架构42.1系统逻辑架构42.1.1网络体系结构图42.1.2逻辑体系结构图52.2系统功能描述53测试计划63.1测试目标63.1.1测试需求及功能点63.1.2测试范围63.1.3测试环境63.2测试工具73.3测试方法73.3.1场景设计83.3.2监控策略83.3.3关键指标83.4时间安排93.5测试进入/退出标准93.5.1进入标准93.5.2退出标准103.6测试中断标准103.7测试恢复标准103.8约束和假设104.风险分析105.测试交付物116.参考文档121. 项目概述1.1. 项目背景泰海网络银行卡收单系统（以下简称POSP系统）是为了更好的支持目前顺丰速运业务，由泰海网络主导实施的满足中国人民银行关于第三方支付相关法规的一套专业的支付体系，供应商为南京银石计算机系统有限公司。POSP系统采用了该公司成熟的产品，能更加有效的支持泰海网络的第三方支付业务。1.2. 测试目的测试的目的和目标是：在公司提供POSP系统的测试环境中，测试方运用性能测试工具对POSP系统产生模拟真实使用环境的压力负载，重现缺陷发生状态，并监控客户端和服务器性能指标，最终判断性能缺陷所属系统业务模块。1.3. 缩略语词汇相关描述Loadrunner测试工具，用来编写测试脚本和产生压力负载WebLogic11g DELL R710高性能服务器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数内存数用途DELL R71014864G中间件服务器DELL R71015864G数据库服务器软件环境 软件类型软件版本操作系统RedHat中间件WebLogic 11g数据库Oracle 11g人力资源环境公司角色姓名人员职责研发经理XXXXX配合协调测试工作配合协调测试工作研发人员XXXXX测试组长XXXXX测试工程师XXXXX测试工程师测试人员3.2. 测试工具本次测试使用的测试工具为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联机交易并发量计算结果一：主要工作时间段8：0024：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，则系统并发用户数为100010%（1+15%）= 115，若在线数的20%计算，并发数位230。注：1.可以在此基础上再加增量，例如增加30%的增量，则最后结果为150300个并发，可按300测试 2.web登录的并发用户数可在此基础上再增加30%的增量,则最后结果为195390个并发,可按390测试3.3.2. Web部分针对POSP系统的各种复杂业务进行分析，根据业务人员和开发经理的综合意见，取得以下该系统性能测试中需要关注的关键业务，包括：登录商户录入终端录入交易查询交易统计针对以上关键业务，得出以下POSP_Web性能测试要求：系统功能操作步骤系统用户数并发用户数响应时间（秒）POSP登录输入用户名、密码、验证码后，点登录按钮10003903商户录入在商户管理中点击“商户录入”3005在商户管理中点击“商户查询”终端录入在本行终端管理中点击“终端录入”在本行终端管理中点击“终端查询”附：响应时间参考值：业务复杂性平均响应时间值(秒)行业平均响应时间参考值（秒）峰值响应时间参考值（秒）日常交易、简单查询0.52秒小于3一般业务高峰期建议在2秒内，极端情况下小于4秒中等交易、一般查询335小于10秒复杂交易、复杂查询8510小于20秒批量交易、151030小于30秒3.3.3. 接口部分无3.3.4. 监控策略 本次性能测试将使用LoadRunner监控业务的性能指标及主机的性能情况，为发现性能缺陷提供准确的参考数据。 3.3.5. 关键指标在进行性能测试的同时，用测试工具对应用服务器资源进行监控。监控系统资源指标，选取有意义的数据进行分析。下面列出常用的一些参考指标UNIX性能资源度量 描述CPU utilization CPU 的使用时间百分比Disk rate 磁盘传输速率Incoming packets rate 每秒钟传入的以太网数据包数Interrupt rate 每秒内的设备中断数Outgoing packets rate 每秒钟传出的以太网数据包数Page-in rate每秒钟读入到物理内存中的页数Page-out rate每秒钟写入页面文件和从物理内存中删除的页数Paging rate 每秒钟读入物理内存或写入页文件的页数Swap-in rate正在交换的进程数Swap-out rate正在交换的进程数System mode CPU utilization 在系统模式下使用 CPU 的时间百分比User mode CPU utilization 在用户模式下使用 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沟通，明确被测试系统的技术架构和通信协议3XXXXX完成准生产环境的搭建4XXXXX配合完成测试数据准备工作5测试团队确认数据的可用性6搭建测试环境：网络、硬件、软件、系统应用以及监控工具，测试工具安装等测试方案设计阶段XXXXX性能测试计划XXXXX性能测试方案7定义测试模型，抽取典型交易，确认交易配比8完成人员及资源的规划安排9确定测试实施的方案及策略脚本开发阶段10验证压