一种持续集成测试的方法以及装置与流程

本发明涉及软件开发技术领域，特别是涉及一种持续集成测试的方法以及装置。

背景技术：

随着以敏捷开发模式为特点的持续集成开发方式的发展进步，通过持续的相对频繁的集成来验证开发人员上传代码的语法和逻辑正确性的方式得到了广泛应用。

持续集成的流程一般包括check阶段和gate阶段，即先进行自动化代码审查，再进行项目的集成测试。对于一些项目来说，例如JavaWeb项目，自动化代码检查很难检测到项目的配置文件是否存在问题，例如spring的配置文件。一般地，项目文件即使不存在代码语法上的错误，但是若有配置文件有问题，可能会导致整个项目无法正常工作，甚至无法启动。

如何检测项目配置文件是否存在异常是本领域亟待解决的问题。

技术实现要素：

本发明的目的是提供一种持续集成测试的方法以及装置，目的在于解决现有技术中无法检测项目配置文是否存在异常的问题。

为解决上述技术问题，本发明提供一种持续集成测试的方法，该方法包括：

获取待测试项目文件，将所述待测试项目文件传输至容器服务器；

利用部署命令，部署所述待测试项目文件的测试环境，以使所述容器服务器启动所述测试环境，返回启动结果信息；

接收返回的所述启动结果信息，根据所述启动结果信息，判断所述测试环境是否正常启动；

若正常启动，得出所述待测试项目文件对应的配置文件正确的测试结果。

可选地，在所述若正常启动，得出所述待测试项目文件对应的配置文件正确的测试结果之后还包括：

将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查。

可选地，在所述将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查之后还包括：

对所述测试环境进行清除操作，清除所述测试环境。

可选地，所述利用部署命令，部署所述待测试项目文件的测试环境，以使所述容器服务器启动所述测试环境，返回启动结果信息包括：

利用所述部署命令，通过URL方式远程部署所述待测试项目文件，得到所述测试环境。

可选地，所述获取待测试项目文件，将所述待测试项目文件传输至容器服务器包括：

获取所述待测试项目文件；

当监听任务监听到所述待测试项目文件的上传时，生成与所述待测试项目文件相对应的任务ID；

根据所述任务ID，分配给所述待测试项目文件与所述任务ID一一对应的端口号；

检测所述端口号是否存在；

当所述端口号存在时，清除所述端口号，配置相应的配置文件以及端口号设置；

当所述端口号不存在时，配置相应的配置文件以及端口号设置；

通过预设传输命令，将所述待测试项目文件传输至容器服务器。

此外，本发明还提供了一种持续集成测试的装置，该装置包括：

获取传输模块，用于获取待测试项目文件，将所述待测试项目文件传输至容器服务器；

部署模块，用于利用部署命令，部署所述待测试项目文件的测试环境，以使所述容器服务器启动所述测试环境，返回启动结果信息；

判断模块，用于接收返回的所述启动结果信息，根据所述启动结果信息，判断所述测试环境是否正常启动；

测试结果模块，用于若正常启动，得出所述待测试项目文件对应的配置文件正确的测试结果。

可选地，还包括：

作为模块，用于将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查。

可选地，还包括：

清除模块，用于对所述测试环境进行清除操作，清除所述测试环境。

可选地，所述部署模块包括：

远程部署单元，用于利用所述部署命令，通过URL方式远程部署所述待测试项目文件，得到所述测试环境。

可选地，所述获取传输模块包括：

获取单元，用于获取所述待测试项目文件；

ID生成单元，用于当监听任务监听到所述待测试项目文件的上传时，生成与所述待测试项目文件相对应的任务ID；

端口号分配单元，用于根据所述任务ID，分配给所述待测试项目文件与所述任务ID一一对应的端口号；

检测单元，用于检测所述端口号是否存在；

清除配置单元，用于当所述端口号存在时，清除所述端口号，配置相应的配置文件以及端口号设置；

配置单元，用于当所述端口号不存在时，配置相应的配置文件以及端口号设置；

传输单元，用于通过预设传输命令，将所述待测试项目文件传输至容器服务器。

本发明所提供的一种持续集成测试的方法以及装置，通过获取待测试项目文件，将上述待测试项目文件传输至容器服务器；利用部署命令，部署上述待测试项目文件的测试环境，以使上述容器服务器启动上述测试环境，返回启动结果信息；接收返回的上述启动结果信息，根据上述启动结果信息，判断上述测试环境是否正常启动；若正常启动，得出上述待测试项目文件对应的配置文件正确的测试结果。将待测试项目文件部署指容器服务器，即部署相应的测试环境，再启动所部署的测试环境，判断测试环境是否正常启动，来判断待测试项目文件的配置文件是否存在异常，以实现对项目配置文件进行检测。可见，本申请可以检测项目配置文件是否存在异常。

附图说明

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

图1为本发明实施例所提供的持续集成测试方法的一种具体实施方式的流程示意图；

图2为本发明实施例所提供的持续集成测试装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例所提供的持续集成测试方法可以应用于各种不同的项目测试，下文将以应用至Java Web项目场景下的持续集成流程进行介绍说明。显而易见地，本发明实施例提供的持续集成测试方法还可以应用于其它场景，在此不作限定。

请参见图1，图1为本发明实施例所提供的持续集成测试方法的一种具体实施方式的流程示意图，该方法包括以下步骤：

步骤101：获取待测试项目文件，将所述待测试项目文件传输至容器服务器；

需要说明的是，上述待测试项目文件可以具体表现为war文件，该war文件可以由开发人员将需要测试的项目进行打包得到。将项目打包成war文件后，开发人员可以在工作机上，利用上传工具(例如git工具)将该war文件上次至代码审查工具，以该代码审查工具获取到相应的待测试项目文件。代码审查工具为代码审查软件，例如gerrit软件。

代码审查软件接收到待测试项目文件后，可以将待测试项目文件通过一定的方式发送给容器服务器。上述容器服务器具体可以为Tomcat服务器，也可以为其它类型的容器服务器。

由于开发人员可能同时上传多个待测试项目文件，为了区分各个不同的待测试项目文件，使测试工作可以有序地进行，代码审查软件可以在接收到待测试项目文件时，为各个待测试项目文件分配唯一的任务ID，根据任务ID，生成唯一端口号，进而为每一个测试环境分配一个唯一的端口号。

作为一种具体实施方式，上述获取待测试项目文件，将所述待测试项目文件传输至容器服务器的过程可以具体为：获取所述待测试项目文件；当监听任务监听到所述待测试项目文件的上传时，生成与所述待测试项目文件相对应的任务ID；根据所述任务ID，分配给所述待测试项目文件与所述任务ID一一对应的端口号；检测所述端口号是否存在；当所述端口号存在时，清除所述端口号，配置相应的配置文件以及端口号设置；当所述端口号不存在时，配置相应的配置文件以及端口号设置；通过预设传输命令，将所述待测试项目文件传输至容器服务器。

需要说明的是，当代码审查工具接收到待测试项目文件后，监听任务(例如zuul监听任务)会根据所监听到的上传事件，触发相应的命令(例如Jenkins)，执行check任务，以生成相应的任务ID。

上述任务ID即task-id是按照一定的规律变化的，task-id的变化规律可以根据待测试项目文件的上传次数决定，例如，项目开发至今已经上传了1233次代码，那么下一次代码上传时，所生产的task-id则为1234，即task-id是逐一递加的。当然，task-id的变化规律还可以为其它，在此不作限定。

上述的端口号可以是指测试主机上所部署的测试环境的端口号。根据task-id，可以生成与task-id一一对应的端口号，一般地，可以取task-id的相应位数的数字和其它的数字组成端口号，例如，当task-id为1234时，可以取后两位34和80组成端口号，则1234对应的端口号为8034。

可以理解的是，取task-id的后两位和相应数字组成端口号时，会产生出现重复端口号的情况，即每100次待测试项目文件上传，就会产生端口号冲突，例如，task-id为1234和task-id为1334的端口号均为8034。为了避免上述情况，可以考虑取task-id的后3位组成端口号，当然，也可以使用其它的端口号命名方式，在此不作限定。

为待测试项目文件分配对应端口号后，可能该端口号已经存在，故可以先远程到测试主机，检测当前所分配的端口好是否已经存在。如果存在，则可以将该端口好进行清除。

当检测到所分配的端口号不存在时，可以进行配置文件的配置，以避免其它环境的端口冲突。其过程可以具体为：从文件服务器下载Tomcat压缩包，并解压到特定目录，例如/opt/tomcat34；然后进行配置文件的修改，设置定义相应的接口，例如，HTTP/port＝8034，shutdown/port＝8134，AJP/port＝8234。

设置好对应的端口号后，可以利用一定的指令传输待测试项目文件至容器服务器。上述预设传输命令可以具体表现为Jenkins命令，当然，还可以为不同于Jenkins命令的传输命令。

步骤102：利用部署命令，部署所述待测试项目文件的测试环境，以使所述容器服务器启动所述测试环境，返回启动结果信息；

需要说明的是，上述部署命令可以具体表现为curl命令，即可以curl命令，通过Tomcat manager text的路径将待测试项目文件部署至容器服务器。

将待测试项目文件部署至容器服务器，即创建一个新的context，建立一个测试环境。测试环境建立后，容器服务器可以启动该测试环境，然后将该测试环境是否正常启动的信息，同一定的方式返回给代码审查软件。

将测试文件部署至容器服务器的方式有很多，其可以远程部署，也可以利用其它的部署方式。

作为一种具体实施方式，远程部署的过程可以具体为：利用所述部署命令，通过URL方式远程部署所述待测试项目文件，得到所述测试环境。

具体地，当容器服务器具体为Tomcat服务器时，可以利用Tomcat的webapp下名为mannager的context，即利用URL的方式远程部署待测试文件，例如，通过http://<username>:<password>@<host>:<port>/manager/text/deploy？path＝/test&war＝file:<path-of-war>，以将war文件部署至http://<host>:<port>/test。

当然，还可以利用其它的部署方式进行部署，例如，将war文件直接复制到相应的目录下，在此不作限定。

步骤103：接收返回的所述启动结果信息，根据所述启动结果信息，判断所述测试环境是否正常启动；

具体地，可以通过curl命令返回的部署信息进行分析，以确定测试环境是否正常启动。当正常启动时，则判断当前的待测试项目文件的配置文件没有存在异常，即待测试项目文件通过自动化代码审查阶段；当启动异常时，则判断当前的待测试项目文件的配置文件存在异常。

可以理解的是，当待测试项目文件的配置文件出现异常时，开发人员可以对待测试项目文件修改。开发人员可以不断地向代码审查工具上传新的补丁(patch)，对测试项目文件进行修改完善。

需要说明的是，代码审查工具新的patch后，会触发新的check任务，进而覆盖之前的测试环境，部署新的测试环境。而所有的patch均共享一个task-id。

步骤104：若正常启动，得出所述待测试项目文件对应的配置文件正确的测试结果。

可以理解的是，测试环境的正常启动后，可以利用部署的测试环境进行后续测试流程，即开发人员可以进入到该测试环境，进行人工代码审查。

作为一种具体实施方式，在测试环境正常启动后还可以包括：将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查。

在进行了人工代码审查阶段后，可以进入到gate阶段，则当前测试环境处于空置状态，故可以关闭当前测试环境。

作为一种具体实施方式，在上述将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查之后还可以包括：对所述测试环境进行清除操作，清除所述测试环境。

可以理解的是，在待测试项目文件通过自动化代码检查后，可以将测试环境关闭，即删除相应的容器服务器的目录，例如，删除Tomcat目录(/opt/tomcat34)。而在进入gate阶段后，在将测试环境进行清除即可。

需要说明的是，各个测试环境直觉可以共享数据库以及缓存等资源。而当容器服务器为Tomcat服务器时，多个Tomcat之间可以通过不同的端口号进行区分，保证了环境的隔离性，相较于Docker服务器的Dec0ps方式，其更加的轻量。

本发明实施例所提供的持续集成测试的方法，通过获取待测试项目文件，将上述待测试项目文件传输至容器服务器；利用部署命令，部署上述待测试项目文件的测试环境，以使上述容器服务器启动上述测试环境，返回启动结果信息；接收返回的上述启动结果信息，根据上述启动结果信息，判断上述测试环境是否正常启动；若正常启动，得出上述待测试项目文件对应的配置文件正确的测试结果。将待测试项目文件部署指容器服务器，即部署相应的测试环境，再启动所部署的测试环境，判断测试环境是否正常启动，来判断待测试项目文件的配置文件是否存在异常，以实现对项目配置文件进行检测。可见，该方法可以检测项目配置文件是否存在异常。

下面对本发明实施例提供的持续集成测试装置进行介绍，下文描述的持续集成测试装置与上文描述的持续集成测试方法可相互对应参照。

图2为本发明实施例所提供的持续集成测试装置的结构框图，参照图2持续集成测试装置可以包括：

获取传输模块201，用于获取待测试项目文件，将所述待测试项目文件传输至容器服务器；

部署模块202，用于利用部署命令，部署所述待测试项目文件的测试环境，以使所述容器服务器启动所述测试环境，返回启动结果信息；

判断模块203，用于接收返回的所述启动结果信息，根据所述启动结果信息，判断所述测试环境是否正常启动；

测试结果模块204，用于若正常启动，得出所述待测试项目文件对应的配置文件正确的测试结果。

可选地，还包括：

作为模块，用于将所述测试环境作为临时测试环境，以使测试人员进入所述临时测试环境进行人工代码审查。

可选地，还包括：

清除模块，用于对所述测试环境进行清除操作，清除所述测试环境。

可选地，所述部署模块包括：

远程部署单元，用于利用所述部署命令，通过URL方式远程部署所述待测试项目文件，得到所述测试环境。

可选地，所述获取传输模块包括：

获取单元，用于获取所述待测试项目文件；

ID生成单元，用于当监听任务监听到所述待测试项目文件的上传时，生成与所述待测试项目文件相对应的任务ID；

端口号分配单元，用于根据所述任务ID，分配给所述待测试项目文件与所述任务ID一一对应的端口号；

检测单元，用于检测所述端口号是否存在；

清除配置单元，用于当所述端口号存在时，清除所述端口号，配置相应的配置文件以及端口号设置；

配置单元，用于当所述端口号不存在时，配置相应的配置文件以及端口号设置；

传输单元，用于通过预设传输命令，将所述待测试项目文件传输至容器服务器。

本发明实施例所提供的持续集成测试的装置，通过将待测试项目文件部署指容器服务器，即部署相应的测试环境，再启动所部署的测试环境，判断测试环境是否正常启动，来判断待测试项目文件的配置文件是否存在异常，以实现对项目配置文件进行检测。可见，该装置可以检测项目配置文件是否存在异常。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本发明所提供的持续集成测试的方法以及装置进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。