系统压力测试方案素材.doc

门诊压力测试方案 文档修改历史 日期 版本 作者 修改内容 审批人 发布日期 2016.04.20 V1.0 初稿 目 录 1. 文档介绍 3 1.1.测试目的 3 1.2.读者对象 3 1.3.参考资料 3 1.4.术语与解释 3 2. 测试环境 3 2.1. 测试环境 4 2.2. 测试工具 4 3. 测试需求 5 3.1. 测试功能点 5 3.2. 性能需求 5 4. 准备工作 5 4.1 并发用户数计算 6 4.2 业务分配 7 4.3 脚本和环境 7 5. 测试完成准则 7 6. 测试风险 8 7. 测试设计策略 8 7.1. 组合测试用例策略 8 7.2. 测试执行策略 8 8. 业务模型 9 8.1 场景启用模式 9 8.2 测试目标 9 8.3 场景设计 9 9. 测试报告输出 12 文档介绍 1.1.测试目的 本次压力测试目的是检测孕妇端系统的核心业务的性能情况。为了保证后期在业务量不断增长的情况下系统后能够稳定运行，需要对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为系统稳定运行的依据。 编写本方案的目的是指导本次性能测试有序的进行，相关人员了解本次压力测试。 1.2.读者对象 本方案的预期读者：项目负责人、测试人员和系统其他的相关人员。 1.3.参考资料 名称 是否可用 备注 1.4.术语与解释 系统用户数：使用该系统的总用户数； 同时在线用户数：在一定的时间范围内，最大的同时在线用户数； 并发用户数：在同一时间内，并同时向服务器发送请求数； 测试环境 模拟客户使用环境（最好模拟客户实际使用的配置环境）。具体如下： 测试环境 网络环境：Lan（100M） 硬件环境： 应用服务器 数量：1台 配置：型号、CPU、内存等 数据库服务器 数量：1台 配置：型号、CPU、内存等 测试客户端 数量：2台 配置：型号（戴尔）、CPU（3.2GHz）、内存（4G）等 软件环境： 操作系统：linux，Windows 7 应用服务软件：Tomcat 6.037 数据库：MySQL 5.5 测试工具 jmeter使用HTTP/HTTPS协议。 主要思想是使用虚拟用户（Virtual users）来模拟实际用户对系统施加压力。 系统名称 系统用户数 平均并发用户数 并发用户数峰值 系统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 脚本和环境 对登录功能、充值、查询功能进行功能测试，且功能测试全部通过； 测试环境服务器：开发搭建并保持和线上环境一致； 测试客户机：既定的三台客户机，内网IP为23 和84，35，超出三台机器的需要，会另增测试客户机； 对于登录功能、充值和查询功能，事先录制好相应的测试脚本，包括参数化、关联等，准备好测试数据，并且调试好，脚本能够成功的回放，保证在测试的时候能够顺利的运行； 创建测试场景，并配置好每个场景的设置； 测试过程中保存好脚本和分析结果，并规范的对脚本和分析结果等进行命名。 测试完成准则 系统响应时间判断原则如下： 系统业务响应时间小于2秒，判为优秀，用户对系统感觉很好； 系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉一般； 系统业务响应时间超过10秒，判断为一般，用户体验不佳。 在长时间运行后，系统不崩溃，各功能正常；服务器CPU，内存，响应时间等参数保持稳定；场景运行停止后，一段时间内占用的资源可以正常释放。 测试风险 选择的业务流不具有代表性。即选择的测试功能点经过负荷测试和长时间测试后不能重现系统问题，如内存溢出，速度慢等问题； 选择测试功能点的原则：客户使用系统时经常操作的业务流，以及觉得反应比较慢的几个功能模块； 不是在实际环境中的测试（即模拟的测试环境和客户实际使用环境配置差别较大），由于测试环境的不同，测试结果和实际使用环境中的结果有一定的出入； 测试环境中的数据