系统压力测试方案.docx
- 文档编号:27635830
- 上传时间:2023-07-03
- 格式:DOCX
- 页数:11
- 大小:33KB
系统压力测试方案.docx
《系统压力测试方案.docx》由会员分享,可在线阅读,更多相关《系统压力测试方案.docx(11页珍藏版)》请在冰豆网上搜索。
系统压力测试方案
门诊压力测试案
文档修改历史
日期
版本
作者
修改容
审批人
发布日期
2016.04.20
V1.0
初稿
1.文档介绍
1.1.测试目的
本次压力测试目的是检测孕妇端系统的核心业务的性能情况。
为了保证后期在业务量不断增长的情况下系统后能够稳定运行,需要对核心业务场景的压力情况有充分了解。
因此,希望在模拟生产环境的情况下,模拟用户并发数,对系统核心业务进展压力测试,收集相应的系统参数,并最终作为系统稳定运行的依据。
编写本案的目的是指导本次性能测试有序的进展,相关人员了解本次压力测试。
1.2.读者对象
本案的预期读者:
工程负责人、测试人员和系统其他的相关人员。
1.3.参考资料
名称
是否可用
备注
1.4.术语与解释
Ø系统用户数:
使用该系统的总用户数;
Ø同时在线用户数:
在一定的时间围,最大的同时在线用户数;
Ø并发用户数:
在同一时间,并同时向效劳器发送请求数;
2.测试环境
模拟客户使用环境〔最好模拟客户实际使用的配置环境〕。
具体如下:
2.1.测试环境
网络环境:
Lan〔100M〕
硬件环境:
Ø应用效劳器
数量:
1台
配置:
型号、CPU、存等
Ø数据库效劳器
数量:
1台
配置:
型号、CPU、存等
Ø测试客户端
数量:
2台
配置:
型号〔戴尔〕、CPU〔3.2GHz〕、存〔4G〕等
软件环境:
Ø操作系统:
linux,Windows7
Ø应用效劳软件:
Tomcat6.
Ø数据库:
MySQL5.5
2.2.测试工具
jmeter使用HTTP/HTTPS协议。
主要思想是使用虚拟用户〔Virtualusers〕来模拟实际用户对系统施加压力。
模拟图如下:
3.测试需求
3.1.测试功能点
本次测试涉及到的模块为:
Ø登录功能
Ø完毕监护
Ø上传档案
Ø提交门诊
3.2.性能需求
1)登录系统平均响应时间小于等于5秒钟;
2)在线商品充值处理时间要小于等于2秒;
3)订单查询系统响应时间在3个月在3s之,超出3个月,可在2-10s之。
4.准备工作
4.1并发用户数计算
根据提供的数据,系统用户数为1600;2014年12月份总订单数量为160144笔订单,12月份顶峰日订单数量为9205笔订单,另外根据网吧提交次数,一天一家网吧平均提交28.8笔订单,那么,在顶峰日:
平均每天访问用户数量=顶峰日订单总数量/单个用户日平均提交的订单数量
=9205/28.8≈320
即平均每天访问用户数量320个;
平均并发用户数计算公式①C=nL/T
其中C是平均并发用户数,n是平均每天访问用户数,L是一天用户从登陆到退出的平均时间,T是考察时间长度〔一天多长时间有用户在使用系统〕;对于一个典型用户来说,一天之用户从登陆到退出系统的平均时间为4小时,在一天,用户在8小时使用该系统;那么平均并发用户数C=nL/T=320*4/8=160
并发用户数峰值:
②C1≈C+3*根号C=160+3*根号160=200
〔注:
公式①②遵循泊松分布理论〕
由此可以计算出当网吧用户数量到达16000家时对应的平均并发用户数和并发用户数峰值,如下列图所示:
系统名称
系统用户数
平均并发用户数
并发用户数峰值
系统a
1600个
160个
200个
系统b
16000个
1600个
2000个
〔注:
根据2012年淘宝报告显示,淘宝注册用户数为3.7亿,最顶峰时同时在线用户数为6000万,按照这个规律计算,网吧系统到达16000个用户时,最顶峰同时在线用户数为2500+〕
4.2业务分配
在线用户登录后,网吧业务包括:
游戏充值、查询记录、账户管理、资金管理,根据业务分配,游戏充值业务占总业务的60%,查询记录占30%,账户管理占用5%,资金管理占用5%,详见下列图:
业务名称
游戏充值
查询记录
账户管理
资金管理
业务占比
60%
30%
5%
5%
并发用户数峰值
1200个
600个
100个
100个
4.3脚本和环境
1)对登录功能、充值、查询功能进展功能测试,且功能测试全部通过;
2)测试环境效劳器:
开发搭建并保持和线上环境一致;
3)测试客户机:
既定的三台客户机,网IP为192.168.2.223和192.168.2.184,192.168.2.235,超出三台机器的需要,会另增测试客户机;
4)对于登录功能、充值和查询功能,事先录制好相应的测试脚本,包括参数化、关联等,准备好测试数据,并且调试好,脚本能够成功的回放,保证在测试的时候能够顺利的运行;
5)创立测试场景,并配置好每个场景的设置;
6)测试过程中保存好脚本和分析结果,并规的对脚本和分析结果等进展命名。
5.测试完成准那么
系统响应时间判断原那么如下:
1)系统业务响应时间小于2秒,判为优秀,用户对系统感觉很好;
2)系统业务响应时间在2-5秒之间,判为良好,用户对系统感觉一般;
3)系统业务响应时间超过10秒,判断为一般,用户体验不佳。
4)在长时间运行后,系统不崩溃,各功能正常;效劳器CPU,存,响应时间等参数保持稳定;场景运行停顿后,一段时间占用的资源可以正常释放。
6.测试风险
1)选择的业务流不具有代表性。
即选择的测试功能点经过负荷测试和长时间测试后不能重现系统问题,如存溢出,速度慢等问题;
选择测试功能点的原那么:
客户使用系统时经常操作的业务流,以及觉得反响比拟慢的几个功能模块;
2)不是在实际环境中的测试〔即模拟的测试环境和客户实际使用环境配置差异较大〕,由于测试环境的不同,测试结果和实际使用环境中的结果有一定的出入;
3)测试环境中的数据量比实际环境中使用一段时间后的数据量要少的多,系统目前的性能不能代表数据量增长后的性能。
7.测试设计谋略
7.1.组合测试用例策略
先按照单个场景进展并发测试,在组合多个场景进展长时间测试,即:
先单独执行登录功能测试,再组合登录、充值、查询,同时并发执行4个小时。
7.2.测试执行策略
在正常的生产数据下,采用阶梯式的式,分别使用并发用户1、10、50、100、200等进展测试。
每次增加虚拟用户数时,查看系统的性能参数变化,如果变化很大,可以加大虚拟用户的数量;另外,如果在某一个并发用户数,如100个并发用户测试时,发现性能下降,那么那么逐步减少并发数,以找出并发用户到达什么数目时,系统性能开场急剧下降。
8.业务模型
8.1场景启用模式
1)首页登录功能:
逐步加压模式
2)在线游戏充值功能:
逐步加压模式
3)订单查询功能:
逐步加压模式
8.2测试目标
测试功能
最大并发数
响应时间
事务通过率
CPU使用率
存使用率
错误率
登录
2000
<5s
>95%
<70%
<70%
<5%
订单查询
600〔3个月以下〕
<3s
>95%
<70%
<70%
<5%
600(3个月以上)
2-10
>95%
<70%
<70%
<5%
游戏充值
1200
<2s
>95%
<70%
<70%
<5%
8.3场景设计
1〕登录功能
测试目的:
验证网吧系统用户登录在逐渐增加虚拟用户数量的情况下,系统响应时间如变化以及系统响应时间分别是多少
前置条件:
注册并激活网吧系统用户账号;
法:
逐渐增加用户个数进展登录,获取平均响应时间和吞吐量
序号
功能
并发用户数
迭代次数
操作间隔
1
登录功能
5
1
3
2
登录功能
10
1
3
3
登录功能
50
1
3
4
登录功能
100
1
3
5
登录功能
150
1
3
6
登录功能
200
1
3
7
登录功能
500
1
3
8
登录功能
…….
1
3
2〕游戏充值
测试目的:
逐渐增加虚拟用户数量,获取游戏充值的平均响应时间以及逐渐增加负载的过程系统响应时间的变化,在用户数量到达峰值为多少时,系统的性能开场下降;
前置条件:
已注册好的网吧系统账号,已选择好的游戏充值商品;
法:
逐渐增加用户数量进展游戏充值,获取游戏充值的平均响应时间;
序号
功能
并发用户数
迭代次数
操作间隔
1
在线游戏充值
1
1
3
2
在线游戏充值
10
1
3
3
在线游戏充值
50
1
3
4
在线游戏充值
100
1
3
5
在线游戏充值
150
1
3
6
在线游戏充值
200
1
3
7
在线游戏充值
500
1
3
8
在线游戏充值
…….
1
3
9
在线游戏充值
1200
1
3
3〕订单查询
测试目的:
逐渐增加负载过程中,包支付充值的响应时间,在用户数量到达多少时,系统的性能开场下降;
前置条件:
已注册的网吧系统账号、账号中有足够的金额进展充值,已准备好的充值商品;
法:
逐渐增加用户个数,获取包充值的平均响应时间;
序号
功能
并发用户数
时间跨度
迭代次数
操作间隔
1
订单查询
5
1个月/3个月/1年
1
3
2
订单查询
10
1个月/3个月/1年
1
3
3
订单查询
50
1个月/3个月/1年
1
3
4
订单查询
100
1个月/3个月/1年
1
3
5
订单查询
150
1个月/3个月/1年
1
3
6
订单查询
200
1个月/3个月/1年
1
3
7
订单查询
500
1个月/3个月/1年
1
3
8
订单查询
…….
1
3
4〕组合场景
功能
并发用户数
迭代次数
运行时间
操作间隔
登录
2000
1
4小时
5分钟
游戏充值
1200
1
4小时
5分钟
订单查询
600
1
4小时
5分钟
9.测试报告输出
在网吧系统的压力测试完毕后,根据测试结果,将生成压力测试报告。
教育之通病是教用脑的人不用手,不教用手的人用脑,所以一无所能。
教育革命的对策是手脑联盟,结果是手与脑的力量都可以大到不可思议。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 压力 测试 方案