模版性能测试计划.doc

模版性能测试计划 网通系统压力测试方案微软（中国）有限公司编建日期xx年4月9日编制人冯江、谢华芳网通压力测试方案版本控制版本日期作者备注v1.0xx-4-9冯江、谢华芳第2页网通压力测试方案第3页目录 一、概述1.1项目背景和测试目的为了保障网通即将建设的综合营帐系统能够顺利实施，网通希望在项目正式实施前了解未来系统是否可以使用目前已经选用的技术进行搭建，即了解项目技术的可行性。 另外，网通还希望了解使用不同技术实现的差异。 1.2被测系统介绍本次被测系统是针对网通项目的一个前期实验系统。 系统逻辑结构图如下Tuxedo(B)ServiceWebLogic(B)EJBJsp/servletWTC Http/XMLBiztalkHttpportTuxedo(A)ServiceWebLogic(A)Jsp/servletEJBWTCchannelLaptopLaptop AICAB图 1、系统逻辑结构图整个系统分为三个主要部分，主要功能包括1.系统A系统A是整个系统的数据入口，可以将客户请求传给Biztalk或者直接传给系统B。 系统A可以通过两种方法接收客户请求传给系统。 一种通过Tuexdo(A)接收用户请求，另一种可以直接通过WebLogic(A)接收用户请求。 2.Biztalk第4页网通压力测试方案Biztalk是整个系统的中心，负责连接系统A和B，主要目的是同步处理系统消息。 另外，由于测试需要，Biztalk本身可以接收用户请求（Http）。 3.系统B可以看作系统的服务端。 接收Biztalk的请求，并返回结果。 1.3测试可接收条件 1、每次测试交易成功率在90%以上 2、用户每个请求的响应时间低于2秒每次测试，以上条件必须同时满足，方视为本次测试通过。 二、测试需求本次测试的需求包括 1、Biztalk系统的处理能力 2、整个系统能够支持多少用户同时访问 3、不同技术间实现的差异 三、测试方法3.1测试方法测试过程采用自动测试工具进行。 目前暂时决定使用Mercury Interactive公司的测试产品LoadRunner。 1、测试Biztalk系统的处理能力第5页网通压力测试方案Http/XMLBiztalkHttpportchannel AIC图 2、测试Biztalk系统的处理能力模拟多个Web类型的虚拟用户，同时向Biztalk系统发送请求，之后记录每个虚拟用户的响应时间。 2、整个系统能够支持多少用户同时访问方法一模拟多个Web类型的虚拟用户，同时向WebLogic(A)发送请求，之后记录每个虚拟用户的响应时间。 Tuxedo(B)ServiceWebLogic(B)EJBJsp/servletWTC Http/XMLBiztalkHttpportTuxedo(A)ServiceWebLogic(A)Jsp/servletEJBWTCchannel AICAB图 3、测试整个系统能够支持多少用户同时访问（方法一）第6页网通压力测试方案方法二模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，之后记录每个虚拟用户的响应时间。 Tuxedo(B)ServiceWebLogic(B)EJBJsp/servletWTC Http/XMLBiztalkHttpportTuxedo(A)ServiceWebLogic(A)Jsp/servletEJBWTCchannelTuxedo AICAB图 4、测试整个系统能够支持多少用户同时访问（方法二） 3、不同技术间实现的差异方法一模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，并且Tuxedo（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。 第7页网通压力测试方案Tuxedo(B)ServiceWebLogic(B)EJBJsp/servletWTC Http/XMLTuxedo(A)ServiceWebLogic(A)Jsp/servletEJBWTCTuxedoAB图 5、测试不同技术间实现的差异（方法一）方法二模拟多个Web类型的虚拟用户，同时向WebLogic(A)的发送请求，并且WebLogic（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。 Tuxedo(B)ServiceWebLogic(B)EJBJsp/servletWTC Http/XMLTuxedo(A)ServiceWebLogic(A)Jsp/servletEJBWTCAB图 6、测试不同技术间实现的差异（方法二）第8页网通压力测试方案3.2测试案例测试目的虚拟用户类型WEB CaseNo.并发用户数交易循环次数00100xx00400500600700800901001101xx014015016017018019020测试Biztalk系统的处理能力WEB整个系统能够支持多少用户同时访问TUXEDO WEB不同技术间实现的差异TUXEDO3.3测试流程正式测试过程如下 1、确认被测环境正常（Env_Check_list） 2、确认测试环境设置（Env_Check_list） 3、开始测试 4、存储测试结果 5、系统调试 6、应用调试 7、环境维护3.4数据文件准备数据文件名称包含内容说明数据量第9页网通压力测试方案3.5测试脚本说明脚本名称描述（TranNo.:Tran名称:解释）参数说明（参数:说明）数据（参数:文件:方法） 四、测试环境4.1网络拓扑图被测系统测试系统网络测试机测试机控制台服务器1服务器2服务器3图 7、测试网络拓扑图4.2环境配置第10页网通压力测试方案类型配置软件服务器1服务器2服务器3测试机控制台被测系统测试系统网络 五、测试实施5.1试资源与进度项目阶段任务分解任务内容完成标准责任人资源与时间0.5人天项目启动设立项目项目定义，规划项目运作模式，编制项目计划，组建项目班子与实施队伍输出项目计划测试经理测试需求调研明确测试需求、测试目标、界定测试范围、任务和具体内容双方就测试需求达成共识测试人员微软负责人0.5人天制定测试方案细化测试方案，定义测试范围，并定义各项测试活动和步骤，具体安排测试实施过程及测试进度输出测试方案（初稿）测试经理2人天测试计划和测试设计测试方案评审对测试方案定义的功能、性能测试范围、测试策略、测试组织实施过程、测试进度等进行评审输出测试方案（讨论稿），对测试方案中涉及的各项内容达成共识微软负责人测试经理1人天搭建应用运行环境搭建应用所需的环境，并建立测试数据库应用正常运行微软负责人搭建测试运行环境搭建测试所需的环境，包括测试工具软件、性能监控软件等各测试软件正常运行测试人员1人天测试准备工作准备测试数据准备必要的功能及压力测试所需的测试数据输出测试数据准备清单，并准备好测试数据测试人员微软开发人员1人天测试开发开发压力测试脚本按照压力测试案例设计，开发测试脚本输出可执行的测试脚本测试人员1人天第11页网通压力测试方案预测试证明测试脚本可用，证明测试流程可用证明测试环境配置合理证明测试数据准备充分按照预期可接收条件运行2x2场景成功运行25x25场景成功运行500或1000并微软负责人微软开发人员测试经理1天系统调优使系统运行在最佳状态发用户场景，测试经理和项目经理直到认为测试停止微软负责人微软开发人员测试经理2天极限测试测试系统究竟能够承受的业务量按照预期可接收条件，系统已经不能承受测试人员1天测试执行压力测试评估按照测试评估策略对性能进行评估，并对系统性能进行分析输出性能测试评估报告测试评估总结总结输出项目报告、相关文档归档，安排后续工作输出项目报告测试人员5.2测试机构和人员职责角色任务网通项目经理测试项目经理测试组织、管理协调测试组测试执行并协助进行结果分析开发专家业务指导，调优指导测试专家测试工具支持，测试方案审核系统专家系统恢复、系统问题顾问测试策略制定，管理协调网通项目经理测试项目经理专家组测试组图 8、测试组织结构图开发专家测试专家系统专家第12页网通压力测试方案 六、试存储管理规范6.1存储内容、地点、命名规则?存储内容a)测试脚本b)测试场景c)测试结果d)相关文档e)数据文件?存储地点运行控制台的主机硬盘上，存储结构见下面图9。 ?命名规则a)测试脚本LTscr_App_SubApp_version说明LTscr LoadTest ScriptApp业务名称SubApp子业务名称（可选）Version脚本的版本号b)测试场景LTsce_App_SubApp_ConCurrUser_Iteration说明LTsce LoadTest ScenarioApp业务名称SubApp子业务名称（可选）ConCurrUser并发用户数Iteration每个用户循环次数c)测试结果LTres_App_SubApp_ConCurrUser_Iteration_time说明LTres LoadTest Result第13页网通压力测试方案App业务名称SubApp子业务名称（可选）ConCurrUser并发用户数Iteration每个用户循环次数Time第几次测试6.2存储目录结构Pre_Test TestResult DocumentDataFileDF_LoadTest ScriptScenario Date(MM_DD_YYYY)图 9、测试存储结构图说明Script存储测试脚本Scenario存储测试场景Result存储测试结果Document存储相关文档DataFile存储数据文件6.3备份测试结果每天在测试结束后备份一次，将“D:LoadTest”目录，全部备份到磁带机或“AnyPCC:LoadTest_bak”第14页网通压力测试方案附录1Env_Check_list日期xx年_月_日_时_分测试结果名称_检查内容如下检查项检查人结论备注被测试系统Web Server清除Cache和临时文件Web Server重新启动Application Server清除Cache和临时文件Application Server重新启动DB Server清除新生成的记录和临时文件DB Server重新启动确认应用可以正常运行测试系统测试机清除临时文件测试机重新启动控制台机器清除临时文件控制台机器重新启动测试机LoadRunner RCL已经启动确认测试机临时空间大于1G Iteration次数设置正确不写log确认Proxy设置Simulate browserCache enableDownload non-HTML resourcesenable Simulatea newuser eachiteration enable参数方法正确DNS Cacheenable Keep-Alive enableConcurent connections=4测试监督签字_第15页网通压力测试方案附录2测试工具原理Mercury Interactive公司的客户机/服务器系统的压力测试工具LoadRunner，其工作原理为通过一个中心控制点，在一个或几个主机上同时模拟成百上千的实际用户的操作，从而生成一致的、可测量的及可重复的系统负载，并记录特定交易操作的响应时间。 概要地说首先录制应用程序的操作过程，测试工具会自动生成可执行的脚本，该脚本运行起来，从服务器端看，就如同一个实际的用户在进行操作，我们称为虚拟用户。 然后，通过中心控制点（Controller）设置测试场景，控制许多个虚拟用户在多台Agent机器上同时运行，监控运行状态，收集响应时间等性能数据。 ?使用虚拟用户（Vuser）替代实际用户每个模拟的用户即为一个虚拟用户，其实就是一个运行的测试脚本。 LoadRunner在PC上主要有两种Vuser非图形用户界面的虚拟用户（Non-GUI Vuser）和图形用户界面虚拟用户（GUI Vuser）。 Non-GUI Vuser是直接通过API调用和Web/Application/DB服务器进行交互的，它的脚本是直接向服务器提交请求的类C语言程序。 多个Non-GUI Vuser可运行于一台主机上。 Vuser可通过Virtual UserGenerator来录制生成，在录制脚本中可以标明某一活动（transaction）的开始和结束点，用于具体度量这一活动的响应时间及性能，还可以在某一操作之前定义集结点（rendezvous），用于测试这一操作的多用户并发。 GUI Vuser模拟实际用户运行应用程序进行操作的情况，它的脚本记录了客户机上所有的界面操作。 GUI Vuser可通过Mercury Interactive公司的功能测试工具WinRunner来录制生成。 由于本次压力测试的目的是检验服务器对压力的承载能力，因此建议通过在一台主机上运行多个Non-GUI Vuser来模拟多用户的活动进行压力测试。 ?测试脚本的参数化测试脚本反映的是录制时输入的数据的情况。 但由于录制操作可能引起原输入数据状态的变化，因此要修改测试脚本中的输入数据及与其相关的数据；而且为了更准确地模拟真实系统的运作，输入的数据及与其相关的数据就必须参数化，并且为该参数建立一个包含所有数据的参数文件。 这样当模拟多用户进行压力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。 通过中心控制点（Controller）管理虚拟用户在中心控制点，定制测试场景，即将要在测试会话中发生的事件。 定制包括模拟的用户个数、模拟用户所在的主机、模拟用户的动作等。 在中心控制点控制场景的运行，管理所有虚拟用户的活动，监控虚拟用户的第16页网通压力测试方案状态，也可以无人照料地运行。 场景执行完后，可通过Controller的性能分析图形和报表对结果数据进行分析。 代理程序必须安装在参与测试的每一台主机上，当场景开始运行，代理程序负责Controller与主机之间的通讯。 Application/WebServerLoadRunnerControllerLANLoadRunnerVusersDatabaseClient?使用自动生成的图表和报表分析测试结果在每个测试场景运行完后，Controller自动收集服务器、网络及客户端的性能数据，并以图形和报表的形式显示。 其中包括服务器响应Vuser以及transaction提交的请求和任务的时间；在运行期间的基于活动Vuser数目的transaction性能时间；服务器磁盘I/O、CPU使用情况，网络延迟等数据。 测试方法及步骤 1、建立虚拟用户（生成测试脚本）在LoadRunner的Virtual UserGenerator中录制测试脚本，建立虚拟用户，一般一个业务操作录制成一个测试脚本，步骤如下1)根据应用软件的体系结构、中间件、数据库或客户端与服务器之间的协议，选择对应的虚拟用户类型，如WEB、Oracle、Tuxedo、WinSocket等等；2)指定要录制的可执行程序，开始录制；3)在Vuser initsection中记录登录应用系统的过程；4)在Actions section中记录功能操作过程，适当加入事务（transaction）的开始与结束点（事务也可在脚本生成后，直接在脚本中加入）。 当需要记录压力测试过程中某一操作的响应时间时，则在执行这一操作前定义事务的开始点，并给这一事务命名，在操作结束后定义该事务的结束点；5)在Vuser endsection中记录退出系统的过程；6)回放测试脚本，检验测试脚本执行的正确性（有可能要恢复录制以前的数据状态，或进行必要的参数化）。 第17页网通压力测试方案 2、试脚本的参数化测试脚本反映的是录制时输入的数据的情况，但为了更准确地模拟真实系统的运作，如模拟不同用户的登录，不同用户查询股票行情，不同用户在做不同的股票交易等情况，有些输入的数据必须参数化，并且为该参数建立一个包含所有可能的数据的参数文件。 这样当模拟多用户进行压力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。 参数的选择、参数文件的定制具体根据应用软件的实际情况而定，但要保证录制的脚本能够顺利地执行回放，且完成相应的业务功能。 3、定制压力测试场景在LoadRunner的Controller中，定制压力测试场景，也就是模拟一个多用户并发的情况，包括运行虚拟用户的测试主机、在测试机上运行的虚拟用户数、虚拟用户运行的测试脚本、每个虚拟用户的循环次数等等。 1)虚拟用户并发数定义执行某一测试脚本的虚拟用户并发数，则虚拟用户并发总数为各脚本虚拟用户并发数之和；由于在运行测试脚本时，忽略了Think Time，因此一个虚拟用户的操作是非常连贯的，其强度远远大于一个实际用户的操作强度；另外，为了测试引起系统性能急剧下降的拐点和引起系统崩溃的崩溃点，并发的虚拟用户数需逐渐增加，每次增加的数量可视测试的具体情况而定。 2)测试主机选择运行某一测试脚本的测试主机。 3)虚拟用户执行的脚本选择虚拟用户执行的测试脚本，即完成某一业务功能的测试脚本。 4)Iteration Count虚拟用户运行测试脚本Actions section部分的循环次数，增加循环次数是为了保证在某一稍长的时间段内有一个稳定的负载，这样统计的结果才比较准确。 需要注意的是，每台测试机上所支持的虚拟用户数，与测试机的配置和录制的应用程序的大小有关。 每台测试机上运行的虚拟用户数不能太多，因为如果太多的话，性能瓶颈将会出现在客户端，那么测出的结果将毫无意义。 4、运行压力测试场景在LoadRunner的Controller中，运行压力测试场景，就可以控制测试机上的所有虚拟用户并发进行相应的操作。 步骤为1)启动测试机的Remote CommandLauncher；2)在Controller中使测试机处于“连接”状态；3)在Controller中，对所有虚拟用户发出初始化（initialize）命令，测试主机的RCL启动Agent，并将虚拟用户初始化，执行测试脚本中Vuser initsection部分，使之登录系统；第18页网通压力测试方案4)在Controller中，对所有虚拟用户发出运行（run）命令，通过测试主机的Agent运行各虚拟用户，执行测试脚本中的Actions section部分，在Controller端监控虚拟用户的状态及执行结果；5)每个虚拟用户按指定的循环次数执行测试脚本中的Actions section部分，然后执行Vuser endsection部分，退出应用系统；6)当每一个虚拟用户运行完成后，整个测试场景运行结束。 在压力测试场景执行过程中，Controller会自动收集服务器、网络及客户端的性能数据，以及各事务的响应时间等。 5、监控系统性能在测试场景运行过程中，我们需要监控1)监控运行虚拟用户的客户端的资源使用情况，使用Windows的性能监视器监控客户端的CPU、Memory等资