CN109739744A - 一种测试系统及方法 - Google Patents
一种测试系统及方法 Download PDFInfo
- Publication number
- CN109739744A CN109739744A CN201811481607.0A CN201811481607A CN109739744A CN 109739744 A CN109739744 A CN 109739744A CN 201811481607 A CN201811481607 A CN 201811481607A CN 109739744 A CN109739744 A CN 109739744A
- Authority
- CN
- China
- Prior art keywords
- test
- node
- branch
- file
- tested
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 374
- 238000000034 method Methods 0.000 title claims abstract description 69
- 238000012856 packing Methods 0.000 claims abstract description 20
- 238000012545 processing Methods 0.000 claims abstract description 17
- 230000008569 process Effects 0.000 claims description 24
- 238000004891 communication Methods 0.000 claims description 19
- 238000010998 test method Methods 0.000 claims description 18
- 238000012544 monitoring process Methods 0.000 claims description 12
- 230000005540 biological transmission Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 5
- 230000006399 behavior Effects 0.000 claims 1
- 230000006870 function Effects 0.000 description 13
- 238000005516 engineering process Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 8
- 230000001276 controlling effect Effects 0.000 description 7
- 238000011161 development Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000011160 research Methods 0.000 description 3
- 238000002405 diagnostic procedure Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 235000013399 edible fruits Nutrition 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013522 software testing Methods 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明实施例提供了一种测试系统及方法，该系统包括：代码管理节点、资源调度节点和至少两个docker compose节点；代码管理节点对待测试项目的每一待测试分支的测试代码进行打包处理，生成代码文件；按照一个docker compose节点上部署同一测试项目的一个待测试分支的代码文件的方式，从资源调度节点发送的可用节点列表中确定目标docker compose节点，并向目标docker compose节点发送代码文件；docker compose节点运行待测试分支的运行环境的镜像文件生成测试容器，将代码文件挂载在测试容器中对待测试分支进行测试。应该本发明实施例的方案能够提高对软件进行测试的效率。
Description
技术领域
本发明涉及软件测试技术领域，特别是涉及一种测试系统及方法。
背景技术
随着软件技术的快速发展，各种各样的软件为人们的生活提供了便利。软件开发人员将所开发的软件提供给用户使用之前，一般会进行严格的测试，以发现软件中存在的问题，并消除所发现的问题。
现有技术中，对软件进行测试时，可以采用Docker技术对软件进行测试。其中，Docker是一个开源的应用容器引擎。在采用Docker技术对软件进行测试时，一般是利用Docker所提供的容器对软件进行测试。
然而，在测试过程中，Docker所提供的各个容器所启动的软件待测试项目的运行环境的镜像文件只能是同一镜像文件，因此，利用Docker所提供的容器对软件进行测试时，只能对软件的同一待测试项目的同一待测试分支进行测试。
而对于一个软件而言，一般存在多个待测试项目，每一待测试项目又存在多个待测试分支，这样应用上述方式进行软件测试时，测试效率低下。
发明内容
本发明实施例的目的在于提供一种测试系统及方法，能够提高对软件进行测试的效率。
具体技术方案如下：
一种测试系统，所述系统包括：代码管理节点、资源调度节点和至少两个dockercompose节点；
所述资源调度节点，用于所述docker compose节点的状态，并根据监测结果，获取包含可用docker compose节点信息的可用节点列表；并向所述代码管理节点发送所述可用节点列表；
所述代码管理节点，用于对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；并在接收到所述资源调度节点发送的所述可用节点列表时，按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所述可用节点列表中确定用于部署所生成代码文件的目标docker compose节点，并向所述目标docker compose节点发送所生成的代码文件；
所述docker compose节点，用于在接收到所述代码管理节点发送的代码文件时，并将所接收的代码文件部署在指定的目录中；并获得待测试分支的运行环境的镜像文件，通过运行所获得的镜像文件生成测试容器，将所述指定的目录中部署的代码文件挂载在所述测试容器中，以对待测试分支进行测试。
进一步地，所述获得待测试分支的运行环境的镜像文件，包括：
从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
进一步地，所述资源调度节点，还用于控制每一所述目标docker compose节点生成的各个测试容器的生命周期。
进一步地，所述docker compose节点为：安装有docker compose服务和dockercompose管理器的宿主机；
其中，所述docker compose管理器中设置有与docker compose通信的web接口，所述docker compose管理器用于控制各个docker compose节点上的docker compose服务；
所述docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
进一步地，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中之后，
所述docker compose节点，还用于执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件到本地私有库中，其中，所述Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
进一步地，所述资源调度节点，还用于修改所述Dockerfile文件；
所述docker compose节点，还用于根据修改后的所述Dockerfile文件编辑测试容器。
进一步地，所述docker compose节点还包括：http proxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。
一种测试方法，所述方法包括：
获得记录可用docker compose节点信息的可用节点列表；
按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标docker compose节点；
对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；
向所述目标docker compose节点发送所生成的代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。
进一步地，所述方法还包括：
控制所述目标docker compose节点在对所述待测试分支进行测试过程中生成的测试容器的生命周期。
进一步地，所述方法还包括：
对Dockerfile文件进行修改，以使得所述目标docker compose节点根据修改后的所述Dockerfile文件编辑测试容器，其中，所述Dockerfile文件为：用于生成所述镜像文件的配置文件。
一种测试方法，应用于docker compose节点，所述方法包括：
获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个docker compose节点上部署同一测试项目的一个测试分支的代码文件；
将所接收的代码文件部署在指定的目录中；
获得待测试分支的运行环境的镜像文件；
运行所获得的镜像文件生成测试容器；
将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试。
进一步地，所述获得待测试分支的运行环境的镜像文件，包括：
从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
进一步地，所述docker compose节点为：安装有docker compose服务和dockercompose管理器的宿主机；
其中，所述docker compose管理器中设置有与docker compose通信的web接口，所述docker compose管理器用于控制各个docker compose节点上的docker compose服务；
所述docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
进一步地，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试之后，还包括：执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件到本地私有库中，其中，所述Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
进一步地，所述方法还包括：
获得修改后的所述Dockerfile文件，并根据修改后的所述Dockerfile文件编辑测试容器。
进一步地，所述Docker compose节点还包括：http proxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。
本发明实施例又提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一所述的信测试方法。
本发明实施例再提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的测试方法。
本发明实施例提供的一种测试系统及方法，该系统包括：代码管理节点、资源调度节点和至少两个docker compose节点；代码管理节点对待测试项目的每一待测试分支的测试代码进行打包处理，生成待测试分支的代码文件；按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从资源调度节点发送的可用节点列表中确定docker compose节点，向目标docker compose节点发送所生成的代码文件；dockercompose节点运行获得的待测试分支的运行环境的镜像文件生成测试容器，将指定的目录中部署的代码文件挂载在docker compose测试容器中，以对待测试分支进行测试。相对于现有技术，本发明实施例提供的系统是按照一个docker compose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式确定目标docker compose节点并署代码文件的，且docker compose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行待测试分支的运行环境的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，可见，待测试项目间可以根据不同版本同时进行测试，不阻塞或者污染正在测试的项目，因此，应用本发明实施例提供的方案能够提高对软件进行测试的效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1为本发明实施例提供的第一种测试系统的结构示意图；
图2为本发明实施例提供的第二种测试系统的结构示意图；
图3为本发明实施例提供的第一种测试方法的流程示意图；
图4为本发明实施例提供的第二种测试方法的流程示意图；
图5为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。
下面对本发明实施例涉及的术语进行说明。
1、测试项目
测试项目是通过测试技术手段运行或测试某个软件的一个项目，目的在于检验该项目是否满足规定的需要或弄清楚预期结果与实际结果之间的差别。
例如，测试微信可以作为一个测试项目。另外，在包括手机APP监控软件和云平台监控软件的大数据监控系统中，测试手机APP监控软件可作为一个测试项目，测试云平台监控软件也可以作为一个测试项目。
2、测试分支
测试分支可以是为了满足不同的需求而划分出来的分支版本，主要针对不同的开发需求，或多个团队协同开发一套代码，一套代码可以有多个分支。
现针对测试分支举一示例：如发布的项目A，但项目A中存在漏洞，同时又要继续对项目A开发。这个时候又不能将项目A开发的功能发布，此刻可以在发布项目A时对该漏洞建立一个分支，该分支的分支版本记为版本1.0，为了对项目A增加一个功能，也可以将该功能建立一个分支，该分支的分支版本记为版本2.0。
基于上述的示例，如微信的分支包括付款功能、下载功能和视频功能，则微信的三个测试分支分别为付款功能的测试分支、下载功能的测试分支和视频功能的测试分支。
为了解决现有技术问题，本发明实施例提供了一种测试系统及方法。
参见图1，图1为本实施例提供的一种测试系统的结构示意图，该系统包括：资源调度节点10、docker compose节点20和代码管理节点30；
资源调度节点10，用于监测docker compose节点20的状态，并根据监测结果，获取包含可用docker compose节点20信息的可用节点列表；并向代码管理节点30发送可用节点列表；
代码管理节点30，用于对待测试项目的每一待测试分支的测试代码进行打包处理，生成该待测试分支的代码文件；并在接收到资源调度节点发送的该可用节点列表时，按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从可用节点列表中确定用于部署所生成代码文件的目标docker compose节点，并向所述目标docker compose节点发送所生成的代码文件；
docker compose节点20，用于在接收到代码管理节点发送的代码文件时，将所接收的代码文件部署在指定的目录中；并获得待测试分支的运行环境的镜像文件，通过运行所获得的镜像文件生成测试容器，将指定的目录中部署的代码文件挂载在所述测试容器中，以对待测试分支进行测试。
其中，测试系统可以采用开源脚本语言php(Hypertext Preprocessor，超文本预处理器)开发。
本发明的一个实施例中，docker compose节点20的状态中可以包括资源状态，其中，资源状态是指资源消耗和资源运行状态。基于情况，资源调度节点监测每一dockercompose节点20的状态，可以是监测每一docker compose节点20的资源状态，资源状态包括：已经占用多少资源，可用多少资源。
资源调度节点监测每一docker compose节点20的状态的一种实现方式可以为：监测每一docker compose节点20自身所生成的测试容器的进程以达到监测每一dockercompose节点20的状态。
基于对docker compose节点20的状态的描述可知，docker compose节点20包括可用docker compose节点和不可用docker compose节点。
其中，进程可以理解为每一测试容器测试待测分支的代码文件的进程。
可见，本实现方式通过监测每一docker compose节点自身所生成的测试容器的进程，可以快速、准确地获得每一docker compose节点的资源状态。
由于可能存在一些docker compose节点在某一时刻是可用的，在另一时刻这些docker compose节点被占用了，也就是不可用了，为了部署代码文件，因此需要根据监测结果更新、记录可用docker compose节点信息的可用节点列表。
每个docker compose节点上可以运行一个待测试项目，也可以运行多个待测试项目；
对于一个特定的待测试项目，每个docker compose节点上只能运行它的一个版本；
每个待测试项目相互间是独立的，每一待测试项目所使用的语言可以是相同的，也可以是不同的；
每个待测试项目都有自己的版本定义方式，不同的待测试项目间版本互相独立，完全不影响。
一个测试项目设有多个测试分支的目的是为了满足不同的需求而划分出来的分支版本，主要针对不同的开发需求，或多个团队协同开发一套代码，一套代码可以有多个分支。
本发明的一个实施例中，对待测试项目的每一待测试分支的测试代码进行打包处理时，可以按照打包规则对待测试项目的每一待测试分支的测试代码进行打包处理，该打包规则可为按照测试代码所使用的代码语言确定的规则。
代码文件可以理解为程序员用开发工具所支持的语言写出来的源文件的压缩文件。
举例而言：如果待测试分支的测试代码所使用的是java类代码，则打包规则为：通过maven命令对测试代码进行打包，生成tar包；如果待测试分支的测试代码所使用的是node类的代码，则打包规则为：将该node类的代码以及依赖的node_modules压缩成tar包。
代码管理节点可以利用shell命令按照代码规则实现待测试分支的测试代码打包。
按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，可以理解为：一个docker compose节点上可以部署多个待测试项目的代码文件，但是仅仅能够部署每一待测试项目的一个测试分支的代码文件。这样的话，每个dockercompose节点可以同时部署多个不同测试项目的测试分支的代码文件，也就是，每个dockercompose节点可以同时对多个不同测试项目的测试分支进行测试，做到不同测试项目之间的并行测试，节省了测试资源。
举例而言，假设本发明实施例提供的测试系统中包含三个docker compose节点，分别记为：节点1、节点2和节点3。待测试项目以及每个待测试项目所包含待测试分支的情况如下表1所示。
表1
| 待测试项目 | 待测试分支 |
| 待测试项目A1 | 待测试分支A11、待测试分支A12和待测试分支A13 |
| 待测试项目A2 | 待测试分支A21和待测试分支A22 |
| 待测试项目A3 | 待测试分支A31和待测试分支A32 |
对表1中每一待测试分支的测试代码进行打包处理，则生成与待测试分支相应的代码文件。代码管理节点向每一目标docker compose节点部署的代码文件的情况如下表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类似，将运行环境按照一定的格式制作成单一的文件，以方便用户下载后使用或直接使用。
docker compose节点通过Docker环境直接运行镜像文件，生成测试容器，dockercompose节点通过运行一个镜像文件可以生成多个测试容器，这些测试容器中可以测试同一测试项目的测试分支的代码文件。
需要说明的是，同一测试项目的测试分支的运行环境均相同，也就是说，同一项目的不同测试分支的运行环境的镜像文件均相同。
举例而言，基于上述示例，项目1的三个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件1，项目2的两个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件2，项目3的两个待测试分支的运行环境对应的镜像文件均相同，记为镜像文件3，各个节点生成的测试容器测试的代码文件的情况如下表5所示。
表5
由此可见，待测试的代码文件与测试工具即docker compose节点的测试容器是分开管理的，也就是，代码文件是被挂载在docker compose节点指定的目录中，测试容器是docker compose节点运行镜像文件生成的，二者之间的生成或部署是独立的。测试人员只需要准备测试代码文件，配置测试待测试分支的流程就可实施测试了，由于测试容器是由docker compose节点运行环境的镜像文件运行生成，因此在测试容器生成后，还需要继续测试代码文件时，无需搭建测试环境和启动测试服务及测试工具，操作简单，管理方便。
另外，由于每个docker compose节点上部署的待测试项目均可以是相同的，在宿主机硬件资源充足的条件下，理论上可以支持无限多个待测试项目，以充分利用硬件资源实现并行测试，因此docker compose节点支持水平扩展。
本发明实施例提供的系统能够实现快速搭建测试环境以实现并行测试，可以对各个不同的测试项目进行并行测试，因此相对于现有技术的测试系统，每一测试项目需要对应提供一个测试系统，本发明实施例提供的系统所需要的硬件成本低。另外，能够支持微服务系统的并行测试部署，且不同测试项目对应的测试环境之间由于使用测试容器对代码文件进行测试，因此能够使得资源隔离，同时每一docker compose节点均是独立的，因此构成了网络隔离。
另外，仅仅利用运行环境生成待测试分支的镜像文件，对于开发人员和测试人员，每一docker compose节点所需要的测试环境均相同，因此可根据运行环境的镜像文件进行一键部署，网络和资源相互隔离，更容易定位和发现该测试系统的漏洞bug，提高代码质量。
由此可见，本发明实施例提供的系统包括代码管理节点、资源调度节点和dockercompose节点；按照一个docker compose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式，代码管理节点从资源调度节点发送的可用节点列表中确定目标docker compose节点，并向目标docker compose节点发送代码文件；docker compose节点运行待测试分支的运行环境的镜像文件生成测试容器，将接收的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的系统按照一个dockercompose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式确定目标docker compose节点并署代码文件的，且目标docker compose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，可见，待测试项目间可以根据不同版本同时进行测试，不阻塞或者污染正在测试的项目，因此，应用本发明实施例提供的系统能够提高对软件进行测试的效率。
在一种实现方式中，获得待测试分支的运行环境的镜像文件，包括：从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
其中，可以提前将每一项目的运行环境一一对应生成镜像文件，并将生成的镜像文件保存在本地私有仓库中，这样，在每一docker compose节点在测试待测试分支的代码文件时，需要待测试分支对应的镜像文件时，仅需要从本地私有仓库中拉取所需要的镜像文件便可，无需在使用时生成镜像文件，而且每一docker compose节点存在使用同一镜像文件的可能，也就是说，在部署新测试环境时，只需要更新业务代码即待测试分支的代码文件，不重新制作镜像文件。因此，将镜像文件提前保存在本地私有仓库中，提高了dockercompose节点测试效率。
举例而言，基于上述示例，设本地私有仓库中存储有镜像文件1、镜像文件2和镜像文件3，则节点1、节点2和节点3在需要镜像文件时，节点1和节点2无需生成镜像文件1、镜像文件2和镜像文件3，节点3无需生成镜像文件1，节点1和节点2仅需要分别从本地私有仓库拉取镜像文件1、镜像文件2和镜像文件3，节点3仅需要从本地私有仓库拉取镜像文件1，节约了每一docker compose节点生成镜像文件的时间。
可见，本实现方式通过从本地私有仓库中拉取待测试分支的运行环境的镜像文件，不仅为docker compose节点在测试待测试分支的代码文件时提供便利，而且也能够进一步提高测试效率。
在一种实现方式中，资源调度节点，还用于控制每一目标docker compose节点生成的各个测试容器的生命周期。
每一目标docker compose节点通过docker的API(Application ProgrammingInterface,应用程序编程接口)或者docker event命令，都可以获取到每一测试容器在生命周期内的测试状态，其中，测试状态可以理解为每一测试容器测试代码文件过程中所处的状态，对于一个测试容器的生命周期来说，测试状态一般有4个状态，分别为：新建、初始化完成、启动、停止、失败或销毁等。
资源调度节点从每一目标docker compose节点获取每一测试容器在生命周期内的测试状态，可以根据获取的每一测试容器在生命周期内的测试状态，控制每一目标docker compose节点生成的各个测试容器是否需要销毁、停止或启动等。
资源调度节点可以展示每一目标docker compose节点对应的测试容器在生命周期内的测试状态，实现与管理人员的交互，使管理人员能够根据实际测试情况，决定是否控制某一测试容器的生命周期。
可见，本实现方式通过控制每一目标docker compose节点生成的各个测试容器的生命周期，便于能够掌握每一待测试分支的代码文件的测试状态，能够为用户带来良好的体验效果。
在一种实现方式中，docker compose节点为：安装有docker compose服务和docker compose管理器的宿主机；
其中，docker compose管理器中设置有与docker compose通信的web接口，dockercompose管理器用于控制各个docker compose节点上的docker compose服务；
docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
其中，docker compose可以理解为是一个定义和运行多个容器Docker应用程序的工具。也就是说，可以通过docker compose，可以使用配置文件来配置应用程序所需要的服务。
docker compose服务的作用可以理解为能够对测试容器起到编排作用，也就是说，能够将docker compose节点上自身运行的多个测试容器实例进行编排组织，以使编排组织后的测试容器能够对外提供一种服务；其中，一个测试容器可以看作一个运行实例。docker compose服务和测试容器的关系可以比喻成音乐会上的指挥和各乐器手的关系。
docker compose管理器由于提供了与docker compose通信的web接口，因此可以通过http api来控制各docker compose节点上的docker compose服务。
如图2所示，代码管理节点通过API与所述资源调度节点通信，所述资源调度节点分别通过API一一对应与每一docker compose节点通信，而每一docker compose节点均安装有docker compose管理器和docker compose服务，其中，docker compose管理器控制自身所在docker compose节点的docker compose服务，以实现docker compose服务对测试容器的编排组织。
可见，本实现方式的docker compose节点能够使自身上的测试容器井然有序的进行测试，进一步提高了对测试软件的测试效率。
在一种实现方式中，在将上述目录中部署的代码文件挂载在测试容器中对待测试分支进行测试之后，
docker compose节点，还用于执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件，其中，Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
其中，对各个测试容器的资源消耗和运行状态进行实时监控，可以通过统计各测试容器的性能指标，并对测试容器的测试结果进行分析，生成测试报告，可随时对被测系统进行性能和功能方面的评估，有助于快速发现系统问题，提高测试效率。
管理测试过程中生成的日志文件可以有助于测试人员处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动。
在对待测试分支完成测试后，释放测试过程中占用的资源，有助于提高dockercompose节点的性能和测试速度。
将所生成的镜像文件提交到本地私有库中，可以助于以备后续人员对待测试分支的研究和问题的追踪。
Dockerfile文件对运行环境的可靠描述，能保证开发环境与测试环境的一致性。
Docke-compse.yml文件可以理解为用于定义各个测试容器的配置信息，如使用什么镜像、挂载数据卷、依赖的容器以及对外提供的端口等。也可以理解为：用于定义多个镜像容器间的组合和编排关系，组合编排的结果是形成一个完整的“环境”来运行服务。
可见，本实现方式所提供的上述操作不仅可以有助于测试人员快速发现系统问题，提高测试效率，而且也助于处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动，同时以备后续人员对待测试分支的研究和问题的追踪，进一步能够为用户带来良好的体验效果。
在一种实现方式中，上述资源调度节点，还用于通过修改Dockerfile文件编辑测试容器。
其中，上述编辑包括：添加、删除或重新配置。
可见，本实现方式通过修改Dockerfile文件编辑测试容器，能够使测试系统更加完善和智能，有助于进一步提高用户体验效果。
在一种实现方式中，docker compose节点还包括：http proxy，用于将待测项目的流量一一对应导入至流量对应的各个待测项目或分支中。
其中，可以通过两种访问方式，实现http proxy的功能，第一个访问方式为：将各个待测项目的域名与docker compose节点绑定的访问方式，以使当测试任务时，根据请求域名，将待测项目的流量一一对应导入至待测试项目对应的测试容器。
第二个访问方式为：使用地址ip+端口号port的方式访问各个docker compose节点的docker compose服务的访问方式，以使根据访问的docker compose服务，将待测项目的流量一一对应导入至待测试项目对应的测试容器。
可见，本实现方式中的http proxy可以将待测项目的流量一一对应导入至待测试项目对应的测试容器，减少了测试人员的工作量，提高了测试效率。
参见图3，图3为一种测试方法的流程示意图，该测试方法的执行主体可以是代码管理节点，也可以是具备代码管理节点功能和资源调度节点功能的设备。
上述方法包括：
S301，获得记录可用docker compose节点信息的可用节点列表；
S301的一种实现方式可以为：通过监测docker compose节点的状态，并根据监测结果，获取包含可用docker compose节点信息的可用节点列表；
另一种实现方式为：从第三方软件中获得记录可用docker compose节点信息的可用节点列表。
S302，按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标dockercompose节点；
S303，对待测试项目的每一待测试分支的测试代码进行打包处理，生成该待测试分支的代码文件；
S304，向目标docker compose节点发送所生成的代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。
在S304之后，一种实现方式可以为：控制目标docker compose节点在对所述待测试分支进行测试过程中生成的测试容器的生命周期。
在S304之后，另一种实现方式可以为：对Dockerfile文件进行修改，以使得目标docker compose节点根据修改后的所述Dockerfile文件编辑测试容器，其中，所述Dockerfile文件为：用于生成所述镜像文件的配置文件。
由此可见，本发明实施例提供的方法通过按照一个docker compose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式，从可用节点列表中确定目标docker compose节点，并向目标docker compose节点发送代码文件；以使目标dockercompose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法按照一个docker compose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式部确定目标docker compose节点并署代码文件的，以使目标docker compose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。
参见图4，图4为第二种测试方法的流程示意图，应用于docker compose节点，其中，该docker compose节点也属于具备代码管理节点功能和资源调度节点功能的设备。
上述方法包括：
S401，获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个docker compose节点上部署同一测试项目的一个测试分支的代码文件；
在一种实现方式中，docker compose节点为：安装有docker compose服务和docker compose管理器的宿主机；
其中，docker compose管理器中设置有与docker compose通信的web接口，dockercompose管理器用于控制各个docker compose节点上的docker compose服务；
docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
可见，本实现方式的docker compose节点能够使自身上的测试容器井然有序的进行测试，进一步提高了对测试软件的测试效率。
S402，将所接收的代码文件部署在指定的目录中；
S403，获得待测试分支的运行环境的镜像文件；
实现S403的一种具体实现方式，包括：
从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
可见，本实现方式通过从本地私有仓库中拉取待测试分支的运行环境的镜像文件，不仅为docker compose节点在测试待测试分支的代码文件时提供便利，而且也能够进一步提高测试效率。
S404，运行所获得的镜像文件生成测试容器；
S405，将目录中部署的代码文件挂载在上述测试容器中对待测试分支进行测试。
在S405之后，执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件，其中，Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
可见，本实现方式所提供的上述操作不仅可以有助于测试人员快速发现系统问题，提高测试效率，而且也助于处理历史测试数据、诊断测试问题的追踪以及理解测试系统的活动，同时以备后续人员对待测试分支的研究和问题的追踪，进一步能够为用户带来良好的体验效果。
由此可见，本发明实施例提供的方法通过运行待测试分支的运行环境的镜像文件生成测试容器，将接收的按照预设方式确定的待测试分支的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法是通过按照一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件的方式，获得所生成的代码文件，且docker compose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。
本发明实施例还提供了一种电子设备，参考图5，图5为本发明实施例的电子设备的示意图，如图5所示，电子设备包括处理器501、通信接口502、存储器503和通信总线504，其中，处理器501，通信接口502，存储器503通过通信总线504完成相互间的通信，
存储器503，用于存放计算机程序；
处理器501，用于执行存储器503上所存放的程序时，实现本发明实施例提供的两种测试方法。
具体的，上述第一种测试方法，该方法包括：
获得记录可用docker compose节点信息的可用节点列表；
按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标docker compose节点；
对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；
向目标docker compose节点发送所生成的代码文件；以使目标docker compose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。
由此可见，执行本实施例提供的电子设备，通过从获得的可用节点列表中确定docker compose节点；按照一个docker compose节点上部署已打包后的同一测试项目的一个待测试分支的代码文件的方式确定目标docker compose节点，并向目标docker compose节点发送代码文件；以使目标docker compose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法按照一个docker compose节点上仅能部署同一测试项目的一个待测试分支的代码文件的方式部署代码文件的，以使目标docker compose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。
上述的相关内容测试方法的实施方式与前述方法实施例部分提供的测试方式相同，这里不再赘述。
上述第二种测试方法，上述电子设备可以作为docker compose节点，方法包括：
获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个docker compose节点上部署同一测试项目的一个测试分支的代码文件；
将所接收的代码文件部署在指定的目录中；
获得待测试分支的运行环境的镜像文件；
运行所获得的镜像文件生成测试容器；
将指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试。
由此可见，执行本实施例提供的电子设备，通过运行待测试分支的运行环境的镜像文件生成测试容器，将接收的按照预设方式确定的待测试分支的代码文件挂载在测试容器中对待测试分支进行测试。相对于现有技术，本发明实施例提供的方法是通过按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，获得所生成的代码文件，且docker compose节点测试待测试分支的代码文件所挂载的测试容器，是通过运行由待测试分支的运行环境生成的镜像文件生成的，又因各测试容器间互相隔离，保证各个代码文件的测试环境彼此隔离、互不影响，因此，应用本发明实施例提供的方法能够提高对软件进行测试的效率。
的相关内容测试方法的实施方式与前述方法实施例部分提供的测试方式相同，这里不再赘述。
电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的测试方法。
在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的测试方法。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备、存储介质和程序产品实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。
Claims (18)
1.一种测试系统，其特征在于，所述系统包括：代码管理节点、资源调度节点和至少两个docker compose节点；
所述资源调度节点，用于监测所述docker compose节点的状态，并根据监测结果，获取包含可用docker compose节点信息的可用节点列表；并向所述代码管理节点发送所述可用节点列表；
所述代码管理节点，用于对待测试项目的待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；并在接收到所述资源调度节点发送的所述可用节点列表时，按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所述可用节点列表中确定用于部署所生成代码文件的目标docker compose节点，并向所述目标docker compose节点发送所生成的代码文件；
所述docker compose节点，用于在接收到所述代码管理节点发送的代码文件时，将所接收的代码文件部署在指定的目录中；并获得待测试分支的运行环境的镜像文件，通过运行所获得的镜像文件生成测试容器，将所述指定的目录中部署的代码文件挂载在所述测试容器中，以对待测试分支进行测试。
2.如权利要求1所述的系统，其特征在于，所述获得待测试分支的运行环境的镜像文件，包括：
从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
3.如权利要求1所述的系统，其特征在于，
所述资源调度节点，还用于控制每一所述目标docker compose节点生成的各个测试容器的生命周期。
4.如权利要求1所述的系统，其特征在于，所述docker compose节点为：安装有dockercompose服务和docker compose管理器的宿主机；
其中，所述docker compose管理器中设置有与docker compose通信的web接口，所述docker compose管理器用于控制各个docker compose节点上的docker compose服务；
所述docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
5.如权利要求1～4中任一项所述的系统，其特征在于，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中之后，
所述docker compose节点，还用于执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件到本地私有库中，其中，所述Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
6.如权利要求5所述的系统，其特征在于，
所述资源调度节点，还用于修改所述Dockerfile文件；
所述docker compose节点，还用于根据修改后的所述Dockerfile文件编辑测试容器。
7.如权利要求6所述的系统，其特征在于，所述docker compose节点还包括：httpproxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。
8.一种测试方法，其特征在于，所述方法包括：
获得记录可用docker compose节点信息的可用节点列表；
按照一个docker compose节点上部署同一测试项目的一个测试分支的代码文件的方式，从所获得的可用节点列表中确定用于部署所生成代码文件的目标docker compose节点；
对待测试项目的每一待测试分支的测试代码进行打包处理，生成所述待测试分支的代码文件；
向所述目标docker compose节点发送所生成的代码文件；以使目标docker compose节点根据所述代码文件和待测试分支的运行环境的镜像文件对待测试分支进行测试。
9.如权利要求8所述的方法，其特征在于，所述方法还包括：
控制所述目标docker compose节点在对所述待测试分支进行测试过程中生成的测试容器的生命周期。
10.如权利要求8所述的方法，其特征在于，所述方法还包括：
对Dockerfile文件进行修改，以使得所述目标docker compose节点根据修改后的所述Dockerfile文件编辑测试容器，其中，所述Dockerfile文件为：用于生成所述镜像文件的配置文件。
11.一种测试方法，其特征在于，应用于docker compose节点，所述方法包括：
获得按照预设方式确定的待测试分支的代码文件，其中，所述预设方式为：一个dockercompose节点上部署同一测试项目的一个测试分支的代码文件；
将所接收的代码文件部署在指定的目录中；
获得待测试分支的运行环境的镜像文件；
运行所获得的镜像文件生成测试容器；
将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试。
12.如权利要求11所述的方法，其特征在于，所述获得待测试分支的运行环境的镜像文件，包括：
从本地私有仓库中拉取待测试分支的运行环境的镜像文件。
13.如权利要求11所述的方法，其特征在于，所述docker compose节点为：安装有docker compose服务和docker compose管理器的宿主机；
其中，所述docker compose管理器中设置有与docker compose通信的web接口，所述docker compose管理器用于控制各个docker compose节点上的docker compose服务；
所述docker compose服务用于控制自身所在的docker compose节点生成的各个测试容器的运行。
14.如权利要求11～13中任一项所述的方法，其特征在于，在所述将所述指定的目录中部署的代码文件挂载在所述测试容器中对待测试分支进行测试之后，还包括：执行以下操作中的至少一种：
监控自身生成的各个测试容器的资源消耗和运行状态；
管理自身目录中部署的代码文件；
管理测试过程中生成的日志文件；
在对待测试分支完成测试后，释放测试过程中占用的资源；
在对待测试分支完成测试后，将对待测试分支进行测试的测试容器进行打包处理，生成镜像文件，并将所生成的镜像文件提交到本地私有库中；
提交待测试分支所依赖的Dockerfile文件和Docke-compse.yml文件到本地私有库中，其中，所述Dockerfile文件为：用于生成待测试分支的运行环境的镜像文件的配置文件，所述Docke-compse.yml文件为：用于运行对待测试分支进行测试的测试环境的配置文件。
15.如权利要求14所述的方法，其特征在于，所述方法还包括：
获得修改后的所述Dockerfile文件，并根据修改后的所述Dockerfile文件编辑测试容器。
16.如权利要求15所述的方法，其特征在于，所述Docker compose节点还包括：httpproxy，用于将待测项目的流量一一对应导入至流量对应的各个待测分支中。
17.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
存储器，用于存放计算机程序；
处理器，用于执行存储器上所存放的程序时，实现权利要求8～10中任一所述的方法步骤。
18.一种电子设备，所述电子设备作为docker compose节点，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
存储器，用于存放计算机程序；
处理器，用于执行存储器上所存放的程序时，实现权利要求11～16中任一所述的方法步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811481607.0A CN109739744B (zh) | 2018-12-05 | 2018-12-05 | 一种测试系统及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811481607.0A CN109739744B (zh) | 2018-12-05 | 2018-12-05 | 一种测试系统及方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109739744A true CN109739744A (zh) | 2019-05-10 |
| CN109739744B CN109739744B (zh) | 2022-04-22 |
Family
ID=66359213
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811481607.0A Active CN109739744B (zh) | 2018-12-05 | 2018-12-05 | 一种测试系统及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109739744B (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110297647A (zh) * | 2019-05-29 | 2019-10-01 | 福建天泉教育科技有限公司 | 一种前端工程更新npm包的方法及终端 |
| CN110647469A (zh) * | 2019-09-24 | 2020-01-03 | 广州荔支网络技术有限公司 | 一种微服务的测试方法、装置、计算机设备和存储介质 |
| CN111104321A (zh) * | 2019-12-16 | 2020-05-05 | 烽火通信科技股份有限公司 | 一种基于docker的云平台稳定性测试方法及系统 |
| CN111464603A (zh) * | 2020-03-24 | 2020-07-28 | 聚好看科技股份有限公司 | 一种服务器扩容方法及扩容系统 |
| WO2020253079A1 (zh) * | 2019-06-17 | 2020-12-24 | 平安科技（深圳）有限公司 | 基于Jmeter的分布式性能测试方法、装置、设备及存储介质 |
| CN112199243A (zh) * | 2020-10-10 | 2021-01-08 | 中国建设银行股份有限公司 | 一种系统的检测方法、装置、设备及可读存储介质 |
| CN112242933A (zh) * | 2019-07-16 | 2021-01-19 | 贵州白山云科技股份有限公司 | 一种tcpcopy测试方法、装置、介质及设备 |
| CN112711522A (zh) * | 2019-10-24 | 2021-04-27 | 中国科学院深圳先进技术研究院 | 一种基于docker的云测试方法、系统及电子设备 |
| CN115484187A (zh) * | 2022-11-02 | 2022-12-16 | 江苏博云科技股份有限公司 | 容器环境下容器网络接口测试方法、设备及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106502905A (zh) * | 2016-10-26 | 2017-03-15 | 腾讯科技（深圳）有限公司 | 一种应用程序的测试方法、装置及系统 |
| CN106873975A (zh) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | 基于Docker的devops持续交付与自动化系统及方法 |
| CN108427641A (zh) * | 2018-01-29 | 2018-08-21 | 中国互联网络信息中心 | 一种基于Docker容器的多任务调度自动化测试方法及系统 |
| CN108763072A (zh) * | 2018-05-18 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种高效的自动化测试环境搭建方法 |
| US10146936B1 (en) * | 2015-11-12 | 2018-12-04 | EMC IP Holding Company LLC | Intrusion detection for storage resources provisioned to containers in multi-tenant environments |
-
2018
- 2018-12-05 CN CN201811481607.0A patent/CN109739744B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10146936B1 (en) * | 2015-11-12 | 2018-12-04 | EMC IP Holding Company LLC | Intrusion detection for storage resources provisioned to containers in multi-tenant environments |
| CN106502905A (zh) * | 2016-10-26 | 2017-03-15 | 腾讯科技（深圳）有限公司 | 一种应用程序的测试方法、装置及系统 |
| CN106873975A (zh) * | 2016-12-30 | 2017-06-20 | 武汉默联股份有限公司 | 基于Docker的devops持续交付与自动化系统及方法 |
| CN108427641A (zh) * | 2018-01-29 | 2018-08-21 | 中国互联网络信息中心 | 一种基于Docker容器的多任务调度自动化测试方法及系统 |
| CN108763072A (zh) * | 2018-05-18 | 2018-11-06 | 郑州云海信息技术有限公司 | 一种高效的自动化测试环境搭建方法 |
Non-Patent Citations (1)
| Title |
|---|
| 胡湘菲: "软件自动化测试环境搭建中的Docker应用", 《计算机时代》 * |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110297647A (zh) * | 2019-05-29 | 2019-10-01 | 福建天泉教育科技有限公司 | 一种前端工程更新npm包的方法及终端 |
| CN110297647B (zh) * | 2019-05-29 | 2023-12-01 | 福建天泉教育科技有限公司 | 一种前端工程更新npm包的方法及终端 |
| WO2020253079A1 (zh) * | 2019-06-17 | 2020-12-24 | 平安科技（深圳）有限公司 | 基于Jmeter的分布式性能测试方法、装置、设备及存储介质 |
| CN112242933A (zh) * | 2019-07-16 | 2021-01-19 | 贵州白山云科技股份有限公司 | 一种tcpcopy测试方法、装置、介质及设备 |
| CN110647469B (zh) * | 2019-09-24 | 2023-09-08 | 广州荔支网络技术有限公司 | 一种微服务的测试方法、装置、计算机设备和存储介质 |
| CN110647469A (zh) * | 2019-09-24 | 2020-01-03 | 广州荔支网络技术有限公司 | 一种微服务的测试方法、装置、计算机设备和存储介质 |
| CN112711522B (zh) * | 2019-10-24 | 2024-04-19 | 中国科学院深圳先进技术研究院 | 一种基于docker的云测试方法、系统及电子设备 |
| CN112711522A (zh) * | 2019-10-24 | 2021-04-27 | 中国科学院深圳先进技术研究院 | 一种基于docker的云测试方法、系统及电子设备 |
| CN111104321A (zh) * | 2019-12-16 | 2020-05-05 | 烽火通信科技股份有限公司 | 一种基于docker的云平台稳定性测试方法及系统 |
| CN111464603A (zh) * | 2020-03-24 | 2020-07-28 | 聚好看科技股份有限公司 | 一种服务器扩容方法及扩容系统 |
| CN111464603B (zh) * | 2020-03-24 | 2022-03-29 | 聚好看科技股份有限公司 | 一种服务器扩容方法及扩容系统 |
| CN112199243A (zh) * | 2020-10-10 | 2021-01-08 | 中国建设银行股份有限公司 | 一种系统的检测方法、装置、设备及可读存储介质 |
| CN115484187B (zh) * | 2022-11-02 | 2023-03-24 | 江苏博云科技股份有限公司 | 容器环境下容器网络接口测试方法、设备及存储介质 |
| CN115484187A (zh) * | 2022-11-02 | 2022-12-16 | 江苏博云科技股份有限公司 | 容器环境下容器网络接口测试方法、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109739744B (zh) | 2022-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109739744A (zh) | 一种测试系统及方法 | |
| CN109766269A (zh) | 持续集成自动化测试方法、装置、设备和介质 | |
| US7676806B2 (en) | Deployment, maintenance and configuration of complex hardware and software systems | |
| US9069901B2 (en) | Software and framework for reusable automated testing of computer software systems | |
| US20090007073A1 (en) | Service testing method and service testing system | |
| US20070074204A1 (en) | Upgrade and downgrade of data resource components | |
| CN112965700B (zh) | 基于路由的微服务处理方法、装置、计算机设备和介质 | |
| CN102279790A (zh) | 分布式调试方法和系统 | |
| CN109901985B (zh) | 分布式测试装置及方法、存储介质和电子设备 | |
| CN110515628A (zh) | 应用部署方法及装置 | |
| El-Hokayem et al. | THEMIS: a tool for decentralized monitoring algorithms | |
| CN111831567B (zh) | 应用的测试环境配置方法、装置、系统和介质 | |
| Li et al. | Microservice patterns for the life cycle of industrial edge software | |
| Hummer et al. | Testing of data‐centric and event‐based dynamic service compositions | |
| Iyenghar et al. | Towards model-based test automation for embedded systems using UML and UTP | |
| De Iasio et al. | A framework for microservices synchronization | |
| CN103176903B (zh) | MapReduce分布式系统程序的测试方法及设备 | |
| Nikolaidis et al. | Frisbee: automated testing of Cloud-native applications in Kubernetes | |
| US20120284695A1 (en) | Error simulation | |
| Leucker et al. | Runtime verification for interconnected medical devices | |
| Yabandeh et al. | Finding almost-invariants in distributed systems | |
| Daga et al. | Flame: Simplifying Topology Extension in Federated Learning | |
| Marinho et al. | Evaluating testing strategies for resource related failures in mobile applications | |
| CN109634650A (zh) | 管理配置文件的方法和装置，存储介质和电子设备 | |
| Schmieders et al. | Architectural runtime models for privacy checks of cloud applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240207 Address after: 200335 room 205, floor 2, building 9, No. 365, Linhong Road, Changning District, Shanghai Patentee after: Shanghai iqiyi New Media Technology Co.,Ltd. Country or region after: China Address before: 10 / F and 11 / F, Hongcheng development building, 2 Haidian North 1st Street, Haidian District, Beijing 100080 Patentee before: BEIJING QIYI CENTURY SCIENCE & TECHNOLOGY Co.,Ltd. Country or region before: China |
|
| TR01 | Transfer of patent right |