性能测试计划XX项目Word下载.docx
《性能测试计划XX项目Word下载.docx》由会员分享，可在线阅读，更多相关《性能测试计划XX项目Word下载.docx（23页珍藏版）》请在冰豆网上搜索。
7.测试结束标准7
8.附录I：
7
8.1性能计数器7
8.2WEB服务器10
8.3数据库12
性能测试计划
1.简介
目的
此处描述本次测试的目的是什么，比如验证系统设计的性能目标。
定义、首字母缩写词和缩略语
此处描述本计划中用到的专业术语定义。
范围
本次测试覆盖的范围
参考文献
此处列出本计划相关的文档，包含数据来源以及其他参考
2.测试准备
系统性能要求分析
一般的性能要求包括：
系统容量：
系统最大容纳多少个用户注册。
访问数：
同时访问系统的用户数。
并发数：
一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。
响应时间：
用户提交一个操作到得到响应的时间间隔。
…………
性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。
并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。
在描述并发用户数目时，总是会带有相应的时间段限制。
系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。
单位时间内能处理的请求个数就是系统的业务吞吐量。
虚拟并发用户的数量可以使用如下的公式换算：
（真实用户数×
每个真实用户请求数）/（总请求响应时间+真实用户总思考时间）=（虚拟用户数×
每用户请求个数）/（总请求响应时间+虚拟用户总思考时间）=吞吐量。
测试数据准备
数据分析可以参考以下方式：
历史数据分析有助于数据量级的确定。
从历史数据入手，找出高峰期数据量。
从其他相似或者相同系统入手，进行数据分析，找出高峰期数据量。
无历史或者相关系统可以参考的时候，就要对系统的性能数据进行估算，包含系统容量，并发数等数据，估算以后给相关人员进行评审或者修订以后，按照大家同意的性能指标进行测试。
测试数据最好和真实数据相同，如果能够获得真实系统运行3个月的数据，我们就可以在此基础上进行性能测试。
测试数据最重要的是要达到真实环境运行下的数据量级。
下面是某一个系统一年的数据量估算。
数据对象
数据量
计算方法
用户
8000
重要通知记彔
200000
新建通知记彔:
800个单位*250天，一天一条通知,共计200000条通知，每条通知发送给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条上报信息
督察督办
40000
800个单位*250天，每5天新建1条记彔：
共计40000条记彔
测试环境准备
测试环境要求尽量和真实环境相同，至少要求服务器配置和网络带宽和拓扑结构应该相似。
主要内容：
服务器数量和配置，操作系统和数据库版本，软硬件部署等。
用途
硬件配置
软件配置
Web服务器
CPU内存硬盘
操作系统IE版本
数据库服务器
测试客户端
其他配置
网络或子网
基于TCP/IP协议的局域网结构，千兆带宽，防火墙需要开放服务端口和管理服务端口
测试工具选择
选用jmeter作为性能压测工具，服务器端采用nmon/zabbix监控服务器端资源占用
3.测试策略
对于一个特定的业务系统，用户一般会分散在一天的各个时间段进行访问。
在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。
在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。
例如对于公文处理子系统而言，可能就存在短时间内大量用户查看并办理某条公文的情况。
在进行性能测试时，应当使用“考虑最坏情况的原则”。
也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能和页面是否能够满足性能的要求，系统的响应时间是否过长。
另一方面，系统性能的验证必须做到“覆盖全面”。
虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在进行性能测试和优化时，不能忽略这些功能，编制测试用例时也不能仅仅选择最常用功能。
例如可能所有的用户都会访问我的通知列表，但是一般只有5%的用户会使用通过系统设置模块查找某个用户的信息；
但是在测试时，我们并不能因为查看用户信息功能的使用频率相对较少，而忽略掉这项功能的测试。
测试场景
测试场景的选择和系统的具体业务相关。
计划制定者一定对系统的业务十分了解。
测试场景从整个业务系统分离出来，一般可以参考以下方法：
●以前的系统或者其他类似业务系统的数据参考
●相关项目文档关于场景的描述
场景选择的一个策略可以是按照对系统性能影响的程度，以操作响应时间多少为序。
场景选择要包含系统所有能够影响性能的操作，这些影响主要有：
●和其他系统有交互的操作，要等待其他系统或者组件返回结果的操作：
第三方接口的使用，合成，识别等
●本身存在后台处理的业务：
后台处理耗时的业务（评分，更新排行榜等），数据库查询等
●使用缓存信息的操作
设计场景的时候要考虑思考时间。
在用户真实使用环境中，用户操作不同功能之间并不是连续不断的，而是在不同步骤之间有所延迟，称之为“思考时间”。
在设计用例时，应当模拟实际用户使用系统的方式，在不同的操作步骤中加入用户的“思考时间”，才能够模拟真实的压力情况。
测试场景要说明覆盖了哪些场景，没有覆盖到哪些场景，为什么没有覆盖。
测试场景一
步骤
说明
备注：
Action、平均响应时间（S）
1
打开主界面
Action：
访问首页（FWSY）；
5
2
输入用户名密码（需进行参数化），登录系统，进入首页
登陆（DL）；
3
点击“我的通知”标签，进入通知列表页面
进入通知列表（JRTZLB）；
4
在我的通知上点击已收通知标题链接，查看通知（重要通知）
查看通知（CKTZ）；
在我的通知上点击已收通知的“回复”链接，进入回复界面
进入回复界面（JRHFJM）；
6
在通知回复界面上填写回复内容并提交
回复通知（HFTZ）；
测试场景二
负载分配策略
场景确定以后，就要确定各个场景的比例数。
各个场景所占比例的多少可以根据以下方法进行确定：
●历史数据统计
●其他系统参考
●如果是一个全新的系统，需要测试人员估计一个比例以后和项目组讨论确定。
服务器上总的负载确定以后，需要在客户端进行压力分配，就是各个测试机上运行多少和什么样的测试场景：
和具体的网络条件以及机器配置相关。
计划的负载下，性能达到设计要求以后，可以持续增加系统的压力，一直到瓶颈出现，可以为系统性能的提高提出改进方向。
总计
192.168.×
.×
10
28
50
20
140
4.性能数据记录和分析
根据系统性能要求，记录需要的数据，可以对以下数据进行记录和分析：
被测系统
各个主要Action的响应时间，在自动加载压力测试的同时，人工检查各项数据是否和自动记录的数据相同。
内存、CPU、虚拟内存、句柄、线程，可以使用操作系统的性能计数器来记录这些数据，或者测试工具自己可以记录。
可记录不同压力下各种操作响应时间的变化。
比如100路200路500路下的各个操作的响应时间分布情况，内存、CPU使用情况等，以分析压力的增加对系统性能的影响。
在压力不断增大的情况下，找出响应超时的操作，对这些操作超时进行详细分析，给性能改进提出意见，最好能够指出瓶颈所在，比如是数据库、网络或者CPU原因引起。
下图是压力倍数和处理器时间的关系：
说明在3倍压力的情况下处理器时间缩小，说明在其它的部分已经出现性能瓶颈，不需要太多的处理器时间来处理事件。
出现性能瓶颈的时候，识别出是哪个场景不符合，着重测试这个场景性能拐点出现的条件。
数据记录可以采取采样的方式进行，也可以采取线型记录的方式全部记录，根据系统的具体需要以及工具的功能而定。
服务器
服务器的数据主要考察CPU，内存，虚拟内存，硬盘，页面错误，句柄，线程。
服务器CPU，内存剩余不多的时候性能的影响。
数据库
数据库主要考察的指标有占用的内存，CPU。
各个查询或者其他操作的响应时间，特别是数据量比较大的时候
网络
网络流量监控，带宽等。
特别是出现网络超时的时候，系统响应情况。
5.风险分析
风险描述
风险缓解措施
风险应对措施
触发条件
责任人
6.项目里程碑
里程碑任务
工作量（人日）
开始日期
结束日期
制定测试计划
测试脚本准备
测试工具开发
测试环境部署
执行测试
性能测试报告
7.测试结束标准
测试结束标准一般依据以下原则：
所有计划的测试已经完成
所有计划收集的性能数据已经获得
所有性能瓶颈得到改善并达到设计要求
性能计数器
性能对象
计数器
描述
Processor使用
%ProcessorTime（所有实例）
指处理器执行非闲置线程时间的百分比。
这个计数器设计成用来作为处理器活动的主要指示器。
它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。
（每台处理器有一个闲置线程，该线程在没有其
升级会员 