性能测试作业指导书文档格式.doc
《性能测试作业指导书文档格式.doc》由会员分享，可在线阅读，更多相关《性能测试作业指导书文档格式.doc（23页珍藏版）》请在冰点文库上搜索。
第5章、测试业务用例准备 9
第6章、测试环境准备 10
第7章、测试脚本开发调试 11
第8章、配置场景 12
第9章、执行测试 13
第10章、生成测试报告 14
第11章、测试结果分析产生调优建议 15
第12章、项目结束经验总结 16
第1章、引言
文档用途
根据公司性能测试项目需要，在这里对性能测试项目的过程和具体执行方法进行规范性的描述，在本文中对项目的申请、确认、接受、执行到项目的结束总结做了规范性的描述，在具体操作用根据项目的情况可以做适当的裁剪。
阅读对象
l项目经理
l性能测试工程师
l需求人员
名词术
l性能测试评测系统综合能力的测试，评测系统在模拟环境中变现出来的性能
l负载测试在一定压力下连续运行一段时间的测试
lVU虚拟用户
l场景：
是指执行测试的环境等信息，包括要跑那些脚本，在那些机器上运行这些脚本，运行时间，模仿多少个vu等。
l每秒点击数每秒点击次数图将点击（HTTP请求）Web服务器的次数（Y轴）显示为方案已用时间（X轴）的函数。
该图可以查看点击次数对事务性能产生的影响。
第2章、操作流图
启动流程
项目组向测试组提交性能测试申请
需求文档
发布测试版本
项目计划
测试部门对提交需求文档进行确认
对提交版本可测性进行确认
确认是否通过
进入测试准备阶段
测试执行流图
接受测试申请
制定测试计划
研究测试需求，设计测试场景
研发和需求对测试方案评审
研发和需求业务用例和场景设计进行评审
搭建测试环境
部署测试版本
开发测试脚本，
调试测试脚本
场景设计纳入td（testrequire）
准备测试场景（重点对监控内容汝何收集数据）
测试内部对脚本评审优化
执行测试
出测试报告，性能分析报告，调整建议
开发和业务对测试结果review
项目总结报告（对出现问题和好的经验进行总结）
根据场景设计业务测试用例
业务和功能测试人员对业务测试用例评审
业务用例纳入td（testplan）
测试脚本纳入testlab管理
测试内部总结
第3章、性能测试申请
性能测试需要项目组根据项目需要向测试部门提出测试申请同时提交如下可见物并提供需要测试的范围及测试完成的标准和时间。
l项目需求文档
l项目设计开发文档
l项目计划，增加一个里程碑，标示出可以开始进行性能测试的版本
l稳定的release可测物
第4章、测试项目确认
在项目组根据项目需要提交测试申请时，需要提交性能测试需要的文档（或会议方式划定测试范围，环境，系统版本等要求），针对这些文档，对此项目进行性能测试前的可测性确认。
性能测试目标和范围确认
性能测试策略
预期指标的性能测试
独立/组合业务场景性能测试
强度测试/大数据量性能测试
网络性能测试
服务器性能指标监测
需求文档确认
检查需求文档中对性能需求的要求，用户使用环境，当前用户支持量，将来预计用户支持数量，为测试场景设计提供依据。
l需求中对业务功能的描述
l需求中对支持用户量的描述
l需求中对系统运行环境描述
l需求中对系统性能要求的描述（响应时间等）
目前公司的项目中的需求文档，更多的体现在功能需求上，在非功能需求描述得非常的少，增加一个CheckList供PM和功能测试Lead参考
所以在性能测试时候无可参考物，目标很模糊，除了文档确认方式外，对小项目应该会议沟通确认方式确定性能部分的需求。
总体设计文档确认
确认对能够根据文档内容对系统的架构有清晰的认识，能够根据该文档的描述来判断性能测试的监控点。
l清楚确认系统运行环境（操作系统，webserver，dbserver）
l清楚确认系统的架构
l清楚确认系统的部署情况
项目计划确认
根据对需求文档和设计文档估计测试工作量，测试风险等级，对开发/测试计划中的测试时间进行估计确认完成时间
l确认开发/测试计划中的测试进度计划
l确认开发/测试计划中与测试相关描述
系统功能确认
根据提交的测试范围，在测试前对测试范围进行确认（也可由功能测试人员提供测试用例或报告）在这部分确认中，功能测试工程师应该提供数据证明实际交付测试版功能上能够实现，
第5章、制定测试计划
测试需求，测试资源，职责，测试里程碑，测试执行，测试风险，测试验收标准，培训。
l确定性能测试需求
l确定性能测试需要的资源
l确定性能测试参与人员的工作职责
l确定性能测试过程中的阶段里程碑
l确定性能测试执行计划
l预估性能测试过程中风险
l确定性能测试完成的验收标准
l安排性能测试前期的业务，功能，技术的培训
l沟通模式（周报）
性能测试计划模板
第6章、设计测试场景（根据测试需求）
分析测试需求
测试场景是为了满足测试需求的，所以首先要明确需求，分析需求中的测试指标和测试业务环境等方面的需求，分解成对应的场景，一般来说一个大的项目测试场景不应该太多，如果是测试整个系统的性能多使用一个场景来实现，如果测试系统中多个模块测试，对每个模块进行独立的场景设置，一般来说模块的颗粒度不宜太小。
确定场景编号
在确定场景后，在细化场景前，需要给场景定义个唯一的场景编号，所以需要有相应的场景规则作支持
Scenario_name_id
确定测试业务
对需求分析后确定大概的场景后，需要对场景中设计的业务进行明晰出来，清除的描述业务功能，业务针对的性能点
确定测试环境
根据测试需求，准备相应的测试服务器，测试服务器需要采用实际上线用的服务一致为好，这样可以真实体现未来上线后的设备所能支撑的性能。
如果实在没有一样的服务一器，考虑配置模仿方式，比例压缩环境需求
确定测试数据
如果测试用户查询等模块，尤其是对数据库查询，插入等数据操作时候，要根据用户需求判断数据库表中正常运行时，表中的数据量，在测试环境中需模拟数据量
确定场景时间方案
时间方案，是场景在加压方式，例如一次加压，持续加压，停止方式，加压时间，启动时间等配置
确定vu启动数量
根据需求分析每种业务的压力大小，根据业务比例，系统环境支持等情况设置vu数量，要考虑web服务器支撑的进程数量，数据库的最大连接数等因素。
确定脚本运行设置
脚本运行设置比较麻烦，根据场景的不同需要采用不同的配置，具体操作时候可以参考下表
Menu
Setting
A.Speed
B.Contention
C.Overload
D.Longevity
Controller
#ofIterations
1only
Several
Infinite
RunOptions
Frequencyofoutput:
Sampleonceevery
1second
10seconds
1minute
5minutes
Run-time
Settings
Vusers
max.licensed
#below"
knee"
Logging
Fordebugging
No
ThinkTime
None
Yes
Continueonerror?
NetworkSpeedSimulation
Maximum
Browser（cache）emulation
ContentChecks
Schedule
Ramp-up:
LoadallVuserssimultaneously
Yes
InitializeBeforeRun?
-
Interval（seconds）
4
>
30ormore
测试类型
Speed
Thescriptforeachactionwilllookforsometextoneachresultingpagetoconfirmthattheintendedresultappearsasdesigned
Eachrunidentifiestheminimum,average,median,andmaximumtimesforeachaction.Thisisdonetomakesurethatdataandprocessingofmultipleusersareappropriatelysegregated.
Becausethisformofperformancetestingisperformedforasingleuser（undernootherload）,thisformoftestingexposesissueswiththeadequacyofCPU,diskI/Oaccessanddatatransferspeeds,anddatabaseaccessoptimizations.
Contentiontest
Thisformofperformancetestaimstofindperformancebottlenecks（suchaslock-outs,memoryleaks,andthrashing）causedbyasmallnumberofVuserscontendingforthesameresources.
Eachrunidentifiestheminimum,average,median,andmaximumtimesforeachaction.Thisisdonetomakesurethatdataandprocessingofmultipleusersareappropriatelysegregated.
Suchtestsidentifythelargestburst（spike）oftransactionsandrequeststhattheapplicationcanhandlewithoutfailing.Suchloadsaremorelikethearrivalratetowebserversthanconstantloads.
Overload:
test
Thisformofperformancetestingdetermineshowwellthenumberofusersanticipatedcanbesupportedbythehardwarebudgetedfortheapplication.
Thegoalistoquantifythedegradationinresponsetimeandresourceconsumptionatvariouslevelsofsimultaneoususers.Thisisdonebygraduallyramping-upthenumberofVusersuntilthesystem"
chokes"
atabreakpoint（whenthenumberofconnectionsflattenout,responsetimedegradesortimesout,anderrorsappear）.
Duringtests,theresourcesusedbyeachserveraremeasuredtomakesurethereisenoughtransientmemoryspaceandadequatememorymanagementtechniques.
Thiseffortmakessurethatadmissioncontroltechniqueslimitingincomingworkperformasintended.ThisincludesdetectionofandresponsetoDenialofService（DoA）attacks.
Longevity:
Test
Thisformofperformancetestingmakessurethatthesystemcansustain--overatleasta24hourperiod--aconsistentnumberofconcurrentVusersexecutingtransactionsusingnearpeakcapacity.
Becauselongertestsusuallyinvolveuseofmorediskspace,thesetestrunsalsomeasurethepatternofbuild-upin"
cruft"
（obsoletelogs,intermediatedatastructures,andstatisticaldatathatneedtobeperiodicallypruned）.
Longerrunsallowforthedetectionandmeasurementoftheimpactofoccasionalevents（suchasJavaFullGCandlogtruncations）andanomaliesthatoccurinfrequently.
Thesetestsverifiesprovisionsformanagingspace,suchaslogtruncation"
cron"
jobsthatnormallysleeps,butawakeatpredeterminedintervals（suchasinthemiddleofthenight）.
确定负载生成器设置
如果我们需要运行很多vu（虚拟用户）的时候我们需要考虑分散在不同的负载生成器上去运行，应该让负载生成器有良好的配置（memory,cpu）和很好的性能，以足够支持测试的需要,需要配置的是机器名称，运行平台，临时目录，以及vu限制，防火墙，运行文件存储和unix环境的配置等（这些在帮助中有明确的说明，根据实际情况进行配置）
确定监控服务器
根据被测试系统的部署情况以及采用架构，确定需要被监控的服务器，首先我们要确定控制台能够访问这台机器（有相应的权限和网络连接），其次我们要确定我们能够采集到这些机器上运行的服务的数据，需要根据不同的服务进行相应的配置，例如apache的采集需要配置apache自身的监控，unix系统的数据采集需要启动rpc端口和rstatd守候进程等。
具体的操作实现可以参考资源监控说明的附件
确定监控计数器
确定要收集的指标，这个非常重要也有一定的难度，我们需要对系统的性能指标有一定的了解，通常loadrunner对每个监控对象提供了大量的计数器，我们要在其中找到我们需要的，不一定要全部收集。
测试场景review
参加人：
测试经理，测试设计人员，项目经理，系统架构师，业务人员
输入：
测试场景设计文档
活动：
场景设计人员讲解场景描述
业务人员对场景中业务范围评审，
架构师对场景中环境搭建和监控采集指标进行评审
项目经理和测试经理对场景执行时间进行评审
输出：
评审结果表
场景id
设计人
性能测试
需求描述
业务描述：
环境描述：
预期性能：
测试环境
应用服务器
网络配置
数据库服务
Web服务器
其它
运行业务测试用例
业务id
业务描述
Vu数量
运行时设置
业务1
Runlogic
Log
Pracing
Thinkingtime
Miscellaneous
BrowserEmulation
Internetprotocol
业务2
业务3
业务4
场景时间方案
方案定义：
schedulebyscenarioorbygroup
Starttime:
Rampup:
Duration:
Rampdown:
Initializeall:
监控配置
监控点
监控类型
监控计数器
服务器类型
数据库
Ip：
192.168.9.1
内存
磁盘读写
Cpu
数据库专用指标
%TotalProcessorTime（NT）
%ProcessorTime（Win2000）
I/O-OutstandingReads
I/O-Transactions/sec
UserConnections
服务器类型：
IISweb服务器
Web服务器专项指标
BytesReceived/sec
GetRequests/sec
PostRequests/sec
MaximumConnections
CurrentConnections
NotFoundErrors/sec
业务应用服务器指标
1、%totalprocessortime
2、%ProcessorTime（Windows2000）
3、ProcessorQueueLength
网络设备监控
数据吞吐
设备缓存
等
场景设计模版
（一）
注：
监控配置是性能测试中非常重要的一部分工作，使否检测到关键的、有效的数据，决定了能够根据测试结果分析并定位系统的瓶颈在那里。
第7章、测试场景-设计业务用例
准备业务用例
准备业务用例是根据场景中的业务要求来准备的，这里所要完成的主要是对业务操作的分解细化业务在系统中实现中的每一步。
确定事务
在业务操作中可能有很多我们不关系的动作，比如一些进入事务操作界面的动作都是我们不关心的，我们把业务提交的动作作为一个事务，我们需要监控的正是这些事务的性能和对系统的压力
确定事务中需参数的数据
在确定事务后，对事物中的数据确定是否要进行参数化（例如读帖操作，需要初始化帖子id）
确定用例id和事务id的规则
用例id：
uc_XXX_id
事务id：
trans_XXX_id
业务用例和场景review
测试经理，测试设计人员，项目经理，业务人员
测试用例设计文档
场景设计人员讲解业务用例
业务人员对场景中业务操作评审
Devliverables：
在TD的Requirements中体现
性能测试用例模板
用例id
tester
用例描述
用户登录后查询国际机票信息
步骤id
操作
是否为事务（事务id）
是否有参数化
Step1
点登陆按钮
Tran_login_001
用户名/密码
Step2
录入关键字
N
Step3
提交查询按钮
Trans_search_002
查询关键字
第8章、测试场景-环境准备
测试环境准备包括硬件准备，软件准备，以及根据用例分析所要做的数据准备工作，测试准备工作主要依赖场景设计，来具体实施
硬件准备
l被测试系统需要部署的服务器（WebServer，DbServer，ApplicationServer）
l负载生成器的设备（每台机器最多跑80个vu，具体根据vu的业务操作情况）
l负载控制器的设备
l网络环境模拟（根据测试需求采用模拟方式部署设备）
软件准备
l测试工具的安装
lWebServer的配置安装
lDbServer的配置安装
lApplicationServer的配置安装
l监控的配置详细内容见《Loadrunner监控的配置》加在附件之中，进行整理
数据准备
l分析业务要求准备需要参数化的数据
l根据测试范围的需要在数据库中准备响应数量的数据
l根据测试范围的需要准备响应的vu登录帐户数据
根据场景中设计要监控的点进行采集配置，每种监控类型都有不同的配置方式，有些需要在监控点起来一些守候进程，有些要在监控点起来写监控端口，有些需要安装loadrunner插件，在实际应用中需要考虑具体情况具体实施
第9章、测试场景-测试脚本开发（业务用例脚本化）
录制脚本
脚本录制需要注意录制前的配置，在这里我们主要针对Http协议，因为这是我们项目最常用到的一种协议。
完善脚本
l插入事务
l插入集合点
l模拟用户思考时间
l参数化输入
l插入text/image检查点
l关联语句
lRun-timesetting选项
l注释
详细见TheVuGenScriptFileDevelopmentProcess这篇文档附件
第10章、测试场景-场景配置
升级会员 