性能测试计划(DOC).doc

性能测试计划

XXX手机银行客户端

性能测试方案

第II页

手机银行性能测试方案
修订记录
日期
版本
修订说明
修订人
2011-8-30
1.0
初稿
王颖

目 录
1 导言 1
1.1 文档目的 1
1.2 背景 1
1.3 参考文档 1
2 测试目的 1
3 测试指标 2
4 测试范围 3
4.1 逻辑架构图 3
4.2 交易选取原则 3
4.3 交易范围 4
4.4 环境与版本 5
5 测试资源 5
5.1 人员 5
5.2 工具 5
5.3 环境 6
5.3.1 网络拓扑图 6
5.3.2 软硬件配置 6
6 测试约束 7
6.1 入口和出口准则 7
6.1.1 入口准则 7
6.1.2 出口准则 7
6.2 暂停/再启动准则 7
6.3 通过/失败准则 8
6.3.1 通过准则 8
6.3.2 失败准则 8
7 测试策略 8
7.1 策略描述 8
7.2 测试类型 9
7.2.1 基准测试 9
7.2.2 负载测试 9
7.2.3 稳定性测试 9
7.3 测试数据 9
7.3.1 参数数据 9
7.3.2 存量数据 9
8 测试方法 10
8.1 基准测试 10
8.1.1 场景1：普通联机交易基准测试场景 10
8.1.2 场景2：普通联机交易以档板程序返回的基准测试场景 10
8.2 负载测试 11
8.2.1 场景3：单交易负载测试 11
8.3 稳定性测试 12
8.3.1 场景4：稳定性测试场景 12
9 测试风险 12
10 进度及分工 12
11 交付物 13
12 附件 13

- III -

1 导言
1.1 文档目的
手机银行客户端系统（简称客户端系统）即将上线，为了保证投产后系统能够支撑业务发展，稳定运行，对手机客户端系统进行性能测试；本文档的编写即是为了对性能测试实施提供方法指导、计划资源分配、识别实施风险，提高测试的可控性和有效性。
1.2 背景
手机客户端系统是在推出wap手机银行后，针对高端手机客户推出的在线金融服务系统，手机客户端系统与wap系统共用一套客户数据，传统业务业务逻辑一致，针对手机客户端独有的特点，推出了金融助手服务，主要包含了，商户搜索，在线购买机票，手机充值，理财计算器等特色功能。
由于客户端和wap手机银行共用一套客户数据，故wap手机银行的客户群是手机银行客户端系统潜在的使用者。所以手机银行客户端系统的性能测试基于现有wap手机银行生产的存量数据进行，保证性能测试环境与将来生产环境相吻合。
备注：但实际测试过程中，银行很难提供完全满足业务的大量数据，因为这些大量数据不一定能满足我们所做业务的单项数据要求。
1.3 参考文档
暂无
2 测试目的
通过对手机银行客户端系统的性能测试实施，在测试范围内可以达到如下目的：
1、 了解客户端系统在各种业务场景下的性能表现；
2、 了解客户端业务系统的稳定性；
3、 检验系统在异常业务场景下的容错能力；
4、 通过各种业务场景的测试实施，为系统调优提供数据参考；
5、 通过性能测试发现系统瓶颈，并进行优化。
6、 预估系统的业务容量
3 测试指标
指标分类
指标描述
性能指标需求数值
系统处理能力
每秒事务数TPS
TPS1=100笔/秒
典型交易平均交易响应时间ART
ART ≤0.2秒/笔
交易成功率
≥98%
主机资源利用率
CPU占用率
≤ 60%
内存使用率
≤ 80%
磁盘读写率(I/O)
≤ 80%
EWP资源利用率
CPU占用率
≤ 60%
内存使用率
≤ 80%
磁盘读写率(I/O)
≤ 80%
系统稳定性
评估系统是否能够长时间稳定运行
1、交易成功率≥98%；
2、场景运行期间系统资源及处理能力保持平稳；
3、无内存泄漏发生；
【说明】
1、把手机银行客户端接入的服务(EWP)和应用服务(APP)作为一个整体进行测试，前提是保证EWP服务不成为系统的瓶颈，如果发现EWP是瓶颈需要查明原因，并解决。
2、为了保证测试过程中负载机/客户端不成为系统瓶颈，测试过程中要求负载机/客户端的CPU和内存使用率均低于80%，否则需要考虑增加负载机资源。
3、为了重点测试手机银行客户端自身系统，系统的联机交易均做档板处理。系统通过前置发起交易测试一组基础数据，以便得到系统自身响应时间，通过该响应时间确定在混合业务场景中不同交易的占比。
4 测试范围
4.1 逻辑架构图
手机客户端就是可以在手机终端运行的软件；光大银行的客户端指的是推出的给客户提供在线金融服务的手机客户端，包括三部分，客户端，EWP，APP，本次性能测试主要针对EWP服务和APP服务，业务逻辑图如下：

为了真实反映手机客户端系统自身的处理能力，本次测试范围只包含客户端系统新增加的服务（图中黑色线实框），客户端，前置和核心等业务系统不在本次测试范围内。由于加密机为本次客户端上线做了升级，故对升级部分包含在本次测试范围内。
4.2 交易选取原则
手机银行客户端系统的性能测试交易选取原则如下：
1、 覆盖日交易发生量累计占日交易总量80%的交易；
2、 业务逻辑处理复杂的交易；
3、 被测系统特殊性能关注点；
4、 取WAP手机银行最新日交易量情况调整交易范围及比例
4.3 交易范围
本次性能测试包括手机银行CS版本主要交易和关键性交易以及内部管理系统用户登录。登录后交易包括登陆交易、储蓄账户类交易（包括查询，转账（行内转账））、信用卡查询；非登录，支付交易，商户查询，储蓄计算器等内容。
编号
交易码
交易名
交易占比
脚本名称
可参数化域
1
GeneratePINFromRSAToDes
测试通过加密机进行RSA密码到3DES转换性能
5%

2
Login
用户认证
20%

Password
UserId
_locale
BankId
LoginType
4
ActQueryPre
余额查询账户列表
10%

5
ActBalQry
余额查询
10%

AcNo
BankAcType
6
ActTrsQry
交易明细查询
10%

AcNo
BankAcType
BeginDate
EndDate
Currency
7
BankInnerTransfer
行内转账
15%

8
AcctInfoQry
信用卡账户信息查询
10%

9
BillInCurQry
未出账单查询
10%

CardId
Currency
10
ClientPayPre
发起支付
5%

Plain
Signature
11
ClientPay
支付
5%

Plain
Signature
MobilePhone
SignFlag
merchantId
MerName
orderId
transAmt
transDateTime
customerName
productInfo
customerEMail
merURL
merURL1
msgExt
currencyType
payType
EpayAcNo
AcType
cvv2
ExpDate
TestCode
AcTypeValue
VerType
Password
OTPPassword
4.4 环境与版本
性能测试是为了验证被测系统是否满足生产环境下的业务需求，因此要求测试环境（软硬件资源）与被测系统均与上线环境保持一致。
5 测试资源
5.1 人员
1. 项目经理：杨涛，任可任
2. 测试负责人：王磊
3. 测试人员：杨涛，任可任，王琦，张程等
4. 运维人员：周艳庆
5.2 工具
用途
工具
厂商/自产
版本
测试管理
QC
HP
9.0
测试执行
手工
/
/
LoadRunner
HP
8.1
测试缺陷
QC
HP
9.0
5.3 环境
5.3.1 网络拓扑图
暂时计划使用测试环境进行测试，拓扑图如下：

5.3.2 软硬件配置
为了尽可能模拟真实的生产环境，本次测试在测试环境上执行，软硬件配置如下：
环境
资源
数量
配置
与生产环境差异
EWP服务器硬件环境
EWP服务
1
PC Server 8
CPU：2核，主频 2.4GHz
内存：16G
存储：300G
IP地址：10.1.91.4
有差异：生产环境CPU为8核
EWP软件环境
EWP服务操作系统
1
CentOS 5.4
无差别
EWP服务应用软件
1
EWP3.0
无差别
APP服务器硬件环境
APP服务器
1
HP-UNIX
CPU：4核，主频 1.6GHz
内存：16G
存储：
IP地址：10.1.18.84
有差异：生产环境内存为20G
APP软件环境
APP服务操作系统
1
HP-UX B.11.31
无差别
APP服务器J2EE容器
1
Weblogic 10.3.0.0
无差别
6 测试约束
6.1 入口和出口准则
6.1.1 入口准则
1、 测试目的、测试指标均已明确；
2、 测试环境已经就绪；
3、 测试脚本已经编写并调试通过；
4、 测试脚本已参数化；
5、 测试数据已经准备；
6、 负载机已经准备；
7、 测试工具已经准备并已安装足够的License；
8、 测试人员全部到位；
9、 测试接口人已经明确；
10、 测试计划通过评审；
以上条件必须全部满足。
6.1.2 出口准则
1、 所有场景均已执行；
2、 测试结果通过评审；
3、 测试场景未执行完成但已经没有测试时间；
以上满足1、2属于正常退出，满足3属于异常退出。
6.2 暂停/再启动准则
1、 测试环境出现问题导致测试无法继续进行；
2、 测试数据不能及时准备就绪；
3、 测试中出现的缺陷不能及时解决且影响后续的测试执行；
4、 其它导致测试无法继续进行的情况出现；
以上条件满足其一测试可进入暂停状态。
导致测试暂停的问题得以解决即可重新启动测试执行。
6.3 通过/失败准则
6.3.1 通过准则
1、 所有场景均已执行；
2、 被测系统达到预期性能指标；
以上条件全部满足则测试通过。
6.3.2 失败准则
1、 场景未能按计划执行；
2、 场景变更未通过评审；
3、 被测系统性能数据不满足指标需求；
4、 因各种问题导致测试结果无效；
出现以上情况之一则测试失败。
7 测试策略
本章主要描述本次测试的策略及测试类型。
7.1 策略描述
1、为了模拟更真实的生产环境，在基础测试阶段要采集3组数据：
-通过前置发送核心系统，得到核心系统处理业务的响应时间
-通过网银挡板，模拟核心系统返回，得到网银系统业务响应时间
-通过EWP挡板，模拟网银系统返回，得到EWP系统业务响应时间

2、通过基础测试阶段得到的TPS推算出混合场景的业务占比模型，从而通过测试得到最贴近生产环境下的测试结果；

本次性能测试在局域网环境内进行，测试服务包括两部分：手机银行接入服务（EWP）,手机银行应用服务(APP),对EWP服务器的资源使用情况进行监控，并获取相关性能指标（支持并发数，响应时间）；手机银行应用服务（支持并发数，响应时间）。

7.2 测试类型
本次测试的测试类型包括基准测试、负载测试、稳定性测试。
7.2.1 基准测试
基准测试是在系统无压力的情况下，通过对单交易进行多次迭代，获取该交易发送单笔请求的平均响应时间，为后续的负载测试提供基准参照。测试共分为3种情况，
第一种：客户端系统将交易发送至核心，得到交易响应时间；
第二种：客户端系统通过WAP挡板程序，得到系统自身的交易响应时间。
第三种：客户端系统通过EWP挡板程序，得到EWP系统自身的交易响应时间。
本次测试对所有普通联机交易执行基准测试。
7.2.2 负载测试
负载测试是模拟多用户同时向服务器发送请求（单交易），获取服务器对并发请求的处理能力，并通过不断有规律地改变请求压力，获取系统在不同压力下的处理效率及系统性能拐点。
7.2.3 稳定性测试
稳定性测试是对特定场景在特定压力下（一般选取相关场景性能平稳处的压力）的长时间（理论为7×24小时）运行，通过观察系统响应效率、交易成功率及主机资源变化情况，分析被测系统是否能够长时间稳定运行。
疲劳测试对特定场景在特定压力下（一般选取相关场景性能拐点处的压力）的长时间（理论为7×24小时）运行，通过观察系统响应效率、交易成功率及主机资源变化情况，分析被测系统是否能够长时间稳定运行。
7.3 测试数据
7.3.1 参数数据
为了尽可能的模拟系统生产环境，所以JVM的初始堆栈大小、应用服务器的线程池、数据库连接池等系统配置，统一参考WAP手机银行生产环境配置。
7.3.2 存量数据
存量数据来自WAP手机银行实际生产系统，对生产数据进行脱敏处理，去除包括姓名、身份证号码、密码等敏感信息，并导入测试环境核心系统数据库。基础数据的数据规模（截至到2008-04-10）。
8 测试方法
根据不同的测试目的共设计6个业务模型测试场景，
8.1 基准测试
本次测试只对普通联机交易执行基准测试。
8.1.1 场景1：普通联机交易基准测试场景（无挡板）
【场景目的】
获取各个联机交易通过前置系统返回的基准响应时间，为负载测试提供数据参考。
执行顺序：1
【交易范围】
所有性能测试涵盖的交易。
【测试方法】
在测试环境无外在压力的情况下，模拟单用户迭代多次，获取交易平均响应时间。
【场景设置】
场景名称
用户数
迭代次数
迭代延时
思考时间
加压时间
负载生成器数量
Scene1
1
5min次数
0
0
跑完为止
1
对所有普通联机交易均执行上述场景测试，获取基准响应时间。
8.1.2 场景2：普通联机交易以档板程序返回的基准测试场景（EWP挡板）
【场景目的】
获取各个联机交易以档板返回的基准响应时间，测试手机银行客户端系统内处理交易流程的性能瓶颈，为负载测试提供数据参考。
执行顺序：2
【交易范围】
所有性能测试涵盖的交易。
【测试方法】
在测试环境无外在压力的情况下，模拟单用户迭代多次，获取交易平均响应时间。
【场景设置】
场景名称
用户数
迭代次数
迭代延时
思考时间
加压时间
负载生成器数量
Scene2
1
5min次数
0
0
跑完为止
1
对所有普通联机交易均执行上述场景测试，获取基准响应时间。
8.1.3 场景3：普通联机交易以档板程序返回的基准测试场景（WAP挡板）
【场景目的】
获取各个联机交易以档板返回的基准响应时间，测试手机银行客户端系统内处理交易流程的性能瓶颈，为负载测试提供数据参考。
执行顺序：2
【交易范围】
所有性能测试涵盖的交易。
【测试方法】
在测试环境无外在压力的情况下，模拟单用户迭代多次，获取交易平均响应时间。
【场景设置】
场景名称
用户数
迭代次数
迭代延时
思考时间
加压时间
负载生成器数量
Scene2
1
5min次数
0
0
跑完为止
1
对所有普通联机交易均执行上述场景测试，获取基准响应时间。
8.2 负载测试
8.2.1 场景4：单交易负载测试
【场景目的】
测试单个交易在高并发情况下的处理效率，定位每个交易影响处理性能的缺陷。查看在并发提交请求时刻，服务器对这些请求的处理和响应能力。主要观察内存使用情况，首先要观察各并发时刻或者多次并发持续时间段内，是否存在内存泄露；其次观察服务进程会否停止、僵死、锁页，这两种情况都是比较极端的故障情况，如果程序实现良好没有内存泄露，并且进程状况良好，不会出现上述两种现象，需要进一步跟踪响应时间、每秒点击率、业务失败率等性能指标在各并发时刻或者多次并发持续时间段内，是否能够表现在用户可接受范围内。
优先级：高 执行顺序：3
【交易范围】
所有性能测试涵盖的交易。
【测试方法】
在测试环境每秒增加25用户，模拟多用户高并发的情况，观察内存回收、CPU使用率、应用服务器线程池使用情况、交易响应时间等关键数据。
【场景设置】
场景名称
用户数
迭代延时
思考时间
加载方式
加压时间
退出方式
负载生成器数量
Scene3
25
50
……
0
0
递增
5分钟
同时
1
8.3 稳定性测试
8.3.1 场景5：混合业务容量测试场景（最合适的用户数和可承受的最大业务总量）
【场景目的】
在混合不同交易的场景中，不断增加用户并发请求量，同时观察系统性能拐点，最终测试出系统最合适的用户数和可承受的最大业务总量。
优先级：高 执行顺序：4
【测试方法】
根据场景1中得到的每个交易的基准响应时间，按照比例配置每个交易的并发请求量，从而建立一个混合业务的测试场景模型。在每秒增加50用户并发请求的压力下，观察系统的整体运行情况，最终找到系统性能拐点，确定最合适的用户数和最大业务容量。
【场景设置】
场景名称
用户数
迭代延时
思考时间
加载方式
加压时间
退出方式
负载生成器数量
Scene4
50
100
….
0
0
递增
不限时间
系统性能达到拐点
1
8.3.2 场景6：混合业务稳定性测试场景（稳定性测试和疲劳测试）
【场景目的】
在混合不同交易的场景中，使服务器的资源处于平稳状态和极限状态，并长时连续运行，以测试服务器在高负载情况下是否能够稳定工作。
优先级：高 执行顺序：5
【测试方法】
根据场景1中得到的每个交易的基准响应时间，按照比例配置每个交易的并发请求量，从而建立一个混合业务的测试场景模型。在多用户并发请求的压力下，系统连续运行12小时，观察系统的整体运行情况。
【场景设置】
场景名称
用户数
迭代延时
思考时间
加载方式
加压时间
退出方式
负载生成器数量
Scene5
待定
0
0
同时
12小时
同时
1

9 测试风险
风险编号
风险描述
风险发生可能性（高/中/低）
风险影响
（高/中/低）
责任人
规避方法
1
测试版本与生产上线版本不一致，造成测试风险
低
高
任可任
本次测试在UAT测试结束，程序代码封版之后进行，故不会有版本不一致带来的风险
2
在测试过程中业务变更带来的风险
低
中
任可任
本次测试在业务测试已经结束之后，不再接受新需求的前提下进行，故可以避免该风险点
10 进度及分工
阶段
编号
任务
工作量(人日)
开始日期
结束日期
责任人
测试计划
1
《测试计划》编写
3
2011-03-22
2011-03-24
任可任
2
《测试计划》评审及修订
1
2011-03-25
2011-03-25

测试准备
3
测试脚本准备
6
2011-03-28
2011-03-30
王琦、张程
4
测试环境准备
3
2011-03-28
2011-03-30
任可任
5
测试工具准备
3
2011-03-28
2011-03-30
田渊文
6
测试数据准备及验证
3
2011-03-30
2011-03-30
任可任
7
场景设计
2
2011-03-30
2011-03-31
任可任
测试执行
9
测试执行
16
2011-03-30
2011-04-05
王琦、张程
10
数据整理及分析
4
2011-04-05
2011-04-06
任可任、杨涛
测试总结
11
编写《测试报告》
4
2011-04-06
2011-04-07
任可任、杨涛
12
《测试报告》评审及修订
4
2011-04-07
2011-04-08

11 交付物
交付物名称
责任人
参与者
交付日期
性能测试计划
任可任
杨涛，任可任，王琦，张程
2011-03-25
性能测试脚本
任可任
杨涛，任可任，王琦，张程
2011-04-01
性能测试报告
任可任
杨涛，任可任，王琦，张程
2011-04-08
12 附件

第 16 页 / 共 16 页