性能测试计划_XX项目

《性能测试计划_XX项目》由会员分享，可在线阅读，更多相关《性能测试计划_XX项目（14页珍藏版）》请在金锄头文库上搜索。

1、1目录1. 简介 21.1 目的 21.2 定义、首字母缩写词和缩略语 21.3 范围 21.4 参考文献 22. 测试准备 22.1 系统性能要求分析 22.2 测试数据准备 32.3 测试环境准备 32.4 测试工具选择 33. 测试策略 43.1 测试场景 43.1.1 测试场景一 43.1.2 测试场景二 53.2 负载分配策略 54. 性能数据记录和分析 54.1 被测系统 54.2 服务器 64.3 数据库 64.4 网络 65. 风险分析 76. 项目里程碑 77. 测试结束标准 78. 附录 I： 78.1 性能计数器 78.2 WEB 服务器 108.3 数据库 122性能测

2、试计划1. 简介1.1 目的此处描述本次测试的目的是什么，比如验证系统设计的性能目标。1.2 定义、首字母缩写词和缩略语此处描述本计划中用到的专业术语定义。1.3 范围本次测试覆盖的范围1.4 参考文献此处列出本计划相关的文档，包含数据来源以及其他参考2. 测试准备2.1 系统性能要求分析一般的性能要求包括：系统容量：系统最大容纳多少个用户注册。访问数：同时访问系统的用户数。并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户） 。响应时间：用户提交一个操作到得到响应的时间间隔。性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的

3、性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行 3 个月的数据量。在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算： （真实用户数 每个真实用户请求数） /(总请求响应时间 +真实用户总思考时间 )=(虚拟用户数 每用户请求个数 )/(总请求响应时间 +虚拟用户总思考时间 )=吞吐量。项目 Version: 性能Test Plan Date: 32.2 测试数据准备数据分析可以参考以下方式：历史数据分析有助于

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

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

6、每个日报发给 10个接收人 信息上报 200000 800个单位 *250天，一天上报 1条信息：共计 200000条上报信息 督察督办 40000 800个单位 *250天，每 5天新建 1条记彔：共计 40000条记彔 2.3 测试环境准备测试环境要求尽量和真实环境相同，至少要求服务器配置和网络带宽和拓扑结构应该相似。主要内容：服务器数量和配置，操作系统和数据库版本，软硬件部署等。用途 硬件配置 软件配置Web 服务器 CPU 内存 硬盘 操作系统 IE 版本 数据库服务器测试客户端其他配置网络或子网 基于 TCP/IP 协议的局域网结构，千兆带宽，防火墙需要开放服务端口和管理服务端口2.

7、4 测试工具选择测试工具的选择对性能测试能否成功至关重要。一般的测试 B/S 结构的系统我们现在使用的是 LR。基本上可以解决目前我们需要测试的性能点问题。 C/S 结构的系统一般要开项目 Version: 性能Test Plan Date: 4发性能测试工具，模拟多路进行长时间的运行，并记录相应的性能数据。新工具要经过确认3. 测试策略对于一个特定的业务系统，用户一般会分散在一天的各个时间段进行访问。在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。例如对于公文处理子系统而言，可能就存在短时间内大量用户查看

8、并办理某条公文的情况。 在进行性能测试时，应当使用“考虑最坏情况的原则 ”。也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能和页面是否能够满足性能的要求，系统的响应时间是否过长。另一方面，系统性能的验证必须做到 “覆盖全面 ”。虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在进行性能测试和优化时，不能忽略这些功能，编制测试用例时也不能仅仅选择最常用功能。例如可能所有的用户都会访问我的通知列表，但是一般只有 5%的用户会使用通过系统设置模块查找某个用户的信息；但是在测试时，我们并不能因为查看用户信息功能的使用频

9、率相对较少，而忽略掉这项功能的测试。3.1 测试场景测试场景的选择和系统的具体业务相关。计划制定者一定对系统的业务十分了解。测试场景从整个业务系统分离出来，一般可以参考以下方法： 以前的系统或者其他类似业务系统的数据参考 相关项目文档关于场景的描述场景选择的一个策略可以是按照对系统性能影响的程度，以操作响应时间多少为序。场景选择要包含系统所有能够影响性能的操作，这些影响主要有： 和其他系统有交互的操作，要等待其他系统或者组件返回结果的操作：第三方接口的使用，合成，识别等 本身存在后台处理的业务：后台处理耗时的业务（评分，更新排行榜等） ，数据库查询等 使用缓存信息的操作设计场景的时候要考虑思考

10、时间。在用户真实使用环境中，用户操作不同功能之间并不是连续不断的，而是在不同步骤之间有所延迟，称之为 “思考时间 ”。在设计用例时，应当模拟实际用户使用系统的方式，在不同的操作步骤中加入用户的 “思考时间 ”，才能够模拟真实的压力情况。测试场景要说明覆盖了哪些场景，没有覆盖到哪些场景，为什么没有覆盖。3.1.1 测试场景一步骤 说明 备注： Action、平均响应时间（ S）1 打开主界面 Action：访问首页 (FWSY)； 52 输入用户名密码（需进行参数化） ，登录系统，进入首页Action：登陆 (DL)； 53 点击 “我的通知 ”标签，进入通知列表页面Action：进入通知列表

11、(JRTZLB)；5项目 Version: 性能Test Plan Date: 54 在我的通知上点击已收通知标题链接，查看通知（重要通知）Action：查看通知 (CKTZ)； 55 在我的通知上点击已收通知的 “回复 ”链接，进入回复界面Action：进入回复界面 (JRHFJM)；56 在通知回复界面上填写回复内容并提交 Action：回复通知 (HFTZ)； 53.1.2 测试场景二3.2 负载分配策略场景确定以后，就要确定各个场景的比例数。各个场景所占比例的多少可以根据以下方法进行确定： 历史数据统计 其他系统参考 如果是一个全新的系统，需要测试人员估计一个比例以后和项目组讨论确定。

12、服务器上总的负载确定以后，需要在客户端进行压力分配，就是各个测试机上运行多少和什么样的测试场景：和具体的网络条件以及机器配置相关。计划的负载下，性能达到设计要求以后，可以持续增加系统的压力，一直到瓶颈出现，可以为系统性能的提高提出改进方向。测试场景一测试场景二 总计192.168. 10 4 1 1 4 2 2 2 2 28192.168. 10 4 1 1 4 2 2 2 2 28192.168. 10 4 1 1 4 2 2 2 2 28192.168. 10 4 1 1 4 2 2 2 2 28192.168. 10 4 1 1 4 2 2 2 2 28总计 50 20 5 5 20 1

13、0 10 10 10 1404. 性能数据记录和分析根据系统性能要求，记录需要的数据，可以对以下数据进行记录和分析：4.1 被测系统各个主要 Action 的响应时间，在自动加载压力测试的同时，人工检查各项数据是否和自动记录的数据相同。内存、 CPU、虚拟内存、句柄、线程，可以使用操作系统的性能计数器来记录这些数据，或者测试工具自己可以记录。可记录不同压力下各种操作响应时间的变化。比如 100 路 200 路 500 路下的各个操作项目 Version: 性能Test Plan Date: 6的响应时间分布情况，内存、 CPU 使用情况等，以分析压力的增加对系统性能的影响。在压力不断增大的情况

14、下，找出响应超时的操作，对这些操作超时进行详细分析，给性能改进提出意见，最好能够指出瓶颈所在，比如是数据库、网络或者 CPU 原因引起。下图是压力倍数和处理器时间的关系：说明在 3 倍压力的情况下处理器时间缩小，说明在其它的部分已经出现性能瓶颈，不需要太多的处理器时间来处理事件。出现性能瓶颈的时候，识别出是哪个场景不符合，着重测试这个场景性能拐点出现的条件。数据记录可以采取采样的方式进行，也可以采取线型记录的方式全部记录，根据系统的具体需要以及工具的功能而定。4.2 服务器服务器的数据主要考察 CPU，内存，虚拟内存，硬盘，页面错误，句柄，线程。服务器 CPU，内存剩余不多的时候性能的影响。4

15、.3 数据库数据库主要考察的指标有占用的内存， CPU。各个查询或者其他操作的响应时间，特别是数据量比较大的时候4.4 网络网络流量监控，带宽等。特别是出现网络超时的时候，系统响应情况。项目 Version: 性能Test Plan Date: 75. 风险分析风险描述 风险缓解措施 风险应对措施 触发条件 责任人6. 项目里程碑里程碑任务 工作量（人日） 开始日期 结束日期 责任人制定测试计划测试脚本准备测试工具开发测试环境部署测试数据准备执行测试性能测试报告7. 测试结束标准测试结束标准一般依据以下原则：所有计划的测试已经完成所有计划收集的性能数据已经获得所有性能瓶颈得到改善并达到设计要求8. 附录 I：8.1 性能计数器性能对象 计数器 描述Processor %Processor 指处理器执行非闲置线程时间的百分比。这个计数器设计成用来项目 Version: 性能Test Plan Date: 8使用 Time（所有实例） 作为处理器活动的主要指示器。它通过在每个范例间隔中衡 量处理器用于执行闲置处理线程的时间，并且用 100% 减去该值得出。(每台处理器有一个闲置线程，该线程在没有其它线程可以运行时消耗周期)。可将其视为范例间隔用于做有用工作的百分比。这个计数器显示在范例间隔时所看到的忙时平均值。这个值是用 10