系统压力测试方案
-门诊压力测试案文档修改历史日期版本作者修改容审批人发布日期V1.0初稿. z.-目 录1.文档介绍31.1.测试目的31.2.读者对象31.3.参考资料31.4.术语与解释32.测试环境32.1.测试环境42.2.测试工具43.测试需求53.1.测试功能点53.2.性能需求54.准备工作54.1 并发用户数计算64.2 业务分配74.3 脚本和环境75.测试完成准则76.测试风险87.测试设计策略87.1.组合测试用例策略87.2.测试执行策略88.业务模型98.1场景启用模式98.2 测试目标98.3 场景设计99.测试报告输出12. z.-1. 文档介绍1.1.测试目的本次压力测试目的是检测孕妇端系统的核心业务的性能情况。为了保证后期在业务量不断增长的情况下系统后能够稳定运行，需要对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟用户并发数，对系统核心业务进展压力测试，收集相应的系统参数，并最终作为系统稳定运行的依据。编写本案的目的是指导本次性能测试有序的进展，相关人员了解本次压力测试。1.2.读者对象 本案的预期读者：工程负责人、测试人员和系统其他的相关人员。1.3.参考资料名称是否可用备注1.4.术语与解释Ø 系统用户数：使用该系统的总用户数；Ø 同时在线用户数：在一定的时间围，最大的同时在线用户数；Ø 并发用户数：在同一时间，并同时向效劳器发送请求数；2. 测试环境模拟客户使用环境最好模拟客户实际使用的配置环境。具体如下：2.1. 测试环境 网络环境：Lan100M硬件环境：Ø 应用效劳器数量：1台配置：型号、CPU、存等Ø 数据库效劳器数量：1台配置：型号、CPU、存等Ø 测试客户端数量：2台配置：型号戴尔、CPU3.2GHz、存4G等软件环境：Ø 操作系统：linu*，Windows 7Ø 应用效劳软件：Tomcat 6.Ø 数据库：MySQL 5.52.2. 测试工具jmeter使用HTTP/HTTPS协议。主要思想是使用虚拟用户Virtual users来模拟实际用户对系统施加压力。模拟图如下：3. 测试需求3.1. 测试功能点本次测试涉及到的模块为：Ø 登录功能Ø 完毕监护Ø 上传档案Ø 提交门诊3.2. 性能需求1) 登录系统平均响应时间小于等于5秒钟；2) 在线商品充值处理时间要小于等于2秒；3) 订单查询系统响应时间在3个月在3s之，超出3个月，可在2-10s之。4. 准备工作4.1 并发用户数计算 根据提供的数据，系统用户数为1600；2021年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 并发用户数峰值：C1C+3*根号C=160+3*根号160=200注：公式遵循泊松分布理论 由此可以计算出当网吧用户数量到达16000家时对应的平均并发用户数和并发用户数峰值，如以下图所示：系统名称系统用户数平均并发用户数并发用户数峰值系统a1600个160个200个系统b16000个1600个2000个 注：根据2021年淘宝报告显示，淘宝注册用户数为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%订单查询6003个月以下<3s>95%<70%<70%<5%600(3个月以上)2-10>95%<70%<70%<5%游戏充值1200<2s>95%<70%<70%<5%8.3 场景设计1登录功能测试目的：验证网吧系统用户登录在逐渐增加虚拟用户数量的情况下，系统响应时间如变化以及系统响应时间分别是多少前置条件：注册并激活网吧系统用户账号；法：逐渐增加用户个数进展登录，获取平均响应时间和吞吐量序号功能并发用户数迭代次数操作间隔1登录功能5132登录功能10133登录功能50134登录功能100135登录功能150136登录功能200137登录功能500138登录功能.132游戏充值测试目的：逐渐增加虚拟用户数量，获取游戏充值的平均响应时间以及逐渐增加负载的过程系统响应时间的变化，在用户数量到达峰值为多少时，系统的性能开场下降；前置条件：已注册好的网吧系统账号，已选择好的游戏充值商品；法：逐渐增加用户数量进展游戏充值，获取游戏充值的平均响应时间； 序号功能并发用户数迭代次数操作间隔1在线游戏充值1132在线游戏充值10133在线游戏充值50134在线游戏充值100135在线游戏充值150136在线游戏充值200137在线游戏充值500138在线游戏充值.139在线游戏充值1200133订单查询测试目的：逐渐增加负载过程中，包支付充值的响应时间，在用户数量到达多少时，系统的性能开场下降； 前置条件：已注册的网吧系统账号、账号中有足够的金额进展充值，已准备好的充值商品；法：逐渐增加用户个数，获取包充值的平均响应时间；序号功能并发用户数时间跨度迭代次数操作间隔1订单查询51个月 /3个月 /1年132订单查询101个月 /3个月 /1年133订单查询501个月 /3个月 /1年134订单查询1001个月 /3个月 /1年135订单查询1501个月 /3个月 /1年136订单查询2001个月 /3个月 /1年137订单查询5001个月 /3个月 /1年138订单查询.134组合场景功能并发用户数迭代次数运行时间操作间隔登录200014小时5分钟游戏充值120014小时5分钟订单查询60014小时5分钟9. 测试报告输出在网吧系统的压力测试完毕后，根据测试结果，将生成压力测试报告。教育之通病是教用脑的人不用手，不教用手的人用脑，所以一无所能。教育革命的对策是手脑联盟，结果是手与脑的力量都可以大到不可思议。. z.
