CN108829399A - 一种应用的测试方法、测试装置、介质和计算设备 - Google Patents

Abstract

本发明的实施方式提供了一种应用的测试方法、测试装置、介质和计算设备。该方法包括：根据应用的开发代码构建容器引擎镜像，该容器引擎镜像包括该应用的运行环境；将该运行环境的配置参数设置为测试环境的配置参数；启动容器引擎镜像，在该测试环境中对该应用进行测试。通过设置容器引擎镜像中运行环境的配置参数，将该容器引擎镜像部署到测试环境中，该方法使得应用可以快速部署到多个测试环境中，显著地降低了测试过程的复杂度，提高了测试效率，解决了在多个环境中进行问题定位和问题解决的难度大的问题。

Description

一种应用的测试方法、测试装置、介质和计算设备

技术领域

本发明的实施方式涉及软件技术领域，更具体地，本发明的实施方式涉及一种应用的测试方法、测试装置、介质和计算设备。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

为了使得发布后的应用软件可以在多个环境中稳定运行，所有的应用软件发布之前都需要进行测试，应用软件只有在多个环境中经过充分测试之后才会被发布上线。目前，应用软件测试包括服务部署、提测等流程。提测是指在迭代过程中，开发人员完成开发代码并针对该开发代码自测完毕后，将开发代码提交给测试人员进行测试的过程。通常，提测过程中会采用专用的测试环境部署开发代码进行验证。

目前，常见的应用软件的部署方式可以为：在构建机器上基于提交测试的源代码构建war包，将该war包远程发布到目标机器(例如tomcat服务器)的指定目录并启动服务。由于多个环境的设计架构、配置参数、以及加载有的java/tomcat的版本等都存在较大差别，因此应用软件在每个环境中进行测试之前都需要重新进行服务部署，这使得应用软件的测试过程繁琐，测试效率低，并且可能会导致多个环境中进行测试和预发布时难以进行问题定位和问题解决。

通常采用基于代码部署的多分支管理的模式进行提测，提测方式可以如图1所示，图1为现有技术中2个迭代测试周期内的提测流程示意图，其中多个分支包括20170525、20170608、20170622、hotfix、yanlian、online等。具体如下：在20170608分支中完成应用软件的源代码编写和冒烟自测之后，基于20170608分支的源代码将该应用软件部署到目标机器一中进行测试。若测试期间存在漏洞修复(bug fix)，则需要重新基于修复后的源代码将该应用软件更新部署到目标机器中进行测试。在20170608分支测试完毕之后，需要将20170608分支的源代码合入到yanlian分支，并基于合入后的代码将该应用软件更新部署到演练环境下的目标机器二中进行测试。在yanlian分支测试完毕之后，将yanlian分支需要的源代码合入到online分支，并基于合入后的代码将该应用软件更新部署到线上环境下的目标机器中进行回归，回归完毕后本次迭代上线完成。在上线之后若出现热补丁(hotfix)则需要从yanlian分支中拉取出hotfix分支，并在该hotfix分支上修改源代码(或编写新代码)，待修改完成后重新部署到演练环境下的目标机器中进行回归，回归通过后将hotfix分支的源代码合入到online分支中重新上线。从上述过程可知，一次迭代上线过程中需要进行多次服务部署以及多次合并不同分支的代码，导致代码管理成本高、冲突解决的时间成本大、测试效率低。此外，由于多次合并不同分支的代码，还可能会造成代码版本混乱，不利于追溯提测过程中存在问题的代码版本，使得问题定位、问题解决难度大。

综上，现有的应用软件测试的技术方案存在测试过程繁琐、测试效率低、代码管理成本高、冲突解决的时间成本大以及在多个环境中进行问题定位和问题解决的难度大等问题。

发明内容

但是，出于一次迭代上线过程中需要进行多次服务部署以及多次合并不同分支的代码的原因，现有的应用软件测试的技术方案存在测试过程繁琐、测试效率低、代码管理成本高、冲突解决的时间成本大以及在多个环境中进行问题定位和问题解决的难度大等问题。

为此，非常需要一种改进的应用软件测试的技术方案，以使应用可以快速便捷地部署到多个测试环境中。

在本上下文中，本发明的实施方式期望提供一种应用的测试方法、介质、装置和计算设备。

在本发明实施方式的第一方面中，提供了一种应用的测试方法，包括：根据应用的开发代码构建容器引擎镜像，容器引擎镜像包括应用的运行环境；将运行环境的配置参数设置为测试环境的配置参数；启动容器引擎镜像，在测试环境中对应用进行测试。

在本发明的一个实施例中，根据应用的开发代码构建应用的容器引擎镜像，包括：将应用的开发代码构建成预设格式的数据包；在运行有容器引擎的构建设备中，采用容器引擎将数据包构建成容器引擎镜像，并将容器引擎镜像存储到镜像仓库中。

在本发明的另一实施例中，将运行环境的配置参数设置为测试环境的配置参数，包括：将容器引擎镜像从镜像仓库提取至运行有测试环境的目标设备；在目标设备的构建模板中，将运行环境的配置参数设置为测试环境的配置参数，配置参数包括端口配置参数和/或配置文件路径。

在本发明的又一个实施例中，该镜像仓库包括开发代码构建出的数据包，和/或，应用的运行环境。

在本发明的再一个实施例中，根据应用的开发代码构建容器引擎镜像之前，还包括：当构建应用的容器引擎镜像为初次时，在构建设备中加载以下之一或组合：容器引擎、获取所述开发代码的环境。

在本发明的一个实施例中，启动容器引擎镜像在测试环境中对应用进行测试之后，还包括：若需要修改该应用，则修改该应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像。

在本发明的一个实施例中，启动容器引擎镜像在测试环境中对应用进行测试之后，还包括：获取应用的测试结果；将测试结果作为对应的容器引擎镜像的标签，标签用于指示容器引擎镜像对应版本的开发代码的质量。

在本发明的一个实施例中，获取应用的测试结果，包括：在测试表单中获取应用的测试结果。将测试结果作为对应的容器引擎镜像的标签，包括：触发回调函数，将在测试表单中获取的测试结果写入容器引擎镜像的元数据中；基于元数据和容器引擎镜像，构建携带有元数据的容器引擎镜像。

在本发明的一个实施例中，启动容器引擎镜像在测试环境中对应用进行测试之后，还包括：在第一代码分支上测试应用的过程中，若应用待修改，则在第二代码分支上修改应用的开发代码；将修改后的应用的开发代码拉取至第一代码分支，并基于修改后的应用的开发代码，在第一代码分支上构建应用的容器引擎镜像。

在本发明实施方式的第二方面中，提供了一种测试装置，包括：

构建单元，用于根据应用的开发代码构建容器引擎镜像，容器引擎镜像包括应用的运行环境；

设置单元，用于将运行环境的配置参数设置为测试环境的配置参数；

测试单元，用于启动容器引擎镜像，在测试环境中对应用进行测试。

在本发明的一个实施例中，构建单元具体用于：将应用的开发代码构建成预设格式的数据包；在运行有容器引擎的构建设备中，采用容器引擎将数据包构建成容器引擎镜像，并将容器引擎镜像存储到镜像仓库中。

在本发明的一个实施例中，设置单元具体用于：将容器引擎镜像从镜像仓库提取至运行有测试环境的目标设备；在目标设备的构建模板中，将运行环境的配置参数设置为测试环境的配置参数，配置参数包括端口配置参数和/或配置文件路径。

在本发明的一个实施例中，镜像仓库包括开发代码构建出的数据包，和/或，应用的运行环境。

在本发明的一个实施例中，构建单元还用于：在根据应用的开发代码构建容器引擎镜像之前，当构建应用的容器引擎镜像为初次时，在构建设备中加载以下之一或组合：容器引擎、获取所述开发代码的环境。

在本发明的一个实施例中，该测试装置还包括修改单元，修改单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，若需要修改该应用，则修改该应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像。

在本发明的一个实施例中，该测试装置还包括评估单元，评估单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，获取应用的测试结果；将测试结果作为对应的容器引擎镜像的标签，标签用于指示容器引擎镜像对应版本的开发代码的质量。

在本发明的一个实施例中，评估单元在获取应用的测试结果时，具体用于：在测试表单中获取应用的测试结果。评估单元在将测试结果作为对应的容器引擎镜像的标签时，具体用于：触发回调函数，将在测试表单中获取的测试结果写入容器引擎镜像的元数据中；基于元数据和容器引擎镜像，构建携带有元数据的容器引擎镜像。

在本发明的一个实施例中，还包括在线修改单元，在线修改单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，在第一代码分支上测试应用的过程中，若应用待修改，则在第二代码分支上修改应用的开发代码；将修改后的应用的开发代码拉取至第一代码分支，并基于修改后的应用的开发代码，在第一代码分支上构建应用的容器引擎镜像。

在本发明实施方式的第三方面中，提供了一种介质，该介质存储有计算机可执行指令，计算机可执行指令用于使计算机执行第一方面任一实施例的方法。。

在本发明实施方式的第四方面中，提供了一种计算设备，包括：处理器、存储器以及收发机；

存储器，用于存储处理器执行的程序；

处理器，用于根据存储器存储的程序，执行第一方面任一实施例的方法；

收发机，用于在处理器的控制下接收或发送数据。

根据本发明实施方式提供的技术方案，通过设置容器引擎镜像中运行环境的配置参数，将该容器引擎镜像部署到测试环境中，使得应用可以快速部署到多个测试环境中，简化了应用部署到多个测试环境中的过程，从而显著地降低了测试过程的复杂度，并且降低了代码管理成本和冲突解决的时间成本，解决了在多个环境中进行问题定位和问题解决的难度大的问题。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

图1示意性地示出了现有技术中的多分支管理模式提测的流程示意图；

图2示意性地示出了本发明实施例涉及的一种应用的测试方法的流程示意图；

图3A示意性地示出了本发明实施例涉及的一种应用的容器引擎镜像的构建方法和部署方法的流程示意图；

图3B示意性地示出了本发明实施例涉及的另一种应用的容器引擎镜像的构建方法和部署方法的流程示意图；

图4示意性地示出了本发明实施例涉及的又一种应用的测试方法的流程示意图；

图5示意性地示出了本发明实施例涉及的一种质量评价方法的流程示意图；

图6示意性地示出了本发明实施例涉及的一种容器引擎镜像的标签；

图7示意性地示出了本发明实施例涉及的另一种质量评价方法的流程示意图；

图8示意性地示出了本发明实施例涉及的一种应用的测试装置的结构示意图；

图9示意性地示出了本发明实施例涉及的一种介质的结构示意图；

图10示意性地示出了本发明实施例涉及的一种计算设备的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种应用的测试方法、介质、装置和计算设备。

在本文中，需要理解的是，所涉及的几个概念的含义分别为：

容器引擎(Docker)，是一个用于构建、发布和运行应用的开源平台，其主要是为开发者和系统管理员设计的，例如由dotCloud公司开源的应用容器引擎。以Docker为代表的容器即服务(Containers as a Service，CaaS)技术正在成为云计算的新形式。

容器引擎镜像(Image)，包括一个可运行的系统，该系统是由操作系统、基础组件以及应用等部分组成，例如该系统可以是一个linux系统。应用的开发代码构建出的数据包以及该应用所在的运行环境可以保存为镜像文件(例如容器引擎镜像)。

容器(container)，是容器引擎镜像的执行实例，在容器中可以对应用进行启动、关闭、删除等操作，同一设备上多个容器之间是互相隔离的。此外，容器也可以理解为在Docker中用于承载应用的数据和运行环境的基本单位。容器封装有整个应用运行时的环境，容器还可以理解为容器引擎中用于对资源进行分割和调度的基本单位。容器具有轻量级、快速部署和管理简单的特点，因此通过容器引擎服务创建的容器可以更为简单、高效地在运行该容器引擎服务的设备中构建和发布应用。

镜像仓库，主要用于存储例如容器引擎镜像等镜像文件的数据、存储路径、传输时间以及传输数据量等信息。镜像仓库包括应用的开发代码构建出的数据包和/或应用的运行环境。

提测，是指在开发迭代过程中将已完成初步自测的开发代码提交并进行测试的过程。通常，会将提测的开发代码部署在专用的测试环境中进行测试验证。

质量评价，是在测试完成后对被测应用的质量给出的评价。该质量评价可以是例如质量较好，可以上线，质量较差，存在遗留问题，存在重大风险，不建议上线等。通常质量评价会存储在jira单或邮件中。

迭代测试周期，也即迭代周期，是一个应用从开发到上线发布所需的时间周期。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

发明概述

本发明人发现，目前应用软件的测试方案存在测试过程繁琐、测试效率低、代码管理成本高、冲突解决的时间成本大以及在多个环境中进行问题定位和问题解决的难度大等问题，因此目前应用软件的测试方案均不能较好地实现应用的测试。

针对上述问题，本发明提供了一种应用的测试方法、测试装置、介质和计算设备。该方法包括：根据应用的开发代码构建容器引擎镜像，该容器引擎镜像包括该应用的运行环境；将该运行环境的配置参数设置为测试环境的配置参数；启动容器引擎镜像，在该测试环境中对该应用进行测试。本发明的方法通过设置容器引擎镜像中运行环境的配置参数，将该容器引擎镜像部署到测试环境中，使得应用可以快速部署到多个测试环境中，从而显著地降低了测试过程的复杂度，提高了测试效率，解决了在多个环境中进行问题定位和问题解决的难度大的问题。

在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。

应用场景总览

本发明实施例可以应用于多个环境下进行应用测试的场景。本发明实施例涉及的运行环境和测试环境，可以是例如安卓、IOS、Lunix、windows等环境中的任意一种。

示例性方法

下面参考图2来描述根据本发明示例性实施方式的用于应用的测试方法。需要注意的是，上述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。

本发明实施例提供了一种应用的测试方法，如图2所示，该方法包括：

S201、根据应用的开发代码构建容器引擎镜像，该容器引擎镜像包括应用的运行环境；

S202、将运行环境的配置参数设置为测试环境的配置参数；

S203、启动容器引擎镜像，在测试环境中对应用进行测试。

该方法通过设置容器引擎镜像中运行环境的配置参数，将该容器引擎镜像部署到测试环境中，使得应用可以快速部署到多个测试环境中，简化了应用部署到多个测试环境中的过程，从而显著地降低了测试过程的复杂度，并且降低了代码管理成本和冲突解决的时间成本，解决了在多个环境中进行问题定位和问题解决的难度大的问题。

下面对该方法的各个步骤进行详细说明。

S201中，根据应用的开发代码构建应用的容器引擎镜像的具体实现方式包括如下步骤：

步骤一：将应用的开发代码构建成预设格式的数据包。该应用的开发代码是采用开发工具所支持的语言写出来的源文件，开发代码可以表示为一组由字符、符号、信号码元等离散信息组成的体系。该数据包的预设格式包括但不限于二进制格式、tomcat war以及其他容器引擎可读取的数据格式。二进制格式的数据包可以是例如由mvn格式的数据或者git格式的数据构建成的。

步骤二：在运行有容器引擎的构建设备中，采用容器引擎将数据包构建成容器引擎镜像，并将容器引擎镜像存储到镜像仓库中。

其中，镜像仓库包括但不限于开发代码构建出的数据包和应用的运行环境，构建设备可以是例如运行有容器引擎的服务器。

可选的，应用的容器引擎镜像可以包括但不限于指定仓库的容器引擎镜像和/或模块的容器引擎镜像。指定仓库的容器引擎镜像是通过将指定仓库保存为镜像文件得到的，该指定仓库可以用于指示容器引擎镜像的路径信息，从而通过该路径信息指定的路径获取到该路径信息对应的容器引擎镜像。模块的容器引擎镜像是通过将模块保存为镜像文件得到的，该模块主要用于表示由应用服务拆分成的微服务，也即组成该应用的服务功能模块，例如该模块可以是用于为用户提供注册功能的服务功能模块，也可以是用于为用户提供登录功能的服务功能模块。可选的，模块的容器引擎镜像可以是独立于应用对应的容器引擎镜像，单独存在的容器引擎镜像。

以应用的容器引擎镜像包括指定仓库的容器引擎镜像和模块的容器引擎镜像为例，步骤二中可以采用容器引擎将数据包构建成指定仓库的容器引擎镜像以及一个或多个模块的容器引擎镜像，并将该指定仓库的容器引擎镜像以及这一个或多个模块的容器引擎镜像传送至镜像仓库进行存储。

除了运行有容器引擎的构建设备，上述执行步骤一和步骤二的设备也可以是具有容器引擎镜像构建功能的其他构建设备，此处并不限定。

需要说明的是，构建该应用的容器引擎镜像的实现方式还有多种，除了采用上述步骤一和步骤二来构建该应用的容器引擎镜像之外，还可以采用其他方式构建该应用的容器引擎镜像，此处并不限定。例如，可以使用docker file的方式构建该应用的容器引擎镜像，具体步骤为：编写docker file文件，使用docker build命令来根据docker file文件构建该应用的容器引擎镜像。

在S201之前，若为初次构建应用的容器引擎镜像，则在构建设备中加载容器引擎和/或获取开发代码的环境。获取开发代码的环境可以是例如具有拉取git仓库源代码的功能的git环境。

S202中将运行环境的配置参数设置为测试环境的配置参数的具体实现方式包括如下步骤：

步骤三：将容器引擎镜像从镜像仓库提取至运行有测试环境的目标设备。

其中，目标设备的数量可以为一个或多个，该目标设备可以是例如运行有测试环境的服务器，测试环境可以是例如安卓、IOS、windows、lunix等。

步骤四：在目标设备的构建模板中，将运行环境的配置参数设置为测试环境的配置参数，该配置参数包括端口配置参数和/或配置文件路径。例如，端口配置参数和配置文件路径可以是目标设备的pod模板内的端口配置参数和配置文件路径(path)。

可选的，在S202之前，若为初次部署应用的容器引擎镜像，则可以在目标设备中加载用于加载容器引擎镜像的环境，例如docker deamon环境、kubelet环境等。dockerdeamon环境还用于启动容器引擎镜像，kubelet环境还用于控制后台运行状态。

需要说明的是，目标设备与构建设备可以是相同设备，也可以是不同设备，此处并不限定。

举例说明一

图3A为初次构建和部署应用的容器引擎镜像的流程图，以图3A为例对S201至S202进行说明。如图3A所示，为了便于后续构建容器引擎镜像，在步骤一之前构建设备加载容器引擎、mvn环境、git环境等。步骤一中，先获取应用的开发代码(git pull code)，采用mvn对该应用的开发代码进行打包得到预设格式的数据包(mvn package)。步骤二中，将预设格式的数据包构建为应用的容器引擎镜像(docker build)，然后将该应用的容器引擎镜像存储到镜像仓库中(docker push)，该镜像仓库的路径信息为hub.c.163.com/repo/img.tag。为了便于后续以容器化的方式部署和启动应用的容器引擎镜像，在步骤三之前在目标设备中加载docker deamon环境和kubelet环境。步骤三中，该目标设备通过该镜像仓库的路径信息(hub.c.163.com/repo/img.tag)，将该镜像仓库中存储的容器引擎镜像加载到该目标设备中。步骤四中，配置目标设备的pod模板，将运行环境的端口配置参数(port)、配置文件路径(path)、安装配置文件(config，conf)等配置参数设置为测试环境的端口配置参数、配置文件路径、安装配置文件等配置参数。安装配置文件可用于存储硬件驱动程序的安装配置信息。最后，在测试环境中启动该应用的容器引擎镜像(container run)，并准备拉起该应用的服务(service ready)，从而以便S203中在该测试环境中启动容器引擎镜像。

举例说明二

图3B为非初次构建和部署应用的容器引擎镜像的流程示意图，以图3B为例对S201至S202进行说明。图3B所示的步骤一至步骤三均与图3A示出的步骤一至步骤三类似，可参见上文中图3A示出的步骤一至步骤三的相关描述，此处不再赘述。步骤四中，更新目标设备的pod模板，将运行环境的端口配置参数、配置文件路径、安装配置文件等配置参数，修改为测试环境的端口配置参数、配置文件路径、安装配置文件等配置参数。最后，等待应用的容器引擎镜像在该测试环境中重新拉起，并在该测试环境中将该应用的服务更新成对应最新版本的开发代码的服务，从而以便S203中在该测试环境中启动容器引擎镜像。

S203中通过启动部署到测试环境中的容器引擎镜像，使得该容器引擎镜像中的应用可以在该测试环境中进行测试。

可选的，在S203之后，若对应用进行需要修改，则修改该应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像，以便后续可以采用重新构建的较为稳定的容器引擎镜像来进行测试、发布等操作，简化了修改后的开发代码重新部署到目标机器中的过程，进一步提供高了应用的测试效率，缩短了应用的测试时间。例如，在S203之后若测试期间该应用存在漏洞修复(bug fix)，则修改该应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像(image for release)来进行测试、发布。

可选的，在S203之后，在第一代码分支上结束应用的测试过程之后，若该应用的开发代码还需要进行修改，则在第二代码分支上修改应用的开发代码，然后将修改后的应用的开发代码拉取至第一代码分支，并基于修改后的应用的开发代码在第一代码分支上构建应用的容器引擎镜像。通过这一方法，简化了该应用的开发代码的修改过程，避免了同一分支中多个代码版本混乱的情况，从而降低了代码管理成本和冲突解决的时间成本，进一步提供高了应用的测试效率，缩短了应用的测试时间。

举例说明三

以图4示出的两个迭代测试周期内应用测试的示意图为例，说明本发明提供的应用的测试方法进行说明。

第一个迭代测试周期中，该应用的开发代码经过多个环境下的测试后，使用develop分支将经过测试后的该应用的开发代码构建为该应用的用于发布的容器引擎镜像(image for release)，并将该image for release存储到镜像仓库中。

第二个迭代测试周期中的具体步骤如下：

S401：在该image for release对应的开发代码的基础上，继续使用develop分支对该应用进行开发，在该应用开发完成后对该应用的开发代码进行自测。

S402：使用develop分支将自测完成后的开发代码构建得到该应用的用于测试的容器引擎镜像(image for test)，并将该image for test存储到镜像仓库中。

S403：在加载持续集成(continuous integration，CI)环境的设备中提取镜像仓库内存储的该image for test。

CI环境是一种测试人员专用的测试环境，CI环境支持应用的自动化构建(包括应用的自动编译、自动发布以及自动测试)，通过应用的自动化构件使得测试人员可以在更短的时间内发现该应用存在的问题，从而缩短应用的测试周期，提高应用的测试效率。

S404：在加载CI环境的设备的pod模板中，将该image for test的端口配置参数和配置文件路径，分别设置为CI环境的端口配置参数和配置文件路径，以便将image fortest部署到CI环境中进行该应用的功能测试(function test)。其中，pod模板存储有CI环境的配置参数，CI环境的配置参数包括但不限于端口配置参数、配置文件路径、镜像文件路径、线上(online)字段。

通过这一步骤，简化了部署image for test的过程，提高了image for test的部署效率，缩短了image for test的部署时间。

S405：判断该应用在功能测试的过程中是否存在修改。若该应用在功能测试的过程中存在修改，则执行步骤S406；若该应用在功能测试的过程中未修改，则执行步骤S407。

S406：使用develop分支将修改后的开发代码构建得到该应用的用于发布的容器引擎镜像(image for release)，并将该image for release存储到镜像仓库中。

S407：将该应用的容器引擎镜像依次部署到演练环境和线上(online)环境中进行更新、回归等操作，第二个迭代测试周期结束。

需要说明的是，S407中在演练环境和线上环境中部署容器引擎镜像的方法与S403和S404类似，S407中的具体方法可参见S403和S404的相关描述，此处不再赘述。

如图4所示，在S407之后，若在发布过程中该应用出现问题，或需要紧急更新上线该应用的新版本，则使用hotfix分支重新开发或修改该应用的开发代码，然后使用develop分支拉取重新开发或修改后的该应用的开发代码，并将拉取的该应用的开发代码构建为容器引擎镜像(image for hotfix)，再次执行S407。

多次提测之后会构建出多个容器引擎镜像，这多个容器引擎镜像对应多个版本的应用的质量存在差异，这多个版本的应用的开发代码的质量也存在差异，为了便于后续目标设备可以根据应用和/或开发代码的质量来提取容器引擎镜像，在S203之后，还可以在容器引擎镜像中评价该容器引擎镜像对应版本的应用和/或开发代码的质量。

图5示出了一种质量评价方法，该质量评价方法用于对容器引擎镜像对应版本的应用以及该应用的开发代码的质量进行评价，该质量评价方法包括如下步骤：

S501：获取应用的测试结果。

可选的，可以在测试表单中获取应用的测试结果，该测试表单可以是例如jira表单，该应用的测试结果可以是例如jira表单中的质量评价参数。

S502：将测试结果作为对应的容器引擎镜像的标签，该标签可以用于指示容器引擎镜像对应版本的开发代码的质量。

可选的，S502中可以先触发回调函数，将在测试表单中获取的测试结果写入容器引擎镜像的元数据中，例如该元数据可以是如图6所示的标签；然后再基于元数据和容器引擎镜像来构建携带有元数据的容器引擎镜像。例如，回调函数可以是webhook-jenkins-trigger函数，该webhook-jenkins-trigger函数可以用于指示jira表单回调jenkins job，从而实现jira表单中该应用的质量评价参数的传输。

通过上述S501和S502，可以根据携带有标签的容器引擎镜像较为快速地确定该容器引擎镜像对应版本的开发代码的质量，从而较为快速地追溯提测过程中存在问题的代码版本，降低了问题定位和问题解决的难度。

举例说明四

图7为评价容器引擎镜像对应版本的开发代码的质量的流程示意图。如图7所示，在采用容器引擎镜像提测并部署到测试环境中进行测试之后，可以由测试人员给出该容器引擎镜像的测试结果，并将该容器引擎镜像的测试结果存储到jira表单。该容器引擎镜像的测试结果可以是例如质量良好、可以发布、通过测试、存在遗留问题、重大风险或者不建议上线等。在该容器引擎镜像的测试结果存储到jira表单之后，将jira表单中的测试结果获取到jenkins任务中，具体的实现方式可以是：通过jira表单的webhook事件触发回调函数对jenkins任务进行关联；然后触发jenkins job的运行，将测试结果写入到元数据中，具体的实现方式可以是：将jira表单中的测试结果传输至jenkins job，触发jenkins job将测试结果写入到元数据中，再通过buildimage_after_test.sh函数远程触发容器引擎镜像的构建，从而生成携带有元数据的容器引擎镜像。若该容器引擎镜像的测试结果为质量良好、可以发布或者测试通过，则将该容器引擎镜像部署到线上环境中，以便在线上环境中发布该容器引擎镜像对应版本的应用。若该容器引擎镜像的测试结果为存在遗留问题、重大风险或者不建议上线，则暂时不将该容器引擎镜像部署到线上环境中，以便开发人员后续修改或更新该容器引擎镜像对应版本的开发代码，解决该版本开发代码存在的技术问题。通过这一技术方案，可以快速获取该容器引擎镜像的测试结果，有利于追溯提测过程中存在问题的代码版本，降低了问题定位、问题解决的难度，进一步提高了应用的测试效率。

需要说明的是，除了上述列举的测试结果之外，该容器引擎镜像的测试结果还包括其他测试结果，例如需要更新、待修复遗留问题等，此处并不限定。

根据本发明实施方式提供的一种应用的测试方法，通过设置容器引擎镜像中运行环境的配置参数，将该容器引擎镜像部署到测试环境中，使得应用可以快速部署到多个测试环境中，简化了应用部署到多个测试环境中的过程，从而显著地降低了测试过程的复杂度，并且降低了代码管理成本和冲突解决的时间成本，解决了在多个环境中进行问题定位和问题解决的难度大的问题。

示例性装置

在介绍了本发明示例性实施方式的方法之后，接下来，介绍本发明提供了示例性实施的装置。

参考图8，本发明提供了一种装置进行说明，该测试装置可以实现图2对应的对本发明示例性实施方式中的方法。参阅图8所示，该装置包括：构建单元、设置单元和测试单元，其中，

构建单元，用于根据应用的开发代码构建容器引擎镜像，容器引擎镜像包括应用的运行环境；

设置单元，用于将运行环境的配置参数设置为测试环境的配置参数；

测试单元，用于启动容器引擎镜像，在测试环境中对应用进行测试。

可选的，构建单元具体用于：将应用的开发代码构建成预设格式的数据包；在运行有容器引擎的构建设备中，采用容器引擎将数据包构建成容器引擎镜像，并将容器引擎镜像存储到镜像仓库中。

可选的，设置单元具体用于：将容器引擎镜像从镜像仓库提取至运行有测试环境的目标设备；在目标设备的构建模板中，将运行环境的配置参数设置为测试环境的配置参数，配置参数包括端口配置参数和/或配置文件路径。

可选的，镜像仓库包括开发代码构建出的数据包，和/或，应用的运行环境。

可选的，构建单元还用于：在根据应用的开发代码构建容器引擎镜像之前，当构建应用的容器引擎镜像为初次时，在构建设备中加载以下之一或组合：容器引擎、获取所述开发代码的环境。

可选的，该测试装置还包括修改单元，修改单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，若需要修改该应用，则修改该应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像。

可选的，该测试装置还包括评估单元，评估单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，获取应用的测试结果；将测试结果作为对应的容器引擎镜像的标签，标签用于指示容器引擎镜像对应版本的开发代码的质量。

可选的，评估单元在获取应用的测试结果时，具体用于：在测试表单中获取应用的测试结果。评估单元在将测试结果作为对应的容器引擎镜像的标签时，具体用于：触发回调函数，将在测试表单中获取的测试结果写入容器引擎镜像的元数据中；基于元数据和容器引擎镜像，构建携带有元数据的容器引擎镜像。

可选的，该测试装置还包括在线修改单元，该在线修改单元用于：在测试单元启动容器引擎镜像在测试环境中对应用进行测试之后，在第一代码分支上测试应用的过程中，若应用待修改，则在第二代码分支上修改应用的开发代码；将修改后的应用的开发代码拉取至第一代码分支，并基于修改后的应用的开发代码，在第一代码分支上构建应用的容器引擎镜像。

示例性介质

在介绍了本发明示例性实施方式的方法和装置之后，接下来，参考图9，本发明提供了一种示例性介质，该介质存储有计算机可执行指令，该计算机可执行指令可用于使所述计算机执行图2对应的本发明示例性实施方式中任一项所述的方法。

示例性计算设备

在介绍了本发明示例性实施方式的方法、介质和装置之后，接下来，参考图10，介绍本发明提供的一种示例性计算设备，该设备包括处理器、存储器以及收发机，其中该存储器，用于存储处理器执行的程序；该处理器，用于根据该存储器存储的程序，执行图2对应的本发明示例性实施方式中任一项所述的方法；该收发机，用于在该处理器的控制下接收或发送数据。

应当注意，尽管在上文详细描述中提及了应用的测试装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种应用的测试方法，包括：

根据应用的开发代码构建容器引擎镜像，所述容器引擎镜像包括所述应用的运行环境；

将所述运行环境的配置参数设置为测试环境的配置参数；

启动所述容器引擎镜像，在所述测试环境中对所述应用进行测试。

2.如权利要求1所述的方法，其特征在于，所述根据应用的开发代码构建所述应用的容器引擎镜像，包括：

将所述应用的开发代码构建成预设格式的数据包；

在运行有容器引擎的构建设备中，采用所述容器引擎将所述数据包构建成所述容器引擎镜像，并将所述容器引擎镜像存储到镜像仓库中。

3.如权利要求2所述的方法，其特征在于，所述将所述运行环境的配置参数设置为测试环境的配置参数，包括：

将所述容器引擎镜像从所述镜像仓库提取至运行有所述测试环境的目标设备；

在所述目标设备的构建模板中，将所述运行环境的配置参数设置为所述测试环境的配置参数，所述配置参数包括端口配置参数和/或配置文件路径。

4.如权利要求2或3所述的方法，其特征在于，所述镜像仓库包括所述开发代码构建出的数据包，和/或，所述应用的运行环境。

5.如权利要求2所述的方法，其特征在于，所述根据应用的开发代码构建容器引擎镜像之前，还包括：

当构建所述应用的容器引擎镜像为初次时，在所述构建设备中加载以下之一或组合：所述容器引擎、获取所述开发代码的环境。

6.如权利要求1所述的方法，其特征在于，所述启动所述容器引擎镜像在所述测试环境中对所述应用进行测试之后，还包括：

若需要修改所述应用，则修改所述应用的开发代码，并基于修改后的开发代码重新构建成用于发布的容器引擎镜像。

7.如权利要求1所述的方法，其特征在于，所述启动所述容器引擎镜像在所述测试环境中对所述应用进行测试之后，还包括：

获取所述应用的测试结果；

将所述测试结果作为对应的所述容器引擎镜像的标签，所述标签用于指示所述容器引擎镜像对应版本的开发代码的质量。

8.一种测试装置，包括：

构建单元，用于根据应用的开发代码构建容器引擎镜像，所述容器引擎镜像包括所述应用的运行环境；

设置单元，用于将所述运行环境的配置参数设置为测试环境的配置参数；

测试单元，用于启动所述容器引擎镜像，在所述测试环境中对所述应用进行测试。

9.一种计算设备，其特征在于，包括处理器、存储器以及收发机；

所述存储器，用于存储所述处理器执行的程序；

所述处理器，用于根据所述存储器存储的程序，执行权利要求1至7任一项所述的方法；

所述收发机，用于在所述处理器的控制下接收或发送数据。

10.一种介质，其特征在于，所述介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行权利要求1至7任一项所述的方法。