性能测试计划模板.docx
《性能测试计划模板.docx》由会员分享，可在线阅读，更多相关《性能测试计划模板.docx（14页珍藏版）》请在冰豆网上搜索。
性能测试计划模板
XX银行手机银行客户端系统
性能测试计划
文档编号
保密等级
作者
最后修改日期
审核人
最后审批日期
批准人
最后批准日期
修订记录
日期
版本
修订说明
修订人
2012-02-13
V0.1
创建全文
目录
1.导言1
1.1背景2
2.测试目的2
2.1交易选取原则和业务配比3
2.2性能测试指标要求3
2.3交易吞吐量4
2.4交易响应时间4
2.5交易成功率4
2.6资源使用指标5
2.7测试资源5
2.7.1人员5
2.7.2工具5
2.8环境6
2.8.1网络扩扑图7
2.8.2软硬件配置7
3测试约束7
3.1入口和出口准则7
3.1.1入口准则8
3.1.2出口准则8
3.2暂停/再启动准则8
3.3通过/失败准则8
3.3.1通过准则8
3.3.2失败准则8
4策略描述8
4.1测试类型8
4.1.1基准测试9
4.1.2负载测试9
4.1.3稳定性测试9
4.2测试数据9
4.2.1参数数据9
4.2.2存量数据9
5测试方法10
5.1单业务测试10
5.1.1测试方法10
5.1.2测试目的10
5.2混合业务测试11
5.2.1测试方法11
5.2.2测试目的11
5.3疲劳测试11
5.3.1测试方法………………………………………………….………………………..……………….……..………………12
5.3.2测试目的……………………………………………………………….…………………………………..………………12
6测试风险12
7进度13
8交付物13
导言
1.1背景
手机客户端系统是在我行推出wap手机银行后，针对高端手机客户推出的在线金融服务系统，手机客户端系统与wap系统共用一套客户数据，传统业务业务逻辑一致，针对手机客户端独有的特点，推出了金融助手服务，主要包含了，商户搜索，在线购买机票，手机充值，理财计算器等特色功能。
由于客户端和wap手机银行共用一套客户数据，故wap手机银行的客户群是手机银行客户端系统潜在的使用者。
所以手机银行客户端系统的性能测试基于现有wap手机银行生产的存量数据进行，保证性能测试环境与将来生产环境相吻合。
测试目的
通过对手机银行客户端系统的性能测试实施，在测试范围内可以达到如下目的：
1、了解客户端系统在各种业务场景下的性能表现；
2、了解客户端业务系统的稳定性；
3、检验系统在异常业务场景下的容错能力；
4、通过各种业务场景的测试实施，为系统调优提供数据参考；
5、通过性能测试发现系统瓶颈，并进行优化。
6、预估系统的业务容量
交易选取原则和业务配比
手机银行客户端系统的性能测试交易选取原则如下：
1、覆盖日交易发生量累计占日交易总量80%的交易；
2、业务逻辑处理复杂的交易；
3、被测系统特殊性能关注点；
4、取WAP手机银行最新日交易量情况调整交易范围及比例
性能测试指标要求
本次性能测试需要测试的性能指标包括：
1、交易吞吐量：
后台主机每秒能够处理的交易笔数（TPS）
2、交易响应时间
3、并发交易成功率
4、批处理效率
5、资源使用指标：
前置和核心系统各服务器CPU占用率、内存占用率、I/O占用率；LoadRunner压力负载机CPU占用率、内存占用率
交易吞吐量
根据统计数据，恒丰银行网银系统当前生产环境高峰日交易总量为7万笔。
根据二八原则（80%的交易量发生在20%的时间段内），当前生产环境对主机的交易吞吐量指标要求为：
TPS_1≥70000*80%/（24*20%*3600）=3.2笔/秒
为获取系统主机的最大处理能力，在本次性能测试中可通过不断加压，让核心系统主机CPU利用率达到60%，记录此时的TPS值，作为新主机处理能力的一个参考值。
交易响应时间
本次性能测试中的交易响应时间是指由性能测试工具记录和进行统计分析的、系统处理交易的响应时间，用一定时间段内的统计平均值ART来表示。
本次性能测试中，对所有交易的ART指标要求为：
ART≤0.5秒
交易成功率
指测试结束时成功交易数占总交易数的比率。
交易成功率越高，系统越稳定。
对典型交易的场景测试，要求其并发交易成功率≥98%。
资源使用指标
在正常的并发测试和批处理测试中，核心系统服务器主机的资源使用指标要求：
CPU使用率≤80%
内存使用率≤80%
I/O使用率≤80%
2.7测试资源
2.7.1人员
1.项目经理：
2.测试负责人：
3.测试人员：
4.运维人员：
2.7.2工具
用途
工具
厂商/自产
版本
脚本编写
VuGen
HP
场景执行
Controller
HP
性能分析器
Analysis
HP
CPU、内存监控
Top/topas、sar
Linux/AIX
2.8环境
2.8.1网络拓扑图
暂时计划使用测试环境进行测试，拓扑图如下：
2.8.2软硬件配置
为了尽可能模拟真实的生产环境，本次测试在测试环境上执行，软硬件配置如下：
环境
资源
数量
配置
与生产环境差异
EWP服务器硬件环境
EWP服务
1
PCServer8
CPU：
2核，主频2.4GHz
内存：
16G
存储：
300G
IP地址：
10.1.91.4
有差异：
生产环境CPU为8核
EWP软件环境
EWP服务操作系统
1
CentOS5.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-UXB.11.31
无差别
APP服务器J2EE容器
1
Weblogic10.3.0.0
无差别
测试约束
入口和出口准则
入口准则
1、测试目的、测试指标均已明确；
2、测试环境已经就绪；
3、测试脚本已经编写并调试通过；
4、测试脚本已参数化；
5、测试数据已经准备；
6、负载机已经准备；
7、测试工具已经准备并已安装足够的License；
8、测试人员全部到位；
9、测试接口人已经明确；
10、测试计划通过评审；
以上条件必须全部满足。
出口准则
1、所有场景均已执行；
2、测试结果通过评审；
3、测试场景未执行完成但已经没有测试时间；
以上满足1、2属于正常退出，满足3属于异常退出。
暂停/再启动准则
1、测试环境出现问题导致测试无法继续进行；
2、测试数据不能及时准备就绪；
3、测试中出现的缺陷不能及时解决且影响后续的测试执行；
4、其它导致测试无法继续进行的情况出现；
以上条件满足其一测试可进入暂停状态。
导致测试暂停的问题得以解决即可重新启动测试执行。
通过/失败准则
通过准则
1、所有场景均已执行；
2、被测系统达到预期性能指标；
以上条件全部满足则测试通过。
失败准则
1、场景未能按计划执行；
2、场景变更未通过评审；
3、被测系统性能数据不满足指标需求；
4、因各种问题导致测试结果无效；
出现以上情况之一则测试失败。
策略描述
1、为了模拟更真实的生产环境，在基础测试阶段要采集2组数据：
-通过前置发送核心系统，得到核心系统处理业务的响应时间
-通过网银挡板，模拟核心系统返回，得到客户端系统业务响应时间
2、通过基础测试阶段得到的交易响应时间推算出混合场景的业务占比模型，从而通过测试得到最贴近生产环境下的测试结果；
本次性能测试在局域网环境内进行，测试服务包括两部分：
手机银行接入服务（EWP）,手机银行应用服务（APP）,对EWP服务器的资源使用情况进行监控，并获取相关性能指标（支持并发数，响应时间）；手机银行应用服务（支持并发数，响应时间）。
测试类型
本次测试的测试类型包括基准测试、负载测试、稳定性测试。
基准测试
基准测试是在系统无压力的情况下，通过对单交易进行多次迭代，获取该交易发送单笔请求的平均响应时间，为后续的负载测试提供基准参照。
测试共分为2种情况，第一种：
客户端系统将交易发送至核心，得到交易响应时间；第二种：
客户端系统通过挡板程序，得到系统自身的交易响应时间。
本次测试对所有普通联机交易执行基准测试。
负载测试
负载测试是模拟多用户同时向服务器发送请求，获取服务器对并发请求的处理能力，并通过不断有规律地改变请求压力，获取系统在不同压力下的处理效率及系统性能拐点。
稳定性测试
稳定性测试是对特定场景在特定压力下（一般选取相关场景性能拐点处的压力）的长时间（理论为7×24小时）运行，通过观察系统响应效率、交易成功率及主机资源变化情况，分析被测系统是否能够长时间稳定运行。
测试数据
参数数据
为了尽可能的模拟系统生产环境，所以JVM的初始堆栈大小、应用服务器的线程池、数据库连接池等系统配置，统一参考WAP手机银行生产环境配置。
存量数据
存量数据来自WAP手机银行实际生产系统，对生产数据进行脱敏处理，去除包括姓名、身份证号码、密码等敏感信息，并导入测试环境核心系统数据库。
基础数据的数据规模。
测试方法
测试方法包括单业务测试、混合业务测试、疲劳测试等等。
单业务测试
典型单业务测试，目的是对选择的每个典型业务在无压力情况下（无额外进程运行并占用系统资源）情况下，获取系统处理单业务的耗时，为下一步模拟多个用户、混合交易的性能测试提供一个基本数据参考。
单业务测试要达到以下目标：
●验证测试脚本及测试参数的正确性。
●获取系统处理单业务交易性能数据，主要是单业务交易平均响应时间。
测试方法
选择具有代表性的交易，对该交易进行多组用户并发测试：
并发用户数以梯度增量方式，分别为50、100、200、400、600、800、1000…，采用逐渐加压和释压方式，无思考时间和迭代延迟，持续运行5分钟，分别记录每组场景下的TPS,ART,CPU,内存平均值和交易成功率（排除各种参数设置不合理因素），根据并发数，TPS，ART数据，以横坐标为并发数，纵坐标为TPS绘制一个趋势图，以横坐标为并发数，纵坐标为ART绘制另一个趋势图，综合考虑，以TPS和ART出现拐点为最佳用户数，以某一项监控指标达到预期峰值为最大用户数。
最佳用户数为后期单业务的并发测试和疲劳测试提供依据。
或者选择具有代表性的交易:
最佳用户数：
并发用户数采用梯度增量方式，以较低用户数为起始，比如并发数30，每一分钟增加50人，直到增加到1000人或更多，无思考时间和迭代延迟，持续运行直到加载到全部负载，通过较大跨度的递增负载来观察在并发用户数递增的过程中TPS,ART,CPU,内存平均值和交易成功率（排除各种参数设置不合理因素）的变化，合并TPS和ART图，分析当ART出现拐点或TPS趋于平稳，此时的用户数为最佳用户数。
最大用户数：
在最佳用户基础上继续递增人数，当任一项新能指标达到了要求峰值，此时的用户数为最大用户数。
测试目标
这种测试是为了检查关键业务对应的应用程序模块是否存在代码上的并发性能问题，取融易通服务器（CPU、进程、内存等）数据进行分析，若单个业务的平均响应时间随着并发数量的增加而呈线性增长，则说明该关键业务对应的应用程序存在性能上的瓶颈。
此时应该协调相关的开发人员发现该关键业务的性能瓶颈，并进行性能调优，直到该关键业务的响应时间达到了可接受的增长趋势，再次进行并发测试。
混合业务测试
混合业务多用户测试是最典型也是最有效的性能测试手段，选择的混合业务测试按一定的交易占比，通过按照业务量不同的情况下进行用户数比分配模拟各种业务的并发向服务器端发送交易，获取各交易在比较接近真实生产场景的情况下的交易平均响应时间、服务器的交易吞吐量，同时监控服务器的资源状况，根据需要进行性能调优。
测试方法
混合业务测试按一定的交易占比进行测试，通过按照业务量不同的情况下进行用户数比分配模拟各种业务的并发向服务器端发送交易。
从而获取各交易在比较接近真实生产场景的情况下的交易平均响应时间、服务器的交易吞吐量，同时监控服务器的资源状况，进行性能资源优化。
测试目标
混合业务多用户测试是最典型也是最有效的性能测试手段，选择的混合业务测试按一定的交易占比，通过不同数量的并发用户向服务器端发送交易，获取各交易在比较接近真实生产场景的情况下的交易平均响应时间、服务器的交易吞吐量，同时监控服务器的资源状况，查看最大和最佳用户数，根据需要进行性能调优。
疲劳测试
持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
测试方法
通过单业务测试得出的交易响应时间，按照响应时间设置交易占比。
然后不断施加压力，观测系统的CPU使用率。
来判断系统所能承受的极限压力。
再根据此压力的并发数量，让场景持续运行时间（1小时、8小时）分别进行测试，各交易无思考时间、无迭代延迟时间。
获取核心主机TPS值、各典型交易的平均响应时间ART和性能监控数据，查看用户通过成功率和内存使用情况。
测试目标
通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
测试风险
风险编号
风险描述
风险发生可能性（高/中/低）
风险影响
（高/中/低）
责任人
规避方法
1
测试版本与生产上线版本不一致，造成测试风险
低
高
本次测试在UAT测试结束，程序代码封版之后进行，故不会有版本不一致带来的风险
2
在测试过程中业务变更带来的风险
低
中
本次测试在业务测试已经结束之后，不再接受新需求的前提下进行，故可以避免该风险点
3
测试会产生大量数据
中
中
由于性能测试的并发用户量大，而且要重复执行多次，所以会在系统中产生大量的数据，测试数据和现实数据不一致带来的风险。
进度
阶段
编号
任务
工作量（人日）
开始日期
结束日期
责任人
测试计划
1
《测试计划》编写
2
《测试计划》评审及修订
测试准备
3
测试脚本准备
4
测试环境准备
5
测试工具准备
6
测试数据准备及验证
7
场景设计
测试执行
9
测试执行
10
数据整理及分析
测试总结
11
编写《测试报告》
12
《测试报告》评审及修订
交付物
交付物名称
责任人
参与者
交付日期
性能测试计划
性能测试报告
升级会员 