性能测试作业指导书docx.docx

1、性能测试作业指导书docx性能测试作业指导书版本V1.02006/10/25文档修订摘要日期修订号描述著者审阅者日期2006/10/251创建文档，完成目录划分，完成Jianyu.dong2006/11/2121、 修改执行流程，拆分测试用例设计为测试场景设计利测试业务用例设计2、 建立完善测试场景设计内容3、 完善业务测试用例设计内容4、 完善执行测试内容5、 完善结果分析调优部分内容6、 增加需求checkList附件7、 增加场景设计模版8、 增加业务用例设计模版9、 增加测试报告模版10、 増加测试计划模版Jianyu.dong第1章、引言 4文档用途 4阅读对彖 4名词术 4第2章、

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章.引言文档用途根据公司性能测试项目需要，在这里对性能测试项口的过程和具体执行方法进 行规范性的描述，在本文屮对项冃的巾请、确认、接受、执行到项冃的结束总

3、结做 了规范性的描述，在具体操作用根据项日的情况可以做适当的裁剪。阅读对象项目经理性能测试工程师需求人员名词术性能测试 评测系统综介能力的测试，评测系统在模拟环境中变现出來的性能负载测试 在一定圧力下连续运行一段时间的测试VU 虚拟用户场景： 是指执行测试的环境等信息,包括要跑那些脚木，在那些机器上运行这些脚本，运行时间，模仿多少个VU等。每秒点击数每秒点击次数图将点击（HTTP请求）Web服务器的次数（Y轴） 显示为方案已用时间（X轴）的函数。该图对以查看点击次数对事务性能产 生的影响。第2章.操作流图启动流程测试执行流图第3章、性能测试申请性能测试需要项H组根据项目需要向测试部门提出测试申

4、请同时提交如下可见物 并提供需要测试的范围及测试完成的标准和时间。项目需求文档项目设计开发文档项li计划，增加一个里程碑，标示出可以开始进行性能测试的版本稳定的release町测物第4章.测试项目确认在项日组根据项日需要提交测试川请时，需要提交性能测试需要的文档（或会议方式划定测 试范围，环境，系统版木等要求），针对这些文档，对此项日进行性能测试前的可测性确认。性能测试目标和范围确认性能测试策略预期指标的性能测试独立/组合业务场景性能测试 强度测试/大数据虽性能测试 网络性能测试服务器性能指标监测需求文档确认检查需求文档中对性能需求的要求，用户使用环境，当前用户支持最，将來预计用 户支持数量，

5、为测试场景设计提供依据。需求中对业务功能的描述需求中对支持用户量的描述需求中对系统运行环境描述需求中对系统性能要求的描述（响应时间等）批注E1 :增加-个CheckList供PM和功能测试Lead参考H前公司的项H中的需求文档，更多的体现在功能需求上，在非功能需求描述得非 常的少，所以在性能测试时候无可参考物，日标很模糊，除了文档确认方式外，对一 小项II应该会议沟通确认方式确定性能部分的需求。总体设计文档确认确认对能够根据文档内容对系统的架构有消晰的认识，能够根据该文档的描述来判 断性能测试的监控点。淸楚确认系统运彳亍环境（操作系统，webserver, dbserver ）清楚确认系统的架

6、构清楚确认系统的部署悄况项目计划确认根据对需求文档和设计文档估计测试工作量，测试风险等级，对开发/测试计划中 的测试时间进行估计确认完成时间确认开发/测试计划中的测试进度计划确认开发/测试计划小与测试相关描述系统功能确认根据提交的测试范围，在测试前对测试范围进行确认（也可由功能测试人员捉供测 试用例或报告）在这部分确认中，功能测试工程师应该提供数据证明实际交付测试 版功能上能够实现，第5章.制定测试计划测试需求，测试资源，职责，测试里程碑，测试执行，测试风险，测试验收标准, 培训。确定性能测试需求确定性能测试需要的资源确定性能测试参与人员的工作职责确定性能测试过程中的阶段里程碑确定性能测试执行

7、计划预估性能测试过程中风险确定性能测试完成的验收标准安排性能测试前期的业务，功能，技术的培训沟通模式（周报）性能测试计划模板第6章.设计测试场景（根据测试需求）分析测试需求测试场景是为了满足测试需求的，所以首先耍明确需求，分析需求中的测试指标和测试业务 环境等方面的需求，分解成对应的场景，-般来说一个大的项忖测试场景不应该A多，如果 是测试聖个系统的性能多使用一个场呆來实现，如果测试系统中多个模块测试，对每个模块 进行独立的场景设置，一般来说模块的颗粒度不宜太小。确定场景编号在确定场景后，在细化场景前，需要给场景定义个唯一的场景编号，所以需要有相应的场景 规则作支持Scenario_name_

8、id确定测试业务对需求分析后确泄人概的场景后，需要对场景中设计的业务进行明晰出来，消除的描述业务 功能，业务针对的性能点确定测试环境根据测试需求，准备相应的测试服务器，测试服务器需要采用实际上线用的服务致为好, 这样可以貞实体现未來上线后的设备所能支撑的性能。如果实在没有-样的服务-器，考虑 配置模仿方式，比例压缩环境需求确定测试数据如果测试用户査询等模块,尤英是对数据悴査询,插入等数据操作时候，要根据用户需求判 断数据库表中正常运行时，表中的数据量，在测试环境中需模拟数据量确定场景时间方案时间方案，是场景在加压方式，例如-次加压，持续加压，停止方式，加压时间，启动时间 等配置确定VU启动数量

9、根据需求分析每种业务的压力人小，根据业务比例，系统环境支持等情况设置VU数量，耍 考龙web服务器支撐的进程数量，数据库的最大连接数等因素。确定脚本运行设置脚本运行设世比较麻烦，根据场景的不同需要采用不同的配此 具体操作时候可以参考下表MenuSettingd SpeedContention2OverloadLonqevitvController# of Iterations1 onlySeveralInfiniteRunOptionsFrequency of output:Sample once every1 second10 seconds1 minute5 minutesRun-time

10、SettingsVusers1 onlymax. licensed# below knee*LoggingFor debuggingNoThink TimeNoneYesContinueon error?NoYesNetwork SpeedSimulationMaximumNoBrowser (cache)emulationNoYosContent ChecksYesNoScheduleRamp up：Load all Vusers simultaneouslyYesInitialize Before Run?NoYesNo-Interval (seconds)4430 or more测试类型

11、描述SpeedThe script for each action will look for some text on each resulting page to confimi that the intended result appears as designedEach run identifies the minimum, average, median, and maximum times lor each action. This is done to make sure that data and processing of multiple users are approp

12、riately segregated.Because this fonn of perfonnance testing is performed for a single user (under no other load), this form of testing exposes issues with the adequacy of CPU, disk I/O access and data transfer speeds, and database access optimizationsContention testThis form of performance test aims

13、 to find performance bottlenecks (such as lock-outs, memory leaks, and thrashing) caused by a small number of Vusers contending for the same resources.Each run identifies the minimum, average, median, and maximum times for each action. This is done to make sure that data and processing of multiple u

14、sers are appropriately segregatedSuch tests identify the largest burst (spike) of transactions and requests that the application can handle without failing Such loads are more like the arrival rate to web servers than constant loads.Overload:testThis foim of performance testing determines how well t

15、he number of users anticipated can be supported by the hardware budgeted for the application.The goal is to quantify the degradation in response time and resource consumption at various levels of simultaneous users. This is done by gradually ramping-up the number of Vusers until the system chokes at

16、 a breakpoint (when the number of connections flatten out, response time degrades or times out, and errors appear)During tests, the resources used by each server arc measured to make sure therc is enough transient memory space and adequate memory management techniques This effort makes sure that adm

17、ission control techniques limiting in coming work perform as intended This includes detection of and response to Denial of Service (DoA) attacksLongevity:TestThis form of perfoimance testing makes sure that the system can sustain 一 over at least a 24 hour period - a consistent number of concurrent V

18、users executing transactions using near peak capacityBecause longer tests usually involve use of more disk space, these test runs also measure the pattern of build-up in cruft” (obsolete logs, intermediate data structures, and statistical data that need to be periodically pruned).Longer runs allow f

19、or the detection and measurement of the impact of occasional events (such as Java Full GC and log tmneations) and anomalies that occur infrcqucntl y.These tests verifies provisions for managing space, such as log truncation cron” jobs that nonnally sleeps, but awake at predetermined intervals (such

20、as in the middle of the night).确定负载生成器设置如果我们需要运行很多VU （虚拟用八）的时候我们需要考虑分散在不同的负载牛成器上去 运行，应该让负载生成器有良好的配置（mcmmycpu）和很好的性能，以足够支持测试的需 要，需要配置的是机器名称，运行平台，临时目录，以及vu限制，防火墙，运行文件存储和 unix环境的配置等（这些在帮助中有明确的说明，根据实际情况进行配置）确定监控服务器根据被测试系统的部署情况以及采用架构，确定需要被监控的服务器，首先我们要确定控制 台能够访问这台机器（有相应的权限和网络连接），其次我们要确定我们能够采集到这些机 器上运行的服务的

21、数据，需要根据不同的服务进行相应的配置，例如apache的采集需耍 配置apache自身的监控，unix系统的数据采集需要启动rpc端口和rstatd守候进程等。具体 的操作实现可以参考资源监控说明的附件确定监控计数器确定要收集的指标，这个非常重要也有一定的难度，我们需要对系统的性能指标有一定的了 解，通常loadrunner对每个监控对象提供了大星的计数器，我们要在其小找到我们需要的， 不一定要全部收集。测试场景review参加人：测试经理，测试设计人员，项目经理，系统架构师，业务人员输入：测试场景设计文档活动：场景设计人员讲解场景描述业务人员对场景中业务范围评审，架构师対场景中环境搭建和监

22、控采集指标进行评审项目经理和测试经理对场景执行时间进行评审输出：评审结果表场景id设计人性能测试 需求描述业务描述：环境描述：预期性能：测试环境应用服务器网络配置数据库服务Web服务器其它运行业务 测试用例业务id业务描述Vu数量运行时设置业务1Run logicLogPracingThinking time业务2业务3业务4MiscellaneousBrowser EmulationInternet protocol场景时间 方案方案定义： schedule by scenario or by group Start time :Ramp up :Duration:Ramp down:Ini

23、tialize all:监控配置监控点监控类型监控计数器服务器类型 数据库Ip： 192.168.9.1内存 磁盘读写 Cpu数据库专 用指标% Total Processor Time (NT) % Processor Time (Win 2000) I/O - Outstanding Reads I/O Transactions/secUser Connections服务器类型： US web服务 器Ip：192.168.9.1内存 磁盘读写CpuWeb服务器 专项指标Bytes Received/sec Get Requests/sec Post Requests/sec Maximum

24、 Connections Current Connections Not Found Errors/sec服务器类型： 应用服务器Ip： 192.168.9.1内存磁盘读写Cpu业务应用 服务器指 标k % total processor time2、 % Processor Tim e (Window s 2000)3、 Processor Queue Length网络设备监控数据吞吐 设备缓存 等场景设计模版（一）注：监控配置是性能测试中非常巫要的部分匸作,使否检测到关键的、有效的数据,决定 了能够根据测试结果分析并定位系统的瓶颈在那里。第7章.测试场景-设计业务用例准备业务用例准备业务用

25、例是根据场景中的业务要求来准备的，这里所耍完成的主要是对业务操作的分解 细化业务在系统屮实现中的每一步。确定事务在业务操作中对能有很多我们不关系的动作，比如一些进入事务操作界而的动作都是我们不 关心的，我们把业务提交的动作作为一个事务，我们需要监控的正是这些事务的性能和对系 统的压力确定事务中需参数的数据在确定事务后，对事物中的数据确圧是否要进行参数化（例如读帖操作，需要初始化帖了 id）确定用例id和事务id的规则用例 id : uc_XXX_id專务 id : trans_XXX_id业务用例和场景review参加人：测试经理，测试设计人员，项日经理，业务人员输入：测试用例设计文档活动：场

26、景设讣人员讲解业务用例业务人员对场景中业务操作评审输岀:评审结果表Devliverables:在 TD 的 Requirements 中体现性能测试用例模板用例idtester设计人用例描述用户登录后査询国际机票信息步骤id操作是否为事务（事务id）是否有参数化Stepl点登陆按钮Tran login 001用户名/密码Step2录入关键字NNStep3提交查询按钮Trans search 002杏询关键字第8章.测试场景-环境准备测试环境准备包括换件准备，软件准备，以及根据用例分析所要做的数据准备匸作，测试准 备工作主要依赖场景设计，來具体实施硬件准备被测试系统需要部署的服务器（Webser

27、ver , DbServer , ApplicationServer）负载生成器的设备（每台机器报多跑80个vu,具体根据vu的业务操作情况）负载控制器的设备网络环境模拟（根据测试需求采川模拟方式部署设备）软件准备测试工具的安装Webserver的配置安装DbServer的配置安装ApplicationServfer 的配置安装监控的配置 详细内容见ILoadrunner监控的配置数据准备分析业务要求准备需要参数化的数据根据测试范围的需要在数据库中准备响应数虽的数据根据测试范围的需耍淮备响应的VU登录帐户数据监控配置根据场景中设计要监控的点进行采集配置，每种监控类型都有不同的配置方式，有 些需

28、要在监控点起来一些守候进程，有些要在监控点起来写监控端口，有些需要女装 loadrunner插件，在实际应用中需要考虑具体情况具体实施第9章.测试场景-测试脚本开发（业务用例脚本化）录制脚本脚本录制需要注意录制询的配置，在这里我们主耍针对Http协议，因为这是我们项口 最常用到的一种协议。完善脚本插入事务插入集合点模拟用户思考时间参数化输入插入text/image检查点关联语句Run-time setting 选项注释批注|E3|:附件详细见 The VuGen Script File Development Process 这篇文料场景是业务用例的组合模拟一定真实会出现的悄况，场景出了选择合

29、适的业务用例（也就是 对应的脚本）已经运行模拟用户的数量外，还要考虑压力的方式，如场景运行时间，场景持 续加压模式。确定压力点（确定VU数量）场景小每种业务的VU数量应该是按比例存在的，根据业务需求计算出总VU数量的理论值, 在这个值的配置下运行场景，监控被加压的web服务的响应时间，以及web服务所在服务 器的资源情况，如果web服务所在服务器资源还没有被完全占用的惜况下，web服务已经开始出现错 误相应，需要检查web服务的配置例如web服务限制的进程数量等。如果web服务所在服务器资源还被完全占用的情况下，说明服务器的配置，所能支撑 的我们业务数量大不到理论值如果爭务响应时间没有达到要求

30、，首先确认服务器的资源，确认资源并没有占用的情况 下，考虑事务的执行过程（是否有数据库的调用），确认数据库的性能，如果数据库性 能正常，检查程序。确定负载模式在施加压力时候可以持续加压也可以一次加压到位。一般我们采取持续加压的方式，这样比 较能够情况的看到系统资源在前期加压时随着加压资源波动情况。对我们不关心的操作基本都在脚本的vu_init中，所以，建议在设置场景时候选择全部初始 化，以免对资源监控时候产生误差。确定监控点这个非常重要，在场景运行前要确认监控那些内容，如何确定是根据系统架构和部署来确定的在web应用中我们需婆监控的如下：Web服务Web服务所在的服务器数据库服务数据库所在服务器貝