使用Pabot并行运行RF案例

一、问题引入

在做接口自动化时随着案例增多,特别是流程类案例增多,特别是asp.net的webform类型的项目,再加上数据库校验也比较耗时,导致RF执行案例时间越来越长,就遇到这样一个问题,705个接口测试案例(案例包含流程类案例,一个流程类案例可能包含3、4个单个案例,单个案例又都包含登录),通过Jenkins在单机上要跑13小时30分钟,而且目前还不是整个项目所有的接口测试案例,案例个数还在继续增长,一个系统假如有3、4000个接口那如果按照这个速度可能得跑一两天,这是很可怕的。

二、解决方案

于是就是在想有没有方法能缩短运行时间呢?一是将大的项目分成几个子模块,测试案例也是分为几个子模块,这样可以做分布式测试,二是进行并行测试,在一台机子上开启多个进程进行测试,最好的方案是一、二的结合,在网上搜了下,没想到已经有开源的类库Pabot。Pabot通过开启多个进程以Suite为单位并行运行RF测试案例,而且对于进程之间资源共享问题也有锁机制。它也兼容RF命令行参数,这样在Jenkins中修改之前RF命令也很容易,只需加几个参数就可以了。

三、测试

这里新建了一个PabotDemo,包含3个Suite,每个Suite中还有3个Test,每个Test都是执行相同的步骤sleep 10s,暂停10s。如果在RF中运行9个Test,每个Test耗时10s,那就需要90s。下图为在RF中运行的测试结果。

如果使用Pabot,开启多个进程并行运行案例,那就会减少运行时间,这里分别2个进程和3个进程。

2个进程:pabot --processes 2 PabotDemo,这里原本要90s的案例耗时63s。

3个进程:pabot --processes 3 PabotDemo,这里原本要90s的案例耗时32s。

上面简单测试了使用Pabot开启多个进程并行执行RF案例,这里没有进程间的资源共享,所以没加锁,具体使用可以参考:https://github.com/mkorpela/pabot。使用Pabot开启2个进程还是在原来单个执行机运行上面提到的705个测试案例,耗时减少5个小时,通过率也有提升,运行时间下降到8小时30分。

四、进一步优化

在开启2个进程并行运行705个案例减少5小时的运行时间,如果再多开启几个进程还是有下降的空间,除了多开几个进程外,还可以对案例进行优化。我们应该都下载过文件,有的大文件几个G,有的只有几M,小的文件很快下载完了,大的文件可能才刚开始,影响下载时间的关键因素可能就是几个大的文件,为了达到并行下载的目的,可以将大文件分为几个小文件,这样并行下载效果更好。由于Pabot并行运行是以Suite为单位运行的,因为项目的案例结构有的Suite中案例个数100多个,有的只有几个,这样就导致案例少的Suite几个可能已经运行完了,案例多的Suite可能才刚开始,并不能发挥并行运行的最大效果,分布不均,所以需要对案例进行调整,将案例多的Suite进行拆分,这样也能开启多个进程,不然总共有3个Suite开启5个进程,那也没用,还是只有3个进程在运行,上面只是举了下载文件的例子,还有好多整体与部分的关系,有点类似木桶原理。

五、优缺点

这里只是使用Pabot进行的接口案例执行,对于UI测试案例可能会杀浏览器进程的,这里没测是否能用Pabot进行测试。

六、总结

上面优化案例结构也是为了并行执行案例进行的优化,其实还有地方进行优化,比如登录,目前每个案例在执行时都会先进行登录,算是多了一个get和post请求,特别是那种json的,可能就是先get、post进行登录,然后就只有post请求就结束的,如果能模拟人的操作,同一个用户只登录一次,那效率应该也会有所提高,案例少的话可能不明显,案例多的话应该就会明显些。

原文地址:https://www.cnblogs.com/5ishare/p/9495264.html

时间: 2024-10-09 10:35:44

使用Pabot并行运行RF案例的相关文章

.NET下的并行开发(案例代码)

以下主要是通过一个报表处理程序来说明并行开发的方式.对于数据冲突和共享,可以通过对象数组解决.设计到并行的核心代码已用红色标出.在并行程序的处理上,需要把原来串行的子公司变成一个一个类的对象,让所有的类对象一起并行运行就达到提高响应速率的目的了.并行设计中,主要的还是编程的思想,并行的语法,规则都是规划好的.好的工具就看你如何使用了. using System;using System.Data;using System.Configuration;using System.Collection

Oozie_03运行官方案例【20161116】

3.1官方的案例 (1)Oozie根目录下找到 oozie-examples.tar.gz (2)解压tar -zxvf oozie-examples.tar.gz  生成example文件夹 [[email protected] oozie-4.0.0-cdh5.3.6]$ tar -zxvf oozie-examples.tar.gz (3)拷贝(2)新生成的examples到HDFS的用户家目录下 [[email protected] hadoop-2.5.0-cdh5.3.6]$ bin

用Parallel.For()和Parallel.For<TLocal>()方法实现并行运行迭代

Parallel类是.NET 4中新增的抽象线程类.如果你开发用的是VS2008或更低版本,那么就直接关闭吧,下面两个示例用了匿名委托,如果不知道匿名委托的语法,那么先去简单了解一下,不然很难理解示例代码. Parallel.For()方法类似于C#的for循环语句,也是多次执行一个任务.使用Parallel.For()方法,可以并行运行迭代.迭代的顺序没有定义. 在For()方法中,前两个参数定义了循环的开头和结束.下面代码示例从0迭代到9.第三个参数是一个Action<int>委托.整数是

VS2012运行Cocos2d-xTest案例加载失败解决方案

编译cocos2d-x,一直提示加载失败 通过搜索,解决方案如下: 第一步,通过命令提示行工具进入VS安装目录下的%VS2012home%Common7\IDE 第二部,执行devenv.exe /setup /resetuserdata /resetsettings 第三步,重新加载sln文件 VS2012运行Cocos2d-xTest案例加载失败解决方案

Robotframework(3):使用pycharm编写和运行RF脚本

我们在使用Robotframework时,经常编写脚本的人或许会不习惯,不过没关系!我们在熟悉RF的语法后,可以使用编辑器来编写和运行.下面就通过使用最多的python编辑器pycharm来演示一下如何配置和运行RF的脚本. 1.下载pycharm 我们可以通过官网来下载软件:http://www.jetbrains.com/pycharm/ 当然,也可以通过百度云链接下载(三个版本任选一个即可):http://pan.baidu.com/s/1pL3EB39 安装后我们可以通过File-Ope

使用pycharm编写和运行RF脚本

使用pycharm编写和运行RF脚本 转至https://www.cnblogs.com/CCGGAAG/p/7800322.html 我们在使用Robotframework时,经常编写脚本的人或许会不习惯,不过没关系!我们在熟悉RF的语法后,可以使用编辑器来编写和运行.下面就通过使用最多的python编辑器pycharm来演示一下如何配置和运行RF的脚本. 1.下载pycharm 我们可以通过官网来下载软件:http://www.jetbrains.com/pycharm/ 当然,也可以通过百

Android环境配置及运行helloWord案例

  Android的环境搭建步骤,以及输出一个helloWorder 1:下载Android开发环境   及是: SDK adt-bundle-windows-x86_64-20140702 此时的版本是4.4的版本 ( 须知:开发环境的SDK版本多少的,那么你创建项目的时候,也要多少版本的要进行的匹配,否则会安装不了的,会报错的) ----------------------------------------------------------------------------------

高频运行脚本案例 $$

在执行定时任务脚本频率比较快,并不知道上一次的脚本是否真正执行完毕,但是业务要求同一个时刻只能有一个同样的脚本运行,此时就可以利用$$获取上次的运行的脚本进程号,当程序重新运行时候,根据所得进程号,清理掉上一次的进程,运行新的脚本命令,脚本如下: [email protected]:/shell# cat cmz.sh #!/bin/bash pidpath=/tmp/cmz.pid if [ -f "$pidpath" ];then     kill $(cat $pidpath)&

Optaplanner终于支持多线程并行运行 - Multithreaded incremental solving

Optaplanner 7.9.0.Final之前,启动引擎开始对一个Problem进行规划的时候,只能是单线程进行的.也就是说,当引擎对每一个possible solution进行分数计算的过程中,细化到每个步骤(Caculation),都只能排队在同一个线程中依次计算,不管你的问题是否存在并行计算的可能.很显示这种运算方式应用于一些可并行计划的场景下,是相当不利的.就算是一些在业务逻辑上无法实现并行运算的情况,若在引擎自行调用指定的算法进行寻优时,若可以将每个Step,甚至每个Move的运行