性能测试计划XX项目.docx
《性能测试计划XX项目.docx》由会员分享，可在线阅读，更多相关《性能测试计划XX项目.docx（24页珍藏版）》请在冰点文库上搜索。
性能测试计划XX项目
目录
1.简介2
1.1目的2
1.2定义、首字母缩写词和缩略语2
1.3范围2
1.4参考文献2
2.测试准备2
2.1系统性能要求分析2
2.2测试数据准备3
2.3测试环境准备3
2.4测试工具选择3
3.测试策略4
3.1测试场景4
3.1.1测试场景一4
3.1.2测试场景二5
3.2负载分配策略5
4.性能数据记录和分析5
4.1被测系统5
4.2服务器6
4.3数据库6
4.4网络6
5.风险分析7
6.项目里程碑7
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
发文
400000
800个单位*250天，一天2篇发文,共计400000条发文
收文
400000
800个单位*250天，一天2篇收文,共计400000条通知
效能日报
400000
800个单位*250天，一天新建2个日报：
共计400000条日报，每个日报发给10个接收人
信息上报
200000
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
输入用户名密码（需进行参数化），登录系统，进入首页
Action：
登陆（DL）；5
3
点击“我的通知”标签，进入通知列表页面
Action：
进入通知列表（JRTZLB）；5
4
在我的通知上点击已收通知标题链接，查看通知（重要通知）
Action：
查看通知（CKTZ）；5
5
在我的通知上点击已收通知的“回复”链接，进入回复界面
Action：
进入回复界面（JRHFJM）；5
6
在通知回复界面上填写回复内容并提交
Action：
回复通知（HFTZ）；5
测试场景二
负载分配策略
场景确定以后，就要确定各个场景的比例数。
各个场景所占比例的多少可以根据以下方法进行确定：
●历史数据统计
●其他系统参考
●如果是一个全新的系统，需要测试人员估计一个比例以后和项目组讨论确定。
服务器上总的负载确定以后，需要在客户端进行压力分配，就是各个测试机上运行多少和什么样的测试场景：
和具体的网络条件以及机器配置相关。
计划的负载下，性能达到设计要求以后，可以持续增加系统的压力，一直到瓶颈出现，可以为系统性能的提高提出改进方向。
测试场景一
测试场景二
…………
…………
…………
…………
…………
…………
…………
总计
192.168.×.×
10
4
1
1
4
2
2
2
2
28
192.168.×.×
10
4
1
1
4
2
2
2
2
28
192.168.×.×
10
4
1
1
4
2
2
2
2
28
192.168.×.×
10
4
1
1
4
2
2
2
2
28
192.168.×.×
10
4
1
1
4
2
2
2
2
28
总计
50
20
5
5
20
10
10
10
10
140
4.性能数据记录和分析
根据系统性能要求，记录需要的数据，可以对以下数据进行记录和分析：
被测系统
各个主要Action的响应时间，在自动加载压力测试的同时，人工检查各项数据是否和自动记录的数据相同。
内存、CPU、虚拟内存、句柄、线程，可以使用操作系统的性能计数器来记录这些数据，或者测试工具自己可以记录。
可记录不同压力下各种操作响应时间的变化。
比如100路200路500路下的各个操作的响应时间分布情况，内存、CPU使用情况等，以分析压力的增加对系统性能的影响。
在压力不断增大的情况下，找出响应超时的操作，对这些操作超时进行详细分析，给性能改进提出意见，最好能够指出瓶颈所在，比如是数据库、网络或者CPU原因引起。
下图是压力倍数和处理器时间的关系：
说明在3倍压力的情况下处理器时间缩小，说明在其它的部分已经出现性能瓶颈，不需要太多的处理器时间来处理事件。
出现性能瓶颈的时候，识别出是哪个场景不符合，着重测试这个场景性能拐点出现的条件。
数据记录可以采取采样的方式进行，也可以采取线型记录的方式全部记录，根据系统的具体需要以及工具的功能而定。
服务器
服务器的数据主要考察CPU，内存，虚拟内存，硬盘，页面错误，句柄，线程。
服务器CPU，内存剩余不多的时候性能的影响。
数据库
数据库主要考察的指标有占用的内存，CPU。
各个查询或者其他操作的响应时间，特别是数据量比较大的时候
网络
网络流量监控，带宽等。
特别是出现网络超时的时候，系统响应情况。
5.风险分析
风险描述
风险缓解措施
风险应对措施
触发条件
责任人
6.项目里程碑
里程碑任务
工作量（人日）
开始日期
结束日期
责任人
制定测试计划
测试脚本准备
测试工具开发
测试环境部署
测试数据准备
执行测试
性能测试报告
7.测试结束标准
测试结束标准一般依据以下原则：
所有计划的测试已经完成
所有计划收集的性能数据已经获得
所有性能瓶颈得到改善并达到设计要求
8.附录I：
性能计数器
性能对象
计数器
描述
Processor使用
%ProcessorTime（所有实例）
指处理器执行非闲置线程时间的百分比。
这个计数器设计成用来作为处理器活动的主要指示器。
它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。
（每台处理器有一个闲置线程，该线程在没有其它线程可以运行时消耗周期）。
可将其视为范例间隔用于做有用工作的百分比。
这个计数器显示在范例间隔时所看到的忙时平均值。
这个值是用100%减去该服务不活动的时间计算出来的。
Processor瓶颈
Interrupts/sec
指处理器每秒钟接收并维护的硬件中断的平均值。
它不包括DPC，DPC将单独计算。
这个值是产生中断的设备（如：
系统时钟、鼠标、磁盘驱动器、数据交流线路、网络街面卡和其它附件设备）的活动的间接指示器，这些设备通常在完成了一项任务或需要注意时中断处理器。
正常的线程操作在中断时悬停。
大多数的系统时钟每隔10毫秒中断处理器一次，形成了间隔活动的后台。
这个计数值显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。
System/ProcessorQueueLength（所有实例）
是指处理列队中的线程数。
即使在有多个处理器的计算机上处理器时间也会有一个单列队。
不象磁盘计数器，这个计数器仅计数就绪的线程，而不计数运行中的线程。
如果处理器列队中总是有两个以上的线程通常表示处理器堵塞。
这个计数器仅显示上一次观察的值；而不是一个平均值。
System/ContextSwitches/sec
指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。
当正在运行的线程自动放弃处理器时出现上下文转换，由一个有更高优先就绪的线程占先或在用户模式和特权（内核）模式之间转换以使用执行或分系统服务。
它是在计算机上的所有处理器上运行的所有线程的Thread:
ContextSwitches/sec的总数并且用转换数量衡量。
在系统和线程对象上有上下文转换计数器。
这个计数值显示在上一次两个实例中观察到的值除于实例间隔的持续时间所得的值的差异。
Process
（进程）
PrivateBytes
指这个处理不能与其它处理共享的、已分配的当前字节数。
VirtualBytes
指处理使用的虚拟地址空间的以字节数显示的当前大小。
使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。
虚拟空间是有限，如果使用过多，可能会限制处理加载数据库的能力。
WorkingSet
指这个处理的WorkingSet中的当前字节数。
WorkingSet是在处理中被线程最近触到的那个内存页集。
如果计算机上的可用内存处于阈值以上，即使页不在使用中，也会留在一个处理的WorkingSet中。
当可用内存降到阈值以下，将从WorkingSet中删除页。
如果需要页时，它会在离开主内存前软故障返回到WorkingSet中。
HandleCount
由这个处理现在打开的句柄总数。
这个数字是在这个处理中每个线程当前打开的句柄的总数。
Objects
Threads
线程指在数据收集时在计算机中线程的数目。
请注意这是一个即时计算而不是一个时间间隔的平均值。
一个线程为一个基本的可执行实体，该实体在处理器中执行指令。
Memory使用
AvailableBytes
是计算机上可用于运行处理的有效物理内存的字节数量。
是用零、空闲和备用内存表上的空间总值计算的。
空闲内存指可以使用内存；零内存指为了防止以后的处理看到以前处理使用的数据而在很多页内存中充满了零的内存。
备用内存是指从处理的工作集（它的物理内存）移到磁盘的，但是仍旧可以调用的内存。
这个计数器只显示上一次观察到的值；它不是一个平均值。
CacheBytes
是SystemCacheResidentBytes的总数。
SystemDriverResidentBytes、SystemCodeResidentBytes、以及PoolPagedResidentBytes计数器。
该计数器只显示最后一次观察的值，它不是一个平均值。
Memory瓶颈或溢出
Pages/sec
是指为解析硬页错误从磁盘读取或写入磁盘的页数。
（当处理程序请求不在本身工作集或物理内存其它地方中的代码或数据，而必须要从磁盘上检索时就会出现硬页错误）。
这个计数器设计成可以显示导致系统范围延缓类型错误的主要指示器。
它是Memory:
PagesInput/sec和Memory:
PagesOutput/sec的总和。
是用页数计算的，以便在不用做转换的情况下就可以同其它页计数如:
Memory:
PageFaults/sec做比较，这个值包括为满足错误而在文件系统缓存（通常由应用程序请求）的非缓存映射内存文件中检索的页。
这个计数器显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。
PageReads/sec
是指为解析硬页错误而读取磁盘的次数。
（当处理请求的硬页错误不在工作集和物理内存其它地方中的代码或数据，而必须从磁盘上检索时就会出现硬页错误）。
这个计数器设计成可以显示导致系统范围延缓错误的主要指示器。
这个包括要满足错误而在文件系统缓存（通常由应用程序请求）的非缓存映射内存文件终检索的页。
这个计数器显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。
TransitionFaults/sec
是指由在修改页列表、备份页表或在页错误时写入磁盘上造成的页错误数量。
这些页是在没有额外磁盘活动的情况下恢复的。
传输错误是在不计算每次操作时出错的页数的情况下计算错误数量。
这个计数器显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。
PoolPagedBytes
指在分页池中的字节数，分页池是系统内存（操作系统使用的物理内存）中可供对象（在不处于使用时可以写入磁盘的）使用的一个区域。
Memory:
PoolPagedBytes的计数方式与Process:
PoolPagedBytes的方式不同，因此可能不等于Process:
PoolPagedBytes:
_Total。
这个计数器仅显示上一次观察的值；而不是一个平均值。
PoolNonpagedBytes
指在非分页池中的字节数，非分页池是指系统内存（操作系统使用的物理内存）中可供对象（指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象）使用的一个区域。
Memory:
PoolNonpagedBytes的计数方式与Process:
PoolNonpagedBytes的计数方式不同，因此可能不等于PoolNonpagedBytes:
_Total。
这个计数器仅显示上一次观察的值；而不是一个平均值。
PhysicalDisk
的使用
%DiskTime
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
请谨慎对待%DiskTime计数器。
因为该计数器的_Total实例不能精确反映多磁盘系统的利用率，因此使用%IdleTime计数器也非常重要。
%IdleTime
汇报在实例间隔时磁盘闲置时间的百分比。
DiskReads/sec
指在此盘上读取操作的速率。
DiskWrites/sec
指在此盘上写入操作的速率。
PhysicalDisk的瓶颈
Avg.DiskQueueLength（所有实例）
指读取和写入请求（为所选磁盘在实例间隔中列队的）的平均数。
System
FileDataOperations/sec
指在计算机的所有逻辑磁盘上读取和写入操作的综合速度。
这是系统的逆转率：
每秒钟的文件控制操作。
这个总值显示了上两个实例中观察到的值的差异除于实例间隔的时间。
ProcessorQueueLength
是指处理列队中的线程数。
即使在有多个处理器的计算机上处理器时间也会有一个单列队。
不象磁盘计数器，这个计数器仅计数就绪的线程，而不计数运行中的线程。
如果处理器列队中总是有两个以上的线程通常表示处理器堵塞。
这个计数器仅显示上一次观察的值；而不是一个平均值。
网络使用
NetworkSegment\%NetUtilization
网络吞吐量
协议传输计数器（随网络协议而改变）；对于TCP/IP：
NetworkInterface\Bytestotal/sec
NetworkInterface\Packets/sec
Server\BytesTotal/secorServer\BytesTransmitted/sec和Server\BytesReceived/sec
可能需要监视网络的其他对象或服务器吞吐量，如监视网络活动中所述。
WEB服务器
计数器
描述
参考值
Processor:
%ProcessorTime
CPU使用率，如果一个或多个处理器的该数值持续超过90%，则表示CPU是瓶颈。
小于75%。
排除内存因素，如果该计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU瓶颈。
Processor:
%UserTime
表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。
如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值
Memory:
AvailableMbytes
物理内存的可用。
至少要有10%的物理内存值。
如果AvailableMbytes的值很小（4MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
Memory:
CacheBytes
文件系统缓存。
默认情况下为50%的可用物理内存。
A:
RequestsQueued
由于处理请求的服务器资源不足而未执行的请求总数。
RequestQueued在理想状况下应该接近0，如果这两个值太大，那么需要重写代码提高性能。
A:
RequestExecutionTime
执行最近的请求所用的毫秒数。
ASP.NETApplications：
Request/Sec
每秒执行的请求数。
它表示应用程序的当前吞吐量。
在恒定负载下，此数值应处于特定的范围内（不包含其他的服务器工作，如垃圾回收、缓存清理线程和外部服务器工具等）。
如果Request/Sec的值比较小，Web程序可能是瓶颈。
ASP.NET:
RequestWaitTime
队列中的最近请求等待处理的亳秒数。
RequestWaitTime在理想状况下应该接近0，如果这两个值太大，那么需要重写代码提高性能。
ASP.NET:
Requestrejected
由于处理请求的服务器资源不足而未执行的请求总数。
此计数器表示返回503HTTP状态代码（表示服务器太忙）的请求数量。
PhysicalDisk：
%DiskTime
所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比
PhysicalDisk：
AverageDiskQueueLength
指读取和写入请求（为所选磁盘在实例间隔中列队的）的平均数
该值应不超过磁盘数的1.5~2倍
PhysicalDisk：
AverageDiskReadQueueLength
指读取请求（为所选磁盘在实例间隔中列队的）的平均数。
两者相加，应小于磁盘设备最大容量。
PhysicalDisk：
AverageDiskWriteQueueLength
指写入请求（为所选磁盘在实例间隔中列队的）的平均数。
PhysicalDisk：
AverageDisksec/Read
指以秒计算的在此盘上读取数据的所需平均时间。
PhysicalDisk：
AverageDisksec/Transfer
指以秒计算的在此盘上写入数据的所需平均时间。
PhysicalDisk：
DiskRe
升级会员 