CN115454812A

CN115454812A - 一种对被测单元的测试方法、计算设备及测试系统

Info

Publication number: CN115454812A
Application number: CN202210945955.9A
Authority: CN
Inventors: 谢志才
Original assignee: XFusion Digital Technologies Co Ltd
Current assignee: Henan Kunlun Technology Co ltd
Priority date: 2022-08-08
Filing date: 2022-08-08
Publication date: 2022-12-09

Abstract

本申请实施例公开一种对被测单元的测试方法、计算设备及测试系统，该方法包括：向测试服务器发送获取请求，所述获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中发送给测试服务器以便从测试服务器中获取配置文件；若接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则从测试服务器下载所述第一配置文件指示的程序对象；在被测单元中加载从测试服务器下载的程序对象，以完成对被测单元的测试。采用本发明，能够合理地利用服务器资源，提高对被测单元的测试效率。

Description

一种对被测单元的测试方法、计算设备及测试系统

技术领域

本申请涉及电子装置测试技术领域，尤其涉及一种对被测单元的测试方法、计算设备及测试系统。

背景技术

在服务器、个人电脑等设备的生产制造环节中，对设备中的各个组件需要进行测试，提前拦截缺陷与改进，以保障计算设备的出厂质量。这些组件例如可以是主板，背板、CPU(central processing unit，中央处理器)、硬盘、内存等。

目前在对各种组件进行测试的过程中，一般针对不同的测试场景，会分别组装得到不同的被测单元，并且会分别设置测试服务器来存储相应测试场景下的测试用的OS(Operating System，操作系统)，这样一来，不同测试场景下，由待测试的计算设备中的组件构成的被测单元可以依次接入相应的测试服务器下载测试用的OS，完成不同工序的测试。但是，不同场景依赖不同测试服务器资源，测试成本高，测试服务器资源不能得到充分利用。

发明内容

本申请实施例提供了一种对被测单元的测试方法、计算设备及测试系统，可以通过配置文件来灵活地为被测单元提供不同测试场景下的测试用程序对象。

第一方面，本申请实施例提供了一种对被测单元的测试方法，该方法可以应用于由基于主板、各种所需的存储介质等组件构成的被测单元，所述方法包括：向测试服务器发送获取请求，在所述获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，并且查询优先级高的查询标识会优先作为目标查询标识携带在获取请求中发送给测试服务器，所述获取请求用于请求从所述测试服务器下载与所述目标查询标识对应的配置文件，测试服务器中的配置文件是由与查询标识相同的字符串作为查询关键字存储的；若接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则从测试服务器下载所述第一配置文件指示的程序对象，该程序对象例如可以是各种测试用的OS文件；在被测单元中加载从测试服务器下载的程序对象，这样便可根据测试用的OS文件中定义的相应测试策略完成对被测单元的测试。

在该技术方案中，通过向测试服务器发送不同查询优先级的查询标识可以获取到不同的配置文件以及OS文件，这样一来，当被测单元的测试场景需要切换时，例如当前测试场景已经测试完成需要切换到下一测试场景，只需要在测试服务器中为查询优先级更高的查询标识设置相应的配置文件和OS文件即可，可以灵活地为被测单元提供不同测试场景下的配置文件以及测试用程序对象，节省了测试服务器资源，降低了测试成本。

在一种可能的实现方式中，所述测试服务器中存储有配置文件，各配置文件中包括查询关键字和程序对象信息；各配置文件中的程序对象信息指示了不同测试场景的程序对象；各配置文件中，包括的查询关键字与所述目标查询标识相同的配置文件被确定为第一配置文件。在该技术方案中，可以通过在测试服务器中设置或者更新得到配置文件的方式来实现对被测单元在不同测试场景下的测试，并且，查询关键字可以作为配置文件中的一部分内容，也可以作为配置文件的文件名，这样一来，通过查询标识和查询关键字是否相同，来确定第一配置文件下载给被测单元。

在一种可能的实现方式中，所述在被测单元中加载从测试服务器下载的程序对象之后，所述方法还可以包括：确定所述程序对象的属性信息；如果所述属性信息与获取到的第二配置文件包括的程序对象信息不匹配，则根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件；其中，所述第二配置文件包括的程序对象信息用于指示所述测试单元在本次测试场景下的程序对象；当所述被测单元重启之后，向测试服务器发送的获取请求用于请求从所述测试服务器的更新后的配置文件中下载对应的配置文件。

在该技术方案中，加载了测试用的OS文件等程序对象之后，可以判断已经下载的OS文件等程序对象与最新所需的测试场景是否一致，即将程序对象的名称、版本号等属性信息与最新所需的测试场景对应的第二配置文件中配置的名称及版本号等程序对象信息进行比对，如果相同，则可以继续进行测试，如果不相同，则需要对测试服务器中的配置文件进行更新，该更新例如是生成对应的查询优先级更高查询标识对应的配置文件。也就是说，测试相关人员可以根据实际的测试场景的需要，配置相应的第二配置文件，这样一来，基于属性信息与第二配置文件中的程序对象信息是否匹配的相关步骤流程，可以随时指示被测单元切换到新的测试场景进行测试，使得被测单元的测试更加灵活高效。

在一种可能的实现方式中，所述根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件，包括：根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；将所述第三配置文件发送至所述测试服务器；其中，所述第三配置文件包括查询关键字和程序对象信息，所述第三配置文件包括的查询关键字所对应的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

在该技术方案中，为了切换到第二配置文件所对应的测试场景，在对测试服务器中的配置文件进行更新是采用生成新的第三配置文件的方式进行，通过该第三配置文件能够便捷地完成测试服务器中配置文件的更新，并且可以确保新测试场景的第三配置文件能够被优先下载到，进而完成测试场景的切换。

在一种可能的实现方式中，所述根据所述第二配置文件中设置的程序对象信息，生成第三配置文件，包括：判断是否获取到优先测试场景指示信息；若是，则根据第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级为最高优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

在该技术方案中，引入了优先测试场景指示信息，基于该信息，可以直接生成查询优先级为最高优先级的查询标识对应的第三配置文件，这样一来，被测单元在从测试服务器获取配置文件时，按照查询优先级的查询顺序，可以最快地获取到最高查询优先级的查询标识对应的配置文件，而不需要按照查询优先级的优先级顺序一个一个的尝试下载配置文件，进一步提高了一些特殊测试场景的测试效率。

在一种可能的实现方式中，所述根据所述第二配置文件中设置的程序对象信息，生成第三配置文件，包括：判断是否获取到优先测试场景指示信息；若否，则根据第一配置文件中的查询关键字，第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级比所述第一配置文件中包括的查询关键字的查询优先级高一个等级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

在该技术方案中，在没有优先测试场景指示信息的情况下，只需要生成比原有的配置文件高一个查询登记的第三配置文件即可，为后续可能存在的测试场景的切换留有余地，方便在下一次切换时，也能够生成合适的查询优先级的查询标识对应的配置文件。

在一些实施例中，如果发现当前的第一配置文件的优先级已经是最高优先级了，已经不能生成第三配置文件时，可以删除测试服务器中所有的关于该被测单元(可以以板名来区分不同的被测单元)的配置文件或者删除指定查询优先级的查询标识所对应的配置，以便于生成所述第三配置文件。其中，在所有的配置文件都被删除的情况下，可以生成最低查询优先级的查询标识对应的配置文件(例如生成默认字符串对应的配置文件)，或者生成指定查询优先级的查询标识对应的配置文件(例如生成以板名命名的配置文件)。在一些实施例中，针对所述测试服务器中存储的配置文件被允许按照删除指令进行删除处理，所述删除指令是在响应于针对测试服务器中的配置文件的删除操作时生成的；或者所述删除指令是在检测到自动删除条件被满足时生成的。可以是手动直接对测试服务器发起删除操作或者手动通过被测单元对测试服务器发起删除操作，来发出删除指令删除对应的部分或者全部配置文件，也可以在时间或者周期等因素满足自动删除条件时，来发出删除指令删除对应的部分或者全部配置文件。

在一种可能的实现方式中，所述向测试服务器发送获取请求之前，还包括：获取被测单元的单元属性信息，所述单元属性信息包括：被测单元的硬件地址、通信地址、被测单元所使用主板的板名中的任意一种或多种；生成携带目标查询标识的获取请求，所述目标查询标识是根据单元属性信息得到的。

在该技术方案中，以被测单元本身特殊的属性来作为查询标识或者查询关键字，可以较好地区分不同的被测单元的配置文件，针对不同的被测单元，提高了下载配置文件以及OS文件的准确性。

在一种可能的实现方式中，所述方法还包括：若没有接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则生成携带新的目标查询标识的获取请求，新的目标查询标识是根据单元属性得到的，并且新的目标查询标识的查询优先级低于在该新的目标查询标识确定之前的目标查询标识的查询优先级。

在该技术方案中，通过逐级降低查询优先级的方式来查询下载配置文件，使得高查询优先级的配置文件被优先下载而低查询优先级不会被下载，方便配置文件的切换，便捷地实现了测试场景的切换。

在一种可能的实现方式中，所述向测试服务器发送获取请求之前，还包括：通过被测单元的网口向测试服务器发送连接请求，所述被测单元的网口配置有与所述测试服务器建立连接的通信协议；根据所述测试服务器响应所述连接请求返回的连接信息建立与所述测试服务器之间的通信连接；通过建立的所述通信连接从所述测试服务器下载引导程序，并在被测单元上执行该引导程序以便于执行所述向测试服务器发送获取请求的步骤。

在该技术方案中，定义了在被测单元和测试服务器之间建立通信连接的方式，可以确保还没有记载任何操作系统的被测单元与测试服务器建立连接，执行后续相关的流程步骤。

在一种可能的实现方式中，如果所述属性信息与获取到的第二配置文件中设置的程序对象信息匹配，则继续运行所述程序对象，按照所述程序对象中设置的测试规则对被测单元进行测试处理；根据所述程序对象中设置的配置更新信息，生成第四配置文件；将所述第四配置文件发送给所述测试服务器；其中，所述第四配置文件中的查询关键字的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。

在该技术方案中，在基于当前下载到的程序对象进行测试的过程中，可以指示被测单元下一次测试所需的配置信息，这样一来，被测单元即可在测试服务器中登记新的配置文件，确保在本次测试完成后，重启再次进行测试时，能够从测试服务器下载到最新的配置文件，而不会再次下载到已经完成的测试场景所对应的配置文件，提高了测试切换的效率。

在一种可能的实现方式中，所述测试服务器中存储的配置文件被允许按照删除指令进行删除处理；所述删除指令是在响应于针对测试服务器中的配置文件的删除操作时生成的；或者所述删除指令是在检测到自动删除条件被满足时生成的。

在该技术方案中，可以通过直接对测试服务器发起删除操作的方式，或者通过被测单元对测试服务器发起删除操作的方式，或者测试服务器也可以自动地在诸如时间或者删除周期等因素满足自动删除条件的情况下，删除测试服务器中的部分或者全部配置文件，以便于回收对应的查询关键字生成针对新的测试场景所需的配置文件。

在一种可能的实现方式中，所述被测单元为由主板和功能组件构建的计算设备，所述功能组件包括：背板、板卡、处理器、介质中的任意一种或多种。

第二方面，本申请实施例还提供了一种对被测单元的测试装置，该装置具有执行上述第一方面所述的方法示例中部分或全部步骤的能力，比如该装置可具备执行本申请中的部分或全部实施例中的相关步骤的功能，也可以具备单独执行本申请中的任一个实施例中的步骤的功能。在该装置中，相关的步骤和功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元或模块。

在一种实现方式中，该对被测单元的测试装置的结构中可包括处理单元和通信单元，所述处理单元被配置为支持本装置执行上述方法中相应的步骤。所述通信单元用于支持本装置与其他设备之间的通信。所述对被测单元的测试装置还可以包括存储单元，所述存储单元用于与处理单元和通信单元耦合，其保存必要的计算机程序和数据。

第三方面，本申请实施例还提供了一种计算设备，该计算设备包括处理器，该计算设备通过该处理器该装置具备执行上述第一方面所述的方法示例中部分或全部步骤的能力，比如通过该处理器，计算设备可具备执行本申请中的部分或全部实施例中的相关步骤的功能，也可以具备单独执行本申请中的任一个实施例中的步骤的功能。相关的步骤和功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。

在一种实现方式中，该计算设备的结构中还可包括通信接口，例如网口，所述通信接口用于支持本装置与其他设备之间的通信。所述计算设备还可以包括存储器，所述存储器用于与处理器和通信接口耦合，其保存必要的计算机程序和数据。

第四方面，本申请实施例还提供了一种测试系统，该系统包括：被测单元、测试服务器、配置平台；所述测试服务器，用于存储测试用的配置文件和程序对象；所述配置平台，用于配置关于所述测试单元在本次测试场景下的程序对象信息；所述被测单元，用于执行上述第一方面所述的方法示例中部分或全部步骤。

附图说明

图1是本申请实施例的一种对被测单元的测试系统的结构示意图；

图2是本申请实施例的一种对被测单元的测试方法的流程示意图；

图3是本申请实施例的另一种对被测单元的测试方法的流程示意图；

图4是本申请实施例的另一种对被测单元的测试方法的流程示意图；

图5是本申请实施例的一种在测试用的OS文件版本存在更新的测试场景下的测试方法的流程示意图；

图6是本申请实施例的一种在测试工序存在更新的测试场景下的测试方法的流程示意图；

图7是本申请实施例的一种指定测试场景下的测试方法的流程示意图；

图8是本申请实施例的一种对被测单元的测试装置的结构示意图；

图9是本申请实施例的一种计算设备的结构示意图。

具体实施方式

为了更好地理解本申请实施例提供的技术方案，首先对本申请实施例涉及的技术术语进行介绍。

本申请实施例通过在测试服务器中存储各种测试场景下测试用的操作系统OS，当需要对主板、硬盘、移动介质、背板、处理器等等组件进行测试时，可以根据实际情况将这些组件单独或者全部接入到主板构成UUT(Unit Under Test，被测单元)，以便于以UUT为对象进行测试，在这种情况下，由于UUT没有可以正常启动的操作系统OS，因此本申请实施例设置一个或者多个引导执行程序，UUT接入到测试服务器后，基于这些引导执行程序从测试服务器中下载、解析配置文件，进而根据配置文件下载并运行指定测试场景的测试用OS，实现对UUT进行测试。在测试用OS的初始化阶段，还能够通过更新测试服务器中的配置文件的方式，切换下载不同的测试用OS，实现不同测试场景下的UUT测试。

在一个实施例中，对UUT的测试过程可以包括：

步骤1、UUT上电，通过主板自带的开机网络引导功能接入到测试服务器，UUT向测试服务器请求IP与引导执行程序(该引导执行程序例如为一个x86_64.efi的文件)。

步骤2、UUT从测试服务器下载引导执行程序并运行，通过运行该引导执行程序，一方面可获取UUT当前的IP地址、MAC地址、主板的板名等UUT的属性信息，另一方面可以尝试根据01-Mac、02-Mac、IP地址、板名等UUT的属性信息，按照查询优先级从测试服务器中逐个为该UUT找到对应的配置文件(按照先找到的配置文件为准)。

步骤3、UUT通过运行所述引导执行程序解析从测试服务器找到的第一配置文件，基于该第一配置文件解析得到OS名称及版本等OS文件(OS文件也可以称之为程序对象)的属性信息，进而基于解析得到的OS名称及版本等属性信息从测试服务器下载对应的OS文件并运行。需要说明的是，为了与其他配置文件区别开来，通过步骤2UUT最先能获取到的配置文件被标记为第一配置文件。

步骤4、UUT通过运行所述引导执行程序，解析第一配置文件的内容，并按照从所述第一配置文件中解析得到的OS名称及版本等属性信息，从测试服务器中下载OS文件运行从测试服务器下载到的OS文件，在其中的OS初始化程序执行过程中，获取OS文件的名称及版本号等属性信息，然后将获取到OS文件的属性信息与从配置平台、云端等服务端获取的第二配置文件中设置的程序对象信息进行校验，确定当前运行的OS名称及版本等属性信息与第二配置文件中配置的程序对象信息是否匹配，如果匹配，就继续测试，如果不匹配就执行下面的步骤5。

步骤5、UUT执行OS初始化程序的过程中，会根据第二配置文件，生成新的配置文件以更新所述测试服务器中存储的配置文件，进而在重启后可以基于新的配置文件获取到在测试用测试服务器中存储的其他OS文件，以便于完成对UUT的测试。在生成新的配置文件并发送给测试服务器以触发在测试服务器进行配置文件更新之后，UUT会执行重启，以便于在重启之后再次执行上述的步骤1等步骤。对于新的配置文件，可以基于上述在步骤2提及的查询优先级来生成，根据查询优先级，UUT在重启后执行步骤2的过程中，新的配置文件会被优先查找到。

配置平台中的第二配置文件的程序对象信息可以根据实际测试场景进行配置，因此，在测试服务器中可以存储各种场景下的OS文件，针对某个被测单元而言，各测试场景所需的OS文件的名称及版本号，均可以设置到第二配置文件中，进而实现各种测试场景所需的OS文件的查询、下载以及运行，以完成测试。

在一个可能的实施例中，请参考图1，是本申请实施例的一种对被测单元的测试系统的结构示意图。该系统包括：测试服务器101，配置平台102，网络设备103，以及UUT104、UUT105等等。测试服务器101可以是基于PXE(Pre-boot Execution Environment，网络引导)协议的PXE测试服务器。通过配置平台102可以方便测试用户或者测试管理用户进行程序对象信息的配置，其独立于PXE测试服务器，由提供IT服务的设备或者云端测试服务器承载。网络设备103可以为交换机、路由器等设备，网络设备103为可选设备，当被测的UUT较多时，各个UUT可以通过网络设备103分别连接测试服务器101和配置平台102，在通过各UUT的网口从测试服务器获取到IP地址之后，即可与测试服务器101和配置平台102进行数据交互。当UUT较少时，比如只有1台UUT时，可以不需网络设备103，而直接基于网线来建立UUT与测试服务器101和配置平台102之间的连接，进而基于测试服务器101分配的IP地址实现与测试服务器101和配置平台102进行数据交互。UUT可以是在主板上插入了内存、硬盘等组件后构成的需要测试的单元。

测试服务器101可以是PXE测试服务器(PXE server)、引导测试服务器(boostserver)、OS测试服务器(OS server)等，对于测试服务器101而言，其功能可以包括：开启DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)、TFTP(Trivial FileTransfer Protocol，简单文件传输协议)、FTP(FileTransferProtocol，文件传输协议)等服务，提供IP自动分配、客户端引导执行程序分发、文件下载功能等，可以部署不同平台(x86、aarch64等框架)引导执行程序(例如：x86_64.efi/aarch64.efi文件)、引导配置文件、OS文件等。引导执行程序是在UUT上电启动后执行，从而实现PXE配置文件下载与解析功能。通过引导执行程序，能够根据指定的查询优先级获取PXE配置文件(最先获取到的配置文件为第一配置文件)，解析获取到的第一配置文件中配置的OS名称及版本等程序对象信息，根据程序对象信息从测试服务器101上继续下载OS文件(即程序对象)到UUT本地。

配置平台102为独立于测试服务器101的设备或者设备集合，配置平台102的功能在于：提供用户界面等人机交互功能，通过这些用户界面可以设置测试场景所对应的PXEOS文件的名称及版本等程序对象信息，也就是配置本次针对某个UUT的测试所需的实际配置文件(可以称之为第二配置文件)，配置平台102可以提供Webservices接口服务，UUT在运行OS文件执行OS文件中OS初始化程序的过程中，可以通过Webservices接口服务从配置平台102获取到当前测试场景实际所需的PXE OS文件的名称及版本等信息查询服务。实际配置文件或者说第二配置文件可以基于主板的板名设置查询关键字，这样一来，不同的主板所对应的被测单元可以基于主板的板名获取到所需的第二配置文件。当然也可以使用主板的硬件地址来区别不同的主板，设置第二配置文件中的查询关键字。

UUT104中包括能够接入测试服务器101或者交换机等网络设备的网口，在测试服务器101为PXE测试服务器的情况下，UUT104的网口支持PXE协议，支持开机网络引导功能，基于该开机网络引导功能，UUT104可以基于PXE协议从PXE测试服务器获取IP和引导执行程序，基于引导执行程序能够读取UUT本地信息(网口Mac地址、IP、板名等)、下载并解析01-Mac、02-Mac、IP或者板名所对应的第一配置文件、下载第一配置文件指示的OS文件，运行下载得到的OS文件以完成测试等等处理。对于UUT104而言，还可以遵循SMBIOS(SystemManagement BIOS)规范(一种以标准格式显示主板或系统等产品管理信息所需遵循的统一规范)，通过DMI(Desktop Management Interface，桌面管理接口)type2字段填充板名等信息以便于在运行引导执行程序的过程中从测试服务器下载所需的配置文件，其中板名信息所包含类似物料版本标识号(Bill of Material Identity document)BOM ID标志，支持同种类型单板，不同硬件版本的测试场景。

请参见图2，是本发明实施例的一种对被测单元的测试方法的流程示意图，本发明实施例的所述方法可以在被测单元侧实现，所述被测单元为由主板和功能组件构建的计算设备，所述功能组件包括：背板、板卡、处理器、介质中的任意一种或多种。其中，背板可以包括：硬盘背板、风扇控制板、IO(Input/Output，输入/输出)控制板，板卡可以包括：BMC(Baseboard Management Controller，基板管理控制器)卡、RAID(Redundant Arrays ofIndependent Disks，独立冗余磁盘阵列)卡、网卡、管理板，处理器CPU(centralprocessing unit，中央处理器)，介质可以包括：硬盘、内存等。所述被测单元将内存、处理器、硬盘、背板等功能组件插入到主板后，可以构成能够运行引导执行程序和测试用的程序对象的计算设备，该被测单元的具体描述可参考前述内容，所述方法包括如下步骤。

S201：向测试服务器发送获取请求，所述获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中，所述获取请求用于请求从所述测试服务器下载与所述目标查询标识对应的配置文件。

可以预先定义多个查询标识并定义每个查询标识的查询优先级，查询标识及其查询优先级的示意性描述如表1所示。

表1

查询优先级	1	2	3	4	5
						查询标识	查询标识A	查询标识B	查询标识C	查询标识D	查询标识E

查询标识可以是多个字符构成的字符串，可以根据需要进行设置，确保每个字符串构成的查询标识不相同即可，查询标识也可以是被测单元的某些特征信息所对应的字符，比如被测单元的单元属性信息，其包括：被测单元的硬件地址、通信地址、被测单元所使用主板的板名中的任意一种或多种。一方面，对于被测单元而言，可以通过查询标识到测试服务器中查询配置文件，另一方面，对于测试服务器而言，会将查询标识作为查询关键字与一个配置文件关联，这样一来，通过查询标识可以到测试服务器中找到匹配的查询关键字(匹配的查询关键字与查询标识的字符串相同)，进而找到配置文件。

在预先定义好查询标识或者说查询关键字的查询优先级之后，后续即可基于不同的查询标识或查询关键字以及不同的查询优先级执行本申请实施例后续的相关操作。

在确定目标查询标识时，是按照查询优先级从高到低的顺序进行确定的，假设查询优先级最高为等级1的查询标识A，查询优先级最低为等级5的查询标识E，在此情况下，在执行S201时，优先使用查询标识1作为目标查询标识，其次将查询标识B作为目标查询标识，以此类推，最后才将查询标识E作为目标查询标识。

S202：若接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则从测试服务器下载所述第一配置文件指示的程序对象。如果按照目标查询标识，查找并下载得到了匹配的查询关键字，这该查找到的匹配查询关键字所关联的配置文件即为第一配置文件。而如果没有接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则再次从所述单元属性信息中确定新的目标查询标识，以便于按照新的目标查询标识下载配置文件，新的目标查询标识的查询优先级低于在该新的目标查询标识确定之前的目标查询标识的查询优先级，例如上一次的目标查询标识为查询标识A，则本次按照查询优先级的优先级顺序依次将查询标识B作为目标查询标识，依次类推，直到下载到第一配置文件或者没有下载到任何配置文件为止。

S203：在被测单元中加载从测试服务器下载的程序对象，以完成对被测单元的测试。第一配置文件中记录了程序对象信息，程序对象信息例如可以是某个测试程序或者测试用的OS文件的名称和版本号，基于名称和版本号，可以从测试服务器下载对应的测试程序或者测试用的OS文件，进而允许测试程序或者测试用的OS文件，进行对被测单元的测试。

本申请实施例中，围绕查询标识和查询优先级部署了测试用的程序对象的获取流程，一方面，在测试服务器上可以基于不同的查询标识和查询优先级来设置配置文件，另一方面，定义了需要基于查询优先级来确定查询标识以下载配置文件，也就是说，当管理员用户或者测试用户需要从一个测试用的程序对象切换到另一个新的测试用的程序对象时，只需要将新的测试用的程序对象对应的配置文件的查询关键字修改为查询优先级更高的查询关键字，这样一来可确保被测单元重启后能够基于查询优先级优先找到该更高查询优先级的查询关键字，再下载其对应的配置文件，进而下载配置文件所指示的程序对象完成新的测试，合理地利用了测试服务器的资源，提高了被测单元的测试效率。

本申请实施例可以针对测试的UUT没有安装任何操作系统的情况，在此情况下，并不能通过上述的配置平台等途径直接为UUT配置所需的配置文件，并且直接单独地为某个主板、某个测试场景设置测试服务器来加载所需的OS文件的方式存在诸如测试服务器资源利用率低的问题。因此，本申请实施例定义了新的与UUT测试相关的处理流程，能够获取到用户配置的关于某个UUT、不同测试场景下的配置文件和测试所需的各OS文件，完成UUT在各个测试场景下的测试。

简单来讲，UUT在通过网口建立与测试服务器的连接后，一方面需要从测试服务器获取引导执行程序，并且通过运行引导执行程序获取第一配置文件、OS文件，另一方面需要基于下载的OS文件在系统初始化阶段从配置平台获取为本次实际测试场景所配置的配置文件，通过从配置平台获取到的配置内容与目前下载到的OS文件的信息进行比较，如果一致则可以进行测试，如果不一致则需要更新测试服务器中的配置文件，以便于在UUT重启后，能够基于测试服务器中更新后的配置文件下载到本次的实际测试场景所需的OS文件。

请参见图3，是本申请实施例的一种对被测单元的测试方法的流程示意图，本申请所述的方法由测试服务器、配置平台、被测单元UUT之间交互来实现。所述方法可包括如下步骤。

S301：被测单元接入测试服务器，请求IP地址和引导执行程序。UUT的网口通过网线连接等方式接入测试服务器或者网络后，会在UUT上电的情况下自动向测试服务器请求IP地址和引导执行程序。通过被测单元的网口向测试服务器发送连接请求，所述被测单元的网口配置有与所述测试服务器建立连接的通信协议；根据所述测试服务器响应所述连接请求返回的连接信息建立与所述测试服务器之间的通信连接；通过建立的所述通信连接从所述测试服务器下载引导程序，并在被测单元上执行该引导程序以便于执行后续的诸如向测试服务器发送获取请求等步骤。

在一个可选的实施例中，UUT(被测单元)的网口中设置有PXE协议等通信协议，在上电开机之后，可以认为UUT(被测单元)的网口可以通过基于PXE协议等通信协议的网络接入功能，一方面能够在上电之后自动向诸如PXE服务器等测试服务器请求IP地址以建立与PXE服务器等测试服务器的连接，另一方面，在UUT通过网口获取到IP地址建立了与测试服务器的连接后，UUT向测试服务器请求引导执行程序，测试服务器下发引导执行程序，UUT基于引导执行程序执行下述的相关步骤。

S302：测试服务器向被测单元反馈响应消息，测试服务器通过响应消息将为被测单元分配的IP地址和引导执行程序先后发送给被测单元。

S303：被测单元运行引导执行程序获取被测单元的单元属性信息，单元属性信息包括：通信地址即IP地址、被测单元的硬件地址即MAC地址、被测单元所使用主板的板名等信息。也就是说，在本申请实施例中，以被测单元的单元属性信息作为查询标识或者说作为配置文件的查询关键字。在获取到单元属性信息之后，可以生成携带目标查询标识的获取请求，所述目标查询标识是根据单元属性信息得到的。

S304：被测单元向测试服务器发送获取请求，所述获取请求用于请求从测试服务器下载与目标查询标识对应的配置文件即第一配置文件。所述获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中发送给测试服务器，以便从测试服务器中获取配置文件，被测单元在执行引导执行程序的过程中，根据从被测单元本地读取的单元属性信息以及查询优先级，到测试服务器中下载第一配置文件。查询优先级指示了查询顺序，被测单元会优先基于查询优先级高的查询标识到测试服务器中尝试下载配置文件。

被测单元按照查询优先级、基于FTP协议等文件传输协议从测试服务器下载与查询标识对应的配置文件，查询标识是单元属性信息中其中一个。在一个可能的实施例中，默认设置的查询优先级为：01-Mac、02-Mac、IP地址、板名、默认字符串，例如，单元属性信息为：Mac地址00-11-22-33-44-55-AA，IP地址192.168.0.22，板名BN0000001的UUT，会生成01-00-11-22-33-44-55-AA、02-00-11-22-33-44-55-AA、C0A80016(IP地址从十进制到十六进制的转换后得到的)、BN0000001、default(默认字符串)查询标识，按照上述提及的查询优先级，被测单元可以先后到测试服务器中尝试下载这些查询标识对应的配置文件，并且将最先下载得到的配置文件确定为第一配置文件。需要说明的是，设置5级查询优先级(即01-Mac、02-Mac、IP地址、板名、默认字符串)用于举例，在一种可能的实现方式中，可以查询优先级的个数可以为6、7、8或其他数量。例如，查询优先级的个数为6时，查询优先级可以为：01-Mac、02-Mac、03-Mac、IP地址、板名、默认字符串。还需要说明的是，将十进制的IP地址转换为十六进制的格式后作为查询标识用于举例，在其他可能的实现方式中，也可以将十进制的IP地址转换为其他格式后作为查询标识，或者，不对IP地址进行格式转换，直接将十进制的IP地址作为查询标识。

被测单元根据本地可以获取得到的信息，从测试服务器查找与查询标识匹配的查询关键字对应的配置文件。具体的，被测单元通过本地执行的所述引导执行程序，按照上述提及的查询优先级先后尝试下载与查询标识匹配的查询关键字对应的配置文件，直到获取到第一配置文件为止，所述查询关键字可以是配置文件的文件名，也可以是配置文件中的一个配置内容信息。例如先以“01-00-11-22-33-44-55-AA”作为查询标识，到测试服务器中查找匹配的文件名尝试下载配置文件，如果在测试服务器中超时没有命中与“01-00-11-22-33-44-55-AA”对应的文件名，则继续以“02-00-11-22-33-44-55-AA”作为查询标识，到测试服务器中查找匹配的文件名尝试下载配置文件，直到下载到第一配置文件或者查找“default(默认字符串)”仍未命中对应的配置文件的文件名为止。

对于测试服务器而言，其存储有配置文件，各配置文件中包括查询关键字和程序对象信息，其具体示意如下表2所示；各配置文件中的程序对象信息指示了不同测试场景的程序对象；各配置文件中，包括的查询关键字与所述目标查询标识相同的配置文件被确定为第一配置文件。测试服务器作为一个提供配置文件下载服务、OS文件下载服务的服务器，会基于诸如FTP协议等文件传输协议向被测单元发送第一配置文件、OS文件等。对于在测试服务器中存储的任一配置文件，一方面这些配置文件对应有查询关键字key，通过这些查询关键字是否与被测单元发起的查询标识匹配来确定配置文件，这些查询关键字具体可以包括：针对某块主板而设置的01-Mac、02-Mac、IP地址对应的十六进制字符串、主板的板名、默认字符串中的任意一个，查询关键字可以以配置文件的文件名或者配置文件中的内容的形式存在；另一方面，在配置文件中包括程序对象信息，该程序对象信息包括针对测试所需的OS文件的名称以及版本号。这样一来，针对该块主板，可以配置不同测试场景下的OS文件，测试用户或者管理员用户可以根据实际测试场景的需要，为不同测试场景下的OS文件设置不同的配置文件，通过对配置文件的文件名等查询关键字的设置或调整，可以确保某个测试场景所需的配置文件能够被优先下载到，进而方便被测单元根据优先下载到的配置文件继续下载OS文件，同时还可以根据配置平台配置的针对测试场景实际所需的信息，对测试服务器存储的配置文件进行动态更新，使得测试服务器能够动态满足同一主板下构成的UUT在各种测试场景下的UUT测试。

在一个可能的实施例中，一种配置文件的示例如下表2所示：

表2

在配置文件中，可以通过“C0A80016”(由IP地址进行十进制到十六进制的转换而来)作为查询关键字设置为该配置文件的文件名，并且内容也可以包括查询关键字“C0A80016”，同时其中的程序对象信息包括：针对Linux(一种计算机操作系统)内核的OS文件：“kernel_XXXos_V1.01”，其中“kernel_XXXos”为OS文件的名称，“V1.01”为该OS文件的版本号；程序对象信息还包括：针对Linux文件系统的OS文件：“CloudTest_rootfs_XXXos_V1.12”，其中“CloudTest_rootfs_XXXos”为OS文件的名称，“V1.12”为版本号。需要说明的是，上述提及的配置文件中的程序对象信息指示的是适用于Linux平台的OS文件仅为举例，在其他可能的实现方式中，配置文件中的程序对象信息可以指示适用于非Linux平台的OS文件，例如，指示适用于Windows或其他操作系统的OS文件。

在一个可选的实施例中，在测试服务器中存储的配置文件的形式可以参考表2所示，基于表2所示的配置文件，被测单元基于被测单元的IP地址，将IP地址转换成十六进制的字符串之后，将IP地址转换后的字符串作为查询标识到服务器中查找并下载查询关键字与转换后的字符串匹配的配置文件，如果表2所示的配置文件的文件名与所述转换后的字符串匹配，则将表2所示的配置文件作为第一配置文件下载到被测单元中，否则，再基于转换后的十六进制的字符串继续查找其他配置文件，如果按照转换后的十六进制字符串在预设时间范围内一直无法下载得到对应的配置文件，则按照查询优先级，基于被测单元发送的板名(例如上述提及的“BN0000001”)继续查找并下载第一配置文件。如果基于板名也无法下载得到第一配置文件，则继续以“默认字符串”查找并下载第一配置文件。如果基于“默认字符串”也无法下载得到第一配置文件，则PXE失败，本次测试失败。在一些可能的实施例中，测试服务器可以在无法响应被测单元的文件传输请求为被测单元提供文件(配置文件或OS文件)的情况下，发出测试失败提示信息，可以写向指定的账号发送测试失败提示信息，以实现测试失败的提示功能。

S305：被测单元从测试服务器成功下载到第一配置文件之后，被测单元解析第一配置文件，得到第一配置文件上设置的程序对象信息。第一配置文件上可以记录一个或者多个程序对象各自对应的程序对象信息。

被测单元继续通过运行引导执行程序解析第一配置文件，并基于第一配置文件确定OS文件。例如测试服务器将表2所示的配置文件发送给被测单元，被测单元解析配置文件，最终确定两个OS文件的程序对象信息：Linux内核的OS文件：“kernel_XXXos_V1.01”和Linux文件系统的OS文件：“CloudTest_rootfs_XXXos_V1.12”。

若没有接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则生成携带新的目标查询标识的获取请求，新的目标查询标识是根据单元属性得到的，并且新的目标查询标识的查询优先级低于在该新的目标查询标识确定之前的目标查询标识的查询优先级。

S306：被测单元从测试服务器下载第一配置文件所指示的程序对象。测试服务器向被测单元提供第一配置文件指示的程序对象的下载服务，被测单元成功获取到程序对象。

被测单元根据第一配置文件中的程序对象信息，从测试服务器中获取对应名称和版本号的OS文件。例如，被测单元根据表2所示的第一配置文件中记录的程序对象信息包括的：“kernel_XXXos_V1.01”和“CloudTest_rootfs_XXXos_V1.12”，从测试服务器找到并下载对应的名称和版本号为kernel_XXXos_V1.01的Linux内核的OS文件，和对应的名称和版本号为“CloudTest_rootfs_XXXos_V1.12”的Linux文件系统的OS文件。可以理解的是，在测试服务器中，不同的OS文件的文件名或者文件夹名为名称+版本号的形式完成的命名，这样可以方便测试服务器快速响应被测单元的文件传输请求提供程序对象下载服务。

S307：被测单元确定所述程序对象的属性信息。被测单元加载程序对象以便获取所述程序对象的属性信息。也就是说被测单元会安装并运行从测试服务器下载到的第一配置文件所指示的程序对象，该程序对象可以为OS文件。在测试服务器存储的OS文件可以被认为是测试OS文件或者PXE OS文件，该OS文件所对应的系统是针对硬件测试定制，可以不在硬盘上运行，而是通过网络下载到内存里面加载并运行，UUT下电后就会丢失。可以理解的是，当第一配置文件记录的是多个程序对象信息时，在S307中确定的为多个程序对象的属性信息，如上述例子所述，被测单元会在Linux内核运行kernel_XXXos_V1.01的OS文件，而文件系统则运行CloudTest_rootfs_XXXos_V1.12的OS文件，同时会分别获取到：属性信息1即“kernel_XXXos_V1.01”，属性信息2即“CloudTest_rootfs_XXXos_V1.12”。

S308：被测单元向配置平台请求第二配置文件。该第二配置文件可以是测试人员或者管理员通过配置平台为本次需要测试的所述UUT配置确定的一个配置文件。在该第二配置文件中设置了针对所述被测单元在当前具体的测试场景下的程序对象信息，该第二配置文件的程序对象信息包括了当前测试场景下所需的OS文件名称和版本号。被测单元是在执行上述提及的引导执行程序的过程中，从配置平台请求第二配置文件，配置平台为被测单元提供第二配置文件的下载服务，以便于被测单元从配置平台成功下载到第二配置文件。当有多个UUT时，配置平台可以根据被测单元发起的文件传输请求，分别给不同测试需求的UUT返回不同的第二配置文件。第二配置文件可以基于主板的板名设置第二配置文件的查询关键字，这样一来，不同的主板所对应的被测单元可以基于携带有主板的板名的文件传输请求获取到所需的第二配置文件。当然也可以使用主板的硬件地址来区别不同的主板，设置第二配置文件中的查询关键字。

S309：被测单元从配置平台成功下载到第二配置文件之后，被测单元判断程序对象的属性信息与第二配置文件中设置的程序对象信息是否匹配。如果所述属性信息与获取到的第二配置文件包括的程序对象信息不匹配，则执行S310。如果匹配，则继续运行下载到的OS文件，基于下载到的OS文件完成本次UUT测试。主要判断的是OS文件的文件名和版本号，与第二配置文件中记载的文件名和版本号是否相同，如果相同则在S309中确定匹配，否则不匹配。所述第二配置文件包括的程序对象信息用于指示所述测试单元在本次测试场景下的程序对象，即第二配置文件指示了本次测试实际所需的程序对象；当所述被测单元重启之后，向测试服务器发送的获取请求用于请求从所述测试服务器的更新后的配置文件中下载对应的配置文件。

S310：被测单元根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件；其中，所述第二配置文件包括的程序对象信息用于指示所述测试单元在本次测试场景下的程序对象；当所述被测单元重启之后，向测试服务器发送的获取请求用于请求从所述测试服务器的更新后的配置文件中下载对应的配置文件。被测单元可以根据第二配置文件中设置的程序对象信息，生成一个可以被引导执行程序查找和识别的配置文件，为了区别，被测单元根据第二配置文件中设置的对象信息生成的配置文件被记录为第三配置文件。被测单元可以将第三配置文件发送给测试服务器，由测试服务器存储，在生成的第三配置文件中的查询关键字在查询优先级上高于第一配置文件中的查询关键字，这样一来，在被测单元重启之后，开始从S301重新开始执行相关步骤时，被测单元基于查询标识发送文件传输请求，会在测试服务器中优先查找到第三配置文件，进而优先获取到第三配置文件，而不会获取到第一配置文件。

举例来说，默认设置的查询优先级为：01-Mac、02-Mac、IP地址、板名、默认字符串，被测单元的Mac地址为00-11-22-33-44-55-AA，IP地址为192.168.0.22，板名为BN0000001。第一配置文件中的查询关键字为：板名BN0000001，程序对象信息为：TestOS V1.03。从配置平台获取的第二配置文件中的程序对象信息为：TestOS V1.04，由于TestOS V1.03与TestOS V1.04不一致，两者不匹配，因此，被测单元根据第二配置文件中的程序对象信息TestOS V1.04，生成第三配置文件，第三配置文件中的关键字的查询优先级需要高于第一配置文件中的查询优先级，以便于被测单元在下一次尝试下载配置文件时所述第三配置文件能够被优先查找并下载得到，因此，第三配置文件的查询关键字可以为：IP地址C0A80016，程序对象信息为：TestOS V1.04。将第三配置文件发送给测试服务器即可。当然，第三配置文件的查询关键字也可以为其他的关键字，只要查询优先级高于第一配置文件中的查询关键字即可，比如，第三配置文件的查询关键字可以为“01-00-11-22-33-44-55-AA”，这样一来，在被测单元重启之后执行引导执行程序时，第三配置文件很快会被下载得到。

在其他一些可能的实施例中，被测单元也可以将生成的第三配置文件发送给测试服务器，测试服务器直接替换原来的第一配置文件，也能实现测试服务器中配置文件的更新。

在S309中，被测单元的判断结果如果为所述属性信息与获取到的第二配置文件中设置的程序对象信息匹配，则继续运行所述程序对象，并按照所述程序对象中设置的测试规则对被测单元进行测试处理；同时，运行下载得到的程序对象的被测单元会根据所述程序对象中设置的配置更新信息，生成第四配置文件；并将所述第四配置文件发送给所述测试服务器；其中，所述第四配置文件中的查询关键字的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。按照所述程序对象中设置的测试规则，所述第四配置文件中的查询关键字的查询优先级可以根据需要被设置为最高查询优先级，也可以被设置为仅仅比当前进行测试时的程序对象所对应的配置文件的查询关键字的查询优先级高出一个等级。测试服务器中会存储第四配置文件，这样一来在被测单元重启执行下一次测试处理流程的时候，可优先获取到第四配置文件而不会获取到第一配置文件，基于第四配置文件下载程序对象重新执行上述的S305等步骤，以完成新的测试。

总的来说，在S310中UUT运行OS后，是通过运行该定制的OS文件中的OS初始化程序执行上述S307、S308以及S309，具体是通过OS初始化程序首先通过IT服务从配置平台下载得到第二配置文件，然后校验当前运行OS文件所对应系统的OS名称及版本与第二配置文件中配置的名称及版本是否一致，如果一致，就继续测试，不一致，继续基于OS初始化程序执行S310，并在执行完S310之后，向测试服务器发送用于触发测试服务器添加第三配置信息的配置添加信息、或者发送一些更新触发信息之后，直接重启UUT，以便于执行下一次处理过程，例如重新执行S301～S309或重新执行S301～S310。

再请参见图4，是本申请实施例的另一种对被测单元的测试方法的流程示意图，该方法可以在被测单元侧执行，被测单元通过网口从测试服务器请求IP地址，进而建立与测试服务器的连接，基于该连接从测试服务器获取引导执行程序，运行该引导执行程序之后，即可执行下述描述的步骤。本申请实施例所述方法的步骤如下。

S401：从测试服务器获取第一配置文件。从被测单元上电到从测试服务器获取第一配置文件的实现方式可参考前述实施例中相关内容的描述。

S402：获取所述第一配置文件上设置的程序对象信息所指示的程序对象。被测单元通过执行从测试服务器下载的引导执行程序来解析第一配置文件，进而获取所述第一配置文件上设置的程序对象信息所指示的程序对象。所述第一配置文件的样式可参考表2所示，所述程序对象主要是指OS文件。在第一配置文件上包括了查询关键字和程序对象信息，程序对象信息包括了OS文件的名称及版本号，同时，在测试服务器中存储的OS文件也是以名称和版本号进行的命名，这样一来，基于第一配置文件上的程序对象信息，可以找到对应的OS文件。在一个可能的实施例中，在第一配置文件的程序对象信息中还可以包括OS文件的存储地址，因此可以基于第一配置文件，直接到相应的存储地址下载OS文件。

S403：加载所述程序对象，并确定所述程序对象的属性信息。程序对象的属性信息包括OS文件的名称及版本号。加载下载到的OS文件，在程序初始化阶段，确定OS文件所对应系统的属性信息，该属性信息可以在程序初始化阶段自动获取得到，例如可以是在程序初始化阶段，根据第一配置文件中的程序对象信息所包括的OS文件的名称及版本号直接获取的。第一配置文件中的程序对象信息与下载得到的所述程序对象的属性信息相同。

S404：基于所述程序对象的属性信息和第二配置文件设置的程序对象信息进行匹配校验。也即判断所述程序对象的属性信息和第二配置文件设置的程序对象信息是否匹配。所述第二配置文件是从配置平台获取到的，测试人员或者管理人员通过配置平台设置第二配置文件中的程序对象信息，第二配置文件中的程序对象信息为被测单元本次测量过程中实际所需的OS文件的名称及版本号，第二配置文件中的程序对象信息与所述属性信息或者所述第一配置文件中的程序对象信息可以相同，也可以不相同。如果第二配置文件中的程序对象信息与所述属性信息或者所述第一配置文件中的程序对象信息相同，则确定所述S404的匹配校验通过，否则，则确定所述S404的匹配校验未通过。如果匹配校验未通过，则可以根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件，所述第二配置文件包括的程序对象信息用于指示所述测试单元在本次测试场景下的程序对象；当所述被测单元重启之后，向测试服务器发送的获取请求用于请求从所述测试服务器的更新后的配置文件中下载对应的配置文件。具体的更新处理可以包括根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；将所述第三配置文件发送至所述测试服务器；其中，所述第三配置文件包括查询关键字和程序对象信息，所述第三配置文件包括的查询关键字所对应的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。而根据所述第二配置文件中设置的程序对象信息，生成第三配置文件则可以包括如下步骤S405～S408。如果匹配校验通过，则执行下述的S410。

S405：判断是否获取到优先测试场景指示信息。该优先测试场景指示信息可以是从配置平台获取到的，在配置平台上，管理员或者测试人员可以设置一个特殊的标识或者特殊的字符串作为优先测试场景指示信息，该优先测试场景指示信息的作用在于：在程序对象的属性信息和第二配置文件中设置的程序对象信息的更新校验未通过，或者说程序对象的属性信息与第二配置文件中设置的程序对象信息不匹配的情况下，指示被测单元生成查询优先级为最高优先级的配置文件，以更新测试服务器中存储的配置文件。这样一来，在被测单元将查询优先级为最高优先级的配置文件(第三配置文件)发送给测试服务器之后，掉电后启动即可按照查询标识，根据查询优先级快速找到该第三配置文件，进而快速找到针对本次UUT测试所需的OS文件。而如果没有设置测试场景指示信息，则被测单元只需要生成一个查询优先级高于第一配置文件中查询关键字的查询优先级的第三配置文件即可，并不必生成最高查询优先级的第三配置文件。在S405中，如果存在测试场景指示信息，则执行下述的S407，否则，执行下述的S406。

S406：根据第一配置文件中的查询关键字，第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级比所述第一配置文件中包括的查询关键字的查询优先级高一个等级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。在S406生成的第三配置文件中，查询关键字的查询优先级相比于第一配置文件中的查询关键字的查询优先级高出一个等级，这样可以方便后续在有新的测试需求的情况下，再次设置一个相比于当前的第三配置文件更高的配置文件，以便于被测单元重启之后，该更高查询优先级的配置文件会先于第三配置文件被查询得到的。例如，默认设置的查询优先级为：01-Mac、02-Mac、IP地址、板名、默认字符串，而第一配置文件为：板名-TestOS V1.04，第二配置文件的程序对象信息为：TestOSV1.05，则生成的第三配置文件为：IP地址-TestOS V1.05，这样一来，在被测单元重启之后，会优先根据IP地址找到第三配置文件，而不会再次根据板名获取到原来的第一配置文件。

S407：根据第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级为最高优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。根据优先测试场景指示信息的指示，直接生成最高查询优先级的第三配置文件。例如，默认设置的查询优先级为：01-Mac、02-Mac、IP地址、板名、默认字符串，而第一配置文件为：(板名，TestOS V1.04)，第二配置文件的程序对象信息为：TestOS V1.05，则生成的第三配置文件为：(01-Mac，TestOS V1.05)，这样一来，在被测单元重启之后，会优先根据01-Mac找到第三配置文件，而不会再次根据板名获取到原来的第一配置文件。

S408：根据第三配置文件更新测试服务器中存储的配置文件。该更新主要包括将第三配置文件存储到测试服务器中。

S409：被测单元重启，以便于在重启之后重新执行本申请实施例的相关方法步骤。

S410：运行所述程序对象以完成测试。也就是说，无论是重启之前的流程还是重启之后流程，只要确定所述程序对象的属性信息和第二配置文件设置的程序对象信息相同，或者说第一配置文件中的程序对象信息和第二配置文件设置的程序对象信息相同，则可以继续运行所述程序对象，完成系统初始化以及后续的测试。

在一些可能的实施例中，在执行S410进行后续的测试过程中，可以根据OS文件的配置的下一项测试用的配置更新信息，生成第四配置文件；并将所述第四配置文件发送给所述测试服务器；其中，所述第四配置文件中的查询关键字的查询优先级高于新的第一配置文件(或者说所述第三配置文件)中包括的查询关键字的查询优先级，所述第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。按照所述程序对象中设置的测试规则，所述第四配置文件中的查询关键字的查询优先级可以根据需要被设置为最高查询优先级，也可以被设置为仅仅比当前进行测试时的程序对象所对应的配置文件的查询关键字的查询优先级高出一个等级。测试服务器中会存储第四配置文件，这样一来在被测单元重启执行下一次测试处理流程的时候，可优先获取到第四配置文件而不会获取到第一配置文件，基于第四配置文件下载程序对象重新执行上述的S403等相关步骤，以完成新的测试。

在一些可能的实施例中，所述测试服务器中存储的配置文件被允许按照删除指令进行删除处理；所述删除指令是在响应于针对测试服务器中的配置文件的删除操作时生成的；或者所述删除指令是在检测到自动删除条件被满足时生成的。即测试服务器可以根据需要对配置文件进行清除处理，可以是在第一配置文件或者第三配置文件所对应的查询关键字已经是最高查询优先级的情况下，通过手动发起删除操作、定时、或者周期性触发、或者在检测到存在最高查询优先级的查询关键字的配置文件等情况时，测试服务器自动进行已存储的部分或者全部配置文件的清除处理。清除处理包括将指定查询优先级的查询关键字对应的配置文件清除，例如将01-Mac、02-Mac对应的配置文件清除，也可以将所有的配置文件都清除。

再请参见图5，是本申请实施例的一种在测试用的OS文件版本存在更新的场景下的测试方法的流程示意图，所述方法在被测单元端执行，在本申请实施例中，在被测单元进行相应的测试处理前，可以根据需要进行如下设置。

第一，测试服务器上设置有引导执行程序，以便于被测单元通过网口接入到测试服务器之后，能够运行引导执行程序执行相应的操作。

第二，针对目标主板构成的被测单元，测试服务器上配置以该目标主板的板名为查询关键字的配置文件，并且配置文件的程序对象信息所对应的OS文件已经存储于测试服务器其中，被测单元下载并运行该OS文件之后能够完成目标测试场景的测试。以板名为查询关键字的配置文件可参考如下表3的示例。需要说明的是，表3中的OS文件名及版本号、板名是通过示意性的字符串进行举例说明，并非真实的OS文件名及版本号、板名。

表3

程序对象信息	TestOS V1.00
		查询关键字	ABC123DE0

第三，针对目标主板在目标测试场景下的测试用OS文件存在更新，对于发布的新版本，需要存储到测试服务区上，该更新的OS文件的文件名使用OS文件名称及其版本号命名。例如，版本更新之前OS文件的文件名为“TestOS V1.00”，版本更新之后的OS文件的文件名为“TestOS V1.01”。

第四，针对目标主板的目标测试场景，由于OS文件版本存在更新，因此，测试的用户可以在配置平台上位该目标主板对应的被测单元配置一个配置文件，即前述实施例中提及的第二配置文件，在该第二配置文件上，查询关键字依然使用目标主板的板名，只是程序对象信息修改为新的OS文件的名称及版本号。第二配置文件可以参考表4的示例。

表4

程序对象信息	TestOS V1.01
		查询关键字	ABC123DE0

基于上述提到的设置过程，本申请实施例的所述方法包括如图5所述的第一阶段501、第二阶段502以及第三阶段503的相关步骤，需要说明的是，三个阶段的划分仅仅是为了方便描述，并不对本申请实施例进行任何关于处理阶段的限制，具体试试时还可以有其他的阶段划分方式。

针对第一阶段501，包括S501：被测单元根据板名从测试服务器获取第一配置文件。被测单元与测试服务器之间建立连接、获取引导执行程序等相关过程可参考前述实施例中相关内容的描述。在本申请实施例，被测单元通过执行引导执行程序，可以向测试服务器发送获取请求，所述获取请求携带有目标查询标识即板名“ABC123DE0”，基于板名可以下载到如表3所示的第一配置文件。当然，被测单元可以是先基于01-Mac、02-Mac、IP地址均没有下载到第一配置文件的情况下，再次利用板名作为目标查询标识发起获取请求获取到如表3所示的第一配置文件的。

S502：被测单元从测试服务器下载所述第一配置文件指示的程序对象，即表3中TestOS V1.00的OS文件，运行该OS文件，以便在初始化阶段执行下述步骤。

针对第二阶段502，包括S503：判断程序对象的属性信息与第二配置文件中设置的程序对象信息是否匹配。在运行OS文件的过程中，一方面，确定OS文件的属性信息，即确定得到“TestOS V1.00”的属性信息，另一方面，基于板名从配置平台下载如表4所示的配置文件。如果S503的判断结果为匹配，则继续运行OS文件以便于完成目标测试场景的测试。如果S503的判断结果为不匹配，则执行下述的S504，在本申请实施例中，由于OS文件的属性信息“TestOS V1.00”与第二配置文件中的“TestOS V1.01”不相同，则确定S503的判断结果为不匹配。

S504：根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件。即根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；将所述第三配置文件发送至所述测试服务器。所述第三配置文件包括的查询关键字所对应的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。在本申请实施例中，使用02-Mac作为查询关键字生成第三配置文件，02-Mac的查询优先级高于板名的查询优先级，生成的第三配置文件如表5所示。在表5中02-Mac仅为示意，Mac可以是该目标主板实际的硬件地址。

表5

程序对象信息	TestOS V1.01
		查询关键字	02-Mac

S505：将第三配置文件上传给测试服务器。

S506：复位主板，被测单元重启。

针对第三阶段503，包括S507：重启上电上，建立与测试服务器的连接。通过被测单元的网口建立与测试服务器的连接过程同样参考前述实施例的描述。

S508：向测试服务器发送获取请求，所述获取请求携带有目标查询标识即02-Mac，优先下载到表5所示的第三配置文件，即优先获取到02-Mac的配置文件，将第三配置文件作为新的第一配置文件。原来的表3所示的第一配置文件不会被下载到。

S509：基于新的第一配置文件，下载TestOS V1.01的OS文件，基于下载到的OS文件可以完成对目标主板构成的被测单元在目标测试场景下的测试。

可以看出，通过上述步骤的描述，本申请实施例在对被测单元进行测试的过程中，支持测试迭代版本发布的情况下，新版本的OS文件的切换，测试切换简单便捷，提高了基于新的OS文件对被测单元进行测试的效率。

再请参见图6，是本申请实施例的一种在测试工序存在更新的场景下的测试方法的流程示意图，所述方法在被测单元端执行。在本申请实施例中，在被测单元进行相应的测试处理前，可以根据需要进行如下设置。

第二，针对目标主板构成的被测单元，测试服务器上配置有针对该被测单元的在至少两个工序下的配置文件及各个工序选所需的OS文件，例如，在测试服务器上，至少存在以该目标主板的硬件地址对应的02-Mac为查询关键字的配置文件，如表6所示，其中，1A-2B-33-44-55-6D作为目标主板的Mac地址的示意性字符串。

表6

程序对象信息	TestOS V1.00
		查询关键字	02-1A-2B-33-44-55-6D

第三，在完成一道工序的测试之后，需要进行下一道工序的测试时，在配置平台上配置第二配置文件，该第二配置文件如下表7所示。

表7

程序对象信息	Pre_OS V1.00
		查询关键字	02-1A-2B-33-44-55-6D

基于上述提到的设置过程，本申请实施例的所述方法包括如图6所述的第一阶段601、第二阶段602以及第三阶段603的相关步骤，需要说明的是，三个阶段的划分仅仅是为了方便描述，并不对本申请实施例进行任何关于处理阶段的限制，具体试试时还可以有其他的阶段划分方式。

针对第一阶段601，包括S601：被测单元根据02-Mac从测试服务器获取第一配置文件。被测单元与测试服务器之间建立连接、获取引导执行程序等相关过程可参考前述实施例中相关内容的描述。在本申请实施例，被测单元通过执行引导执行程序，可以向测试服务器发送获取请求，所述获取请求携带有目标查询标识即02-Mac：“02-1A-2B-33-44-55-6D”，可以下载到如表6所示的第一配置文件。当然，被测单元可以是先基于01-Mac没有下载到第一配置文件的情况下，再次利用02-Mac作为目标查询标识发起获取请求获取到如表6所示的第一配置文件的。

S602：被测单元从测试服务器下载所述第一配置文件指示的程序对象，即表6中TestOS V1.00的OS文件，运行该OS文件，以便在初始化阶段执行下述步骤。

针对第二阶段602，包括S603：判断程序对象的属性信息与第二配置文件中设置的程序对象信息是否匹配。在运行OS文件的过程中，一方面，确定OS文件的属性信息，即确定得到“TestOS V1.00”的属性信息，另一方面，基于02-Mac从配置平台下载如表7所示的配置文件。如果S603的判断结果为匹配，则继续运行OS文件以便于完成目标测试场景的测试。如果S603的判断结果为不匹配，则执行下述的S604，由于OS文件的属性信息“TestOS V1.00”与第二配置文件中的“Pre_OS V1.00”不相同，则确定S603的判断结果为不匹配。

S604：根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件。即根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；将所述第三配置文件发送至所述测试服务器。所述第三配置文件包括的查询关键字所对应的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。在本申请实施例中，使用01-Mac(01-1A-2B-33-44-55-6D)作为查询关键字生成第三配置文件，01-Mac的查询优先级高于01-Mac的查询优先级，生成的第三配置文件如表8所示。

表8

程序对象信息	Pre_OS V1.00
		查询关键字	01-1A-2B-33-44-55-6D

S605：将第三配置文件上传给测试服务器。

S606：复位主板，被测单元重启。

针对第三阶段603，包括S607：重启上电上，建立与测试服务器的连接。通过被测单元的网口建立与测试服务器的连接过程同样参考前述实施例的描述。

S608：向测试服务器发送获取请求，所述获取请求携带有目标查询标识即02-Mac，优先下载到表8所示的第三配置文件，即优先获取到01-Mac的配置文件，将第三配置文件作为新的第一配置文件。原来的表6所示的第一配置文件不会被下载到。

S609：基于新的第一配置文件，下载Pre_OS V1.00的OS文件，基于下载到的OS文件可以完成对目标主板构成的被测单元在目标测试场景下的测试。

可以看出，通过上述步骤的描述，本申请实施例在对被测单元进行测试的过程中，支持测试工序切换的情况下，OS文件类型的切换，测试切换简单便捷，提高了基于新的OS文件对被测单元进行测试的效率。

再请参见图7，是本发明实施例的一种指定测试场景下的测试方法的流程示意图，所述方法在被测单元端执行。在本申请实施例中，在被测单元进行相应的测试处理前，可以根据需要进行如下设置。

第二，针对目标主板构成的被测单元，测试服务器上设置了相应的配置文件，例如以板名、或默认字符串为查询关键字的配置文件，例如下表9所示。并存储了各种所需的OS文件，特别是本次针对目标主板构成的被测单元所指派的测试任务的OS文件。

表9

程序对象信息	TestOSV1.00
		查询关键字	ABC123DE0

第三，针对目标主板构成的被测单元完成了某个测试场景的测试之后，需要指派测试任务时，在配置平台上设置第二配置文件，并设置一个优先测试场景指示信息，优先测试场景指示信息具体可以通过一个特殊字符串来表示本次需要进行一个指定测试任务的测试。第二配置文件的形式如下表10所示。

表10

程序对象信息	TestOS V2.00
		查询关键字	ABC123DE0

基于上述提到的设置过程，本申请实施例的所述方法包括如图6所述的第一阶段701、第二阶段702以及第三阶段703的相关步骤，需要说明的是，三个阶段的划分仅仅是为了方便描述，并不对本申请实施例进行任何关于处理阶段的限制，具体试试时还可以有其他的阶段划分方式。

针对第一阶段701，包括S701：被测单元根据板名从测试服务器获取第一配置文件。被测单元与测试服务器之间建立连接、获取引导执行程序等相关过程可参考前述实施例中相关内容的描述。在本申请实施例，被测单元通过执行引导执行程序，可以向测试服务器发送获取请求，所述获取请求携带有目标查询标识即板名：“ABC567DE2”，可以下载到如表9所示的第一配置文件。当然，被测单元可以是先基于01-Mac、02-Mac等没有下载到第一配置文件的情况下，再次利用板名作为目标查询标识发起获取请求获取到如表9所示的第一配置文件的。

S702：被测单元从测试服务器下载所述第一配置文件指示的程序对象，即表9中TestOS V1.00的OS文件，运行该OS文件，以便在初始化阶段执行下述步骤。

针对第二阶段702，包括S703：判断程序对象的属性信息与第二配置文件中设置的程序对象信息是否匹配。在运行OS文件的过程中，一方面，确定OS文件的属性信息，即确定得到“TestOS V1.00”的属性信息，另一方面，基于板名：“ABC567DE2”从配置平台下载如表9所示的配置文件。如果S703的判断结果为匹配，则继续运行OS文件以便于完成目标测试场景的测试。如果S703的判断结果为不匹配，则执行下述的S704，由于OS文件的属性信息“TestOS V1.00”与第二配置文件中的“TestOS V 2.00”不相同，则确定S703的判断结果为不匹配。

S704：获取优先测试场景指示信息；由于配置平台中与第二配置文件关联配置了优先测试场景指示信息，因此，会基于优先测试场景指示信息来执行后续的更新步骤。

S705：根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件。即根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；将所述第三配置文件发送至所述测试服务器。所述第三配置文件中的查询关键字所对应的查询优先级为最高优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。在本申请实施例中，使用01-Mac(01-1A-2B-33-44-55-6D)作为查询关键字生成第三配置文件，01-Mac的查询优先级为最高级，生成的第三配置文件如表11所示。

表11

程序对象信息	TestOS V2.00
		查询关键字	01-1A-2B-33-44-55-6D

S706：将第三配置文件上传给测试服务器。

S707：复位主板，被测单元重启。

针对第三阶段703，包括S708：重启上电上，建立与测试服务器的连接。通过被测单元的网口建立与测试服务器的连接过程同样参考前述实施例的描述。

S709：向测试服务器发送获取请求，所述获取请求携带有目标查询标识即02-Mac，优先下载到表11所示的第三配置文件，将第三配置文件作为新的第一配置文件。原来的表9所示的第一配置文件不会被下载到。

S710：基于新的第一配置文件，下载TestOS V2.00的OS文件，基于下载到的OS文件可以完成对目标主板构成的被测单元在目标测试场景下的测试。

可以看出，通过上述步骤的描述，本申请实施例在对被测单元进行测试的过程中，支持同种主板差异化测试，提高了基于新的OS文件对被测单元进行测试的效率。

再请参见图8，是本申请实施例的一种对被测单元的测试装置的结构示意图，本申请实施例所述的装置可以应用在上述的被测单元中，所述装置包括如下单元。

通信单元801，用于向测试服务器发送获取请求，获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中，获取请求用于请求从测试服务器下载与目标查询标识对应的配置文件；

处理单元802，用于若接收到测试服务器返回的与目标查询标识对应的第一配置文件，则从测试服务器下载第一配置文件指示的程序对象；在被测单元中加载从测试服务器下载的程序对象，以完成对被测单元的测试。

在一个可选的实施例中，测试服务器中存储有配置文件，各配置文件中包括查询关键字和程序对象信息；各配置文件中的程序对象信息指示了不同测试场景的程序对象；各配置文件中，包括的查询关键字与目标查询标识相同的配置文件被确定为第一配置文件。

在一个可选的实施例中，在用于在被测单元中加载从测试服务器下载的程序对象之后，处理单元802，还用于确定该程序对象的属性信息；如果该属性信息与获取到的第二配置文件包括的程序对象信息不匹配，则根据第二配置文件中设置的程序对象信息更新测试服务器中存储的配置文件；其中，第二配置文件包括的程序对象信息用于指示测试单元在本次测试场景下的程序对象；当被测单元重启之后，向测试服务器发送的获取请求用于请求从测试服务器的更新后的配置文件中下载对应的配置文件。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息更新测试服务器中存储的配置文件时，处理单元802，用于根据第二配置文件中设置的程序对象信息，生成第三配置文件；将第三配置文件发送至测试服务器；其中，第三配置文件包括查询关键字和程序对象信息，第三配置文件包括的查询关键字所对应的查询优先级高于第一配置文件中包括的查询关键字的查询优先级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息，生成第三配置文件时，处理单元802，用于判断是否获取到优先测试场景指示信息；若是，则根据第二配置文件中的程序对象信息，生成第三配置文件，其中，第三配置文件中的查询关键字所对应的查询优先级为最高优先级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息，生成第三配置文件时，处理单元802，用于判断是否获取到优先测试场景指示信息；若否，则根据第一配置文件中的查询关键字，第二配置文件中的程序对象信息，生成第三配置文件，其中，第三配置文件中的查询关键字所对应的查询优先级比第一配置文件中包括的查询关键字的查询优先级高一个等级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于向测试服务器发送获取请求之前，处理单元802，还用于获取被测单元的单元属性信息，所述单元属性信息包括：被测单元的硬件地址、通信地址、被测单元所使用主板的板名中的任意一种或多种；生成携带目标查询标识的获取请求，目标查询标识是根据单元属性信息得到的。

在一个可选的实施例中，处理单元802，还用于若没有接收到测试服务器返回的与目标查询标识对应的第一配置文件，则生成携带新的目标查询标识的获取请求，新的目标查询标识是根据单元属性得到的，并且新的目标查询标识的查询优先级低于在该新的目标查询标识确定之前的目标查询标识的查询优先级。

在一个可选的实施例中，处理单元802，还用于如果所述属性信息与获取到的第二配置文件中设置的程序对象信息匹配，则继续运行所述程序对象，按照所述程序对象中设置的测试规则对被测单元进行测试处理；根据所述程序对象中设置的配置更新信息，生成第四配置文件；将所述第四配置文件发送给所述测试服务器；其中，所述第四配置文件中的查询关键字的查询优先级高于第一配置文件中包括的查询关键字的查询优先级，第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。

在一个可选的实施例中，在用于向测试服务器发送获取请求之前，处理单元802，还用于通过被测单元的网口向测试服务器发送连接请求，被测单元的网口配置有与测试服务器建立连接的通信协议；根据测试服务器响应所述连接请求返回的连接信息建立与测试服务器之间的通信连接；通过建立的通信连接从测试服务器下载引导程序，并在被测单元上执行该引导程序以便于执行所述向测试服务器发送获取请求的步骤。

在一个可选的实施例中，测试服务器中存储的配置文件被允许按照删除指令进行删除处理；删除指令是在响应于针对测试服务器中的配置文件的删除操作时生成的；或者删除指令是在检测到自动删除条件被满足时生成的。

在一个可选的实施例中，被测单元为由主板和功能组件构建的计算设备，所述功能组件包括：背板、板卡、处理器、介质中的任意一种或多种。

本申请实施例中对被测单元的测试装置中各单元的具体实现及该装置能够实现的有益效果可参考前述实施例中相关内容的描述，在此不赘述。

再请参见图9，是本申请实施例的一种计算设备的结构示意图，本发明实施例的所述计算设备90包括处理器901。

处理器901可以具有存储功能，能够存储必要的计算机程序和数据。可选的，在计算设备90中，也可以设置独立的存储器902。处理器901可以具有数据收发功能，能够与其他设备进行通信。可选的，在计算设备90中，也可以设置独立的数据通信单元，例如收发器903，用于收发数据。处理器901、存储器902、收发器903之间可以通过总线连接，该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器901中存储有计算机程序，处理器902调用计算机程序实现如上述部分或者全部实施例中所述的方法。

在一个实施例中，处理器902，用于向测试服务器发送获取请求，获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中，获取请求用于请求从测试服务器下载与目标查询标识对应的配置文件；若接收到测试服务器返回的与目标查询标识对应的第一配置文件，则从测试服务器下载第一配置文件指示的程序对象；在被测单元中加载从测试服务器下载的程序对象，以完成对被测单元的测试。

在一个可选的实施例中，在用于在被测单元中加载从测试服务器下载的程序对象之后，处理器902，还用于确定所述程序对象的属性信息；如果所述属性信息与获取到的第二配置文件包括的程序对象信息不匹配，则根据第二配置文件中设置的程序对象信息更新测试服务器中存储的配置文件；其中，第二配置文件包括的程序对象信息用于指示测试单元在本次测试场景下的程序对象；当被测单元重启之后，向测试服务器发送的获取请求用于请求从测试服务器的更新后的配置文件中下载对应的配置文件。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息更新测试服务器中存储的配置文件时，处理器902，用于根据第二配置文件中设置的程序对象信息，生成第三配置文件；将第三配置文件发送至测试服务器；其中，第三配置文件包括查询关键字和程序对象信息，第三配置文件包括的查询关键字所对应的查询优先级高于第一配置文件中包括的查询关键字的查询优先级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息，生成第三配置文件时，处理器902，用于判断是否获取到优先测试场景指示信息；若是，则根据第二配置文件中的程序对象信息，生成第三配置文件，其中，第三配置文件中的查询关键字所对应的查询优先级为最高优先级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于根据第二配置文件中设置的程序对象信息，生成第三配置文件时，处理器902，用于判断是否获取到优先测试场景指示信息；若否，则根据第一配置文件中的查询关键字，第二配置文件中的程序对象信息，生成第三配置文件，其中，第三配置文件中的查询关键字所对应的查询优先级比第一配置文件中包括的查询关键字的查询优先级高一个等级，第三配置文件包括的程序对象信息为第二配置文件中包括的程序对象信息。

在一个可选的实施例中，在用于向测试服务器发送获取请求之前，处理器902，还用于获取被测单元的单元属性信息，所述单元属性信息包括：被测单元的硬件地址、通信地址、被测单元所使用主板的板名中的任意一种或多种；生成携带目标查询标识的获取请求，目标查询标识是根据单元属性信息得到的。

在一个可选的实施例中，处理器902，还用于若没有接收到测试服务器返回的与目标查询标识对应的第一配置文件，则生成携带新的目标查询标识的获取请求，新的目标查询标识是根据单元属性得到的，并且新的目标查询标识的查询优先级低于在该新的目标查询标识确定之前的目标查询标识的查询优先级。

在一个可选的实施例中，处理器902，还用于如果所述属性信息与获取到的第二配置文件中设置的程序对象信息匹配，则继续运行所述程序对象，按照所述程序对象中设置的测试规则对被测单元进行测试处理；根据所述程序对象中设置的配置更新信息，生成第四配置文件；将第四配置文件发送给测试服务器；其中，第四配置文件中的查询关键字的查询优先级高于第一配置文件中包括的查询关键字的查询优先级，第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。

在一个可选的实施例中，在用于向测试服务器发送获取请求之前，处理器902，还用于通过被测单元的网口向测试服务器发送连接请求，被测单元的网口配置有与测试服务器建立连接的通信协议；根据测试服务器响应所述连接请求返回的连接信息建立与测试服务器之间的通信连接；通过建立的所述通信连接从测试服务器下载引导程序，并在被测单元上执行该引导程序以便于执行所述向测试服务器发送获取请求的步骤。

在一个可选的实施例中，被测单元为由主板和功能组件构建的计算设备，所述功能组件包括：背板、板卡、处理器902、介质中的任意一种或多种。

本申请实施例中对被测单元的计算设备中处理器902的具体实现及该装置能够实现的有益效果可参考前述实施例中相关内容的描述，在此不赘述。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序包括程序指令，该程序指令被计算机执行时实现上述任一方法实施例的功能。

上述计算机可读存储介质包括但不限于快闪存储器、硬盘、固态硬盘。

本申请还提供了一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。

本申请所描述的方案可通过各种方式来实现。例如，这些技术可以用硬件、软件或者软硬件结合的方式来实现。对于硬件实现，用于在计算设备(例如，被测单元、测试服务器)处执行这些技术的处理单元，可以实现在一个或多个通用处理器、数字信号处理器(digital signal processor，DSP)、数字信号处理器件、专用集成电路(applicationspecific integrated circuit，ASIC)、可编程逻辑器件、现场可编程门阵列(fieldprogrammable gate array，FPGA)、或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合中。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是实现上述任一实施例中的被测单元、测试服务器的功能的装置。示例性的，该装置可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

本申请中对于使用单数表示的元素旨在用于表示“一个或多个”，而并非表示“一个且仅一个”，除非有特别说明。本申请中，在没有特别说明的情况下，“至少一个”旨在用于表示“一个或者多个”，“多个”旨在用于表示“两个或两个以上”。

另外，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A可以是单数或者复数，B可以是单数或者复数。

本申请中的预设(如预设时间范围)可以理解为定义、预先定义、存储、预存储、预协商、预配置、固化、或预烧制。

本领域普通技术人员可以理解，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请中各个实施例之间相同或相似的部分可以互相参考。在本申请中各个实施例、以及各实施例中的各个实施方式/实施方法/实现方法中，如果没有特殊说明以及逻辑冲突，不同的实施例之间、以及各实施例中的各个实施方式/实施方法/实现方法之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例、以及各实施例中的各个实施方式/实施方法/实现方法中的技术特征根据其内在的逻辑关系可以组合形成新的实施例、实施方式、实施方法、或实现方法。以上所述的本申请实施方式并不构成对本申请保护范围的限定。

Claims

1.一种对被测单元的测试方法，其特征在于，包括：

向测试服务器发送获取请求，所述获取请求携带有目标查询标识；其中，不同的查询标识具有不同的查询优先级，查询优先级高的查询标识会优先作为目标查询标识被携带在获取请求中，所述获取请求用于请求从所述测试服务器下载与所述目标查询标识对应的配置文件；

若接收到所述测试服务器返回的与所述目标查询标识对应的第一配置文件，则从测试服务器下载所述第一配置文件指示的程序对象；

在被测单元中加载从测试服务器下载的程序对象，以完成对被测单元的测试。

2.如权利要求1所述的方法，其特征在于，所述测试服务器中存储有配置文件，各配置文件中包括查询关键字和程序对象信息；

各配置文件中的程序对象信息指示了不同测试场景的程序对象；

各配置文件中，包括的查询关键字与所述目标查询标识相同的配置文件被确定为第一配置文件。

3.如权利要求1所述的方法，其特征在于，所述在被测单元中加载从测试服务器下载的程序对象之后，所述方法还包括：

确定所述程序对象的属性信息；

如果所述属性信息与获取到的第二配置文件包括的程序对象信息不匹配，则根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件；其中，所述第二配置文件包括的程序对象信息用于指示所述测试单元在本次测试场景下的程序对象；

当所述被测单元重启之后，向测试服务器发送的获取请求用于请求从所述测试服务器的更新后的配置文件中下载对应的配置文件。

4.如权利要求3所述的方法，其特征在于，所述根据所述第二配置文件中设置的程序对象信息更新所述测试服务器中存储的配置文件，包括：

根据所述第二配置文件中设置的程序对象信息，生成第三配置文件；

将所述第三配置文件发送至所述测试服务器；其中，所述第三配置文件包括查询关键字和程序对象信息，所述第三配置文件包括的查询关键字所对应的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

5.如权利要求4所述的方法，其特征在于，所述根据所述第二配置文件中设置的程序对象信息，生成第三配置文件，包括：

判断是否获取到优先测试场景指示信息；

若是，则根据第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级为最高优先级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

6.如权利要求4所述的方法，其特征在于，所述根据所述第二配置文件中设置的程序对象信息，生成第三配置文件，包括：

判断是否获取到优先测试场景指示信息；

若否，则根据第一配置文件中的查询关键字，第二配置文件中的程序对象信息，生成第三配置文件，其中，所述第三配置文件中的查询关键字所对应的查询优先级比所述第一配置文件中包括的查询关键字的查询优先级高一个等级，所述第三配置文件包括的程序对象信息为所述第二配置文件中包括的程序对象信息。

7.如权利要求1所述的方法，其特征在于，所述向测试服务器发送获取请求之前，还包括：

获取被测单元的单元属性信息，所述单元属性信息包括：被测单元的硬件地址、通信地址、被测单元所使用主板的板名中的任意一种或多种；

生成携带目标查询标识的获取请求，所述目标查询标识是根据单元属性信息得到的。

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

9.如权利要求3所述的方法，其特征在于，还包括：

如果所述属性信息与获取到的第二配置文件中设置的程序对象信息匹配，则继续运行所述程序对象，按照所述程序对象中设置的测试规则对被测单元进行测试处理；

根据所述程序对象中设置的配置更新信息，生成第四配置文件；

将所述第四配置文件发送给所述测试服务器；

其中，所述第四配置文件中的查询关键字的查询优先级高于所述第一配置文件中包括的查询关键字的查询优先级，所述第四配置文件包括的程序对象信息为所述配置更新信息所指示的程序对象信息。

10.如权利要求1-9任一项所述的方法，其特征在于，所述向测试服务器发送获取请求之前，还包括：

通过被测单元的网口向测试服务器发送连接请求，所述被测单元的网口配置有与所述测试服务器建立连接的通信协议；

根据所述测试服务器响应所述连接请求返回的连接信息建立与所述测试服务器之间的通信连接；

通过建立的所述通信连接从所述测试服务器下载引导程序，并在被测单元上执行该引导程序以便于执行所述向测试服务器发送获取请求的步骤。

11.如权利要求1-9任一项所述的方法，其特征在于，所述测试服务器中存储的配置文件被允许按照删除指令进行删除处理；

所述删除指令是在响应于针对测试服务器中的配置文件的删除操作时生成的；或者

所述删除指令是在检测到自动删除条件被满足时生成的。

12.如权利要求1-9任一项所述的方法，其特征在于，所述被测单元为由主板和功能组件构建的计算设备，所述功能组件包括：背板、板卡、处理器、介质中的任意一种或多种。

13.一种计算设备，其特征在于，该计算设备包括处理器，该处理器用于执行如权利要求1-11任一项所述的方法。

14.一种测试系统，其特征在于，该系统包括：被测单元、测试服务器、配置平台；

所述测试服务器，用于存储测试用的配置文件和程序对象；

所述配置平台，用于配置关于所述测试单元在本次测试场景下的程序对象信息；

所述被测单元，用于执行如权利要求1-11任一项所述的方法。