性能测试作业指导书.doc

性能测试作业指导书版本 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章、操作流图5启动流程5测试执行流图5第3章、性能测试申请7第4章、测试项目确认8需求文档确认8总体设计文档确认8开发计划确认8制定测试计划8第5章、测试业务用例准备9第6章、测试环境准备10第7章、测试脚本开发调试11第8章、配置场景12第9章、执行测试13第10章、生成测试报告14第11章、测试结果分析产生调优建议15第12章、项目结束经验总结16第1章、 引言文档用途根据公司性能测试项目需要，在这里对性能测试项目的过程和具体执行方法进行规范性的描述，在本文中对项目的申请、确认、接受、执行到项目的结束总结做了规范性的描述，在具体操作用根据项目的情况可以做适当的裁剪。阅读对象l 项目经理l 性能测试工程师l 需求人员名词术l 性能测试 评测系统综合能力的测试，评测系统在模拟环境中变现出来的性能l 负载测试 在一定压力下连续运行一段时间的测试l VU 虚拟用户l 场景： 是指执行测试的环境等信息，包括要跑那些脚本，在那些机器上运行这些脚本，运行时间，模仿多少个vu等。l 每秒点击数 每秒点击次数图将点击（HTTP 请求）Web 服务器的次数（Y 轴）显示为方案已用时间（X 轴）的函数。该图可以查看点击次数对事务性能产生的影响。第2章、 操作流图启动流程 项目组向测试组提交性能测试申请需求文档发布测试版本项目计划测试部门对提交需求文档进行确认对提交版本可测性进行确认确认是否通过进入测试准备阶段测试执行流图接受测试申请制定测试计划研究测试需求，设计测试场景研发和需求对测试方案评审研发和需求业务用例和场景设计进行评审搭建测试环境部署测试版本开发测试脚本，调试测试脚本场景设计纳入td(test require)准备测试场景（重点对监控内容汝何收集数据）测试内部对脚本评审优化执行测试出测试报告，性能分析报告，调整建议开发和业务对测试结果review项目总结报告（对出现问题和好的经验进行总结）根据场景设计业务测试用例业务和功能测试人员对业务测试用例评审业务用例纳入td（test plan）测试脚本纳入test lab管理测试内部总结第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 # of Iterations 1 only Several Infinite Run Options Frequency of output: Sample once every 1 second 10 seconds 1 minute 5 minutes Run-timeSettingsVusers 1 only max. licensed # below knee Logging For debugging No Think Time None Yes Continue on error? No Yes Network Speed Simulation Maximum No Browser (cache) emulation No Yes Content Checks Yes No Schedule Ramp-up: Load all Vusers simultaneously YesInitialize Before Run? No Yes No - Interval (seconds) 4 4 30 or more 测试类型描述SpeedThe script for each action will look for some text on each resulting page to confirm that the intended result appears as designedEach run identifies the minimum, average, median, and maximum times for each action. This is done to make sure that data and processing of multiple users are appropriately segregated.Because this form of performance 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 optimizations.Contention test This form of performance test aims 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 users are appropriately segregated. Such 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 form of performance testing determines how well the 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 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 are measured to make sure there is enough transient memory space and adequate memory management techniques. This effort makes sure that admission control techniques limiting incoming work perform as intended. This includes detection of and response to Denial of Service (DoA) attacks. Longevity:Test This form of performance testing makes sure that the system can sustain - over at least a 24 hour period - a consistent number of concurrent Vusers executing transactions using near peak capacity. Because 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 for the detection and measurement of the impact of occasional events (such as Java Full GC and log truncations) and anomalies that occur infrequently. These tests verifies provisions for managing space, such as log truncation cron jobs that normally sleeps, but awake at predetermined intervals (such as in the middle of the night). 确定负载生成器设置如果我们需要运行很多vu（虚拟用户）的时候我们需要考虑分散在不同的负载生成器上去运行，应该让负载生成器有良好的配置（memory,cpu）和很好的性能，以足够支持测试的需要,需要配置的是机器名称，运行平台，临时目录，以及vu限制，防火墙，运行文件存储和unix环境的配置等 （这些在帮助中有明确的说明，根据实际情况进行配置）确定监控服务器根据被测试系统的部署情况以及采用架构，确定需要被监控的服务器，首先我们要确定控制台能够访问这台机器（有相应的权限和网络连接），其次我们要确定我们能够采集到这些机器上运行的服务的数据，需要根据不同的服务进行相应的配置 ，例如 apache 的采集需要配置apache 自身的监控，unix系统的数据采集需要启动rpc端口和rstatd守候进程等。具体的操作实现可以参考资源监控说明的附件确定监控计数器确定要收集的指标，这个非常重要也有一定的难度，我们需要对系统的性能指标有一定的了解，通常loadrunner对每个监控对象提供了大量的计数器，我们要在其中找到我们需要的，不一定要全部收集。测试场景review参加人：测试经理，测试设计人员，项目经理，系统架构师，业务人员输入：测试场景设计文档活动：场景设计人员讲解场景描述 业务人员对场景中业务范围评审， 架构师对场景中环境搭建和监控采集指标进行评审 项目经理和测试经理对场景执行时间进行评审输出：评审结果表场景id设计人性能测试需求描述业务描述：环境描述：预期性能：测试环境应用服务器网络配置数据库服务Web服务器其它运行业务测试用例业务id业务描述Vu数量运行时设置业务1Run logicLogPracing Thinking time MiscellaneousBrowser EmulationInternet protocol 业务2业务3业务4场景时间方案方案定义： schedule by scenario or by groupStart time :Ramp up :Duration:Ramp down:Initialize all:监控配置监控点监控类型监控计数器服务器类型数据库Ip：内存磁盘读写Cpu数据库专用指标% Total Processor Time (NT)% Processor Time (Win 2000) I/O - Outstanding Reads I/O - Transactions/secUser Connections服务器类型：IIS web服务器Ip：内存磁盘读写CpuWeb服务器专项指标Bytes Received/sec Get Requests/sec Post Requests/sec Maximum Connections Current Connections Not Found Errors/sec 服务器类型：应用服务器Ip：内存磁盘读写Cpu业务应用服务器指标1、%total processor time 2、% Processor Time (Windows 2000) 3、Processor Queue Length网络设备监控数据吞吐设备缓存等场景设计模版（一）注：监控配置是性能测试中非常重要的一部分工作，使否检测到关键的、有效的数据，决定了能够根据测试结果分析并定位系统的瓶颈在那里。第7章、 测试场景-设计业务用例准备业务用例准备业务用例是根据场景中的业务要求来准备的，这里所要完成的主要是对业务操作的分解细化业务在系统中实现中的每一步。确定事务在业务操作中可能有很多我们不关系的动作，比如一些进入事务操作界面的动作都是我们不关心的，我们把业务提交的动作作为一个事务，我们需要监控的正是这些事务的性能和对系统的压力确定事务中需参数的数据在确定事务后，对事物中的数据确定是否要进行参数化（例如读帖操作，需要初始化帖子id）确定用例id和事务id的规则用例id ： uc_XXX_id事务id ： trans_XXX_id业务用例和场景review参加人：测试经理，测试设计人员，项目经理，业务人员输入：测试用例设计文档活动：场景设计人员讲解业务用例 业务人员对场景中业务操作评审 输出：评审结果表Devliverables：在TD的Requirements中体现性能测试用例模板用例idtester设计人用例描述用户登录后查询国际机票信息步骤id操作是否为事务（事务id）是否有参数化Step1点登陆按钮Tran_login_001用户名/密码Step2录入关键字NNStep3提交查询按钮Trans_search_002查询关键字第8章、 测试场景-环境准备测试环境准备包括硬件准备，软件准备，以及根据用例分析所要做的数据准备工作，测试准备工作主要依赖场景设计，来具体实施硬件准备l 被测试系统需要部署的服务器（WebServer ，DbServer ，ApplicationServer）l 负载生成器的设备（每台机器最多跑80个vu，具体根据vu的业务操作情况）l 负载控制器的设备l 网络环境模拟（根据测试需求采用模拟方式部署设备）软件准备l 测试工具的安装l WebServer 的配置安装l DbServer 的配置安装l ApplicationServer 的配置安装l 监控的配置 详细内容见Loadrunner 监控的配置加在附件之中，进行整理数据准备l 分析业务要求准备需要参数化的数据l 根据测试范围的需要在数据库中准备响应数量的数据l 根据测试范围的需要准备响应的vu登录帐户数据监控配置根据场景中设计要监控的点进行采集配置，每种监控类型都有不同的配置方式，有些需要在监控点起来一些守候进程，有些要在监控点起来写监控端口，有些需要安装loadrunner 插件， 在实际应用中需要考虑具体情况具体实施第9章、 测试场景-测试脚本开发（业务用例脚本化）录制脚本脚本录制需要注意录制前的配置，在这里我们主要针对Http协议，因为这是我们项目最常用到的一种协议。完善脚本l 插入事务l 插入集合点l 模拟用户思考时间l 参数化输入l 插入text/image 检查点l 关联语句l Run-time setting 选项l 注释详细见The VuGen Script File Development Process 这篇文档附件第10章、 测试场景-场景配置场景是业务用例的组合模拟一定真实会出现的情况，场景出了选择合适的业务用例（也就是对应的脚本）已经运行模拟用户的数量外，还要考虑压力的方式，如场景运行时间，场景持续加压模式。确定压力点（确定vu数量）场景中每种业务的vu数量应该是按比例存在的，根据业务需求计算出总vu数量的理论值,在这个值的配置下运行场景，监控被加压的web服务的响应时间，以及web服务所在服务器的资源情况，l 如果web服务所在服务器资源还没有被完全占用的情况下，web服务已经开始出现错误相应，需要检查web服务的配置 例如web服务限制的进程数量等。l 如果web服务所在服务器资源还被完全占用的情况下，说明服务器的配置，所能支撑的我们业务数量大不到理论值l 如果事务响应时间没有达到要求，首先确认服务器的资源，确认资源并没有占用的情况下，考虑事务的执行过程（是否有数据库的调用），确认数据库的性能，如果数据库性能正常，检查程序。确定负载模式在施加压力时候可以持续加压也可以一次加压到位。一般我们采取持续加压的方式，这样比较能够情况的看到系统资源在前期加压时随着加压资源波动情况。对我们不关心的操作基本都在脚本的vu_init 中，所以，建议在设置场景时候选择全部初始化，以免对资源监控时候产生误差。确定监控点这个非常重要，在场景运行前要确认监控那些内容，如何确定是根据系统架构和部署来确定的在web应用中我们需要监控的如下：l Web服务l Web服务所在的服务器l 数据库服务l 数据库所在服务器具体监控的配置方法可以参见Computer Performance Monitoring 附件第11章、 执行测试执行测试需要注意几个地方监控错误运行过程中对错误监控，如果出现脚本错误退出的错误是最严重的需要重新调适脚本或运行设置如果初选http类型的错误需要能够根据错误编号确定问题，下面列出了所有http的响应编号及其含义HTTP错误代码详细介绍 HTTP 400 - 请求无效 HTTP 401.1 - 未授权：登录失败 HTTP 401.2 - 未授权：服务器配置问题导致登录失败 HTTP 401.3 - ACL 禁止访问资源 HTTP 401.4 - 未授权：授权被筛选器拒绝 HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败 HTTP 403 - 禁止访问 HTTP 403 - 对 Internet 服务管理器 (HTML) 的访问仅限于 Localhost HTTP 403.1 禁止访问：禁止可执行访问 HTTP 403.2 - 禁止访问：禁止读访问 HTTP 403.3 - 禁止访问：禁止写访问 HTTP 403.4 - 禁止访问：要求 SSL HTTP 403.5 - 禁止访问：要求 SSL 128 HTTP 403.6 - 禁止访问：IP 地址被拒绝 HTTP 403.7 - 禁止访问：要求客户证书 HTTP 403.8 - 禁止访问：禁止站点访问 HTTP 403.9 - 禁止访问：连接的用户过多 HTTP 403.10 - 禁止访问：配置无效 HTTP 403.11 - 禁止访问：密码更改 HTTP 403.12 - 禁止访问：映射器拒绝访问 HTTP 403.13 - 禁止访问：客户证书已被吊销 HTTP 403.15 - 禁止访问：客户访问许可过多 HTTP 403.16 - 禁止访问：客户证书不可信或者无效 HTTP 403.17 -