CN109960643B - 一种代码测试方法和装置 - Google Patents

Abstract

本发明实施例涉及容器技术领域，尤其涉及一种代码测试方法和装置，用于实现研发环境和测试环境互不干扰，提高代码开发效率。从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；根据待测试代码，构建用于执行测试任务的流水线；对流水线进行测试环境的部署，并在测试环境中测试待测试代码；在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。如此，需求分支上的代码研发环境和流水线上的代码测试环境互不干扰，可以加快代码迭代速度，进而提高代码开发效率。

Description

一种代码测试方法和装置

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种代码测试方法和装置。

背景技术

软件研发通常会涉及源代码开发、编译、测试、发布上线等环节，其中，代码测试环节需要测试人员根据源代码的特点进行部署测试环境。

现有技术中软件研发完成时进行的代码测试，涉及到频繁的部署测试环境。比如，在一个项目研发过程中，不同的研发人员对该项目的不同需求功能进行研发，在每个需求功能研发完成之后，需要测试人员手动部署测试环境进行集成测试，使得研发完成部署测试过程耗费时间过长。因此，现有技术中的代码测试方法容易出现研发和测试过程相互干扰，开发效率低。

因此，亟需一种代码测试方法，实现研发环境和测试环境互不干扰，统一规范部署测试环境的过程，提高代码开发效率。

发明内容

本发明实施例提供一种代码测试方法和装置，用以实现研发环境和测试环境互不干扰，统一规范部署测试环境的过程，提高代码开发效率。

本发明实施例提供一种代码测试方法，包括：从目标项目的需求分支获取待测试代码；其中，所述需求分支是根据待开发需求从所述目标项目的集成发布分支创建的；根据所述待测试代码，构建用于执行测试任务的流水线；对所述流水线进行测试环境的部署，并在所述测试环境中测试所述待测试代码；在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中。

可选的，在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中，包括：若所述待测试代码为从需求子分支获取的，则：在所述待测试代码测试通过后，将所述待测试代码并入所述需求子分支所属的需求分支的合并代码中；根据所述需求分支的合并代码，在所述需求分支的流水线上进行测试；在测试通过后，将所述需求分支的合并代码并入所述集成发布分支的代码中。

可选的，所述根据所述待测试代码，构建用于执行测试流程任务的流水线，包括：若所述需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：根据该版本的待测试代码，构建用于执行测试任务的流水线。

可选的，所述对所述流水线进行测试环境的部署，包括：通过代码构建机器构建所述待测试代码对应的docker镜像；在目标机器构建docker容器；在所述目标机器部署所述待测试代码对应的docker镜像；将所述docker镜像在所述docker容器中启动，从而完成对所述流水线进行测试环境的部署。

可选的，所述通过代码构建机器构建所述待测试代码对应的docker镜像，包括：根据部署过程规约和配置文件规约，通过所述代码构建机器将所述待测试代码进行编译打包，生成组件包；所述部署过程规约和所述配置文件规约为根据所述目标项目预先设定的；根据所述组件包和部署脚本，构建所述docker镜像。

本发明实施例提供一种代码测试装置，包括：获取单元，用于从目标项目的需求分支获取待测试代码；其中，所述需求分支是根据待开发需求从所述目标项目的集成发布分支创建的；构建单元，用于根据所述待测试代码，构建用于执行测试任务的流水线；对所述流水线进行测试环境的部署；测试单元，用于在所述测试环境中测试所述待测试代码；集成单元，用于在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中。

可选的，所述集成单元，用于：若所述待测试代码为从需求子分支获取的，则：在所述待测试代码测试通过后，将所述待测试代码并入所述需求子分支所属的需求分支的合并代码中；在通过所述测试单元测试通过后，将所述需求分支的合并代码并入所述集成发布分支的代码中；所述测试单元，用于根据所述需求分支的合并代码，在所述需求分支的流水线上进行测试。

可选的，所述构建单元，用于：若所述需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：根据该版本的待测试代码，构建用于执行测试任务的流水线。

可选的，所述构建单元，用于：通过代码构建机器构建所述待测试代码对应的docker镜像；在目标机器构建docker容器；在所述目标机器部署所述待测试代码对应的docker镜像；将所述docker镜像在所述docker容器中启动，从而完成对所述流水线进行测试环境的部署。

可选的，所述构建单元，用于：根据部署过程规约和配置文件规约，通过所述代码构建机器将所述待测试代码进行编译打包，生成组件包；所述部署过程规约和所述配置文件规约为根据所述目标项目预先设定的；根据所述组件包和部署脚本，构建所述docker镜像。

本发明实施例中，从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；根据待测试代码，构建用于执行测试任务的流水线；对流水线进行测试环境的部署，并在测试环境中测试待测试代码；在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。如此，需求分支和用于执行测试任务的流水线之间互不干扰，也就是说，需求分支上的代码研发环境和流水线上的代码测试环境互不干扰，可以加快代码迭代速度，进而提高代码开发效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍。

图1为本发明实施例提供的一种基于GIT的代码管理系统示意图；

图2为本发明实施例提供的一种代码测试方法流程示意图；

图3为本发明实施例提供的一种流水线功能需求示意图；

图4为本发明实施例提供的一种代码测试装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例中，代码研发完成之后，提交至版本管理工具中的版本库，本发明实施例基于分布式版本控制系统GIT的各个功能分支进行代码迭代研发，并在进行代码迭代研发之前对各个功能分支的作用进行规约。下面基于GIT的代码管理系统以及代码迭代研发过程进行介绍。

图1示例性示出了本发明实施例提供的一种基于GIT的代码管理系统示意图。基于GIT的代码管理系统主要包括主分支(master)、集成发布分支(develop)、需求分支(feature)等。如图1所示，基于GIT的代码管理系统主要包括主分支(master)、集成发布分支(develop)、需求分支(feature-1-demand)、需求分支(feature-2-demand)，其中，每个需求分支对应一个待开发需求，如果一个待开发需求分为多个功能需求进行研发，此时可以从需求分支克隆出需求子分支进行研发。如图1所示，基于GIT的代码管理系统还包括从feature-1-demand分支克隆出的feature-1-demand-dev1分支、feature-1-demand-dev2分支和feature-1-demand-dev3分支，以及从feature-2-demand分支克隆出的feature-2-demand-dev4分支。

本发明实施例中，一个需求子分支上的代码研发完成并测试之后，合并入该需求子分支所属的需求分支；比如，如图1中的feature-1-demand-dev1分支上的代码研发完成并测试之后合并入feature-1-demand分支；再比如，如图1中的feature-2-demand-dev4分支上的代码研发完成并测试之后合并入feature-2-demand分支。可选的，一个需求分支在代码研发完成并测试之后，合并入集成发布分支；比如，feature-1-demand分支或feature-2-demand分支上的代码研发完成并测试之后，合并入develop分支。

为了制定一个流水线模式的研发过程，在进行代码研发之前，先规约GIT中各分支的作用。

主分支(master)上的代码保持和线上最新版本一致，该master分支的作用为：在线上出现bug时，从master分支克隆出一个修复(hotfix)分支进行线上bug修复。

集成发布分支(develop)不允许直接提交代码，必须通过pull request方式合入其他分支。develop分支代码必须保持随时可发布状态；举个例子，例如，在develop分支上规划了两个待开发需求，分别创建了feature-1-demand分支和feature-2-demand分支。其中，feature-1-demand分支进行集成测试且测试通过，创建pull request将feature-1-demand分支合入develop分支；而feature-2-demand分支未进行集成测试或者集成测试未通过，则feature-2-demand分支不能合入到develop分支。在具体实施例中，是否将需求分支合入develop分支由版本发布规划人员进行判断。

需求分支，也可称为集成开发分支(feature)，此分支根据可用于独立发布的需求，规划成一个分支。此分支从develop分支中稳定版本克隆出来，在功能研发完成后，需要独立进行集成部署测试。

可选的，上述基于GIT的代码管理系统还包括修复分支(hotfix)和版本标记(tag)。其中，hotfix分支主要用于修复线上bug，也可以用于修复develop分支发布过程的bug。tag标记用于记录每个版本的标记，如图1中master分支上的版本0.1、版本0.2、版本0.3和版本0.4等。

下面对代码研发过程中的代码测试方法进行介绍。

图2示例性示出了本发明实施例提供的一种代码测试方法流程示意图。如图2所示，该方法包括以下步骤：

步骤201：从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；

步骤202：根据待测试代码，构建用于执行测试任务的流水线；

步骤203：对流水线进行测试环境的部署，并在测试环境中测试待测试代码；

步骤204：在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。

本发明实施例中，从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；根据待测试代码，构建用于执行测试任务的流水线；对流水线进行测试环境的部署，并在测试环境中测试待测试代码；在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。如此，需求分支和用于执行测试任务的流水线之间互不干扰，也就是说，需求分支上的代码研发环境和流水线上的代码测试环境互不干扰，可以加快代码迭代速度，进而提高代码开发效率。

基于步骤202，针对每个需求分支来说，在该需求分支上的代码研发完成之后需要进行集成测试时，构建一条流水线。该流水线用于对需求分支上的待测试代码执行测试任务。

本发明实施例中，测试任务主要包括代码检出、代码构建、代码静态检查、单元测试、部署测试环境、手工测试六个阶段。其中，代码检出主要包括在开始执行测试任务时，从版本管理工具中将待测试代码检出至流水线构建机器。代码构建主要包括根据各代码语言类型和代码构建任务的对应关系，执行待测试代码的语言类型对应的代码构建任务。代码静态检查主要包括根据配置的静态检查命令，对待测试代码进行静态检查。单元测试主要包括对待测试代码进行单元测试，并向流水线返回实时日志。部署测试环境主要包括根据部署过程规约、配置文件规约、待测试代码，进行编译打包并部署。手工测试主要包括在部署成功后，对所迭代研发的功能进行测试验证。在流水线执行上述测试任务过程中，在获取目标项目的待测试代码之后，配置用于上述测试任务中各个阶段任务的相关脚本和环境参数，并提供相应的修改功能。

本发明实施例中，需求分支包括两种类型，第一种类型为直接从集成发布分支克隆出的需求分支，比如从develop分支克隆出feature-1-demand分支和feature-2-demand分支；第二种类型为从需求分支克隆出的需求子分支；比如从feature-1-demand分支克隆出feature-1-demand-dev1、feature-1-demand-dev2和feature-1-demand-dev3子分支。针对上述两种类型的需求分支，在任一个需求分支完成代码研发时都需要构建一条流水线，每个需求分支对应一条流水线，如此，每个需求分支上的代码研发互不影响，各个需求分支上待开发需求对应的功能可独立发布测试和上线。

一种可选的实施方式中，在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中，包括：若待测试代码为从需求子分支上获取的，则：在待测试代码测试通过后，将待测试代码并入需求子分支所属的需求分支的合并代码中；根据需求分支的合并代码，在需求分支的流水线上进行测试；在测试通过后，将需求分支的合并代码并入集成发布分支的代码中。

举个例子，根据规约的各个分支的作用，从develop分支克隆出feature-1-demand分支，将feature-1-demand分支作为对接测试人员的一个集成测试分支。根据需求功能优先级，需求发布规划分配给N个研发人员，以feature-1-demand分支为基础，克隆出N个需求子分支进行独立研发，比如分配给3个人进行研发，那么从需求分支feature-1-demand克隆出三个需求子分支，分别为feature-1-demand-dev1分支、feature-1-demand-dev2分支和feature-1-demand-dev3分支，每个研发人员将自己的需求子分支的相关功能需求研发完毕后，对自己的需求子分支的待测试代码分别构建流水线进行测试，待检验各项功能正常后，可将自己的需求子分支上测试通过后的待测试代码合并至feature-1-demand分支，得到合并代码。如果研发人员自己的需求子分支上的待测试代码测试不通过，则该需求子分支待测试代码不与feature-1-demand分支上的代码合并。之后，针对feature-1-demand分支上的合并代码构建流水线进行测试，并将测试通过后的合并代码并入develop分支的代码中。如此，研发过程和测试过程互不干扰，而且采用流水线模式的研发测试流程，针对每个待开发需求以及待开发需求对应的每个功能，先分别进行测试后再合并入develop分支，可以提高代码开发效率。

本发明实施例中，根据待测试代码构建用于执行测试流程任务的流水线包括多种实现方式。一种可选的实现方式为：为每个需求分支构建一条流水线。另一种可选的实现方式为：若需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：根据该版本的待测试代码，构建用于执行测试任务的流水线。

举个例子，以部署项目A中的需求1、需求2、需求3至不同的服务器为例，项目A中的代码按照GIT分支规约方式进行规约，根据需求1、需求2和需求3，分别以develop分支为基线克隆出三个需求分支(feature-1-demand、feature-2-demand、feature-3-demand)，分别在上述三个需求分支上进行需求功能研发。在管理平台进行新增项目A，配置项目A的服务地址，选取需要执行的流程任务，并根据流程任务配置规约对流程任务中的各阶段任务进行相关执行命令、环境参数和以及脚本等进行配置。

图3示例性示出了本发明实施例提供的一种流水线功能需求示意图。针对三个需求分支，分别创建如图3所示的三个测试流程，分别为：feature-1-demand分支对应的测试流程1、feature-2-demand分支对应的测试流程2、feature-3-demand分支对应的测试流程3。

若需要在一个需求分支里面迭代功能，也就是说，在一个需求分支的需求功能分为多个小功能分阶段进行研发，针对每个小功能研发成功后的待测试代码构建流水线(pipeline)。以图3中的feature-1-demand分支对应的测试流程1为例。

当feature-1-demand分支上第一个小功能研发完成后，得到版本为1.0的待测试代码，当版本为1.0的待测试代码提交后，基于该版本为1.0的待测试代码构建一个流水线(pipeline)进行集成测试，最终部署出一个测试环境(基于代码版本1.0)用于检验研发成果。

当feature-1-demand分支上第二个小功能研发完成后，得到版本为1.1的待测试代码，此时基于该版本为1.1的待测试代码，构建一个流水线(pipeline)进行集成测试，最终部署出一个测试环境(基于代码版本1.1)用于检验研发成果。继续研发新功能得到版本为1.2的待测试代码，构建一个基于版本为1.2的流水线(pipeline)。

基于与feature-1-demand分支对应的测试流程1相同构思，如图3所示的feature-2-demand分支对应的测试流程2中，当研发出一个小功能之后得到版本为2.0的待测试代码，基于版本为2.0的待测试代码构建流水线；当又研发出一个小功能之后得到版本为2.1的待测试代码，基于版本为2.1的待测试代码构建流水线；当又研发出一个小功能之后得到版本为2.2的待测试代码，基于版本为2.2的待测试代码构建流水线。如图3所示的feature-3-demand分支对应的测试流程3中，依次构建基于版本为3.0、3.1和3.2的待测试代码的流水线。

依次类推，在同一测试流程(或者同一个需求分支)里面可根据每次代码迭代进行重新构建待测试代码的流水线pipeline，直到需求功能全部检验通过为止，即可对外提供服务。如此，针对同一个需求分支上的每个功能研发对应的代码都可以部署一套测试环境，研发人员和测试人员的环境互不干扰。针对不同的需求分支代码也可独立构建出不同的测试环境，相互不影响，实现流水线模式的研发流程。

下面针对流水线模式测试的操作过程进行介绍。

第一步，新增目标项目，并配置好测试任务后进入查看目标项目。

第二步，为目标项目的需求分支新增测试流程，填写该测试流程对应的分支名称、测试流程名称及备注后保存，完成一个测试流程的新增。

第三步，在该新增的测试流程中，点击构建按钮，根据当前需求分支上的待测试代码的版本标识(commitId)可构建一个流水线pipeline执行测试任务，最终部署成功一个用于测试待测试代码的测试环境。若该需求分支上有提交新版本代码，再次点击构建按钮，可构建出另一个新的流水线pipeline执行测试任务，最终部署成功另一个用于测试新版本代码的测试环境。

第四步，针对不同的测试流程，可重复执行第二步和第三步，完成测试环境的部署。

通过上述操作，可实现各测试流程之间并行独立地部署测试，以检验各个测试流程的研发结果，使得各个需求分支之间测试互不干扰。进一步，在同一个测试流程中也可以根据不同的流水线pipeline进行独立部署，以检验各个版本的研发结果，实现同一需求分支上的不同版本代码之间测试互不干扰。

由于一个项目在研发过程中，不同的研发人员对该项目的不同需求功能进行研发，在每个需求功能研发完成之后，需要测试人员手动部署测试环境进行集成测试，测试部署测试过程耗费的时间过长，且每套软件要成功部署测试环境需要占用很多的机器资源。为了解决测试人员手动部署测试环境过程工作量大、后续开发效率低的问题，本发明实施例提供一种可选的实施方式，对流水线进行测试环境的部署包括：通过代码构建机器构建待测试代码对应的docker镜像；在目标机器构建docker容器；在目标机器部署待测试代码对应的docker镜像；将docker镜像在docker容器中启动，从而完成对流水线进行测试环境的部署。如此，由于docker容器存在快速启停、容灾能力强、事故现场保留等特性，可以提高代码测试的效率；而且一台机器可部署多个docker容器，进而可以提高服务器资源的利用率，节约成本，可以减少服务器的维护量。

本发明实施例中，通过代码构建机器构建待测试代码对应的docker镜像，包括：根据部署过程规约和配置文件规约，通过代码构建机器将待测试代码进行编译打包，生成组件包；部署过程规约和配置文件规约为根据目标项目预先设定的；根据组件包和部署脚本，构建docker镜像。如此，通过制定的部署过程规约和配置文件规约，可以实现一次规约，永久使用，而且部署过程可见，便于排查问题、分析代码质量。

可选的，在构建docker镜像之前，根据不同类型的项目，制定不同类型的项目对应的部署过程规约。其中，部署过程规约包括容器类型、容器部署路径、默认配置信息、版本信息和仓库信息等。

以下提供一个以javaweb项目为例的部署过程规约，主要包括以下内容：采用tomcat容器部署，其部署路径为/usr/local/tomcat/webapps/xxx.war；tomcat容器端口、运行变量等的默认规约配置；依赖的jdk版本规约，统一维护升级；第三方jar仓库，统一维护升级；主备节点部署方案脚本规约；其他部署过程需要规约的信息。

可选的，配置文件规约主要包括以下内容：将目标项目中部署环境、横向扩展、硬代码等进行抽离，形成不同类型的配置文件，主要为：包括部署环境的配置文件、包括横向扩展的配置文件和包括硬代码的配置文件，在项目中新增一个文件夹对不同类型的配置文件进行分类管理。

通过上述实施例可以看出，从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；根据待测试代码，构建用于执行测试任务的流水线；对流水线进行测试环境的部署，并在测试环境中测试待测试代码；在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。如此，需求分支和用于执行测试任务的流水线之间互不干扰，也就是说，需求分支上的代码研发环境和流水线上的代码测试环境互不干扰，可以加快代码迭代速度，进而提高代码开发效率。

基于以上实施例以及相同构思，图4为本发明实施例提供的一种代码测试装置结构示意图，该代码测试装置可以实现如上图2中所示的任一项或任多项对应的方法中的步骤。该用于代码测试装置400可以包括获取单元401、构建单元402、测试单元403和集成单元404。

获取单元401，用于从目标项目的需求分支获取待测试代码；其中，所述需求分支是根据待开发需求从所述目标项目的集成发布分支创建的；

构建单元402，用于根据所述待测试代码，构建用于执行测试任务的流水线；对所述流水线进行测试环境的部署；

测试单元403，用于在所述测试环境测试所述待测试代码；

集成单元404，用于在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中。

本发明实施例中，从目标项目的需求分支获取待测试代码；其中，需求分支是根据待开发需求从目标项目的集成发布分支创建的；根据待测试代码，构建用于执行测试任务的流水线；对流水线进行测试环境的部署，并在测试环境中测试待测试代码；在待测试代码测试通过后，将待测试代码并入集成发布分支的代码中。如此，需求分支和用于执行测试任务的流水线之间互不干扰，也就是说，需求分支上的代码研发环境和流水线上的代码测试环境互不干扰，可以加快代码迭代速度，进而提高代码开发效率。

可选的，所述集成单元404，用于：若所述待测试代码为从所述需求子分支获取的，则：在所述待测试代码测试通过后，将所述待测试代码并入所述需求子分支所属的需求分支的合并代码中；在通过所述测试单元403测试通过后，将所述需求分支的合并代码并入所述集成发布分支的代码中；所述测试单元403，用于根据所述需求分支的合并代码，在所述需求分支的流水线上进行测试。

可选的，所述构建单元402，用于：若所述需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：根据该版本的待测试代码，构建用于执行测试任务的流水线。

可选的，所述构建单元402，用于：通过代码构建机器构建所述待测试代码对应的docker镜像；在目标机器构建docker容器；在所述目标机器部署所述待测试代码对应的docker镜像；将所述docker镜像在所述docker容器中启动，从而完成对所述流水线进行测试环境的部署。

可选的，所述构建单元402，用于：根据部署过程规约和配置文件规约，通过所述代码构建机器将所述待测试代码进行编译打包，生成组件包；所述部署过程规约和所述配置文件规约为根据所述目标项目预先设定的；根据所述组件包和部署脚本，构建所述docker镜像。

该代码测试装置所涉及的与本发明实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。

需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。在本发明的实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本领域内的技术人员应明白，本发明实施例可提供为方法、系统、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (8)

1.一种代码测试方法，其特征在于，包括：

从目标项目的需求分支获取待测试代码；其中，所述需求分支是根据待开发需求从所述目标项目的集成发布分支创建的；

根据所述待测试代码，构建用于执行测试任务的流水线；

根据部署过程规约和配置文件规约，通过代码构建机器将所述待测试代码进行编译打包，生成组件包；根据所述组件包和部署脚本，构建所述待测试代码对应的docker镜像，并在docker容器中启动所述docker镜像，完成对所述流水线进行测试环境的部署，并在所述测试环境中测试所述待测试代码；其中，所述部署过程规约和所述配置文件规约为根据所述目标项目预先设定的；所述部署过程规约包括所述docker镜像的部署过程需要规约的信息；所述配置文件规约用于将目标项目中的配置进行抽离，形成不同类型的配置文件以及对不同类型的配置文件进行分类管理；

在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中。

2.如权利要求1所述的方法，其特征在于，所述在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中，包括：

若所述待测试代码为从需求子分支获取的，则：

在所述待测试代码测试通过后，将所述待测试代码并入所述需求子分支所属的需求分支的合并代码中；

根据所述需求分支的合并代码，在所述需求分支的流水线上进行测试；

在测试通过后，将所述需求分支的合并代码并入所述集成发布分支的代码中。

3.如权利要求1所述的方法，其特征在于，所述根据所述待测试代码，构建用于执行测试流程任务的流水线，包括：

若所述需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：

根据该版本的待测试代码，构建用于执行测试任务的流水线。

4.如权利要求1所述的方法，其特征在于，所述在docker容器中启动所述docker镜像，完成对所述流水线进行测试环境的部署，包括：

在目标机器构建docker容器；

在所述目标机器部署所述待测试代码对应的docker镜像；

将所述docker镜像在所述docker容器中启动，从而完成对所述流水线进行测试环境的部署。

5.一种代码测试装置，其特征在于，包括：

获取单元，用于从目标项目的需求分支获取待测试代码；其中，所述需求分支是根据待开发需求从所述目标项目的集成发布分支创建的；

构建单元，用于根据所述待测试代码，构建用于执行测试任务的流水线；根据部署过程规约和配置文件规约，通过代码构建机器将所述待测试代码进行编译打包，生成组件包；根据所述组件包和部署脚本，构建所述待测试代码对应的docker镜像，并在docker容器中启动所述docker镜像，完成对所述流水线进行测试环境的部署；所述部署过程规约包括所述docker镜像的部署过程需要规约的信息；所述配置文件规约用于将目标项目中的配置进行抽离，形成不同类型的配置文件以及对不同类型的配置文件进行分类管理；

测试单元，用于在所述测试环境中测试所述待测试代码；其中，所述部署过程规约和所述配置文件规约为根据所述目标项目预先设定的；

集成单元，用于在所述待测试代码测试通过后，将所述待测试代码并入所述集成发布分支的代码中。

6.如权利要求5所述的装置，其特征在于，所述集成单元，用于：

若所述待测试代码为从需求子分支获取的，则：

在所述待测试代码测试通过后，将所述待测试代码并入所述需求子分支所属的需求分支的合并代码中；在通过所述测试单元测试通过后，将所述需求分支的合并代码并入所述集成发布分支的代码中；

所述测试单元，用于根据所述需求分支的合并代码，在所述需求分支的流水线上进行测试。

7.如权利要求5所述的装置，其特征在于，所述构建单元，用于：

若所述需求分支在开发周期内生成至少一个版本的待测试代码，则针对每个版本的待测试代码，执行：

根据该版本的待测试代码，构建用于执行测试任务的流水线。

8.如权利要求5所述的装置，其特征在于，所述构建单元，用于：

在目标机器构建docker容器；

在所述目标机器部署所述待测试代码对应的docker镜像；

将所述docker镜像在所述docker容器中启动，从而完成对所述流水线进行测试环境的部署。

Images