loadrunner入门篇 - Controller控制器

发表于:2018-8-29 13:41

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:一加一    来源:博客园

  Controller组件是LR的控制中心,主要包括场景设计和场景执行两部分。在VuGen中编辑完脚本并将脚本加载到Controller组件中,即开始对脚本运行时的场景进行设计,当场景设计完成后,即可执行该场景。
  场景类型介绍
  Controller控制器提供了手动设计和面向目标两种测试场景。一般情况下使用手动测试场景设计方法,因为能够更灵活地按照需求来设计场景模型,使场景能更好地接近用户的真实使用。面向目标场景则是测试性能是否能达到预期的目标,在能力规划和能力验证的测试过程中经常使用到。
  启动方式有两种:第一种是在开始菜单中启用;第二种是在VuGen发生器的Tools菜单中启动,如图1所示。
   
  图1
  1、手动测试场景
  启动Controller控制器后,会弹出‘新建场景’对话框,如图2所示。
   
  图2
  这里选中的是手动测试场景,该场景包含两种模式:用户组模式与百分比模式,不同之处在于计算虚拟用户的方式不同。
   
  手动用户组模式如图3所示。
  图3(手动用户组模式)
  百分比模式如图4所示。(scenario->convert senario to the percentage mode,即可切换到百分比模式)
   
  图4(手动百分比模式)
  2、面向目标测试场景
  首先定义要达到的目标,接着LR会自动基于该目标创建场景,在场景运行过程中,LR会不断地将结果与目标相比较,以决定下一步如何执行。
  该场景提供了Virtual Users、Hit per Secnod、Transactions per Second、Transaction Response Time和Pages per Minute一种目标。
  如图5所示是面向目标测试场景界面。
   
  图5
  场景设计
  这里主要介绍Schedule、View Script和Generator参数的设置。而两种场景模式的区别主要体现在Schedule参数的设置上,另外两个参数的设置都是一致的。
  1、手动场景Schedule配置
  主要是用来设置用户的行为方式,这里包括按场景计划和按用户组计划(切换为用户组模式才会有group选项)两种(如图6所示)。
   
  图6(scenario schedule配置界面)
  1)场景名称(schedule name)
  2)按场景计划(schedule by scenario)
  initialize :设置脚本运行前如何初始化每个虚拟用户。包含3种方式:
  a.同时初始化所有虚拟用户;b.每隔一段时间初始化一定数量的虚拟用户;c.在脚本运行之前初始化所有虚拟用户。(通常情况下选择方式三)。
  start vusers :设置虚拟用户加载的过程(是指总的虚拟用户数)。包含2种加载方式:
  a.同时加载所有的虚拟用户;b.每隔一定的时间加载一定数目的虚拟用户。(在实际测试过程中不会选择方式一进行加载虚拟用户)
  duration :设置场景执行的时间,包含2种方式:
  a.一直运行,直到所有的虚拟用户运行完成后,结束整个场景的运行;b.设置场景持续运行时间,一般情况下在进行压力测试时,只需测试15~30min即可,但如果需要测试系统的可靠性和稳定性时,则需要持续运行24h或3*24h。
  stop vusers :设置场景执行完成后虚拟用户如何释放的策略。(只有duration设置为按指定时间运行时才需要设置该项)
  a.当场景运行结束后,同时释放所有的虚拟用户;b.每隔一段时间就停止一定量的虚拟用户。(一般情况下,虚拟用户如何添加就如何停止)
  3)按用户组计划(schedule by group)
  比按场景计划多出了start gruop选项,在该场景中,是以组为单位进行计划的,每个组都要设置自己的start vusers、duration和stop vusers。比较灵活,能够创建实际应用中脚本与脚本之间的约束关系。如一组用户执行后产生的数据记录为另一组用户的输入,这种情况就需要使用该方式来配置场景。使用该场景时,LR默认将每个脚本定义为一个组。
  这里只对start group选项卡进行分析,包含3种方式:
  a.场景执行时立即开始运行该脚本;b.场景执行一段时间后才开始运行该脚本;c.在某个特定的用户组运行结束后才开始运行该脚本,即就是在某个脚本运行结束后才开始运行。
  一般情况下使用场景组方式来运行场景时,会选中每个脚本分别进行设置。如果同时设置则与普通的场景设置没有什么区别。
  4)场景开始时间(scenario start time)
  如图7所示,有3种方式(针对run页面的start scenario):
  a.场景立即开始,没有延误时间;b.推迟指定的时间后才开始运行;在指定的时间开始运行,如晚上8点运行。
   
  图7
  5)百分比模式
  是先设定好虚拟用户总数,然后按百分比的形式对所有的虚拟用户进行分配。该场景适合综合业务模型明确的性能测试。(比如银行的查存取业务)
  2、面向目标场景Schedule配置
  在面向目标场景中,首先定义测试需要达到的目标,然后LR会自动根据这一目标创建场景。
  在场景设置界面,单击edit scenario goal,进入编辑该目标场景对话框,如图8所示,以hit per second目标类型为例,讲述其各项设置。
   
  图8
  1)scenario settings选项卡
  run time:表示当执行达到目标后,该场景还会持续运行一段时间(设置的时间值)才结束运行。
  if target cannot be reached:表示如果目标无法达到,controller将如何处理场景。有2种选择:a.停止运行场景并保存结果;b.继续运行场景直到达到目标。
  2)load behavior选项卡
  设置加载行为,有3种方式:a.让controller自动加载用户;b.设定一个时间,在该时间后达到目标;c.每隔一段时间增加一定的目标量。
  3)目标类型
  a.virtual users
  主要是用来测试服务器对并发用户的处理能力,假如将虚拟用户设置为100个,那么LR会逐渐递增虚拟用户,直到加载到100个为止,如不能达到,将采取if target cannot be reached中设置的策略来继续运行当前的场景。(如图9所示)
   
  图9
  b.hits per second
  设置的目标是点击数/秒,如图10所示,同时要设置最大和最小虚拟用户数。因为点击率的值大小与虚拟用户数成正比,假设测试出来的点击率的值达不到目标值,那么就必须增加虚拟用户数,否则点击率的值就不可能增加,所以在设置点击率的值为目标时,就必须限定虚拟用户数的范围,也即最大和最小虚拟用户数的值。
  运行原理:当场景执行时,controller会先用最小虚拟用户数去执行,结束后判断点击率的值是否达到目标值,如果达到了则停止当前运行的场景;否则继续增加虚拟用户,再判断结果是否达到预期目标值。一直重复,直到达到目标 。如果使用最大虚拟用户数还是无法达到目标值时,那么场景将会停止运行,并保存相应的结果。
   
  图10
  c.transaction per second
  设置的目标为每秒处理的事务数,如图11所示,注意在脚本中一定要定义事务,否则事务名称栏为空白。
   
  图11
  如果从业务的角度看,每秒钟处理的事务数即为系统每秒钟处理的业务笔数,所以该项指标更多的是用于衡量系统每秒钟处理的业务数。同样的也要设置最大和最小虚拟用户数,因为要改变每秒钟处理的事务数就必须通过虚拟用户数来改变,但要注意的是,当虚拟用户数成倍增长时,处理的事务数并不会成倍增长,因为随着虚拟用户数增多,事务的平均响应时间也增加了,这样在相同的时间内,每个虚拟用户处理的事务数就相当少了,所以处理的事务数不可能成倍增长。
  运行原理:跟hits per second的原理相同
  d.transaction response time
  设置的目标为多用户并发时事务的响应时间,如图12所示
   
  图12
  运行原理:跟hits per second的原理相同,假设当前虚拟用户数为10个,那么说明系统最多只能处理10个用户同时请求。如果使用最大的虚拟用户数还是无法达到目标值时,那么场景将会停止运行,并保存相应的结果,同时也说明系统可以支持更多的虚拟用户同时运行。
  e.pages per minute
  设置的目标为每分钟处理的页面数,如图13所示。
   
  图13
  每秒钟处理的页面数与每秒钟处理的事务数,其本质是一样的,因为一个事务可能由多个页面组成,当一个事务只由一个页面组成时,那么每秒种处理的页面数一每秒钟处理的事务数完全一致。
  在以下情况下,hits per second、transactions per second、pages per minute类型的场景结果中会被置为failed状态:
  a.控制器使用指定的最大用户数,并且执行两次都没有达到目标;b.负载机不够;c.所有的用户都运行失败;d.控制器增加了几批虚拟用户后,hits per second、transactions per second、pages per minute的值没有增加。
  3、配置View Script
  在场景设计界面,脚本加载后,如需对加载的脚本进行修改,可以选中需要配置的脚本并单击右键,选择View Script对脚本进行修改。
  要注意修改后,一定要重新加载该脚本才能确保场景执行中的脚本是修改后的脚本
  4、配置Load Generator
  Load Generator 又称负载发生器,当控制器发出执行命令时,Load Generator 负责和其他的负载机建立起联系并强制负载机执行。一个controller可以通过Load Generator 来控制多台负载机。如图14所示
   
  图14
  可以add负载机,完成后connect,测试负载机与控制机连接的情况,如果status为ready,表示连接成功;如果为failed,表示连接失败,这时就要检查网络是否存在问题。
  在使用负载机模拟多用户测试系统时,需要注意以下几个问题:
  1)计算需要负载机的台数。
  在使用负载机时首先需要解决的第一个问题是测试时需要多少台负载机才能满足测试的需要(如测试时需要测试500个虚拟用户),在确定该问题之前需要先确定每个用户需要消耗的系统资源,当把每个虚拟用户按进行的方式来运行时,那么当场景运行时,每添加一个虚拟用户都会增加一个进程,而每个进程都是需要消耗内存和CPU资源的。通常情况下每个虚拟用户消耗多少资源受操作系统、录制时选择的协议及LR的版本3个方面的影响,可百度下官方公布的虚拟用户消耗内存资源参考值。
  比如每个虚拟用户消耗的内存资源大概为6800KB左右,如果以500个虚拟用户为例大概需要消耗3320MB(6800KB*500/1024=3320MB)的内存,如果每台测试机的内存为1GB(3320MB/1024=3.2421875),那么至少需要4台这样的测试机。
  2)控制器如何控制负载机运行。
  控制器通过代理程序去控制负载机运行(代理程序的名称为loadrunner agent process),所以首先需要在控制器和客户端启动代理程序(开始菜单->HP LR->Tools->loadrunner agent runtimes..)。
  启动后弹出loadrunner agent设置对话框,如图15所示
   


    上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号