性能测试计划XX项目Word下载.docx

1、7. 测试结束标准 78. 附录I： 78.1 性能计数器 78.2 WEB服务器 108.3 数据库 12性能测试计划1. 简介 目的此处描述本次测试的目的是什么，比如验证系统设计的性能目标。定义、首字母缩写词和缩略语此处描述本计划中用到的专业术语定义。范围本次测试覆盖的范围参考文献 此处列出本计划相关的文档，包含数据来源以及其他参考2. 测试准备系统性能要求分析一般的性能要求包括：系统容量：系统最大容纳多少个用户注册。访问数：同时访问系统的用户数。并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。响应时间：用户提交一个操作到得到响应的

2、时间间隔。性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。 在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算： （真实用户数每个真实用户请求数）/（总请求响应时间+真实用户总思考时间）=（虚拟用户数每用户请求个数）/（总请求响应时间+虚拟用户总思考时间）=吞吐量。测试数据准备数据分析可以参考以下方式：历史数据分析有助于数据量级的确

3、定。从历史数据入手，找出高峰期数据量。从其他相似或者相同系统入手，进行数据分析，找出高峰期数据量。无历史或者相关系统可以参考的时候，就要对系统的性能数据进行估算，包含系统容量，并发数等数据，估算以后给相关人员进行评审或者修订以后，按照大家同意的性能指标进行测试。测试数据最好和真实数据相同，如果能够获得真实系统运行3个月的数据，我们就可以在此基础上进行性能测试。测试数据最重要的是要达到真实环境运行下的数据量级。下面是某一个系统一年的数据量估算。数据对象 数据量 计算方法 用户 8000重要通知记彔 200000 新建通知记彔: 800个单位*250天，一天一条通知,共计200000条通知，每条通

4、知发送给10个接收人 回复通知记彔 400000 回复通知记彔： 800单位*2条*250天=400000条回复记彔 转发通知记彔 12500 转发通知记彔： 1条通知*转发给5个单位*每个单位有20个人*50%（平均只需转发一半人）*250天（每天需要转发一条通知）=12500 发文 800个单位*250天，一天2篇发文,共计400000条发文 收文 800个单位*250天，一天2篇收文,共计400000条通知 效能日报 800个单位*250天，一天新建2个日报：共计400000条日报，每个日报发给10个接收人 信息上报 800个单位*250天，一天上报1条信息：共计200000条上报信息

5、督察督办 40000 800个单位*250天，每5天新建1条记彔：共计40000条记彔 测试环境准备测试环境要求尽量和真实环境相同，至少要求服务器配置和网络带宽和拓扑结构应该相似。主要内容：服务器数量和配置，操作系统和数据库版本，软硬件部署等。用途硬件配置软件配置Web服务器CPU 内存 硬盘操作系统 IE版本 数据库服务器测试客户端其他配置网络或子网基于TCP/IP协议的局域网结构，千兆带宽，防火墙需要开放服务端口和管理服务端口测试工具选择选用jmeter作为性能压测工具，服务器端采用nmon/zabbix 监控服务器端资源占用3. 测试策略 对于一个特定的业务系统，用户一般会分散在一天的各

6、个时间段进行访问。在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。例如对于公文处理子系统而言，可能就存在短时间内大量用户查看并办理某条公文的情况。 在进行性能测试时，应当使用“考虑最坏情况的原则”。也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能和页面是否能够满足性能的要求，系统的响应时间是否过长。另一方面，系统性能的验证必须做到“覆盖全面”。虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在进行性能测试和优化时，不能忽略这

7、些功能，编制测试用例时也不能仅仅选择最常用功能。例如可能所有的用户都会访问我的通知列表，但是一般只有5%的用户会使用通过系统设置模块查找某个用户的信息；但是在测试时，我们并不能因为查看用户信息功能的使用频率相对较少，而忽略掉这项功能的测试。测试场景测试场景的选择和系统的具体业务相关。计划制定者一定对系统的业务十分了解。测试场景从整个业务系统分离出来，一般可以参考以下方法： 以前的系统或者其他类似业务系统的数据参考 相关项目文档关于场景的描述场景选择的一个策略可以是按照对系统性能影响的程度，以操作响应时间多少为序。场景选择要包含系统所有能够影响性能的操作，这些影响主要有： 和其他系统有交互的操作

8、，要等待其他系统或者组件返回结果的操作：第三方接口的使用，合成，识别等 本身存在后台处理的业务：后台处理耗时的业务（评分，更新排行榜等），数据库查询等 使用缓存信息的操作 设计场景的时候要考虑思考时间。在用户真实使用环境中，用户操作不同功能之间并不是连续不断的，而是在不同步骤之间有所延迟，称之为“思考时间”。在设计用例时，应当模拟实际用户使用系统的方式，在不同的操作步骤中加入用户的“思考时间”，才能够模拟真实的压力情况。测试场景要说明覆盖了哪些场景，没有覆盖到哪些场景，为什么没有覆盖。测试场景一步骤说明备注：Action、平均响应时间（S）1打开主界面Action：访问首页（FWSY）；52输

9、入用户名密码（需进行参数化），登录系统，进入首页登陆（DL）；3点击“我的通知”标签，进入通知列表页面进入通知列表（JRTZLB）；4在我的通知上点击已收通知标题链接，查看通知（重要通知）查看通知（CKTZ）；在我的通知上点击已收通知的“回复”链接，进入回复界面进入回复界面（JRHFJM）；6在通知回复界面上填写回复内容并提交回复通知（HFTZ）；测试场景二负载分配策略场景确定以后，就要确定各个场景的比例数。各个场景所占比例的多少可以根据以下方法进行确定： 历史数据统计 其他系统参考 如果是一个全新的系统，需要测试人员估计一个比例以后和项目组讨论确定。 服务器上总的负载确定以后，需要在客户端进

10、行压力分配，就是各个测试机上运行多少和什么样的测试场景：和具体的网络条件以及机器配置相关。 计划的负载下，性能达到设计要求以后，可以持续增加系统的压力，一直到瓶颈出现，可以为系统性能的提高提出改进方向。总计192.168.102850201404. 性能数据记录和分析 根据系统性能要求，记录需要的数据，可以对以下数据进行记录和分析：被测系统 各个主要Action的响应时间，在自动加载压力测试的同时，人工检查各项数据是否和自动记录的数据相同。 内存、CPU、虚拟内存、句柄、线程，可以使用操作系统的性能计数器来记录这些数据，或者测试工具自己可以记录。 可记录不同压力下各种操作响应时间的变化。比如1

11、00路200路500路下的各个操作的响应时间分布情况，内存、CPU使用情况等，以分析压力的增加对系统性能的影响。 在压力不断增大的情况下，找出响应超时的操作，对这些操作超时进行详细分析，给性能改进提出意见，最好能够指出瓶颈所在，比如是数据库、网络或者CPU原因引起。下图是压力倍数和处理器时间的关系：说明在3倍压力的情况下处理器时间缩小，说明在其它的部分已经出现性能瓶颈，不需要太多的处理器时间来处理事件。 出现性能瓶颈的时候，识别出是哪个场景不符合，着重测试这个场景性能拐点出现的条件。 数据记录可以采取采样的方式进行，也可以采取线型记录的方式全部记录，根据系统的具体需要以及工具的功能而定。服务器

12、服务器的数据主要考察CPU，内存，虚拟内存，硬盘，页面错误，句柄，线程。服务器CPU，内存剩余不多的时候性能的影响。数据库数据库主要考察的指标有占用的内存，CPU。各个查询或者其他操作的响应时间，特别是数据量比较大的时候网络网络流量监控，带宽等。特别是出现网络超时的时候，系统响应情况。5. 风险分析风险描述风险缓解措施风险应对措施触发条件责任人6. 项目里程碑里程碑任务工作量（人日）开始日期结束日期制定测试计划测试脚本准备测试工具开发测试环境部署执行测试性能测试报告7. 测试结束标准测试结束标准一般依据以下原则：所有计划的测试已经完成所有计划收集的性能数据已经获得所有性能瓶颈得到改善并达到设计要求性能计数器性能对象计数器描述Processor使用%Processor Time（所有实例） 指处理器执行非闲置线程时间的百分比。这个计数器设计成用来作为处理器活动的主要指示器。它通过在每个范例间隔中衡 量处理器用于执行闲置处理线程的时间，并且用 100% 减去该值得出。（每台处理器有一个闲置线程，该线程在没有其