系统性能测试方案.docx
《系统性能测试方案.docx》由会员分享，可在线阅读，更多相关《系统性能测试方案.docx（10页珍藏版）》请在冰豆网上搜索。
系统性能测试方案
产品名称Productname
密级Confidentialitylevel
秘密
产品版本Productversion
Total14pages共14页
XX系统性能测试方案
（仅供内部使用）
拟制:
日期：
yyyy-mm-dd
审核:
日期：
yyyy-mm-dd
审核:
日期：
yyyy-mm-dd
批准:
日期：
yyyy-mm-dd
修订记录
日期
修订版本
描述
作者
目录
1概述6
1.1被测试系统简介6
1.2性能测试目的6
2性能需求分析6
3系统角色行为分析7
3.1用户行为分析7
3.2运营行为分析7
3.3系统后台行为分析7
4系统结构分析8
4.1系统组成分析8
4.2压力传递分析8
4.3潜在瓶颈分析8
4.4系统资源分析8
4.5系统监测及其评价标准分析8
5性能测试方案的确定9
5.1基本流程的确定9
5.2异常流程分析9
5.3混合流程分析10
5.4测试项的确定10
5.5数据模型分析及数据规划10
5.6妨碍性能测试持续开展的问题及其解决办法11
5.7测试接口分析11
5.8被测系统配置及其组网图11
5.9测试工具的选定11
5.10测试数据的准备11
5.11测试用例设计建议11
6附录12
表目录ListofTables
表1需求跟踪矩阵表8
图目录ListofFigures
错误！
未找到目录项。
XX系统性能测试方案
关键词：
性能测试、性能测试方案
摘要：
本文档为××系统性能测试方案，主要目的在于通过本文档能够指导性能测试脚本、用例开发、性能测试执行以及性能测试评估等相关工作。
主要的读者有性能测试脚本开发人员、性能测试执行人员、性能评估人员、项目经理、用户代表等。
缩略语清单：
1概述
1.1被测试系统简介
简明扼要地描述被测试系统的功能、技术背景、以及商业背景等相关信息。
1.2性能测试目的
简明扼要地描述本次性能测试的主要目的，比如是为了得到一个性能指标？
还是为了做一次调优类的性能测试？
还是做对比分析的性能测试等？
2性能需求分析
性能需求分析是整个性能测试活动中最关键和最核心的工作，完整的、清晰的、有代表性的、可测试的性能需求直接关系到本次性能测试的目标是否能够达到。
这里指的性能需求可以是用户
（比如中国银行项目，那么银行是用户）对系统的性能需求，当然也可以是产品内部的性能要求（在调优为目的的性能测试中尤其如此）。
系统的性能需求就是一个测试的标准，通过它可以来评价系统性能情况，如果不先分析清楚系统的性能需求，性能测试的目的将变得不明确，性能测试的开展也会有很大随意性，而最终对系统性能测试的结果进行评价时，也会陷入没完没了的毫无意义的争论之中。
服务提供能力
服务提供质量
业务类型
用户类型
容量
单位时间内处理请求能力
同时在线用户数
响应时间
TPS
响应率
正确率
时延
交易类
查询类
这些性能需求的数据可以通过如下途径来获得：
1、国际、国家、行业标准和规范。
2、SRS中关于性能的需求。
3、根据现实情况的估计。
这个估计要基于最终用户的体验和容忍程度的分析，并需要经过开发人员的评审。
4、竞争对手产品性能指标
3系统角色分析建模
这部分分析工作通过对用户的行为模型分析、对运营行为模型的分析、以及对系统后台行为模型的分析，来规划系统性能测试测试模型。
3.1用户行为模型
选取需要做性能测试的用户行为。
这部分不管是什么业务类型的系统都需要考虑
业务类型
用户类型
用户行为
行为频度
特殊情况下行为的最高频度
是否特别消耗资源
是否是关键用户行为
是否需要做性能测试
3.2运营行为模型
选取需要做性能测试的运营（OM）行为，这一部分其实也非常重要，因为越来越多的产品开始关注OM功能。
管理员类型
管理员行为
行为频度
是否特别消耗资源
是否是关键行为
是否需要做性能测试
3.3系统后台行为模型
选取需要做性能测试的系统后台行为。
这部分并不是每一种类型的系统都有的模型，根据需要可选
后台进程、线程、定时任务
后台行为
是否并行执行数量多
是否特别消耗资源
是否是关键后台行为
是否需要做性能测试
4系统结构分析
对系统结构的充分了解是开展后续性能测试活动的基础，在性能测试活动中该如何测试、观察什么、如何观察，对于观察到的结果该如何分析、如何解释，都是建立在对系统结构的充分了解之上的。
4.1系统组成分析
系统组成分析的结果要能清晰的描述如下内容：
a、系统的各组成部分，具体到系统资源的最小拥有者，通常是进程、线程
b、系统各组成部分之间的联系
c、系统各组成部分之间的比例关系
d、系统各组成部分之间的接口协议
这可以通过画出类似系统组网图的方式来描述。
4.2压力传递分析
画出每种需要性能测试的行为的压力传递图，可以画成消息交互图的形式。
4.3潜在瓶颈分析
通过系统组成分析和压力传递分析的结果，我们可以判断系统性能的潜在瓶颈，这是我们后续性能测试中需要重点观测的地方。
4.4系统资源分析
分析系统中的各种资源及其拥有者、使用者。
资源
资源拥有者
资源使用者
4.5系统监测及其评价标准分析
对各系统组成部分运行状态的监测及其评价标准：
系统组成
使用的资源
是否需要监测
使用不充分
使用正常
使用过高
过程趋势
监测方法
对系统总体资源使用情况的监测及其评价标准：
物理实体
拥有的资源
是否需要监测
使用不充分
使用正常
使用过高
过程趋势
监测方法
对系统执行结果的监测及其评价标准：
系统输出
是否需要监测
评价标准
监测方法
5性能测试方案的确定
5.1基本流程的确定
在系统角色行为分析结果的基础上，对于每种需要做性能测试的用户行为，我们需要在这个行为之前，顺序写出用户在进行这项行为之前，必须进行的行为，这样就得到了一个流程。
如果某个流程包含在其他流程中，则这个流程不需要测试，我们只需要测试包含这个流程的其他流程就可以了。
行为
流程
是否需要做性能测试
流程中各步时延要求
5.2异常流程分析
确定需要进行性能测试的异常流程。
基本流程
是否需要测试中途出错
是否需要测试中途放弃
是否需要测试中途拒绝
是否需要测试中途不响应
是否需要测试系统拒绝或放弃
是否需要测试多种消息顺序
异常流程
5.3混合流程分析
可以考虑如下建议来得到我们的混合流程：
a、异常流程尽量不必考虑到混合流程中
b、如果基本流程比较少，将所有的基本流程组合成一个混合流程
c、如果基本流程太多，组合成一个混合流程比较难操作，则考虑组合成多个混合流程
d、基本流程中的后台行为相关的流程需要组合进去
e、各流程的混合比例根据实际情况估计
混合流程
混合比例
5.4测试项的确定
将所有的基本流程、异常流程、混合流程汇总，并标明那些流程需要做指标测试，那些流程需要做压力测试，这样就确定了我们性能测试的测试项。
测试流程
流程每步时延
流程混合比例
是否进行指标测试
是否进行压力测试
5.5数据模型分析及数据规划
数据模型分析的目的，是要确定性能测试时的基础数据量及其分布比例，使性能测试接近于实际的网上运行情况。
数据字段
数据量
数据范围
数据分布比例
5.6妨碍性能测试持续开展的问题及其解决办法
分析各测试项中，存在的各种妨碍性能测试持续开展的问题，并分析解决办法。
5.7测试接口分析
分析性能测试接口的协议类型及其接口能力。
测试接口
接口协议
接口带宽
接口时延
5.8被测系统配置及其组网图
分析被测系统的软硬件配置及其组网图。
软件配置：
硬件配置：
组网图：
5.9测试工具的选定
分析备选测试工具的优缺点，并选择性能测试工具。
备选工具
接口模拟能力
流程模拟能力
流程发起能力
统计分析能力
5.10测试数据的准备
分析测试基础数据的生成和导入的工具和方法。
5.11测试用例设计建议
对下阶段的测试用例设计工作提一些建议。
6附录
参考资料清单：
[1]《》
升级会员 