CN108733553A - 基于docker的测试装置的配置方法、装置和系统 - Google Patents

Abstract

本公开实施例提供一种基于docker的测试装置的配置方法、装置和系统，用于解决配置PC的繁琐和复杂限制了云测平台扩展PC机数量的速度的问题。该方法包括：接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；启动环境容器镜像和测试任务管理容器镜像分别获得环境容器和测试任务管理容器；运行测试设备识别脚本，使得测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应；本公开实施例提供的基于docker的测试装置的配置方法、装置和系统减少了测试主机的维护和部署复杂度，降低了测试主机的维护成本和横向扩展成本。

Description

基于docker的测试装置的配置方法、装置和系统

技术领域

本公开实施例涉及计算机技术，具体涉及一种基于docker的测试装置的配置方法、装置和系统。

背景技术

在对包括谷歌地图在内的应用程序app进行测试时，目前存在许多云测平台。例如，著名的百度移动云测试中心、Testin测试平台等，这些云测试平台均拥有大量的手机设备，以提供端上多种测试能力。使用这些平台，应用程序开发/测试人员在方便的选择被测机型、提交相应的测试任务后，即可获得多款手机的运行结果。这种便捷的测试方式为应用程序上线提供质量保证。

上述云测平台执行测试任务实际上是依赖于后台的计算机控制对应机型的手机设备完成的；被测试的应用程序通常都需要经过几百上千个测试项目，才能得出测试报告，而执行几百上千个测试项目所耗费的时间是很长的。为了避免测试的互相干扰，一台手机设备通常只能执行一个应用程序的测试任务。因此常常云测平台需要部署大量手机设备，而一台计算机能控制的手机数量是有限的，因增加计算机的数量非常有必要。

但是计算机上需要安装和配置大量的测试工具和软件，才能控制手机设备执行测试任务。而安装和配置上述测试工具和软件，需要开发人员消耗大量的时间，这不利于云测平台扩展其计算机数量。

而由于安装配置的繁琐和复杂，容易导致安装配置过程出错，配置出错容易导致在该计算机上无法运行测试任务，或导致执行测试任务获得的测试结果是错误的，从而该计算机在“配置好”后仍然无法上线接收测试任务。

因此配置计算机的繁琐和复杂限制计算机扩展计算机数量的速度。

发明内容

鉴于上述问题：

第一方面，本公开实施例提供一种基于docker的测试装置的配置方法，包括：

接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；

启动环境容器镜像和测试任务管理容器镜像分别获得环境容器和测试任务管理容器；

运行测试设备识别脚本，使得测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应。

第二方面，本公开实施例提供一种基于docker的测试装置的配置装置，其中包括：

接收模块，用于接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；

启动模块，用于启动环境容器镜像和测试任务管理容器镜像分别获得环境容器和测试任务管理容器；

运行模块，用于运行测试设备识别脚本，使得测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应。

第三方面，本公开实施例提供一种基于docker的测试装置的配置系统，包括如上所述任一测试装置，还包括工程仓库，所述工程仓库用于存储测试任务相关的配置文件、数据和/或程序。

在上述测试装置中，除了测试设备识别脚本部分，其他均可封装为镜像，并上传至测试工程仓库或docker仓库中，而需要在另一个物理或虚拟的PC机B上搭建上述测试环境时，则可通过上述配置方法的步骤搭建出一样的测试环境，从而避免了在PC机B上重复安装和配置大量的测试工具和软件的步骤、消耗过多的时间和避免出错。而测试环境修改升级时，只需要一台PC机上传修改后的镜像、其他PC机上拉取最新镜像、重启其他PC机这三个步骤即可快速的修改所有PC机的测试环境，减少了测试设备的维护和部署复杂度，降低了测试设备的维护成本和横向扩展成本。

前面是提供对本公开实施例一些方面的理解的简要发明内容。这个部分既不是本公开实施例及其各种实施例的详尽表述也不是穷举的表述。它既不用于识别本公开实施例的重要或关键特征也不限定本公开实施例的范围，而是以一种简化形式给出本公开实施例的所选原理，作为对下面给出的更具体的描述的简介。应当理解，单独地或者组合地利用上面阐述或下面具体描述的一个或多个特征，本公开实施例的其它实施例也是可能的。

附图说明

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

图1为本公开实施例的一个基于docker的系统的结构示意图，该系统中包括测试设备；

图2为本公开实施例的一个实施例中的配置方法的流程图。

具体实施方式

为使本公开实施例实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例实施例中的附图，对本公开实施例实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开实施例一部分实施例，而不是全部的实施例。基于本公开实施例中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开实施例保护的范围。

为了便于理解本公开实施例的技术方案，以下对本文中出现的术语进行解释：

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

Jenkins是基于Java开发的一种持续集成工具，用于监控持续重复的工作，功能包括：持续的软件版本发布/测试项目，以及监控外部调用执行的工作。

Appium是一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Node.js是一个基于Chrome V8引擎的JavaScript运行环境。

supervisor是由python语言编写、基于linux操作系统的一款服务器管理工具，用以监控服务器的运行，发现问题能立即自动预警及自动重启等功能。

以下，请结合图和文字说明理解本公开实施例的实施方式和目的。

参见图2，在配置测试装置时采用的方法包括步骤：

S101、接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；

S102、启动环境容器镜像和测试任务管理容器镜像获得环境容器、测试任务管理容器；

S103、运行测试设备识别脚本，使测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应；

触发接收环境容器镜像的可以是在测试装置上运行dock pull指令，dock pull指令从对应的工程仓库或docker仓库中下载镜像。优选的所述环境容器501中的SDK以持久化状态存储，测试装置上的其他容器可访问该SDK；

测试设备识别脚本可以是一个USB监听脚本。例如在一个实施例中，测试设备的自动识别由USB_detect脚本实现，其用于自动识别测试设备的挂载，例如对于android系统的测试设备，其挂载/移除的主要流程如下：

1)通过linux命令find/dev/bus/USB-type c获得当前所有USB设备文件。

2)通过linux命令udevadm info-q property–n device_file，获得USB设备的属性(例如：BUSNUM/DEVNUM/ID_SERIAL_SHORT/ID_VENDOR)。

3)判断是否有Android手机插入或移除；ID_SERIAL_SHORT是USB设备的唯一标识，也是Android手机的序列号，通过该序列号判断是否有Android手机插入或移除。

4)手机插入时，执行docker run创建worker容器。容器创建时使用device参数将设备文件传递给容器，这样容器内只存在单一手机设备，使得在测试装置中多个手机环境独立，互补干扰。

5)手机移除时，执行docker rm删除容器，同时对应的Jenkins slave也被删除。

区别与现有技术，上述测试装置中除了测试设备识别脚本部分，其他均可封装为镜像，并将脚本和镜像们上传至测试工程仓库或docker仓库中。而需要在另一个物理或虚拟的PC机B上搭建上述测试环境时，则可通过上述配置方法的步骤搭建出一样的测试环境，从而避免了在PC机B上重复安装和配置大量的测试工具和软件的步骤，从而避免消耗过多的时间和避免出错。而测试环境修改升级时，只需要一台PC机上传修改后的镜像、其他PC机上拉取最新镜像、重启其他PC机这三个步骤即可快速的修改所有PC机的测试环境，减少了测试设备的维护和部署复杂度，降低了测试设备的维护成本和横向扩展成本。

图1所示，为本公开实施例的一个实施例中云测平台的结构示意图。其中用户通过网页访问测试服务器530，并发送测试任务请求，测试任务请求包括待测app、测试设备的机型、测试的其他要求等。测试服务器530发送测试任务请求或测试任务至测试装置50，测试装置50控制测试设备510对待测app进行测试，并获得测试结果。

可以理解的是，图1中只列出了一个测试装置(可理解为一个电脑主机)和一个测试设备(可理解为手机)，但是在一个云测平台中，是可以存在多个测试装置，每个测试装置下挂载有多个测试设备。图1即是云测平台的结构图。

其中，环境容器用于为测试任务管理容器和/或测试设备容器提供所需的SDK中的数据和程序，所述SDK与测试设备的操作系统对应；

测试任务管理容器用于运行测试执行引擎，测试执行引擎用于通过测试执行引擎的执行节点控制测试设备容器执行测试任务；

测试设备容器用于通过测试执行引擎的执行节点接收测试执行引擎的测试任务，控制测试设备执行测试任务，获得测试结果。

其中测试装置包括环境容器模块、测试任务管理容器模块、测试设备容器模块和测试设备拔插监听模块；

所述测试任务管理容器502中的测试执行引擎和所述设备测试容器504中的测试执行引擎的执行节点对应；例如是Jenkins和Jenkins-swarm。设备测试容器504也可以称为worker(一个docker中的术语)，worker与测试手机是一对一的关系，它的作用是将每一台手机封为一个独立的执行单元，使在测试过程中不存在手机之间的USB端口冲突等环境依赖问题。

工程仓库520可以是基于git实现的，git是一种代码仓库构建技术，实现上述技术的对应工具也称为git。

可以理解的是测试装置50、测试服务器530、和工程仓库520可以是在一个硬件设备中，即某一硬件设备即作为测试装置，而且该测试装置上还安装有测试服务器的相关代码或处理逻辑，以及还部署有工程仓库。但也可以理解的是上述容器、仓库也可以是分散部署在多个主机或服务器中。任务管理容器、环境容器可以是在一个docker容器中。

在本公开实施例的一个实施例中，通过下述生成步骤，生成初始的环境容器镜像、测试任务管理容器镜像和测试设备容器镜像。即配置方法还包括：

执行生成环境容器的步骤、执行生成测试任务管理容器的步骤和执行生成测试设备容器的步骤；

将所述环境容器、测试任务管理容器、测试设备容器分别制作为镜像；

发送环境容器镜像、测试任务管理容器镜像、和测试设备容器的镜像至容器仓库中；

其中：

执行生成环境容器的步骤包括：创建一个docker容器作为环境容器，环境容器接收软件开发工具包SDK，所述SDK与测试设备的操作系统对应，所述SDK用于提供测试任务管理容器所需的数据和程序；

执行生成测试任务管理容器的步骤包括：创建一个docker容器作为测试任务管理容器，在测试任务管理容器中运行测试执行引擎的安装指令，根据测试设备的注册方式执行配置测试执行引擎和/或配置测试任务管理容器的指令；

执行生成测试设备容器的步骤包括：创建一个docker容器作为测试设备容器，设置测试设备容器具有访问在环境容器中的SDK的数据和程序的权限；在测试设备容器中运行测试执行引擎的执行节点的安装指令；测试执行引擎的执行节点用于接收测试执行引擎的数据和指令，根据接收到的数据和指令在测试设备中执行测试任务和生成测试结果数据。

在一些实施例中，所述的测试执行引擎为Jenkins；Jenkins为测试执行的引擎，其负责管理各种测试任务和测试任务的执行。在任务管理容器中已开放Jenkins的slave(从设备)注册端口；所述测试执行引擎的执行节点包括Jenkins-swarm；启动Jenkins-swarm，该设备测试容器向测试执行引擎注册为slave。

例如开放50000端口用于slave注册；启动Jenkins-swarm，该设备测试容器向测试执行引擎注册为slave。

上述实施例中，通过Jenkins管理测试任务，简化对测试过程的管理，即其简化了对测试任务的调度和对测试设备的管理。

在一些实施例中的任务管理容器中还包括安装环境变量设置插件、slave动态注册插件。其中slave注册插件用于手机插入时动态注册为Jenkins的slave，进一步简化了对测试设备的管理。

在一些实施例中，测试执行引擎被配置为在启动测试之前先从代码仓库中拉取测试任务的配置文件。在以Jenkins作为测试执行引擎的实施例中，可以通过修改Jenkins.sh，使得Jenkins启动之前先从测试工程仓库中拉取各测试任务的配置文件。这样一个Jenkins的配置有变化，只需提交到测试工程参考上，其它测试主机中的Jenkins在启动时自动更新上述测试任务的配置文件。工程仓库可以是根据git部署的。

上述技术方案中，在工程项目对于测试任务更新时，方便各测试装置同时对测试任务的进行修改和升级。

同样在测试任务的程序和测试数据更新时，也可以通过上述方法，使其他测试装置快速的使用最新的测试程序和测试数据。

测试设备容器中可以安装supervisor、Jenkins-swarm、node.js、appium等测试执行引擎的执行节点，除此之外还可以保存有adbkey.exe，用于手机测试时测试装置和测试设备之间连接的授权，或还保存有sshkey.exe，sshkey.exe用于从其他git仓库中拉取测试过程中所需的代码/数据；以及保存有编译运行时需要的java/gradle/maven环境。所述USB监听模块504中设置有USB端口事件监听机制，用于在监听到挂载上USB设备时，判断USB设备的属性是否满足预设条件，若满足预设条件，则为该USB设备创建对应的设备测试容器。

在另一些实施例中，还包括结果查看容器，所述结果查看容器中包括http请求处理工具，http请求处理工具用于根据处理结果查看请求，提供对应的测试结果文件。在一些实施例中，结果查看容器中的http请求处理工具为Nginx；Nginx的网页文件的目录被设置为linux系统中的一个目录，例如/home/share/；设备测试容器中的测试结果实时同步到/home/share下。

结果查看容器用于提供一种测试结果查看的方式，其将测试结果持久化，并开放http接口供外部访问，从而在方便测试结果的查看。

在一些实施例中，所述SDK为android SDK；android SDK是开发/调试/测试Android不可或缺的工具。将android SDK通过docker提供的共享方式共享给该测试装置中的设备测试容器，使得测试设备(如android手机、平板)均能访问该的SDK中的程序和软件。

例如SDK以docker的voloume或voloume-from的方式共享给其他容器，这样每个设备测试容器即可访问SDK，而不需要对应的另外部署SDK。

本文还提供上述配置方法生成的测试装置，测试装置中包括环境容器模块、测试任务管理容器模块、测试设备容器模块和测试设备拔插监听模块；

所述环境容器模块中包括环境容器，环境容器中包括SDK，所述SDK与待测设备的操作系统对应，所述环境容器用于为测试任务管理容器和/或测试设备容器提供所需的SDK中的数据和程序；

所述测试任务管理容器模块包括测试任务管理容器，所述测试任务管理容器模块用于运行测试执行引擎，测试执行引擎用于控制测试设备容器执行测试任务；

所述测试设备容器模块包括测试设备容器，用于从接收测试执行引擎的测试任务，控制测试设备执行测试任务，获得测试结果。

所述测试设备拔插监听模块用于监听测试设备的添加或移除事件，用于使添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器。

在一些实施例中，所述测试执行引擎为Jenkins，所述测试执行引擎的执行节点为Jenkins-swarm。

在一些实施例中，所述测试任务管理容器用于自动获取测试任务所对应的最新的配置文件或获取最新的测试任务所需的数据和程序。

在一些实施例中，所述测试设备容器中包括Appium、Node.js、supervisor中的一种或多种工具。

在一些实施例中，测试任务管理容器中至少包括以下一种插件：Jenkins动态注册插件、环境变量设置插件。

Jenkins动态注册插件用于根据测试设备的拔插事件，在jenkins中将插入/移除的设备测试动态的注册/注销；

环境变量设置插件用于根据测试任务设置测试任务管理器的环境变量。

在一些实施例中，包括结果查看容器，所述结果查看容器包Nginx，用于根据处理结果查看请求和结果查看请求处理逻辑，向发出处理结果查看请求的请求设备返回对应的测试结果数据。

本文还提供基于docker的测试系统包括上述的任一测试装置，还包括工程仓库，所述工程仓库用于存储测试任务的配置文件或测试任务所需的数据和程序；用于在测试装置执行测试任务前，向其发送最新的测试任务的配置文件或最新的测试任务所需的数据和程序。

在一些实施例中，包括测试服务器，测试服务器用于接收测试任务请求，根据测试任务请求选择对应的测试装置执行测试任务，返回测试任务的执行结果。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。而且，在没有更多限制的情况下，由语句“包括……”或“包含……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的要素。

尽管已经对上述各实施例进行了描述，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改，所以以上所述仅为本公开实施例的实施例，并非因此限制本公开实施例的专利保护范围，凡是利用本公开实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本公开实施例的专利保护范围之内。

Claims (19)

1.一种基于docker的测试装置的配置方法，其特征在于，包括：

接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；

启动环境容器镜像和测试任务管理容器镜像分别获得环境容器和测试任务管理容器；

运行测试设备识别脚本，使得测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应。

2.根据权利要求1所述的方法，其特征在于：

其中，所述环境容器用于为测试任务管理容器提供所需的软件开发工具包SDK中的数据和程序，所述SDK与测试设备的操作系统对应；所述测试任务管理容器用于运行测试执行引擎，测试执行引擎用于通过测试执行引擎的执行节点控制测试设备容器执行测试任务；所述测试设备容器用于通过测试执行引擎的执行节点接收测试执行引擎的测试任务，控制测试设备执行测试任务，获得测试结果。

3.根据权利要求2所述的方法，其特征在于，所述测试执行引擎为Jenkins，所述测试执行引擎的执行节点为Jenkins-swarm。

4.根据权利要求2所述的方法，其特征在于，在所述接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本之前，还包括：

执行生成环境容器的步骤、执行生成测试任务管理容器的步骤和执行生成测试设备容器的步骤；

将所述环境容器、测试任务管理容器、测试设备容器分别制作为镜像；

发送环境容器镜像、测试任务管理容器镜像和测试设备容器的镜像。

5.根据权利要求4所述的方法，其特征在于，执行生成环境容器的步骤包括：创建一个docker容器作为环境容器，环境容器接收SDK，接收配置SDK运行环境的指令；

执行生成测试任务管理容器的步骤包括：创建一个docker容器作为测试任务管理容器，在测试任务管理容器中运行测试执行引擎的安装指令，根据测试设备的注册方式执行配置测试执行引擎的指令；

执行生成测试设备容器的步骤包括：创建一个docker容器作为测试设备容器，设置测试设备容器具有访问在环境容器中的SDK的数据和程序的权限；在测试设备容器中运行测试执行引擎的执行节点的安装指令；测试执行引擎的执行节点用于接收测试执行引擎的数据和指令，根据接收到的数据和指令在测试设备中执行测试任务和生成测试结果数据。

6.根据权利要求5所述的方法，其特征在于，所述在测试任务管理容器中运行测试执行引擎的安装指令，根据测试设备的注册方式执行配置测试执行引擎的指令包括：

在测试任务管理容器中，根据测试设备的注册端口，执行配置测试设备管理容器的指令用以开放测试执行引擎的对应端口；

所述在测试设备容器中运行测试执行引擎的执行节点的安装指令的步骤包括：测试设备容器中执行安装可增加所述测试执行引擎的执行节点的指令。

7.根据权利要求6所述的方法，其特征在于，还包括：

在测试执行引擎的脚本文件中添加第一指令，第一指令用于在执行测试任务之前，从任务配置仓库中获得测试任务的配置文件或测试任务所需的数据和程序。

8.根据权利要求6所述的方法，其特征在于，所述运行测试执行引擎的安装指令还包括：

执行安装以下一种或多种插件的指令：所述测试执行引擎的动态注册插件和测试执行引擎的环境变量设置插件。

9.根据权利要求4所述的方法，其特征在于，还包括执行生成结果查看器的步骤，其包括：

执行安装网页服务工具的指令，

执行配置网页服务工具的指令，使其具有访问生成测试结果数据的权限；

所述网页服务工具用于根据处理结果查看请求和结果查看请求处理逻辑，向发出处理结果查看请求的请求设备返回对应的测试结果数据。

10.根据权利要求9所述的方法，其特征在于，所述网页服务工具为Nginx。

11.根据权利要求1所述的方法，其特征在于，包括接收结果查看器镜像，启动结果查看器镜像；

所述结果查看器包括网页服务工具，所述访问服务工具用于根据处理结果查看请求和结果查看请求处理逻辑，向发出处理结果查看请求的请求设备返回对应的测试结果数据。

12.根据权利要求11所述方法，其特征在于，所述网页服务工具为Ngnix。

13.一种基于docker的测试装置的配置装置，其特征在于，其中包括：

接收模块，用于接收环境容器镜像、测试任务管理容器镜像和测试设备容器镜像，以及接收测试设备识别脚本；

启动模块，用于启动环境容器镜像和测试任务管理容器镜像分别获得环境容器和测试任务管理容器；

运行模块，用于运行测试设备识别脚本，使得测试设备的添加或移除事件触发添加或删除所述测试设备所唯一对应的测试设备容器，其中添加的测试设备容器与接收的测试设备容器镜像对应。

14.根据权利要求13所述的装置，其特征在于，

其中，所述环境容器中包括SDK，所述SDK与待测设备的操作系统对应，所述环境容器用于为测试任务管理容器和/或测试设备容器提供所需的SDK中的数据和程序；

所述测试任务管理容器用于运行测试的测试执行引擎，测试执行引擎用于通过测试执行引擎的执行节点控制测试设备容器执行测试任务；

所述测试设备容器，用于通过测试执行引擎的执行节点接收测试执行引擎的测试任务，控制测试设备执行测试任务，获得测试结果。

15.根据权利要求14所述的装置，其特征在于，所述测试执行引擎为Jenkins，所述测试执行引擎的执行节点为Jenkins-swarm。

16.根据权利要求14所述的装置，其特征在于，所述测试任务管理容器用于自动获取测试任务所对应的最新的配置文件或获取最新的测试任务所需的数据和程序。

17.根据权利要求14所述的装置，其特征在于，测试任务管理容器中至少包括以下一种插件：所述测试执行引擎的动态注册插件和所述测试执行引擎的环境变量设置插件。

所述测试执行引擎的动态注册插件用于根据测试设备的拔插事件，在所述测试执行引擎中将插入/移除的设备测试动态的注册/注销；

环境变量设置插件用于根据测试任务设置测试任务管理器的环境变量。

18.根据权利要求13所述的装置，其特征在于，包括结果查看容器，所述结果查看容器包Nginx，用于根据处理结果查看请求和结果查看请求处理逻辑，向发出处理结果查看请求的请求设备返回对应的测试结果数据。

19.一种基于docker的测试装置的配置系统，其特征在于，包括如权利要求13-18所述的任一测试装置，还包括工程仓库，所述工程仓库用于存储测试任务相关的配置文件、数据和/或程序。