系统压力测试方案.docx
《系统压力测试方案.docx》由会员分享，可在线阅读，更多相关《系统压力测试方案.docx（11页珍藏版）》请在冰豆网上搜索。
系统压力测试方案
网吧系统压力测试方案
文档修改历史
日期
版本
作者
修改内容
审批人
发布日期
2014.10.13
V1.0
初稿
2015.01.20
V2.0
1.文档介绍
1.1.测试目的
本次压力测试的目的是检测网吧系统的核心业务的性能情况。
为了保证后期在业务量不断增长的情况下系统后能够稳定运行，需要对核心业务场景的压力情况有充分了解。
因此，希望在模拟生产环境的情况下，模拟用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为系统稳定运行的依据，同时为系统调优提供指导。
编写本方案的目的是指导本次性能测试有序的进行，相关人员了解本次压力测试。
1.2.读者对象
本方案的预期读者是：
项目负责人、测试人员和其他相关人员。
1.3.参考资料
名称
是否可用
备注
1.4.术语与解释
系统用户数：
使用该系统的总用户数；
同时在线用户数：
在一定的时间范围内，最大的同时在线用户数；
2.测试环境
模拟客户使用环境（最好模拟客户实际使用的配置环境）。
具体如下：
2.1.测试环境
被测系统环境需要和线上环境一致
网络环境：
Lan（100M）
硬件环境：
应用服务器
数量：
1台
配置：
型号、CPU、内存等
数据库服务器
数量：
1台
配置：
型号、CPU、内存等
测试客户端
数量：
3台
配置：
型号、CPU、内存等
软件环境：
操作系统：
Ubuntu12，Windows7，WindowsXP
应用服务软件：
Tomcat6.037
数据库：
MySQL5.5
2.2.测试工具
LoadRunner11使用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.测试报告输出
在网吧系统的压力测试结束后，根据测试结果，将生成压力测试报告。
升级会员 