性能压力测试方案实例

1、UDMS性能压力测试方案UDMS性能压力测试方案错误！未指定书签。版本控制版本日期作者备注v1.02011-9-9初稿第12页目录一、概述41.1 项目背景和测试目的41.2 被测系统介绍41.3 测试可接收条件4二、测试需求5三、测试方法53.1 测试方法53.2 测试案例63.3 测试流程63.4 数据文彳准备6四、测试环境74.1 网络拓扑图74.2 环境配置7五、测试实施85.1试资源与进度8附录：测试工具原理 91.1 项目背景和测试目的为保障UDMS后续示范应用项目能够顺利实施，UDMS项目组希望在示范 应用项目正式实施前了目前的 UDMS性能是否可行，即了解示范应用项目技术 的可

2、行性。另外，通过测试，还希望了解使用不同技术之间实现的差异。1.2 被测系统介绍本次被测系统是目前已完成的 UDMS1.1系统，系统逻辑结构如下图：示范应用UDMS系统统一存储统一分析u统一索引j统一查询接匚 接口 U 接口 U 接口工具数据建模数据导入交互抽取分析插件索引插件基础设施（存储+计算）系统逻辑结构图本次测试主要测试数据的索引性能及并发数据搜索性能。1.3 测试可接收条件1、数据索引性能每次测试均需成功;2、数据并发搜索性能根据并发用户量决定，见后续描述；每次测试，以上条件必须同时满足，方视为本次测试通过。二、测试需求本次测试的需求包括：项目计划文档性能需求规格说明书系统架构设计文

3、档:、测试方法3.1 测试方法测试过程采用自动测试工具进行。使用 HP公司的测试产品：LoadRunnen 对数据索引性能测试不使用上述工具。1 .测试UDMS系统数据索引性能：对UDMS系统进行数据导入测试，分别导入 1万、10万，100万，1000万 条文本及多媒体数据，之后记录每次导入的时间。2 .整个系统能够支持多少用户同时访问模拟多个虚拟用户，同时向 UDMS发送搜索请求，之后记录每个虚拟用户 的响应时间。3、不同技术间实现的差异如有条件，可测试示范应用系统使用不同数据库平台之间的性能差异。该部分测试视实际情况决定是否需要测试。3.2 测试案例测试目的虚拟用户Case No.并发用户

4、数数据量测试数据索引Non-GUIVuser00111万002110万0031100万00411000 万整个系统能够支 持多少用户同时 访问Non-GUIVuser0051100万00610100万007100100万0081000100万Non-GUIVuser00811000 万010101000 万0111001000 万01210001000 万3.3 测试流程正式测试过程如下：确认被测环境正常; 确认测试环境设置; 开始测试；存储测试结果；系统调试；应用调试； 环境维护；3.4 数据文件准备数据文件名称包含内容说明数据量文本数据标注完后的文本GBK格式纯文本1000 万多媒体数据带

5、标注文本及媒体文 件包括声音、图像及视 频1000 万四、测试环境4.1 网络拓扑图Load Generator测试网络拓扑图4.2 环境配置配置软件被测系统服务器DELL POWEREDGE210CPU:INTEL XEON E31220 3.1GHZDISK:2TMEMORY:8G测试系统测试机器 及控制台CPU:INTEL CORE I5-2410M 2.30HZMEMORY:2G网络交换机千兆网络五、测试实施5.1 试资源与进度项目 阶段任务分解任务内容完成标准责任人资源与 时间项目 启动设立项目项目定义，规划项目运作模式， 编制项目计划，组建项目班子与 实施队伍输出项目计划测试经理0

6、.5人天测试 计划 和测 试设 计测试需求 调研明确测试需求、测试目标、界定 测试范围、任务和具体内容双方就测试需求达 成共识测试人员0.5人天制定测试力杀细化测试方案，定义测试范 围，并定义各项测试活动和步 骤，具体安排测试实施过程及测 试进度输出测试力不» （初稿）测试经理2人天测试执行预测试证明测试脚本可用，证明测试流程可用证明测试环境配置合理证明测试数据准备充分按照预期可接收条 件开发及测试人 员1天系统调优使系统运行在最佳状态运行500或1000并发用户场景，测试 经理和项目经理直 到认为测试停止项目负责人/开 发人员/测试人 员/测试经理2天性能测试根据测试案例测试按照预

7、期可接收条 件测试人员1天压力测试测试系统究竟能够承受的业务 量按照预期可接收条 件，系统已经不能 承受测试人员1天测试 评估 总结总结输出项目报告、相关文档归档， 安排后续工作输出项目报告测试人员2天测试组织结构图附录：测试工具原理Mercury Interactive公司的客户机/服务器系统的压力测试工具 LoadRunner,其工作原理为：通过一个中心控制点，在一个或几个主机上同时 模拟成百上千的实际用户的操作， 从而生成一致的、可测量的及可重复的系统负 载，并记录特定交易操作的响应时间。概要地说：首先录制应用程序的操作过程， 测试工具会自动生成可执行的脚本，该脚本运行起来，从服务器端看

8、，就如同一个实际的用户在进行操作，我们称为虚拟用户。然后，通过中心控制点(Controller)设置测试场景，控制许多个虚拟用户在多台 Agent机器上同时运行， 监控运行状态，收集响应时间等性能数据。使用虚拟用户(Vuser)替代实际用户每个模拟的用户即为一个虚拟用户，其实就是一个运行的测试脚本。LoadRunner在PC上主要有两种Vuser：非图形用户界面的虚拟用户(Non-GUI Vuser)和图形用户界面虚拟用户(GUI Vuser)。Non-GUI Vuser是直接通过API调用和 Web/Application/DB服务器进行交互 的,一它的脚本是直接向服务器提交请求的类C语言程

9、序。多个Non-GUI Vuser可运行于一台主机上。 Vuser可通过Virtual User Generator来录制生成，在录制 脚本中可以标明某一活动(transaction)的开始和结束点，用于具体度量这一活 动的响应时间及性能，还可以在某一操作之前定义集结点(rendezvous,用于测试这一操作的多用户并发。GUI Vuser模拟实际用户运行应用程序进行操作的情况，它的脚本记录了客 户机上所有的界面操作。GUI Vuser可通过Mercury Interactive公司的功能测试 工具WinRunner来录制生成。由于本次压力测试的目的是检验服务器对压力的承载能力，因此建议通过在

10、一台主机上运行多个Non-GUI Vuser来模拟多用户的活动进行压力测试。测试脚本的参数化测试脚本反映的是录制时输入的数据的情况。 但由于录制操作可能引起原输 入数据状态的变化，因此要修改测试脚本中的输入数据及与其相关的数据；而且为了更准确地模拟真实系统的运作，输入的数据及与其相关的数据就必须参数 化，并且为该参数建立一个包含所有数据的参数文件。这样当模拟多用户进行压 力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。通过中心控制点(Controller)管理虚拟用户在中心控制点，定制测试场景，即将要在测试会话中发生的事件。定制包括 模拟的用户个数、模拟用户所在的主机、模拟用户的动作等

11、。在中心控制点控制场景的运行，管理所有虚拟用户的活动，监控虚拟用户的 状态，也可以无人照料地运行。场景执行完后，可通过Controller的性能分析图形和报表对结果数据进行分析代理程序必须安装在参与测试的每一台主机上，当场景开始运行，代理程序 负责Controller与主机之间的通讯。Client使用自动生成的图表和报表分析测试结果在每个测试场景运行完后，Controller自动收集服务器、网络及客户端的性 能数据，并以图形和报表的形式显示。其中包括服务器响应Vuser以及transaction 提交的请求和任务的时间；在运行期间的基于活动Vuser数目的transaction性能时间；服务器

12、磁盘I/O、CPU使用情况，网络延迟等数据。测试方法及步骤1、建立虚拟用户（生成测试脚本）在LoadRunner的Virtual User Generator中录制测试脚本，建立虚拟用户, 般一个业务操作录制成一个测试脚本，步骤如下：1）根据应用软件的体系结构、中间件、数据库或客户端与服务器之间的协 议，选择对应的虚拟用户类型，如： WEB、Oracle、Tuxedo、WinSocket 等等；2）指定要录制的可执行程序，开始录制；3）在Vuser init section中记录登录应用系统的过程；4） 在 Actions sections己录功能操作过程，适当加入事务（transaction

13、）的开始与结束点（事务也可在脚本生成后，直接在脚本中加入）。当需要 记录压力测试过程中某一操作的响应时间时，则在执行这一操作前定义 事务的开始点，并给这一事务命名，在操作结束后定义该事务的结束点；5） 在Vuser end sections己录退出系统的过程；6）回放测试脚本，检验测试脚本执行的正确性（有可能要恢复录制以前的 数据状态，或进行必要的参数化）。1、试脚本的参数化测试脚本反映的是录制时输入的数据的情况，但为了更准确地模拟真实系统 的运作，如模拟不同用户的登录，不同用户查询，有些输入的数据必须参数化， 并且为该参数建立一个包含所有可能的数据的参数文件。这样当模拟多用户进行 压力测试时

14、，就可控制每个虚拟用户使用参数文件中的不同数据。参数的选择、参数文件的定制具体根据应用软件的实际情况而定，但要保证 录制的脚本能够顺利地执行回放，且完成相应的业务功能。2、定制压力测试场景在LoadRunner的Controller中，定制压力测试场景，也就是模拟一个多用户 并发的情况，包括：运行虚拟用户的测试主机、在测试机上运行的虚拟用户数、 虚拟用户运行的测试脚本、每个虚拟用户的循环次数等等。1）虚拟用户并发数：定义执行某一测试脚本的虚拟用户并发数，则虚拟用 户并发总数为各脚本虚拟用户并发数之和；由于在运行测试脚本时，忽 略了 Think Time,因此一个虚拟用户的操作是非常连贯的，具强

15、度远远 大于一个实际用户的操作强度；另外，为了测试引起系统性能急剧下降 的拐点和引起系统崩溃的崩溃点，并发的虚拟用户数需逐渐增加，每次 增加的数量可视测试的具体情况而定。2）测试主机：选择运行某一测试脚本的测试主机。3）虚拟用户执行的脚本：选择虚拟用户执行的测试脚本，即完成某一业务 功能的测试脚本。4） Iteration Count:虚拟用户运行测试脚本 Actions section分的循环次 数，增加循环次数是为了保证在某一稍长的时间段内有一个稳定的负载， 这样统计的结果才比较准确。需要注意的是，每台测试机上所支持的虚拟用户数，与测试机的配置和录制 的应用程序的大小有关。每台测试机上运行

16、的虚拟用户数不能太多，因为如果太 多的话，性能瓶颈将会出现在客户端，那么测出的结果将毫无意义。3、运行压力测试场景在LoadRunner的Controller中，运行压力测试场景，就可以控制测试机上的 所有虚拟用户并发进行相应的操作。步骤为：1）启动测试机的 Remote Command Launcher;2）在Controller中使测试机处于“连接”状态；3）在Controller中，对所有虚拟用户发出初始化（initialize ）命令，测试主 机的RCL启动Agent,并将虚拟用户初始化，执行测试脚本中Vuser init section分，使之登录系统；4）在Controller中，

17、对所有虚拟用户发出运行（run）命令，通过测试主机的Agent运行各虚拟用户，执行测试脚本中的 Actions section分，在 Controller端监控虚拟用户的状态及执行结果；5）每个虚拟用户按指定的循环次数执行测试脚本中的Actions section部分，然后执行Vuser end section?分，退出应用系统；6）当每一个虚拟用户运行完成后，整个测试场景运行结束。在压力测试场 景执行过程中，Controller会自动收集服务器、网络及客户端的性能数据， 以及各事务的响应时间等。4、监控系统性能在测试场景运行过程中，我们需要监控：1）监控运行虚拟用户的客户端的资源使用情况，使

18、用Windows的性能监视 器监控客户端的CPU、Memory等资源使用情况，以防止性能瓶颈出现 在客户端；另外，可以在进行压力测试的同时，在另外的客户端上运行 应用程序，也就是在系统负载较大时从最终客户的角度再进行相应功能 的确认，并测试端到端的响应时间，也可将该响应时间与压力测试的响 应时间进行比较，若结果差别不大，也可验证压力测试结果的可信性。2）监控数据库服务器、WEB服务器资源的使用情况，可以使用QuestSoftware 的 I/Watch,或 CA UniCenter 和 IBM Tivoli 等专门的系统监控 工具，来监控服务器端的 CPU、Memory、Disk、Process Network