系统压力测试方案设计Word文档下载推荐.docx

1、4.2业务分配 74.3脚本和环境 75.测试完成准则 76.测试风险 87.测试设计策略 87.1.组合测试用例策略 87.2.测试执行策略 88.业务模型 98.1 场景启用模式 98.2测试目标 98.3场景设计 99.测试报告输出 121.文档介绍1.1.测试目的本次压力测试的目的是检测网吧系统的核心业务的性能情况。 为了保证后期在业务量不断增长的情况下系统后能够稳定运行，需要对核心业务场景的压力情况有充分了解。因此， 希望在模拟生产环境的情况下， 模拟用户并发数，对系统核心业务进行压力测试， 收集相应的系统参数，并最终作为系统稳定运行的依据，同时为系统调优提供指导。编写本方案的目的是

2、指导本次性能测试有序的进行，相关人员了解本次压力测试。1.2.读者对象本方案的预期读者是：项目负责人、测试人员和其他相关人员。1.3.参考资料名称是否可用备注1.4.术语与解释系统用户数：使用该系统的总用户数；同时在线用户数：在一定的时间范围内，最大的同时在线用户数;2.测试环境。具体如下:模拟客户使用环境（最好模拟客户实际使用的配置环境）2.1.测试环境被测系统环境需要和线上环境一致网络环境：Lan （100M ）硬件环境：应用服务器数量：1台配置：型号、CPU、内存等数据库服务器测试客户端3台软件环境：操作系统：Ubuntu 12， Windows 7， Windows XP应用服务软件：

3、Tomcat 6.037数据库：MySQL 5.52.2.测试工具LoadRunner 11 使用 HTTP/HTTPS 协议。主要思想是使用虚拟用户（Virtual users）来模拟实际用户对系统施加压力。 模拟图如下：业务系统 Business system3.测试需求3.1.测试功能点本次测试涉及到的模块为：登录功能在线商品充值订单查询32性能需求1） 登录系统平均响应时间小于等于 5秒钟；2） 在线商品充值处理时间要小于等于 2秒；3） 订单查询系统响应时间在 3个月内在3s之内，超出3个月，可在2-10S之内。4.准备工作4.1并发用户数计算根据提供的数据，系统用户数为 1600

4、; 2014年12月份总订单数量为160144笔订单,12月份高峰日订单数量为 9205笔订单，另外根据网吧提交次数，一天内一家网吧平均提交28.8笔订单，那么，在高峰日内：平均每天访问用户数量 =高峰日内订单总数量/单个用户日平均提交的订单数量=9205/28.8 320即平均每天访问用户数量 320个；平均并发用户数计算公式 C=nL /T其中C是平均并发用户数，n是平均每天访问用户数，L是一天内用户从登陆到退出的平均 时间，T是考察时间长度（一天内多长时间有用户在使用系统） ；对于一个典型用户来说，一天之内用户从登陆到退出系统的平均时间为 4小时，在一天内，用户在8小时内使用该系 统；那

5、么平均并发用户数 C= nL /T=320*4 /8=160并发用户数峰值： C1 C+3*根号C=160+3*根号160=200（注：公式遵循泊松分布理论）由此可以计算出当网吧用户数量达到 16000家时对应的平均并发用户数和并发用户数峰值，如下图所示：系统名称系统用户数平均并发用户数并发用户数峰值系统a1600 个160个200个系统b16000 个2000 个根据2012年淘宝报告显示，淘宝注册用户数为 3.7亿，最高峰时同时在线用户数为6000万，按照这个规律计算，网吧系统达到 16000个用户时，最高峰同时在线用户数为2500+）4.2业务分配在线用户登录后，网吧业务包括：游戏充值、

6、查询记录、账户管理、资金管理，根据业务分配，游戏充值业务占总业务的 60%，查询记录占30%，账户管理占用5%，资金管理占用5%,详见下图：业务名称游戏充值查询记录账户管理资金管理业务占比60%30%5%1200 个600个100个4.3脚本和环境1） 对登录功能、充值、查询功能进行功能测试，且功能测试全部通过；2） 测试环境服务器：开发搭建并保持和线上环境一致；3） 测试客户机：既定的三台客户机，内网 IP为192.1682223和192.1682 184，192.1682235,超出三台机器的需要，会另增测试客户机；4） 对于登录功能、充值和查询功能，事先录制好相应的测试脚本，包括参数化、

7、关联等，准备好测试数据，并且调试好， 脚本能够成功的回放，保证在测试的时候能够顺利的运行；5） 创建测试场景，并配置好每个场景的设置；6） 测试过程中保存好脚本和分析结果，并规范的对脚本和分析结果等进行命名。5.测试完成准则系统响应时间判断原则如下:1） 系统业务响应时间小于 2秒，判为优秀，用户对系统感觉很好；2） 系统业务响应时间在 2-5秒之间，判为良好，用户对系统感觉一般;3） 系统业务响应时间超过 10秒，判断为一般，用户体验不佳。4）在长时间运行后，系统不崩溃，各功能正常；服务器 CPU，内存，响应时间等参数保持稳定；场景运行停止后，一段时间内占用的资源可以正常释放。6.测试风险1

8、） 选择的业务流不具有代表性。即选择的测试功能点经过负荷测试和长时间测试后不能重现系统问题，如内存溢出，速度慢等问题；选择测试功能点的原则：客户使用系统时经常操作的业务流， 以及觉得反应比较慢的几个功能模块；2） 不是在实际环境中的测试（即模拟的测试环境和客户实际使用环境配置差别较大） 由于测试环境的不同，测试结果和实际使用环境中的结果有一定的出入；3） 测试环境中的数据量比实际环境中使用一段时间后的数据量要少的多， 系统目前的性能不能代表数据量增长后的性能。7.测试设计策略7.1.组合测试用例策略先按照单个场景进行并发测试， 在组合多个场景进行长时间测试， 即:先单独执行登录功能测试，再组合

9、登录、充值、查询，同时并发执行 4个小时。7.2.测试执行策略在正常的生产数据下，采用阶梯式的方式，分别使用并发用户 1、10、50、100、200等进行测试。每次增加虚拟用户数时，查看系统的性能参数变化，如果变化很大，可以加大虚拟用户的数量； 另外，如果在某一个并发用户数， 如100个并发用户测试时， 发现性能下降，那么则逐步减少并发数， 以找出并发用户达到什么数目时， 系统性能开始急剧下降。&业务模型8.1场景启用模式1） 首页登录功能：逐步加压模式2） 在线游戏充值功能：3） 订单查询功能：8.2 测试目标测试功能最大并发数响应时间事务通过率CPU使用率内存使用率错误率登录200095%

10、70%600（ 3个月以下）3s600（3个月以上）2-1012002s8.3场景设计1）登录功能测试目的：验证网吧系统用户登录在逐渐增加虚拟用户数量的情况下， 系统响应时间如何变化以及系统响应时间分别是多少前置条件：注册并激活网吧系统用户账号；方法：逐渐增加用户个数进行登录，获取平均响应时间和吞吐量序号功能并发用户数迭代次数操作间隔1532105041001506200750082）游戏充值逐渐增加虚拟用户数量， 获取游戏充值的平均响应时间以及逐渐增加负载的过程系统响应时间的变化，在用户数量达到峰值为多少时，系统的性能开始下降；已注册好的网吧系统账号，已选择好的游戏充值商品；逐渐增加用户数量进行游戏充值，获取游戏充值的平均响应时间;在线游戏充值93）订单查询逐渐增加负载过程中，钱包支付充值的响应时间， 在用户数量达到多少时， 系统的性能开始下降；已注册的网吧系统账号、账号中有足够的金额进行充值，已准备好的充值商品；逐渐增加用户个数，获取钱包充值的平均响应时间；时间跨度1个月/3个月/1年4）组合场景运行时间4小时5分钟6009.测试报告输出在网吧系统的压力测试结束后，根据测试结果，将生成压力测试报告。