性能测试作业指导书docx.docx
《性能测试作业指导书docx.docx》由会员分享，可在线阅读，更多相关《性能测试作业指导书docx.docx（24页珍藏版）》请在冰豆网上搜索。
性能测试作业指导书docx
性能测试作业指导书
版本V1.0
2006/10/25
文档修订摘要
日期
修订号
描述
著者
审阅者
日期
2006/10/25
1
创建文档，完成目录划分，完成
Jianyu.dong
2006/11/21
2
1、修改执行流程，拆分测试用例设计为测试场
景设计利测试业务用例设计
2、建立完善测试场景设计内容
3、完善业务测试用例设计内容
4、完善执行测试内容
5、完善结果分析调优部分内容
6、增加需求checkList附件
7、增加场景设计模版
8、增加业务用例设计模版
9、增加测试报告模版
10、増加测试计划模版
Jianyu.dong
第1章、引言4
文档用途4
阅读对彖4
名词术4
第2章、操作流图5
启动流程5
测试执行流图5
第3章、性能测试巾请7
第4章、测试项日确认8
需求文档确认8
总体设计文档确认8
开发计划确认8
制定测试计划9
第5章、测试业务用例准备错误！
未定义书签。
第6章、测试环境准备错误！
未定义书签。
第7章、测试脚本开发调试错误！
未定义书签。
第8章、配置场景错误！
未定义书签。
第9章、执行测试19
第10章、生成测试报告21
第11章、测试结果分析产生调优建议22
第12章、项H结束经验总结23
第1章.引言
文档用途
根据公司性能测试项目需要，在这里对性能测试项口的过程和具体执行方法进行规范性的描述，在本文屮对项冃的巾请、确认、接受、执行到项冃的结束总结做了规范性的描述，在具体操作用根据项日的情况可以做适当的裁剪。
阅读对象
•项目经理
•性能测试工程师
•需求人员
名词术
•性能测试评测系统综介能力的测试，评测系统在模拟环境中变现出來的性能
•负载测试在一定圧力下连续运行一段时间的测试
•VU虚拟用户
•场景：
是指执行测试的环境等信息,包括要跑那些脚木，在那些机器上运
行这些脚本，运行时间，模仿多少个VU等。
•每秒点击数每秒点击次数图将点击（HTTP请求）Web服务器的次数（Y轴）显示为方案已用时间（X轴）的函数。
该图对以查看点击次数对事务性能产生的影响。
第2章.操作流图
启动流程
测试执行流图
第3章、性能测试申请
性能测试需要项H组根据项目需要向测试部门提出测试申请同时提交如下可见物并提供需要测试的范围及测试完成的标准和时间。
•项目需求文档
•项目设计开发文档
•项li计划，增加一个里程碑，标示出可以开始进行性能测试的版本
•稳定的release町测物
第4章.测试项目确认
在项日组根据项日需要提交测试川请时，需要提交性能测试需要的文档（或会议方式划定测试范围，环境，系统版木等要求），针对这些文档，对此项日进行性能测试前的可测性确认。
性能测试目标和范围确认
性能测试策略
预期指标的性能测试
独立/组合业务场景性能测试强度测试/大数据虽性能测试网络性能测试
服务器性能指标监测
需求文档确认
检查需求文档中对性能需求的要求，用户使用环境，当前用户支持最，将來预计用户支持数量，为测试场景设计提供依据。
•需求中对业务功能的描述
•需求中对支持用户量的描述
•需求中对系统运行环境描述
•需求中对系统性能要求的描述（响应时间等）
批注[E1]:
增加-个CheckList供PM
和功能测试Lead参考
H前公司的项H中的需求文档，更多的体现在功能需求上，在非功能需求描述得非常的少，所以在性能测试时候无可参考物，日标很模糊，除了文档确认方式外，对一小项II应该会议沟通确认方式确定性能部分的需求。
总体设计文档确认
确认对能够根据文档内容对系统的架构有消晰的认识，能够根据该文档的描述来判断性能测试的监控点。
•淸楚确认系统运彳亍环境（操作系统，webserver,dbserver）
•清楚确认系统的架构
•清楚确认系统的部署悄况
项目计划确认
根据对需求文档和设计文档估计测试工作量，测试风险等级，对开发/测试计划中的测试时间进行估计确认完成时间
•确认开发/测试计划中的测试进度计划
•确认开发/测试计划小与测试相关描述
系统功能确认
根据提交的测试范围，在测试前对测试范围进行确认（也可由功能测试人员捉供测试用例或报告）在这部分确认中，功能测试工程师应该提供数据证明实际交付测试版功能上能够实现，
第5章.制定测试计划
测试需求，测试资源，职责，测试里程碑，测试执行，测试风险，测试验收标准,培训。
•确定性能测试需求
•确定性能测试需要的资源
•确定性能测试参与人员的工作职责
•确定性能测试过程中的阶段里程碑
•确定性能测试执行计划
•预估性能测试过程中风险
•确定性能测试完成的验收标准
•安排性能测试前期的业务，功能，技术的培训
•沟通模式（周报）
性能测试计划模板
第6章.设计测试场景（根据测试需求）
分析测试需求
测试场景是为了满足测试需求的，所以首先耍明确需求，分析需求中的测试指标和测试业务环境等方面的需求，分解成对应的场景，--般来说一个大的项忖测试场景不应该A多，如果是测试聖个系统的性能多使用一个场呆來实现，如果测试系统中多个模块测试，对每个模块进行独立的场景设置，一•般来说模块的颗粒度不宜太小。
确定场景编号
在确定场景后，在细化场景前，需要给场景定义个唯一的场景编号，所以需要有相应的场景规则作支持
Scenario_name_id
确定测试业务
对需求分析后确泄人概的场景后，需要对场景中设计的业务进行明晰出来，消除的描述业务功能，业务针对的性能点
确定测试环境
根据测试需求，准备相应的测试服务器，测试服务器需要采用实际上线用的服务•致为好,这样可以貞•实体现未來上线后的设备所能支撑的性能。
如果实在没有-•样的服务-•器，考虑配置模仿方式，比例压缩环境需求
确定测试数据
如果测试用户査询等模块,尤英是对数据悴査询,插入等数据操作时候，要根据用户需求判断数据库表中正常运行时，表中的数据量，在测试环境中需模拟数据量
确定场景时间方案
时间方案，是场景在加压方式，例如-•次加压，持续加压，停止方式，加压时间，启动时间等配置
确定VU启动数量
根据需求分析每种业务的压力人小，根据业务比例，系统环境支持等情况设置VU数量，耍考龙web服务器支撐的进程数量，数据库的最大连接数等因素。
确定脚本运行设置
脚本运行设世比较麻烦，根据场景的不同需要采用不同的配此具体操作时候可以参考下表
Menu
Setting
dSpeed
Contention
2
Overload
Lonqevitv
Controller
#ofIterations
1only
Several
Infinite
Run
Options
Frequencyofoutput:
Sampleonceevery
1second
10seconds
1minute
5minutes
Run-time
Settings
Vusers
1only
max.licensed
#below"knee*
Logging
Fordebugging
No
ThinkTime
None
Yes
Continueonerror?
No
Yes
NetworkSpeed
Simulation
Maximum
No
Browser（cache）
emulation
No
Yos
ContentChecks
Yes
No
Schedule
Ramp・up：
LoadallVuserssimultaneously
Yes
InitializeBeforeRun?
No
Yes
No
-
Interval（seconds）
4
>4
30ormore
测试类型
描述
Speed
Thescriptforeachactionwilllookforsometextoneachresultingpagetoconfimithattheintendedresultappearsasdesigned
Eachrunidentifiestheminimum,average,median,andmaximumtimesloreachaction.Thisisdonetomakesurethatdataandprocessingofmultipleusersareappropriatelysegregated.
Becausethisfonnofperfonnancetestingisperformedforasingleuser（undernootherload）,thisformoftestingexposesissueswiththeadequacyofCPU,diskI/Oaccessanddatatransferspeeds,anddatabaseaccessoptimizations・
Contentiontest
Thisformofperformancetestaimstofindperformancebottlenecks（suchaslock-outs,memoryleaks,andthrashing）causedbyasmallnumberofVuserscontendingforthesameresources.
Eachrunidentifiestheminimum,average,median,andmaximumtimesforeachaction.Thisisdonetomakesurethatdataandprocessingofmultipleusersareappropriatelysegregated・
Suchtestsidentifythelargestburst（spike）oftransactionsandrequeststhattheapplicationcanhandlewithoutfailing・Suchloadsaremorelikethearrivalratetowebserversthanconstantloads.
Overload:
test
Thisfoimofperformancetestingdetermineshowwellthenumberofusersanticipatedcanbesupportedbythehardwarebudgetedfortheapplication.
Thegoalistoquantifythedegradationinresponsetimeandresourceconsumptionatvariouslevelsofsimultaneoususers.Thisisdonebygraduallyramping-upthenumberofVusersuntilthesystem"chokes"atabreakpoint（whenthenumberofconnectionsflattenout,responsetimedegradesortimesout,anderrorsappear）・
Duringtests,theresourcesusedbyeachserverarcmeasuredtomakesurethercisenoughtransientmemoryspaceandadequatememorymanagementtechniques・Thiseffortmakessurethatadmissioncontroltechniqueslimitingincomingworkperformasintended・ThisincludesdetectionofandresponsetoDenialofService（DoA）attacks・
Longevity:
Test
Thisformofperfoimancetestingmakessurethatthesystemcansustain一overatleasta24hourperiod-aconsistentnumberofconcurrentVusersexecutingtransactionsusingnearpeakcapacity・
Becauselongertestsusuallyinvolveuseofmorediskspace,thesetestrunsalsomeasurethepatternofbuild-upin"cruft”（obsoletelogs,intermediatedatastructures,andstatisticaldatathatneedtobeperiodicallypruned）.
Longerrunsallowforthedetectionandmeasurementoftheimpactofoccasionalevents（suchasJavaFullGCandlogtmneations）andanomaliesthatoccurinfrcqucntly.
Thesetestsverifiesprovisionsformanagingspace,suchaslogtruncation"cron”jobsthatnonnallysleeps,butawakeatpredeterminedintervals（suchasinthemiddleofthenight）.
确定负载生成器设置
如果我们需要运行很多VU（虚拟用八）的时候我们需要考虑分散在不同的负载牛成器上去运行，应该让负载生成器有良好的配置（mcmmycpu）和很好的性能，以足够支持测试的需要，需要配置的是机器名称，运行平台，临时目录，以及vu限制，防火墙，运行文件存储和unix环境的配置等（这些在帮助中有明确的说明，根据实际情况进行配置）
确定监控服务器
根据被测试系统的部署情况以及采用架构，确定需要被监控的服务器，首先我们要确定控制台能够访问这台机器（有相应的权限和网络连接），其次我们要确定我们能够采集到这些机器上运行的服务的数据，需要根据不同的服务进行相应的配置，例如apache的采集需耍配置apache自身的监控，unix系统的数据采集需要启动rpc端口和rstatd守候进程等。
具体的操作实现可以参考资源监控说明的附件
确定监控计数器
确定要收集的指标，这个非常重要也有一定的难度，我们需要对系统的性能指标有一定的了解，通常loadrunner对每个监控对象提供了大星的计数器，我们要在其小找到我们需要的，不一定要全部收集。
测试场景review
参加人：
测试经理，测试设计人员，项目经理，系统架构师，业务人员
输入：
测试场景设计文档
活动：
场景设计人员讲解场景描述
业务人员对场景中业务范围评审，
架构师対场景中环境搭建和监控采集指标进行评审
项目经理和测试经理对场景执行时间进行评审
输出：
评审结果表
场景id
设计人
性能测试需求描述
业务描述：
环境描述：
预期性能：
测试环境
应用服务器
网络配置
数据库服务
Web服务器
其它
运行业务测试用例
业务id
业务描述
Vu数量
运行时设置
业务1
Runlogic
Log
Pracing
Thinkingtime
业务2
业务3
业务4
Miscellaneous
BrowserEmulation
Internetprotocol
场景时间方案
方案定义：
schedulebyscenarioorbygroupStarttime:
Rampup:
Duration:
Rampdown:
Initializeall:
监控配置
监控点
监控类型
监控计数器
服务器类型数据库
Ip：
192.168.9.1
内存磁盘读写Cpu
数据库专用指标
%TotalProcessorTime（NT）%ProcessorTime（Win2000）I/O-OutstandingReadsI/O・Transactions/sec
UserConnections
服务器类型：
USweb服务器
Ip：
192.168.9.1
内存磁盘读写
Cpu
Web服务器专项指标
BytesReceived/secGetRequests/secPostRequests/secMaximumConnectionsCurrentConnectionsNotFoundErrors/sec
服务器类型：
应用服务器
Ip：
192.168.9.1
内存
磁盘读写
Cpu
业务应用服务器指标
k%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）
是否有参数化
Stepl
点登陆按钮
Tranlogin001
用户名/密码
Step2
录入关键字
N
N
Step3
提交查询按钮
Transsearch002
杏询关键字
第8章.测试场景-环境准备
测试环境准备包括换件准备，软件准备，以及根据用例分析所要做的数据准备匸作，测试准备工作主要依赖场景设计，來具体实施
硬件准备
•被测试系统需要部署的服务器（Webserver,DbServer,ApplicationServer）
•负载生成器的设备（每台机器报多跑80个vu,具体根据vu的业务操作情况）
•负载控制器的设备
•网络环境模拟（根据测试需求采川模拟方式部署设备）
软件准备
•测试工具的安装
•Webserver的配置安装
•DbServer的配置安装
•ApplicationServfer的配置安装
•
监控的配置详细内容见I《Loadrunner监控的配置》「
数据准备
•分析业务要求准备需要参数化的数据
•根据测试范围的需要在数据库中准备响应数虽的数据
•根据测试范围的需耍淮备响应的VU登录帐户数据
监控配置
根据场景中设计要监控的点进行采集配置，每种监控类型都有不同的配置方式，有些需要在监控点起来一些守候进程，有些要在监控点起来写监控端口，有些需要女装loadrunner插件，在实际应用中需要考虑具体情况具体实施
第9章.测试场景-测试脚本开发（业务用例脚本化）
录制脚本
脚本录制需要注意录制询的配置，在这里我们主耍针对Http协议，因为这是我们项口最常用到的一种协议。
完善脚本
•插入事务
•插入集合点
•模拟用户思考时间
•参数化输入
•插入text/image检查点
•关联语句
•Run-timesetting选项
•注释
批注|E3|:
附件
详细见TheVuGenScriptFileDevelopmentProcess这篇文料
场景是业务用例的组合模拟一定真实会出现的悄况，场景出了选择合适的业务用例（也就是对应的脚本）已经运行模拟用户的数量外，还要考虑压力的方式，如场景运行时间，场景持续加压模式。
确定压力点（确定VU数量）
场景小每种业务的VU数量应该是按比例存在的，根据业务需求计算出总VU数量的理论值,在这个值的配置下运行场景，监控被加压的web服务的响应时间，以及web服务所在服务器的资源情况，
•如果web服务所在服务器资源还没有被完全占用的惜况下，web服务已经开始出现错误相应，需要检查web服务的配置例如web服务限制的进程数量等。
•如果web服务所在服务器资源还被完全占用的情况下，说明服务器的配置，所能支撑的我们业务数量大不到理论值
•如果爭务响应时间没有达到要求，首先确认服务器的资源，确认资源并没有占用的情况下，考虑事务的执行过程（是否有数据库的调用），确认数据库的性能，如果数据库性能正常，检查程序。
确定负载模式
在施加压力时候可以持续加压也可以一次加压到位。
一般我们采取持续加压的方式，这样比较能够情况的看到系统资源在前期加压时随着加压资源波动情况。
对我们不关心的操作基本都在脚本的vu_init中，所以，建议在设置场景时候选择全部初始化，以免对资源监控时候产生误差。
确定监控点
这个非常重要，在场景运行前要确认监控那些内容，如何确定是根据系统架构和部署来确定
的在web应用中我们需婆监控的如下：
•Web服务
•Web服务所在的服务器
•数据库服务
•数据库所在服务器
貝
升级会员 