性能测试方案模板.docx
《性能测试方案模板.docx》由会员分享，可在线阅读，更多相关《性能测试方案模板.docx（13页珍藏版）》请在冰豆网上搜索。
性能测试方案模板
XXX容灾系统性能测试
性能测试方案
文档资料信息
服务名称：
XX.XXX.XX.27~46（XXX应用服务器）
XXX.XXX.XX.123~24（XXX数据库）
项目经理：
XX
文档版本号：
1.0
服务阶段：
项目实施
文档版本日期：
准备者：
XX
准备日期：
审定者：
审定日期：
发送列表
发送者：
日期：
电话/传真：
接受者：
目的：
日期：
电话/传真：
审阅
版本历史
版本号：
版本日期：
修订者：
描述：
文件名：
1
2016-7-14
马鸿飞
服务器数
注意事项
内部传阅
1项目介绍
1.1测试背景
随着业务量和业务能力的拓展，为了防止XXX系统因事故无法使用，建立灾备系统
1.2测试目的
本次性能测试的目的是检测灾备系统的性能情况。
作为XXX的灾备系统，能够在事故发生后切换至灾备系统，能够稳定运行。
对该系统进行核心业务场景的性能测试。
希望在模拟生产环境的情况下，能够收集相应的系统参数，作为灾备系统评估的依据。
1.3参考文档
《XXX环境应用服务器列表清单》、《XXXdb清单v2》、《XXX环境网络拓扑图》
1.4缩略语和术语说明
性能测试：
在一定约束条件下（指定的软件、硬件和网络环境等）确定系统所能承受的最大负载压力的测试过程。
场景：
一种文件，用于根据性能要求定义在每一个测试会话运行期间发生的事件。
虚拟用户：
在场景中，LoadRunner用虚拟用户代替实际用户。
模拟实际用户的操作来使用应用程序。
一个场景可以包含几十、几百甚至几千个虚拟用户。
虚拟用户脚本：
用于描述虚拟用户在场景中执行的操作。
事务：
表示要度量的最终用户业务流程。
并发数：
单位时间内同时执行一种操作的用户数量
在线用户数：
访问被测应用的用户数量，单位时间内用户不会同时对被测服务器发送请求，产生压力
TPS：
TransactionPerSecond，每秒事务数量，单位是事务/秒
TRT:
TransactionResponseTime，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒
2测试范围
XXX灾备系统
2.1涉及系统
XXX灾备系统
3性能测试环境搭建
3.1生产环境拓扑图
3.2性能测试环境拓扑图
3.3测试设备列表
应用服务器37台，配置如下：
CPU个数16
CPU型号Intel（R）Xeon（R）CPUE7-4820@2.00GHz
内存：
82G
系统Linux
数据库服务器1台，配置如下：
CPU个数60
CPU型号Intel（R）Xeon（R）CPUE7-4870v2@2.30GHz
内存：
380G
系统Linux
数据库ORACLE 11g
3.4测试环境和生产环境差异
按照最接近生产系统结构的原则，因只有两台数据库服务器，至少有一台参与性能测试，所以本次性能测试按照实际生产环境1:
2比例缩小，也就是10台应用服务器，1台数据库服务器
因10台应用服务器对数据库服务器产生的压力太小，改为37台应用服务器和1台数据库服务器
3.5性能测试机配置
性能测试测试机1台，详情如下：
系统名称Microsoft®WindowsServer®2008Enterprise
处理器Intel（R）Xeon（R）CPUE7-4830@2.13GHz，2134Mhz，8个内核，8个逻辑处理器
内存16.0GB
备注：
压测机CPU使用率<50%内存<80%IOBUSY<50%磁盘使用率<90%网络带宽<30%
3.6性能测试工具
Loadrunner11
4性能测试条件准备
4.1准备工作
1、测试功能点全部通过功能测试，确保功能上没有问题
2、准备性能测试环境服务器：
A、应用服务器10台
B、数据库服务器1台
3、准备性能测试机1台，需要安装Loadrunner11并打通到应用服务器的网络
4、对于每个测试功能点，都要事先调试好相应脚本，并准备测试数据。
保证脚本能够成功回放，数据正确
5、创建测试场景，配置好各场景设置
6、测试过程中保存好脚本及分析结果，并规范的对脚本和分析结果命名
5性能测试方案
5.1性能测试策略
1、关键资源不处于阻塞状态
A、服务器CPU利用率<70%
B、物理内存利用率<80%
C、场景通过率>99.99%
2、组合多个场景并发测试
3、测试执行
采用阶梯方式，并发数按照5、10、15、20….逐步增加，直至在某一个并发数增加后TPS达到峰值，并再增加并发造成响应时间增加，事件通过率降低
5.2性能测试通过准则
1、达到性能要求，在要求并发数用户下，系统响应时间小于或者等于客户要求的响应时间
2、在长时间运行后，系统不崩溃，各功能正常。
3、服务器CPU、内存、等参数保持稳定
4、测试停止后，一段时间内占用资源可以正常释放
5.3测试业务模型
以下根据生产环境（2016年6月26日当日按照工作10小时数据估算值TPS=并发数/平均响应时间=日交易量*0.8/7200）
序号
业务名称
平均处理时间
并发数量
高峰时段
业务量/天
备注（估算TPS）
1
员工登录
1.5s
XX
9:
00~11:
00
XXX
XXX
2
新建客户
15s
XX
12:
00~14:
00
XXX
XXX
5.4测试场景设计
1、员工登录
用例编号
NMYC_001
验证功能
员工登录
测试目的
被测系统是否能够满足大并发用户数登录的要求
前置条件
员工账号、密码
并发用户数
2500
思考时间
0s
方法
逐步设置并发用户数为2500个，模拟用户登录系统的负载压力情况，进行15分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。
对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。
用例名称
并发数
期望响应时间（秒）
备注
员工登录
2500
<1.5s
2、新建客户
用例编号
NMYC_002
验证功能
新建客户
测试目的
被测系统能否满足大并发数新建客户的要求
前置条件
1、员工账号、密码
2、客户名称、客户证件号码、客户地址等
并发用户数
2500
思考时间
0s
方法
逐步设置并发用户数为2500个，模拟员工新建客户的负载压力情况，进行15分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。
对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。
用例名称
并发数
期望响应时间（秒）
备注
新建客户
2500
<15s
5.4.1第一轮测试
5.4.1.1场景设置
员工登录
5.4.1.2测试结果
Ø整体结果
Ø基准测试虚拟用户数与TPS关系趋势图
Ø基准测试虚拟用户数与处理时间关系趋势图
本次性能测试一共37台应用服务器，两台数据库服务器，压测30分钟
从压测图中可以看出，随着并发数增加（0-600）时间段（0:
00-8:
00）tps稳定上升，处理时间无太大变化
随着并发数增加（600-2500）时间段（8:
00-15:
00）TPS基本维持在2200—2300，处理时间随着并发数增加而增加
随着并发数增加（2500+）时间段（15:
00-20:
00）TPS呈现不规则跳动，处理时间也大幅度增加，同时错误事务数量变大，出现了接口异常和超时
因本次只压测了员工登录，门户部署的应用内存小于2.0G当TPS达到2300并发数最高为2500
5.4.2第二轮测试
5.4.2.1场景设置
新建客户
5.4.2.2测试结果
Ø整体结果
XXX
Ø基准测试虚拟用户数与TPS关系趋势图
XXX
Ø基准测试虚拟用户数与处理时间关系趋势图
Xxx
5.5测试数据要求
客户设备号、员工工号及密码
测试数据需求列表
序号
适用场景描述
所需资源描述
数量
备注
1
员工登录
员工工号及密码
2500
2
客户定位
在用设备号码（接入号）
2500
5.6监控内容
6测试计划
编号
任务
参与人员
开始日期
结束日期
1
熟悉被测试系统，确定典型事务
测试人员
开发人员
业务人员
2016-7-3
2016-7-4
2
搭建测试环境，录制典型事务的脚本，增强脚本
测试人员
开发人员
2016-7-5
2016-7-10
3
执行测试并收集相关数据
测试人员
2016-7-13
2016-7-13
4
数据分析
测试人员
2016-7-13
2016-7-15
5
编写测试报告
测试人员
2016-7-15
2016-7-15
7团队
容灾项目组
8风险
风险描述
风险发生的可能性
风险对项目影响
规避方法
目前容灾环境先要经过生产环境的CSB-DEP，若系统双活可能会造成大量流水重复事务通过率下降，导致测试失败
低
高
单独部署CSB-DEP服务
测试数据大量预占，造成并发无法继续增加
低
高
数据准备充足
随着压力增加，系统异常，造成服务请求中断或者超时
高
高
及时做好服务器监控
存在重大错误，以致测试无法继续，需要开发部进行额外的调试和修改才能继续
低
高
代码质量控制
硬件或网络环境出现故障
低
高
无
9通过标准
1、性能测试场景通过，并满足并发、响应时间等要求
2、系统资源消耗
服务器CPU利用率<70%
物理内存利用率<80%
场景通过率>99.99%
3、性能测试结束后一段时间内，资源（系统资源及数据资源）释放正常
10优化建议
XXX
升级会员 