一种测试系统及方法与流程

本发明涉及软件测试
技术领域：
，特别是涉及一种测试系统及方法。
背景技术：
：随着软件技术的快速发展，各种各样的软件为人们的生活提供了便利。软件开发人员将所开发的软件提供给用户使用之前，一般会进行严格的测试，以发现软件中存在的问题，并消除所发现的问题。现有技术中，对软件进行测试时，可以采用docker技术对软件进行测试。其中，docker是一个开源的应用容器引擎。在采用docker技术对软件进行测试时，一般是利用docker所提供的容器对软件进行测试。然而，在测试过程中，docker所提供的各个容器所启动的软件待测试项目的运行环境的镜像文件只能是同一镜像文件，因此，利用docker所提供的容器对软件进行测试时，只能对软件的同一待测试项目的同一待测试分支进行测试。而对于一个软件而言，一般存在多个待测试项目，每一待测试项目又存在多个待测试分支，这样应用上述方式进行软件测试时，测试效率低下。技术实现要素：本发明实施例的目的在于提供一种测试系统及方法，能够提高对软件进行测试的效率。具体技术方案如下：一种测试系统，所述系统包括：代码管理节点、资源调度节点和至少两个dockercompose节点；所述资源调度节点，用于所述dockercompose节点的状态，并根据监测结果，获取包含可用dockercompose节点信息的可用节点列表；并向所述代码管理节点发送所述可用节点列表；所述代码管理节点，用于对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；并在接收到所述资源调度节点发送的所述可用节点列表时，按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所述可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点，并向所述目标dockercompose节点发送所生成的代码文件；所述dockercompose节点，用于在接收到所述代码管理节点发送的代码文件时，并将所接收的代码文件部署在指定的目录中；并获得待测试分支的运行环境的镜像文件，通过运行所获得的镜像文件生成测试容器，将所述指定的目录中部署的代码文件挂载在所述测试容器中，以对待测试分支进行测试。进一步地，所述获得待测试分支的运行环境的镜像文件，包括：从本地私有仓库中拉取待测试分支的运行环境的镜像文件。进一步地，所述资源调度节点，还用于控制每一所述目标dockercompose节点生成的各个测试容器的生命周期。进一步地，所述dockercompose节点为：安装有dockercompose服务和dockercompose管理器的宿主机；其中，所述dockercompose管理器中设置有与dockercompose通信的web接口，所述dockercompose管理器用于控制各个dockercompose节点上的dockercompose服务；所述dockercompose服务用于控制自身所在的dockercompose节点生成的各个测试容器的运行。进一步地，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中之后，所述dockercompose节点，还用于执行以下操作中的至少一种：监控自身生成的各个测试容器的资源消耗和运行状态；管理自身目录中部署的代码文件；管理测试过程中生成的日志文件；在对待测试分支完成测试后，释放测试过程中占用的资源；在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；提交待测试分支所依赖的dockerfile文件和docke-compse.yml文件到本地私有库中，其中，所述dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。进一步地，所述资源调度节点，还用于修改所述dockerfile文件；所述dockercompose节点，还用于根据修改后的所述dockerfile文件编辑测试容器。进一步地，所述dockercompose节点还包括：httpproxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。一种测试方法，所述方法包括：获得记录可用dockercompose节点信息的可用节点列表；按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点；对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；向所述目标dockercompose节点发送所生成的代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。进一步地，所述方法还包括：控制所述目标dockercompose节点在对所述待测试分支进行测试过程中生成的测试容器的生命周期。进一步地，所述方法还包括：对dockerfile文件进行修改，以使得所述目标dockercompose节点根据修改后的所述dockerfile文件编辑测试容器，其中，所述dockerfile文件为：用于生成所述镜像文件的配置文件。一种测试方法，应用于dockercompose节点，所述方法包括：获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件；将所接收的代码文件部署在指定的目录中；获得待测试分支的运行环境的镜像文件；运行所获得的镜像文件生成测试容器；将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试。进一步地，所述获得待测试分支的运行环境的镜像文件，包括：从本地私有仓库中拉取待测试分支的运行环境的镜像文件。进一步地，所述dockercompose节点为：安装有dockercompose服务和dockercompose管理器的宿主机；其中，所述dockercompose管理器中设置有与dockercompose通信的web接口，所述dockercompose管理器用于控制各个dockercompose节点上的dockercompose服务；所述dockercompose服务用于控制自身所在的dockercompose节点生成的各个测试容器的运行。进一步地，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试之后，还包括：执行以下操作中的至少一种：监控自身生成的各个测试容器的资源消耗和运行状态；管理自身目录中部署的代码文件；管理测试过程中生成的日志文件；在对待测试分支完成测试后，释放测试过程中占用的资源；在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；提交待测试分支所依赖的dockerfile文件和docke-compse.yml文件到本地私有库中，其中，所述dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。进一步地，所述方法还包括：获得修改后的所述dockerfile文件，并根据修改后的所述dockerfile文件编辑测试容器。进一步地，所述dockercompose节点还包括：httpproxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。本发明实施例又提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一所述的信测试方法。本发明实施例再提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的测试方法。本发明实施例提供的一种测试系统及方法，该系统包括：代码管理节点、资源调度节点和至少两个dockercompose节点；代码管理节点对待测试项目的每一待测试分支的测试代码进行打包处理，生成待测试分支的代码文件；按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从资源调度节点发送的可用节点列表中确定dockercompose节点，向目标dockercompose节点发送所生成的代码文件；dockercompose节点运行获得的待测试分支的运行环境的镜像文件生成测试容器，将指定的目录中部署的代码文件挂载在dockercompose测试容器中，以对待测试分支进行测试。相对于现有技术，本发明实施例提供的系统是按照一个dockercompose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式确定目标dockercompose节点并署代码文件的，且dockercompose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行待测试分支的运行环境的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，可见，待测试项目间可以根据不同版本同时进行测试，不阻塞或者污染正在测试的项目，因此，应用本发明实施例提供的方案能够提高对软件进行测试的效率。附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。图1为本发明实施例提供的第一种测试系统的结构示意图；图2为本发明实施例提供的第二种测试系统的结构示意图；图3为本发明实施例提供的第一种测试方法的流程示意图；图4为本发明实施例提供的第二种测试方法的流程示意图；图5为本发明实施例提供的一种电子设备的结构示意图。具体实施方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。下面对本发明实施例涉及的术语进行说明。1、测试项目测试项目是通过测试技术手段运行或测试某个软件的一个项目，目的在于检验该项目是否满足规定的需要或弄清楚预期结果与实际结果之间的差别。例如，测试微信可以作为一个测试项目。另外，在包括手机app监控软件和云平台监控软件的大数据监控系统中，测试手机app监控软件可作为一个测试项目，测试云平台监控软件也可以作为一个测试项目。2、测试分支测试分支可以是为了满足不同的需求而划分出来的分支版本，主要针对不同的开发需求，或多个团队协同开发一套代码，一套代码可以有多个分支。现针对测试分支举一示例：如发布的项目a，但项目a中存在漏洞，同时又要继续对项目a开发。这个时候又不能将项目a开发的功能发布，此刻可以在发布项目a时对该漏洞建立一个分支，该分支的分支版本记为版本1.0，为了对项目a增加一个功能，也可以将该功能建立一个分支，该分支的分支版本记为版本2.0。基于上述的示例，如微信的分支包括付款功能、下载功能和视频功能，则微信的三个测试分支分别为付款功能的测试分支、下载功能的测试分支和视频功能的测试分支。为了解决现有技术问题，本发明实施例提供了一种测试系统及方法。参见图1，图1为本实施例提供的一种测试系统的结构示意图，该系统包括：资源调度节点10、dockercompose节点20和代码管理节点30；资源调度节点10，用于监测dockercompose节点20的状态，并根据监测结果，获取包含可用dockercompose节点20信息的可用节点列表；并向代码管理节点30发送可用节点列表；代码管理节点30，用于对待测试项目的每一待测试分支的测试代码进行打包处理，生成该待测试分支的代码文件；并在接收到资源调度节点发送的该可用节点列表时，按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点，并向所述目标dockercompose节点发送所生成的代码文件；dockercompose节点20，用于在接收到代码管理节点发送的代码文件时，将所接收的代码文件部署在指定的目录中；并获得待测试分支的运行环境的镜像文件，通过运行所获得的镜像文件生成测试容器，将指定的目录中部署的代码文件挂载在所述测试容器中，以对待测试分支进行测试。其中，测试系统可以采用开源脚本语言php(hypertextpreprocessor，超文本预处理器)开发。本发明的一个实施例中，dockercompose节点20的状态中可以包括资源状态，其中，资源状态是指资源消耗和资源运行状态。基于情况，资源调度节点监测每一dockercompose节点20的状态，可以是监测每一dockercompose节点20的资源状态，资源状态包括：已经占用多少资源，可用多少资源。资源调度节点监测每一dockercompose节点20的状态的一种实现方式可以为：监测每一dockercompose节点20自身所生成的测试容器的进程以达到监测每一dockercompose节点20的状态。基于对dockercompose节点20的状态的描述可知，dockercompose节点20包括可用dockercompose节点和不可用dockercompose节点。其中，进程可以理解为每一测试容器测试待测分支的代码文件的进程。可见，本实现方式通过监测每一dockercompose节点自身所生成的测试容器的进程，可以快速、准确地获得每一dockercompose节点的资源状态。由于可能存在一些dockercompose节点在某一时刻是可用的，在另一时刻这些dockercompose节点被占用了，也就是不可用了，为了部署代码文件，因此需要根据监测结果更新、记录可用dockercompose节点信息的可用节点列表。每个dockercompose节点上可以运行一个待测试项目，也可以运行多个待测试项目；对于一个特定的待测试项目，每个dockercompose节点上只能运行它的一个版本；每个待测试项目相互间是独立的，每一待测试项目所使用的语言可以是相同的，也可以是不同的；每个待测试项目都有自己的版本定义方式，不同的待测试项目间版本互相独立，完全不影响。一个测试项目设有多个测试分支的目的是为了满足不同的需求而划分出来的分支版本，主要针对不同的开发需求，或多个团队协同开发一套代码，一套代码可以有多个分支。本发明的一个实施例中，对待测试项目的每一待测试分支的测试代码进行打包处理时，可以按照打包规则对待测试项目的每一待测试分支的测试代码进行打包处理，该打包规则可为按照测试代码所使用的代码语言确定的规则。代码文件可以理解为程序员用开发工具所支持的语言写出来的源文件的压缩文件。举例而言：如果待测试分支的测试代码所使用的是java类代码，则打包规则为：通过maven命令对测试代码进行打包，生成tar包；如果待测试分支的测试代码所使用的是node类的代码，则打包规则为：将该node类的代码以及依赖的node_modules压缩成tar包。代码管理节点可以利用shell命令按照代码规则实现待测试分支的测试代码打包。按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，可以理解为：一个dockercompose节点上可以部署多个待测试项目的代码文件，但是仅仅能够部署每一待测试项目的一个测试分支的代码文件。这样的话，每个dockercompose节点可以同时部署多个不同测试项目的测试分支的代码文件，也就是，每个dockercompose节点可以同时对多个不同测试项目的测试分支进行测试，做到不同测试项目之间的并行测试，节省了测试资源。举例而言，假设本发明实施例提供的测试系统中包含三个dockercompose节点，分别记为：节点1、节点2和节点3。待测试项目以及每个待测试项目所包含待测试分支的情况如下表1所示。表1待测试项目待测试分支待测试项目a1待测试分支a11、待测试分支a12和待测试分支a13待测试项目a2待测试分支a21和待测试分支a22待测试项目a3待测试分支a31和待测试分支a32对表1中每一待测试分支的测试代码进行打包处理，则生成与待测试分支相应的代码文件。代码管理节点向每一目标dockercompose节点部署的代码文件的情况如下表2所示。表2对一个待测试分支的测试代码进行打包处理，所生成的代码文件可以为一个文件也可以为多个文件；基于上述示例，待测试分支以及待测试分支对应生成的代码文件的情况如下表3所示。表3待测试分支待测试分支生成的代码文件待测试分支a11代码文件a111和代码文件a112待测试分支a12代码文件a121和代码文件a122待测试分支a13待测试分支a13的代码文件待测试分支a21待测试分支a21的代码文件待测试分支a22待测试分支a22的代码文件待测试分支a31待测试分支a31的代码文件待测试分支a32待测试分支a32的代码文件根据表2中节点中部署代码文件的情况，以及表3中代码文件和待测试分支的对应关系，对上述表3的代码文件进行部署时，还需要增加一个节点，记为节点4，具体见表4。表4代码管理节点可以借助php-ansible库将生成的代码文件发送至各个目标dockercompose节点中。该运行环境可以理解为一种把半编译的运行码在目标机器上运行的环境。其中，镜像文件可以理解为与压缩包rar或zip类似，将运行环境按照一定的格式制作成单一的文件，以方便用户下载后使用或直接使用。dockercompose节点通过docker环境直接运行镜像文件，生成测试容器，dockercompose节点通过运行一个镜像文件可以生成多个测试容器，这些测试容器中可以测试同一测试项目的测试分支的代码文件。需要说明的是，同一测试项目的测试分支的运行环境均相同，也就是说，同一项目的不同测试分支的运行环境的镜像文件均相同。举例而言，基于上述示例，项目1的三个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件1，项目2的两个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件2，项目3的两个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件3，各个节点生成的测试容器测试的代码文件的情况如下表5所示。表5由此可见，待测试的代码文件与测试工具即dockercompose节点的测试容器是分开管理的，也就是，代码文件是被挂载在dockercompose节点指定的目录中，测试容器是dockercompose节点运行镜像文件生成的，二者之间的生成或部署是独立的。测试人员只需要准备测试代码文件，配置测试待测试分支的流程就可实施测试了，由于测试容器是由dockercompose节点运行环境的镜像文件运行生成，因此在测试容器生成后，还需要继续测试代码文件时，无需搭建测试环境和启动测试服务及测试工具，操作简单，管理方便。另外，由于每个dockercompose节点上部署的待测试项目均可以是相同的，在宿主机硬件资源充足的条件下，理论上可以支持无限多个待测试项目，以充分利用硬件资源实现并行测试，因此dockercompose节点支持水平扩展。本发明实施例提供的系统能够实现快速搭建测试环境以实现并行测试，可以对各个不同的测试项目进行并行测试，因此相对于现有技术的测试系统，每一测试项目需要对应提供一个测试系统，本发明实施例提供的系统所需要的硬件成本低。另外，能够支持微服务系统的并行测试部署，且不同测试项目对应的测试环境之间由于使用测试容器对代码文件进行测试，因此能够使得资源隔离，同时每一dockercompose节点均是独立的，因此构成了网络隔离。另外，仅仅利用运行环境生成待测试分支的镜像文件，对于开发人员和测试人员，每一dockercompose节点所需要的测试环境均相同，因此可根据运行环境的镜像文件进行一键部署，网络和资源相互隔离，更容易定位和发现该测试系统的漏洞bug，提高代码质量。由此可见，本发明实施例提供的系统包括代码管理节点、资源调度节点和dockercompose节点；按照一个dockercompose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式，代码管理节点从资源调度节点发送的可用节点列表中确定目标dockercompose节点，并向目标dockercompose节点发送代码文件；dockercompose节点运行待测试分支的运行环境的镜像文件生成测试容器，将接收的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的系统按照一个dockercompose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式确定目标dockercompose节点并署代码文件的，且目标dockercompose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，可见，待测试项目间可以根据不同版本同时进行测试，不阻塞或者污染正在测试的项目，因此，应用本发明实施例提供的系统能够提高对软件进行测试的效率。在一种实现方式中，获得待测试分支的运行环境的镜像文件，包括：从本地私有仓库中拉取待测试分支的运行环境的镜像文件。其中，可以提前将每一项目的运行环境一一对应生成镜像文件，并将生成的镜像文件保存在本地私有仓库中，这样，在每一dockercompose节点在测试待测试分支的代码文件时，需要待测试分支对应的镜像文件时，仅需要从本地私有仓库中拉取所需要的镜像文件便可，无需在使用时生成镜像文件，而且每一dockercompose节点存在使用同一镜像文件的可能，也就是说，在部署新测试环境时，只需要更新业务代码即待测试分支的代码文件，不重新制作镜像文件。因此，将镜像文件提前保存在本地私有仓库中，提高了dockercompose节点测试效率。举例而言，基于上述示例，设本地私有仓库中存储有镜像文件1、镜像文件2和镜像文件3，则节点1、节点2和节点3在需要镜像文件时，节点1和节点2无需生成镜像文件1、镜像文件2和镜像文件3，节点3无需生成镜像文件1，节点1和节点2仅需要分别从本地私有仓库拉取镜像文件1、镜像文件2和镜像文件3，节点3仅需要从本地私有仓库拉取镜像文件1，节约了每一dockercompose节点生成镜像文件的时间。可见，本实现方式通过从本地私有仓库中拉取待测试分支的运行环境的镜像文件，不仅为dockercompose节点在测试待测试分支的代码文件时提供便利，而且也能够进一步提高测试效率。在一种实现方式中，资源调度节点，还用于控制每一目标dockercompose节点生成的各个测试容器的生命周期。每一目标dockercompose节点通过docker的api(applicationprogramminginterface,应用程序编程接口)或者dockerevent命令，都可以获取到每一测试容器在生命周期内的测试状态，其中，测试状态可以理解为每一测试容器测试代码文件过程中所处的状态，对于一个测试容器的生命周期来说，测试状态一般有4个状态，分别为：新建、初始化完成、启动、停止、失败或销毁等。资源调度节点从每一目标dockercompose节点获取每一测试容器在生命周期内的测试状态，可以根据获取的每一测试容器在生命周期内的测试状态，控制每一目标dockercompose节点生成的各个测试容器是否需要销毁、停止或启动等。资源调度节点可以展示每一目标dockercompose节点对应的测试容器在生命周期内的测试状态，实现与管理人员的交互，使管理人员能够根据实际测试情况，决定是否控制某一测试容器的生命周期。可见，本实现方式通过控制每一目标dockercompose节点生成的各个测试容器的生命周期，便于能够掌握每一待测试分支的代码文件的测试状态，能够为用户带来良好的体验效果。在一种实现方式中，dockercompose节点为：安装有dockercompose服务和dockercompose管理器的宿主机；其中，dockercompose管理器中设置有与dockercompose通信的web接口，dockercompose管理器用于控制各个dockercompose节点上的dockercompose服务；dockercompose服务用于控制自身所在的dockercompose节点生成的各个测试容器的运行。其中，dockercompose可以理解为是一个定义和运行多个容器docker应用程序的工具。也就是说，可以通过dockercompose，可以使用配置文件来配置应用程序所需要的服务。dockercompose服务的作用可以理解为能够对测试容器起到编排作用，也就是说，能够将dockercompose节点上自身运行的多个测试容器实例进行编排组织，以使编排组织后的测试容器能够对外提供一种服务；其中，一个测试容器可以看作一个运行实例。dockercompose服务和测试容器的关系可以比喻成音乐会上的指挥和各乐器手的关系。dockercompose管理器由于提供了与dockercompose通信的web接口，因此可以通过httpapi来控制各dockercompose节点上的dockercompose服务。如图2所示，代码管理节点通过api与所述资源调度节点通信，所述资源调度节点分别通过api一一对应与每一dockercompose节点通信，而每一dockercompose节点均安装有dockercompose管理器和dockercompose服务，其中，dockercompose管理器控制自身所在dockercompose节点的dockercompose服务，以实现dockercompose服务对测试容器的编排组织。可见，本实现方式的dockercompose节点能够使自身上的测试容器井然有序的进行测试，进一步提高了对测试软件的测试效率。在一种实现方式中，在将上述目录中部署的代码文件挂载在测试容器中对待测试分支进行测试之后，dockercompose节点，还用于执行以下操作中的至少一种：监控自身生成的各个测试容器的资源消耗和运行状态；管理自身目录中部署的代码文件；管理测试过程中生成的日志文件；在对待测试分支完成测试后，释放测试过程中占用的资源；在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；提交待测试分支所依赖的dockerfile文件和docke-compse.yml文件，其中，dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。其中，对各个测试容器的资源消耗和运行状态进行实时监控，可以通过统计各测试容器的性能指标，并对测试容器的测试结果进行分析，生成测试报告，可随时对被测系统进行性能和功能方面的评估，有助于快速发现系统问题，提高测试效率。管理测试过程中生成的日志文件可以有助于测试人员处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动。在对待测试分支完成测试后，释放测试过程中占用的资源，有助于提高dockercompose节点的性能和测试速度。将所生成的镜像文件提交到本地私有库中，可以助于以备后续人员对待测试分支的研究和问题的追踪。dockerfile文件对运行环境的可靠描述，能保证开发环境与测试环境的一致性。docke-compse.yml文件可以理解为用于定义各个测试容器的配置信息，如使用什么镜像、挂载数据卷、依赖的容器以及对外提供的端口等。也可以理解为：用于定义多个镜像容器间的组合和编排关系，组合编排的结果是形成一个完整的“环境”来运行服务。可见，本实现方式所提供的上述操作不仅可以有助于测试人员快速发现系统问题，提高测试效率，而且也助于处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动，同时以备后续人员对待测试分支的研究和问题的追踪，进一步能够为用户带来良好的体验效果。在一种实现方式中，上述资源调度节点，还用于通过修改dockerfile文件编辑测试容器。其中，上述编辑包括：添加、删除或重新配置。可见，本实现方式通过修改dockerfile文件编辑测试容器，能够使测试系统更加完善和智能，有助于进一步提高用户体验效果。在一种实现方式中，dockercompose节点还包括：httpproxy，用于将待测项目的流量一一对应导入至流量对应的各个待测项目或分支中。其中，可以通过两种访问方式，实现httpproxy的功能，第一个访问方式为：将各个待测项目的域名与dockercompose节点绑定的访问方式，以使当测试任务时，根据请求域名，将待测项目的流量一一对应导入至待测试项目对应的测试容器。第二个访问方式为：使用地址ip+端口号port的方式访问各个dockercompose节点的dockercompose服务的访问方式，以使根据访问的dockercompose服务，将待测项目的流量一一对应导入至待测试项目对应的测试容器。可见，本实现方式中的httpproxy可以将待测项目的流量一一对应导入至待测试项目对应的测试容器，减少了测试人员的工作量，提高了测试效率。参见图3，图3为一种测试方法的流程示意图，该测试方法的执行主体可以是代码管理节点，也可以是具备代码管理节点功能和资源调度节点功能的设备。上述方法包括：s301，获得记录可用dockercompose节点信息的可用节点列表；s301的一种实现方式可以为：通过监测dockercompose节点的状态，并根据监测结果，获取包含可用dockercompose节点信息的可用节点列表；另一种实现方式为：从第三方软件中获得记录可用dockercompose节点信息的可用节点列表。s302，按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点；s303，对待测试项目的每一待测试分支的测试代码进行打包处理，生成该待测试分支的代码文件；s304，向目标dockercompose节点发送所生成的代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。在s304之后，一种实现方式可以为：控制目标dockercompose节点在对所述待测试分支进行测试过程中生成的测试容器的生命周期。在s304之后，另一种实现方式可以为：对dockerfile文件进行修改，以使得目标dockercompose节点根据修改后的所述dockerfile文件编辑测试容器，其中，所述dockerfile文件为：用于生成所述镜像文件的配置文件。由此可见，本发明实施例提供的方法通过按照一个dockercompose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式，从可用节点列表中确定目标dockercompose节点，并向目标dockercompose节点发送代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法按照一个dockercompose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式部确定目标dockercompose节点并署代码文件的，以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。参见图4，图4为第二种测试方法的流程示意图，应用于dockercompose节点，其中，该dockercompose节点也属于具备代码管理节点功能和资源调度节点功能的设备。上述方法包括：s401，获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件；在一种实现方式中，dockercompose节点为：安装有dockercompose服务和dockercompose管理器的宿主机；其中，dockercompose管理器中设置有与dockercompose通信的web接口，dockercompose管理器用于控制各个dockercompose节点上的dockercompose服务；dockercompose服务用于控制自身所在的dockercompose节点生成的各个测试容器的运行。可见，本实现方式的dockercompose节点能够使自身上的测试容器井然有序的进行测试，进一步提高了对测试软件的测试效率。s402，将所接收的代码文件部署在指定的目录中；s403，获得待测试分支的运行环境的镜像文件；实现s403的一种具体实现方式，包括：从本地私有仓库中拉取待测试分支的运行环境的镜像文件。可见，本实现方式通过从本地私有仓库中拉取待测试分支的运行环境的镜像文件，不仅为dockercompose节点在测试待测试分支的代码文件时提供便利，而且也能够进一步提高测试效率。s404，运行所获得的镜像文件生成测试容器；s405，将目录中部署的代码文件挂载在上述测试容器中对待测试分支进行测试。在s405之后，执行以下操作中的至少一种：监控自身生成的各个测试容器的资源消耗和运行状态；管理自身目录中部署的代码文件；管理测试过程中生成的日志文件；在对待测试分支完成测试后，释放测试过程中占用的资源；在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；提交待测试分支所依赖的dockerfile文件和docke-compse.yml文件，其中，dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。可见，本实现方式所提供的上述操作不仅可以有助于测试人员快速发现系统问题，提高测试效率，而且也助于处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动，同时以备后续人员对待测试分支的研究和问题的追踪，进一步能够为用户带来良好的体验效果。由此可见，本发明实施例提供的方法通过运行待测试分支的运行环境的镜像文件生成测试容器，将接收的按照预设方式确定的待测试分支的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法是通过按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，获得所生成的代码文件，且dockercompose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。本发明实施例还提供了一种电子设备，参考图5，图5为本发明实施例的电子设备的示意图，如图5所示，电子设备包括处理器501、通信接口502、存储器503和通信总线504，其中，处理器501，通信接口502，存储器503通过通信总线504完成相互间的通信，存储器503，用于存放计算机程序；处理器501，用于执行存储器503上所存放的程序时，实现本发明实施例提供的两种测试方法。具体的，上述第一种测试方法，该方法包括：获得记录可用dockercompose节点信息的可用节点列表；按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点；对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；向目标dockercompose节点发送所生成的代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。由此可见，执行本实施例提供的电子设备，通过从获得的可用节点列表中确定dockercompose节点；按照一个dockercompose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式确定目标dockercompose节点，并向目标dockercompose节点发送代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法按照一个dockercompose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式部署代码文件的，以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。上述的相关内容测试方法的实施方式与前述方法实施例部分提供的测试方式相同，这里不再赘述。上述第二种测试方法，上述电子设备可以作为dockercompose节点，方法包括：获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件；将所接收的代码文件部署在指定的目录中；获得待测试分支的运行环境的镜像文件；运行所获得的镜像文件生成测试容器；将指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试。由此可见，执行本实施例提供的电子设备，通过运行待测试分支的运行环境的镜像文件生成测试容器，将接收的按照预设方式确定的待测试分支的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法是通过按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，获得所生成的代码文件，且dockercompose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。的相关内容测试方法的实施方式与前述方法实施例部分提供的测试方式相同，这里不再赘述。电子设备提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于上述电子设备与其他设备之间的通信。存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的测试方法。在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的测试方法。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备、存储介质和程序产品实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。当前第1页12