LoadRunner学习笔记

一、练习

1、参数化的三种策略是什么?第一个策略指的是什么?

答:取值方式、更新方式、越界后处理方式——用户注册脚本,使用控制台,则参数池的策略为:Unique+ Each Iteration+Abort Vuser(U+E+A)

      第一个策略指的是选择下一行参数的方式

2、LR中参数化的取值方式分为哪几种?

答:按照顺序(suquential)、Unique(唯一的) 、Random(随机的) 、Same line as XXX:2个参数如果取值需要保持一致,则设置好其中一个后,另外的一个参数的取值方式可以选择Same line as XXX

3、根据你的理解,尝试写出在线综合场景测试的要点

答:1)多个脚本(三个以上)

      2)每个脚本的Think time移到事务之外

         3)控制台的设置:

           A、虚拟用户数

           B、虚拟用户的部署(加载、持续时间设置)

           C、所有脚本的runtime settings

                 D、WindowsResources(资源监控)

4、性能测试过程中何时需要监控资源,何时不需要监控资源?

答:性能测试过程中都需要监控资源,各种类型性能测试都需要监控服务器(如果有多台服务器,则每台都需要监控),比如基准测试、并发测试、(在线)综合场景测试(如果没有特殊说明,则一般为在线)、疲劳强度测试。

做测试备用数据(注册脚本,注册出30个用户,为后面的测试做准备)或者背景数据(数据库中的容量数据,比如某大型系统,背景数据是2千万)时,则不需要监控被测系统。因为是准备阶段,还没有开始测试。

5、注意:

1)录制脚本过程中,要稍微放慢速度,待当前页面资源下载完毕后再进行下一步,否则脚本录制不完全,回放或者增强脚本时会失败,而且很难修复,修复的方法——重新录制。

      2)web_add_cookie:脚本中的该句代码往往和本机的浏览器设置有关,如果脚本中出现该类代码,尽量不要删除,因为某些大型软件(尤其是银行系统)

会将有用的信息写入cookie中。

二、本章总结

1、手动设置场景(必会)

2、多机联合测试(必须掌握)

3、面向目标的场景类型(可以不会,了解)

三、控制台设置

1、当控制台中虚拟用户数为百分比时,可以通过new新场景中的设置(百分比对勾取消)修改

2、企业中,一般的并发测试为几百居多

3、Duration:如果Duration设置为30分钟,则当30分钟到达时,所有的VUs运行完当前的action,然后再退出。Duration中包含的是完整的action。

4、正常的在线综合场景,测试结束后不应该报错,但是如果在线综合场景报错,是不是测试工程师的错?

      1)如果报错的位置在脚本的登录过程中,即500用户在线只有490个用户登录成功,则该性能测试工程师执行的综合场景不规范,则没有达到500用户在线。

      2)如果所有的虚拟用户全部登录成功,在Duration阶段报错数很少,没有达到场景总事务的5%(依不同单位不同项目而定),则视为场景成功。

      3)如果所有的虚拟用户全部登录成功,大量报错, 超过场景总事务数的5%,则场景不通过(不是性能测试工程师的责任)。

5、在线综合场景测试如果有性能需求,则按照需求指标设置运行时间(Duration),如果没有具体需求,则按照常规(经验)设置为1个小时或(50分钟)。

四、注意

1、控制台中跑完后查看走势图时,不光看线型的走势,还要看纵轴的单位,结合纵轴单位,就可以知道该图示曲线是否平稳。

2、在带宽充足的情况下,完美的吞吐量应该随着点击率的升高而升高。如果点击率的增加,而吞吐量持平或者降低,则说明当前的AUT处理能力不充足,当前AUT有可能会遇到响应时间增长甚至报错的情况。

3、在做性能测试之前,要将AUT的数据库备份。

4、运行完成后左侧Available Graph中的图:黑色表示没有监控(没有数据),蓝色表示有数据。

五、初始监控资源(笔试:写出你常用的5个资源)

1、如果把CPU比较画家,则画家面前的桌子就是内存,如果内存中找不到想要取得东西,则需要跑到地下室去取,该处的地下室就相当于磁盘

2、内存的运行速度可以是磁盘的成千上万倍,所以我们要尽可能的减少磁盘的I/O,这也是性能测试调优的一个重要的原则。

3、磁盘的读写可以减少,但不能为0

4、处理器队列:等待处理的线程(或者进程)。比如:一个理发店3个理发师,来了6个顾客,则3个人要排队,则当前的队列就是3。

六、按组设置综合场景

1、要求:在原来场景的基础上增加注册脚本(regis)(1个用户,迭代10次),其中注册脚本先执行,执行完毕后,其余的脚本再执行30分钟,请设置。

Schedule by:Group

 

 

      1)首先设置regis(选中它)的Group Schedule(还需要将它的迭代次数设置为10),设置结果如下图:

 

      2) 其次分别scan、search、buy的GroupSchedule(它们三个设置相同),设置结果如下图:

 

注意:按组设置综合场景,一定要随时观察VU预览图:

 

七、多机联合测试(联机测试)

 

1、联机测试时,对方机器需要准备:

      1)安装了Load Generator

      2)开启Loadrunner AgentProcessor

2、LR的四大组件中的Load Generator不仅可以安装在Windows机器上,还可以安装在Linux机器上,但是其余的三大组件只能安装在Windows系统上。

3、LR安装在Windows机器上,是不是只能测试Windows的AUT?

——不是,被测系统的平台和测试机器的平台无关,例如:百度的程序搭建在Linux环境,但是依然可以测试。

4、练习:

         联机测试要求:

1)       订票2张,使用自己的和同桌的压力生成器(各1个VU)(我没办法实现,只有一台机器)

2)       2张票都要订在自己的网站上(LR自带的tours)。

 

步骤:

1)       确认联网(使用ping命令可以ping通)

2)       确认2台机器联机成功(对方开启Load Generator agent)

3)       脚本中URL地址中所有的127.0.0.1修改成本机(控制台机器)的物理IP(假设是198.16.11.209),刷新脚本到控制台(172.1.1.98是联合的另外一台机器的地址)

 

 

 

4)       上步原因:如果脚本中URL地址为127.0.0.1,则不同的压力生成器执行时都是向压力生成器的本机发送请求,所以会订票到2台机器。第2个代码中的URL修改成控制台所在的机器的IP,则订票的请求都指向同一机器(控制台机器)

我的脚本这里运行不成功,因为没有能联合的机器

5、企业中做联机测试需要修改代码吗?

      答:不需要。因为企业中服务器一般情况下不是自己的客户机,所以脚本中网站的URL地址是确定的服务器的IP地址,而不是127.0.0.1.

八、脚本参数化

1、参数池策略:

1)作业一、

使用脚本empty,写出如下输出结果(单脚本循环10次),不打开控制台(一个参数name,取值a1 a2 a3、、、、a30):

      A、顺序+每次迭代:a1, a2, a3、、、 a10

      B唯一+每次迭代:a1, a2, a3、、、 a10

      C随机+每次迭代:a1, a5, a10、、、a20

      D顺序+每次遇到:a1, a2, a3、、、、a10

      E唯一+每次遇到:a1, a2, a3、、、、a10

      F随机+每次遇到:a1, a3, a10、、、a21

      G顺序+一次:a1, a1,a1, a1, a1、、、、

      H唯一+一次:a1, a1, a1, a1, a1、、、、

      I随机+一次:ax,ax, ax, ax, ax、、、、

2、参数池策略:

1)取值(下一行)方式:

      A、顺序

      B、随机

      C、唯一

      D、跟XX取一样的行

2)更新方式:

      A、每次迭代:当脚本在每次循环时更新参数(去取值)

      B、每次遇到:当脚本执行过程中遇到该参数(比如name参数)即更新这个参数(实际场景很少可以用到

      举例:如果脚本的action中password参数出现2次,则脚本循环一次会遇到该参数2次;循环n次,遇到该参数2n次,即更新2n次。

      C、一次(once):脚本执行过程中,只取值一次(不更新值)。

2)越界的处理方式(只有取值方式为唯一时才会出现此选项):

      A、放弃虚拟用户

      B、使用最后一个值继续

      C、使用循环的方式继续

三、作业2

      1)在线综合场景继续练习

      2)如果1)已经没有问题,练习按照组设计综合场景

      3)得出报告结果,并上传

作者:hlmmcw 发表于 2017/06/17 15:58:36 原文链接 https://blog.csdn.net/hlmmcw/article/details/73381272

阅读:149 评论:3 查看评论

 
[原]LoadRunner学习笔记——Day5

Day5

注意:

1、如果Runtime settings中忽略了think time,则脚本在运行时所有的think time时间记为0,所以lr_think_time不生效,所以也就不需要移到事务之外;但是如果runtime settings中不忽略think time,则事务中的lr_think_time一定要移出 。

           2、如果是多用户,则必须要打开控制台;如果需要得到结果报告,则也需要打开控制台

一、练习

1、什么是基准测试,简介其做法

2、什么是并发测试,简介其做法

——多用户进行并发测试,即在同一时刻进行某种操作

3、什么是参数化?

      ——简单的说,就是将脚本中的常量变成变量的过程。比如:订购机票,1000张机票,每张机票的起始和目的城市都有可能不同,所以为了模拟真实的情况,将脚本中录制好的起始城市和目的城市转化成变量,这就是参数化的过程。

4、检查点的三个函数?LR推荐使用的是哪个函数

      ——web_reg_find

二、如何将2个参数写到一个文件中?(regis30中改的)

      即:实现name.bat和password.bat形成一个文件,文件名称不重要,使用两者中任意一个都行,目的是在该文件中,出现2列,一列对应一个参数,比如:第一列对应name参数,第二列对应password参数。

      实现步骤:

      1、参数化脚本中的name、password

      2、点击name.bat,给它增加一列,列名可以不和参数名相同(我还是设置password了)

      3、将所有参数值(2列)拷贝到name.dat中(与上一步的效果相同)

      4、将Name指定为name.dat文件的第一列(使用列号或选择列名都可以)

      5、将Password制定为name.dat文件的第二列(使用列号或选择列名都可以)

三、参数池的策略:

1、select next row(选择下一行的方式——how):

      1)按照顺序(suquential):(默认的)每个VU都是从第一行开始,顺序的向下取值(第一次取第一行、第二次取第二行、、、)

            特点:每个虚拟用户取值序列相同

      2)随机的(random):所有VU随机取值

         3)唯一的(unique):每个VU要唯一的向下取值,第一个用户从第一行开始取(只有选择此种方式时才会出现when out of values)

           例如:如果数据为1(行) 、2(行) 、3(行)、4(行)…….,VU为甲、乙、丙,则取数据的规则:

甲:第一次取1(行)、第二次取2(行)、第三次取3(行)

乙:第一次取4(行)、第二次取5(行)、第三次取6(行)

丙:第一次取7(行)、第二次取8(行)、第三次取9(行)

注意:如果控制台中设置的循环次数为5,则每个VU都循环5次(取5行参数执行)

      4)Same line as XXX:2个参数如果取值需要保持一致,则设置好其中一个后,另外的一个参数的取值方式可以选择Same line as XXX

2、update value on(何时取值——when):

         1)每次迭代(Each Iteration):每次迭代(action的循环)时取值

      2)Each Occurrence(没讲)

3、越界后的处理方法(when out ofvalues):

      1、继续取最后一个值(Continue with last value)

      2、以循环的方式继续(continue in a cyclic manner)

      3、放弃虚拟用户(AbortVuser)

 

注意:

1、       多用户注册脚本,使用控制台,则参数池的策略为:Unique+ Each Iteration+AbortVuser(U+E+A)

2、       如果对于单用户,顺序和 唯一 的取值方式一致

 

四、Runtime settings- Miscellaneous(杂项)中的相关设置

1、Error handling(对错误的处理)

1)Continue on error:先不管错误,继续往下执行。在长时间测试中,如综合场景或者疲劳强度测试时,该项要选中,测试结束后如果失败的事务数是场景中所有事务综合的5%以下则视为场景通过,以上则为失败(系统出错)。

      2)Fail opentransactions on lr_error_message:

      执行到事务中调用lr_error_message()函数,将事务的结果置为Failed

      3)Generate snapshot onerror:对错误进行快照

2、Multithreading:设定脚本是以多线程还是多进程方式运行

      1)Run Vuser as aprocess:以多进程方式运行,场景运行时会为每一个虚拟用户创建一个进程   

2)Run Vuseras a thread:以多线程方式运行(一般都是它,节省客户端的资源),将每个虚拟用户作为一个线程来运行,在任务管理器中只看到一个mmdrv.exe,这种方式的运行效率更高,能造成更大的压力,是默认选项

           如果以多线程方式并发,一个进程可以支持50VU的并发,只会出现一个mmdrv进程;如果以多线程方式并发,Load generator将会比多进程支持更多的用户,具体的一个VU占用内存的取值根据LR的版本不同而不同。

 

五、综合场景测试(在线)

1、综合场景的准备条件:至少3个以上的脚本

2、LR的tours网站,购票、查询订票线路 和 搜索航班

3、准备好三个脚本,在将脚本(三个脚本放入同一个文件夹中,同时在VUG中打开)放入控制台前需要做的工作是?——去掉所有事务里面的Think time,建议移出事务,不要删除,不要注释(因为录制时的停顿一般是模拟用户的操作,如果注释或者删除,甚至脚本中没有think time,则脚本不真实,此时综合场景测试设置(按照脚本录制的thinktime的随机百分比设置)的thinktime则无效), 保留,原因是要真实模拟实际的生产环境

4、在线综合场景测试时,如果事务中的think time不移出,则后果是?

答:因为综合场景根据实际生产环境要保留think time,所以事务中的think time(没有移出的话)会生效,进而影响事务的响应时间,会导致结果不准确。

5、脚本修改完毕要编译,保证没有语法错误,准备加入控制台(控制台中如果脚本路径为红色,说明路径错误,重新选择即可)

6、控制台中设置:

      1)设置用户数:买2  查路线2  搜索航班4(此时Load Generator是本机服务器)

      2)Schedule by:Scenario(场景方式),所有的虚拟用户统一听指挥,可以同时设置三个脚本(Ctrl同时选中它们)

           场景类型:

           A、按场景Scenario设置:即场景中所有的虚拟用户统一行动,一般都用这个

           B、按组group设置:场景中每个组(执行不同脚本的VUs,一个脚本的用户成为一个组)分头行动

      3)Global Schedule:

           A、Initialize:默认(运行前初始化每一个虚拟用户)

           B、Start Vusers:每隔1s一个Vuser

           C、Duration:设置运行30mins

           D、Stop Vusers:一般不设置(退出时一般没有压力)

      4)runtime settings:

           A、Runtime logic:不动,因为已经设置了Duration

           B、Pacing:设置随机6-9s(企业中一般2-3s)

           C、Log:不动(如果调试脚本,可以设置,方便随时查看日志;如果运行场景,则只在报错时发送日志即可)

           D、Think time:设置按照录制时间的200%-400%随机(企业中一般选择默认的50%-150%)

           E、Miscellaneous(杂项):

                 Error:Continue on error,场景出错时继续

                 MultiThreading:Run user as a thread,以线程运行VUs

           F、Speed Simulation(Network speed):

Usemaximum bandwidth:使用最大带宽,如果带宽不充足则LR发出的请求可能会只有部分成功到达服务器端,导致性能测试结果不准确。带宽越充足越接近真实

           G、Browser Emulation(模拟浏览器):

Simulatebrowser cache:不勾选,不模拟浏览器的缓存——执行严格的测试

           H、Proxy不动

           I、Preference:

Enableimage and text check:不勾选(因为此时脚本没有加检查点)

                 Optios:中三个超时时间由120s均改为600s

      5)Windows Resources

           点击它的空白处选择Add measurements(增加计数器):

A、       AddMachine:localhost

B、       将上一步添加进来的资源全部删掉(下一步再添加需要的)

C、       Add  Windows  Resources

a、       Object:Memory  时

Counters中:

选择%Committed Bytes In Use—Add

选择available Mbytess—Add

选择Page Faults/Sec—Add

选择Pages Reads/sec—Add

选择Pages/sec(页面读取率)—Add——后面加的

 

                            Object:Network Interface时

Counters中:

           选择Packets/sec-网络选择loopback (回环,表示本机通讯,企业中测试如果客户端和服务器不是一台机器,则需要选择使用着的物理网卡)(没找到,选择的默认的环境WiFi网络))

           选择BytesTotal/sec—同上

 

Object:PhysicalDisk时

Counters中:

选择Avg. Disk Read Queue Length—Total(磁盘和CPU,选择Total)

选择Current Disk Queue Length—Total

选择Disk Reads Bytes/sec—Total

选择Disk Writes Bytes/sec—Total

 

 

 

Object:Processor时

Counters中:

选择%Processor Time——Total

选择%User Time——Total

 

 

Object:System时

Counters中:

      选择ProcessorQueue Length

                      只要测试的是Windows系统的,选以上14项就足够了

 

      设置完成,点击运行

      运行过程中出现错误修改脚本(点击红色error修改、直接在控制台添加的脚本路径处修改),修改后控制台中菜单栏Details-refresh-scris刷新脚本,之后再重新开跑,资源什么的重新计算,完成场景,保存结果

 

7、性能测试中的设置要把握一个原则,模拟真实场景,并且不给AUT增加额外的负载,以免结果数据不准确。

8、综合场景测试注意:

1、控制台中,开始运行时,在所有的VUs加载的过程中,如果有错误,应马上停止,因为测试要求是所有的VUs在线场景,如果没有达到所有的VUs在线,则无法继续测试

2、要保证所有的VUs登录成功,后面出错可以继续,但是如果大量出错,也要查找原因,必要时停止。

3、有一种错误是正常的:报 发现有资源为负值,没有问题,表示监控的服务器中有出错的计数器,但是不属于监控的13项。

 

六、联系作业:

1、LR自带Tours网站,综合场景完成

2、QTP自带的Tours网站,三个脚本,完成综合场景,设置与上例相同

3、保存测试结果,提交Analysis文件

 

 

作者:hlmmcw 发表于 2017/06/17 15:57:47 原文链接 https://blog.csdn.net/hlmmcw/article/details/73381264

阅读:145

 
[原]LoadRunner学习笔记——Day4

Day4

一、性能测试的学习路线:

1、性能测试的初级部分:

      1)概念的理解和灵活应用:事务、检查点、并发点(集合点),初级的参数池(参数化)

      2)理解并能够灵活应用的测试类型:

      A、基准测试

      B、并发测试

      C、综合场景测试

2、性能测试的高级部分:

      1)脚本调试:高级的参数池部分(三大策略)、关联、涉及简单的C语言函数

      2)控制台设置:继续巩固初级部分,加强对服务器的各项资源控制

      3)结果分析:能够深入理解Analysis报告,并在AUT出现问题时能够尝试进行分析甚至调优,提高AUT的性能

二、小练习

1、什么是并发点(集合点)?并发点的三个策略?

答:系统压力最大的情况——所有用户都集合到系统瓶颈的某个点上进行操作(从脚本的角度讲,这个点就是执行脚本的某一条或一段语句)

三个策略:

A、当全部虚拟用户的百分之XX到达集合点的时候,系统释放用户,继续向下执行

B、当全部的运行着的虚拟用户的百分之XX到达集合点的时候,系统释放用户,继续向下执行

C、当XX个虚拟用户到达集合点的时候,系统释放用户,继续向下执行

2、如果达到50%的用户并发,则如何设置?

答:第一种策略(XX=50)、第三种策略(一半用户)

3、简要介绍检查点的三个函数。

答:

1)       web_find

2)       web_reg_find

3)       web_image_check

三、web_reg_find()函数

1、LR中,带有reg字样的函数,称为注册性函数,该类函数的特点就是要将函数写在相应请求之前。

2、web_reg_find函数注册一个请求,在下一个操作函数(如web_url)检索到的缓存中搜索一个文本字符串

1)返回值用0和1表示;

2)是否注册成功(web_reg_find是注册类型函数,它本身并不执行),不代表查找的内容是否存在;

3)可利用SaveCount进行判断:

web_reg_find(“Search=Body”,”SaveCount=n”,”Text=welcome”,LAST);

解释:

A、       search用来定义查找范围(可以缺省),SaveCount定义查找计数变量名称,可记录在缓存中查找内容出现的次数,可使用该值判断要查找的内容是否被找到

B、       上例是查找内容为welcome的信息,并将出现次数记录在变量n中

3、性能测试中,所有的数据包(客户端和服务器端的对话)分为两类:请求包和应答包;无论是请求包和应答包都分为2部分:header和body

1)header中是一些参数设置

2)body中是真正要传递的信息

4、LR函数(web_或者lr_开头的函数)中出现的变量称为LR变量,该类变量不需要在脚本初始位置定义,但是C语言的变量一定要在初始位置定义

5、strcmp(lr_eval_string("{count}"),"0")==0)解释:

1)strcmp函数的作用是比较2个字符串是否相等,如果2个字符串相等,则函数的返回值为0,即strcmp(a,b)==0

2)lr_eval_string函数的作用:

      A、为C语言函数和LR变量起到桥梁的作用

      B、可以取出LR的变量count的实际值,如3,

      C、为何三层括号:

           a、lr_eval_string函数后面必须接()

           b、()里面是字符串,所以用“ ”

           c、“ ”里面不是普通字符串,而是LR的变量,LR要求如果取LR变量值,则必须要用{ }

3)lr_output_message("%stimes",lr_eval_string("{count}"));解释:

A、%s是格式限定符,表示输出是该处输出字符串;如果是%d,则该出输出整型

B、输出的内容将由逗号后的内容代替

C、如果引号里有多个限定符,则依次按照逗号后的内容来代替,如lr_output_message("%stimes,%d",a,b),则输出时,由a替换%s,b替换%d

4)输出语句lr_output_message写在相应请求之后即可,不一定紧贴在对应的请求后面,只要值形成,随时可以输出

这里的练习均在buyandcheck中添加

 

四、web_find、web_reg_find、web_image_check函数的区别:

1、录制模式区别:web_find只能用在基于HTML模式录制的脚本中,web_reg_find没有此限制

2、位置的区别:web_reg_find是先注册(register)后查找,放在请求语句的前面;而web_find是查找前面的请求结果,使用时放在请求语句的后面

3、设置区别:Runtimesettings中的“enable image and textcheck”对web_find有效,对web_reg_find无效

4、查找方式区别:web_reg_find函数的参数SaveCount记录查找匹配的次数;web_find的机制是一旦查找匹配成功就立即返回,并不继续查找和记录匹配次数

5、查找范围区别:web_find是在返回的页面中进行内容查找,web_reg_find是在缓存中进行查找

6.效率区别:web_reg_find执行效率高于web_find

 

五、基准测试(单用户测试)

1、如果脚本录制过程中遇到页面报错,则放弃录制,从来再来,要保证录制过程绝对正确

2、录制完成的脚本一定要回放,如果正确,再进行下一步增强脚本,如果不正确要查找原因。

3、基准测试步骤:

1)脚本调试,运行通过

2)放入控制台

3)控制台的参数设置:

A、用户数为1

B、虚拟用户部署不需要设置(global schedule)

C、Runtime settings中的设置:

      a-  Runlogic中设置5次迭代(10次也可)

      b-  pacing(循环之间的间隔,一般情况下2-3s左右,因为在线测试过程中,如果用户循环提交请求,但是每次循环之间没有间隔,则过于严格,不符合实际的生产环境)循环之间的间隔,一般情况下设置随机的2-3秒

      c-  thinktime时间忽略,(原因:单用户对系统压力很小,所以是否存在思考时间对结果影响不大)

 

注意:

1、如果将Pacing、Think time值调长,则对AUT的压力减小。

      2、如果测试过程中或者结束后发现脚本错误,则需要重新修改脚本,修改脚本后实现如下步骤:

      1)修改后的脚本要编译

    2)刷新到控制台:控制台中选中脚本(Design页),点击Scenario Groups框中倒数第三个图标(Details),refresh script

      3)重新运行控制台即可(其他的参数不用再重复设置)

 

4、基准测试的第二种:

要求:运行脚本1分钟(singlebuy)

1)脚本调试,运行通过

2)放入控制台

3)控制台的参数设置:

A、用户数为1

B、Duration设置为1分钟(注意: 当Runtimesettings中的run logic和duration都设置时,duration优先级高;  duration默认时,以settings中的run logic为准;  当Duration时间结束时,虚拟用户会运行完当前的action再退出)

C、鉴于上面一步,Run logic中可不设置

D、pacing设置随机的2-3秒(注意: 只要有迭代,就要设置pacing, 这样是为了真实模拟用户使用)

E、think time时间忽略

注意:这里测试过程时间会比duration时间长,为什么?

——因为测试时间=初始化+用户开始时间+duration(持续时间)+用户退出时间

注意:每次测试提交的数据,应该测试3次,选取其中的中间值,如测试的响应时间有3.5、4.5、6.5,则选取4.5。

 

六、参数化

1、在参数池中,备用数据设置(记事本中那个)时要注意:光标要停留在新的下一行(new line)。

2、如何实现qq购票2张?(singlebuy1)

答:Runtimesettings中设置2次迭代

3、如何实现运行脚本让jojo和qq各订一张票?(singlebuy2)

      1)将包含参数池的init部分里的脚本内容(主要是login)移动到action中

      2)参数池从jojo(第一行)开始取值

      3)迭代2次,则第一次迭代(action的循环)时取第一行值jojo,第二次迭代时取第二行值

 

七、作业

1、基准测试:三个脚本,buy、search、scan的事务响应时间的最大值、最小值、平均值

2、注册30个用户(使用脚本),要有检查点(自己已完成,且正确,此此脚本只能运行一次,因为一个用户名只能注册一次: regis30)

      分析:1)用控制台还是单脚本做测试数据比较合适?——控制台多用户(30个用户),压力大不容易成功,所以使用单脚本(单用户)循环

作者:hlmmcw 发表于 2017/06/16 12:33:50 原文链接 https://blog.csdn.net/hlmmcw/article/details/73330052

阅读:134

 
[原]LoadRunner学习笔记——Day3

Day3

 

每天一更新,今天的内容较前两天略少呢,加油!

 

一、复习

1、什么是性能测试?(性能测试的概念)

答:性能测试指在正常、峰值、以及异常条件下测试AUT的各项性能指标是否满足需求,通过自动化工具模拟进行。

2、为什么要执行性能测试?(性能测试的目的)

答:1)评估系统的能力

      2)识别体系中的弱点

      3)系统调优

      4)验证系统的可靠性、稳定性

3、什么地方执行性能测试?(在哪里执行性能测试)

答:从单方面说,每款软件都有性能问题,都需要做性能测试,但是从另外一方面说,并不是所有的软件都需要做性能测试:

例如:360杀毒软件,如果持续执行3小时、4小时,人们不会抱怨该软件的性能有问题,而是说自己的机器如何如何的慢,有病毒之类、、、

12306购票系统——

4、如何执行性能测试?(性能测试的流程)

答:

第一阶段:测试设计阶段

第二阶段:测试环境的准备阶段

第三阶段:测试执行阶段

第四阶段:测试分析阶段

注意:

1、       事务里面不能包括思考时间,要么注释思考时间,要么把思考时间移动到事务之外

2、       验证脚本是否成功的步骤:

A、       在脚本生成器中:单循环、多循环

B、       在控制台中:单用户单循环

单用户多循环

多用户单循环

多用户多循环

5、性能测试术语

A)并发:多用户在同一时刻对被测系统执行的操作,一般指同一操作

B)在线:多用户在同一时间段对被测系统执行的操作(可以是登录、查询、购买等)

C)响应时间:客户端发送请求通过网络传输给服务器,待服务器处理返回数据的这一段时间(客户端时间+网络时间+服务器端时间),通常情况下,可以规避网络时间(局域网测试),所以可以定位为服务器或者客户端的问题

D)事务响应时间:完成相应的事务所花费的时间(性能测试中重要的性能指标)

E)点击率:虚拟用户每秒钟向服务器提交的HTTP请求数,点击一次鼠标有可能触发多个HTTP请求

F)吞吐率:虚拟用户每秒钟从服务器端获取的数据量

F)TPS(transaction per second):每秒钟系统处理的事务或者交易数

H)资源利用率:CPU、内存、网络、磁盘等

6、文件后缀:

1).usr

2).lrs、 .lrr

3).lra

7、虚拟用户的状态

1)Down:关闭,Vuser处于关闭的状态

2)Pending:挂起,Vuser已经准备好了,等待可用的负载生成器的调用

3)Init:正在初始化,Vuser正在登录远程计算机(负载生成器)

4)Ready:就绪,已经执行完脚本的初始化代码,可以运行

5)Run:运行,Vuser正在负载生成器中运行

6)Rendz:集合点,运行到了集合点的位置,正在等待LR释放

7)Passed:通过,Vuser运行完成,并且通过

8)Failed:失败,Vuser运行完成,但是脚本失败

9)Error:错误,Vuser发生了问题(如:Vuser没有登录到负载生成器上)

10)Gradual Exiting:逐步退出,Vuser被调用了stop(窗口中的Stop按钮,或者duration时间后)命令后,正在运行完当前的迭代

11)Exiting:退出,Vuser已经结束运行,正在退出

12)Stop:停止,Vuser被调用了stop(窗口中的Stop按钮,或者duration时间后)命令后

二、检查点

1、一个脚本中必须加入一个检查点,否则不清楚脚本的正确性,但是检查点不宜过多,1-2个足矣

2、一个脚本中在关心的操作附近要记得添加事务,所以一个脚本至少一个事务,但是一般情况下登录也会被添加为事务(事务为了查看响应时间)

3、关心的操作就是测试计划中的测试点,如查询稿件、购买机票等,只要测试计划确定,则测试点确定

4、注意:web_find函数要求:(LR 12.53已不支持这个函数,支持web_reg_find)

      1)写在相应请求之后

      2)开启runtimesettings中的开关

      3)检查的内容在AUT界面上拷贝即可

           4)lr_output_message函数的结果只显示在回放日志中,不会显示在结果报告中

           5)web_find函数的左右边界:

                 A、Rightof 表示左边界

                 B、Leftof表示右边界

5、web_image_check函数2个参数,使用时选取一个即可,另外一个参数可以为空值(此处的例子运行不成功,教学视频中也如此,已分析原因,见代码中备注)

1)alt参数:当光标悬浮在网页图片上时显示的名称(给用户看的,不一定每个图片都有)

2)src参数:该图片在源代码中的路径及名称(给程序员看的)

注意:web_image_check函数不经常使用,使用时要留意检查的图片是不是属于服务器本次发送的数据包中的内容(可以通过result中的快照查看),如果不是本次应答内容,则检测不到

 

web_image_check函数特性与web_find函数相同:

1)写在相应请求之后

2)开启runtime settings中的开关

3)参数内容在源代码中提取

三、作业

1、上一次作业的三个脚本:购买机票、搜索航班、查询订购线路,做5个、10个用户的并发测试

2、记录下测试的结果:事务的最大、最小、平均响应时间

3、预习:查看报告、web_reg_find()函数

作者:hlmmcw 发表于 2017/06/14 10:45:10 原文链接 https://blog.csdn.net/hlmmcw/article/details/73201371

阅读:140

 
[原]LoadRunner学习笔记——Day2

Day2

一、练习题:

1、什么是性能测试?

答:使用工具去模拟实际的生产情况中的业务压力,去测试系统,去攻击系统,去验证系统是否能够承受当前的压力,满足性能的需求指标

2、简述LR的工作原理

答:1、录制时,Loadrunner记录下客户端和服务器二者之间的对话,形成脚本

2、回放时,Loadrunner模拟真正的客户端,向服务器发出请求,并根据脚本来验证服务器的应答

3、简介LR的三大组件,写出其中英文名称

答:1、虚拟用户生成器-virtual user generator

      2、控制台-controller

      3、结果分析器-analysis

4、并发和在线的区别

答:1、并发:多个用户在某一时刻同时进行某个操作,对系统的瞬间压力考虑较大

2、在线:多个用户在某一时间段循环的进行某个操作

5、简述点击量和吞吐量的概念,并简述其区别

答:1、点击量:一段时间内用户向web服务器提交的HTTP请求数(问的总量)

      2、吞吐量:一段时间内客户端从服务器端获得的全部数据量,单位为字节(答的总量)

二、性能测试策略

1、在性能测试之前,功能测试要先通过

2、基准测试:单用户测试,目的是为其他测试提供参考依据。

3、递增测试存在的意义:如果所有的虚拟用户同时加载,有可能造成被测系统AUT的资源突然增大,进而影响后续测试中关心的测试点的数据,所以前面可以稍稍放缓,递增加载虚拟用户。

4、(在线)综合场景测试:(能够最真实的模拟系统实际的生产场景一般情况下,综合场景中要求脚本为3个以上,将虚拟用户分成不同的组,每组执行不同的脚本。注意:一般不要将login脚本加到综合场景中,因为综合场景一般持续时间很长(1hour左右),这段时间内,所有的用户在循环执行操作,而登录不适合做循环。

注意:在设置综合场景中的用户操作比例时,大部分的用户应该做浏览或者查询,少部分做提交操作,如:

10%的用户执行浏览首页

50%的用户执行查询订单

40%的用户执行订购机票

5、并发测试:多用户在同一时刻同时执行某个操作,称为并发测试。并发测试的目的是考察AUT的瞬间压力的承受能力。

6、疲劳强度测试:一般指的是长时间的在线综合场景测试,即在一定的压力强度下进行长时间测试,测试的时间经常为7*24小时,或者24小时等等

7、内存泄漏:系统运行时占用的内存没有得到及时的释放,随着运行时间的增加,被占用的内存越来越多,导致可用物理内存被用光,系统运行缓慢,甚至宕(down)机,这种现象称为内存泄漏。一般比较少见。

内存泄漏检测:使用相应的测试软件进行内存指定计数器的监控,观察是否符合内存泄漏的曲线走势,还可以使用专门的内存泄漏检测工具进行测试。

8、数据容量测试:考察AUT中数据库服务器中存储不同容量数据时AUT的性能反应。

      数据容量的单位:

      1)1024Byte=1K

      2)1024K=1M

      3)1024M=1G

      4)1024G=1T

      5)1024T=1P

9、极限测试:也称“摸高测试”,即 使用 性能测试,逐渐增加AUT的压力,测试出AUT的极限值,如最大的用户数量,最大的吞吐量等

三、Loadrunner的工作方式:

1、脚本生成器将用户的操作录制成脚本(相当于武器)

2、每个虚拟用户都执行这个脚本(相当于每个士兵都手持武器)

3、控制台统一管理所有的虚拟用户(相当于总司令部统一管理所有的士兵)

4、被攻击的城堡相当于AUT(被测系统,部署在服务器上)

 

 

四、事务

五、场景

      1、如何去设置场景的参数:把握一个原则——模拟实际的生产环境(根据经验、对项目的理解)

六、Loadrunner工具组成

除了三大组件以外还有:

1、压力(负载)生成器(Loadgenerator):通过运行虚拟用户产生实际的负载(Controller中那个灰黄图标)

2、代理程序(Agent):部署在各个客户端,协调得到步调一致的虚拟用户。

作用:当控制台统一对各个压力生成器(load generator)进行控制时,每台压力生成器需要启动agent,agent负责实时监听控制台的指令,以达到协调各个压力生成器中虚拟用户的作用。

注意:在做联机测试时,联机的机器需满足2个条件:

         A、已安装压力生成器

      B、启动agent(所有程序——HP software——HP Loadrunner——Advanced settings——Agent process(其实它开机就自启动了,右下角雷达图标))

3、监控器(Monitor):监控主要的性能计数器。在性能测试过程中,要监控所有的服务器的重要资源。(Controller——Run——Windows Resources——右键单击——Addmeasurements…)

监控的原理:LR连接到(本机)服务器上,将(本机)服务器的信息获取下来,展示出来即OK,后面所有的测试(基准测试、综合场景测试等)都要添加Windows资源,到时候还会讲解。

性能测试整个流程图:

 

七、Loadrunner的工作流程(根据上图):

1)LR的脚本生成器对被测系统AUT进行捕捉和录制(选择相应的网络协议,模拟Java客户端或者IE客户端),形成脚本。对于脚本,可以在Runtime settings中进行设置,进而形成场景。

2)在控制台中,对vus(虚拟用户)进行部署,连同场景,形成各种测试场景(包括基准测试、并发测试、综合场景测试等)。场景可以启动或者停止,包括对于压力生成器的控制,还可以在测试过程中对AUT的服务器进行监控。

3)测试过程中形成的海量数据,在测试结束后,统一提交到结果分析器,形成各式图表。

注意:脚本生成器和控制台中都有runtimesettings,控制台的优先级更高

 

八、浏览器的原理

1)当用户访问某个HTML文件时,浏览器首先获得该HTML文件,然后进行语法分析

2)如果这个HTML文件包含图片、视频等信息,浏览器会再次访问Web服务器,依次获取这些图像、视频文件,然后把HTML和图像、视频文件组织起来,显示在屏幕上。

九、录制脚本的过程(以购票为例):

      1、new一个新脚本

      2、点击“init”    

3、填入登录信息(jojo/bean)

      4、插入login事务起始点

      5、点击“login”按钮

      6、插入login事务结束点

      7、切换到“action”

      8、购票(到最后一个continue按钮截止)

      9、插入“buy”事务起始点

10、点击“continue”按钮

11、插入检查点

12、插入“buy”事务结束点

13、切换到“end”

14、退出系统——如果直接关闭页面,则没有真正退出系统,与服务器的连接还在

15、关闭系统

16、结束录制

上述步骤3和4可以调换位置,因为在输入信息时,对服务器没有提交请求,只有当点击“login”按钮的时候才将输入的信息提交给服务器。

注意:

1、       如果遇到查询的脚本,检查点为查询总条数的信息,但是如果系统中信息条数会变化,则需要避开总条数去验证。

2、       LR中LR函数都是以“web_”和“lr_”开头

3、       LR脚本使用类C语言作为脚本,支持LR函数和C语言函数

4、       思考时间:2个步骤之间的停顿时间,此期间对服务器没有任何请求,什么都没有(可以在脚本中手动修改,或者在Runtimesettings中设置)

5、       一般在测试过程中(控制台),需要设置思考时间(根据测试的需求);而在脚本生成器中,一般是忽略思考时间,越快越好。

十、并发测试

1、集合点:系统压力最大的情况——所有用户都集合到系统瓶颈的某个点上进行操作(从脚本的角度讲,这个点就是执行脚本的某一条或一段语句)。

何时使用集合点——并发测试时使用(在事务开始之前添加集合点,则所有虚拟用户执行到集合点时停止,等待并发)

注意:一个脚本中一般只加入一个集合点,如果一个脚本录制的是一个流程(包含多个操作),这样在每个事务前都添加一个集合点(则脚本中有多个集合点),该做法从语法角度没有问题,但是如果脚本运行结果有问题不好分析。

2、并发测试的个条件:

      1)脚本中加入集合点

      2)控制台中设置集合点策略(一般设置第一种:全部用户的XX%)

      3)并发测试是考察系统的瞬间压力承受能力,是比较严格的测试,所以不需要等待时间(think time)——忽略thinktime

3、脚本中添加代码或者修改代码后一定要进行编译(相当于保存)

课后作业:

1、控制台中集合点策略选取,翻译

A、Realeasewhen XX% of all Vusers arrive at the rendezvous:

      当全部虚拟用户的百分之XX到达集合点的时候,系统释放用户,继续向下执行

B、Realeasewhen XX% of all runningVusers arrive at the rendezvous:

      当全部的运行着的虚拟用户的百分之XX到达集合点的时候,系统释放用户,继续向下执行

C、Realeasewhen XX Vusers arrive at the rendezvous:

当XX个虚拟用户到达集合点的时候,系统释放用户,继续向下执行

最后:Timeout between Vusers:XX sec:不能超时XX秒,超的话就不等了,系统释放用户,继续向下执行

注意:

A、LR结果报告中,显示了事务的响应时间的最小值、平均值、最大值,其中平均值比较重要;标准方差越小(趋近于0),表示事务的响应时间越接近,代表系统越稳定。

B、90percent:表示执行该事务的90%的用户都可以在该时间内完成

例如:100个用户共同执行某事务,1个用户执行时间为1000s,99个用户执行时间为0.01s,则90 percent和平均值哪个真实?——90 percent比较真实,也要关注90 percent值。——所以,读报告时,不应只看平均值,也要关注90 percent值。

C、Analysis不能直接打开脚本生成器中的脚本结果,脚本生成器(VuGen)中的脚本只能调试后点击“run”来查看结果

D、当脚本调试通过后——>加到控制台,run后——>打开Analysis

2、熟悉Runtimesettings中的前四项

1)Runlogic:运行逻辑,设置迭代次数

2)Pacing:起搏

      A、Start new iteration as soon as the previous iteration ends

      前一个迭代结束后立刻开始新的迭代

      B、Start new iteration after the previous iteration ends,with Fixed/Random delay of XX seconds

      延迟固定的/随机的 XX秒后/XX秒到XX秒 开始新的迭代

      C、Start new iteration at fixed/Random intervals,every XX seconds

      在固定的/随机的 XX秒后/XX秒到XX秒 开始新的迭代

3)log

4)thinktime

A、Ignore thinke time:忽略思考时间

B、Replay think time as recorded :按照录制的思考时间回放

C、Multiply recorded think by X:录制时间的X倍

D、Use random percentage of recorded think time Minimum XX% MaximumXXX%:用录制时间的XX%到XXX%的一个随机时间

E、limit think time to XX seconds:限制XX秒

3、录制脚本:qtp自带系统,三个测试点:购买机票、搜索航班、查询订购线路

4、英文作业

 

 

作者:hlmmcw 发表于 2017/06/13 18:56:12 原文链接 https://blog.csdn.net/hlmmcw/article/details/73189718

阅读:96 评论:6 查看评论

 
[原]LoadRunner学习笔记——Day1

Day1

一、       什么是性能测试:

1、在线取款:一个人取款2000,成功——功能测试通过

2、在线取款:

           1)一个人取款(计时)2000,用时0.5小时——功能测试通过,性能测试结果很差(性能测试考察的一个方面:响应时间过长)

           2)1000人共同取款,系统崩溃——性能测试考察的一个方面:多用户支持程度

 3、性能测试——必须使用工具测试,但是性能测试不局限于工具,还包括很多性能测试的理论知识,背景学科(操作系统、数据库、网络知识、防火墙、协议、开发语言……)

二、性能测试课程设置:

1、性能测试的初级部分(3天左右——达到目标:企业中60%-80%的普通项目能够搞定)

      1)使用1天左右,讲解性能测试理论知识

      2)简单脚本调试

      3)简单的控制台参数设置

      4)简单的性能结果分析

      ——以上为LoadRunner三大组件的基本讲解

2、性能测试的高级部分(5天左右——达到目标:企业中比较有难度的项目可以尝试实现)

      1)复杂脚本调试

      2)复杂场景中控制台设置方式,原理

      3)性能测试结果分析,尤其是有问题时的分析、调优过程研究

      ——以上为性能测试的深入讲解,包括loadruuner的三大组件的深入研究

三、性能测试的基本概念

1、PV:PageView页面访问量,刷新一次即被重新计算一次

      2、项目经理的要求:

      1)测试系统的最大并发用户数

      2)测试系统8小时的最大业务吞吐量

      3)测试系统的稳定性和健壮性

      4)测试系统数据在达到100万条记录时的性能

      5)测试系统的核心事物响应时间是否满足用户的需求

      3、性能测试过程中,数据库中不可以为空数据,或者条数很少,该种情况下测试不符合实际的生产环境,一定要根据系统实际的在线情况(投产使用后),插入足够数据(背景数据)后再进行测试

      4、性能测试的解释:就是使用工具去模拟实际的生产情况中的业务压力,去测试系统,去攻击系统,去验证系统,是否能够承受当前的压力,满足性能的需求指标。

      5、在性能测试之前,要对被测系统(AUT,application under test)进行备份(尤其是数据库的备份)

      6、负载测试、压力测试都属于性能测试

1)负载测试(正常范围内):是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足性能指标的情况下,系统所能承受的最大负载量的测试。

2)压力测试(极限):逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态,并以此来获得系统能提供的最大服务级别的测试。

负载测试和压力测试的区别:

1)       工人建桥,桥身上标明该桥的最大载重量为60吨——负载测试

2)       该桥的内部建筑资料中标明该桥的最大载重量为70吨,这个数据是给内部建桥工程师掌握的——压力测试的最大值

???问题:系统如何能够产生压力?有以下几个方面可以产生压力:

            1)用户数量——用户越多,AUT压力越大

                   2)用户数量固定,发送请求越频繁,则AUT压力越大

四、影响系统性能的主要因素:

      1、硬件(CPU、内存、硬盘、网卡及其他网络设备)

      2、操作系统

      3、网络

      4、中间件—(也叫应用服务器,如Jboss(免费)、websphere、weblogic等)、web服务器

      5、数据库服务器

      6、客户端

      7、编程语言、程序实现方式、算法

五、性能测试的常用术语

1、并发(Concurrency):指多用户在同一时刻(精确到毫秒ms级别)共同执行某一操作;并发测试要求比较严格,着重考察系统的瞬间压力

2、在线(online):多用户在线去循环操作某一动作

      对一般系统而言,多用户并发和多用户在线对AUT的压力比例是10:1,即50用户并发相当于500用户在线执行操作

      并发用户数常见错误观点:

      1)把并发用户数理解为使用系统的全部用户数量

      2)并发用户数量就是用户的在线数量

3、请求响应时间(TTLB-time to last byte):从客户端发送一个请求开始计时,到客户端收到服务器端返回的响应为止,这段时间称为请求的响应时间(单位为s或ms)

      性能测试关心两个词:请求和响应,正常的顺序是请求和应答先发(请求)再收(应答),不存在先收再发的情况。

      请求响应时间=客户端时间+网络时间+服务器时间

      实际的项目测试过程中,经常将AUT部署到内网环境,这样有充足的带宽,即可规避掉网络的瓶颈。

4、事务响应时间:用户完成某个具体事务所需要的时间

      358原则:对于一般系统而言,如果用户点击按钮后,系统可以在3s内得到应答,则用户比较满意;如果系统在5s内得到应答,则用户能够忍受;如果系统在8s后得到应答,则用户不能忍受。

5、点击率:每秒钟用户向web服务器提交的HTTP请求数,点击率越大对服务器的压力也越大(注意:点击不是指鼠标的一次“单击”操作,因为在一次“单击”操作中,客户端可能向服务器发送多个HTTP请求)

      如果用户点击登录按钮,返回的页面中包括3张图片,    则点击量是4=3+1(服务器有4次响应请求),3张图片加1个页面。每秒的点击量称为点击率。如果上述点击过程发生在1s内,则点击率是4。

6、吞吐量:用户在任意给定的时间段内从服务器端获得的全部数据量,单位是字节。

      吞吐量/传输时间=吞吐率——反映服务器的处理速度和性能,也是衡量网络性能的重要指标。

吞吐率和点击率的区别:

      1)吞吐率:指服务器每秒处理的数据量

      2)点击率:指客户端每秒向服务器提交的HTTP请求数

如果在带宽充足的情况下,完美的吞吐量(率)应该随着点击率的增加而增加

7、资源利用率:一般指在进行性能测试过程中,要对AUT的服务器进行资源监控,其中资源服务器的CPU、内存、磁盘和网络等主要的性能计数器,关注其利用情况。

六、手动测试存在的问题:

1、是否有足够的测试资源?(测试人员、客户机)

2、如何调度和同步测试用户?

3、如何搜集和分析测试结果

Loadrunner的解决方案:

1、利用“VirtualUsers”代替实际的测试人员,根据进程或线程,可以在loadrunner中设置,每个虚拟用户其实就是一个虚拟线程,可以代替实际的测试人员

2、运行大量的“Virtual Users”在不同的机器上,由控制台进行指挥

3、通过“controller”管理“Users”

4、利用图标工具分析测试结果

七、Loadrunner的三大组件:

1、(虚拟用户)脚本生成器(Virtual user generator——录制、调试脚本)

2、(压力调度)控制台(Controller)——设置场景参数,管理虚拟用户

3、(压力)结果分析器(Analysis)——生成测试报告(Loadrunner有自带报告,也可以自己利用Loadrunner数据结果自己写报告)

八、Loadrunner的工作原理

1、录制时,Loadrunner记录下客户端和服务器二者之间的对话,形成脚本

2、回放时,Loadrunner模拟真正的客户端,向服务器发出请求,并根据脚本来验证服务器的应答

九、Loadrunner安装

十、测试基本流程:

1、制定性能测试计划(部分)——>创建测试脚本——>编译、运行测试脚本——>创建场景——>运行、监控场景,收集数据——>生成测试报告,分析测试结果

      1)LR自带tours(订票)系统:账户/密码(jojo/bean)

         2)在录制脚本之前,先要手工执行操作(熟悉被测系统AUT:http://127.0.0.1:1080/WebTours/index.htm

      3) 录制脚本的时候一般把我们关心的操作(要测试的)录制到Action中,因为action中能够实现很多init中不具备的功能;把登录录制在vuser_init里面,把退出录制在vuser_end里面:

 

例:录制登录操作,则要将登录录制到(action)部分,因为只测试登录系统,测试点就是登录系统

注意:Loadrunner录制时,每次都要重新点击new

Snapshot——快照,一个页面形成一个快照,即一个图片

注意:当LR的脚本运行得出的result中全部为pass时,不一定证明脚本正确,因为LR只是在网络层面上验证了服务器收到了客户端发送的数据包,并且返回,但是返回的应答中数据是否正确(应答页面是否正确)没有验证。

(各个路径:

C:\Users\yangyang1\Documents\VuGen\Scripts\WebHttpHtml2

C:\ProgramFiles (x86)\HP\LoadRunner

F:\09LoadRunner\LRtest

C:\Program Files(x86)\HP\LoadRunner\scenario)

2、制定性能测试计划(部分):

n  测试登录模块在8个用户的情况下系统的性能情况

n  要求:

Ø  用户数:8人

Ø  用户加载方式:每2s加载一个人

Ø  运行时间:所有用户运行完脚本

Ø  登录用户名:test1

Ø  登录密码:test1

1)准备工作:由于LR整个测试过程会产生很多文件或文件夹,所以对这些文件(夹)的管理很重要,可以按照一下方式创建文件夹:

A、脚本文件

B、场景文件(控制台里面的各项参数设置好后保存在场景文件中)

C、分析器结果文件(结果文件)

D、测试报告(word or execl)

2)创建登录脚本

录制前设置:record——>recordingoptions——>advanced——>为每个页面title自动生成检查点函数/选择UTF-8(测试中文被测系统时减少乱码情况)

3)编译、运行脚本

编译时,可以快速检查脚本的语法问题(格式),但是逻辑问题不能查找出来

4)创建场景

A、先将运行通过的脚本加入控制台

B、控制台中设置参数

C、运行场景

5)检查分析器结果文件

点击control中:Results-Analyze results即可调出来

十一、课后作业:

1、       录制3个脚本:搜索航班(OK),查询购票线路(没调通,加的检查点有问题),购买机票(OK),每个脚本都要添加页面检查点

注意:

1)       性能测试中,脚本不建议调试的过于复杂、脚本中action过多——脚本过于复杂,则系统测试结果出现问题后不易查找性能瓶颈,定位较难,降低工作效率,一般情况下一个测试点(操作)对应一个脚本。

2)       录制脚本不要过急,要待页面资源下载完毕后,再进行下一步,否则脚本无法录制完全,不能调试成功

3)       脚本中检查点不需要加过多,添加1-2个关键的即可,因为检查点也是函数,执行时也要耗费资源——如果脚本添加函数过多,过于复杂,则需要耗费额外的资源,但是所有服务器的资源监控数据都会记录在AUT的结果报告中,造成报告中数据不准确。

4)       性能测试中的在线测试是以循环为主,如查询稿件(购买机票),则脚本的运行方式:登录——查询稿件(购买机票)——查询稿件——查询稿件——退出系统;即脚本中init——action——action——action——end

5)       LR(类C语言脚本)的注释:

单行://

多行:/* */

6)正常来说,一台PC机可以支持上百个或者上千个线程。如果使用线程来运行虚拟用户,则一台PC机可以支持1000-2000用户,如果遇到5000用户在线,则需要联机测试(多台PC)

2、思考:Loadrunner和QTP的区别?相同点?

答:

1)相同点:工作方式都是录制——回放

2)区别

      A、LR:基于协议的性能测试,LR关心的是客户端和服务器之间的对话(数据包),关心的是请求(客户端发出)和应答(服务器端发出),关心的是网络协议(网络上的语言:http)。

QTP: 基于UI对象的功能测试,QTP关心的是AUT的界面,以及界面上的对象,及对象的属性

      B、LR录制原理:捕获数据包;录制的前提是能识别协议报文

QTP录制原理:消息机制,截获消息;录制的前提是能识别控件

      C、LR是性能测试工具,侧重的是压力,负载,容量,并发等的测试

QTP是功能测试工具,针对功能的测试

QTP是功能测试的工具,这个功能测试是指的基于GUI的功能测试.QTP的录制和回放都是真实的去操作客户端程序的各种GUI控件,回放的时候会真实的启动客户端程序.而LR只是录制了客户端和服务器之间的通信数据,回放自然也是这些通信的数据,而且只有在录制的时候跟客户端程序有关系,回放的时候就跟客户端没有任何关系了,回放的时候不会启动客户端程序.

3、sample中服务打不开,端口有冲突,解决端口冲突的问题:

         1)查明哪个服务占用1080端口:netstat –ano

      2)在任务管理器中找到PID(进程标识符)所对应的进程,停止掉(或者到服务中将该服务禁用掉)

      3)直接修改服务调用的端口:C:\Program Files (x86)\HP\LoadRunner\WebTours\conf中的httpd.conf文件

4、英文作业:HP学习资料,选择题(no)

作者:hlmmcw 发表于 2017/06/12 23:13:18 原文链接 https://blog.csdn.net/hlmmcw/article/details/73146035

阅读:180

 
[转]如何测试一个WEB的输入框?

将输入框分为文本输入框、数值型文本输入框两类。

 

01

文本输入框测试点

1、重复
2、空也就是不填写是否支持
2、长度:例如支持100字符,那需要测试100字符、101字符、100字符后输入一个汉字的情况,最大长度的显示是否正常
3、哪些是支持的字符类型:数字、字母、汉字、字符!@!#、特殊字符(tab回车键是否支持)
4、是否支持多行,保存是否成功,显示是否按输入的多行显示
5、字符中带有HTML标记对时,显示是否正常例如::<br><br> &nbsp;
6、字符串前后中带空格,前后的空格是否过滤,中间的空格是否保留
7、最大长度显示是否正常
8、全角半角的字母、数字
9、字符串中带JS标记对,比如<script>alert('aa');</script> 
10、复制功能是否可用
11、粘贴功能是否可用、粘贴超过最大长度的字符串怎么显示?
12、多浏览器的兼容性
13 、权限校验
 

02

数值型的输入框测试点

1、重复
2、空不填写是否支持
2、数值类型:
a: 小数支持的位数、不够支持的位数时,后面是否自动补零,超过支持的位数时,是四舍五入还是直接舍去
b: 整数 
3、0 是否支持、是否符合业务逻辑
4、负数是否支持
5、数值的范围:例如 -5<X<5
 a: 小数类型时:-5.0000-4.9999  0.0000 4.9999 5.0000
 b:整数类型时:-5-4 0 4 5
6、非数字类型是否支持输入
7、半角的数字、全角的数字
8、空格+数字
9、多浏览器的兼容性
10、权限校验

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值