用心纪录,用心发现。

发布新日志

  • LoadRunner 概念和参数(转)

    2009-05-21 17:24:33

    事务TRANSACTION

    所谓事务(TRANSACTION),就是在脚本定义中定义的某段操作(ACTION),更确切的说,就是一段脚本语句.定义事务时,首先在脚本中找到事务的开始和结束位置,然后分别插入一个事务起始标记,这样,当脚本运行的时候,LOADRUNER会自动在事务的起始点计时,脚本在运行到事务结束点时计时结束,系统会自动记录这段操作的运行时间等性能数据;在脚本运行完毕后,系统会在结果信息中单独反映每个事务运行结果.

    LR_START_TRANSACTION(“事务名称”)

    LR_END_TRANSACTION(“事务名称“)

    集合点RENDEZVOUS

    多用户同时加载并发,并发过程仅仅体现在开始执行的那一刹那,随着服务器对请求的响应时间的不一致或系统环境条件的限制,在运行过程中能集合到一点的可能性微乎其微,所以将一定数量的用户同时加载并不是真正意义上的并发.

    系统压力最大的情况是:所有用户都集中到系统瓶颈的某个点上进行操作,从脚本的角度来讲,这个点就是执行脚本的某一条或一段语句,为了真实模拟这个最坏的情况,查看系统在最坏情况下的反映,LOADRUNNER提供了集合点的功能,帮助测试人员实现真正意义上的并发.

    LR_RENDEZVOUS(“集合点名称”)

    参数化PARAMETERS

    让所有用户都使用相同的数据来运行,对系统造成的压力与实际情况会有所不同.而对于那些禁止一个用户多次登陆的系统,也就严重到无法测试的地步了.为了解决这个问题,让系统更加真实的模拟多用户使用的实际环境,LOADRUNNER提供了对脚本进行参数化输入的功能.

    所谓的脚本参数化,就是针对脚本中的某些常量,定义一个或多个包含数据源的参数来取代,让场景中不同的虚拟用户在执行相同的脚本时,分别使用参数数据源中的不同数据代替这些常量,从而达到模拟多用户真实使用系统的目的.

    注:参数化输入只能用于函数中的参数,不能用参数代替非函数中的常量参数.

    检查点CHECKPOINT

    LOADRUNNER检查点的功能主要用来验证某个界面上是否存在指定的TEXT或IMAGE等对象,在使用LOADRUNNER测试WEB应用时,可以检查压力较大时WEB服务器能否返回正常的页面。

    系统在执行时是否起用检查点,是由一个系统参数控制的,该参数的设定方法为:VUSER|RUN-TIME SETTINGS|PREFERENCES,如果想让检查点起作用,需要选中ENABLE IMAGE AND TEXT CHECK 复选框。

    Ø RUN-TIME SETTINGS

    ITERATION COUNT(重复次数)

    入口:GENERAL|RUN LOGIC;

    参数说明:设定每个ACTION的重复执行次数;

    注意:DURATION参数是优先于ITERATION的,举例说明,假定将DURATION设为5分钟,即使在RUN-TIME中将INRATIONS参数设为1,虚拟用户也会在5分钟之内进行尽可能多的反复执行脚本,在限定了DURATION的场景中,DURATION时间是从所有用户状态变为INIT开始计算的,这样就存在一个问题,有些初始化过程很长的用户,可能还没有到达RUN状态就因DURATION时间限制而中止了,要解决这个问题,测试人员可选择INITIALIZE ALL VUSERS BEFORE RUN选项,这样DURATION时间会在所有用户都到达RUN状态后开始计时.

    THINK TIME

    参数设定入口:GENERAL|THINK TIME

    参数说明:设定脚本回放时对思考时间的处理方式.

    IGNORE THINK TIME:

    选择该选项,脚本回放时将不在执行LR_THINK_TIME()函数,这样会给服务器造成更大的压力.

    REPLAY THINK TIME:

    选择该选项,脚本回放时执行LR_THINK_TIME()函数,

    ERROR HANDLING

    入口:GENERAL|MISCELLANEOUS

    参数说明:设定遇到错误时的处理方式

    1,CONTINUE ON ERROR,遇到错误继续运行;

    2,FAIL OPEN TRANSACTIONS ON LR_ERROR_MESSAGE,

    执行到事务中调用的LR_ERROR_MESSAGE()函数时将事务的结果置为FAILED

    3,GENERATE SNAJPSHOT ON ERROR对错误进行快照.

    MULTITHREADING

    设定脚本运行方式;

    入口:GENERATOR|MISCELLANEOUS

    1,RUN VUSER AS A PROCESS,以多进程方式运行;

    2,RUN VUSER AS A THREAD,以多线程方式运行;

    关联Correlation

    Ø 自动关联---- Rules Correlation

    1. 启用auto-correlation

    点选VuGen的【Tools】>【Recording Options】,开启【Recording Options】对话窗口,选取【Internet Protocol】>【Correlation】,勾选【Enable correlation during recording】,以启用自动关联。

    设定当VuGen侦测到符合关联规则的数据时,要如何处理:

    【Issue a pop-up message and let me decide online】:跳出一个讯息对话窗口,询问您是否要建立关联。

    【Perform. correlation in sceipt】:直接自动建立关联

    Ø 自动关联----Correlation Studio

    使用Correlation Studio的步骤如下:

    1. 录制脚本并执行;

    2. 执行完毕后,VuGen会跳出下面的【Scan Action for Correlation】窗口,询问您是否要扫描脚本并建立关联,按下【Yes】按钮。

    3. 扫描完后,可以在脚本下方的【Correlation Results】中看到扫描的结果。

    4. 检查一下扫瞄的结果后,选择要做关联的数据,然后按下【Correlate】按钮,一笔一笔做,或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
    注意:由于Correlation Studio会找出所有有变动的数据,但是并不是所有的数据都需要做关联,所以不建议您直接用【Correlate All】。

    Ø 手动关联

    有可能有些需要做关联的动态数据,连Correlation Studio都无法侦测出来,这时您就需要自行做手动关联了。

    CONTROLLER场景

    Ø MANUAL SCENARIO这种方式是完全手动设置,测试人员需要手工设定虚拟用户数,SCHEDULE和LOADGENERATOR等

    Ø MANUAL SCENARI WITH PERCENTAGE MODE 这种方式与MAMUAL SCENARIO方式比较相似,只是在分配用户数的方式有所不同

    1,后者需要设定TOTAL NUMBER OF VUSERS,即所有虚拟用户数;

    2,后者需要为每个脚本分配用户数比例,由系统按照比例自动分配用户数;

    3,后者脚本选择LOADGENERATOR时,除了可以选择单个的LOAD GENERATOR外,还可以设置为ALL LOAD GENERATOR,即使用所有的LOADGENERATOR。

    由于这种方式没有用户组的概念,因此在设置SCHEDULE时,不能按组设置,只能按整个场景设置

    Ø GOAL-ORIENTED SCENARIO

    这种方式是基于目标自动创建场景的方式,测试人员只要输入性能测试所要达到的目标,LOADRUNNER就会自动根据目标安排场景的运行;

    采用GOAL-ORIENTED SCENARIO方式创建场景时,需要单击EDIT SCENARIO GOAL按钮定义场景目标,CONTROLLER在执行的时候会根据场景目标的要求,自动加载用户,控制场景的运行;

    VIRTUAL USERS

    以虚拟用户数作为目标,当一个应用对用户数要求比较高时,可以使用这种方式来测试一个应用程序能够允许多少个用户同时运行。基于用户数目标的原理和设定方法比较简单,他和MANUAL SCENARIO WITH PERCENTAGE MODE 方式基本相似,只需要定义要求达到的用户数就可以了。从某种意义上讲,它还不能体现面向目标类型的优势。

    HITS PER SECOND,以每秒点击数作为目标

    TRANSACTIONS PER SECOND,以每秒事务数作为目标

    PAGES PER MINUTE,以每分钟页数作为目标

    以上三种类型都需要用户指定虚拟用户数的范围,CONTROLLER在运行场景的时候,首先加载最小的用户数,如果使用最小的用户数不能达到目标,系统会自动逐渐增加用户直到能够达到设定的目标为止。当加载的用户数达到最大值仍然不能满足要求时,就需要重新设置场景,增加最大用户数。可以通过LOAD BEHAVIOR选项设定三种不同的用户加载策略,如果没有达到目标,LOADRUNNER会重新运行场景,一次加载最大的用户数,尝试是否能够达到目标,如果出现如下情况之一,场景的运行结果都会置于FAILED状态,

    CONTROLLER两次加载了最大的用户数都没有达到目标;

    在运行过程中所有的用户都失败了;

    LOAD GENERATOR数目不能满足要求;

    CONTROLLER在增加用户的过程中,性能指标没有增加;

    CONTROLLER在加载第一批用户后,没有捕获到指标的值;

    TRANSATIONS RESPONSE TIME,以事务响应作为目标,

    主要用于衡量要达到预期的事务响应时间,系统所容纳的最多用户数,如果系统已经加载了最大的用户数,响应时间仍然低于设定的值,说明系统还有能力容纳更多的用户,如果使用一部分用户就达到了设定的响应时间,说明系统是无法容纳设定的最大数量的用户的,必须通过完善应用程序来达到目的;

    多机联合产生负载

    LOADRUNNER对应用程序施压时,采用的方法就是让一台机器模拟很多用户,同时向被测用户发送请求或进行操作。这样,如果一台测试机器模拟的虚拟用户数过多,他本身性能的下降会直接影响测试效果。为了避免这种情况,LOADRUNNER允许使用多台机器运行场景来均衡测试机器的负荷。只要一台机器安装了LOAD GENERATOR并启动了LOADRUNNER AGENT PROCESS进程,就可以被CONTROLLER统一调度来运行场景,CONTROLLER负载收集统一的测试信息和执行结果。

    Ø安装LOAD GENERATOR,如果一台测试机仅用来被CONTROLLER调用执行场景,只需安装LOAD GENERATOR就可以了。

    Ø 在CONTROLLER中创建LOAD GENERATOR

    Ø 在场景中用不同的LOAD GENERATOR联合产生负载

    设定集合点策略

    LOADRUNNER在运行场景的时候,允许测试人员根据项目需要自己设定集合点的并发策略,要设定一个集合点以何种方法运行,在创建或打开脚本中包含集合点的场景时,选择SCENARIOI|RENDEZVOUS命令,可以查看场景中所有脚本中的集合点名称,所属脚本,当前状态和相关的虚拟用户列表信息等,根据系统需求,还可以针对集合点的执行进行设定。

    Ø 单击DISABLE/ENABLE RENDEZVOUS按钮可以选定集合点是否启用;

    Ø 单击DISABLE/ENABLE VUSERS按钮可以设定一个用户是否参与到集合点中;

    Ø 单击POLICY按钮可以设定集合点执行策略。

    n 在POLICY对话框中的TIMEOUT BETWEEN VUSERS文本框中设定了一个超时时间,当第一个用户到达集合点时,系统开始计时。如果在这个设定的时间内没有达到要求的集合点用户数,系统就不在等待,释放用户让场景继续执行;

    启用IP欺骗

    LOADRUNNER进行压力负载测试的时候,是让一台机器模拟成百上千的用户对服务器施压,这样就产生了一个问题,那就是所有用户向服务器发起请求的时候,使用的都是同一个IP地址,即LOAD GENERATOR所在机器的固定IP地址,这是和实际运行环境不符的,而且有些应用系统在设计的时候会根据IP来分配资源,有些还限制同一个IP的多次登陆过程。LOADRUNNER为了解决这个问题,使用了一种称为“IP欺骗(IP SPOOFER)”的技术。也就是让一个LOAD GENERATOR上的虚拟用户模拟从不同的IP来向服务器发起请求,以达到以假乱真的目的。

    配置IP SPOOFER

    LOADRNNER配置动态IP的工具是程序组中的一个小工具-IP WIZARD,它能够指导用户按步骤完成配置过程,这里有三个单选按钮;

    第一个单选按钮CREATE NEW SETTING,用于创建一个新的设置,首次运行时选用;

    第二个单选按钮LOAD PREVIOUS SETTING FROM可以调用以前保存的设置;

    第三个单选按钮RESTORE ORIGINALSET不是用来创建动态IP,而是将设置恢复为原始状态,这个选项主要用于使用后释放IP,如果使用完毕后不释放IP的话,那么这些IP会被一直占用,别人就无法使用了。

    Ø 启用IP欺骗

    在CONTROLLER窗口中,选择SCENARIO|ENABLE IP SPOOFER命令,就可以起用IP欺骗了,在IP欺骗启用后,在CONTROLLER状态栏中会显示相应的状态标识;

    Ø 在OPTIONS中设置IP地址的分配方式;

    创建虚拟IP地址之后,还要选择TOOLS|OPTIONS命令,在弹出的对话框中单击GENERAL标签以设定IP地址的分配方式;

    n IP ADDRESS ALLOCATION PER PROCESS:给每个进程分配不同的IP地址;

    n IP ADDRESS ALLOCATION PER THREAD: 给每个线程分配不同的IP地址;

    一般来说,如果在RUN-TIME SETTING中设置的是以多线程的方式运行,则这里就给每个线程分配不同的IP地址。如果在RUN-TIME SETTING中设置的是以多进程的方式运行,则这里给每个进程分配不同的IP地址;

    注意:只有在CONTROLLER中选择TOOL|EXPERT MODE 命令,才能在OPTIONS对话框中包含设定IP分配的选项;

    控制场景的运行

    按钮开始执行场景以后,LOADRUNNER首先检查场景的配置信息,并激活被测应用,然后将虚拟用户分配到相应的LOAD GENERATOR上。当虚拟用户准备好以后就开始对被测应用施压,在施压的同时LOADRUNNER会完成如下的操作;

    1) 记录在脚本中定义的每个事务的执行时间;

    2) 执行脚本中定义的集合点的功能;

    3) 收集每个虚拟用户发出的告警,错误和提示信息;

    Ø 初始化用户组

    单击START SCENARIO 按钮执行场景时,虚拟用户并没有立刻执行脚本,而是首先执行一个初始化过程,初始化完毕的用户状态会变为READY,只有状态为READY 的用户才能真正开始执行脚本。由于各种条件的限制,场景中用户的初始化过程是无法达到完全同步的,这就造就了用户无法同时运行测试脚本。为了让用户能够同时对被测应用施压,LOADRUNNER提供了初始化用户组的策略,让所有用户在执行脚本之前全部变为READY 状态。

    初始化用户组的方法是在开始运行场景之前,先在RUN选项卡中选中要初始化的用户组,然后单击工具栏的INITIALIZE THE SELECTED VUSERS按钮,或者单击鼠标右键,在弹出的菜单中选择INITIALIZE GROUPS命令,如果初始化成功,用户状态变为READY,如果失败,用户的状态就会变为ERROR。

    Ø 停止场景的运行

    一个场景会在以下三种情况停止运行:

    1) 所有用户都执行完脚本;

    2) 测试人员手动停止了场景的运行;

    3) 执行超时;

    在线监视场景

    注意:必须以被监视机器的管理员身份登陆到CONTROLLER所在机器,才能添加被监视机器的性能计数器;

    Ø 常见的计数器

    1) MEMORY相关,内存问题主要检查应用程序是否存在内存泄露,如果发生了泄露,PROCESS\PRIVATE BYTES计数器和PROCESS\WORKING SET计数器的值往往会升高,同时AVALIABLE BYTES的值会降低.内存泄露应该通过一个长时间的测试来检查,主要测试当所有内存都耗尽时应用程序的反应情况;

    2) PROCESSOR相关,判断应用程序是否存在处理器的瓶颈

    如果PROCESSOR QUEUE LENGTH显示的队列长度保持不变(>=2),且处理器的利用率%PROCESSOR TIME超过90%,那么很可能存在处理器瓶颈;

    如果发现PROCESSOR QUEUE LENGTH显示的队列长度超过2,而处理器利用率却一直很低,那么或许更应该去解决处理器的阻塞问题,处理器一般不是瓶颈;

    如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(CONTEXT SWITCHES/SEC,显示的上下文切换次数)比较大,那么就会造成大量的系统资源;

    如果系统吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在1500以上,那么意味着上下文切换的次数过高;

    还可以比较CONTEXT SWITCHES/SEC和%PRIVILEGED TIME来判断上下文切换是否过量;如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这么高的上下文切换;

    3) 网络吞吐量及带宽

    BYTES TOTAL/SEC: 判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较,相除结果应该小于50%;

    4) 磁盘相关

    判断磁盘瓶颈的方法是通过以下的公式来计算:

    每磁盘的I/O数=[读次数+(4*写次数)]/磁盘个数

    如果计算的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈;

    5) WEB SERVER相关

    6) 数据库服务器相关

    设定监视器选项

    选择TOOLS|OPTION命令,在MONITORS选项卡中可以统一设定监视器的一些参数选项,

    1) TRANSACTION DATA

    用于监视事务图表的数据行为,这些参数不能在场景运行过程中更改,参数修改后需要重新连接虚拟用户的LOADGENERATOR才能生效;

    ENABLE TRASACTION MONITOR:如果选择该选项,场景启动后就自动开始监视事务,默认情况下,该选项是选中的;

    FREQUENCY:设定MONITOR抽样数据产生事务,获取数据点和生成网络资源在线图表的频率.默认为5秒,如果是小的场景建议使用1秒;如果大一些的场景,建议3-5秒;这个参数越低,采样间隔越小,监视图表越精确,网络工作量也就越大;

    2) SERVER RESOURCE MONITORS

    定义了服务器资源监视器的行为,修改该选项对已经被激活的图表不起作用,只对随后被激活的图表起作用;

    DATA SAMPLING RATE:定义了服务器两次采样数据的时间间隔,默认为3秒,这个参数对所有图表都起作用,如果要对单个图表起作用,需要在单个图表的配置属性中定义,

    每个图表都有一个最小的采样频率,如果这里设定的值低于图表的最小采样频率,图表仍然使用最小的采样频率;

    3) ERROR HANDLING

    定义了监视过程中的错误处理方式;

    SEND ERROR TO THE OUTPUT WINDOW:遇到错误时将出错信息输出到OUTPUT窗口;

    POP-UP AN ERROR MASSAGE BOX:遇到错误时弹出错误信息窗口;

    4) DEBUG

    设定DEBUG场景的方式;

    DISPLAY DEBUG MESSAGE:选中该复选框,系统会向输出日志中发送DEBUG相关信息,定义DEBUG的等级

    合并图表

    LOADRUNNER为了便于测试人员比较两个图表数据之间的关系,提供了图表合并的功能,也就是可以将同一个场景中的两个图表中的计数器合并到一个图表中,合并以后的图表共用一个X轴。

    要合并两个图象,只需右键单击一个图表,在弹出的快捷菜单中选择OVERLAY GRAPHS命令,然后在系统提示的对话框中选择另一个图表,并为新图表命名,需要注意的是只有X轴相同的图表才能合并

    其他与监视图表相关的功能

    Ø 穿越防火墙监视图表;

    为了安全起见,运行MONITOR和VUSER的机器安装了防火墙,这样处于防火墙之外的CONTROLLER在控制虚拟用户执行和监视场景的时候就会碰到一些麻烦;

    LOADRUNER通过在防火墙上使用基于HTTPS或者使用标准SSL端口(443)的安全的TCP/IP的协议来解决这个问题。使用LOAD GENERATOR机器或MONITOR机器上的代理充当通信过程的媒介,与MI LISTENER通信。 MI LISTENER是一个需要单独安装的LOADRUNNER组件,它服务于CONTROLLER和LOADRUNNER代理之间,

    如果未安装MI LISTENER组件,LOADRUNNER也可以穿越防火墙实现监控MONITOR和执行VUSERS,这时需要在LOAD GENERATOR 端和CONTROLLER端的防火墙上均打开54345端口;

    Ø 远程监视场景;

    LOADRUNNER提供了一个组件,用于同时通过多个机器上的WEB页面远程监视场景,每个监视还可以根据需要定制不同监视图表

    要完成远程监控,需要一个远程性能监视服务器,(REMOTE PERFORMANCE MONITOR SERVER),它是一个包括很多ASP页面和性能图表过滤器的网站,和CONTROLLER交互数据,并且决定能够在线查看场景的用户数。远程性能监视服务器上必须安装LOADRUNNER的REMOTE PERFORMANCE MONITOR SERVER组件,该组件有如下系统需求:

    • WEB SERVER: IIS5.0
    • 操作系统:WINDOWS 2000SERVER或WINDOWS 2000ADVANCED SERVER
    • 客户端浏览器:IE5.0或NETSCAPE6.2以上;

    使用ANALYSIS分析结果图表

    LOADRUNNER除了将获取的原始数据形成直观的图表外,还对数据进行了一些统计,,例如在多数分析图表下方的图例列表中,给出了最大值,最小值,平均值,中间值和STD等一些统计字段,便于用户分析;

    STD是一个统计学概念,称为标准偏差值,是用来衡量数据的偏离程度的.当平均值不多时,可以从STD指标看出统计图表列数据到底是分散还是集中的.STD越小表示图表的列数据越集中,拿AVERAGE RESPONSE TIME来说,也就表示每个虚拟用户单一的响应时间值大致是差不多的,即被测系统的反应很稳定,没有大起大落;

    1) TRANSACTION PERFORMANCE SUMMARY

    可以基本确认哪个事务的响应时间比较长,一般来说,响应时间长的事务是分析的重点;

    2) AVERAGE TRANSACTION RESPONSE TIME

    可以详细查看每个事务在场景运行中的响应时间,

    3) WEB PAGE BREAKDOWN

    用于分解页面,查看页面中哪些组件导致事务的响应时间比较长,

    • DNS RESOLUTION时间 DNS服务器解析IP地址的时间,这个度量时间可以确定DNS服务器或者DNS服务器的配置是否有问题,如果DNS运行正常,这个值一般比较小;
    • CONNECTION时间 浏览器和WEB SERVER建立初始化连接的时间,这个度量可以判断网络情况,也可以判断WEBSERVER是否响应这个请求;
    • SSL HANDSHAKING 时间 建立SSL连接的时间,使用SSL协议页面比较少,一般应用在HTTPS通信;
    • FTP AUTHENTICATION时间 FTP服务器在处理客户端的命令之前,首先要对客户端进行鉴权,这个度量就是FTP服务器对客户端进行鉴权的时间;
    • FIRST BUFFER时间 指连接建立成功后,从WEB SERVER发出的第一个数据包经过网络传输到客户端,浏览器成功接受到第一个字节的时间.这个度量既包括WEB SERVER的延迟时间,也包括了网络的反应时间.
    • RECEIVE时间 从浏览器收到第一个字节起,直到成功收到最后一个字节,所经历的时间.这个度量和组件大小结合,可以判断网络的质量;
    • CLIENT时间 指请求在客户端的延迟时间,这个延迟可能是浏览器的THINK TIME等引起的
    • ERROR时间 指从发送HTTP请求到HTTP错误信息返回的时间;

    4) TIME TO FIRST BUFFER BREAKDOWN

    可以将页面或组件的时间分解为服务器时间和网络时间,帮助测试人员判断问题缘由到底是服务器还是网络存在瓶颈;

    5) THROUTPUT

    可分析整个压力测试过程中WEB SERVER的吞吐量,即虚拟用户在测试过程中各时刻从服务器上接收到的数据量.

    6) DOWNLOAD COMPONENT SIZE

    页面元素的大小分解和比较

    7) WINDOWS RESOURCE

    系统资源图表,可以监视服务器端的系统资源使用情况,从而判断服务器的CPU,内存等是否是导致性能降低的原因;

    Ø 关于分析图表的几个选项

    • 自动整理合并结果

    在使用ANALYSIS分析场景结果之前,首先要明确结果文件中收集了哪些信息,默认情况下,各个虚拟用户的执行结果数据都是存放在各个虚拟用户所在的机器上的,场景执行结束后,才被系统自动整理合并后放置到结果目录下,LOADRUNNER是否执行这个整理合并操作是受CONTROLLER中的AUTO COLLATE RESULTS选项控制的。该选项设定方法是在RESULTS下选择AUTO COLLATE RESULTS复选框;

    • 设定收集结果信息方式

    对于结果文件大于100MB的大型场景,ANALYSIS加载结果数据时会耗费很长时间,测试人员在等待全部数据加载的同时可以首先查看结果的概要数据,这样,在测试人员浏览概要信息的时候系统会陆续加载其他详细信息数据;

    测试人员可以根据需要设定是否产生概要数据,以及以何种方式显示结果信息,设定入口:菜单 TOOLS|OPTION|RESULT COLLECTION ,

    在DATA SOURCE一栏有三个选项供测试人员选择;

    只生成概要数据;只生成全部详细数据;在生成全部详细数据的同时显示概要数据;

    • 设定数据聚集粒度
    • 使用系统自动聚合的公式自动聚合数据 ;
    • 使用系统自动聚合公式只对WEB数据进行聚合;
    • 单击AGGREGATION CONFIGURATION自己定义聚合方式 ;

    使用ANALYSIS技巧

    Ø 查看图表技巧

    1) 将鼠标放置到图表上需要放大部分的起始位置,然后按住鼠标左键拖动,松开鼠标后鼠标圈住的矩形部分的图表放大显示,便于用户查看图表细节;

    2) 在图例列表中选择一个MEASUREMENT,单击鼠标右键,在系统弹出的菜单中选择CONFIGURE MEASUREMENT命令,之后就可以设定显示颜色和比例,通过设定比例,可以让不同数量级的数据都在图表的主要区域显示,使每个图表的趋势都很明显;

    3) 在图例列表中单击鼠标右键,选择CONFIGURE COLUMN,可以设定在图例列表包含哪些列,以及表格中的图例如何排序等;

    4) 在图表中单击鼠标右键,选择SET FILTER/GROUP BY,可以筛选图表中要显示数据和数据的分组方式;

    Ø 分析图表技巧

    1) 向下钻取图表

    选中一个图表中的某条折线,单击鼠标右键后选择DRILL DOWN,可以对选定的MEASUERMENT J进行向下钻取,钻取的方向可以根据需要进行选择,要取消钻取,需要使用SET FILTER/GROUP BY功能;

    2) 查看原始数据

    在图表下面的RAW DATA或GRAPH DATA中,可以查看图表的原始数据;

    3) 自动关联图表

    在一个图表上单击鼠标右键,在弹出的菜单中选择AUTO COLLATE命令,依据提示进行设定后,系统会自动搜寻和该图表趋势有一定规律的图表,合并到该图表上,该功能便于测试人员分析指标间的联系,

    4) 合并图表

    为了便于分析指标间的相互关系,在ANALYSIS中还可以手动将两个图表合并为一个图表.两个图表合并的条件是具有相同的X轴,合并图表的方法是:在ANALYSIS中用鼠标右键单击想要合并图表重中的一个,在弹出的菜单中选择MERGE GRAPH,根据系统提示选择被合并的图表和合并方式,系统会自动生成新的合并后图表.下面是ANALYSIS图表的3种合并方式

    • OVERLAY

    两个图表合并和共用一个X轴,左边的Y轴上标识当前图表的刻度值,右边的Y轴标识被合并图表的刻度值。当有多个图表被合并时,仍显示一个Y轴刻度,这时可以通过设定图表的显示比例让所有图表都显示在主区域;

    • TILE

    两个图表合并后共用一个X轴,Y轴会被分为两个部分,这样合并的两个图表,看起来相对独立一些,其中一个显示在另一个的上部;

    • CORRELATE

    在合并图表后的图表中,其中一个图表的Y轴作为合并后的Y轴,而另一个图表的Y轴作为合并后图表的X轴,这样合并的图表更能看出两个图表变化趋势之间的关系

    Ø 引入外部数据

    监视场景的时候,可以通过添加计数器的方式监视服务器的系统资源,使用ANALYSIS打开场景的结果文件后,就可以对这些系统资源的数据图表进行分析.

    但有时受客观条件的限制,测试人员无法在LR场景中监视服务器系统资源,这时可以采用一个办法,就是让服务器自己监视自己的资源,并生成相应的CSV文件,当使用ANALYSIS分析结果的时候,把这些单独的CSV文件作为外部数据导入到ANALYSIS中;

    LOADRUNNER提供了ANALYSIS IMPORT DATA工具允许测试人员把一些非自身生成的数据信息引入和集成到ANALYSIS的SESSION中,引入之后,就可以使用ANALYSIS的工具对它们进行查看和分析了。

    工具入口:菜单TOOLS|EXTERNAL MONITORS|IMPORT DATA

    单击ADD FILE 按钮,输入保存的外部数据源文件后,需要在FILE FORMAT中正确选择数据源的格式,否则可能导致引入过程失败;

  • lr性能分析图解释(转)

    2009-05-21 17:21:50

    Loadrunner关联(一)什么时候需要做关联

    1.关联的含义

    关联(correlation):在脚本回放过程中,客户端发出请求,通过关联函数所定义的左右边界值(也就是关联规则),在服务器所响应的内容中查找,得到相应的值,已变量的形式替换录制时的静态值,从而向服务器发出正确的请求,这种动态获得服务器响应内容的方法被称作关联。

    其实关联也属于一同特殊的参数化,只是与一般的参数化有些不同

    一般的参数化的参数来源于一个文件、一个定义的table、通过sql写的一个结果集等,但关联所获得的参数是服务器响应请求所返回的一个符合条件的、动态的值

    2.什么时候需要做关联

    要想弄清这个问题,我们首先要知道客户端与服务器端的请求与响应的过程

    拿一个登录的过程我们来看一下:

    过程说明:

    客户端发出获得登录页面的请求

    服务器端得到该请求后,返回登录页面,同时动态生成一个Session Id

    当用户输入用户名密码,请求登录时,该Session Id同时被发送到服务器端

    如果该Session Id在当前会话中有效,那么返回登录成功的页面,如果不正确则登录失败

    在第一次录制过程中loadrunner把这个值记录了下来,写到了脚本中,但再次回放时,客户端发出同样的请求,而服务器端再一次动态的生成了Session Id,此时客户端发出的请求就是错误的,为了获得这个动态的Session Id我们这里用到了关联。

    所以我们得出结论:

    当客户端的某个请求是随着服务器端的相应而动态变化的时候,我们就需要用到关联

    当然我们在录制脚本时应该对测试的项目进行适当的了解,知道哪些请求需要用到服务器响应的动态值,如果我们不明确那些值需要做关联的话,我们也可以将脚本录制两遍,通过对比脚本的方法来查找需要关联的部分,但并不是说两次录制的所有不同点都需要关联,这个要具体情况具体分析

  • ip欺骗

    2009-05-21 17:20:28

    Loadrunner关联(一)什么时候需要做关联

    1.关联的含义

    关联(correlation):在脚本回放过程中,客户端发出请求,通过关联函数所定义的左右边界值(也就是关联规则),在服务器所响应的内容中查找,得到相应的值,已变量的形式替换录制时的静态值,从而向服务器发出正确的请求,这种动态获得服务器响应内容的方法被称作关联。

    其实关联也属于一同特殊的参数化,只是与一般的参数化有些不同

    一般的参数化的参数来源于一个文件、一个定义的table、通过sql写的一个结果集等,但关联所获得的参数是服务器响应请求所返回的一个符合条件的、动态的值

    2.什么时候需要做关联

    要想弄清这个问题,我们首先要知道客户端与服务器端的请求与响应的过程

    拿一个登录的过程我们来看一下:

    过程说明:

    客户端发出获得登录页面的请求

    服务器端得到该请求后,返回登录页面,同时动态生成一个Session Id

    当用户输入用户名密码,请求登录时,该Session Id同时被发送到服务器端

    如果该Session Id在当前会话中有效,那么返回登录成功的页面,如果不正确则登录失败

    在第一次录制过程中loadrunner把这个值记录了下来,写到了脚本中,但再次回放时,客户端发出同样的请求,而服务器端再一次动态的生成了Session Id,此时客户端发出的请求就是错误的,为了获得这个动态的Session Id我们这里用到了关联。

    所以我们得出结论:

    当客户端的某个请求是随着服务器端的相应而动态变化的时候,我们就需要用到关联

    当然我们在录制脚本时应该对测试的项目进行适当的了解,知道哪些请求需要用到服务器响应的动态值,如果我们不明确那些值需要做关联的话,我们也可以将脚本录制两遍,通过对比脚本的方法来查找需要关联的部分,但并不是说两次录制的所有不同点都需要关联,这个要具体情况具体分析

  • Loadrunner关联(一)什么时候需要做关联

    2009-05-21 17:17:17

    Loadrunner关联(一)什么时候需要做关联

    1.关联的含义

    关联(correlation):在脚本回放过程中,客户端发出请求,通过关联函数所定义的左右边界值(也就是关联规则),在服务器所响应的内容中查找,得到相应的值,已变量的形式替换录制时的静态值,从而向服务器发出正确的请求,这种动态获得服务器响应内容的方法被称作关联。

    其实关联也属于一同特殊的参数化,只是与一般的参数化有些不同

    一般的参数化的参数来源于一个文件、一个定义的table、通过sql写的一个结果集等,但关联所获得的参数是服务器响应请求所返回的一个符合条件的、动态的值

    2.什么时候需要做关联

    要想弄清这个问题,我们首先要知道客户端与服务器端的请求与响应的过程

    拿一个登录的过程我们来看一下:

    过程说明:

    客户端发出获得登录页面的请求

    服务器端得到该请求后,返回登录页面,同时动态生成一个Session Id

    当用户输入用户名密码,请求登录时,该Session Id同时被发送到服务器端

    如果该Session Id在当前会话中有效,那么返回登录成功的页面,如果不正确则登录失败

    在第一次录制过程中loadrunner把这个值记录了下来,写到了脚本中,但再次回放时,客户端发出同样的请求,而服务器端再一次动态的生成了Session Id,此时客户端发出的请求就是错误的,为了获得这个动态的Session Id我们这里用到了关联。

    所以我们得出结论:

    当客户端的某个请求是随着服务器端的相应而动态变化的时候,我们就需要用到关联

    当然我们在录制脚本时应该对测试的项目进行适当的了解,知道哪些请求需要用到服务器响应的动态值,如果我们不明确那些值需要做关联的话,我们也可以将脚本录制两遍,通过对比脚本的方法来查找需要关联的部分,但并不是说两次录制的所有不同点都需要关联,这个要具体情况具体分析

  • LoadRunner:虚拟用户数和并发用户数的联系

    2009-05-21 17:15:09

    例如OA系统使用用户是100个,这个就是系统用户数,该系统有一个统计查询功能,最高峰在线50人,那么系统的并发数是多少?

      OA系统使用用户是100个,这个就是系统用户数。

      最高峰值50人同时在线,只表明同时登录了这个模块,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。这50人在线,有可能开着电脑溜达去了,有的看的别的模块等等。

      并发用户:是同时执行一个操作的用户,或者是同时执行脚本的用户,这个并发在设置不同场景的时候并发的情况是不一样的,在实际的测试中需要根据具体的需求进行设计。web系统,在线不等于并发,如何计算这个并发数是个难题。这个就是设置集合点时候设置的在scenario->Rendezvous,点policy 设置的用户数。

      估算并发数的公示:

      (1) 计算平均的并发用户数: C = nL/T

      (2) 并发用户数峰值: C’ ≈ C+3根号C

      公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

      公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

      假设有一个OA系统,该系统有3000个用户,(可以看注册信息)平均每天大约有400个用户要访问该系统,(日志文件查看)对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

      则根据公式(1)和公式(2),可以得到:

      C = 400*4/8 = 200

      C’≈200+3*根号200 = 242

      但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值,2或者3.

      假如说用户要求系统每秒最大可以处理100个登陆请求,10/25/50/75/100 个并发用户来执行登陆操作,然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候,响应时间还在允许范围呢,就要加大用户数,例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

  • 软件测试LR通用性能分析流程

    2009-05-19 18:32:10

    第一步:从分析Summary的事务执行情况入手

      Summary主要是判定事务的响应时间与执行情况是否合理。如果发现问题,则需要做进一步分

      析。通常情况下,如果事务执行情况失败或响应时间过长等,都需要做深入分析。

      下面是查看分析概要时的一些原则:

      (1):用户是否全部运行,最大运行并发用户数(Maximum Running Vusers)是否与场景设计的最大运行并发用户数一致。如果没有,则需要打开与虚拟用户相关的分析图,进一步分析虚拟用户不能正常运行的详细原因;

      (2):事务的平均响应时间、90%事务最大响应时间用户是否可以接受。如果事务响应时间过长,则要打开与事务相关的各类分析图,深入地分析事务的执行情况;

      (3):查看事务是否全部通过。如果有事务失败,则需要深入分析原因。很多时候,事务不能正常执行意味着系统出现了瓶颈;

      (4):如果一切正常,则本次测试没有必要进行深入分析,可以进行加大压力测试

      (5):如果事务失败过多,则应该降低压力继续进行测试,使结果分析更容易进行;

      ......

      上面这些原则都是分析Summary的一些常见方法,大家应该灵活使用并不断地进行总结与完善,尤其要主要结合实际情况,不能墨守成规。

      第二步:查看负载生成器和服务器的系统资源情况。

      查看分析概要后,接下来要查看负载生成器和待测服务器的系统资源使用情况:查看CPU的利用率和内存使用情况,尤其要注意查看是否存在内存泄露问题。这样做是由于很多时候系统出现瓶颈的直接表现是CPU利用率过高或内存不足。应高保证负载生成器在整个测试过程中其CPU、内存、带宽没有出现瓶颈,否则测试结果无效。而待测试服务器,则重点分析测试过程中CPU和内存是否出现了瓶颈:CPU需要查看其利用率是否经常达到100%或平均利用率一直高居95%以上;内存需要查看是否够用以及测试过程是否存在溢出现象(对于一些中间件服务器要查看其分配的内存是否够用)。

      第三步:查看虚拟用户与事务的详细执行情况。

      在前两步确定了测试场景的执行情况基本正常后,接下来就要查看虚拟用户与事务的执行情况。对于虚拟用户,主要查看在整个测试过程中是否运行正常,如果有较多用户不能正常运行,则需要重新设计场景或调整用户加载与退出方式再次进行测试。对于事务,重点关注整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行的事务。总之,对每个用户或事务的执行细节都应该认真分析不可轻易忽略;

      example1:一个性能逐步下降的服务器,需要进一步分析其性能下降的原因【可以查找是否存在内存泄露问题】;

    example2:一个性能相对稳定的服务器,但是响应时间偏大,这时需要分析程序算法是否存在缺陷或服务器参数的配置是否合理。

      第四步:查看错误发生情况。

      整个测试过程中错误的发生情况也应该是分析的重点。下面是查看错误发生情况的常用准则:

      (1)查看错误发生曲线在整个测试过程中是否是有规律变化的,如果有规律通常意味着程序在并发处理方面存在一定的缺陷。图5-9所示的每秒缺陷数量曲线十分有规律,这是因为服务器定期生成缓存文件导致用户不能正常访问而产生的错误;

      (2)查看错误分类统计,作为优化系统的参考。例如对于Web性能测试,当出现瓶颈时往往需要查看服务器的错误统计信息结果:如果“超时错误”占到90%以上,可能需要提高硬件配置;如果较多的“内部服务器错误”,则可能是程序方面存在问题。

      第五步:查看Web资源与细分网页。

      本步骤仅适用于Web性能测试。查看Web资源图时,往往结合前面对虚拟用户以及事务响应时间的分析结果,重点分析服务器的稳定性。对于网页细分功能则遵循如下原则:首先分析从用户发出请求到收到第一个缓冲为止,哪些环节比较耗时;其次找出页面哪些组成部分对用户响应时间影响较大;当对页面的性能问题定位后,就可以采取相关的解决方案。

Open Toolbar