持续集成自动化测试方法、装置、设备和介质与流程

本发明涉及软件测试领域,具体涉及一种持续集成自动化测试方法、装置、设备和介质。

背景技术：

目前的自动化测试中，测试工具的可移植性不高，如果测试工具或者机器出问题，不能马上恢复，当前版本有问题，也不能马上回滚到上一版没问题的状态。

在持续集成中，开发的代码提交、打包、部署等一系列已经可以自动完成，测试人员的回归测试工作也可以自主完成，但是开发部署完测试环境到测试人员的测试还没有实现很好的自动化衔接，开发人员提供完测试环境，需要测试人员手动触发测试工作的进行。

技术实现要素：

本发明实施例提供一种持续集成自动化测试方法、装置、设备和介质，以实现实现测试工具的版本可控，易于移植；和/或实现测试持续集成。

第一方面，本发明实施例提供了一种持续集成自动化测试方法，其包括：

接收开发代码；

根据所述开发代码部署测试环境，监测所述测试环境是否部署成功，如果成功，则触发在容器中执行与所述开发代码相对应的测试用例；

在所述测试用例执行完成后，接收由所述容器回写的测试结果。

第二方面，本发明实施例提供了一种持续集成自动化测试装置，其包括：

代码管理模块，用于接收开发代码；

任务执行模块，用于根据所述开发代码部署测试环境，监测所述测试环境是否部署成功，如果成功，则触发在容器中执行与所述开发代码相对应的测试用例；

所述代码管理模块，还用于在所述测试用例执行完成后，接收由所述容器回写的测试结果。

第三方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如第一方面所述的持续集成自动化测试方法。

第四方面，本发明实施例提供了一种计算机设备，其包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如第一方面所述的持续集成自动化测试方法。

上述技术方案具有如下有益效果：

本技术方案通过容器管理测试工具，提接口服务，使得测试工具版本可控，可移植，最终使得开发和测试自动衔接，在自动化测试领域和持续集成领域。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明的实施例的持续集成自动化测试方法的一种流程图；

图2是本发明的实施例的持续集成自动化测试方法的作为一个举例的流程图；

图3是本发明的实施例的持续集成自动化测试装置的功能框图；

图4是本发明的实施例的计算机设备的逻辑功能框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的实施例主要解决如下至少一个技术问题：

(1)实现测试工具的容器化，每一个版本的测试工具都是独立的，保证多个测试版本之间互不干扰，测试人员也可以很容易部署自己的测试工具，并在容器内执行测试用例，实现测试工具的版本可控，易于移植。

(2)实现开发和测试的自动衔接，当开发人员的测试环境部署好，可自动执行相应的测试用例，无需测试人员介入，实现真正的开发、测试持续集成。

以下对缩略语和关键技术术语进行定义：

gitlab：gitlab是一个用于仓库管理系统的开源项目，使用git作为代码管理工具，并在此基础上搭建起来的web服务。

gitlab-runner：gitlab提供了一套持续集成系统，gitlab-runner是用来执行这套系统中各个阶段的任务的工具。

容器：容器是轻量级的操作系统虚拟化，目前容器技术有很多种，本发明的实施例采用docker，但不限于此，它是一个开源的引擎，可以很轻松的创建一个容器。本实施例中该容器内有执行测试所必需的一些环境条件，和tomcat服务。

wetest：一种自动化执行所有测试用例的脚本工具，每次开发人员提供测试环境，测试人员都要手动执行脚本来回归所有测试用例。

持续集成：对于开发人员来说，就是持续的编译、测试、检查和部署源代码的过程。

图1是本发明的实施例的持续集成自动化测试方法的一种流程图。该方法的执行主体是持续集成系统gitlab，其包括：代码管理工具/模块git和任务执行工具gitlab-runner。如图1所示，包括如下步骤：

s110：接收开发代码。

在本实施例中，每个开发人员在开发需求前都会建立自己的分支，不同分支之间互不影响，在自己的分支开发完后，把开发代码提交到git的远程仓库，远端就有了开发人员的这个分支。

s120：根据所述开发代码部署测试环境，监测该测试环境是否部署成功，如果该测试环境部署成功，则触发在容器内执行与该开发代码相对应的测试用例。

在本步骤中，接收开发人员提交的开发代码，形成代码分支，根据该代码分支部署测试环境。具体地，可根据开发代码分支形成镜像文件，通过该镜像文件部署测试环境。或者，对该开发代码进行打包处理，形成打包文件，根据该打包文件部署测试环境。打包是部署测试环境前的一个流程，例如将工程代码打成war包。在本步骤中，作为一个示例，测试环境是开发人员给测试人员部署的，测试人员通过对这个测试环境发送请求，来测试开发的代码。在测试环境里包括需要测试人员测试的所有功能。部署测试环境的具体处理过程可以包括：将开发代码打包编译成后缀是.war的文件，然后把这个文件放到tomcat的webapps文件夹下，最后执行tomcat里的bin文件夹下的启动脚本。

在本步骤中，可通过如下方式来监测该测试环境是否部署成功：在测试环境部署过程中，周期性地向该测试环境发送请求，并接收返回码，根据该返回码监测该测试环境是否部署成功。作为一个示例，在测试环境部署过程中，每隔几秒种向测试环境发送一次请求，然后查看返回码，如果返回码是200表示启动成功。

具体地，测试用例是测试人员根据开发人员的需求功能编写的。作为一个示例，测试环境部署成功之后，先调用本实施例提供的服务接口，然后触发容器内的脚本，该脚本执行的时候，再拉取指定的某个分支(根据该开发代码确定的或对应的测试用例)的测试用例的代码。或者，当触发容器里的脚本执行的时候，会自动拉取最新的测试用例的代码。

在本步骤中，作为一个示例，该服务接口可以是在docker容器里部署的tomcat服务，该服务提供http接口。http接口是一种基于http服务的api，内部可实现某些功能，在本实施例中是用来触发测试的执行，这样不管是谁，只要能调用这个http接口就可以触发测试，而不需要再登陆到指定服务器上执行测试用例。该测试环境的ip和端口等信息需要做为参数传递给该服务接口，然后该服务接口根据接收到的这些参数来执行测试用例。任务执行工具gitlab-runner在检测到测试环境部署成功后，调用该服务接口来触发测试用例或测试任务的执行。把测试环境的ip和端口作为参数传递给服务接口，是因为服务接口会触发测试用例的执行，而执行测试用例需要用到这两个参数，通过这两个参数来对测试环境发送请求。

在本步骤中，作为一个示例，容器不需要接收开发代码，开发人员部署的测试环境就是用由开发代码部署的，也即测试环境里包含开发人员的代码，测试人员只需要通过测试用例代码，向该测试环境发送请求，然后校验请求的结果即可。

在一些实施例中，可以通过指定测试分支名称，执行对应测试人员的分支代码，来触发执行该测试用例。

可选地，该容器可以包括应用容器引擎docker，其优点在于：可以简化程序、节省开支、快速部署等。

可选地，通过任务执行工具gitlab-runner部署测试环境，监测该测试环境是否部署成功，以及触发执行测试用例。

作为一个示例，分支是代码管理工具git提供的便于开发人员共同开发同一项目又互不影响的一种技术，测试人员的分支代码指的是：测试人员在工程中创建的测试代码分支。

s130：在该测试用例执行完成后，接收由该容器回写的测试结果。

在本步骤中，该容器的服务接口调用一次回写接口，将测试结果通过该回写接口回写到代码管理工具gitlab上。这样可以方便开发人员和测试人员查看，该测试分支的开发人员根据该测试用例的结果判断该开发代码是否存在问题，如果存在，则该开发人员修改上述开发代码。

通过上述方法，可以实现测试工具的容器化，每一个版本的测试工具都是独立的，保证多个测试版本之间互不干扰，测试人员也可以很容易部署自己的测试工具，并在容器内执行测试用例，实现测试工具的版本可控，易于移植。而且，通过上述方法可以实现开发和测试的自动衔接，当开发人员的测试环境部署好，可自动执行相应的测试用例，无需测试人员介入，实现真正的开发、测试持续集成。

图2是本发明的实施例的方法的一种流程图。如图2所示，本发明的实施例是基于gitlab提供的gitlab-ci持续集成系统，当开发人员提交开发代码的时候就会触发gitlab-runner，gitlab-runner获取开发人员提交的分支代码，并且gitlab-runner开始执行配置文件指定的任务，其中最重要的两项任务是先根据开发人员提交的代码打包部署测试环境，监听或监测该测试环境是否部署成功，在测试环境部署成功后，再调用服务接口触发测试用例的执行。其中，打包是部署环境前的一个流程，将工程代码打成war包。

图2中的容器container就是wetest所在的容器，容器中包含测试用例执行过程中所需的一切条件，并且对外提供服务，只要调用该服务提供的服务接口(例如http接口)就可以执行容器中对应的测试用例。作为示例，在该容器中可以包括：日志文件、测试脚本、反向代理服务nginx、tomcat服务、操作系统。其中，操作系统不限于linux操作系统，可以是unix或者其它操作系统，具体看使用者需要。tomcat服务是用来提供服务接口的，nginx用于在有多个测试环境的时候做分发处理，测试脚本是用来执行测试用例的，日志文件用来记录测试用例的执行过程中的一些信息。

以下进行举例说明：

该测试技术已经在组内应用，减少了组内人员的时间成本，下面以执行前端用例为例来说明该技术的应用：

如果有开发人员在自己的mergerequest提交代码，就会根据代码分支做个镜像，部署测试环境，测试环境部署成功后git上会出现部署情况提示。mergerequest是指合并请求，即如果开发人员a想要将自己新添加的代码合并到公用的分支，需要先建一个mergerequest申请合并。

如果测试环境部署成功，接下来会调用本发明的实施例提供的服务接口，指定测试分支test_branch可以执行对应测试人员的分支，这为测试用例的执行提供了灵活性，避免了开发代码修改了原逻辑，而测试代码主分支上的逻辑还没有修改的弊端，因为这样将会导致不必要的用例失败，从而误导开发人员。

最后，测试用例执行完成后会把结果通过回写接口回写到gitlab上，该测试分支的开发人员可根据测试用例结果初步判断代码是否还存在问题，如果有，开发人员可以及时地修改代码，并重复以上流程。

以上为开发前端需求时执行测试用例的流程，除前端外，队列和rpc(remoteprocedurecall，远程过程)的测试用例执行均已接入并在组内应用。由于该方法的特点，前端上线前的预览测试步骤也已接入运维，预览起来之后会自动执行本发明实施例的测试用例，测试人员只需看最后结果即可。

本发明的实施例的技术方案具有如下优点：

由于采用了容器管理，测试工具有了很好的版本控制，并且变得可移植，使得测试工具灵活化。开发流程和测试流程的自动衔接，进一步实现持续集成，节省了测试人员回归测试的时间成本，促进开发和测试共同发现问题，解决问题。

图3是本发明的实施例的持续集成自动化测试装置200的功能框图。如图3所示，本发明的实施例还提供一种持续集成自动化测试装置200，其包括：

代码管理模块210，用于接收开发代码；

任务执行模块220，用于根据该开发代码部署测试环境，监测该测试环境是否部署成功，如果成功，则触发在容器中执行与该开发代码相对应的测试用例；

该代码管理模块210，还用于在该测试用例执行完成后，接收由该容器回写的测试结果。

在一些实施例中，任务执行模块220，具体可以用于：根据该开发代码形成镜像文件，通过该镜像文件部署测试环境；或者，对该开发代码进行打包处理，形成打包文件，根据该打包文件部署测试环境。

在一些实施例中，任务执行模块220，具体可以用于：在测试环境部署过程中，周期性地向该测试环境发送请求，并接收返回码，根据该返回码监测该测试环境是否部署成功；将该测试环境的ip和端口作为参数传递给该容器的服务接口，通过调用该容器的服务接口来触发在该容器中执行与该开发代码相对应的测试用例。

在一些实施例中，代码管理模块210，具体可以用于接收由该容器的回写接口回写的测试结果。

在一些实施例中，该容器包括应用容器引擎docker；该服务接口是在docker容器里部署的tomcat服务，该tomcat服务提供http接口。

作为一个示例，代码管理模块210可以为git，任务执行模块220可以是gitlab-runner。

需要说明的是，本发明实施例提供的持续集成自动化测试装置是应用上述持续集成自动化测试方法的装置，则上述持续集成自动化测试方法的所有实施例均适用于该装置，且均能达到相同或相似的有益效果。

本发明实施例还提供了一种电子设备，如图4所示，包括一个或多个处理器301、通信接口302、存储器303和通信总线304，其中，处理器301，通信接口302，存储器303通过通信总线304完成相互间的通信。

存储器303，用于存放计算机程序；

处理器301，用于执行存储器303上所存放的程序时，实现上述持续集成自动化测试方法的各步骤。

由于采用了容器管理，测试工具有了很好的版本控制，并且变得可移植，使得测试工具灵活化。开发流程和测试流程的自动衔接，进一步实现持续集成，节省了测试人员回归测试的时间成本，促进开发和测试共同发现问题，解决问题。

上述电子设备提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，ram)，也可以包括非易失性存储器(non-volatilememory，nvm)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessing，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质内存储有计算机程序，计算机程序被处理器执行时实现上述持续集成自动化测试方法的各步骤。

本发明实施例提供的计算机可读存储介质，由于采用了容器管理，测试工具有了很好的版本控制，并且变得可移植，使得测试工具灵活化。开发流程和测试流程的自动衔接，进一步实现持续集成，节省了测试人员回归测试的时间成本，促进开发和测试共同发现问题，解决问题。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备及可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。