ImageVerifierCode 换一换
格式:DOC , 页数:12 ,大小:490.50KB ,
资源ID:382577      下载积分:2000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-382577.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(性能测试计划(完整版).doc)为本站会员(吴艺期)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

性能测试计划(完整版).doc

1、 第 1 页 性能测试方案 第 2 页 目录 目录 前言 3 1 第一章 XXX 系统性能测试概述 . 3 1.1 被测系统定义 . 3 1.1.1 功能简介 3 1.1.2 性能测试指标 4 1.2 系统结构 及流程 . 4 1.2.1 系统总体结构 4 1.2.2 功能模块 5 1.2.3 关键点描述( KP) . 5 1.3 性能测试环境 . 5 2 第二章 性能测试 6 2.1 预期性能测试 . 7 2.1.1 预期性能概述 7 2.1.2 测试特点 7 2.2 用户并发测试 . 7 2.2.1 并发测试概述 7 2.2.2 测试目的 7 2.3 大数据量测试 . 7 2.3.1 大数

2、据量测试概述 7 2.3.2 测试目的 8 2.4 疲劳强度测试 . 8 2.4.1 疲劳强度测试概述 8 2.4.2 测试目的 8 2.5 负载能力测试 . 8 2.5.1 负载测试概述 8 2.5.2 测试目的 8 2.6 测试方法及测试用例 . 9 2.7 测试指标及期望 . 9 2.7.2 测试数据准备 10 2.7.3 运行状况记录 10 3 第三章 测试过程及结果描述 10 3.1 测试描述 . 10 3.2 测试场景 . 11 3.3 测试结果标准 . 11 测试结束标准一般依据以下原则: 11 执行每个场景时需要记录以下相应的数据 . 11 4 第四章 测试报告 . 12 第

3、3 页 前言 平台 XX 项目 系统 已经成功 发布 , 依据 项目的规划 , 未来 势必 会 出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟,系统的性能问题也逐步成为了 我们关注的焦点: 每天 大数据量的“冲击”,系统能稳定在什么样的性能水平,面临 行业 公司业务 增加 时,系统能否经受住“考验”,这些问题需要通过一个完整的性能测试来给出答案。 本性能测试 计划书 即是基于上述考虑,参考科学的性能测试方法而撰写的,用以指导即将进行的 系统 的性能测试。 1 第一章 XXX 系统性能测试概述 1.1 被测系统定义 XXX 系统 作为本次测试的被测系统(注:以下所有针

4、对被测系统地描述均为针对XXX 系统 进行的) , XXX 系统 是由 平台开发的一款物流 应用软件,后台应用了Oracle11g 数据库,该系统包括主要功能有 :XXX 等 。 在 该 系统 中都存在 多用户 操作 , 大数据量 操作 以及日报、周报、年报的统计, 在本次测试中,将针对 这些 多用户操作, 大数据量的查询、统计功能 进行 如预期性能、用户并发 、大数据量、疲劳强度和负载等方面的性能测试 ,检查并评估在模拟环境中,系统对负载的承受能力,在不同的用户连接情况下,系统 的 吞吐能力和响应能力,以及在预计的数据容量中,系统能够容忍的最大用户数 。 1.1.1 功能简介 主要功能 上面

5、已提到,由于本文档主要专注于性能在这里 功能 不再作为重点讲述。 第 4 页 1.1.2 性能测试指标 本次测试是针对 XXX 系统 进行的 全面性能测试 ,主要需要获得如 下的测试指标。 1、 应用系统的负载能力:即系统所能容忍的最大用户数量,也就是在正常的响应时间中,系统能够支持的最多的客户端的数量。 2、 应用系统的吞吐量: 即 在一次 事务 中 网络内 完成 的数据量的总和 , 吞吐量指标反映的是服务器承受的压力 。 事务 是 用户某一步或几步操作的集合 。 3、 应用系统的吞吐率:即应用系统在单位时间内完成的数据 量,也就是在单位时间内,应用系统针对不同的负载压力,所能完成的 数据

6、量。 4、 TPS: 每秒钟系统能够处理事务或交易的数量,它是衡量系统处理能力的重要指标 。 5、点击率: 每秒钟用户 向 服务器提交的 HTTP 请求数 。 5、 系统的响应能力:即在各种负载压力情况下,系统的响应时间,也就是从客户端请求发起,到服务器端应答返回所需要的时间,包括网络传输时间和服务器处理时间。 6、应 用系统的 可靠性:即在连续工作时间状态下,系统能够正常运行的时间,即在连续工作时间段内没有出错信息 。 1.2 系统结构及流程 XXX 系统 在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的,交易流程也完全一致的。不过,由于硬件条件的限制,本次性能测试的硬件平台跟实

7、际生产环境略有不同。 1.2.1 系统总体结构 描述本系统的总体结构,包括:硬件组织体系结 构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。 第 5 页 1.2.2 功能模块 1 本次性能测试中各类 操作 都是由若干功能模块组成的,每个 功能 都根据其执行特点分 成了若干操作步骤,每个步骤就是一个功能点(即功能模块),本次性能 测试主要涉及 的功能模块以及所属 操作 如下表 步骤 说明 备注: Action、平均响应时间( S) 1 打开主界面 Action:访问首页 (FWSY); 5 2 输入用户名密码(需进行参数化),登录系统,进入首页 Action:登陆 (DL); 5

8、 3 点击“ 我的通知”标签,进入通知列表页面 Action:进入通知列表 (JRTZLB);5 4 在我的通知上点击已收通知标题链接,查看通知(重要通知) Action:查看通知 (CKTZ); 5 5 在我的通知上点击已收通知的“回复”链接,进入回复界面 Action:进入回复界面 (JRHFJM);5 6 在通知回复界面上填写回复内容并提交 Action:回复通知 (HFTZ); 5 1.2.3 关键点描述( KP) 本次性能测试的关键点,就是查看 XXX 系统 在 不同用户数量( 并发 ) 压力下的表现 和大数据量操作时系统的性能状态 ,即:支 持的并发用户数目和并发用户发送频率,以及

9、在较大压力下,系统的 处理能力以及 CPU、数据库 I/O 和内存的使用情况,并找出相应 的性能瓶颈。 1.3 性能测试环境 本次性能测试环境与真实运行环境硬件和网络环境 有所不同 , 是真实环境的缩小,数据库是真实环境数据库的一个复制(或缩小),本系统采用标准的 CS 结构,客户端通过 前台安装 访问应用系统。 其中具体的硬件和网络环境如下: 中间件服务器 : Weblogic9 操作系统: Windows7/Linux 网络环境: LAN( 10M) 数据库: Oracle 11g RAC 第 6 页 客 户端: PC ( Windows) 网络拓扑和结构图如下: 数 据 库 服 务 器中

10、 间 件 服 务 器客 户 机 A客 户 机 B交换机2 第二章 性能测试 从广泛意义上讲性能测试包括: 预期性能测试、用户并发 测试、 大数据量 测试、 疲劳强度测试、 负载能力测试等。在不同应用系统的性能测试中,需要根据应用系统的特点和测试目的的不同来选择具体的测试方案,本次 XXX 系统 的性能测试主要是采用通常的压力测试模式来执行的,即:逐步增加压力,查看应用系统在各种压力状况 下 的性能表现。 在本次性能测试中,将使用性能测试 工具 LoadRunner11.0 对 被 测试项目 的各模块 进行监控,判断 XX 系统各模块 的 性能表现 ,并帮助 项目 人员分析 系统各个 操作 的性

11、能瓶颈点。 第 7 页 2.1 预期性能测试 2.1.1 预期性能 概述 通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。通俗地说,这种方法就是要在特定的运行条件下验证系统的能力状态 。 2.1.2 测试特点 1、主要目的是验证系统是否有系统宣称具有的能力。 2、要事先了解被测试系统经典场景,并具有确定的性能目标。 3、要求在已经确定的环境下运行。 2.2 用户并发测试 2.2.1 并发 测试概述 并发测试方法通过模拟用户并发访问,测试多用户并发访问同 一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题 。 2.2.2 测试目的 1、主要目的是发现系

12、统中可能隐藏的并发访问时的问题。 2、主要关注系统可能存在的并发问题,例如系统中的内存泄漏、线程锁和资源争用方面的问题。 3、可以在开发的各个阶段使用需要相关的测试工具的配合和支持。 2.3 大数据量测试 2.3.1 大数据量 测试概述 测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。大数据量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量 。 第 8 页 2.3.2 测试目的 1、主要目的是 确定软件发生故障的 极限 。 2、 确定测试 对象在给定时间内能够持续处理的最大负载或工作量 。 3、可以在开发的各个阶段使用需要相关的测试工具的配合和支持 。 2.4 疲

13、劳强度测试 2.4.1 疲劳强度 测试概述 即压力测试, 测试系统在一定饱和状态下,例如 cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误 。 2.4.2 测试目的 1、主要目的是检查系统处于压力性能下时,应用的表现。 2、一般通过模拟负载等方法,使得系统的资源使用达到较高的水平。 3、一般用于测试系统的稳定性。 2.5 负载能力测试 2.5.1 负载 测试概述 通过在被测系统上不断加压,直到性能指标达到极限,例如 “响应 时间 ”超过预定指标或都某种资源已经达到饱和状态 。 2.5.2 测试目的 1、主要目的是找到系统处理能力的极限。 2、需要在给定的测试环境下进

14、行,通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。 3、一般用来了解系统的性能容量,或是配合性能调优来使用。 。 第 9 页 2.6 测试方法及测试用例 详情参见 XX 项目测试用例 .doc的 “ 性能测试 ” 章节 2.7 测试指标及期望 在本次性能测试中,各类测试指标包括测试中应该达到的某些性能指标,这些性能指标均是来自应用系统设计开发时遵循的业务需求,当某个测试的某一类指 标已经超出了业务需求的要求范围,则测试已经达到目的,即可终止性能 测试。 2.7.1.1 应用软件级别的测试指标: CPU 的利用率小于 40% 内存占用小于 80% Processo

15、r queue length 小于 2 Response time 小于 1s 吞吐量 throughtput 大于 90% 业务执行的平均响应时间(期望值: 15s) 不同并发用户数的状况下的记录上述值 2.7.1.2 网络级别的测试指标: 吞吐量:单位时间内网络传输数据量 冲突率:在以太网上监测到的每秒冲突数 2.7.1.3 操作系统级别的测试指标: 进程 /线程交换率:进程和线程之间每秒交换次 数 CPU 利用率:即 CPU 占用率() 系统 CPU 利用率:系统的 CPU 占用率() 用户 CPU 利用率:用户模式下的 CPU 占用率() 磁盘交换率:磁盘交换速率 中断速率: CPU

16、每秒处理的中断数 第 10 页 2.7.1.4 数据库级别的测试指标: 数据库 I/O 的流量大小 数据库锁资源的使用数量 数据库的并发连接数:客户端的最大连接数 2.7.2 测试数据准备 2.7.2.1 案例数据:满负荷压力 根据测试系统的硬件条件,选择满负荷的压力,在系统的资源使用基本维持在 90%左右的状况下,测试 天威宽带 业务 管理 系统的处理能力 。 数据准备工作包括: 测试数据库 需具备与真实环境成一定比例 或基本一致 的数据 2.7.3 运行状况记录 记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外,应该结合测试实时记录系统各个层次的资源和参数。主要包括:

17、硬件环境资源 服务器操作系统参数 网络相关参数 数据库相关参数:具体数据库参数有所不同,结合各个数据库独有的特点记录 3 第三章 测试过程及结果描述 3.1 测试描述 在测试数据准备完备以后, 测试 将 进行。 记录每次测试的 结果 数据 ,分析测试结果对系统进行全面评估。 第 11 页 3.2 测试场景 示 例: 步骤 说明 备注: Action、平均响应时间( S) 1 打开主界面 Action:访问首页 (FWSY); 5 2 输入用户名密码(需进行参数化),登录系统,进入首页 Action:登陆 (DL); 5 3 点击“我的通知”标签,进入通知列表页面 Action:进入通知列表 (

18、JRTZLB);5 4 在我的通知上点击已收通知标题链接,查看通知(重要通知) Action:查看通知 (CKTZ); 5 5 在我的通知上点击已收通知的“回复”链接,进入回复界面 Action:进入回复界面 (JRHFJM);5 6 在通知回复界面上填写回复内容并提交 Action:回复 通知 (HFTZ); 5 测试中,使用逐步加压的模式, 测试运行 场景 安排如下: 1. 每隔 2 秒增加 1 个用户连接,最多增加到 100 个用户,查看并记录运行情况 2. 每隔 2 秒增加 2 个用户连接,最多增加到 200 个用户,查看并记录运行情况 3. 每隔 2 秒增加 1 个用户连接,最多增加

19、到 300 个用户,查看并记录运行 情况 4. 每隔 3 秒增加 1 个用户连接,最多增加到 400 个用户,查看并记录运行 情况 每个场景都包括:用户登录 -业务操作 -业务完成 -退出系统, 所有用例都按以上场景进行测试, 由于 pc 性能限制,为了更准确模拟现场环境,将 运行的 所有 脚本部署在LoadRunner 终端上 ,主要目的就是检查在 不同的 压力的情况下,业务系统的性能表现。 3.3 测试结果 标准 测试结束标准一般依据以下原则: 1. 所有计划的测试已经完成 ; 2. 所有计划收集的性能数据已经获得 ; 3. 所有性能瓶颈得到改善并达到设计要求 。 执行每个场景时 需要 记录以下相应的 数据 1. APP 服务器主机上的 CPU 利用率: 2. 在数据库( Oracle)服务器上主机上的 CPU 利用率: 第 12 页 3. IO 和 CPU 利用率对照表如下: 4. APP 服务器监控的网络流量 : 5. DB 服务器上监控的网络流量 : 6. 运行的并发用户数目: 7. 测试中 完成 各 操作 的平均响应时间:(单位: 秒) 8. 测试中每秒的点击率如下: 9. 交易的吞吐率(每秒处理数据量): 4 第四章 测试报告 在 XXX 系统 的性能测试 结束 后 ,根据测试结果,将生成测试报告。 对应的文档名称如下: XX 项目 性能测试报告

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1