性能测试计划.docx
- 文档编号:25228882
- 上传时间:2023-06-06
- 格式:DOCX
- 页数:13
- 大小:51.58KB
性能测试计划.docx
《性能测试计划.docx》由会员分享,可在线阅读,更多相关《性能测试计划.docx(13页珍藏版)》请在冰豆网上搜索。
性能测试计划
XXXXXX
XXXXX系统性能测试计划
用户验收测试平台XXXXX
文档编号:
XXXXXX
日期:
XXXX-XX-XX
文档修订记录
版本号
日期
撰写人
审核人
批准人
变更摘要&修订位置
目录
1项目概述4
1.1项目背景4
1.2测试目的4
1.3缩略语4
2系统架构4
2.1系统逻辑架构4
2.1.1网络体系结构图4
2.1.2逻辑体系结构图5
2.2系统功能描述5
3测试计划6
3.1测试目标6
3.1.1测试需求及功能点6
3.1.2测试范围6
3.1.3测试环境6
3.2测试工具7
3.3测试方法7
3.3.1场景设计8
3.3.2监控策略8
3.3.3关键指标8
3.4时间安排9
3.5测试进入/退出标准9
3.5.1进入标准9
3.5.2退出标准10
3.6测试中断标准10
3.7测试恢复标准10
3.8约束和假设10
4.风险分析10
5.测试交付物11
6.参考文档12
1项目概述
1.1项目背景
XXXXXXX。
1.2测试目的
测试的目的和目标是:
在XXXX提供XXXXX的测试环境中,测试方运用性能测试工具对XXXXX系统产生模拟真实使用环境的压力负载,重现缺陷发生状态,并监控的客户端和服务器性能指标,最终判断性能缺陷所属系统业务模块。
1.3缩略语
词汇
相关描述
Loadrunner
测试工具,用来编写测试脚本和产生压力负载,由惠普公司出品
OracleIAS
OracleInternetApplicationServer,中间件。
HPSuperdome
惠普公司生产,高性能服务器
2系统架构
2.1系统逻辑架构
2.1.1网络体系结构图
系统采用B/S架构模式,客户端通过OracleIas中间件访问数据库。
中间件和数据库分别部署在两台HPSuperdome服务器上。
2.1.2逻辑体系结构图
XXXXX
2.2系统功能描述
XXXXX。
3测试计划
3.1测试目标
此次性能测试的具体目标为:
1.开发正确、有效的软件性能测试脚本,模拟用户操作行为,作为测试有效实施的基础;
2.通过此次性能测试,判断XXXX系统性能缺陷存在的所属业务模块,找到系统的低效进程。
3.1.1测试需求及功能点
现有XXXXX系统在月末运行期间,经常出现系统性能下降,业务响应时间增加,并且发现某一JAVA进程持续占用CPU达到100%,为了准确定位系统性能缺陷并为系统修改提供依据,分阶段针对系统各业务模块各功能点,进行本次性能测试。
3.1.2测试范围
经初步判断,出现性能缺陷模块为XXXX系统的XXXX模块这几个使用频繁、业务处理量大的模块。
由于测试环境中XXX两个模块的业务还存在问题,为保证测试进度,本次测试的范围为XXX系统的XXXX模块。
XXXX系统日常运行的基本业务为新增、查询、修改等操作。
因此将本次性能测试的重点确定为被测模块的新增、查询、修改的典型业务。
另外由于XXXX模块的新增、修改与XXXX模块的新增都存在功能缺陷,所以本次计划不进行这个功能的性能测试。
3.1.3测试环境
硬件环境
硬件类型
IP地址
CPU数
内存数
用途
HPsuperdome
XXXXX
8
64G
中间件服务器
HPsuperdome
XXXXX
8
64G
数据库服务器
软件环境
软件类型
软件版本
操作系统
HPUX11.11
中间件
oracleias(10.12)
数据库
Oracle10g(10.2.0.2)
人力资源环境
公司
角色
姓名
人员职责
XXXXX
XXXXX
配合协调测试工作
配合协调测试工作
XXXXX
XXXXX
测试组长
XXXXX
测试工程师
XXXXX
测试工程师
3.2测试工具
本次测试使用的测试工具为HP公司的性能测试工具LoadRunnerv9.0。
3.3测试方法
由于本次测试的目的是要发现产生性能缺陷的模块,而由于各模块中的业务较多,因此如何快速准确定位到产生性能缺陷的模块成为本次测试的难点。
为了解决该难点我们采用了以下的测试方法:
1.由于本次测试涉及的业务较多,因此我们采取分阶段,分优先级的测试方法进行测试。
首先将本次测试分为三个阶段。
第一阶段选取使用频率高,逻辑复杂的业务作为测试的重点,由于以上业务是最有可能产生性能缺陷的,因此在这个阶段发现性能缺陷模块的概率最高。
第二阶段选取使用频率中等,逻辑复杂度一般的业务作为测试的重点。
第三阶段选取剩余的业务作为重点。
以上的测试阶段划分保证了最有可能产生性能缺陷的业务会在最早的时间进行测试,使得可以在最短的时间内完成测试目标。
2.对于每个阶段的测试,我们采取相同模块同类业务合并的测试方法进行测试。
即首先按模块对业务进行分类,然后在相同模块中,选取业务中相似操作的业务组合成场景,发现问题场景后,再对其中的每个单业务进行测试,从而定位到产生性能缺陷的业务。
这种方法即保证的测试质量,又节省了测试时间
3.根据XXXXXX系统日常运行情况,模拟日常使用用户数,针对不同功能模块进行性能测试。
监控中间件服务器的CPU性能指标,如果中间件服务器的CPU占用率持续接近100%,然后停止运行场景。
假使CPU占用率下降则所测试场景对应模块不存在性能缺陷;假使CPU使用率没有下降的趋势,维持在接近100%的状况,则需要分解该模块测试场景,进行单业务负载测试,判断对应模块是否存在性能缺陷
3.3.1场景设计
本次性能测试采取基准测试、混合业务负载测试、单业务负载测试的顺序来执行。
这样做的优势在于,混合负载测试可以将系统性能缺陷定位在模块范围内,单业务负载测试则在模块范围内定位性能缺陷到某一功能点。
基准测试
检查每个业务的基准响应时间,意思是在系统整体空闲(无额外进程运行并占用系统资源)时,单用户运行业务操作多次,获取该业务的平均响应时间,检查各参测系统的基础性能指标。
混合业务负载测试
将同一个模块的不用业务组合成同一个场景进行负载压力测试,平均分配并发用户,模拟系统日常使用用户数,监控中间件服务器CPU使用率是否持续达到100%,判断是否出现性能缺陷。
单业务负载测试
在将系统缺陷定位到模块后,针对该模块的不同业务操作,设计单业务负载测试场景,将系统缺陷进一步定位到某一只交易。
3.3.2监控策略
本次性能测试将使用LoadRunner监控业务的性能指标及主机的性能情况,为发现性能缺陷提供准确的参考数据。
3.3.3关键指标
在进行性能测试的同时,用测试工具对应用服务器资源进行监控。
监控系统资源指标,选取有意义的数据进行分析。
下面列出常用的一些参考指标
UNIX性能资源
度量
描述
CPUutilization
CPU的使用时间百分比
Diskrate
磁盘传输速率
Incomingpacketsrate
每秒钟传入的以太网数据包数
Interruptrate
每秒内的设备中断数
Outgoingpacketsrate
每秒钟传出的以太网数据包数
Page-inrate
每秒钟读入到物理内存中的页数
Page-outrate
每秒钟写入页面文件和从物理内存中删除的页数
Pagingrate
每秒钟读入物理内存或写入页文件的页数
Swap-inrate
正在交换的进程数
Swap-outrate
正在交换的进程数
SystemmodeCPUutilization
在系统模式下使用CPU的时间百分比
UsermodeCPUutilization
在用户模式下使用CPU的时间百分比
3.4时间安排
时间段
统计
具体任务
执行人员
人员职责
4工作日
业务筛选
筛选典型业务
1工作日
编写测试计划
根据筛选编写测试计划
3工作日
编写测试方案
运维方确定测试场景
测试方编写测试方案
2工作日
测试准备
编辑和录制XXXXX测试脚本
2工作日
测试准备
完成XXXXX测试脚本
2工作日
测试执行
执行完成基准测试场景
4工作日
测试执行
执行混合业务测试场景
2工作日
测试准备
测试准备
3工作日
执行测试
执行测试
2工作日
分析测试结果和编写测试报告
进行测试结果分析和编写测试报告
3.5测试进入/退出标准
3.5.1进入标准
以下条件具备后,用户验收测试平台XXXXX可以进行本次性能测试:
1)测试环境部署完毕(包括应用服务器、中间件、数据库、客户端)
2)测试范围内模块功能完善
3)数据库测试数据准备完毕
4)运维方提供拥有对应操作权限的操作用户
5)数据库中已具备与日常生产环境同级别的数据量,可以保证性能测试结果的准确性
3.5.2退出标准
本次性能测试的退出标准为:
必要的性能测试用例执行率达100%,获得被测系统性能数据,可以进行性能数据分析。
3.6测试中断标准
如果发生业务功能问题,并在一定时间段内无法修复,性能测试将被中断;
测试负载机不能访问被测系统,则性能测试中断;
3.7测试恢复标准
由业务功能问题引起的性能测试中断,将在功能被修复后恢复测试。
由测试负载机不能访问被测系统引起的测试中断,在测试负载机可以访问被测系统后测试恢复。
3.8约束和假设
1.本次测试只对XXXXX提供的系统进行负载压力测试,XXXXX不对XXXXX提供的数据和记录的真实性和准确性进行评估。
2.本次测试不包括:
被测系统环境的软硬件系统搭建;被测系统(生产环境)的数据备份、垃圾数据清除、数据恢复;被测系统(生产环境)应急方案的编制;因被测系统的软件升级、缺陷修复、支撑平台变更而进行的再次测试;以及被测系统的性能优化。
3.因现有环境中的被测系统功能并不全部完善,不完善模块不在本次测试的范围内,有可能系统性能缺陷存在于本次测试范围外的模块中。
4.风险分析
风险因素
可能结果
可能发生时间
风险
级别
应对措施
工具缺陷
测试工具和监控工具无法全部支持信贷业务系统的测试和监控
随时
中
评估被测系统,分析所有需求。
通过其它工具实现对需求的支持程度。
测试数据的准备备份及恢复无法正常完成
测试过程中数据用尽或不满足测试需求,将导致测试无法实施。
测试执行时
高
运维方配合完成数据的准备、备份和恢复
测试环境有其他用户连接进行操作,服务器产生性能缺陷
a)测试方获得最大负载压力与实际最大负载有差距
b)服务器出现性能缺陷的现象,运维方定位性能缺陷模块并非真正性能缺陷的模块
测试执行时
高
测试方进行负载测试时,保证测试环境无其他连接和用户操作
测试服务器访问状态不稳定
测试准备和测试执行中断,测试计划时间延后
随时
高
保证测试期间测试环境访问畅通
5.测试交付物
步骤
测试实施内容
阶段提交物
测试准备阶段
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
进行数据分析并出具性能测试评估报告
6.参考文档
《XXXXX.doc》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 性能 测试 计划