CN117632766A - 测试环境的配置方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请涉及计算机技术领域，提供一种测试环境的配置方法、装置、电子设备和存储介质，该方法包括：在接收到测试环境配置请求的情况下，获取测试环境的配置文件；判断配置文件中是否包括区别于第一配置文件的第二配置文件，其中，第一配置文件是测试环境首次进行配置时所使用的配置文件，第一配置文件包括第一配置信息和第二配置信息，第二配置文件由第一配置信息进行更新后得到，第二配置信息是指测试环境中不进行更新的配置信息；在配置文件包括第二配置文件的情况下，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境。本申请的技术方案实现了减少配置文件内容冗余，提高测试环境的配置效率。

Description

测试环境的配置方法、装置、电子设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种测试环境的配置方法、装置、电子设备和存储介质。

背景技术

机器人框架(Robot Framework)是一个开源的自动化测试框架，专注于易用性和可扩展性，广泛用于自动化测试和自动化验收测试(acceptance test-drivendevelopment，ATDD)。它采用简单的关键字驱动方法来编写测试用例，支持多种编程语言和应用领域。对于Robot Framework在测试框架搭建好之后，需要把实际环境中各设备上大量数据作为配置参数传递给Robot Framework，以模拟测试环境。

在相关技术中，用户手动将配置参数写在配置文件中，将配置文件传输给RobotFramework，利用配置文件中的配置参数对Robot Framework进行测试环境的配置。在实际环境中的设备数据发生变化时，为了使Robot Framework能够匹配更新后的设备数据，需要对原有配置文件进行手动修改，但是在某些特殊情况下，原有配置文件是有用的，因此，需要对原有配置文件进行备份之后，再对原有配置文件进行手动修改。

但是修改后的配置文件和备份配置文件中有一部分配置信息是相同的，导致文件内容冗余，降低测试环境的配置效率，并且人工手动修改也增加了引入错误的概率，同时，人工手动修改效率低下。

发明内容

为了解决上述技术问题，本申请提供了一种测试环境的配置方法、装置、电子设备和存储介质，减少配置文件内容冗余，提高测试环境的配置效率。

第一方面，本申请实施例提供了一种测试环境的配置方法，包括：在接收到测试环境配置请求的情况下，获取测试环境的配置文件；在配置文件包括第一配置文件和第二配置文件的情况下，基于第一配置文件中的第一配置信息和第二配置文件配置测试环境；其中，第一配置信息是指测试环境中不进行更新的配置信息，第二配置文件由第一配置文件中的第二配置信息进行更新后得到。

第二方面，本申请实施例提供一种测试环境的配置装置，包括：配置文件获取模块，用于在接收到测试环境配置请求的情况下，获取测试环境的配置文件；测试环境配置模块，用于在配置文件包括第一配置文件和第二配置文件的情况下，基于第一配置文件中的第一配置信息和第二配置文件配置测试环境；其中，第一配置信息是指测试环境中不进行更新的配置信息，第二配置文件由第一配置文件中的第二配置信息进行更新后得到。

第三方面，本申请实施例提供一种电子设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现第一方面中任一项方法的步骤。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，计算机程序被处理器执行时实现第一方面中任一项的方法的步骤。

第五方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机程序或指令，该计算机程序或指令被处理器执行时实现如上述第一方面中任一项方法的步骤。

本申请实施例提供的技术方案与现有技术相比具有如下优点：

本申请实施例提供的测试环境的配置方法、装置、设备和存储介质，首先，在接收到测试环境配置请求的情况下，获取测试环境的配置文件；然后，判断配置文件中是否包括区别于第一配置文件的第二配置文件，其中，第一配置文件是测试环境首次进行配置时所使用的配置文件，第一配置文件包括第一配置信息和第二配置信息，第二配置文件由第一配置信息进行更新后得到，第二配置信息是指测试环境中不进行更新的配置信息；最后，在配置文件包括第二配置文件的情况下，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境。由于第二配置文件是基于第一配置文件的第一配置信息生成的，并不包括第一配置文件并不需要更新的配置信息，因此，第二配置文件与第一配置文件中不存在相同的配置信息，实现了减少配置文件内容冗余，提高测试环境的配置效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1是本申请实施例提供的测试环境的配置方法的应用场景示意图；

图2是本申请实施例提供的一种测试环境的配置方法的流程图；

图3是本申请实施提供的一种第二配置信息的结构示意图；

图4是本申请实施提供的一种第一配置信息的结构示意图；

图5是本申请实施例提供的一种配置信息引入Robot Framework的流程示意图；

图6是本申请实施例提供的一种第二配置文件更新的方法流程图；

图7是本申请实施例提供的另一种第二配置文件更新的方法流程图；

图8是本申请实施例提供的一种测试环境的配置装置的结构示意图；

图9是本申请实施例提供的一种测试环境的配置设备的结构示意图。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面将对本申请的方案进行进一步描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本申请，但本申请还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本申请的一部分实施例，而不是全部的实施例。

下面结合附图对本申请实施例提供的测试环境的配置方法、装置、设备和存储介质进行详细介绍。

图1是本申请实施例提供的测试环境的配置方法的应用场景示意图。需要注意的是，图1所示仅为可以应用本申请实施例的应用场景的示例，以帮助本领域技术人员理解本申请的技术内容，但并不意味着本申请实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该实施例的应用场景100可以包括多个用户终端110、网络120、服务器130以及数据库140。例如，该应用场景100可以适用于实施本申请任一实施例所述的测试环境的配置方法。

终端设备110可以是包括显示屏器且安装有各种客户端应用的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等。该终端设备110例如可以安装有测试环境搭建应用、应用发布平台、即时通信类应用等。

示例性地，该终端设备110安装的测试环境搭建应用例如可以提供有人机交互界面。用户通过该人机交互界面可以提交测试环境配置请求。在一实施例中，用户还可以通过该人机交互界面选择测试类型，测试类型例如可以包括性能测试、功能测试、回装测试等。

根据本申请的实施例，该应用场景中例如还可以包括与终端设备110通信连接，且能够响应于终端设备110发送的配置请求进行测试环境配置的服务器。

可以理解的是，本申请实施例的应用的测试环境配置方法可以由终端设备110执行，或由与该终端设备110通信连接的服务器130执行。相应的，本申请实施例的应用的测试环境配置装置可以设置于终端设备110中，或设置于与终端设备110通信连接的服务器130中。

网络120可以是单个网络，或至少两个不同网络的组合。例如，网络120可以包括但不限于局域网、广域网、公用网络、专用网络等中的一种或几种的组合。网络120可以是诸如因特网的计算机网络和/或各种电信网络(例如3G/4G/5G移动通信网、W IFI、蓝牙、ZigBee等)，本申请的实施例对此不作限制。

服务器130可以是一个单独的服务器，或一个服务器群组，或云服务器，服务器群组内的各个服务器通过有线的或无线的网络进行连接。一个服务器群组可以是集中式的，例如数据中心，也可以是分布式的。服务器130可以是本地的或远程的。服务器130可以通过有线的或无线的网络与用户终端110进行通信。本申请的实施例对于服务器130的硬件系统以及软件系统不作限制。

数据库140可以泛指具有存储功能的设备。数据库140主要用于存储用户终端110和服务器130在工作中所利用、产生和输出的各种数据。例如，配置测试环境所需的第一配置文件、第二配置文件，再如：测试环境配置或者运行所需的脚本文件等等。

数据库140可以是本地的或远程的。数据库140可以包括各种存储器、例如随机存取存储器(Random Access Memory,RAM)、只读存储器(Read Only Memory,ROM)等。以上提及的存储设备只是列举了一些例子，该系统100可以使用的存储设备并不局限于此。本申请的实施例对于数据库140的硬件系统以及软件系统不作限制，例如，可以是关系型数据库或非关系型数据库。

数据库140可以经由网络120与服务器130或其一部分相互连接或通信，或直接与服务器130相互连接或通信，或是上述两种方式的结合。

在一些示例中，数据库140可以是独立的设备。在另一些示例中，数据库140也可以集成在用户终端110和服务器130中的至少一个中。例如，数据库140可以设置在用户终端110上，也可以设置在服务器130上。又例如，数据库140也可以是分布式的，其一部分设置在用户终端110上，另一部分设置在服务器130上。

图2为本申请实施例中的一种测试环境的配置方法的流程图，本实施例可适用于对测试环境中的设备参数进行配置的情况，该方法可以由测试环境的配置装置执行，该测试环境的配置装置可以采用软件和/或硬件的方式实现，该测试环境的配置方法可由图1中所述的用户终端110或者服务器130执行。

如图2所示，本申请实施例提供的测试环境的配置方法主要包括步骤S101-S103。

S101、在接收到测试环境配置请求的情况下，获取测试环境的配置文件。

测试环境配置请求可以为响应于用户对终端设备110展示的交互界面中的配置请求提交控件的操作而生成的。测试环境的配置文件可以是一个测试用例的配置文件，也可以是多个测试用例的配置文件，配置文件中包括配置信息，该配置信息包括配置项和配置项对应的参数值，该配置信息用于对测试环境进行描述，该配置信息采集于实际测试环境，将配置信息传送给测试架构，让测试架构知道如何在测试环境中执行相应的脚本。

用户可以对终端设备110中展示的交互界面进行操作，生成测试环境配置请求，响应于测试环境配置请求的生成操作，终端设备110接收测试环境配置请求。终端设备110接收到测试环境配置请求后，可以由终端设备110执行本申请实施例提供的测试环境的配置方法。或者，终端设备110接收到测试环境配置请求后，可以由终端设备110将测试环境配置请求发送至服务器130，由服务器130执行本申请实施例提供的测试环境的配置方法。

对测试环境中的至少一个测试用例进行校验，在测试用例校验通过的情况下，运行该测试用例对应的测试脚本，并读取该测试脚本对应的配置文件。

上述配置文件可以是yaml(YAML Ain't Markup Language)格式的配置文件，以下描述中yaml配置文件均是指是yaml格式的配置文件。yaml格式是一种人类可读的数据序列化格式，通常用于配置文件和数据交换。yaml格式的语法简洁、清晰，强调易读性，采用缩进来表示数据的层次结构，因此在人类和计算机之间具有良好的互操作性。

S102、判断配置文件中是否包括区别于第一配置文件的第二配置文件，其中，第一配置文件是测试环境首次进行配置时所使用的配置文件，第一配置文件包括第一配置信息和第二配置信息，第二配置文件由第一配置信息进行更新后得到，第二配置信息是指测试环境中不进行更新的配置信息。

第一配置文件与第二配置文件中配置信息不同。具体的，第一配置文件是针对Robot Framework框架最原始的配置文件，换句话说，第一配置文件是对Robot Framework框架首次进行测试环境配置所使用的配置文件。第一配置文件中的配置信息可以分为2大类，分别为第一配置信息以及第二配置信息。

第二配置信息可以理解为Robot Framework框架中不跟随实际环境中设备数据更新而进行变化的配置信息。图3是本申请实施提供的一种第二配置信息的结构示意图；在图3所示的第二配置信息以yaml格式记录。图3所示的第二配置信息是一个信息类，例如：DNA信息为例，DNA信息(dna_value)包括常规信息(common_value)，常规信息(common_value)中包括三部分内容：路径信息(path)、测试接口信息(test_port)和测试最大传输单元(test_mtu)信息。其中，路径信息中包括测试脚本地址(test_script)，测试脚本地址是”/home/autotest/testscript/k2pro/”。其中，在测试接口中主要包括8个测试接口的信息，分别是：传输控制协议服务端接口(tcp_server_port)是“55”接口，传输控制协议客户端接口(tcp_client_port)是“55”接口，传输控制协议用户服务端接口(tcp_server_user_port)是“888”接口,传输控制协议用户客户端接口(tcp_client_user_port)是“888”接口，用户数据报协议服务端接口(udp_server_port)是“77”接口，用户数据报协议客户端接口(udp_client_port)是“77”接口，用户数据报协议用户服务端接口(udp_server_user_port)是“7777”接口,用户数据报协议用户客户端接口(udp_client_user_port)是7777”接口。其中，test_mtu中包括test_mtu是1300。

如图3所示的第一配置文件中的第二配置信息，例如：测试脚本路径、测试接口以及测试mtu，这个配置项的参数值一般都是固定不变的，不会跟随实际环境中的设备数据更新而变更。进一步的，第二配置信息是不会出现在第二配置文件中的，换句话说，第二配置文件中不包括第二配置信息，也可以理解为第二配置文件中不包括不会跟随实际环境中的设备数据更新而变更的配置信息。

第一配置信息可以理解为Robot Framework框架中跟随实际环境中设备更新而进行变化的配置信息。图4是本申请实施提供的一种第一配置信息的结构示意图；在图4所示的第一配置信息以yaml格式记录。图4中包括常规信息(common_value)和设备信息(dev_info)两部分，常规信息(common_value)中包括：路径信息(path)，路径信息中包括数据路径(data_path)，数据路径是”/home/autotest/”。

设备信息(dev_info)中包括2个设备的信息，分别为设备1(switch_0)的配置信息和设备2(dev_0)的配置信息。其中，switch_0的配置信息包括设备类型(type)、设备主机地址(switch_host)，设备用户名称(switch_user)和设备登录密码(switch_password)。设备类型、设备主机地址，设备用户名称和设备登录密码，均可以称为第一配置项。其中，设备类型是“hw”，设备主机地址是“192.168.22.43”，设备用户名称是“huawei02”，设备登录密码是“1234qwer！@#$QWER”。“hw”，“192.168.22.43”，“huawei02”“1234qwer！@#$QWER”是第一配置项分别对应的第一参数值。

进一步的，dev_0的配置信息包括：设备管理信息(dev_mgt_info)以及设备接口信息(nic_0)。其中，设备管理信息包括设备IP地址(ip)是“192.168.22.8”、设备接口(port)是“22”、设备用户名称(username)是“root”、设备登录密码(password)是“Yusur_auto123”。采集的数据协议(protocol)是“SSH”，设备类型(type)是“centos DUT”，其表示该设备的操作系统为linux系统。设备接口信息(nic_0)中包括设备接口管理信息(nic_info)、第一接口信息(int_0)和第二接口信息(int_1)。其中，设备接口管理信息(nic_info)包括接口类型是“82599”，总线信息(pcie_bus)是[“06:00:0”，“06:00:1”]；第一接口信息(int_0)包括接口媒体访问控制地址(mac)是“00:1b:21:c3:be:3c”，接口名称(name)是“enp6s0f0”，接口IP地址(ip)是“12.168.23.40”，接口的网关IP地址(ip_gw)是“None”，None表示缺省。Sw是“None”。互联网协议第6版(ipv6)的地址是“fe80::57ce:28a5:6a5e:ccda”。第二接口信息(int_1)包括接口媒体访问控制地址(mac)是“None”，接口名称(name)是“None”，接口IP地址(ip)是“194.168.22.40”，接口的网关IP地址(ip_gw)是“None”，None表示缺省。Sw是“None”。互联网协议第6版(ipv6)的地址是“None”。

由上述图4可知，第一配置信息中包括多个第一配置项，每个第一配置项有其对应的第一参数值。针对第一配置文件中的多个第一配置信息，在实际环境中的设备数据进行变更时，获取更新后的设备数据，基于更新后的设备数据替换第一配置项对应的参数值，得到第二配置文件。

第二配置文件是一个区别于第一配置文件而独立存在的配置文件。在第二配置文件中仅仅包括会跟随设备的更新而进行变化的配置信息，第二配置文件中并不包括跟随设备的更新而不进行变化的第二配置信息。

第二配置文件在文件名称中添加更新标识，该更新标识用于表示该配置文件是更新后的第二配置文件。例如：在配置文件原有名称的基础上增加“Update”字段，用于表示该配置文件是更新后的升级配置文件。

其中，第一配置文件和第二配置文件位于同一个目录下，通过该目录可以读取到测试环境的配置文件，在读取到测试环境的配置文件之后，判断该目录包括的所有配置问文件名称中是否存在更新标识，如果有一个配置文件的名称中存在更新标识，则表明该配置文件是第二配置文件，即表明配置文件中包括区别于第一配置文件的第二配置文件。

S103、在配置文件包括第二配置文件的情况下，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境。

在确定配置文件包括区别于第一配置文件的第二配置文件的情况下，利用第一配置文件中不会随设备更新而变化的第二配置信息以及更新后的第二配置文件中的配置信息配置测试环境。

在一个可能的实施方式中，通过测试脚本中第一变量函数获取第一配置文件中的第一配置信息和第二配置信息，其中，第一配置信息包括第一配置项和第一配置项对应的第一参数值，第二配置信息包括第二配置项和第二配置项对应的第二参数值；通过测试脚本中第二变量函数获取第二配置文件中的第三配置信息，第三配置信息包括第三配置项和第三参数值；在第一配置项与第三配置项是相同配置项的情况下，利用第三配置项对应的第三参数值配置测试环境参数更新变量；利用第二配置项和第二配置项对应的第二参数值配置测试环境中的非参数更新变量。

其中，第一变量函数可以是测试脚本中的环境(setting)部分的变量(variables)函数。换句话说，通过测试脚本中的setting部分的variables函数将第一配置文件中的第一配置信息和第二配置信息引入Robot Framework。

其中，第二变量函数可以由robot framework架构中的Robot是命令以及-v选项构成。换句话说，通过Robot-v命令加第二配置文件的形式，将第二配置文件中的第三配置信息引入Robot Framework。

在一个可能的实现方式中，可以将第一配置文件中的第二配置信息以及第二配置文件中的配置信息提供给robot framework架构，由robot framewor架构据执行脚本，基于配置文件进行测试环境的配置。

在另一个可能的实现方式中，robot framework架构根据配置文件配置测试环境，在配置文件中增加设定字段，在该设定字段为set时，则基于配置文件中的配置信息进行测试环境的配置，在该设定字段为get时，则从实际测试环境中获取采集数据，实现对第一配置文件中第一配置信息的更新，得到第二配置文件。

在本申请实施例中，测试脚本会将第一配置文件中的全部配置信息(第一配置信息和第二配置信息)全部引用至Robot Framework，同时，也会将第二配置文件中的全部配置信息(第三配置信息息)引用至Robot Framework。此时，在Robot Framework中，针对一些参数值更新过的配置项，该配置项可能会存在两个对应的参数值，即第一配置文件中的第一参数值和第二配置文件中的第三参数值。由于两个配置的引入方式不同具有不同的优先级，第二配置文件的引入方式赋予变量的优先级高于第一配置文件方式引入变量的优先级，在同一个配置项存在两个参数值时，优先采用第二配置文件中的第三参数值配置测试环境。

图5是本申请实施例提供的一种配置信息引入Robot Framework的流程示意图；如图5所示，主要包括如下步骤：S201、读取测试脚本对应的配置文件，S202、判断配置文件中是否存在更新后的第二配置文件，如果不存在，则执行步骤S203。如果存在，则执行步骤S204。S203、通过setting部分的variables函数将第一配置文件引入Robot Framework。S204、通过setting部分的variables函数将第一配置文件引入Robot Framework。S205、通过测试脚本中的Robot-V函数加第二配置文件的形式，将第二配置文件中的第三配置信息引入Robot Framework。

在本申请实施例中，不修改第一yaml配置文件，而是根据第一yaml配置文件中设备部分的配置信息重新生成新的第二yaml配置文件(非设备变量不考虑)。第二yaml配置文件的数据结构和设备名称(只涉及网络设备)和第一yaml配置文件中的是一样的，不一样的只有配置项对应的参数值。在引用配置项的时候，第一yaml配置文件和第二yaml配置文件中的配置项都会引入Robot Framework架构中，但Robot-v+第二yaml配置文件文件引入的配置项优先级比通过脚本variables引入的配置项优先级高，这样在同一个配置项被引入两次的情况下，Robot Framework会优先采用第二yaml配置文件中的配置项对应的第三参数值。

本申请的技术方案，不需要更改原来的第一yaml配置文件，减少修改可能引入的问题，也简化了生成配置文件的技术难度；而且此方案无缝支持原来的yaml配置文件和脚本，唯一需要的是封装一层程序用来判断原来的yaml配置文件同目录下是否有对应的新的第二yaml配置文件，如果有，就在运行脚本时通过Robot-v把新的第二yaml配置文件传参给Robot Framework架构，如果没有，就和原来运行脚本一样没有任何变化。

本申请实施例中，使用robot-v和Robot Framework脚本中variables两种方法的结合，实现了在老环境基础上的无缝升级。

yaml配置文件采用缩进的方式表示数据的层级结构，yaml配置文件往往是一个多层结构，这样变量结构会很清晰，在测试脚本中的函数想要引用yaml配置文件中的参数值时，需要根据数据的层级结构一级一级的引用。变量名称会由‘.’连接的多层结构来表示，使用起来会很不方便。

以引用图3中所示的“tcp_mtu”对应的参数值为例，如果测试脚本直接引用该配置项对应的参数值，其在测试脚本中的引用变量名称是：“dna_value.common_value.test_mtu.tcp_mtu”，由此可见，引用的变量名称过长，会给用户的操作和查看带来不便。

在一个可能的实现方式中，通过测试脚本中第一变量函数获取第一配置文件中的第一配置信息和第二配置信息，包括：针对第一配置信息或第二配置信息中的任意一个配置项，通过测试脚本中的第三变量函数，在中间文件中获取变量名称对应的配置项路径，其中，中间文件中包括变量名称与配置项路径的对应关系；通过测试脚本中的第一变量函数，基于配置项路径从第一配置文件中获取配置项对应的参数值。

本申请实施例中，不再在测试脚本中通过variables引用yaml配置文件，而是在测试脚本中通过resource引用一个新的robot文件(中间文件)，而该robot文件通过variables引用yaml文件，这个被新加入的robot文件用来对yaml数据结构的配置项重定义，减少脚本直接引用yaml变量的复杂度。

示例性的，在robot文件中重新定义“TCP_MTU”与“dna_value.common_value.test_mtu.tcp_mtu”之间的对应关系。这样，在在测试脚本中通过resource引用robot文件中的“TCP_MTU”，robot文件接收到该引用请求后，获取与“TCP_MTU”对应的配置项“dna_value.common_value.test_mtu.tcp_mtu”。通过variables引用“dna_value.common_value.test_mtu.tcp_mtu”，并获取到该配置项对应的参数值“1300”，并通过robot文件将“1300”返回给测试脚本。

本申请实施例中，通过对引入参数的重定义，简化了yaml数据结构引用的复杂度。

在一个可能的实现方式中，该方法还包括：在配置文件中包括多个第二配置文件的情况下，获取各个第二配置文件的创建信息；基于各个第二配置文件的创建信息从多个第二配置文件中选取目标配置文件；相应的，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境，包括：基于第一配置文件中的第二配置信息和目标配置文件配置测试环境。

在实际测试环境中的设备数据进行多次更新的情况下，每次数据更新后都会生成一个对应的第二配置文件，这样，就会存在多个第二配置文件。在第二配置文件创建成功后，为每个第二配置文件添加对应的创建信息，其中，创建信息可以包括创建时间和/或创建版本。

在配置测试环境的过程中，如果在配置文件中包括多个第二配置文件，则可以从多个第二配置文件中选取出一个第二配置文件作为目标配置文件，最后，第一配置文件中的第二配置信息和目标配置文件进行测试环境的配置。

进一步的，目标配置文件的选取方式可以包括如下几种方式中的任意一种：(1)将创建时间最晚的第二配置文件作为目标配置文件，(2)将创建时间最早的第二配置文件作为目标配置文件，(3)将创建版本最新的第二配置文件作为目标配置文件，(4)将创建版本最早的第二配置文件作为目标配置文件，(5)根据用户在终端设备中选取操作，将选取操作对应的第二配置文件作为目标文件。

本申请实施例中，可以根据自动化测试环境变化随意选用对应的更新后的第二yaml配置文件，以提高测试环境的配置效率。

在上述实施例的基础上，本申请实施例还提供一种第二配置文件的更新方法，图6是本申请实施例提供的一种第二配置文件更新的方法流程图，如图6所示，本申请实施例提供的第二配置文件更新的方法主要包括如下步骤：

S301、获取测试环境中的第一配置文件，第一配置文件中包括至少一个第一配置信息，第一配置信息中包括其对应的目标设备的设备类型。

在实际环境中的设备数据发生变化时，用户可以在终端设备的交互界面上进行配置文件更新操作，响应于接收到配置文件更新操作，获取测试环境中的第一配置文件。第一配置文件中包括第一配置信息(如图4所示的配置信息)和第二配置信息(如图3所示的配置信息)。

目标设备是指Robot Framework框架中配置的虚拟网络设备，其中该虚拟网络设备与实际环境中的网络设备一一对应。每个目标设备会有一套对应的第一配置信息，用于配置Robot Framework中对应的目标设备。

其中，目标设备的设备类型在第一配置信息中存储。例如：图4中的switch_0.type：“hw”，表明设备类型是交换机。图4中的dev_mgt_info.type：“CentOSDUT”，表明该设备类型是Linux操作系统的设备。

S302、针对至少一个目标设备，基于目标设备的设备类型获取目标设备的采集数据，采集数据包括第四配置项以及和第四配置项对应的第四参数值。

由于在yaml配置文件中，不同类型的设备其主要的数据结构是不一样的。因此，获取目标设备的设备类型之后，确定该设备类型对应的数据结构，基于该数据结构从目标设备获取采集数据。上述数据结构可以理解为按照层次结构排布的需要采集的配置信息。不同设备的数据结构是不一样的，数据结构的确定是根据第一配置文件内定义的结构为依据的，后期更新只是更新其值而不是结构。

第四配置项是指目标设备的采集数据中包括的配置项，或者，也可以成为变量名称。第四配置项对应的第四参数值是指从目标设备中采集到的参数值，或者也可以成为变量值。

在一个可能的实现方式中，第一配置信息还包括：目标设备的设备管理信息；该方法还包括：基于设备管理信息控制目标设备处于登录状态；基于目标设备的设备类型获取目标设备的采集数据，包括：基于所述目标设备的设备类型以及待更新参数生成数据采集命令；向处于登录状态的目标设备发送数据采集命令，数据采集命令用于指示目标设备基于数据采集命令采集待更新参数对应的数据；获取目标设备反馈的采集数据。

其中，设备管理信息至少包括设备登录地址、设备登录方式、设备用户名称和设备登录密码，例如：图4中的dev_0这个设备中的设备登录地址是“192.168.22.8”，设备登录方式是“SSH”，其设备用户名称为“root”，设备登录密码是“Yusur_auto123”。

进一步的，根据设备登录地址、设备登录方式、设备用户名称和设备登录密码可以控制实际环境中的目标设备处于登录状态。然后，根据设备管理信息中设备类型确实该目标设备对应的数据采集命令。并将数据采集命令发送至实际环境中的目标设备，目标设备基于数据采集命令进行数据采集，并将采集到的数据返回至测试环境的配置装置中。其中，采集到的数据为目标设备的设备相关信息。例如：设备接口数量，各个接口的相关信息等等。

在一个可能的实施方式中，基于目标设备的设备类型生成数据采集命令，包括：在目标设备是Linux设备的情况下，判断目标设备的内核是否大于设定数值；如果目标设备的内核大于或等于设定数值，则基于第一配置文件中的第一设定数据结构生成数据采集命令；其中，第一设定数据结构是指内核大于或等于设定数值的linux设备对应的数据结构；如果目标设备的内核小于设定数值，则基于第一配置文件中的第二设定数据结构生成数据采集命令；其中，第二设定数据结构是指内核小于设定数值的linux设备对应的数据结构；在目标设备是Win设备的情况下，则基于第三配置文件中的Win设备对应的数据结构生成数据采集命令；在目标设备是已支持网络设备的情况下，则基于第一配置文件中的已支持网络设备对应的数据结构生成数据采集命令。

其中，设定数值可以根据实际情况进行设定，可选的，设定数值为2.2。第一设定数据结构是指在第一配置文件中linux操作系统且内核数大于或等于2.2的设备所采用的数据结构。第二设定数据结构是指在第一配置文件中linux操作系统且内核数小于2.2的设备所采用的数据结构。

由于不同的目标设备查询设备信息使用的命令不同，因此需要确认设备类型，由下面的yaml配置文件中的变量type字段定义，可以据此执行特定的命令集。

S303、在第四配置项与第一配置项是相同配置项的情况下，将第四参数值替换第一配置项对应的第一参数值，得到目标设备的第三配置信息。

针对第一配置信息中的每个第一配置项，如果在采集数据中存在于第一配置项相同的第四配置项，则将第四配置项对应的第四参数值替换第一配置项对应的第一参数值，得到第一配置项更新后的参数值。如果在采集数据中不存在于第一配置项相同的第四配置项，则直接将第一配置项保留原有的第一参数值。对第一配置信息中的每个第一配置项均进行判断，然后处理之后，目标设备的第三配置信息，其中，第三配置信息是指更新后的第一配置信息。

示例性的，在采集数据中的第四配置项“int_0的ip”对应的第四参数值是“12.168.22.88”，在第一配置信息中“int_0的ip”对应的第四参数值是“12.168.23.40”，则使用第四参数值“12.168.22.88”替换“12.168.23.40”，得到第一配置项对应的新的参数值“12.168.22.88”。

S304、基于至少一个目标设备的第三配置信息生成第二配置文件。

在实际环境中可能会存在多个目标设备，针对每个目标设备均要执行本申请实施例中的S302和S303，得到每个目标设备对应的第三配置信息。将多个目标设备的第三配置信息进行聚合之后，得到第一配置文件更新后的第二配置文件。

图7是本申请实施例提供的另一种第二配置文件的生成方法的流程图，如图7所示，本申请实施例提供的第二配置文件的生成方法包括如下流程：

S401、读取第一配置文件，获取第一配置文件中的设备信息。

其中该设备信息包括设备管理信息和所需采集的数据集。

S402、判断目标设备是不是Linux操作系统的设备，如果是，则执行步骤S403，如果不是，则执行步骤S408。

S403、判断目标设备的内核数是否大于或等于2.2，如果是，则执行步骤S404，如果不是，则执行步骤S406。

S404、基于第一配置文件中的第一设定数据结构生成数据采集命令并基于该数据采集命令获取目标设备的采集数据。

S405、将该采集数据中的第四参数值替换第一配置信息中的第一参数值，生成第二配置文件。

S406、基于第一配置文件中的第二设定数据结构生成数据采集命令并基于该数据采集命令获取目标设备的采集数据。

S407、将该采集数据中的第四参数值替换第一配置信息中的第一参数值，生成第二配置文件。

S408、判断目标设备是不是Win操作系统的设备，如果是，则执行S409，如果不是，则执行步骤S411。

S409、基于第一配置文件中的Win操作系统的设备的数据结构生成数据采集命令并基于该数据采集命令获取目标设备的采集数据。

S410、将该采集数据中的第四参数值替换第一配置信息中的第一参数值，生成第二配置文件。

S411、判断目标设备是不是已支持网络设备，如果是，则执行S412，如果不是，则执行步骤S414。

S412、基于第一配置文件中的已支持网络设备的数据结构生成数据采集命令并基于该数据采集命令获取目标设备的采集数据。

S413、将该采集数据中的第四参数值替换第一配置信息中的第一参数值，生成第二配置文件。

S414、任务异常结束

S415、判断目标设备是不是最后一个设备，如果是，则执行S416，如果否，则执行S417。

S416、任务正常结束。

S417、通过下一个设备的设备管理信息登录下一个设备，并返回执行S402。

在一个具体的实现方式中，获取目标设备数据需要网络设备的设备管理信息，该设备管理信息就在第一yaml配置文件中描述，根据该设备管理信息选择ssh或telnet等多种登录方式登录对应的目标设备，然后生成对应的新的第二yaml配置文件，第二yaml配置文件在第一yaml配置文件名字的基础上加上update关键字，表示是对应自动化测试环境的升级文件，该第二yaml配置文件和第一yaml配置文件放在一个目录下，初始化RobotFramework自动化环境时候根据有没有这个文件决定是否更新目标设备参数。

第一yaml配置文件中变量将分为设备变量和其他变量，设备变量是会因为拓扑设备变更而变化的变量，也是会被程序采集写入新配置yaml文件中的变量，即本申请实施中所述的第一配置信息中的第一配置项。可选的，一个测试环境只有一个新的第二yaml配置文件，反复更新会覆盖原来的新的第二配置yaml文件，也可以给新更新的第二yaml配置文件加上时间，这样可以根据自动化测试环境变化随意选用对应的配置更新yaml文件。

图8是本实施例提供的一种测试环境的配置装置的结构示意图；该装置配置于电子设备中，可实现本申请任意实施例的测试环境的配置方法。如图8所示，本申请实施例提供的测试环境的配置装置800主要包括：配置文件获取模块801，用于在接收到测试环境配置请求的情况下，获取测试环境的配置文件；配置文件判断模块802，用于判断配置文件中是否包括区别于第一配置文件的第二配置文件，其中，第一配置文件是测试环境首次进行配置时所使用的配置文件，第一配置文件包括第一配置信息和第二配置信息，第二配置文件由第一配置信息进行更新后得到，第二配置信息是指测试环境中不进行更新的配置信息；测试环境配置模块803，用于在配置文件包括第二配置文件的情况下，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境。

本申请实施例提供的测试环境的配置装置，用于执行如下流程：首先，在接收到测试环境配置请求的情况下，获取测试环境的配置文件；然后，判断配置文件中是否包括区别于第一配置文件的第二配置文件，其中，第一配置文件是测试环境首次进行配置时所使用的配置文件，第一配置文件包括第一配置信息和第二配置信息，第二配置文件由第一配置信息进行更新后得到，第二配置信息是指测试环境中不进行更新的配置信息；最后，在配置文件包括第二配置文件的情况下，基于第一配置文件中的第二配置信息和第二配置文件配置测试环境。由于第二配置文件是基于第一配置文件的第一配置信息生成的，并不包括第一配置文件并不需要更新的配置信息，因此，第二配置文件与第一配置文件中不存在相同的配置信息，实现了减少配置文件内容冗余，提高测试环境的配置效率。

在一个可能的实现方式中，测试环境配置模块803，具体用于通过测试脚本中第一变量函数获取第一配置文件中的第一配置信息和第二配置信息，其中，第一配置信息包括第一配置项和第一配置项对应的第一参数值，第二配置信息包括第二配置项和第二配置项对应的第二参数值；通过测试脚本中第二变量函数获取第二配置文件中的第三配置信息，第三配置信息包括第三配置项和第三参数值；在第一配置项与第三配置项是相同配置项的情况下，利用第三配置项对应的第三参数值配置测试环境参数更新变量；利用第二配置项和第二配置项对应的第二参数值配置测试环境中的非参数更新变量。

在一个可能的实现方式中，测试环境配置模块803，具体用于针对第一配置信息或第二配置信息中的任意一个配置项，通过测试脚本中的第三变量函数，在中间文件中获取变量名称对应的配置项路径，其中，中间文件中包括变量名称与配置项路径的对应关系；通过测试脚本中的第一变量函数，基于配置项路径从第一配置文件中获取配置项对应的参数值。

在一个可能的实现方式中，配置文件判断模块802，具体用于在配置文件中包括多个第二配置文件的情况下，获取各个第二配置文件的创建信息；基于各个第二配置文件的创建信息从多个第二配置文件中选取目标配置文件；测试环境配置模块803，具体用于基于第一配置文件中的第二配置信息和目标配置文件配置或获取测试环境信息。

在一个可能的实现方式中，该装置还包括：第一配置文件获取模块，用于获取测试环境中的第一配置文件，第一配置文件中包括至少一个第一配置信息，第一配置信息中包括其对应的目标设备的设备类型；采集数据获取模块，用于针对至少一个目标设备，基于目标设备的设备类型获取目标设备的采集数据，采集数据包括第四配置项以及和第四配置项对应的第四参数值；第三配置信息确定模块，用于在第四配置项与第一配置项是相同配置项的情况下，将第四参数值替换第一配置项对应的第一参数值，得到目标设备的第三配置信息；第二配置文件生成模块，用于基于至少一个目标设备的第三配置信息生成第二配置文件。

在一个可能的实现方式中，第一配置信息还包括：目标设备的设备管理信息；该装置还包括：目标设备控制模块，用于基于设备管理信息控制目标设备处于登录状态；采集数据获取模块，具体用于基于目标设备的设备类型生成数据采集命令；向处于登录状态的目标设备发送数据采集命令，数据采集命令用于指示目标设备基于数据采集命令采集数据；获取目标设备反馈的采集数据。

在一个可能的实现方式中，采集数据获取模块，具体用于在目标设备是linux设备的情况下，判断目标设备的内核是否大于设定数值；如果目标设备的内核大于或等于设定数值，则基于第一配置文件中的第一设定数据结构生成数据采集命令；其中，第一设定数据结构是指内核大于或等于设定数值的linux设备对应的数据结构；如果目标设备的内核小于设定数值，则基于第一配置文件中的第二设定数据结构生成数据采集命令；其中，第二设定数据结构是指内核小于设定数值的linux设备对应的数据结构；在目标设备是Win设备的情况下，则基于第三配置文件中的Win设备对应的数据结构生成数据采集命令；在目标设备是已支持网络设备的情况下，则基于第一配置文件中的已支持网络设备对应的数据结构生成数据采集命令。

本发明实施例所提供的测试环境的配置装置可执行本发明任意实施例所提供的测试环境的配置方法，具备执行方法相应的功能模块和有益效果。

图9是本实施例提供的一种测试环境的配置设备的结构示意图。如图9所示，该测试环境的配置设备900包括处理器910、存储器920、输入装置930和输出装置940；电子设备中处理器910的数量可以是一个或多个，图9中以一个处理器910为例；电子设备中的处理器910、存储器920、输入装置930和输出装置940可以通过总线或其他方式连接，图9中以通过总线连接为例。

存储器920作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的数据传输方法对应的程序指令/模块。处理器910通过运行存储在存储器920中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现本发明实施例所提供的测试环境的配置和信息获取方法。

存储器920可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器920可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器920可进一步包括相对于处理器910远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置930可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入，可以包括键盘、鼠标等。输出装置940可包括显示屏等显示设备。

本实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于实现本发明实施例所提供的测试环境的配置方法。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的测试环境的配置方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述搜索装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

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

在接收到测试环境配置请求的情况下，获取所述测试环境的配置文件；

判断所述配置文件中是否包括区别于第一配置文件的第二配置文件，其中，所述第一配置文件是所述测试环境首次进行配置时所使用的配置文件，所述第一配置文件包括第一配置信息和第二配置信息，所述第二配置文件由所述第一配置信息进行更新后得到，所述第二配置信息是指所述测试环境中不进行更新的配置信息；

在所述配置文件包括所述第二配置文件的情况下，基于所述第一配置文件中的第二配置信息和所述第二配置文件配置所述测试环境。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一配置文件中的第二配置信息和所述第二配置文件配置测试环境，包括：

通过测试脚本中第一变量函数获取所述第一配置文件中的第一配置信息和第二配置信息，其中，所述第一配置信息包括第一配置项和所述第一配置项对应的第一参数值，所述第二配置信息包括第二配置项和所述第二配置项对应的第二参数值；

通过所述测试脚本中第二变量函数获取所述第二配置文件中的第三配置信息，所述第三配置信息包括第三配置项和所述第三参数值；

在所述第一配置项与所述第三配置项是相同配置项的情况下，利用所述第三配置项对应的第三参数值配置所述测试环境参数更新变量；

利用所述第二配置项和所述第二配置项对应的第二参数值配置所述测试环境中的非参数更新变量。

3.根据权利要求2所述的方法，其特征在于，所述通过测试脚本中第一变量函数获取所述第一配置文件中的第一配置信息和第二配置信息，包括：

针对所述第一配置信息或所述第二配置信息中的任意一个配置项，通过测试脚本中的第三变量函数，在中间文件中获取变量名称对应的配置项路径，其中，所述中间文件中包括所述变量名称与所述配置项路径的对应关系；

通过测试脚本中的第一变量函数，基于所述配置项路径从所述第一配置文件中获取所述配置项对应的参数值。

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

在所述配置文件中包括多个第二配置文件的情况下，获取各个所述第二配置文件的创建信息；

基于各个所述第二配置文件的创建信息从多个所述第二配置文件中选取目标配置文件；

相应的，所述基于所述第一配置文件中的第二配置信息和所述第二配置文件配置所述测试环境，包括：

基于所述第一配置文件中的第二配置信息和所述目标配置文件配置所述测试环境。

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

获取所述测试环境中的第一配置文件，所述第一配置文件中包括至少一个所述第一配置信息，所述第一配置信息中包括其对应的目标设备的设备类型；

针对至少一个目标设备，基于所述目标设备的设备类型获取所述目标设备的采集数据，所述采集数据包括第四配置项以及和所述第四配置项对应的第四参数值；

在所述第四配置项与所述第一配置项是相同配置项的情况下，将所述第四参数值替换所述第一配置项对应的第一参数值，得到所述目标设备的第三配置信息；

基于至少一个所述目标设备的第三配置信息生成第二配置文件。

6.根据权利要求5所述的方法，其特征在于，所述第一配置信息还包括：所述目标设备的设备管理信息；所述方法还包括：

基于所述设备管理信息控制所述目标设备处于登录状态；

所述基于所述目标设备的设备类型获取所述目标设备的采集数据，包括：

基于所述目标设备的设备类型以及待更新参数生成数据采集命令；

向处于登录状态的所述目标设备发送所述数据采集命令，所述数据采集命令用于指示所述目标设备基于数据采集命令采集待更新参数对应的数据；

获取所述目标设备反馈的采集数据。

7.根据权利要求6所述的方法，其特征在于，所述基于所述目标设备的设备类型以及待更新参数生成数据采集命令，包括：

在所述目标设备是linux设备的情况下，判断所述目标设备的内核是否大于设定数值；

如果所述目标设备的内核大于或等于所述设定数值，则基于所述第一配置文件中的第一设定数据结构生成数据采集命令；其中，所述第一设定数据结构是指内核大于或等于所述设定数值的linux设备对应的数据结构；

如果所述目标设备的内核小于所述设定数值，则基于所述第一配置文件中的第二设定数据结构生成数据采集命令；其中，所述第二设定数据结构是指内核小于所述设定数值的linux设备对应的数据结构；

在所述目标设备是Win设备的情况下，则基于所述第三配置文件中的所述Win设备对应的数据结构生成数据采集命令；

在所述目标设备是已支持网络设备的情况下，则基于所述第一配置文件中的所述已支持网络设备对应的数据结构生成数据采集命令。

8.一种测试环境的配置装置，其特征在于，包括：

配置文件获取模块，用于在接收到测试环境配置请求的情况下，获取所述测试环境的配置文件；

配置文件判断模块，用于判断所述配置文件中是否包括区别于第一配置文件的第二配置文件，其中，所述第一配置文件是所述测试环境首次进行配置时所使用的配置文件，所述第一配置文件包括第一配置信息和第二配置信息，所述第二配置文件由所述第一配置信息进行更新后得到，所述第二配置信息是指所述测试环境中不进行更新的配置信息；

测试环境配置模块，用于在所述配置文件包括所述第二配置文件的情况下，基于所述第一配置文件中的第二配置信息和所述第二配置文件配置所述测试环境。

9.一种电子设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。