CN115114154A - 处理方法、固件测试方法、装置、设备、系统及存储介质 - Google Patents

Abstract

本申请提供一种处理方法、固件测试方法、装置、设备、系统及存储介质，处理方法应用于测试系统，测试系统包括计算机设备；方法包括：通过计算机设备获取待裁剪的目标测试任务；通过计算机设备基于目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；通过计算机设备删除目标测试子项的属性信息。这样可以自动将目标测试任务中存在的测试效果影响不明显的测试子项剔除，降低测试用时，提高测试效率。同时可以自动化生成最新的测试任务，从而无需工程师进行测试任务的重配置，降低生成测试任务所需的人力成本和时间成本。

Description

处理方法、固件测试方法、装置、设备、系统及存储介质

技术领域

本申请涉及测试领域，具体而言，涉及一种处理方法、固件测试方法、装置、设备、系统及存储介质。

背景技术

为了避免将有功能缺陷的芯片或固件投入市场，带来不可预计的经济和信誉损失，芯片或固件在出厂前会进行测试。

在进行芯片或固件的测试时，会预先设定好测试任务，并交由安装好芯片的DUT(Device Under Test，被测器件)进行执行，以实现测试。

目前测试任务一般由工程师根据测试需要进行配置。但是，受限于配置测试任务的工程师的经验，在测试任务中可能会存在一些测试效果影响不明显的测试子项，对这些测试子项进行测试会提高测试用时，降低测试效率。

发明内容

本申请实施例的目的在于提供一种处理方法、固件测试方法、装置、设备、系统及存储介质，用以降低生成测试任务所需的人力成本和时间成本，提高测试效率。

本申请实施例提供了一种处理方法，所述方法应用于测试系统，所述测试系统包括计算机设备；所述方法包括：

通过所述计算机设备获取待裁剪的目标测试任务；所述目标测试任务中包括至少一个子任务文件，每个所述子任务文件中包括至少一个测试子项的属性信息；通过所述计算机设备基于所述目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；通过所述计算机设备删除所述目标测试子项的属性信息。

在上述实现过程中，通过计算机设备基于目标测试任务的各测试子项的历史测试数据，获取到不满足预设条件的目标测试子项，从而可以将目标测试任务中这些目标测试子项的属性信息进行删除。通过这样的方式，只需合理设置预设条件，就可以自动将目标测试任务中存在的测试效果影响不明显的测试子项剔除，降低测试用时，提高测试效率。同时，通过上述实现方式可以自动化生成最新的测试任务，从而无需工程师进行测试任务的重配置，降低生成测试任务所需的人力成本和时间成本。

进一步地，所述历史测试数据包括所述测试子项的测试过程数据、测试结果数据和测试完成时长；其中：所述目标测试子项用于表征在被测试时出现错误的次数少于第一阈值的所述测试子项；或，所述目标测试子项用于表征测试结果满足预设结果的次数大于第二阈值的所述测试子项；或，所述目标测试子项用于表征在被测试时的测试完成时长大于第三阈值的所述测试子项。

如果一个测试子项在测试过程中，所有的被测对象的表现均很良好，那么意味着该测试子项对测试效果的影响不明显，因此可以将其作为目标测试子项进行删除。而在上述实现过程中，通过将被测试时出现错误的次数少于第一阈值的测试子项，或测试结果满足预设结果的次数大于第二阈值的测试子项作为目标测试子项，则可以有效剔除对测试效果影响不明显的这些测试子项，从而仅保留测试效果更好的测试子项，从而降低测试用时，提高测试效率。此外，如果测试子项在测试过程中用时特别长，则该测试子项会严重拖累整个测试过程的效率，因此为了提高测试效率，也可以将被测试时的测试完成时长大于第三阈值的测试子项作为目标测试子项进行删除，从而降低测试用时，提高测试效率。

进一步地，所述测试子项的属性信息包括：所述测试子项对应的测试子项用例所在设备的地址，以及所述测试子项对应的测试子项用例的唯一标识。

在上述实现过程中，通过将试子项对应的测试子项用例所在设备的地址和测试子项对应的测试子项用例的唯一标识作为属性信息携带于测试任务中，这就可以使得测试任务内无需携带具体的测试子项用例，从而可以降低测试任务的大小，同时也可以便于不同测试子项用例在不同测试任务中的复用。

进一步地，在删除所述目标测试子项的属性信息之后，所述方法还包括：基于未被删除属性信息的各所述测试子项的出错率，对各所述测试子项进行降序排列；其中，相同出错率的各所述测试子项之间，按照测试完成时长进行升序排列。

这样，在测试子项之间没有执行依赖关系，且待测DUT数量少于测试任务的子任务文件的情况，可以按照被测试时各测试子项的出错率从高到低进行排序，且相同出错率的测试子项按测试完成时长从短到长进行排序，从而可以使得出错率高的测试子项优先被测试，使得相同出错率的测试子项中，测试完成时长短的测试子项优先被测试，从而使得整个测试过程中，出现执行失败的时间节点尽可能提前，从而降低测试用时，提高测试效率。

进一步地，在删除所述目标测试子项的属性信息之后，所述方法还包括：基于未被删除属性信息的各所述测试子项的测试完成时长，重新构建所述目标测试任务的各子任务文件。

在上述实现过程中，在删除目标测试子项的属性信息之后，通过获取未被删除属性信息的各测试子项之间的执行依赖关系，进而基于未被删除属性信息的各测试子项之间的执行依赖关系，以及未被删除属性信息的各测试子项的测试完成时长，重新构建目标测试任务的各子任务文件，这就可以重新形成测试时长大致相同的新的子任务文件，从而可以便于后续进行子任务文件到不同待测DUT的分发，提高测试效率。

进一步地，所述测试系统还包括待测DUT，所述计算机设备和所述待测DUT建立有通信连接；所述目标测试任务为针对待测固件的测试任务；在删除所述目标测试子项的属性信息之后，所述方法还包括：通过所述计算机设备将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到所述各子任务文件的测试结果；其中，每个所述待测DUT集合由至少一个所述待测DUT构成。

在上述实现过程中，通过将目标测试任务的各子任务文件分别分配给不同的待测DUT集合，从而可以通过不同的待测DUT集合来分别执行相应的子任务文件，这样对于不存在执行依赖关系(即对某一子任务文件的执行，需要依赖于对其他子任务文件的执行结果)的子任务文件之间，就可以实现子任务文件的并行执行，从而提高对于待测固件的测试效率。

进一步地，将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：在所述目标测试任务的各子任务文件之间具有执行先后顺序时，按照各所述子任务文件的执行先后顺序，将在先执行的所述子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合。

在上述实现过程中，通过对具有执行先后顺序的各子任务文件，按照各子任务文件的执行先后顺序，依次进行下发。这样，如果在测试任务的执行过程中，待测试固件更新了新版本，需要对新版本的待测试固件进行测试，则可以在已执行完子任务文件的待测DUT集合中，重新布置新版本的待测试固件并进行测试，从而实现新旧两个版本的待测试固件的并行测试，从而可以减少整体上的测试周期，提高整体上的测试效率。

进一步地，所述待测DUT上搭载有系统启动固件；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；按照各所述子任务文件的执行先后顺序，将在先执行的所述子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合，包括：按照所述系统启动固件的各子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

应理解，系统启动固件是用于系统内最重要的固件之一，直接决定了系统启动过程的安全性。在上述实现过程中，通过按照系统启动固件的各子固件的运行先后顺序，依次分配各子固件对应的子任务文件，从而可以保证对于系统启动固件的测试过程与系统启动固件的运行过程一致，从而保证测试效果。

进一步地，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；所述目标测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，包括：将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行；在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

在上述实现过程中，通过先对运行于可信执行环境的可信固件进行测试，再对运行于普通执行环境的普通固件进行测试，从而可以符合系统启动的过程，保证测试结果的可靠性。

进一步地，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；所述普通固件包括：BL33固件和操作系统OS固件；其中，所述系统启动固件的各所述子固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件、BL33固件、OS固件；所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件；所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

进一步地，接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

在上述实现过程中，通过在可信执行环境中执行第一子任务文件，在普通执行环境中执行第二子任务文件，从而可以提高对安全性要求更高的子固件的测试安全性。

进一步地，将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：在所述测试任务的各子任务文件之间不具有执行先后顺序时，将各所述子任务文件随机发送给各空闲的待测DUT集合。

在上述实现过程中，通过将不具有执行先后顺序的各子任务文件随机发送给各空闲的待测DUT集合，从而可以使得各待测DUT集合并行执行各子任务文件，从而使得整个测试完成时间等于用时最长的子任务文件的执行完成时间，从而可以有效降低测试周期，提高测试效率。

本申请实施例还提供了一种处理装置，应用于测试系统的计算机设备中，所述测试系统包括所述计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述装置包括：获取模块，用于获取待裁剪的目标测试任务；所述目标测试任务中包括至少一个子任务文件，每个所述子任务文件中包括至少一个测试子项的属性信息；所述获取模块，还用于基于所述目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；处理模块，用于删除所述目标测试子项的属性信息。

应理解，系统启动固件是计算机设备中的核心固件，系统固件的安全性与可靠性直接影响到计算机设备的安全性与可用性。因此在开发出一版系统启动固件后，需要对系统启动固件进行测试，以判断该版系统启动固件的可用性。

为实现对于系统启动固件的测试，本申请实施例提供了一种固件测试方法，所述方法应用于测试系统，所述测试系统包括计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；所述方法包括：

通过所述计算机设备获取所述系统启动固件对应的测试任务；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；通过所述计算机设备将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到测试结果；其中，每个所述待测DUT集合由至少一个所述待测DUT构成。

在上述实现过程中，通过计算机设备将对应于系统启动固件的各子固件的子任务文件分别分配给不同的待测DUT集合，以得到测试结果。这样，就可以实现对于系统启动固件的拆分，实现对于系统启动固件的测试。此外，在开发过程中，可能会出现连续开发多各版本的系统启动固件的情况。而在上述实现过程中，可以通过不同的待测DUT集合来分别执行相应的子任务文件，这样，如果在测试任务的执行过程中，系统启动固件更新了新版本，需要对新版本的系统启动固件进行测试，则可以在已执行完子任务文件的待测DUT集合中，重新布置新版本的系统启动固件并进行测试，从而实现新旧两个版本的系统启动固件的并行测试，可以减少整体上的测试周期，提高整体上的测试效率。

进一步地，所述将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

在上述实现过程中，通过按照系统启动固件的各子固件的运行先后顺序，依次分配各子固件对应的子任务文件，从而可以保证对于系统启动固件的测试过程与系统启动固件的运行过程一致，从而保证测试效果。

进一步地，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；所述测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，包括：将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行；在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

在上述实现过程中，通过先对运行于可信执行环境的可信固件进行测试，再对运行于普通执行环境的普通固件进行测试，从而可以符合系统启动的过程，保证测试结果的可靠性。

进一步地，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；其中，各所述可信固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件；所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件。

进一步地，所述普通固件包括：BL33固件和操作系统OS固件；所述BL33固件先于所述OS固件运行；所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

进一步地，接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

在上述实现过程中，通过在可信执行环境中执行第一子任务文件，在普通执行环境中执行第二子任务文件，从而可以提高对安全性要求更高的子固件的测试安全性。

本申请实施例还提供了一种固件测试装置，应用于测试系统的计算机设备中，所述测试系统包括所述计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；所述装置包括：获取单元，用于获取所述系统启动固件对应的测试任务；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；分配单元，用于将所述测试任务的各子任务文件分别分配给不同的待测DUT集合执行，以通过构成各所述待测DUT集合的待测DUT的执行结果，得到测试结果。

本申请实施例还提供了一种测试系统，包括：计算机设备，以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；

所述计算机设备用于获取所述系统启动固件对应的测试任务，并将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到测试结果；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；其中，每个所述待测DUT集合由至少一个所述待测DUT构成；

所述待测DUT用于执行所分配的子任务文件，并向所述计算机设备反馈对所述子任务文件的执行结果，以使所述计算机设备根据所述执行结果确定所述测试结果。

本申请实施例还提供了一种计算机设备，包括通信模组、处理器和存储器；所述通信模组用于与待测DUT通信连接；所述处理器用于执行所述存储器中存储的一个或多个程序，以实现上述任一种的处理方法，或实现上述任一种的固件测试方法。

本申请实施例中还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任一种的处理方法，或实现上述任一种的固件测试方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种测试系统的基本结构示意图；

图2为本申请实施例提供的一种处理方法的流程示意图；

图3为本申请实施例提供的一种具体的测试系统的结构示意图；

图4为本申请实施例提供的一种固件测试方法的流程示意图；

图5为本申请实施例提供的一种系统启动固件的模块化示意图；

图6为本申请实施例提供的一种更具体的测试系统的结构示意图；

图7为本申请实施例提供的一种处理装置的结构示意图；

图8为本申请实施例提供的一种固件测试装置的结构示意图；

图9为本申请实施例提供的一种计算机设备的基本结构示意图；

图10为本申请实施例提供的一种计算机设备的软硬件双层面的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。需要说明的是，在不冲突的情况下，本申请提供的各实施例、实施例中的各实施方式以及特征可以相互组合。

实施例一：

为了降低生成测试任务所需的人力成本和时间成本，提高测试效率，本申请实施例中提供了一种测试系统。可以参见图1所示，测试系统包括计算机设备。除此之外，测试系统还可以包括与计算机设备通信连接的待测DUT。计算机设备和待测DUT之间可以相互配合，实现对于芯片或固件的测试。

在本申请实施例中，还提供了一种可以应用于测试系统的计算机设备中的处理方法，参见图2所示，包括：

S201：获取待裁剪的目标测试任务。

应理解，本申请实施例中，计算机设备内可以预先配置有一个或多个测试任务。而目标测试任务为当前选中的，需要进行裁剪以用于进行芯片或固件测试的测试任务。

本申请实施例中，目标测试任务中可以包括一个或多个子任务文件，每个子任务文件中可以包括一个或多个测试子项的属性信息。子任务文件为下发至待测DUT进行执行的最小单元。

需要说明的是，所谓测试子项是指需要进行的整个测试过程中所需要进行测试的各个子项目，各测试子项的测试通常是通过配置的测试子项用例来实现。

因此，在本申请实施例的一种可选实施方式中，可以将预先配置的各测试子项用例存储在某一或些测试用例服务器或数据库中，然后将所需的测试子项的对应的测试子项用例所在设备的地址，以及测试子项对应的测试子项用例的唯一标识(例如可以是测试子项用例的文件名)作为测试子项的属性信息记录在子任务文件中，从而待测DUT在执行子任务文件时，可以基于子任务文件中记录的测试子项用例所在设备的地址和测试子项用例的唯一标识下载到所需的测试子项用例进行执行，实现相应的测试子项的测试。

需要说明的是，在本申请实施例的另一可选实施方式中，也可以将测试子项的测试子项用例作为测试子项的属性信息写入子任务文件中，从而待测DUT在执行子任务文件时，可以直接执行子任务文件中的测试子项用例，实现测试子项的测试。

S202：基于目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项。

应理解，在本申请实施例中，计算机设备可以接收并保存各待测DUT在执行子任务文件时所产生的所有测试过程数据、测试结果数据和测试完成时长。其中，测试过程数据可以包括但不限于测试过程中所产生的异常数据、测试过程中所产生的错误数据等；测试结果数据可以包括表征测试子项测试成功的数据，和表征测试子项测试失败的数据。而测试完成时长是指，待测DUT在执行测试子项的测试子项用例时，从执行开始至执行结束的总时长。

还应理解，在本申请实施例中，预设条件可以由工程师设定。示例性的，预设条件可以包括以下至少之一：

条件1：测试子项在被测试时出现错误的次数少于第一阈值；

条件2：测试子项的测试结果满足预设结果(即测试成功)的次数大于第二阈值；

条件3：测试子项在被测试时的测试完成时长大于第三阈值。

其中，第一阈值、第二阈值和第三阈值的具体取值可以由工程师确定。示例性的，第一阈值可以设置为一个较小的常数值，例如1；第二阈值可以设置为一个较大的常数值，例如为100；第三阈值可以设置为一个较大的常数值，例如为10天等。以上取值仅为示例出的可选取值，不作为对本申请实施例的限制。

这样，通过将被测试时出现错误的次数少于第一阈值的测试子项，或测试结果满足预设结果的次数大于第二阈值的测试子项作为目标测试子项，则进一通过步骤S203，即可以有效剔除对测试效果影响不明显的这些测试子项，从而仅保留测试效果更好的测试子项，降低测试用时，提高测试效率。

此外，由于在实际测试过程中，如果某一测试子项在测试过程中用时特别长，则该测试子项会严重拖累整个测试过程的效率，因此为了提高测试效率，通过将被测试时的测试完成时长大于第三阈值的测试子项作为目标测试子项进行删除，也可以达到降低测试用时，提高测试效率的效果。

但是，针对任一测试子项只要满足条件3就确定为目标测试子项的方案，需要注意的是，若该测试子项为完成测试任务的一必要测试项，则不应进行删除。为此，在针对测试完成时长大于第三阈值的测试子项进行删除前，在本申请实施例的一种可行实施方式中，可以先将测试完成时长大于第三阈值的测试子项反馈给工程师进行删除确定，在工程师确认可以删除后，再进行删除。

此外，在本申请实施例的另一种可行实施方式中，针对任一测试子项只要满足条件3就确定为目标测试子项的方案，也可以通过查找测试子项用例库中是否存在与该测试子项实现的测试功能实质相同，但测试完成时长更短的测试子项用例，若不存在，则不再将该测试子项确定为目标测试子项；若存在，则可以删除该测试子项的属性信息，并以查找到的与该测试子项实现的测试功能实质相同，但测试完成时长更短的测试子项用例所对应的测试子项的属性信息加入到本目标测试任务中。从而，避免删除掉必要测试项。

应理解，对于条件1和条件2而言，基于条件1和/或条件2确定出的目标测试子项为对测试效果影响不明显测试子项，其必然不属于必要测试项，因此可以不发给工程师进行确认，或者不进行测试功能实质相同的测试子项用例的查找与替换。

可选的，以上条件1至条件3可同时被采用，也可以仅采用其中的部分条件。例如，可以仅同时采用条件1和条件2进行目标测试子项的确定，从而剔除对测试效果影响不明显测试子项。

可选的，在同时采用以上条件1和条件2进行目标测试子项的确定是，还可以在基于条件1和条件2确定出满足条件1和条件2的测试子项后，再进一步对这些测试子项进行判断，判断这些测试子项是否满足条件3，从而将这些测试子项中满足条件3的测试子项作为目标测试子项进行删除。这样，可以控制删除的测试子项的数量，避免出现删除标测试子项后，剩余的测试子项过少的情况。

S203：删除目标测试任务中目标测试子项的属性信息。

可选的，考虑到在实际应用过程中，可能存在某些测试子项之间存在执行依赖关系(即某一测试子项用例在执行时，需要依赖某一在先被执行的测试子项用例的执行结果)的情况。对与此情况，若删除了存在执行依赖关系的两个测试子项中，在先被测试的测试子项的属性信息，则可以将该在后被测试的测试子项的属性信息反馈给工程师，以便工程师进行在后被测试的测试子项的测试子项用例的修改，或者更换后被测试的测试子项的属性信息，以保证目标测试任务中的各测试子项都是可以被测试的。

可选的，在本申请实施例中，在删除目标测试任务中目标测试子项的属性信息之后，还可以向工程师反馈所删除的目标测试子项，以便工程师决定是否接受删除，或者以便工程师向计算机设备新增新的测试子项的属性信息，以保证目标测试任务中所需进行测试的项目的丰富性与全面性。

可选的，在本申请实施例的一种可行实施方式中，在删除目标测试任务中目标测试子项的属性信息之后，还可以基于未被删除属性信息的各测试子项的测试完成时长，重新构建目标测试任务的各子任务文件。

示例性的，可以依据各测试子项的测试完成时长，对各测试子项进行划分，使得划分出的各测试子项集合对应的测试总时长中，最大测试总时长尽可能小。然后以每一个划分出的测试子项集合生成新的子任务文件。这样，在后续进行测试时，可以将不同的子任务文件分配给不同的待测DUT，从而尽可能缩短所有子任务文件被执行完毕时所需的时长。

在本申请实施例中，可以先穷尽所有划分方式，确定出每种划分方式划分出的各测试子项集合对应的最大测试总时长，选择出最大测试总时长最小的划分方式。假设存在多种最大测试总时长最小的划分方式，此时可以取这几种划分方式中，各测试子项集合对应的测试总时长两两之间的差值波动最小(即差值的均方差最小)的那一种划分方式来对各测试子项进行划分，进而生成新的子任务文件。

例如，假设A、B、C为3个测试子项，则可以具有以下几种划分方式：方式1：划分出三个集合，每个集合内的测试子项分别为A、B、C；方式2：划分出两个集合，每个集合内的测试子项分别为A和B，C；方式3：划分出两个集合，每个集合内的测试子项分别为A，B和C；方式四：划分出一个集合，集合内的测试子项为A、B和C。假设A、B、C这3个测试子项的测试完成时长分别为1小时、2小时和2小时，则方式1的最大测试总时长为2小时，比其他方式都小，从而可以采用方式1进行划分，然后分别依据测试子项A、B、C生成3个子任务文件。而假设A、B、C这3个测试子项的测试完成时长分别为1小时、2小时和4小时，则方式1和方式2的最大测试总时长均为4小时，比其他方式都小，但是方式1的差值波动比方式2剧烈，故而可以采用方式2进行划分，然后分别依据测试子项A和B、C生成一个子任务文件，依据测试子项C生成一个子任务文件。

还需要说明的是，在进行划分时，所划分出的集合数量可以小于等于待测DUT的数量，以便于后续进行子任务文件的分配，避免分配过程中因待测DUT数量的不足，出现还需要进行某些子任务文件等待分配的情况。例如，仍以上例为例，假设待测DUT的数量为2，则方式1直接排除。

需要说明的是，若各测试子项之间存在执行依赖关系(即某一测试子项的执行必须依赖在先执行的某一测试子项的执行结果)，则依据测试子项之间的执行依赖关系，需要生成各子任务文件之间的执行先后顺序，以保证各测试子项可以被正确执行。

当然，在本申请实施例中，也可以不重新构建目标测试任务的各子任务文件，对此，本申请实施例中并不做限制。

可选的，在本申请实施例的一种可行实施方式中，若各测试子项之间不具有执行依赖关系，且各所需划分的子任务文件的数量大于待测DUT的数量，则在删除目标测试任务中目标测试子项的属性信息之后，还可以基于未被删除属性信息的各测试子项的出错率，对各测试子项进行降序排列；其中，相同出错率的各测试子项之间，按照测试完成时长进行升序排列。

此时，可以对排序后的各测试子项进行划分，得到所需数量的子任务文件。这样，后续进行测试时，可以使得出错率高的测试子项优先被测试，使得相同出错率的测试子项中，测试完成时长短的测试子项优先被测试，从而使得整个测试过程中，出现执行失败的时间节点尽可能提前，从而降低测试用时，提高测试效率。

可选的，在划分子任务文件时，可以根据各测试子项的测试完成时长，尽可能降低划分出的各子任务文件的测试完成总时长的差异。

例如，假设有a、b、c、d、e五个测试子项，出错率分别为30％、33％、31％、26％、26％，测试完成时间分别为5小时、2小时、6小时、8小时、7小时，则可以得到以下排序：b、c、a、e、d。

假设需要划分出2个子任务文件，则可以依据按排列顺序进行划分的原则，可以将b、c、a划分成一个子任务文件，将e和d划分成另一个子任务文件，以使得子任务文件的测试完成总时长之间的差异最小(该划分方式中，b、c、a划分成一个子任务文件对应的测试完成总时长为13个小时，而e和d划分成的子任务文件对应的测试完成总时长为15个小时，差异为2小时，其他划分方式有：b单独划分一个子任务文件，c、a、e、d划分为另一个子任务文件；b和c划分为一个子任务文件，a、e、d划分为另一个子任务文件；b、c、a和e划分为一个子任务文件，d划分为另一个子任务文件。这些划分方式得到的的子任务文件之间的测试完成总时长差异大于2小时)。

需要理解的是，在本申请实施例中，在删除目标测试子项的属性信息之后，或者在重新构建目标测试任务的各子任务文件之后，即可正式进入测试阶段。

在进行测试时，若测试对象为芯片，则需要将需测试的芯片安装到待测DUT上；若测试对象为固件，则需要在待测DUT安装好正常的处理器，然后搭载该待测试的固件。

在进行测试前，还需要对待测DUT进行启动操作。在本申请实施例中，可以通过计算机设备远程向待测DUT发送远程开机命令，然后再将对应于该待测DUT的子任务发送给该待测DUT进行执行。

需要说明的是，在本申请实施例的一种可行实施方式中，参见图3所示，测试系统还可以包括网络交换机，计算机设备通过该网络交换机与各待测DUT连接。待测DUT上布设微控制器(例如可以是STM32微控制器)，微控制器与待测DUT的GPIO(General-purposeinput/output，通用输入输出)口连接，从而计算机设备可以通过网络交换机向待测DUT的微控制器下发远程开机命令，从而使得微控制器在接收到远程开机命令后，通过待测DUT的GPIO口控制待测DUT开机。

在本申请实施例中，计算机设备可以将目标测试任务的各子任务文件分别分配给不同的待测DUT集合，以供各待测DUT集合执行，并反馈测试结果。

应理解，本申请实施例中每个待测DUT集合由至少一个待测DUT构成。待测DUT集合可以随机从所有的待测DUT中选择确定，也可以由工程师预先设定。

在本申请实施例中，在目标测试任务的各子任务文件中，存在具有执行先后顺序的子任务文件时，对于这些子任务文件，可以按照子任务文件的执行先后顺序，将在先执行的子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，再将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合。而对于不具有执行先后顺序的各子任务文件，则可以随机发送给各空闲的待测DUT集合。

示例性的，若目标测试任务的各子任务文件之间均具有执行先后顺序，则按照各子任务文件的执行先后顺序，依次将在先执行的子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，再将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合，直至所有的子任务文件均被下发完毕。

对于这种方式，如果在测试任务的执行过程中，待测试固件更新了新版本，需要对新版本的待测试固件进行测试，则可以在已执行完子任务文件的待测DUT集合中，重新布置新版本的待测试固件并进行测试，从而实现新旧两个版本的待测试固件的并行测试，从而可以减少整体上的测试周期，提高整体上的测试效率。

示例性的，若目标测试任务的各子任务文件之间均不具有执行先后顺序，则可以直接将各子任务文件随机发送给各待测DUT集合，从而使得各待测DUT集合并行执行各子任务文件，从而使得整个测试完成时间等于用时最长的子任务文件的执行完成时间，从而可以有效降低测试周期，提高测试效率。

应理解，在上述示例方式中，若可供分配子任务文件的待测DUT的数量小于需进行分配的子任务文件的数量，那么会存在某些子任务文件需要排队等待分配的情况。

而本申请实施例中，为了节约测试时长，提高测试效率，可以在测试任务的任一子任务文件被执行失败时，即认定整个测试任务失败，从而结束本次测试，以缩短测试周期，提高测试效率。

那么，在此基础上，为了在可供分配子任务文件的待测DUT的数量小于需进行分配的子任务文件的数量的情况下，尽可能提高测试效率，针对上述目标测试任务的各子任务文件之间均不具有执行先后顺序的分配方式，可以预先对目标测试任务的各子任务文件进行排序，排序规则为：

按照各子任务文件的出错率对各子任务文件进行降序排列；若存在多个出错率相同的子任务文件，则对这多个错率相同的子任务文件，按照测试完成时长进行升序排列。

排列完毕后，可以按照排列顺序，依次进行子任务文件的下发。这样，若可供分配子任务文件的待测DUT的数量小于需进行分配的子任务文件的数量，则会先将更容易出错且测试完成时长更短的子任务文件优先进行分配，从而可以使得测试过程中，测试任务的出错时间尽可能提前，从而能够尽快中止测试，减少测试总时长。

例如，假设有A、B、C、D、E五个子任务文件，出错率分别为40％、45％、41％、36％、36％，测试完成时间分别为15小时、12小时、6小时、8小时、7小时，则可以得到以下排序：B、C、A、E、D。

假设有3个空闲的待测DUT，则会将B、C、A随机分配给这3个待测DUT执行。在执行过程中，一旦B、C、A中任一个执行失败，则整个测试结束。一旦在出现执行失败前，B、C、A中任一个执行结束(基于假设的测试完成时间，子任务文件C先执行完)，则向原本执行子任务文件C的待测DUT下发子任务文件E进行执行。假设执行过程中仍旧没有执行失败的子任务，则基于假设的测试完成时间，接下来是子任务文件B执行完毕，则向原本执行子任务文件B的待测DUT下发子任务文件D进行执行。

需要说明的是，本申请实施例中，子任务文件的出错率可以根据该子任务文件的历史执行失败次数和历史总执行次数计算得到(子任务文件的出错率可以等于历史执行失败次数与历史总执行次数的比值)。

此外，子任务文件的出错率可也可以是根据该子任务文件所具有的各测试子项的出错率计算得到。例如，可以取该子任务文件所具有的各测试子项的出错率的均值作为该子任务文件的出错率。其中，测试子项的出错率可以根据该测试子项的测试子项用例的历史执行失败次数和历史总执行次数计算得到(测试子项的出错率可以等于测试子项用例的历史执行失败次数与历史总执行次数的比值)。

还需要说明的是，以上所描述的子任务文件的分配方式，也可以适用于测试对象为芯片的测试场景中，实现方式与测试对象为待测试固件的测试场景是一致的，在此不再赘述。

在本申请实施例中，待测DUT在接收到子任务文件之后，可以先根据子任务文件中的测试子项用例所在设备的地址以及唯一标识，下载并运行测试子项用例的脚本，并根据脚本判断自身的系统内是否运行该脚本所需要的测试软件，如果没有，则可以从预先设计的固件测试软件部署服务器或软件库中下载并安装所需要的测试软件。

需要说明的是，在本申请实施例中，计算机设备可以是服务器、固定终端(如台式机、控制台等)、移动终端(如笔记本电脑等)等，但不作为限制。

实施例二：

应理解，系统启动固件是计算机设备中的核心固件，系统固件的安全性与可靠性直接影响到计算机设备的安全性与可用性。因此在开发出一版系统启动固件后，需要对系统启动固件进行测试，以判断该版系统启动固件的可用性。

为了实现对于系统启动固件的测试，本申请实施例中提供了一种测试系统。测试系统的结构可以参见图1所示，包括计算机设备和待测DUT。其中，计算机设备和待测DUT之间通信连接，待测DUT内搭载有系统启动固件。

为了实现对于系统启动固件的测试，在本申请实施例中，基于所提供的测试系统，还提供了一种可以应用于该测试系统的计算机设备中的固件测试方法，参见图4所示，包括：

S401：获取系统启动固件对应的测试任务。

应理解，本申请实施例中，计算机设备内可以预先配置有一个或多个测试任务。在需要对系统启动固件进行测试是，获取这些预先配置的测试任务中与系统启动固件对应的测试任务。当然，系统启动固件对应的测试任务也可以是工程师在测试前输入至计算机设备中的。对于系统启动固件对应的测试任务的获取方式，本申请实施例中不做限制。

本申请实施例中，测试任务中可以包括一个或多个子任务文件，子任务文件为下发至待测DUT进行执行的最小单元。一个子任务文件分别与系统启动固件的一个子固件对应。系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段。

S402：将测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到测试结果。

本申请实施例中每个待测DUT集合由至少一个待测DUT构成。待测DUT集合可以随机从所有的待测DUT中选择确定，也可以由工程师预先设定。

本申请实施例中，待测DUT用于执行所分配的子任务文件，并向计算机设备反馈对子任务文件的执行结果。计算机设备可以根据各待测DUT返回的执行结果确定出整个测试任务的测试结果。示例性的，若在测试过程中，任一个待测DUT返回了表征执行失败的执行结果，则计算机设备可以直接确定整个测试任务测试失败，从而可以通知其他待测DUT中止本次测试。若计算机设备接收到了所有待测DUT返回的表征执行成的执行结果，则可以确定整个测试任务测试通过。

本申请实施例中，为了节约测试时长，提高测试效率，可以在测试任务的任一子任务文件被执行失败时，即认定整个测试任务失败，从而结束本次测试，以缩短测试周期，提高测试效率。

在本申请实施例的一种可选实施方式中，可以按照系统启动固件的各子固件的运行先后顺序，将在先运行的子固件对应的子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。这样，可以保证对于系统启动固件的测试过程与系统启动固件的运行过程一致，从而保证测试效果。

在本申请实施例中，待测DUT的硬件资源可以被分成两个部分secure world(可信执行环境，即图5中的Secure部分)和normal world(指普通执行环境，即图5中的Non-Secure部分)。可信执行环境和普通执行环境所具有的资源调用权限是不同的。当待测DUT的CPU(Central Processing Unit，中央处理器)运行在可信执行环境的时候，可以访问所有的硬件资源，但运行在普通执行环境时，只能访问普通执行环境的资源。

在本申请实施例中，系统启动固件可以包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件，且可信固件先于普通固件运行。相应的，测试任务中可以包括：与可信固件对应的第一子任务文件，以及与普通固件对应的第二子任务文件。从而在测试时，各待测DUT先搭载该系统启动固件，然后计算机设备可以先将第一子任务文件分配给第一子任务文件对应的待测DUT集合执行，然后在接收到所述第一子任务文件的执行完毕信号后，再将第二子任务文件分配给第二子任务文件对应的待测DUT集合执行。

需要说明的是，在本申请实施例中，接收到第一子任务文件的待测DUT集合中的各待测DUT，可以在可信执行环境中执行第一子任务文件；而接收到第二子任务文件的待测DUT集合中的各待测DUT，可以在普通执行环境中执行第二子任务文件。这样，通过在可信执行环境中执行第一子任务文件，在普通执行环境中执行第二子任务文件，从而可以提高对安全性要求更高的子固件的测试安全性。

示例性的，如图5所示，可信固件可以包括：BL1固件、BL2固件、BL31固件和BL32固件。普通固件可以包括：BL33固件和OS(操作系统)固件；其中，系统启动固件的各子固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件、BL33固件、OS固件。

这样，在测试时，计算机设备先将BL1固件对应的第一子任务文件下发至第一待测DUT集合进行执行。

在接收到第一待测DUT集合的测试结果之后，若第一待测DUT集合的测试结果满足预设结果，则将BL2固件对应的第一子任务文件下发至第二待测DUT集合进行执行。

在接收到第二待测DUT集合的测试结果之后，若第二待测DUT集合的测试结果满足预设结果，则将BL31固件对应的第一子任务文件下发至第三待测DUT集合进行执行。

在接收到第三待测DUT集合的测试结果之后，若第三待测DUT集合的测试结果满足预设结果，则将BL32固件对应的第一子任务文件下发至第四待测DUT集合进行执行。

在接收到第四待测DUT集合的测试结果之后，若第四待测DUT集合的测试结果满足预设结果，则将BL33固件对应的第二子任务文件下发至第五待测DUT集合进行执行。

在接收到第五待测DUT集合的测试结果之后，若第五待测DUT集合的测试结果满足预设结果，则将OS固件对应的第二子任务文件下发至第六待测DUT集合进行执行。

示例性的，如图5所示，在本申请实施例中，BL1固件可以为Boot ROM(无盘启动ROM接口)固件，BL2固件可以为Platform initialization firmwre(平台初始化固件)、BL31固件可以为EL3 15runtime firmwre(EL3运行时固件)，BL32固件可以为OP-TEE，BL33固件可以为U-Boot/UEFI固件，OS固件可以为Kernel(操作系统OS的内核)的启动固件。

需要说明的是，子任务文件中可以包含测试子项的属性信息。所谓测试子项是指需要进行的整个测试过程中所需要进行测试的各个子项目，各测试子项的测试通常是通过配置的测试子项用例来实现。

若各子固件所对应需要进行的测试项目之间没有关联性，则也可以将各子固件所对应的子任务文件随机分配给空闲的待测DUT集合，从而实现对各子固件所对应的子任务文件的并行执行，以提高测试效率。

在本申请实施例的一种可选实施方式中，可以将预先配置的各测试子项用例存储在某一或些测试用例服务器或数据库中，然后将所需的测试子项的对应的测试子项用例所在设备的地址，以及测试子项对应的测试子项用例的唯一标识(例如可以是测试子项用例的文件名)作为测试子项的属性信息记录在子任务文件中，从而待测DUT在执行子任务文件时，可以基于子任务文件中记录的测试子项用例所在设备的地址和测试子项用例的唯一标识下载到所需的测试子项用例进行执行，实现相应的测试子项的测试。

在本申请实施例的另一可选实施方式中，也可以将测试子项的测试子项用例作为测试子项的属性信息写入子任务文件中，从而待测DUT在执行子任务文件时，可以直接执行子任务文件中的测试子项用例，实现测试子项的测试。

应理解，本实施例的方案也可以与实施例一的方案相结合进行实施。具体而言，系统启动固件对应的测试任务可以是按照实施例一中的处理方法处理得到目标测试任务。当然，本实施例的方案也可以与实施例一的方案独立实施，对此本申请不做限制。

需要说明的是，本申请实施例中，系统启动固件的每一个子固件可以对应一个或多个子任务文件。在按照实施例一中的处理方法处理得到目标测试任务时，若需要进行子任务文件重构，则可以以子固件为单位，重新构建每一个子固件所对应的子任务文件。子任务文件重构过程可参见实施例一的相关记载，在此不再赘述。

可选的，若系统启动固件的子固件需要对应多个子任务文件，且各所需划分的子任务文件的数量大于该子固件对应的待测DUT集合中的待测DUT的数量时，还可以基于该子固件对应的各测试子项的出错率，对各测试子项进行降序排列；其中，相同出错率的各测试子项之间，按照测试完成时长进行升序排列。

此时，与实施例一类似的，可以对排序后的各测试子项进行划分，生成所需数量的子任务文件。这样，后续进行测试时，可以使得出错率高的测试子项优先被测试，使得相同出错率的测试子项中，测试完成时长短的测试子项优先被测试，从而使得整个测试过程中，出现执行失败的时间节点尽可能提前，从而降低测试用时，提高测试效率。

类似的，在划分时，可以根据各测试子项的测试完成时长，尽可能降低划分出的各子任务文件的测试完成总时长的差异。

此外，在子固件对应多个子任务文件时，若这多个子任务文件之间不存在执行依赖关系，还可以在分配该子固件对应的子任务文件时，将该子固件对应的各子任务文件随机分配给该子固件对应的待测DUT集合中的各空闲待测DUT进行执行。

而考虑到本申请实施例中，为了节约测试时长，提高测试效率，可以在测试任务的任一子任务文件被执行失败时，即认定整个测试任务失败，从而结束本次测试。且在实际测试过程中，可能存在待测DUT集合中的空闲待测DUT的数量小于所需分配的子任务文件的数量的情况。为此，为了能够在此情况下尽可能提高测试效率，可以预先对该子固件对应的子任务文件进行排序，排序规则为：

按照各子任务文件的出错率对各子任务文件进行降序排列；若存在多个出错率相同的子任务文件，则对这多个错率相同的子任务文件，按照测试完成时长进行升序排列。

排列完毕后，可以按照排列顺序，进行子任务文件的下发。这样，若该子固件对应的待测DUT集合中，空闲待测DUT的数量小于所需分配的子任务文件的数量，则会先将更容易出错且测试完成时长更短的子任务文件优先进行分配，从而使得测试过程中，测试任务的出错时间尽可能提前，从而能够尽快中止测试，减少测试总时长。

需要说明的是，本申请实施例中，子任务文件的出错率可以根据该子任务文件的历史执行失败次数和历史总执行次数计算得到(子任务文件的出错率可以等于历史执行失败次数与历史总执行次数的比值)。

此外，子任务文件的出错率可也可以是根据该子任务文件所具有的各测试子项的出错率计算得到。例如，可以取该子任务文件所具有的各测试子项的出错率的均值作为该子任务文件的出错率。其中，测试子项的出错率可以根据该测试子项的测试子项用例的历史执行失败次数和历史总执行次数计算得到(测试子项的出错率可以等于测试子项用例的历史执行失败次数与历史总执行次数的比值)。

与实施例一类似的，在进行测试前，需要对待测DUT进行启动操作。在本申请实施例中，可以通过计算机设备远程向待测DUT发送远程开机命令，然后再将对应于该待测DUT的子任务发送给该待测DUT进行执行。远程开机的实现方式可参见图3和实施例一的相关记载，在此不再赘述。

在本申请实施例中，待测DUT开机并接收到子任务文件之后，可以向预设的系统启动固件的存储数据库或存储服务器请求需测试的系统启动固件并更新，从而在重启过程中执行对系统启动固件的测试过程。

同时，待测DUT还可以根据子任务文件中的测试子项用例所在设备的地址以及唯一标识，下载测试子项用例的脚本，并根据脚本判断自身的系统内是否运行该脚本所需要的测试软件。如果没有，则可以从预先设计的固件测试软件部署服务器或软件库中下载并安装所需要的测试软件。

需要说明的是，在本申请实施例中，计算机设备可以是服务器、固定终端(如台式机、控制台等)、移动终端(如笔记本电脑等)等，但不作为限制。

实施例三：

为便于理解本申请实施例所提供的方案，下面结合图例，进一说明本申请实施例的方案。

请参见图6所示的测试系统，测试系统包括客户端、固件自动化测试服务器(即前文所述的计算机设备)、固件测试用例及软件部署服务器、网络交换机、串口服务器和DUT。DUT上布设有STM32微控制器和串口。客户端与固件自动化测试服务器之间网络连接。固件自动化测试服务器(即前文所述的计算机设备)、固件测试用例及软件部署服务器、网络交换机、串口服务器之间网络连接。串口服务器和DUT之间通过RS232串口和STM32微控制器通信连接。

测试时，可以按照以下步骤执行：

步骤1：当待测试固件的固件版本更新时，触发固件自动化测试服务器获取目标测试任务。

获取目标测试任务的过程包括：获取上一版本的待测试固件的测试任务。

获取目标测试任务的过程包括：获取上一版本的待测试固件的测试任务。根据上一版本的待测试固件的测试任务中，各测试子项的测试过程数据、测试结果数据和测试完成时长，将各测试子任务文件中，将被测试时出现错误的次数少于第一阈值的测试子项，测试结果满足预设结果的次数大于第二阈值的测试子项的属性信息删除，得到目标测试任务。此外，如果测试子项之间如果没有执行依赖关系，也可以按出错率的降序进行排序，相同出错率按测试完成时长升序排序，对测试子项的测试顺序进行重新排序，并重新划分并生成得到子任务文件，得到目标测试任务。测试子项的属性信息包括测试子项对应的测试子项用例所在设备的地址以及所述测试子项对应的测试子项用例的唯一标识。

在本申请中，目标测试任务中可以包括功能测试子任务文件、性能测试子任务文件和稳定性测试子任务文件。

在本申请实施例中，子任务文件的内容可以包括：

其中，测试子项用例是指事先写好的在DUT上可以运行的测试脚本。

需要说明的是，在本实施例中，待测试固件可以为系统启动固件。

步骤2：固件自动化测试服务器按照目标任务的各子任务文件的提交或生成顺序分配任务ID号并将该子任务文件放到任务队列中。

需要说明的是，在待测试固件为系统启动固件时，固件自动化测试服务器按照BL1固件、BL2固件、BL31固件、BL32固件、BL33固件和OS固件的顺序，依次将各子固件对应的子任务文件放到任务队列中。

步骤3：如果各子任务文件之间具有执行先后顺序，也即必须按序执行，则进行步骤4；如果各子任务文件之间不具有执行先后顺序，也即无需按序执行，则进行步骤5。

步骤4：固件自动化测试服务器确定各子任务文件对应的待测DUT集合。从任务队列中按ID从小到大的顺序选择子任务文件，并从该子任务文件对应的待测DUT集合中选择可用的待测DUT运行该子任务文件。

当测该子任务文件在待测DUT上完成后，再从任务队列中取出下一个子任务文件，交给该子任务文件对应的待测DUT集合。以此类推，直至所有子任务文件都分配完毕。跳到步骤6。

步骤5：固件自动化测试服务器从任务队列中按ID从小到大的顺序依次取出子任务文件，随机选择可用的待测DUT运行各子任务文件，不用等在先分配的子任务文件完成，直至所有子任务文件分配完毕。

步骤6：等待测试任务下一次被测触发。

而每个子任务文件的完成过程如下：

步骤1：固件自动化测试服务器向待测DUT发送远程开机命令，以连接该待测DUT，并将子任务文件发送给该待测DUT。

其中，该开关机命令先经过串口服务器，被串口服务器转换为RS232串口信号。该RS232串口信号通过RS232换TTL(Transistor Transistor Logic，晶体管-晶体管逻辑)的转换器转换成TTL信号。该TTL信号通过STM32微控制器的TTL接口，调用STM32微控制器中已编程实现的开关机程序，向待测DUT的GPIO口发送开机信号，实现对于待测DUT的开机控制。

步骤2：待测DUT下载待测固件并执行固件更新操作。

待测DUT可以根据子任务文件中写有的待测试固件的下载地址下载待测固件，并根据更新固件的命令执行固件更新操作。

步骤3：待测DUT根据子任务文件中的固件测试用例及软件部署服务器的地址以及测试子项用例的文件名，下载并运行测试子项用例。并根据测试子项用例中写入的所需测试软件，判断自身系统内是否具有该需要的测试软件。如果没有，则从固件测试用例及软件部署服务器中下载并安装测试软件。

需要说明的是，虽然图5中，测试子项用例和测试软件都部署在一个服务器中的，但是在实际应用过程中，测试子项用例和测试软件也可以部署在不同服务器或数据库中，对此本申请不做限制。

此外，固件自动化测试服务器和固件测试用例及软件部署服务器在实体实现上可以是两个不同的服务器，但也可以是同一个服务器，对此本申请也不做限制。

步骤4：待测DUT继续执行测试子项用例，并在任一测试子项用例执行失败时，结束测试，并向固件自动化测试服务器发送任务失败消息。如果子任务文件对应的所有测试子项用例均测试成功，待测DUT向固件自动化测试服务器发送任务成功结束消息。

执行期间，输出的所有信息均上传至固件自动化测试服务器保存。

需要说明的是，在待测试固件为系统启动固件时，待测DUT会先根据更新固件的命令执行固件更新操作，并重启系统，从而在重启过程中，执行测试子项用例。

步骤5：固件自动化测试服务器收到任务失败消息后，向其他待测DUT发送任务中止消息，以使中止其他待测DUT中止正在执行的子任务文件，同时取消任务队列中，还未下发的该测试任务的各子任务文件。

同时，固件自动化测试服务器向空闲的待测DUT继续分配任务队列中其他测试任务的子任务文件。

如果固件自动化测试服务器收到待测DUT返回的标准子任务文件成功执行的任务成功结束消息，则继续向该待测DUT分配在任务队列中的子任务文件。

此时，固件自动化测试服务器可以将测试过程中的相关信息存储到文件中，并可以在网页上或发送至客户端上进行展示。

实施例四：

基于同一发明构思，本申请实施例中还提供了一种可以应用于前述计算机设备上的处理装置700和固件测试装置800。请参阅图7和图8所示，图7示出了采用图2所示的方法的处理装置，图8示出了采用图4所示的方法的处理装置。应理解，装置700和装置800具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置700和装置800包括至少一个能以软件或固件的形式存储于存储器中或固化在前述计算机设备的操作系统中的软件功能模块。具体地：

参见图7所示，装置700应用于测试系统的计算机设备中，包括：

获取模块701，用于获取待裁剪的目标测试任务；所述目标测试任务中包括至少一个子任务文件，每个所述子任务文件中包括至少一个测试子项的属性信息；

所述获取模块701，还用于基于所述目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；

处理模块702，用于删除所述目标测试子项的属性信息。

在本申请实施例的一种可行实施方式中，所述历史测试数据包括所述测试子项的测试过程数据、测试结果数据和测试完成时长；其中：

所述目标测试子项用于表征在被测试时出现错误的次数少于第一阈值的所述测试子项；

或，所述目标测试子项用于表征测试结果满足预设结果的次数大于第二阈值的所述测试子项；

或，所述目标测试子项用于表征在被测试时的测试完成时长大于第三阈值的所述测试子项。

在本申请实施例中，所述测试子项的属性信息包括：所述测试子项对应的测试子项用例所在设备的地址，以及所述测试子项对应的测试子项用例的唯一标识。

在本申请实施例中，所述处理模块702还用于，在删除所述目标测试子项的属性信息之后，基于未被删除属性信息的各所述测试子项的测试完成时长，重新构建所述目标测试任务的各子任务文件。

在本申请实施例中，所述处理模块702还用于，在删除所述目标测试子项的属性信息之后，基于未被删除属性信息的各所述测试子项的出错率，对各所述测试子项进行降序排列；其中，相同出错率的各所述测试子项之间，按照测试完成时长进行升序排列。

在本申请实施例的一种可行实施方式中，所述测试系统还包括待测DUT，所述计算机设备和所述待测DUT建立有通信连接；所述目标测试任务为针对待测固件的测试任务；

所述处理模块702还用于，在删除所述目标测试子项的属性信息之后，将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到所述各子任务文件的测试结果；其中，每个所述待测DUT集合由至少一个所述待测DUT构成。

在上述可行实施方式的一种可选示例中，所述处理模块702具体用于，在所述目标测试任务的各子任务文件之间具有执行先后顺序时，按照各所述子任务文件的执行先后顺序，将在先执行的所述子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合。

在上述可选示例中，所述待测DUT上搭载有系统启动固件；所述待测固件可以为所述系统启动固件；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；

所述处理模块702具体可以用于，按照所述系统启动固件的各子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

在上述可选示例中，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；所述目标测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；

所述处理模块702具体可以用于，将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行，在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

在上述可选示例中，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；所述普通固件包括：BL33固件和操作系统OS固件；其中，所述系统启动固件的各所述子固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件、BL33固件、OS固件；

所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件；所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

在上述可选示例中，接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

在上述可行实施方式的另一种可选示例中，所述处理模块702具体用于，在所述测试任务的各子任务文件之间不具有执行先后顺序时，将各所述子任务文件随机发送给各空闲的待测DUT集合。

参见图8所示，装置800应用于前述测试系统的计算机设备中，包括：

获取单元801，用于获取所述系统启动固件对应的测试任务；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；

分配单元802，用于将所述测试任务的各子任务文件分别分配给不同的待测DUT集合执行，以通过构成各所述待测DUT集合的待测DUT的执行结果，得到测试结果。

在本申请实施例的一种可行实施方式中，分配单元802具体用于按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

在上述可行实施方式的一种可选示例中，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；所述测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；

所述分配单元802具体可以用于，将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行；在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

在上述可选示例中，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；其中，各所述可信固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件；所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件。

在上述可选示例中，所述普通固件包括：BL33固件和操作系统OS固件；所述BL33固件先于所述OS固件运行；所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

在上述可选示例中，接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

需要理解的是，出于描述简洁的考量，部分实施例一和实施例二中描述过的内容在本实施例中不再赘述。

基于同一发明构思，本申请实施例还提供了一种计算机设备，参见图9所示，其包括处理器901、存储器902以及通信模组903。其中：

通信模组903用于与待测DUT通信连接。

处理器901用于执行存储器902中存储的一个或多个程序，以实现上述实施例中，计算机设备所执行的处理方法或固件测试方法。

在本申请实施例中，通信模组903可以是诸如GPRS(General packet radioservice，通用无线分组业务)、IP通信模块、TCP通信模块等在内的可以实现数据远程通信的模组。

可以理解，图9所示的结构仅为示意，计算机设备还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。例如，图9还可以具有通信总线，以实现处理器901和存储器902之间的内部通信。

还可以理解，如图10所示，本申请实施例中所述的计算机设备的具体结构均可以抽象成图10所示的结构。也即，除了在硬件层面上，如图9所示，具有处理器、存储器、通信模组这些硬件结构外，还存在操作系统、BIOS(Basic Input/Output System，基本输入输出系统)、应用软件这些软件层面的组件。

其中，处理器是设备的控制中心，用于执行相关程序，以实现本申请实施例所提供的方案。存储器可以存储操作系统和其他的应用软件，通过软件或固件来实现本申请实施例所提供的方案时用于实现本申请实施例提供的技术方案的代码会被保存在存储器中，并由处理器来执行。存储器可以与处理器集成在一起或集成在处理器的内部，也可以是独立于处理器的一个或多个存储单元。

操作系统是管理硬件资源和软件资源的系统软件，也是设备的内核和基石。操作系统需要处理如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。为了方便用户操作，大多数操作系统会提供一个让用户与系统交互的操作界面。

BIOS的作用是在通电引导阶段运行硬件初始化，以及为操作系统和程序提供运行时服务。除了使硬件初始化之外，BIOS通常还具有显示处理器温度以及调整温度保护策略等功能。

应用软件，又称应用程序，是计算机软件的主要分类之一，是指为针对用户的某种特殊应用目的所撰写的软件。例如，应用软件可以是用于实现功率控制、温度管理等目的程序。

本申请实施例中，除计算机设备外，测试系统内所涉及到的各服务器以及待测DUT的主要构成也与图10一致，从而可以协同实现本申请实施例所提供的方案。

本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、U盘、SD(Secure Digital Memory Card，安全数码卡)卡、MMC(Multimedia Card，多媒体卡)卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施一或实施例二中计算机设备所执行的处理方法或固件测试方法。在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (23)

1.一种处理方法，其特征在于，所述方法应用于测试系统，所述测试系统包括计算机设备，所述方法包括：

通过所述计算机设备获取待裁剪的目标测试任务；所述目标测试任务中包括至少一个子任务文件，每个所述子任务文件中包括至少一个测试子项的属性信息；

通过所述计算机设备基于所述目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；

通过所述计算机设备删除所述目标测试子项的属性信息。

2.如权利要求1所述的方法，其特征在于，所述历史测试数据包括所述测试子项的测试过程数据、测试结果数据和测试完成时长；其中：

所述目标测试子项用于表征在被测试时出现错误的次数少于第一阈值的所述测试子项；

或，所述目标测试子项用于表征测试结果满足预设结果的次数大于第二阈值的所述测试子项；

或，所述目标测试子项用于表征在被测试时的测试完成时长大于第三阈值的所述测试子项。

3.如权利要求1所述的方法，其特征在于，所述测试子项的属性信息包括：所述测试子项对应的测试子项用例所在设备的地址，以及所述测试子项对应的测试子项用例的唯一标识。

4.如权利要求1所述的方法，其特征在于，在删除所述目标测试子项的属性信息之后，所述方法还包括：

基于未被删除属性信息的各所述测试子项的出错率，对各所述测试子项进行降序排列；其中，相同出错率的各所述测试子项之间，按照测试完成时长进行升序排列。

5.如权利要求1所述的方法，其特征在于，在删除所述目标测试子项的属性信息之后，所述方法还包括：

基于未被删除属性信息的各所述测试子项的测试完成时长，重新构建所述目标测试任务的各子任务文件。

6.如权利要求1-5任一项所述的方法，其特征在于，所述测试系统还包括待测DUT，所述计算机设备和所述待测DUT建立有通信连接；

所述目标测试任务为针对待测固件的测试任务；在删除所述目标测试子项的属性信息之后，所述方法还包括：

通过所述计算机设备将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到所述各子任务文件的测试结果；

其中，每个所述待测DUT集合由至少一个所述待测DUT构成。

7.如权利要求6所述的方法，其特征在于，将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：

在所述目标测试任务的各子任务文件之间具有执行先后顺序时，按照各所述子任务文件的执行先后顺序，将在先执行的所述子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合。

8.如权利要求7所述的方法，其特征在于，所述待测DUT上搭载有系统启动固件；所述待测固件为所述系统启动固件；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；

按照各所述子任务文件的执行先后顺序，将在先执行的所述子任务文件发送至该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将该子任务文件的下一子任务文件发送至该下一子任务文件对应的待测DUT集合，包括：

按照所述系统启动固件的各子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

9.如权利要求8所述的方法，其特征在于，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；

所述目标测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；

按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，包括：

将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行；

在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

10.如权利要求9所述的方法，其特征在于，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；所述普通固件包括：BL33固件和操作系统OS固件；其中，所述系统启动固件的各所述子固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件、BL33固件、OS固件；

所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件；

所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

11.如权利要求9所述的方法，其特征在于，

接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；

接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

12.如权利要求6所述的方法，其特征在于，将所述目标测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：

在所述测试任务的各子任务文件之间不具有执行先后顺序时，将各所述子任务文件随机发送给各空闲的待测DUT集合。

13.一种处理装置，其特征在于，应用于测试系统的计算机设备中，所述测试系统包括所述计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述装置包括：

获取模块，用于获取待裁剪的目标测试任务；所述目标测试任务中包括至少一个子任务文件，每个所述子任务文件中包括至少一个测试子项的属性信息；

所述获取模块，还用于基于所述目标测试任务的各测试子项的历史测试数据获取不满足预设条件的目标测试子项；

处理模块，用于删除所述目标测试子项的属性信息。

14.一种固件测试方法，其特征在于，应用于测试系统，所述测试系统包括计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；所述方法包括：

通过所述计算机设备获取所述系统启动固件对应的测试任务；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；

通过所述计算机设备将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到测试结果；其中，每个所述待测DUT集合由至少一个所述待测DUT构成。

15.如权利要求14所述的固件测试方法，其特征在于，所述将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，包括：

按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，并在收到该待测DUT集合返回的执行完毕信号后，将下一子固件对应的子任务文件发送至该子任务文件对应的待测DUT集合。

16.如权利要求15所述的固件测试方法，其特征在于，所述系统启动固件包括：运行于可信执行环境的可信固件和运行于普通执行环境的普通固件；所述可信固件先于所述普通固件运行；

所述测试任务包括：与所述可信固件对应的第一子任务文件，以及与所述普通固件对应的第二子任务文件；

按照所述系统启动固件的各所述子固件的运行先后顺序，将在先运行的子固件对应的所述子任务文件分配给该子任务文件对应的待测DUT集合，包括：

将所述第一子任务文件分配给所述第一子任务文件对应的待测DUT集合执行；

在接收到所述第一子任务文件的执行完毕信号后，将所述第二子任务文件分配给所述第二子任务文件对应的待测DUT集合执行。

17.如权利要求16所述的固件测试方法，其特征在于，所述可信固件包括：BL1固件、BL2固件、BL31固件和BL32固件；其中，各所述可信固件的运行先后顺序依次为：BL1固件、BL2固件、BL31固件、BL32固件；所述第一子任务文件包括：与所述BL1固件对应的第一子任务文件，与所述BL2固件对应的第一子任务文件，与所述BL31固件对应的第一子任务文件，与所述BL32固件对应的第一子任务文件。

18.如权利要求17所述的固件测试方法，其特征在于，所述普通固件包括：BL33固件和操作系统OS固件；所述BL33固件先于所述OS固件运行；

所述第二子任务文件包括：与所述BL33固件对应的第二子任务文件，以及与所述OS固件对应的第二子任务文件。

19.如权利要求16-18任一项所述的固件测试方法，其特征在于，

接收到所述第一子任务文件的所述待测DUT集合中的各所述待测DUT，在所述可信执行环境中执行所述第一子任务文件；

接收到所述第二子任务文件的所述待测DUT集合中的各所述待测DUT，在所述普通执行环境中执行所述第二子任务文件。

20.一种固件测试装置，其特征在于，应用于测试系统的计算机设备中，所述测试系统包括所述计算机设备以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；所述装置包括：

获取单元，用于获取所述系统启动固件对应的测试任务；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；

分配单元，用于将所述测试任务的各子任务文件分别分配给不同的待测DUT集合执行，以通过构成各所述待测DUT集合的待测DUT的执行结果，得到测试结果。

21.一种测试系统，其特征在于，包括：计算机设备，以及与所述计算机设备建立有通信连接的待测DUT；所述待测DUT内搭载有系统启动固件；

所述计算机设备用于获取所述系统启动固件对应的测试任务，并将所述测试任务的各子任务文件分别分配给不同的待测DUT集合，以得到测试结果；其中，所述测试任务包括至少一个子任务文件，一个所述子任务文件分别与所述系统启动固件的一个子固件对应；所述系统启动固件的一个子固件分别用于实现系统启动过程的一个阶段；其中，每个所述待测DUT集合由至少一个所述待测DUT构成；

所述待测DUT用于执行所分配的子任务文件，并向所述计算机设备反馈对所述子任务文件的执行结果，以使所述计算机设备根据所述执行结果确定所述测试结果。

22.一种计算机设备，其特征在于，包括：通信模组、处理器和存储器；

所述通信模组用于与待测DUT通信连接；

所述处理器用于执行所述存储器中存储的一个或多个程序，以实现如权利要求1-12、14-19任一项所述的方法。

23.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序在被一个或者多个处理器执行时，使得所述处理器执行如权利要求1-12、14-19任一项所述的方法。

Images