CN110678850A - 自动化装置测试分类系统和技术 - Google Patents

Abstract

提供了用于测试计算装置的方法和设备。提供了一种用于通过使用包括第一测试和第二测试的测试套件来测试被测装置(DUT)的主机计算装置。所述DUT可以包括具有第一DUT的第一DUT组和具有第二DUT的第二DUT组。所述第一DUT组和第二DUT组可以共享公共设计。所述主机计算装置可以确定所述DUT在所述第二测试之前执行所述第一测试。所述主机计算装置可以接收针对所述第一DUT的、失败的第一测试结果。所述主机计算装置可以基于所述第一测试结果以及所述第一DUT组和第二DUT组共享公共设计确定在所述第一测试之前执行所述第二测试，并且随后可以指示所述第二DUT在所述第一测试之前执行所述第二测试。

Description

自动化装置测试分类系统和技术

背景技术

最近，已经开发了用在移动计算装置上的许多软件应用。为了提高利用这些软件应用和移动计算装置获得积极的用户体验的可能性，可以在一个或者多个测试会话期间测试移动计算装置。这些测试会话可以包括对针对测试的测试结果的分析，这些测试涉及在各种操作条件下执行各种装置的硬件和软件。测试结果和后续分析可以用于发现并且解决硬件故障、软件故障和/或与移动计算装置、软件应用、系统软件相关联的其它问题，和/或用于提高移动计算装置的硬件和/或软件的性能。

发明内容

在一个方面中，提供了一种方法。提供执行测试基础架构系统软件的主机计算装置，该测试基础架构系统软件用于通过使用具有待由多个被测装置(DUT)执行的多个测试的测试套件来测试多个DUT。多个DUT包括第一DUT和第二DUT，其中，第一DUT和第二DUT共享公共设计。多个测试包括第一测试和第二测试。主机计算装置确定在第二测试之前在至少第一DUT上执行第一测试。主机计算装置接收针对由第一DUT执行的失败的第一测试的第一测试结果。主机计算装置基于第一测试结果并且基于第一DUT与第二DUT共享公共设计来确定在第一测试之前在第二DUT上执行第二测试。主机计算装置随后指示第二DUT在执行第一测试之前执行第二测试。

在另一方面中，提供了一种主机计算装置。该主机计算装置包括：一个或者多个处理器；以及非暂时性计算机可读介质。该非暂时性计算机可读介质存储有计算机可读指令。这些计算机可读指令在由一个或者多个处理器执行时使该主机计算装置执行功能。这些功能包括：执行测试基础架构系统软件，该测试基础架构系统软件用于通过使用具有待由多个DUT执行的多个测试的测试套件来测试多个DUT，该多个DUT包括第一DUT和第二DUT，其中，第一DUT和第二DUT共享公共设计，以及其中，多个测试包括第一测试和第二测试；确定在第二测试之前，在至少第一DUT上执行第一测试；接收针对由第一DUT执行的失败的第一测试的第一测试结果；基于第一测试结果并且基于第一DUT与第二DUT共享公共设计，确定在第一测试之前在第二DUT上执行第二测试；以及随后指示第二DUT在执行第一测试之前执行第二测试。

在另一方面中，提供了一种制品。该制品包括：一种或者多种非暂时性计算机可读介质，该一种或者多种非暂时性计算机可读介质存储有计算机可读指令，这些计算机可读指令在由主机计算装置的一个或者多个处理器执行时使主机计算装置实施功能。这些功能包括：执行测试基础架构系统软件，该测试基础架构系统软件用于通过使用具有待由多个DUT执行的多个测试的测试套件来测试多个DUT，该多个DUT包括第一DUT和第二DUT，其中，第一DUT和第二DUT共享公共设计，以及其中，多个测试包括第一测试和第二测试；确定在第二测试之前，在至少第一DUT上执行第一测试；接收针对由第一DUT执行的失败的第一测试的第一测试结果；基于第一测试结果并且基于第一DUT与第二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示出了根据至少一些示例实施例的用于图8中的场景的测试套件、分类层级和分类标准的框图。

图10、图11、图12、图13、图14和图15示出了根据至少一些示例实施例的针对图8中的场景的通信流程。

图16描绘了根据至少一些示例实施例的分布式计算架构。

图17A是根据至少一些示例实施例的计算装置的框图。

图17B描绘了根据至少一些示例实施例的基于云的服务器系统。

图18是根据至少一些示例实施例的方法的流程图。

具体实施方式

提供了用于对计算装置(诸如，移动计算装置)的硬件和软件进行分布式测试和验证的方法和设备。例如，可以将计算装置实施为包括与装置无关的软件，诸如，操作系统和硬件控制软件。然后，可以设计和构建专用于计算装置的硬件和与装置有关的软件以利用与装置无关的软件。可以具体地实施和/或修改设计的计算装置以满足一个或者多个特定供应商、市场、通信提供商和/或销售渠道的要求。然后，可以测试实施的计算装置，并且最终批准公开发行计算装置。这种测试和批准可以包括一种或者多种测试和/或批准，诸如但不限于：兼容性测试和/或批准、特定于供应商的测试和/或批准、一般测试和/或批准以及特定于市场的测试和/或批准。

每种测试和/或批准可以涉及使用一个或者多个测试套件。测试套件可以包括针对装置的一个或者多个自动和/或手动测试、针对测试的预期结果以及在测试/批准期间使用的参考软件和/或硬件(例如，软件图像、特定的硬件设计和/或组件)。软件图像可以包括配置用于加载到计算装置上并且由计算装置执行的软件和/或固件的一个或者多个文件或者其它持久性表示。一个或者多个软件图像可以用于通过使用存储在(多个)软件图像中的已知软件和/或固件来使计算装置初始化和/或恢复计算装置。然后，测试计算装置可以涉及首先将具有已知软件和/或软件的软件图像加载到被测计算装置上以确保被测计算装置在测试期间执行已知软件和/或软件。

有时，测试套件、参考软件和/或硬件具有缺陷。如果修正测试套件和/或参考软件/硬件的缺陷的发行周期为N天(例如，N＝5、10、14、15、20、30或者60)，则从在利用有缺陷的测试套件的硬件和/或软件实现器的生态系统中缺陷较明显的时间到修正缺陷为止，会有长达N天的延迟。例如，假设软件图像SI具有缺陷D1，该缺陷D1通过至少导致被测装置(DUT)DUT1初始化/启动失败而变得明显。由于软件图像SI的缺陷D1阻止了DUT1启动，因此，等待纠正缺陷D1的每个长达N天的延迟会导致严重并且代价高昂的延迟，以及可能延迟引入利用软件图像SI的装置。

使用手动过程而不是自动化过程也引入延迟和人为误差。例如，在数百或者数千个与装置相关的实体(包括装置设计和制造实体，诸如，原始设计制造商(ODM)和硅供应商(SV)、组件制造/设计实体、系统集成实体、测试实体、与软件相关的实体以及生态系统协调实体)的生态系统中，使用手动免除过程来允许一个或者多个失败的硬件测试例外可能不可行。原始设计制造商可以是可以产生计算装置的一个或者多个设计和/或可以制造所设计的计算装置的与装置相关的实体。硅供应商可以是基于其自己的和/或其它实体的硬件和/或软件设计来制造计算装置的与装置相关的实体。

计算装置的设计可以包括计算装置的硬件设计和/或软件设计。作为示例，原始设计制造商ODM1可以从另一与装置相关的实体DE1接收装置的规格。然后，ODM1可以设计并且制造DE1所指定的装置。在一些示例中，ODM1可以基于内部规格而不是外部规格来设计并且制造装置。

生态系统协调员可以是为利用与装置无关的软件的计算装置硬件和软件的生态系统开发并且发行与装置无关的软件的与装置相关的实体。生态系统协调员还可以开发并且发行具有一个或者多个测试的一个或者多个测试套件，以验证特定计算装置的功能性和/或特定计算装置与和装置无关的软件的兼容性，并且或许是一个或者多个计算装置和/或利用与装置无关的软件的软件应用。生态系统协调员可以基于特定计算装置在测试套件的测试上的性能来确定是否批准特定计算装置与生态系统中的其它装置和软件应用一起使用。

本文提供了用于加速和促进装置批准的设备和方法，包括但不限于：基于在与装置相关的实体的生态系统内发现的缺陷的分类测试。例如，测试套件可以包括通过使用在主机计算装置上执行的测试基础架构系统软件(TISS)而连续自动执行/部署的测试，其中，测试套件可以包括由框架供应商(FV)提供给用于作为DUT被测试的计算装置的一个或者多个与装置相关的实体的测试和相关软件图像。测试套件和/或主机计算装置还可以包括来自参考硬件的测试结果；例如，通过使用联合测试、测试套件的软件和/或硬件分支、软件图像和/或硬件实施方式。然后，与装置相关的实体中的一些或者所有与装置相关的实体可以通过使用在主机计算装置和/或测试套件上执行的TISS来执行自动连续测试，并且通过使用主机计算装置来将测试结果提供给生态系统协调员。该生态系统协调员可以检查来自与装置相关的实体的测试结果，并且当测试结果有保证时，向与装置相关的实体提供针对装置的一个或者多个批准。另外，生态系统协调员可以基于测试套件的已确认的缺陷/故障来为失败的测试提供豁免。在这些示例中的一些示例中，框架供应商可以充当生态系统协调员。

可以基于分类算法来对测试进行分类或者重新对测试进行排序、省略和/或免除测试。分类算法可以从与装置相关的实体接收测试结果，并且确定是导致失败的测试结果的(多个)误差源的一个或者多个可能实体。分类算法可以应用一个或者多个分类标准以确定(多个)可能误差源。然后，分类算法可以对在与(多个)可能误差源相关联的所有DUT上的测试进行分类。当在分类算法中接收到其它测试结果时，分类算法可以继续确定与失败的测试相关联的(多个)可能误差源，并且随后对在与(多个)可能误差源相关联的所有DUT上的测试进行分类，从而当接收到测试结果时动态地调整哪些测试在不同的装置上运行。

生态系统协调员可以在构建和测试硬件和软件时提供软件、测试套件、参考硬件、硬件和软件开发人员支持以使生态系统能够提供除了由生态系统协调员提供的那些服务/内容之外的其它服务/内容，在整个生态系统中支持更多并且不同种类的装置，并且吸引更多的用户使用与生态系统相关联的装置。通过提供对测试套件和TISS的支持，生态系统协调员可以支持分布式硬件(和软件)验证以快速地向整个生态系统中与装置相关的实体提供统一的测试、批准和豁免，从而实现在生态系统中更快地调试、批准和部署装置。

在一些示例中，计算装置可以利用已经被划分为两个部分的系统软件：与装置无关的软件(DIS)和与装置有关的软件(DDS)，在与装置无关的软件和与装置有关的软件之间具有“供应商接口”。然后，测试套件可以包括针对与装置无关的软件和与装置有关的软件的测试以及集中于与装置有关的软件的测试的“供应商测试套件”。在特定情况下，供应商测试套件可以包括由生态系统协调员编写的并且由与装置相关的实体执行的测试以支持对与装置有关的软件的批准和/或计算装置的一种或者多种特定硬件实施方式。

供应商测试套件可以涉及广泛的测试集合；例如，一个这种供应商测试套件具有超过100个测试模块，这些测试模块具有超过5000个符合性测试和较大的可选质量测试集合。这种大型测试套件花费大量的时间和计算资源来进行执行、验证和批准。进一步地，随着装置的发展，测试、测试模块和接口发生变化，从而引起测试和批准过程发生变化。

为了更好地利用测试时间和努力，可以测量并且检查测试执行时间以了解利用了大量执行时间的地方。然后，可以优化长持续时间测试以减少执行时间，并且可以将经过优化的修正测试作为改进过的测试提供至测试套件。可以(连续地)重复该过程以基于测试执行时间优化测试。可以使用相关方法来基于试覆盖范围优化测试，并且通过同时使用两种方法，可以将测试优化成在增加测试范围的同时使测试执行时间减到最少，从而相对于测试执行和覆盖范围引起更高效的测试。为了减少测试时间，可以针对可能并行性检查测试(即，可能在具有相同设计和/或相同设计实施方式的多个装置上执行测试)，并且然后，当多个DUT可用时，可以并行地执行可并行部分和/或整个测试。另外，测试、测试模块和/或测试套件可以被“分片(shared)”或者分解成较小的可执行部分以使得能够选择特定的测试和/或测试模块。例如，可以在测试设施处将多个DUT分组成一个或者多个测试集群，并且可以对测试进行分片以使得能够选择对一个或者多个特定DUT执行一个或者多个特定测试和/或测试模块和/或选择对一个或者多个测试集群中的所有DUT执行一个或者多个特定测试和/或测试模块。

TISS和/或主机计算装置可以提供附加特征以更好地支持测试人员进行测试工作。例如，TISS和/或主机计算装置可以支持重新执行命令，转而可以编辑这些命令，以使得能够重复执行相同和/或相似的命令。可以防止篡改测试结果以确保批准是基于准确并且实际的测试结果。可以按照易于读取和/或压缩的形式来提供TISS和/或主机计算装置的各种输出(诸如，测试日志)。用于支持测试人员的其它这种特征也是可能的。

在一些示例中，一个或者多个与装置相关的实体可以包括专有的和/或以其它方式敏感的软件作为与装置有关的软件的一部分。同样，使用与装置有关的软件可以实现与装置无关的软件和与装置有关的软件的所有权分开。进一步地，敏感的与装置有关的软件的所有者可以提供用于通过使用本文描述的TISS、主机计算装置和测试套件来测试敏感的与装置有关的软件和相关装置的实验室空间以减少可能意外披露与装置有关的软件。另外，通过使用用于验证和批准计算装置的所有设计和相关实施方式的通用测试套件，设计者和/或实施者可以设计并且实施他们认为合适的计算装置，只要通过测试套件中的测试，从而使得批准计算装置。

在其它示例中，一些“参考装置”可以包括参考硬件和/或软件。例如，参考装置可以具有参考硬件和/或软件，该参考硬件和/或软件可以是已经被验证为是正确的硬件和/或软件(例如，根据早前版本的软件)，和/或可以包括被指定为参考的硬件和/或软件(例如，带有板级支持包和/或其它交钥匙软件的片上系统(SoC)装置)。在这些其它示例中的一些示例中，不同的“非参考”装置可以具有除了参考硬件和/或软件之外的硬件和/或软件；例如，在更新的版本的软件和/或相对较新版本的硬件上运行的OEM装置。然后，包括参考硬件和/或软件的装置的测试结果(特别是失败的结果)可能影响对针对没有参考硬件和/或软件的装置的测试进行分类。例如，不包括参考硬件和软件的一个或者多个其它装置NEW_DEVS可以省略执行在包括参考硬件和软件的一个或者多个装置REF_DEVS上的已经被报告为失败的测试T_REF_FAIL。在这些示例中的一些示例中，一个或者多个其它装置NEW_DEVS可以免于执行测试T_REF_FAIL，直到(多个)REF_DEVS装置中的至少一个REF_DEVS装置通过测试T_REF_FAIL为止。

TISS(例如，当在主机计算装置上执行时)可以提供更快的装置和测试修复，因为测试结果通过与装置相关的实体的生态系统得以更快地传播，这些与装置相关的实体正在测试通过通用硬件和/或软件相关的DUT；例如，生态系统中的所有DUT利用相同的与装置无关的软件。在与装置相关的实体的前提下和/或在生态系统协调员的前提下，TISS可以自动测试硬件和软件版本，并且可以实现实时追踪DUT的批准状态。对于是向与其它装置相关的实体提供硬件的硅供应商的与装置相关的实体，使用TISS可以加速将修正传递至软件和/或加速针对生态系统中的DUT的测试，因为利用硅供应商的所有与装置相关的实体可以使用TISS来获得这种修正，并且可以使用TISS来加速由生态系统协调员进行的批准和免除过程。对于是原始设计制造商的与装置相关的实体，使用主机计算装置和/或TISS会引起在设计的计算装置的各种实施方式之间的故障定位，以及加速批准和免除过程。

下面的表1示出了在使用TISS/主机计算系统之前在7天间隔内在整个生态系统中传播对测试的修正的示例。

表1

表2示出了在短于表1中示出的示例的三天间隔至4天内通过使用TISS/主机计算系统来在整个生态系统中传播相同的测试修正的相似示例。

表2

如通过在上面的表1和表2中示出的示例图示的，使用TISS可以加速传播修正，并且减少在执行已经被修正但是尚未向生态系统发行的测试时浪费的努力和时间，诸如，在表1中，在第2至6天期间发生。

主机计算装置、TISS测试套件和/或与装置无关的软件可以包括用于实现分布式测试和批准的特征；例如，用于使与装置相关的实体能够对其(多种)实施方式和计算装置的(多个)设计执行测试(诸如，供应商测试套件中的测试)。可以改进测试以改进兼容性测试覆盖范围。进一步地，由生态系统协调员和/或一个或者多个与装置相关的实体提供的实验室空间可以包括一个或者多个DUT以及使用主机计算装置上的TISS来使测试执行自动化的主机测试系统。使用与装置有关的软件及其测试可以通过允许多个与装置有关的软件设计者和/或实施者独立地/并行地测试其装置、设计和/或实施方式来增加在计算装置时的并行性。进一步地，可以选择测试套件中的测试以验证完整地测试了供应商接口的与装置无关的相关特征和与装置有关的软件，以允许进行稳健的系统测试，并且在一些情况下，允许向后兼容性。

加速的计算装置批准

转向附图，图1描绘了根据至少一些示例实施例的包括充当被测装置的计算装置110和测试套件150的系统100。计算装置/DUT 110可以包括与装置无关的软件120、与装置有关的软件130和硬件140。与装置无关的软件120可以包括框架软件，诸如，操作系统，该框架软件可以包括内核软件、运行时环境、用于一种或者多种软件语言(例如，Java、Python等)的一个或者多个框架、提供库功能性的一个或者多个软件库形式的软件以及系统应用。

与装置有关的软件130可以包括一个或者多个硬件抽象层(HAL)132、内核接口134和库接口136。HAL可以提供用于在与装置无关的软件与用户级硬件驱动器(例如，相机驱动器、Bluetooth^TM驱动器)之间创建软件挂钩的一组接口。

在一些示例中，HAL 132、内核接口134和库接口136可以是供应商接口138的一部分或者全部，该供应商接口138是在与装置有关的软件120和与装置有关的软件130之间的接口。一个或者多个HAL132可以包括用于计算装置110的硬件组件(诸如但不限于：音频组件、通信(例如，Bluetooth^TM、Wi-Fi^TM等)组件、相机/视频组件、传感器组件)的硬件抽象层。内核接口134可以提供用于和与装置无关的软件120通信的软件和/或相关数据；例如，与操作系统和/或内核通信。库接口136可以提供用于利用与装置无关的软件120的一个或者多个软件库和/或其它软件库的库功能性的软件和/或相关数据。

测试套件150可以包括测试基础架构系统软件/TISS 160、测试案例170和一个或者多个软件图像180。TISS 160可以包括用于执行在本文中描述的测试基础架构系统软件/TISS的功能性的软件，包括但不限于：用于以下的功能性：在一个或者多个DUT上进行协调并且执行测试，从一个或者多个DUT接收测试结果，通过使用比较测试结果174来确定测试通过与否和/或与一个或者多个其它计算装置(诸如，与生态系统协调员相关联的(多个)计算装置)传送与测试相关的信息(包括但不限于：测试和测试结果)。

例如，TIS 160可以提供用于测试一个或者多个DUT的硬件和软件的基础架构。例如，TISS 160可以实现自动测试DUT的与装置无关的软件和/或与装置有关的软件。在一些示例中，TISS 160可以在与DUT联网的主机计算装置(即，在云中和/或提供测试平台作为服务的主机计算装置)上执行。在其它示例中，主机计算装置与DUT共同位于测试设施中；例如，通过使用本地模型来执行测试。在这些示例中的特定示例中，在测试设施处生成/构建软件图像，而在这些示例中的另一特定示例中，云测试计算装置由拥有、设计和/或实施一个或者多个DUT的测试实体共同拥有。在又一些示例中，可以通过使用TISS 160来(连续)下载和/或测试各个测试、测试套件、与测试相关的软件(例如，TISS)和软件图像(例如，与装置无关的软件的图像)和/或可以通过使用TISS 160和/或其它软件(例如，使得能够访问生态系统协调员和/或由生态系统协调员访问的测试“前端”或者用户界面)来(连续)上传测试结果。

测试案例170包括软件/硬件测试172和相关的比较测试结果174。软件/硬件测试172可以包括被设计为验证DUT 110的一个或者多个方面(包括但不限于：DUT 110的和与装置无关的软件120、与装置有关的软件130和/或硬件140相关的方面)的一个或者多个测试。

比较测试结果174可以包括通过执行一些或者所有软件/硬件测试172和/或模拟一些或者所有软件/硬件测试172的执行而生成的结果。例如，一些或者所有比较测试结果174可以是通过在执行软件图像180中包括的一些或者所有软件的一个或者多个参考计算装置上运行一个或者多个软件/硬件测试172而获得的测试结果。

比较测试结果174可以用于确定由DUT 110执行的测试的正确性或者失败。例如，假设测试T1具有比较测试结果174中的R1比较测试结果。然后，假设两个DUT(DUT_A和DUT_B)执行测试T1。可以将在相应DUT(DUT_A和DUT_B)上执行测试T1的输出或者结果保存为相应的测试结果TR_A和TR_B。如果TR_A(或者TR_B)与R1的比较表明TR_A(或者TR_B)等于或者以其它方式等效于R1，则TR_A(或者TR_B)与R1的比较指示DUT_A(或者DUT_B)通过测试T1。然而，如果TR_A(或者TR_B)与R1的比较表明TR_A(或者TR_B)不等于或者以其它方式不等效于R1，则TR_A(或者TR_B)与R1的比较指示DUT_A(或者DUT_B)未通过测试T1。测试结果、比较测试结果以及确定测试结果的相等性/等效性的许多其它示例也是可能的。

软件图像180可以包括待由DUT在测试期间执行的软件的二进制表示和/或其它表示。软件的这些表示可以包括但不限于：与装置无关的软件120和/或与装置有关的软件130中的一部分或者全部的编译版本。在一些示例中，生态系统协调员可以提供测试套件150的部分或者全部内容；即，TISS 160、测试案例170和/或(多个)软件图像180中的一部分或者全部。在这些示例中的特定示例中，生态系统协调员可以为与装置无关的软件120提供TISS160、测试案例170和(多个)软件图像，而另一实体可以为与装置有关的软件130提供(多个)软件图像。

图2包括根据至少一些示例实施例的软件/硬件测试172以及(多个)软件图像180的框图。如上面提到的，软件/硬件测试172和(多个)软件图像180可以是测试套件150的一部分。软件/硬件测试172可以包括兼容性测试套件测试210、供应商测试套件测试212和与装置有关的测试214。

兼容性测试套件测试210可以包括被设计为确定DUT的软件和硬件与在可以通过使用与装置无关的软件120和/或与装置有关的软件130来操作的装置的生态系统中的其它软件和/或硬件的“兼容性”的一个或者多个测试。兼容性测试套件测试210可以包括被设计为在构建和测试DUT的同时被集成到日常工作流中(诸如，在测试驱动的开发期间)的一个或者多个测试。兼容性测试套件测试210可以包括用于测试以下的一个或者多个测试：与装置无关的软件120和/或与装置有关的软件130的特定代码和/或数据单元(例如，特定类别)、与装置无关的软件120和/或与装置有关的软件130的一个或者多个应用编程接口(API)(即，通过实施使用(多个)被测API的案例)、DUT在压力下的反应/耐久性和/或DUT的性能，诸如，与一个或者多个基准值相比较。兼容性测试套件测试210的其它测试也是可能的。在一些示例中，软件/硬件测试172不具有任何兼容性测试套件测试210。

供应商测试套件测试212可以包括被设计为验证供应商接口的预期功能性的一个或者多个测试；例如，在与装置无关的软件120和与装置有关的软件130之间的供应商接口138。在一些示例中，供应商测试套件测试212可以包括用于验证一个或者多个HAL、一个或者多个库和/或DUT的操作系统的一个或者多个方面的预期功能性的测试。在其它情况下，供应商测试套件测试212可以包括用于验证DUT的HAL和/或操作系统的与安全性相关的方面的一个或者多个测试。在一些示例中，软件/硬件测试172不具有任何供应商测试套件测试212。

与装置有关的测试214可以包括被设计为验证特定设计、特定实施方式、一个或者多个特定功能、一个或者多个特定组件和/或DUT的其它特定方面的预期性能的一个或者多个测试。这些方面可以是与设计相关的实体特定的。在一些示例中，除了生态系统协调员之外，一些或者所有与装置有关的测试214由一个或者多个与设计相关的实体编写。在其它示例中，软件/硬件测试172不具有任何与装置有关的测试214。

(多个)软件图像180可以包括一个或者多个与装置无关的图像230以及一个或者多个与装置有关的图像240。与装置无关的图像230可以包括一个或者多个通用系统图像(GSI)232以及一个或者多个内核/启动图像234。与装置有关的图像240可以包括一个或者多个装置图像242以及一个或者多个与装置相关的实体特定的图像244。

(多个)通用系统图像232可以包括与装置无关的软件120的已知发行(release)/版本(version)的一个或者多个软件图像。(多个)内核/启动图像234可以包括用于使计算装置(诸如，DUT)初始化/启动的一个或者多个软件图像。在操作中，计算装置(诸如，DUT)可以使用(多个)内核/启动图像234来启动/初始化计算装置，并且作为启动序列/初始化序列的一部分，可以将来自(多个)通用系统图像232中的软件加载到计算装置上以初始化DUT和/或恢复DUT到与装置无关的软件120的已知发行/版本。例如，内核/启动图像234可以用于通过以下来执行启动计算装置/使计算装置初始化：(a)重新启动计算装置并且(b)开始执行在存储器中的特定位置处的软件，该软件可以(c)从持久性存储中的固定位置(例如，固定的文件系统位置/名称)和/或从辅助持久性存储装置(例如，闪存驱动器、光盘)加载到计算装置的存储器中，并且(d)在加载完成之后，开始执行加载的软件。然后，如果将来自(多个)通用系统图像232中的软件存储在持久性存储中的固定位置处或者存储在辅助持久性存储装置上，则可以在启动期间加载来自(多个)通用系统图像232中的软件。

与装置相关的实体特定的图像244可以包括与装置有关的软件130的一个或者多个软件图像。在一些示例中，可以按照与从(多个)通用系统图像232加载软件相似的方式来在启动序列/初始化序列期间加载来自与装置相关的实体特定的图像244中的软件。在其它示例中，将与装置相关的实体特定的图像244中的软件与(多个)通用系统图像232中的软件合并；即，对于与装置无关的软件120和与装置有关的软件130两者，存在一个(或者一组)图像。在又一些示例中，通过一个与装置相关的实体(诸如，生态系统协调员)来创建和/或维护(多个)通用系统图像232，并且通过不同的与装置相关的实体(诸如，原始设计制造商或者硅供应商)来创建和/或维护与装置相关的实体特定的图像244。

图3是根据至少一些示例实施例的测试设施(TF)300的框图。测试设施300包括目标系统310和主机计算装置340。目标系统310包括一个或者多个测试集群320、332。测试集群可以包括一个或者多个DUT测试组，并且每个测试组可以包括一个或者多个DUT。例如，测试集群320包括至少两个测试组330、332，其中，测试组330包括至少三个DUT 110a、DUT110b、DUT 110c，并且其中，测试组332包括至少三个DUT 110d、DUT 110e、DUT 110f。在测试设施300处的测试集群、测试组和目标系统的其它示例也是可能的。例如，测试设施300可以包括多个目标系统。

在一些示例中，目标系统310可以包括用于测试DUT的一个或者多个测试辅助装置。例如，测试辅助装置可以具有参考装置、DUT和相机。然后，为了测试DUT的显示器，可以指示DUT和参考装置两者示出图像或者其它预定显示，并且测试辅助装置的相机可以用于捕获如由DUT和/或参考装置提供的预定显示的图像以便比较、验证显示和/或用于其它原因。

主机计算装置340可以包括一个或者多个计算装置，该一个或者多个计算装置包括测试基础架构系统软件160的一个或者多个实例以及一个或者多个软件/硬件测试172。在图3中示出的示例中，主机计算装置340具有被组织成测试模块350、352的软件/硬件测试172。每个测试模块350、352可以包括软件/硬件测试172中的一个或者多个测试；例如，测试模块350具有至少三个测试354a、354b、354c，并且测试模块352具有至少三个测试354d、354e、354f。(多个)主机计算装置340的其它示例也是可能的。在一些示例中，测试设施300是虚拟测试设施；例如，主机计算装置340不与目标系统310共位。具体地，主机计算装置340可以是为目标系统310(并且或许是其它目标系统)中的DUT提供测试作为服务的联网装置/云装置。

为了确保测试覆盖范围，诸如，供应商接口和/或与装置有关的软件的测试覆盖范围，软件/硬件测试172可以包括覆盖与装置无关的相关特征(诸如，HAL和跨越多个DUT的特征)的测试。可以自动生成测试套件中的一些测试，诸如，“模糊测试(fuzz testing)”。模糊测试或者模糊涉及将随机和/或以其它方式生成的数据(被称为“模糊(fuzz)”)输入至DUT。对于非随机模糊测试的示例，可以使用一个或者多个模糊测试，测试值在某一范围值内。

例如，如果DUT的扬声器或者其它声音输出装置SD可以产生具有范围在A dB与BdB(B<A)之间的输出，则一组m个模糊测试FT1、FT2、...FTm可以涉及将音量设定设置到相应的音量级L1(＝A)、L2>L1、...Lm(＝B)，从而使得通过SD输出声音，并且从而测量产生的输出声级以使实际的输出音量与音量设定对应。许多其它模糊测试是可能的和/或也可以自动生成许多其它模糊测试。可以通过使用系统化方法论测试和/或发现软件层之间、HAL之间、DUT上的装置之间的相关性和/或其它相关性来产生测试套件中的测试。

在一些示例中，可以通过使用“模糊器(fuzzer)”工具来生成模糊测试。具体地，模糊器工具可以基于对HIDL语法(例如，用于嵌套接口、消息队列和/或HIDL存储器的HIDL的语法)的复杂支持来针对模糊测试使用HIDL注释–这种模糊测试可以用于测试调用流程、API黑名单和多DUT场景等。模糊器工具可以用作模糊测试基础架构的一部分，该模糊测试基础架构可以排除先前经历的那些失败的冗余失败和/或与先前经历的那些失败相似的失败，同时继续探索新案例(包括新的失败案例)以确保(更)完整的测试覆盖范围。

可以开发并且执行软件/硬件测试172中的测试以发现DUT与软件(例如，与装置有关的软件和/或与装置无关的软件)之间的相关性；即，在DUT的硬件初始化和/或启动期间。对软件的静态分析可以用于生成相关性和/或其它测试。例如，可以执行脚本以对测试案例代码进行解析以生成用于识别可以指示一种或者多种启动相关性的系统调用的测试。

在一些情况下，测试驱动的开发(TDD)方法论可以用于为目标系统310中的一个或者多个DUT产生软件。该方法论会引起软件/硬件测试172中的新的和/或改进的测试和/或其它测试，该新的和/或改进的测试和/或其它测试用于验证HAL和/或相关的硬件接口定义语言(HIDL)产品、完整性检查、与装置无关的软件(例如，内核软件、操作系统软件)、开发工具包软件、复杂的数据类型、消息队列、共享存储器、模糊测试、(多个)应用二进制接口(ABI)、供应商接口和/或其它软件。这些测试中的一些测试可以利用记录和重放测试；即，存储或者“记录”并且稍后在测试执行期间使用或者“重放”的一组输入。(与在多个HAL中的结构测试相比较，增益为大约5％)。其它测试可以在一个或者多个HAL中引入失败以确保不会(过度)不利地影响其它软件和/或硬件系统。

目标系统310和主机计算装置340可以使用测试消息传递350来协同测试目标系统310的一个或者多个被测装置；例如，以获得(多个)被测装置的兼容性或者其它认证。在一些情况下，测试消息传递350可以包括：测试从主机计算装置340发送至目标系统310的命令和/或其它指令以及从目标系统310发送至主机计算装置340的测试结果/报告。

测试命令可以包括用于针对目标系统310的一个或者多个DUT执行一个或者多个测试、测试模块和/或测试套件的一个或者多个命令。用于执行特定测试模块的示例测试命令是“run vts-m<module name>”，其中，“vts”是指供应商测试套件，并且“<module name>”是特定测试模块的名称。用于执行一个或者多个特定测试的另一示例测试命令是“runvts-kernel-m VtsKernelOStp-t<testname1,testname2,...>”，其中，“vts-kernel”是指在供应商测试套件中的内核测试，“VtsKernelOStp”是指用于操作系统(OS)测试项目的测试模块，并且“testname1”和“testname2”是指在VtsKernelOStp测试模块中的特定测试。对特定测试、测试模块、DUT、测试集群和/或测试命令的其它可能选择和/或其格式也是可能的。

作为另一示例，可以使用在目标系统310的一个或者多个DUT上操作的操作系统(诸如，SELinux操作系统)来帮助进行测试。例如，操作系统可以生成可以由TISS 160和/或主机计算装置340监测的日志文件(诸如，音频日志文件)。操作系统可以提供安全性策略，这些安全性策略可以在测试期间被审核和/或更新并且可以用于发现DUT的硬件和软件之间的相关性。操作系统可以在测试期间生成帮助识别失败的软件和/或硬件的违规操作和/或异常–如果在测试期间观察到这种违规操作和/或异常，则可以认为测试已经失败，并且同样，引起涉及在目标系统310的失败的DUT的硬件和/或软件中的故障修复和/或对失败的测试的重写的解决方案。

操作系统可以支持监测对一个或者多个API(包括但不限于：供应商接口API(例如，procfs、sysfs、dev/))的访问。在一些情况下，操作系统可以在使得能够在测试期间监测系统调用的安全计算模式(seccomp)下运行。在一些示例中，一个或者多个测试可以使操作系统在(多个)测试的一部分或者全部期间在安全计算模式下运行。在其它示例中，可以将操作系统初始化为在其中运行一个或多个测试的测试会话的一部分或者全部过程中在安全计算模式下运行；例如，操作系统在安全测试模式下的执行可以是用于启动测试会话的先决条件。在又一些示例中，TISS 160、主机计算装置340和/或操作系统可以提供对系统调用和/或目标系统的DUT的其它操作系统支持的特征进行后处理和持续监测和/或过滤的支持。

图4是根据至少一些示例实施例的测试系统400的框图。测试系统400包括一个或者多个测试实体计算装置410、一个或者多个云计算装置420以及测试设施300，全部通过使用网络/防火墙430通信地耦合。

测试实体计算装置410可以包括一个或者多个计算装置，该一个或者多个计算装置包括和/或存储测试结果412、测试协调员/用户界面414、一个或者多个软件图像416以及测试监视器418。测试结果412可以包括在测试设施300处的DUT上执行的测试的一个或者多个结果和/或其它结果。例如，测试结果412可以是包括在测试套件150中的测试的结果。

测试协调员/用户界面414可以包括用于控制测试活动的软件和/或硬件，诸如但不限于：对要由一个或者多个DUT(例如，在测试设施300处的DUT)执行的测试进行调度，获得、维持和/或去除软件图像416，将软件图像加载到一个或者多个DUT上，以及获得、维持、报告和/或去除从一个或者多个DUT接收到的测试结果412。测试协调员/用户界面414还可以包括用于显示测试结果、测试报告、有关测试活动的信息、DUT状态(例如，在DUT上可用的软件和/或硬件；DUT是否可用于测试；对在DUT上运行的测试(或者多个测试)的指示)和/或其它信息的软件和/或硬件。例如，测试协调员/用户界面414可以提供仪表板，该仪表板提供有关一个或者多个测试活动的信息和/或控制和/或与测试活动相关的一个或者多个通知的显示。

软件图像416可以包括用于测试DUT的一个或者多个软件图像，包括但不限于：与装置无关的软件120和/或与装置有关的软件130的图像。在一些示例中，可以由与生成与装置有关的软件130的图像相同的与装置相关的实体生成与装置无关的软件120的图像和/或可以在与生成与装置有关的软件130的图像相同的地理位置处生成与装置无关的软件120的图像。在其它示例中，可以由与生成与装置有关的软件130的图像不同的与装置相关的实体生成与装置无关的软件120的图像和/或可以在与生成与装置有关的软件130的图像不同的地理位置处生成与装置无关的软件120的图像。

测试监视器418可以指导并且观察通过一个或者多个DUT对一个或者多个测试的执行，或许是如由测试协调员/用户界面414指示的。在图4中示出的示例中，测试监视器418可以与主机计算装置340上的测试监视器444协作以指导并且观察测试在测试设施300处的执行。在一些示例中，测试执行可以是连续的；即，当完成一组测试中的一个测试时，在测试完成之后尽快执行该组测试中的下一个测试。在其它示例中，测试监视器418可以传送和/或生成/构建一些或者全部软件图像416；例如，用于设置和/或执行测试。

云计算装置420包括一个或者多个计算装置，该一个或者多个计算装置包括和/或存储测试前端422和一个或者多个软件图像424。云计算装置420可以针对测试系统400的测试活动提供支持、测试软件和软件图像。测试前端422可以提供用户界面，该用户界面用于在云计算装置420处接收(上传)来自测试设施300和/或测试实体计算装置410的测试结果，用于发送(下载)软件图像424中的一些或者全部图像，和/或用于查看一个或者多个测试、DUT、设计、实现、特征、组件等的一个或者多个测试状态，其中，测试状态可以指示批准、失败、免除(例如，对当前正在开发/修复的测试的批准、当前正在开发/修复的测试的失败、免除当前正在开发/修复的测试)和/或其它状态值。在一些示例中，测试前端422可以提供更多的、更少的和/或不同的功能性；例如，使得能够上传测试和/或软件图像以便进行测试和/或调试。

图4示出了测试设施300包括主机计算装置340，该主机计算装置340转而包括测试运行器440、测试案例442和测试监视器444。测试设施300还包括目标系统310，该目标系统310具有测试组330。图4描绘了具有测试代理460、HAL驱动器462和测试案例464的测试组330的DUT 110a。HAL驱动器462包括HAL映射470和HAL加载器472，并且可以与一个或者多个HAL 132(包括但不限于：HAL 474a、HAL 474b)通信。

测试运行器440可以包括在主机计算装置340上执行的主机侧软件，该主机计算装置340可以处理测试逻辑并且与一个或者多个目标侧测试组件(例如，DUT 110a)通信以将测试命令450发送至(多个)目标侧测试组件，并且从(多个)目标侧测试组件获得测试结果452。测试案例442可以包括要在测试设施300处的DUT上执行的一个或者多个测试；例如，DUT 110a。如上面在测试监视器418的上下文中讨论的，测试监视器444可以与主机计算装置340上的测试监视器444协作以指导并且观察在测试设施300处执行测试。在一些示例中，主机计算装置340的TISS 160可以包括测试运行器440、测试案例442和/或测试监视器444。

测试代理460可以包括在DUT(例如，DUT 110a)上执行的目标侧软件，该目标侧软件用于在测试运行器440与一个或者多个HAL驱动器(包括HAL驱动器462)之间中继命令、测试结果和/或其它通信。HAL驱动器462可以包括在DUT上执行的目标侧软件，该目标侧软件实施使用一个或者多个目标HAL的守护进程；例如，一个或者多个HAL 132，该一个或者多个HAL 132包括HAL 474a...474b。HAL驱动器462可以通过使用HAL加载器472来加载多个HAL实例，并且针对每个目标HAL维持信息(诸如，HAL映射470)，其中，信息可以包括具有唯一的HAL实例标识符(ID)的实例指针。HAL驱动器462可以将HAL实例ID传递至测试运行器440，使得测试运行器440可以使用HAL实例ID来选择用于经由一个或者多个HAL远程过程调用进行交互的HAL。

DUT 110a还可以包括测试案例464，该测试案例464包括用于在DUT 110a执行的一个或者多个测试。在一些示例中，基于与测试案例相关联的计算机语言，主机计算装置340上的测试案例442可以与测试案例464不同，诸如，测试案例442与Python计算机语言和Java计算机语言相关联，而测试案例464与C计算机语言和C++计算机语言相关联。

如上面提到的，主机计算装置340和目标系统310可以通过使用测试消息传递350来通信。在测试系统400的示例中，测试消息传递350包括：从在主机计算装置340上执行的测试运行器440发送至在DUT 110a上执行的测试代理460的测试命令450；从测试代理460发送至测试运行器440的测试结果452；从测试运行器440发送至测试代理460的HAL服务名称请求454；以及从测试代理460发送至测试运行器440的命名的HAL服务456。在其它示例中，可以在主机计算装置340、测试运行器440、测试代理460、DUT 110a和/或目标系统310之间传送更多的、更少的和/或不同的测试消息传递350。

可以从测试运行器440发送测试命令450以指示测试代理460执行一个或者多个测试；例如，测试案例442和/或测试案例464中的一个或者多个测试。响应于测试命令450，测试代理460可以与测试命令450命令要执行的测试的结果中的一些或者全部结果一起将测试结果452发送至测试运行器440。

测试运行器440可以发送HAL服务名称请求454以确定DUT的一个或者多个HAL的所有服务名称；例如，经由测试代理460的DUT 110a。HAL可以具有多个实例，并且可以用服务名称来对这些实例中的每个实例进行命名。然后，HAL服务名称请求454可以用于确定一个或者多个HAL的服务名称中的所有服务名称或者一个或者多个HAL的所有实例的名称。响应于HAL服务名称请求454，测试代理460可以发送命名的HAL服务456与所请求的服务名称的列表。

例如，可以在DUT 110a上执行测试T1，并且可以将对应的测试结果TR1作为测试消息传递350的一部分从DUT 110a传送至主机计算装置340。主机计算装置340然后可以经由网络/防火墙430将测试结果TR1传送至测试实体计算装置410以便将TR1存储为测试结果412的一部分和/或上传至云计算装置420。当测试结果TR1被上传到云计算装置420时，云计算装置420可以对测试结果TR1进行分析，并且确定测试T1相对于DUT 110a的测试状态、DUT110a的测试状态、DUT 110a的设计的测试状态、110a的实施方式的测试状态和/或与DUT110a相关联的一个或者多个特征和/或组件的测试状态。

在一些情况下，测试套件150包括用于HAL验证和认证的HAL测试。一些HAL测试涉及复杂的测试场景。例如，一些测试场景涉及测试HAL 132中的多个HAL以在多个HAL上验证正确的行为。作为另一示例，可以测试HAL 132中的多个HAL以了解DUT 110a在各种有压力的条件(诸如，比被设计为参考硬件和/或以其它方式被确定为感兴趣的装置的另一(更现代的)装置具有更少的内存)下起作用的方式。

考虑到HAL 132中的每个HAL可以具有在DUT 110a上运行的多个实例(例如，由于DUT 110a的多个可能的硬件配置)，测试多个HAL的组合可能很耗时。可以测试HAL实例的所有可能的组合以完整地测试DUT 110a。可以通过使用包括测试运行器440的测试基础架构系统软件来执行测试HAL的组合(包括各个HAL实例)。

主机计算装置340可以使用TISS 160(包括测试运行器440)来进行以下操作：通过使用目标侧二进制进行多HAL测试来执行对DUT的测试。例如，主机计算装置340可以在目标装置上执行涉及一个或者多个对应的HAL的一个或者多个目标侧二进制图像的测试，并且处理后续的测试结果以便进行验证。另外，主机计算装置340可以使用注册HAL 132中的被测HAL的增强型目标侧测试，使得增强型测试稍后可以用于针对HAL实例的自动(或者手动)测试。

主机计算装置340还可以使用TISS 160来执行主机侧测试，该主机侧测试可以提供精细地校准的测试控制和对多DUT测试的支持。有关精细地校准的测试控制，主机计算装置可以允许用户(诸如，装置测试器)与HAL 132中的多个目标HAL交互并且验证其在API级别下的行为。主机计算装置340还可以允许在测试执行期间指定另外的主机侧控制/监测逻辑。有关对多DUT测试的支持，主机计算装置340可以实现对涉及多个DUT的甚至更复杂的场景(例如，装置之间的对等通信)的测试。在这些场景中的一些场景中，主机计算装置可以协调在多个DUT之间的活动。

例如，假设使用/测试了n个(n>0)目标HAL H1、H2......Hn的列表作为测试被测装置DUT1的协作功能的一部分。每个HAL H1、H2......具有在DUT1上运行的一个或者多个实例；例如，HAL H1具有在DUT1上运行的N1个(N1>0)实例，H2具有在DUT1上运行的N2个(N2>0)实例，......并且HAL Hn具有在DUT1上运行的Nn个(Nn>0)实例。对于在该示例中对DUT1的完整测试，要测试HAL实例的所有组合，即，存在要测试的

个不同的组合。在该场景中，n＝2，其中，HAL H1具有N1＝2个实例，对应的服务名称为H1A和H1B，以及其中，HAL H2具有N2＝3个实例，对应的服务名称为H2A、H2B和H2C。

对于该场景，存在要测试的

个不同的HAL实例组合：(1)H1A、H2A；(2)H1A、H2B；(3)H1A、H2C；(4)H1B、H2A；(5)H1B、H2B；以及(6)H1B、H2C。主机计算装置340可以使用TIS 160来支持针对一些或者所有不同的HAL实例组合的自动测试。例如，主机计算装置340和TISS 160可以：(a)对测试集合中的每个测试进行预处理以确定用于该测试集合的所有目标HAL，其中，可以从测试或者测试运行器获得目标HAL信息；(b)在运行时间获得目标HAL中的每个目标HAL的所有可用服务名称，其中，可以通过向一个或者多个HAL注册服务器查询与在运行时间使用的HAL实例对应的服务名称来获得服务名称；(c)计算用于该组测试的目标HAL的服务名称的所有组合；以及(d)针对服务名称的每个组合执行该组测试中的每个测试。

如上面指示的，当以许多HAL为目标时和/或如果一个或者多个HAL具有许多实例，HAL实例的组合会变得非常大。所以，主机计算装置和TISS可以确定参数K(或许作为用户输入)，其中，K<n。然后，为了减少/优化测试次数，针对n个HAL中的K个HAL测试全部组合；而对于剩余的(n-K)个HAL，仅选择一个组合。对K的选择可以是基于一系列优化技术，该一系列优化技术基于测试运行时间/资源(指示K的较小值)与测试覆盖范围(指示K的较大值)之间的折衷来选择K。

主机计算装置340和TISS 160可以提供对具有一个或者多个HAL以及API的DUT的稳健并且可靠的测试，这些API用于测试开发人员与一个或者多个目标HAL以及目标装置(诸如，DUT 110a)上的其它方面交互以减少(或者消除)开发人员对加载和传送测试以及相关图像进行的工作量。此外，对于多HAL测试，主机计算装置340可以针对HAL实例或者若需要，HAL实例的基于参数的子集的所有组合自动执行测试。

在一些情况下，测试设施300、测试实体计算装置410和云计算装置420受一个与装置相关的实体(例如，生态系统协调员)的控制(例如，由该实体拥有和/或操作)。在其它情况下，测试设施300和测试实体计算装置410受第一个与装置相关的实体(诸如，硅供应商或者原始装置制造商)的控制，而云计算装置420受第二个不同的与装置相关的实体(诸如，生态系统协调员或者另一与装置相关的实体)的控制。在又一些其它情况下，测试实体计算装置410和云计算装置420受三个不同的与装置相关的实体的控制(例如，由该三个实体拥有和/或操作)。其它情况也是可能的；例如，测试设施由多个与装置相关的实体使用的控制情况。

图5示出了根据至少一些示例实施例的在某一时间间隔内发行测试套件的两个场景500、550。在图5和图6中用具有相对较粗的轮廓的框示出了主要与生态系统协调员相关的场景500、550和600的各个方面，并且在图5和图6中利用相对较粗的轮廓示出了除了生态系统协调员之外还主要与一个或者多个与装置相关的实体相关的场景500、550和600的各个方面。

在图5的上部中示出的场景500开始于生态系统协调员在测试发行间隔540开始时发行包括测试套件TS1的测试套件发行510。在场景500中，测试套件TS1是测试套件的某一版本，诸如，测试套件150，其包括与装置无关的软件120的特定版本V1.1的测试案例。测试发行间隔540可以是分布测试套件版本或者发行测试套件版本之间的时间间隔。在场景500中，测试发行间隔540是大约30天长。

在发行TS1之后，场景500在框512、514、516中继续，在框512、514、516中，相应的与装置相关的实体DE1、DE2和DE3获得测试套件TS1的副本。在获得测试套件TS1之后，与装置相关的实体DE1、DE2和DE3中的每一个开始通过并行地使用测试套件TS1来测试计算装置。

在场景500中，与装置相关的实体DE1执行测试套件TS1中的测试TBug，并且确定在测试TBug中存在错误/误差Bug1，并且发送错误报告518以向生态系统协调员通知Bug1。在接收到错误报告518之后，生态系统协调员如在图5中指示的那样通过错误修正520来对测试TBug中的误差进行校正，并且在测试套件发行间隔540结束时发行测试TBug的校正过的版本作为测试套件TS2的测试套件发行530的一部分。

在发送至生态系统协调员的错误报告518和测试套件TS2的测试套件发行530之间的时间间隔期间，相应的与装置相关的实体DE2和DE3分别执行测试TBug，在测试TBug中发现Bug1，并且随后发送相应的错误报告522、524以将Bug1报告给生态系统协调员。在其它场景中，生态系统协调员可以免除通过与装置相关的实体在发送至生态系统协调员的错误报告518和测试套件发行530之间的时间间隔的至少一部分期间成功地完成测试TBug，并且可以将与测试TBug相关的对应豁免发送至已经获得测试套件TS1的一些或者全部与装置相关的实体。在场景500中，所有三个与装置相关的实体DE1、DE2和DE3等待直到测试套件发行间隔540结束以获得测试TBug的校正过的版本为止。

然后，在发行测试套件TS2之后，相应的与装置有关的实体DE1、DE2和DE3中的每一个获得测试套件TS1的副本，并且通过使用测试套件TS2来开始测试。然后，场景500可以结束。

在图5的下部中示出的场景550与场景500相关。场景550开始于生态系统协调员在测试发行间隔540开始时发行包括测试套件TS1的测试套件发行510。在场景550中，测试套件TS1是在场景500的上下文中描述的测试套件，并且测试发行间隔540与场景500中的相同。

在发行TS1之后，场景550在框552、554、556中继续，在框552、554、556中，相应的与装置相关的实体DE1、DE2和DE3获得测试套件TS1的副本。在获得测试套件TS1之后，与装置相关的实体DE1、DE2和DE3中的每一个开始并行地通过使用测试套件TS1来测试计算装置。

在场景550中，与装置相关的实体DE1执行测试套件TS1中的测试TBug2，并且确定在测试TBug2中存在错误/误差Bug2，并且发送错误报告560以向生态系统协调员通知Bug2。在接收到错误报告560之后，生态系统协调员将错误通知562、564、566发送至相应的与装置相关的实体DE1、DE2、DE3，从而向与装置相关的实体通知在测试TBug2中的所报告的错误Bug2。在场景550中，与装置相关的实体DE2、DE3检查相应的错误通知564、566，并且确定不在其相应的计算装置执行测试TBug2。在一些场景中，错误通知564、566可以时充当在发送错误通知564、566和在测试套件发行间隔540结束的测试套件TS2发行580之间的时间间隔期间成功地完成测试TBug2的(有效)豁免。

在发送了错误通知562、564、566之后，生态系统协调员如在图5中指示的那样通过错误修正570来对测试TBug2中的误差进行校正，并且在测试套件发行间隔540结束时发行测试TBug2的校正的版本作为测试套件TS2的测试套件发行580的一部分。在场景550中，所有三个与装置相关的实体DE1、DE2和DE3等待直到测试套件发行间隔540结束以获得测试TBug2的校正的版本为止。然后，在发行测试套件TS2之后，相应的与装置有关的实体DE1、DE2和DE3中的每一个获得测试套件TS1的副本，并且开始通过使用测试套件TS2来进行测试。然后，场景550可以结束。

图6示出了根据至少一些示例实施例的在某一时间间隔内发行测试套件的场景600。场景600与场景500和550相关。场景600开始于生态系统协调员在测试发行间隔640开始时发行包括测试套件TS1的测试套件发行510。在场景600中，测试套件TS1是在场景500和550的上下文中描述的测试套件。

在发行TS1之后，场景600在框612、614、616中继续，在框612、614、616中，相应的与装置相关的实体DE1、DE2和DE3获得测试套件TS1的副本。在获得测试套件TS1之后，与装置相关的实体DE1、DE2和DE3中的每一个开始并行地通过使用测试套件TS1来测试计算装置。

在场景600中，与装置相关的实体DE1执行测试套件TS1中的测试TBug3，并且确定在测试Tbug3中存在错误/误差Bug3，并且发送错误报告620以向生态系统协调员通知Bug3。在接收到错误报告620之后，生态系统协调员如在图6中指示的那样通过错误修正622来对测试Tbug3中的误差进行校正，并且在测试套件发行间隔640结束时发行测试Tbug3的校正的版本作为测试套件TS2的测试套件发行630的一部分。在场景600中，使用了针对测试套件的连续发行过程，因此，测试套件发行间隔640是一天；在相关场景中，测试套件发行间隔640是1至3天长。

在场景600中，所有三个与装置相关的实体DE1、DE2和DE3等待直到测试套件发行间隔540结束以获得测试Tbug3的校正的版本为止。然后，在发行测试套件TS2之后，相应的与装置有关的实体DE1、DE2和DE3中的每一个获得测试套件TS1的副本并且开始通过使用测试套件TS2来进行测试，如在图6中通过相应的块632、634、636示出的。然后，场景600可以结束。

使用针对测试套件的连续发行过程可以向生态系统提供益处。测试套件发行间隔640比测试套件发行间隔540短很多；例如，测试套件发行间隔640可以是1至3天，而测试套件发行间隔540是30天。使用连续发行过程大大缩短了测试套件发行间隔，诸如，为30天的测试套件发行间隔540；例如，如用于测试套件发行间隔640，从30天减少到1至3天。针对测试套件的连续发行过程可以在测试套件TS1中的至少进行一次更改(例如，针对错误修正的更改、针对新的功能性的更改、针对新的测试的更改)后立即通过生态系统协调员提供测试套件TS1的更新版本。通过不等待特定的发行时间和/或通过更频繁地发行测试套件，可以缩短测试套件发行间隔，从而使更改过的/更新过的测试套件更快地到达与装置相关的实体，从而减少了等待更新过的测试所花费的时间。进一步地，可以减少并且或许是消除多个与装置相关的实体的冗余工作(诸如，在发送错误报告518之后，场景500中的与装置相关的实体DE2和DE3执行失败的测试TBug)。此外，由于测试套件发行发生得更加频繁，因此，生态系统协调员会发出更少的豁免和/或错误通知。

图7是根据至少一些示例实施例的与分类测试相关的系统700的框图。系统700包括在TISS 160处接收到的测试报告710、720、...722，其中，测试报告710可以包括针对从在参考硬件和/或软件上执行的测试接收到的时间段P的测试报告，测试报告720可以包括针对来自由与装置相关的实体DE1执行的测试的时间段P的测试报告，并且测试报告722可以包括针对来自由与装置相关的实体DEn执行的测试的时间段P的测试报告。在一些示例中，时间段P可以是其持续时间是预定的时间段；例如，8小时、12小时、一天、一周、两周、15天、一个月、三个月等。即，在时间段P，测试报告在TISS 160处从在参考硬件和/或软件上执行的测试以及从n个不同的与装置相关的实体执行的测试被接收到。在一些示例中，测试报告710、720...722是来自都执行软件的预定发行的DUT的测试报告；例如，与装置无关的软件120的预定发行和/或与装置有关的软件130的预定发行。

测试报告710、720...722可以由TISS 160处理以创建针对时间段P 730的一个或者多个增量测试报告。增量测试报告是指示两个或者更多个不同的测试报告之间的变化或者“增量(delta)”的测试报告。在一些示例中，测试报告包括测试模块名称、测试案例名称和测试案例结果(例如，通过或者未通过)的列表。在特定示例中，TISS 160可以从多个不同的参考硬件和/或非参考装置接收测试报告，其中，非参考装置测试报告可以是基于不同的硬件和/或软件版本。然后，TISS 160可以生成表示不同装置类型之间的变化的一个或者多个增量测试报告；例如，在装置的不同实例、设计和/或实施方式之间有所不同的测试结果。在一些情况下，可以形成在增量测试报告中的不同装置类型的树；例如，增量测试报告可以示出针对与特定的与装置相关的实体相关联的所有DUT的增量，这些增量可以具有多个DUT设计，并且特定的与装置相关的实体的每个不同的设计可以具有多种实施方式，并且特定的与装置相关的实体的每种不同的实施方式可以具有多个实例/DUT。然后，增量测试报告可以示出在实例、设计和/或实施方式之间和/或当与装置相关的实体在装置中引入或者修正错误或者其它误差时的常见故障。

可以对测试进行分类；即，基于分类算法750重新对测试进行排序、省略测试和/或免除测试。在图7中示出的示例中，分类算法750由TISS 160的分类软件(TS)740执行。分类算法750可以在框760中开始，在该框760中，分类软件740可以从测试结果(诸如但不限于：针对时间段P 730的增量测试报告)确定零个或者更多个失败的测试FT。在时间段P内存在零个失败的测试FT的示例中，分类算法750可以在框760中结束。

假设存在一个或者多个失败的测试FT，分类软件740可以继续至框770以开始执行for循环以选择失败的测试FT中的失败的测试FT1并且对其进行操作。for循环包括框770、772、774和780的过程。

在框772中，分类软件740可以确定可以基于测试FT1是失败的测试这一事实来对其进行分类的测试。具体地，分类软件740可以确定依赖于测试FT1的零个或者多个测试TD。当必须在测试T1之后执行测试T2时，测试T2依赖于测试T1；例如，测试T1建立了开始测试T2所需的一个或者多个初始条件，只有经过测试T1才能执行测试T2。

分类软件740可以针对报告失败的测试FT1的失败的DUT确定公共误差源。例如，分类软件740可以使用分类层级和/或分类标准来针对失败的测试FT1确定一个或者多个误差源。分类层级可以开始于报告测试报告710、720、...722的所有报告DUT共有的误差源；例如，与装置无关的软件的特定版本、经历中间误差源；例如，一些而不是全部报告DUT共有的特定计算机装置设计、具有特定计算机装置设计的一些而不是全部报告DUT共有的特定计算机装置设计的特定实施方式、一些而不是全部报告DUT的公共组件、一些而不是全部报告DUT的公共硬件或者软件特征等，将在特定DUT处结束。

例如，是来自硅供应商SV1的设计DES1的实施方式IMP1并且执行由生态系统协调员EC1提供的与装置无关的软件120的版本RIND1以及由SV1提供的与装置有关的软件的版本RDEP1的DUT(DUT_FT1)可以具有分类层级Thier1：(a)执行与装置无关的软件版本RIND1的所有报告DUT，(b)执行由硅供应商SV1构建的RIND1的所有报告DUT，(c)执行由SV1构建的具有设计DES1的RIND1的所有报告DUT，(d)执行具有SV1的设计DES1的实施方式IMP1的RIND1的所有报告DUT，(e)执行具有SV1的设计DES1的实施方式IMP1的RIND1并且执行与装置有关的软件的RDEP1的所有报告DUT，以及(f)指示失败的特定报告DUT；例如，DUT_FT1。

分类标准可以用于针对失败的测试FT1确定分类标准中的哪个误差源被暗示为可能的公共误差源。在最初，分类软件740可以将初始公共误差源确定为分类层级中的最低误差源；例如，DUT作为当前误差源。然后，分类软件740可以通过确定是否满足下一较高的误差源高于当前误差源的分类标准来尝试向上移动分类层级。如果满足下一较高的误差源高于当前误差源的分类标准，则分类软件740可以向上移动分类层级以将当前误差源设置为等于其次最高的误差源。然后，分类软件740可以继续尝试向上移动分类层级，直到(a)不满足下一较高的误差源高于当前误差源的分类标准，或者(b)确定当前误差源是分类层级中的最高误差源。然后，一旦尝试向上移动分类层级完成，分类软件740就可以针对失败的测试暗示当前误差源。

在一些示例中，分类标准可以是基于分类百分比或者未通过共享公共误差源的测试的DUT的百分比。在上面列出的特定示例中，假设包括DUT_FT1的10个DUT执行了测试FT1并且在分类层级THier1组(e)中，该THier1组(e)是包括执行具有SV1的设计DES1的实施方式IMP1的RIND1并且执行与装置有关的软件的RDEP1的所有报告DUT的一组DUT，并且THier1组(e)的分类百分比为55％。当THier1组(e)中超过55％*10个DUT＝5.5个DUT未通过测试FT1时，可以将THier1组(e)暗示为公共误差源的一部分(或者全部)。在一个特定示例中，THier1组(e)中的7个DUT未通过测试FT1，因此，将THier1组(e)暗示为公共误差源的一部分(或者全部)。

然后，如果将分类层级中的较低误差源指示为可能的误差源，则分类软件740可以通过检查分类层级中的下一较高的误差源作为可能的误差源的分类标准来尝试向上移动分类层级。继续上面的示例，由于公共误差源包括THier1分类组(e)，因此，分类软件740然后可以检查分类层级THier1中的下一较高的组–在这种情况下，是分类THier1组(d)，该分类THier1组(d)是执行具有SV1的设计DES1的实施方式IMP1的RIND1的所有DUT的组。继续该示例，假设THier1组(d)包括30个报告DUT并且THier1组(d)的分类百分比为60.1％，如果THier1组(d)中的30*60.1％＝18.3个DUT未通过测试FT1，则会将THier1组(d)暗示为公共误差源的一部分。在该特定示例中，THier1组(d)中的13个DUT未通过FT1，因此，分类软件740可以确定针对FT1，无法进一步向上移动分类层级，因此，针对失败的测试FT1暗示的公共误差源是THier1组(e)。

在另一示例中，如果THier1组(e)中只有3个DUT未通过FT1，则不会将组(e)暗示为公共误差源的一部分，因此，只会在示例分类层级和分类标准下暗示组(f)(该组(f)只包括DUT_FT1)。

在其它示例中，可以确定统计模型，该统计模型指示未通过测试FT1的、具有公共误差源的DUT的预期数量，并且如果超过未通过测试FT1的DUT的预期数量，则可以在失败的测试FT1中暗示公共误差源。在又一些示例中，默认误差源是报告测试FT1的失败的特定DUT。用于针对一个或者多个失败的测试确定公共误差源的其它分类层级、其它分类标准以及其它技术也是可能的。

分类软件740还可以确定可以基于针对失败的测试FT1的所确定的公共误差源CSE来对其进行分类的零个或者多个测试TCSE。继续使用了上面提到的分类层级THier1的示例，如果暗示了THier1组(e)，则可以针对THeir1组(e)中的所有DUT对包括失败的测试FT1和依赖于FT1的任何从属测试FT的测试集合TSCE进行分类。

在框774中，分类软件740可以生成与FT和TSCE相关的一个或者多个输出。(多个)输出可以包括但不限于：用于针对CSE中的一些或者所有DUT省略测试TD和/或TCSE，重新对测试TD和/或TCSE进行排序，免除测试TD和/或TCSE和/或以其它方式对测试TD和/或TCSE进行分类的指令；针对TD和/或TCSE的一个或者多个测试错误报告；针对测试TD和/或TCSE的一个或者多个测试错误通知。

在框780中，分类软件740可以确定是否存在要由for循环处理的更多失败的测试FT。如果存在更多失败的测试，则分类软件740可以继续至框770以重新开始for循环。或者，不存在更多失败的测试，并且分类算法750可以结束。在一些示例中，在分类算法750的for循环结束之后，可以输出在框774中提到的输出。

在一些示例中，增量测试报告730可以是基于由一个或者多个DUT(DUT1至DUTd(d>0))对具有第一软件版本的软件(与装置有关的软件130和/或与装置无关的软件120)的执行；例如，由DUT(DUT1至DUTd)对软件的版本1.1执行的测试T1至Tn(n>0)的测试报告。然后，分类软件740可以通过另外对执行了等于或者超过第一软件版本的第二软件版本的DUT(DUT1至DUTd)中的一些或者全部DUT执行测试T1至Tn中的一些或者全部测试来获得相关版本测试结果；例如，由一个或者多个DUT(DUT1至DUTd)对软件的版本1.2(或者更新的版本)执行的一个或者多个测试Tm1、Tm2...(1≤m1、m2、...≤n)的测试结果，其中，版本1.2比版本1.1更新。然后，分类软件740可以对与版本1.2相关的测试结果进行分析以确定是否成功地对执行版本1.2(或者更新的版本)的DUT(DUT1至DUTd)中的一些或者全部DUT执行了Tm1、Tm2中的测试Ts。然后，在确定成功地对执行软件1.2的更新的版本的一个或者多个DUT执行了测试Ts之后，软件740可以确定对以下操作进行分类：有关软件版本1.1成功地对第二DUT执行测试Ts；即，有关软件的更新的版本的测试的成功结果会使分类软件740对有关相同软件的更早的版本的测试的执行进行分类；即，由于分类软件740可以通过使用软件的更新的版本来依赖成功结果。

涉及在装置测试期间对测试进行分类的示例场景

图8是根据至少一些示例实施例的用于场景800的系统802的框图。场景800涉及测试系统802中的装置和对针对系统802中的装置的测试进行分类。系统802包括测试设施810、830、850和生态系统协调员云计算系统(ECCCS)870，全部通过网络880通信地耦合。

测试设施810受硅供应商SV810的控制，并且包括测试系统812和主机计算装置820。测试系统812包括具有测试组816的测试集群814，该测试组816转而包括DUT 818a、DUT818b、DUT 818c。DUT 818a、DUT 818b、DUT 818c是分别被制造为硅供应商SV810的设计DES_810的实施方式IMP_810的计算装置。主机计算装置820包括配置有测试基础架构系统软件160的一个或者多个计算装置，该测试基础架构系统软件160包括分类软件740和测试基础架构系统软件160的其它本文所描述的方面。

测试设施830受硅供应商SV830的控制，并且包括目标系统832和主机计算装置840。目标系统832包括具有测试组836a、836b的测试集群834。测试组836a包括DUT 838a、DUT 838b，并且测试组836b包括DUT 838c、DUT 838d。DUT 838a、DUT 838b是分别被制造为硅供应商SV830的设计DES_830的实施方式IMP_830a的计算装置，并且DUT 838c、DUT 838d是分别被制造为硅供应商SV830的设计DES_830的实施方式IMP_830b的计算装置。主机计算装置840包括配置有测试基础架构系统软件160的一个或者多个计算装置，该测试基础架构系统软件160包括分类软件740和测试基础架构系统软件160的其它本文所描述的方面。

测试设施850受硅供应商SV850的控制，并且包括目标系统852和主机计算装置860。目标系统852包括测试集群854a、854b。测试集群854a具有测试组856a、856b，并且测试集群854b具有测试组856c、856d。测试组856a具有DUT 858a，测试组856b具有DUT 858b、DUT858c，测试组856c具有DUT 858d、DUT 858e、DUT 858f，并且测试组856d具有DUT 858g、DUT858h、DUT 858i、DUT 858j。

DUT 858a是被制造为硅供应商SV850的设计DES_850的实施方式IMP_850a的计算装置。DUT 858b、DUT 858c是被制造为硅供应商SV850的设计DES_850的实施方式IMP_850b的计算装置。DUT 858d、DUT 858e、DUT 858f是被制造为硅供应商SV850的设计DES_851的实施方式IMP_851a的计算装置。DUT 858g、DUT 858h、DUT 858i、DUT 858j是被制造为硅供应商SV850的设计DES_851的实施方式IMP_851b的计算装置。主机计算装置860包括配置有测试基础架构系统软件160的一个或者多个计算装置，该测试基础架构系统软件160包括分类软件740和测试基础架构系统软件160的其它本文所描述的方面。

在场景800中，每个测试设施受不同的硅供应商的控制；即，测试设施810、820、830受相应的硅供应商SV810、SV820、SV830的控制。场景800中的每个测试集群包括共享公共硬件设计的DUT；即，测试集群814、834、854a、854a包括具有相应设计DES_810、DES_830、DES_850、DES_851的DUT。场景800中的每个测试组包括共享设计的公共实施方式的DUT；即，测试组816、836a、836b、856a、856b、856c、856d包括作为相应实施方式IMP_810、IMP_830a、IMP_830b、IMP_850a、IMP_850b、IMP_851a、IMP_851b的DUT。因此，在场景800中，每个目标系统与一个硅供应商相关联，每个测试集群与一个设计相关联，并且每个测试组与对应的设计的一种实施方式相关联。

生态系统协调员云计算装置(ECCCD)870包括配置有测试前端422、测试套件872和测试基础架构系统软件160的一个或者多个计算装置，该测试基础架构系统软件160包括分类软件740和测试基础架构系统软件160的其它本文所描述的方面。测试套件872包括一个或者多个测试案例874、一个或者多个与装置无关的软件图像876(该一个或者多个与装置无关的软件图像876包括与装置无关的软件120的软件图像)以及包括分类软件740的测试基础架构系统软件160的副本。

在场景800中，ECCCD 870受生态系统协调员的控制，并且生态系统协调员制作了测试套件872并且经由网络880将测试套件872提供至测试设施810、830、850，该测试套件872包括测试案例874和与装置无关的软件图像876以及测试基础架构系统软件160。ECCCD870还在场景800期间经由网络880向测试设施810、830、850提供对测试前端422的访问。此外，在场景800期间，ECCCD 870正在执行包括分类软件740的测试基础架构系统软件160的实例。

图9示出了根据至少一些示例实施例的用于场景800的测试套件872、分类层级920和分类标准940的框图。如上面提到的，测试套件872包括测试案例874、与装置无关的软件图像876以及具有分类软件740的测试基础架构系统软件160的副本。图9示出了测试案例874包括软件/硬件测试910和相关的比较测试结果912。

在场景800中，执行了软件/硬件测试910中的被编号为测试1至18的18个测试，其中，测试1至18包括用于测试与装置无关的软件图像876和相关的API的一个或者多个测试以及用于测试与装置有关的软件130的软件图像和相关的API和HAL的一个或者多个测试。这些测试包括API测试。在一些场景中，软件图像可以包括对与装置无关的软件120和与装置有关的软件130的表示。具体地，与装置无关的软件图像876的一个或者多个示例可以包括对与装置无关的软件120和与装置有关的软件130两者的表示。与装置无关的软件图像876的这些示例可以在一个地理位置中生成。例如，受生态系统协调员的控制的设施的地理位置能够构建软件图像，这些软件图像包括以下软件图像：该软件图像包括与装置无关的软件120和与装置有关的软件130)两者，或者可以在多个地理位置中生成。作为另一实例，可以通过使用第一软件图像和第二软件图像来在受硅供应商或者其它与装置相关的实体的控制的设施的地理位置LOC1处生成软件图像876，该第一软件图像包括由生态系统协调员在地理位置LOC2处生成的与装置无关的软件120，该第二软件图像包括由硅供应商或者其它与装置相关的实体在地理位置LOC1或者不同的地理位置处生成的与装置有关的软件130。在这些实例中的一些实例中，可以将软件图像876中包括与装置无关的软件120的软件图像SI1作为测试套件872的一部分从LOC1传送至LOC2，在LOC2处生成软件图像SI2，该软件图像SI2包括软件图像SI1中的与装置无关的软件120以及实施与装置有关的软件130的软件。然后，可以通过执行软件图像SI2中的软件的DUT来执行测试1至18。

如在图9中图示的，软件/硬件测试910中的若干测试是独立的测试，包括测试1、测试2、测试3、测试4、测试7、测试10、测试14和测试18，而其余测试是从属测试。从属测试包括：依赖于测试4的测试5；依赖于测试5的测试6；依赖于测试7的测试8；依赖于测试8的测试8；测试10和测试11，该测试10和11中的每一个依赖于测试10；依赖于测试12的测试13；依赖于测试14的测试15；依赖于测试15的测试16；以及依赖于测试16的测试17。比较测试结果912包括针对所有软件/硬件测试910的执行的通过测试结果，包括针对测试(测试1至测试18)中的每个测试的通过测试结果。在场景900中，比较测试结果912由生态系统协调员生成并且提供作为来自在生态系统协调员的控制下在参考计算装置上成功执行软件/硬件测试910中的每个测试的测试结果。

分类层级920提供用于在场景800期间对测试进行分类的层级。分类层级920包括公共误差源层级和对应的场景800实体层级。分类层级920的公共误差源层级包括最高的误差源—与装置无关的软件/测试套件误差源922，该与装置无关的软件/测试套件误差源922在设计误差源924之上，该设计误差源924在实施方式误差源926之上，该实施方式误差源926在最低的误差源之上，该最低的误差源是DUT误差源928。如在图9中示出的，分类层级920还包括场景800的对应实体的层级，其与公共误差源相关联。即，图9说明了：在场景800期间，“DIS/测试套件”误差源922与“生态系统协调源”相关联；在场景800期间，“设计”误差源924与“测试组”相关联；在场景800期间，“实施方式”误差源926与“测试组”相关联；并且“DUT”误差源928与“DUT”相关联。在其它场景中，分类层级920包括不同的公共误差源层级，不包括对应的实体层级，和/或包括更多的、更少的和/或不同的层级。

如上面在分类算法750的上下文中讨论的，当对与失败的测试相关联的测试进行分类时，分类软件740可以在最初暗示最低的误差源；例如，DUT误差源928，并且尝试向上移动分类层级920以发现针对失败的测试的最高的误差源。在场景800中，只要满足针对误差源S2的分类标准940，分类软件740就可以将分类层级920从当前误差源S1向上移动到其次最高的误差源S2，。如果未满足针对其次最高的误差源S2的分类标准940，则分类软件740可以确定当前误差源S1是针对失败的测试暗示的误差源，并且停止尝试向上移动分类层级。

如果满足针对其次最高的误差源S2的分类标准940并且S2是分类层级920中最高的误差源(例如，与装置无关的软件/测试套件误差源922)，则分类软件740可以停止尝试向上移动分类层级920，并且确定生态系统协调员是利用失败的测试暗示的误差源，因为生态系统协调员是场景800中与分类层级920中的最高的误差源对应的实体。一旦分类软件740已经针对失败的测试暗示了误差源，分类软件740就可以使用针对暗示的误差源的分类标准来对测试进行分类。

分类标准940包括用于在场景800期间对测试进行分类的标准。分类标准940中的一个或者多个分类标准可以与分类层级920中的一个公共误差源相关联。即，对于分类层级920中的与装置无关的软件/测试套件误差源、设计误差源、实施方式误差源和DUT误差源中的每一个，存在分类标准940中的单独的分类标准。分类标准940还包括“51％”的分类百分比“TriagePercent”，该分类百分比“TriagePercent”在场景800期间用于所有其它分类标准。在其它场景中，每个公共误差源可以具有更多的和/或不同的标准，和/或分类标准可以包括更少的、更多的和/或不同的分类百分比。

如在图9中图示的，与“DUT”误差源928相关联的分类标准940中的分类标准指示：“如果未通过测试T，则对与测试T相关的所有测试进行分类”。在场景800中，如果(a)T1＝T或者(b)T1依赖于T，则测试T1与测试T相关。同样，在场景800中，如果(a)T1＝T，(b)T1依赖于T或者(c)T依赖于T1，则测试T1与测试T父相关。即，与“DUT”误差源928相关联的分类标准940指示：在针对DUT未通过测试T之后，分类软件740将与针对DUT的测试T相关的所有测试进行分类。

与“实施方式”误差源926相关联的分类标准940中的分类标准指示：“如果”不只是“DUT在测试组中的TriagePercent”(该测试组是与实施方式误差源926对应的实体)“未通过测试T”，则分类软件740将“针对与测试T相关的所有测试对测试组进行分类”。即，在超过TriagePercent的在测试组TG_FAIL中的DUT未通过测试T之后，分类软件740将针对测试组TG_FAIL中的所有DUT对与测试T相关的所有测试进行分类。

与“设计”误差源924相关联的分类标准940中的分类标准指示：“如果”不只是“TriagePercent的在测试集群中的DUT或者测试组”(该测试集群是与设计误差源924对应的实体)“未通过测试T”，则分类软件740将“针对与测试T相关的所有测试对该测试集群进行分类”。即，在不只是TriagePercent的(a)在测试集群TC_FAIL中的DUT未通过测试T或者(b)在测试集群TC_FAIL中的测试组未通过测试T之后，分类软件740将针对测试集群TC_FAIL中的所有DUT对与测试T相关的所有测试进行分类。

与“DIS/测试套件”误差源922相关联的分类标准940中的分类标准指示：“如果”不只是“TriagePercent的或者更多的在所有测试设施处的DUT、测试组或者测试集群未通过测试T”，则分类软件740将“针对在所有测试设施处的所有测试集群对与测试T父相关的所有测试进行分类”。在场景800中，所有测试设施正在使用均由生态系统协调员提供的与装置无关的软件120和测试套件872，因此，提及“所有测试设施”的标准等同于提及与装置无关的软件/测试套件误差源922的标准。在场景800中，生态系统协调员是与和装置无关的软件/测试套件误差源922对应的实体。即，如果在不只是TriagePercent的(a)在所有测试设施处的所有DUT、(b)在所有测试设施处的所有测试组或者(c)在所有测试设施处的所有测试集群未通过测试T，则分类软件740将针对在所有测试设施处的所有DUT对与测试T父相关的所有测试进行分类。在场景800中，当对测试进行分类时，省略该测试。

在其它场景中，分类标准(诸如，分类标准940)包括一个或者多个标准，该一个或者多个标准与暗示与装置无关的软件的误差源和/或测试套件两者相关联；例如，“DIS/测试套件”误差源922，并且与有关与装置相关的实体报告测试的失败的数据(诸如，数字或者百分比)相关联。例如，假设生态系统协调员针对N2个DUT从总数为N1个与装置相关的实体接收到针对测试T_GFAIL的测试结果并且测试结果指示：对于与N4个(N4≤N1)与装置相关的实体的N3个DUT(N3≤N2)未通过测试T_GFAIL。然后，在确定对测试T_GFAIL进行分类之前，与生态系统协调员相关联的计算装置(例如，ECCCD 870)可以应用与超过阈值数量、百分比或者其它值的若干与装置相关的实体相关联的一个或者一个分类标准；例如，如果N4大于失败的与装置相关的实体的阈值数量NF(NF＝2、NF＝3、NF＝10、NF＝25、NF＝100、...)，则N4/N1大于失败的与装置相关的实体的阈值百分比NP(例如，NP＝3.33％、NP＝5％、NP＝20％、NP＝50％)，如果大于失败的与装置相关的实体的阈值数量NF并且大于DUT的阈值数量ND(ND＝10、ND＝16、ND＝50、...)，则未通过测试T_FAIL。与失败的DUT、测试、测试组、测试集群、测试设施和/或与装置相关的实体的数量、百分比和/或其它值相关的其它分类标准也是可能的。

在场景800中，当应用分类标准940时，如果测试T在执行期间失败或者对测试T进行了分类并且因此，针对DUT、测试组、测试集群或者生态系统协调员，假定测试T已经失败，则认为DUT、测试组、测试集群或者生态系统协调员未通过测试T。所以，使测试组TG_EX1具有三个DUT(DUT_EX1、DUT_EX2、DUT_EX2)，并且对于特定的测试T_EX，DUT_EX1使得已经对测试T_EX进行了分类，DUT_EX2未通过测试T，并且DUT_EX3通过了测试T。然后，测试组TG_EX1的失败百分比将是2/3＝大约67％，因为DUT_EX1和DUT_EX1失败或者对测试T进行了分类，并且测试组TG_EX1中有三个DUT。其它示例也是可能的。

图10、图11、图12、图13、图14和图15共同示出了根据至少一些示例实施例的针对场景800的通信流程。该通信流程涉及测试设施810、830、850和ECCCD 870之间的通信。通信流程开始于ECCCD 870使测试套件872可用于测试设施810、830、850，然后，测试设施810、830、850中的每一个下载并且安装测试套件872。然后，测试设施810、830、850中的每一个注册其相应DUT以便测试涉及测试套件872的会话。使用测试套件872中的18个测试的测试开始于在所有测试设施处的所有DUT通过测试1至5，并且在测试设施810处的除了DUT 818b之外的所有DUT通过测试6。然后，主机计算装置820针对DUT 818b对测试6进行分类。然后，在测试设施810、830、850处的所有DUT上执行测试7至9-在测试设施810和850处的所有DUT通过所有三个测试。在测试设施830处，DUT 838a未通过测试7，因此，主机计算装置840针对DUT 838a对测试7至9进行分类。然后，DUT 838b和DUT 838c都未通过测试8，因此，主机计算装置840针对测试集群834中的所有DUT对测试8和测试9进行分类。

然后，在测试设施810、830、850处的所有DUT上执行测试10至13-在测试设施810和830处的所有DUT通过所有四个测试。在测试设施850处，DUT 858a和DUT 858j都未通过测试10，因此，主机计算装置860针对测试组856a以及DUT 858j对这样的测试计算装置以及这样的测试10至13进行分类。然后，DUT 858b未通过测试11，因此，主机计算装置860针对测试集群854a中的所有DUT对测试11至13进行分类。DUT 854d和DUT 854g都未通过测试12，因此，主机计算装置860针对DUT 854d和DUT 854g对测试12和测试13进行分类。然后，在测试设施850处的所有未分类的DUT都通过了测试13。

通信流程指示：在测试设施810处的测试暂停，而在两个测试设施830和850处，测试继续，其中，所有DUT都执行测试14至17。在测试设施830处的所有DUT都通过了测试14，但是DUT 858e、DUT 858f、DUT 858h和DUT 858i都未通过测试14，因此，主机计算装置860针对测试组856c以及DUT 858h和DUT 858i对测试14至17进行分类。在测试设施830处的DUT838b、DUT 838c、DUT 838d和在测试设施850处的DUT 858a，DUT 858b，DUT 858c，DUT 858g未通过测试15。随后，主机计算装置840针对测试集群834对测试15至17进行分类，并且主机计算装置860针对测试集群854a和854b对测试15至17进行分类。在接收到分类的测试集群834、854a和854b针对测试15至17的报告之后，ECCCD 870针对在测试设施810、830、850处的所有DUT对测试14至17进行分类。然后，在测试设施810、830、850中的每一个测试设施处的所有DUT执行测试18，并且它们通过了测试18，并且将针对测试套件872的测试报告从测试设施810、830、850中的每一个发送至ECCCD 870。

然后，场景800继续，ECCCD 870将更新过的测试套件872提供至测试设施810和850，修正了测试14至17。在测试设施850处，重新执行测试14至17，并且所有DUT都通过了测试14至17。在测试设施810处，重新执行测试1至18中的所有测试，并且除了DUT 818b再次未通过测试6之外，所有DUT都通过了测试1至18。更新DUT 818b，并且在更新之后，DUT 818b通过了测试6。然后，测试设施810针对测试集群814请求对测试套件872的批准，并且然后，ECCCD 870针对通过测试套件872测试的功能性批准测试集群814。然后，场景800结束。

图10示出了场景800的通信流程在框1010中开始，在该框1010中，ECCCD 870使测试套件872普遍可用。然后，接着发生通信1012，其中，测试设施810获得测试套件872。然后，测试设施830通过使用通信1014来获得测试套件872，并且测试设施850通过使用通信1016来获得测试套件872。

在框1020中，测试设施810安装测试套件872；即，测试设施810从测试套件872获得测试案例874、(多个)与装置无关的图像876和具有分类软件740的TISS 160，并且准备好TISS 160以供主机计算装置820执行。在场景800中，当主机计算装置在测试设施(诸如，测试设施810)处执行TISS 160时，TISS 160用于在进行分类之前按照数字顺序来在测试设施处的所有DUT上执行测试案例874的软件/硬件测试910中的测试1至18，将来自对测试的执行的测试结果与比较测试结果912相比较，并且基于测试结果与比较测试结果912的比较来确定是否通过了测试1至18中的每个测试。TISS 160还针对在测试设施处执行测试的每个DUT记录测试1至18中的每一个测试的通过/未通过的状态，并且如果测试未通过，则对测试进行分类，并且将失败的测试报告给ECCCD 870。

在框1022中，测试设施830安装测试套件872，如上面在针对测试套件872在测试设施810处的安装的框1020中指示的那样。在框1024中，测试设施850安装测试套件872，如上面在针对测试套件872在测试设施810处的安装的框1020中指示的那样。

然后，测试设施810发送RegisterDUTs消息1030以向ECCCD 870通知在“TF 810”处执行“测试套件872”的DUT、测试组和测试集群或者注册在“TF 810”处执行“测试套件872”的DUT、测试组和测试集群；例如，测试设施810。RegisterDUTs消息1030向ECCCD 870通知：测试设施810具有“TC 814”作为对测试集群814的通知，针对测试组816，该消息包括“TG816”，并且其中，测试组816包括DUT—“DUT 818a、DUT 818b”和“DUT 818c”。基于RegisterDUT消息1030中的该信息，在ECCCD 870处执行的TISS 160和分类软件740可以确定测试设施810具有一个测试集群，该测试集群具有包括三个DUT的一个测试组。

然后，测试设施830发送RegisterDUTs消息1032以向ECCCD 870通知在“TF 830”处执行“测试套件872”的DUT、测试组和测试集群；例如，测试设施830。RegisterDUTs消息1032向ECCCD 870通知：测试设施830具有“TC 834”作为对测试集群834的通知，该测试集群834针对具有DUT(“DUT 838a”和“DUT 838b”)的测试组836a包括“TG 836a”；RegisterDUT消息1032还向ECCCD 870通知：测试集群834针对具有DUT(“DUT 838c”和“DUT 838d”)的测试组836b包括“TG 836b”。基于RegisterDUT消息1032中的该信息，在ECCCD 870处执行的TISS160和分类软件740可以确定测试设施830具有一个测试集群，该测试集群具有两个测试组，并且该两个测试组具有两个DUT。

然后，测试设施850发送RegisterDUTs消息1034以向ECCCD 870通知在“TF 850”处执行“测试套件872”的DUT、测试组和测试集群；例如，测试设施850。RegisterDUTs消息1034向ECCCD 870通知：测试设施850具有“TC 854a”作为对测试集群854a的通知，该测试集群854a针对具有“DUT 858a”的测试组856a包括“TG 856a”，并且针对具有DUT(“DUT 858b”和“DUT 858c”)的测试组856b包括“TG 856b”。RegisterDUT消息1034还向ECCCD 870通知：测试设施850包括如通过使用“TC 854b”通知的测试集群854b，该测试集群854b包括被指示为具有DUT(“DUT 858d、DUT 858e”和“DUT 858f”)的“TG 856c”的测试组856c，并且包括被指示为包括DUT(“DUT 858g、DUT 858h、DUT 858i”和“DUT 858”)的“TG 856d”的测试组856d。根据RegisterDUTs消息1034中的该信息，在ECCCD 870处执行的TISS 160和分类软件740可以确定：测试设施850具有两个测试集群–测试集群“TC 854a”和测试集群“TC 854b”，该测试集群“TC 854a”具有两个测试组，该两个测试组分别具有一个和两个DUT，该测试集群“TC854b”具有两个测试组，该两个测试组分别具有三个和四个DUT。

在ECCCD 870处执行的TISS 160和分类软件740可以使用由RegisterDUTs消息1030、1032和1034提供的信息来做出有关测试套件872的测试的分类决定。在其它场景中，可以通过使用除了注册消息之外的其它技术来在各个测试设施处向在ECCCD 870处执行的TISS 160和分类软件740提供与分类相关的信息。

场景800继续，测试设施810、830和850分别开始执行测试套件872中的测试–在场景800期间，排程测试套件872中的测试1至18以便执行。如在图10中的框1040、1042和1044中指示的，所有DUT在相应的测试设施810、830和850处通过了测试1至5中的所有测试。有关测试6，框1050指示：在测试设施810处，DUT 818a和DUT 818c都通过了测试6，但是DUT 818b未通过测试6。框1052指示：在测试设施830处的所有DUT都通过了测试6。框1054指示：在测试设施850处的所有DUT都通过了测试6。

在确定DUT 818未通过测试6之后，测试设施810(例如，通过使用主机计算机820)发送FailingTR消息1056以向ECCCD 870指示：在测试设施810处，“DUT 818b”未通过“测试6”。在主机计算机820处执行的TISS 160的分类软件740确定DUT 818b未通过测试6之后，在主机计算机820处执行的分类软件740基于分类层级920和分类标准940确定针对失败的测试6的公共失败源是DUT误差源928；从而针对失败的测试6暗示DUT 818b–DUT 818b在测试组816中，该测试组816具有33％的未通过测试6的DUT，这少于TriagePercent＝51％。因此，基于分类标准940，针对失败的测试6，不暗示测试组816(该测试组816与分类层级920中的实施方式误差源926相关)，因此，针对未通过测试6的DUT 818b，暗示DUT误差源928。

由于测试6只与其本身相关(因为没有其它测试依赖于测试6)，因此，仅通过在主机计算机820上执行的分类软件740针对DUT 818b对测试6进行分类–在该场景中，省略测试6。然后，测试设施810将TriageRpt消息1058发送至ECCCD 870以指示：已经针对“DUT 818b”将测试套件872中的“测试6”分类为由FailingTR消息1056指示的失败的测试“测试6”的“相关测试”。在其它场景中，可以组合FailingTR消息1056和TriageRpt消息1058中的信息以指示失败的测试结果和分类测试结果。

如在图11中指示的，场景800继续，每个测试设施810、830和850分别执行测试7至9。如在框1110和1114中指示的，所有DUT在相应的测试设施810和850处通过了测试7至9中的所有测试。然而，框1112指示：在测试设施830处，DUT 838a未通过测试7。作为响应，测试设施830(例如，通过使用主机计算机840)发送FailingTR消息1116以向ECCCD 870指示：在测试设施830处，“DUT 838a”未通过“测试7”。

在主机计算机840处执行的TISS 160的分类软件740确定DUT838a未通过测试7之后，分类软件740基于分类层级920和分类标准940确定针对失败的测试7的公共失败源是DUT误差源928；从而针对失败的测试7暗示DUT 838a。具体地，分类软件740确定DUT 838a在测试组836a中，该测试组836a具有50％的未通过测试7的DUT，这少于TriagePercent＝51％。因此，基于分类标准940，针对失败的测试7，不暗示测试组836a和相关的实施方式误差源926，因此，针对未通过测试7的DUT 838a，暗示DUT误差源928。测试7与测试7、测试8和测试9相关，因为测试8和测试9依赖于测试7。然后，通过在主机计算机840处执行的分类软件740来针对DUT 838a对测试7至9进行分类–在该场景中，省略测试7至9。然后，测试设施830将TriageRpt消息1118发送至ECCCD 870以指示：已经针对“DUT 838a”将测试套件872中的“测试7至9”分类为由FailingTR消息1116指示的失败的测试“测试7”的“相关测试”。

通过对在DUT 838a上的测试7至9进行分类和省略该测试7至9，还已经通过分类软件740针对DUT 838a对测试1至18的执行进行了重新排序。即，在对测试7至9进行分类之前，测试10将已经是由DUT 838a执行的第10个测试。然而，由于DUT 838a将不执行测试8和测试9，因此，测试10将是由DUT 838a执行的第8个测试。在其它场景中，分类软件740可以在分类期间明确地对测试进行重新排序；例如，重新排程未执行的测试8和测试9以供DUT 838a在第一遍通过测试1至18之后执行。

如在框1120中指示的，DUT 838b和DUT 838c未通过测试8。作为响应，测试设施830发送FailingTR消息1122以向ECCCD 870指示：在测试设施830处，“DUT 838b”和“DUT 838c”未通过“测试8”。测试8与测试8和测试9相关，因为测试9依赖于测试8。在主机计算机840处执行的TISS 160的分类软件740确定DUT 838b和DUT 838c未通过测试8之后，当DUT已经未通过测试8或者已经通过测试8对其进行了分类并且因此，可以被认为已经失败时，分类软件740确定测试组836a中的失败的DUT的数量为100％，这超过了TriagePercent(51％)。然后，分类软件740可以确定测试集群834中针对测试8的失败DUT的数量(75％)超过了TriagePercent，因此，针对测试集群834中的所有DUT对测试8和测试9进行分类，从而指示出针对测试8的公共误差源是设计误差源924。然后，测试设施830将TriageRpt消息1124发送至ECCCD 870以指示：已经针对测试集群“834”对测试套件872中的“测试8至9”进行了分类，因为“失败的设计”针对这两个测试。

场景800继续，测试设施810、830和850分别执行测试10至13。如在框1130和1132中指示的，所有DUT在相应的测试设施810和830处通过了测试10至13中的所有测试。然而，框1134指示：在测试设施850处，DUT 858a和DUT 858j未通过测试10。作为响应，测试设施850(例如，通过使用主机计算机860)发送FailingTR消息1136以向ECCCD 870指示：在测试设施850处，“DUT 858a和DUT 858j”未通过“测试10”。

在主机计算机860处执行的TISS 160的分类软件740确定DUT 858a和DUT 858j未通过测试10之后，分类软件740基于分类层级920和分类标准940确定针对DUT 858a进行的测试10的公共失败源是与测试组856a对应的实施方式误差源926，因为测试组856a中的100％的DUT未通过测试10，这超过了TriagePercent(51％)。分类软件740还基于分类层级920和分类标准940确定针对DUT 858j进行的测试10的公共失败源是与DUT 858j对应的DUT误差源928。分类软件740针对未通过测试10的DUT 858j未暗示实施方式误差源926，因为测试组856d中的25％的DUT未通过测试10，这少于TriagePercent(51％)。测试10与测试10、测试11、测试12和测试13相关，因为测试11至13依赖于测试10。然后，通过在主机计算机860处执行的分类软件740针对测试组856a和DUT 858j对测试10至13进行分类–在该场景中，省略测试10至13。然后，测试设施830将TriageRpt消息1138发送至ECCCD 870以指示：由于测试组856a的“失败的实施方式”而已经针对“TG 854a”/测试组856a对测试套件872中的“测试10至13”进行了分类，以及已经针对“DUT 858j”将“测试10至13”分类为由FailingTR消息1136指示的失败的测试“测试10”的“相关测试”。

如通过图12中的框1210示出的，场景800继续，测试设施850的DUT 858b和DUT858c未通过测试11。作为响应，测试设施850发送FailingTR消息1212以向ECCCD 870指示：在测试设施850处，“DUT 858b和DUT 858c”未通过“测试11”。

在主机计算机860处执行的TISS 160的分类软件740确定DUT 858b和DUT 858c未通过测试11之后，分类软件740基于分类层级920和分类标准940确定针对DUT 858b和DUT858c进行的测试11的公共失败源是与测试集群854a对应的设计误差源924，因为测试集群854a中的100％的DUT未通过测试11或者对测试11进行了分类，这超过了TriagePercent(51％)。测试11与测试11、测试12和测试13相关，因为测试12和测试13依赖于测试11。然后，通过在主机计算机860处执行的分类软件740针对测试集群854a对测试11至13进行分类–在该场景中，省略测试11至13。然后，测试设施850将TriageRpt消息1214发送至ECCCD 870以指示：由于测试集群854a的“失败的设计”而已经针对“TG 854a”/测试集群854a对测试套件872中的“测试11至13”进行了分类。

如通过图12中的框1220示出的，场景800继续，针对DUT 858d和DUT 858g未通过测试12。作为响应，测试设施850发送FailingTR消息1222以向ECCCD 870指示：在测试设施850处，“DUT 858d和DUT 858g”未通过“测试12”。

在主机计算机860处执行的TISS 160的分类软件740确定DUT 858d和DUT 858g未通过测试12之后，分类软件740基于分类层级920和分类标准940确定针对由DUT 858d和DUT858g中的每一个执行的测试12的公共失败源是DUT误差源928。对于DUT 854d，测试组856c中的DUT的失败百分比是33％，这小于TriagePercent(51％)，所以，不将测试组856c暗示为公共误差源。对于DUT 854g，测试组856d中的DUT的失败百分比是25％，这小于TriagePercent(51％)，所以，不将测试组856d暗示为公共误差源。测试12与测试12和测试13相关，因为测试13依赖于测试12。然后，通过在主机计算机860处执行的分类软件740针对DUT 858d和DUT 858g两者对测试12和测试13进行分类–在该场景中，省略测试12和测试13。然后，测试设施850将TriageRpt消息1224发送至ECCCD 870以指示：已经针对“DUT 858d”和“DUT 858f”中的每一个对测试套件872中的“测试12至13”进行了分类作为在FailingTR消息1222中报告的失败的测试12的“相关测试”。

如通过图12中的框1230示出的，场景800继续，DUT 858e、DUT 858f、DUT 858h和DUT 858i通过了测试13，在测试设施850处，它们是针对测试13的未分类的DUT。

图12示出了：如通过框1240指示的，测试设施810确定在测试14处暂停测试套件872中的测试，而测试设施830和850都继续测试套件872中的测试。框1242指示在测试设施830处的所有DUT都通过了测试14。框1244指示在测试设施830处的DUT 858e、DUT 858f、DUT858h和DUT 858i未通过测试14。作为响应，测试设施850发送FailingTR消息1246以向ECCCD870指示：在测试设施850处，“DUT 858e、DUT 858f、DUT 858h”和DUT“858i”未通过“测试14”。

在主机计算机860处执行的TISS 160的分类软件740确定DUT 858e、DUT 858f和DUT 858h未通过测试14之后，分类软件740基于分类层级920和分类标准940确定针对DUT858e和DUT 858f进行的测试14的公共失败源是实施方式误差源926，以及针对DUT 858h进行的测试14的公共失败源是DUT误差源928。

对于在测试组856c中的DUT 858e和DUT 858f，测试组856c中的DUT的失败百分比为66％，这超过了TriagePercent(51％)，所以，将测试组856c暗示为公共误差源。向上移动分类层级，测试集群854b中的DUT的失败百分比为大约43％，这小于TriagePercent，并且测试集群854b中的测试组的失败百分比为50％，这也小于TriagePercent；因此，针对失败的测试14未暗示设计误差源924。对于在测试组856c中的DUT 858h，测试组856d中的DUT的失败百分比为25％，这小于TriagePercent(51％)，所以，不将测试组856d暗示为公共误差源。测试14与测试14、测试15、测试16和测试17相关，因为测试15、测试16和测试17依赖于测试14。然后，通过在主机计算机860处执行的分类软件740针对测试组856c和DUT 858h两者对测试14至17进行分类–在该场景中，省略测试14至17。然后，测试设施850将TriageRpt消息1248发送至ECCCD 870以指示：由于“失败的实施方式”而已经针对测试组“856c”对测试套件872中的“测试14至17”进行了分类，并且已经针对“DUT 858h”对测试套件872中的“测试14至17”进行了分类作为在FailingTR消息1246中报告的失败的测试14的“相关测试”。

场景800继续，在测试设施830和850处执行测试15。图13中的框1310示出了在测试设施830处的DUT 838b、DUT 838c、DUT 838d未通过测试15。作为响应，测试设施830发送FailingTR消息1314以向ECCCD 870指示：在测试设施830处，“DUT 838b、DUT 838c”和DUT“838d”未通过“测试15”。

在主机计算机840处执行的TISS 160的分类软件740确定DUT 838b、DUT 838c和DUT 858d未通过测试15之后，分类软件740基于分类层级920和分类标准940确定针对DUT838b、DUT 838c和DUT 838d的测试14的公共失败源是设计误差源924。分类软件740可以确定：对于包括DUT 838c和DUT 838d的测试组836b，测试组中的100％的DUT已经失败，这超过了TriagePercent(51％)。然后，分类软件740可以确定：对于测试集群834，测试集群中的75％的DUT已经失败，这超过了TriagePercent(51％)。然后，分类软件740可以将测试集群834暗示为公共误差源，其与设计误差源924对应。然后，通过在主机计算机840处执行的分类软件740针对测试集群834对测试15至17进行分类–在该场景中，省略测试15至17。然后，测试设施830将TriageRpt消息1316发送至ECCCD 870以指示：由于“失败的设计”而已经针对测试集群“834”对测试套件872中的“测试15至17”进行了分类。

框1312示出了在测试设施850处的DUT 858a、DUT 858b、DUT 858c、DUT 858g、DUT858i未通过测试15。作为响应，测试设施850发送FailingTR消息1320以向ECCCD 870指示：在测试设施850处，“DUT 858a、DUT 858b、DUT 858c、DUT 858g”和“DUT 858i”未通过“测试15。

在主机计算机860处执行的TISS 160的分类软件740确定DUT 858a、DUT 858b、DUT858c、DUT 858g和DUT 858i未通过测试15之后，分类软件740基于分类层级920和分类标准940确定针对DUT 858a、DUT 858b和DUT 858c的测试15的公共失败源是设计误差源924，以及针对DUT 858g和DUT 858i的测试15的公共失败源是设计误差源924。

对于在测试组856a和856b中的DUT 858a、DUT 858b和DUT 858c，两个测试组856a和856b中的DUT的失败百分比为100％，这大于TriagePercent(51％)，所以，将这两个测试组856a和856b暗示为公共误差源。向上移动分类层级，测试集群854a中的DUT的失败百分比为100％，这大于TriagePercent，这将测试集群854a暗示为公共误差源。对于在测试组856d中的DUT 858g和DUT 858i，测试组856d中的DUT的失败百分比为75％，这超过了TriagePercent。向上移动分类层级，测试集群854a中的DUT的失败和分类百分比为大约86％，这大于TriagePercent，这将测试集群854b暗示为公共误差源。测试15与测试15、测试16和测试17相关，因为测试16和测试17依赖于测试15。然后，通过在主机计算机860处执行的分类软件740针对测试集群854a和854两者对测试15至17进行分类–在该场景中，省略测试15至17。然后，测试设施850将TriageRpt消息1332发送至ECCCD870以指示：由于“(多个)失败的设计”而已经针对测试集群“854a”对测试套件872中的“测试15至17”进行了分类。

响应于接收到TriageRpt消息1316和1322，在ECCCD 870处执行的分类软件740可以确定注册了四个测试集群814、834、854a和854b以执行测试套件854，以及至少已经针对三个测试集群-834、854a和854b对测试15至17进行了分类。同样，针对测试15报告给ECCCD870的、生态系统中的失败的或者分类的测试集群的百分比为75％，，这大于TriagePercent(51％)，如在框1330中指示。同样，针对失败的测试15暗示与装置无关的软件/测试套件误差源922。针对与装置无关的软件/测试套件误差源922的分类标准940指示：分类涉及针对在所有测试设施处的所有测试集群对与测试T父相关的所有测试进行分类。

测试15与测试14至17父有关。然后，在ECCCD 870处执行的分类软件740确定在测试集群814、834、854a和854b处对测试14至17进行分类作为分类的测试15的父相关测试。ECCCD 870由于“失败的测试”而将分类消息1336发送至测试设施810以针对测试集群“814”对“测试14至17”进行分类。通过将对测试14至17进行分类的分类消息1336发送至测试设施810和主机计算机820，ECCCD 870和主机计算机820指导DUT 818a、DUT 818b、DUT 818c中的每一个对测试14的执行进行重新排序，从作为在测试在通过框1240指示的测试暂停之后恢复时执行的下一个测试成为在某一稍后的时间执行的测试。相反，将省略测试14至17，因此，将测试18排程为如由主机计算机820指导的那样由DUT 818a、DUT 818b、DUT 818c执行的下一个测试。而且，如上面指示的，基于在测试设施830和850处的失败的测试的结果，分类消息1336被发送至测试设施810。因此，基于共享至少一个公共软件设计(例如，涉及对与装置无关的软件(诸如，经由软件图像876提供的)的使用的软件设计)的DUT的失败的测试，分类消息1336使得对由DUT 818a、DUT 818b、DUT 818c进行的测试14至17的执行进行重新排序，但是其中，在测试设施810处的DUT 818a、DUT 818b、DUT 818c中的任何DUT都未发生失败的测试。在其它场景中，DUT 818a、DUT 818b、DUT 818c可以与在其它测试设施处的DUT共享公共硬件设计、实施方式、组件和/或其它软件设计；例如，测试设施830和/或850。

ECCCD 870还由于“失败的测试”而将分类消息1334发送至测试设施830以针对测试集群“834”对“测试14至17”进行分类，并且由于“失败的测试”而将分类消息1332发送至测试设施850以针对测试集群“854a”和“854b”对“测试14至17”进行分类。

在一些场景中，由在ECCCD 870处执行的分类软件740发送的分类消息(诸如，消息1332、1334或者1336)可以被在接收到该分类消息的测试设施处执行的TISS 160视为对由ECCCD 870进行分类的任何测试的豁免。在这些场景中的特定场景中，从对测试T_Triage1...T_TriageN进行分类的ECCCD 870发送的分类消息可以包括针对测试T_Triage1...T_TriageN的明确豁免。

场景800继续，测试设施810恢复测试18的测试，并且也在测试设施830和850处执行测试18。框1340指示：针对在测试设施810处的所有DUT，通过了测试18。并且，框1342和1344指示：针对在相应的测试设施830和840处的所有DUT，通过了测试18。

在所有测试设施810、830、850处完成测试18之后，已经在所有这三个测试设施处完成了第一遍通过测试1至18。然后，测试设施810、830、850中的每一个将报告测试套件872中的测试1至18的执行结果的测试报告发送至ECCCD 870。

图14示出了测试设施810将PassingTR消息1410发送至ECCCD 870以报告在第一遍期间，测试套件872中的哪些测试已通过并且稍后未对其进行分类。PassingTR消息1410指示在测试设施810处：“DUT 818a”通过了测试“1至13”和“18”，这指示针对该DUT，失败的测试14至17或者对测试14至17进行了分类；“DUT 818b”通过了测试“1至3”和“18”，以及“DUT818c”通过了测试“1至5、7至13”和“18”。

测试设施830将PassingTR消息1412发送至ECCCD 870以报告在第一遍期间，测试套件872中的哪些测试已通过并且稍后未对其进行分类。PassingTR消息1412指示在测试设施830处：“DUT 838a”通过了测试“1至6、10至13”和“18”；“DUT 838b”通过了测试“1至7、10至13”和“18”；“DUT 838b”通过了测试“1至7、10至13”和“18”；以及“DUT 838d”通过了测试“1至7、10至13”和“18”。

测试设施850将PassingTR消息1414发送至ECCCD 870以报告在第一遍期间，测试套件872中的哪些测试已通过并且稍后未对其进行分类。PassingTR消息1414指示在测试设施850处：“DUT 858a”通过了测试“1至9”和“18”；“DUT 858b”通过了测试“1至10”和“18”；“DUT 858c”通过了测试“1至10”和“18”；“DUT 858d”通过了测试“1至11”和“18”；“DUT858e”通过了测试“1至13”和“18”；“DUT 858f”通过了测试“1至13”和“18”；“DUT 858g”通过了测试“1至11”和“18”；“DUT 858h”通过了测试“1至13”和“18”；“DUT 858i”通过了测试“1至13”和“18”；以及“DUT 858j”通过了测试“1至9”和“18”。

如通过框1420指示的，场景800继续，ECCCD 870发行测试套件872的更新版本，其具有对测试14至17的修正。然后，测试设施850通过使用消息1422来获得测试套件872的更新版本，并且安装已更新的测试套件872，如在框1424中指示的。随后，测试设施850在所有DUT上执行已更新的测试套件872中的测试14至17，并且所有DUT通过测试14至17中的所有测试，如在框1430中指示的。测试设施850将PassingTR消息1432发送至ECCCD 870以报告在对测试14至17进行重新测试期间，测试套件872中的哪些测试已通过并且稍后未对其进行分类。PassingTR消息1432指示：在测试设施850处，DUT 854a至DUT 854j中的每一个通过了测试14至17中的所有测试。

场景800继续，测试设施810通过使用消息1440来获得测试套件872的更新版本，并且安装已更新的测试套件872，如在框1424中指示的。转向图15，如在框1510中指示的，测试设施850随后在所有DUT上执行已更新的测试套件872中的测试1至18，并且除了DUT 818a未通过测试6之外，所有DUT通过测试1至18中的所有测试。

在确定DUT 818b未通过测试6之后，测试设施810(发送FailingTR消息1512以向ECCCD 870指示：在测试设施810处，“DUT 818b”未通过“测试6”。在主机计算机820处执行的TISS 160的分类软件740确定DUT 818b未通过测试6之后，在主机计算机820处执行的分类软件740基于分类层级920和分类标准940确定针对失败的测试6的公共失败源是DUT误差源928。DUT 818b在测试组816中，该测试组816具有33％的未通过测试6的DUT，这少于TriagePercent＝51％。因此，基于分类标准940，针对未通过测试6的DUT 818b，暗示DUT误差源928。

由于测试6只与其本身相关(因为没有其它测试依赖于测试6)，因此，仅通过在主机计算机820上执行的分类软件740针对DUT 818b对测试6进行分类–在该场景中，省略测试6。然后，测试设施810将TriageRpt消息1514发送至ECCCD 870以指示：已经针对“DUT 818b”将测试套件872中的“测试6”分类为由FailingTR消息1512指示的失败的测试“测试6”的“相关测试”。

在通过使用已更新的测试套件872执行测试1至18之后，测试设施810发送PassingTR消息1516，该PassingTR消息1516指示在测试设施810处：“DUT 818a”通过了测试“1至18”；“DUT 818b”通过了测试“1至5”和“7至18”，以及“DUT 818c”通过了测试“1至18”。

场景800继续，在测试设施810处更新DUT 818b。然后，如通过框1520指示的，DUT818b重新执行测试6，并且通过了测试6。然后，测试设施810将PassingTR消息1522发送至ECCCD 870以指示：“DUT 818b”已经通过“测试6”。当在测试设施810处的所有DUT已经通过测试套件872中的所有测试1至18时，测试设施810将RequestApproval消息1530发送至ECCCD 870以针对通过“测试套件872”测试的功能性，请求批准在测试设施810处的测试集群“814”中测试的DUT的设计和实施方式。

响应于RequestApproval消息1530，ECCCD 870检查由测试设施810提供的注册消息和测试报告，并且确定测试设施810的测试集群814中的所有DUT已经通过测试套件872中的所有测试。因此，ECCCCD 870将批准消息1532发送至测试设施810，该批准消息1532针对通过“测试套件872”测试的功能性批准测试集群“814”中的DUT。在测试设施810接收到批准消息1532之后，可以完成场景800。

在其它场景中，ECCCD 870可以基于通过测试报告来发送批准消息，而无需通过测试和/或与装置相关的实体来请求；例如，测试设施810将不必发送RequestApproval消息1530来获得批准消息1532。

甚至在其它场景中，可以将系统802中的一些DUT指定为具有参考硬件和/或软件的参考DUT。然后，如果参考DUT未通过测试套件872中的测试，则在参考DUT上未通过的测试也将在非参考DUT上未通过的逻辑下，针对分类和/豁免，在非参考DUT(例如，不具有参考硬件和/或软件的一个或者多个DUT)上的测试会有资格(但是并非反之亦然)。在这些其它场景中的一些场景中，当在参考DUT上未通过一些测试(诸如，被设计为验证先前发行的和/或相对较旧的功能性的回归测试)时，对于非参考DUT，针对分类和豁免，这些测试立即有资格；而如果参考DUT未通过其它测试，则对于非参考DUT，针对分类和豁免，其它测试(诸如，针对先前未发行的和/或相对较新的功能性专门设计的测试)不会有资格，因为参考DUT不会具有先前未发行的和/或相对较新的功能性。

示例数据网络

图16描绘了根据至少一些示例实施例的分布式计算架构1600，该分布式计算架构1600具有服务器装置1608、1610、测试设施1612、1614和ECCCD 1616，它们配置为经由网络1606来与可编程装置1604a、1604b、1604c、1604d、1604e和1604f通信。网络1606可以与LAN、广域网(WAN)、公司内联网、公共互联网或者配置为提供联网计算装置之间的通信路径的任何其它类型的网络对应。网络1606还可以与一个或者多个LAN、WAN、公司内联网和/或公共互联网的组合对应。具体地，网络1606可以执行网络430和/或880的一个或者多个功能；例如，至少在测试设施1612、1614与ECCCD 1616之间能够实现通信。

虽然图16示出了六个可编程装置，但是分布式计算架构1600可以服务更多的或者更少的可编程装置。此外，可编程装置1604a、1604b、1604c、1604d、1604e和1604f(或者任何其它可编程装置)可以是任何种类的计算装置，诸如，普通的膝上型计算机、台式计算机、可穿戴计算装置、移动计算装置、头戴式装置、网络终端、无线通信装置(例如，智能电话或者手机)等。在一些实施例中，诸如利用可编程装置1604a、1604b、1604c和1604f指示的，可编程装置可以直接连接至网络1606。在其它实施例中，诸如利用可编程装置1604d和1604e指示的，可编程装置可以经由相关联的计算装置(诸如，可编程装置1604c)间接地连接至网络1606。在该示例中，可编程装置1604c可以充当用于在可编程装置1604d和1604e与网络1606之间传递电子通信的相关联的计算装置。在图16中未示出的又一些实施例中，可编程装置可以直接以及间接地连接至网络1606。

服务器装置1608、1610可以配置为执行如可编程装置1604a至1604f请求的一种或者多种服务。例如，服务器装置1608和/或1610可以向可编程装置1604a至1604f提供内容。该内容可以包括但不限于：网页、超文本、脚本、二进制数据(诸如，编译的软件)、图像、音频和/或视频。内容可以包括压缩的和/或未压缩的内容。内容可以是加密的和/或未加密的。其它类型的内容也是可能的。

作为另一示例，服务器装置1608和/或1610可以向可编程装置1604a至1604f提供对软件的访问以便进行数据库利用、搜索利用、计算利用、图形利用、音频利用、视频利用、万维网/互联网利用和/或其它功能。服务器装置的许多其它示例也是可能的。

计算装置架构

图17A是根据至少一些示例实施例的计算装置1700(例如，系统)的框图。具体地，在图17中示出的计算装置1700可以配置为执行与以下中的一个或者多个相关的一个或者多个功能：系统100、计算装置110、被测装置110a、110b、110c、110d、110e、110f、测试套件150、TISS 160、测试设施300、810、830、850、1612、1614目标系统310、主机计算装置340、测试消息传递350、测试系统400、测试实体计算装置410、云计算装置420、网络/防火墙430、场景500、550、600、800、系统700、测试报告710、720、722、730、分类软件740、分类算法750。ECCCD 870、1616、网络800、网络1606、服务器装置1608、1610、可编程装置1604a、1604b、1604c、1604d、1604e、1604f和方法1800。

计算装置(诸如，计算装置800)可以是或者包括自动执行计算的任何机器，并且示例包括但不限于：台式计算机、膝上型计算机、平板、移动电话、智能电话、手表、智能手表、耳机和HMD(诸如，智能眼镜)。移动计算装置是包括移动电源(诸如，电池)和/或配置为易于传递的移动计算装置–示例包括但不限于：膝上型计算机、平板、移动电话、智能电话、手表、智能手表、耳机、车辆信息娱乐系统和HMD。固定计算装置是指不是移动计算装置的计算装置–示例包括但不限于：台式计算机、机架式计算机/服务器、大型计算机、家庭娱乐系统、智能恒温器和家用计算机。可穿戴计算装置是配置为易于在人或者动物上传递或者承载在人或者动物上和/或易于由人或者动物传递或者携带的计算装置–示例包括但不限于：移动电话、智能电话、手表、智能手表、耳机和HMD。

计算装置1700可以包括用户界面模块1701、网络通信接口模块1702、一个或者多个处理器1703以及数据存储1704，所有这些可以经由系统总线、网络或者其它连接机构1705链接在一起。

用户界面模块1701可以可操作以向外部的用户输入/输出装置发送数据和/或从外部的用户输入/输出装置接收数据。例如，用户界面模块1701可以配置为向和/或从用户输入装置(诸如，键盘、小键盘、触摸屏、计算机鼠标、轨迹球、操纵杆、摄像头、语音识别模块和/或其它相似的装置)发送和/或接收数据。用户界面模块1701还可以配置为向用户显示装置(诸如，一个或者多个阴极射线管(CRT)、液晶显示器(LCD)、发光二极管(LED)、使用数字光处理(DLP)技术的显示器、打印机、灯泡和/或其它相似的装置)提供输出。用户界面模块1701还可以配置为生成(多个)可听输出，诸如，扬声器、扬声器插孔、音频输出端口、音频输出装置、听筒和/或其它相似的装置。

网络通信接口模块1702可以包括可配置为经由网络(诸如，在图7中示出的网络706)来通信的一个或者多个无线接口1707和/或一个或者多个有线接口1708。无线接口1707可以包括一个或者多个短距离和/或广域无线发送器、接收器和/或收发器，诸如，Bluetooth^TM收发器、ZigBee^TM收发器、IEEE 802.11/Wi-Fi^TM收发器、WiMAX收发器、蜂窝和/或可配置为经由无线网络来通信的其它相似类型的无线收发器。有线接口1708可以包括一个或者多个有线发送器、接收器和/或收发器，诸如，以太网收发器、通用串行总线(USB)收发器或者可配置为经由双绞线、同轴电缆、光纤链路或者与有线网络的相似物理连接来通信的相似收发器。

在一些实施例中，网络通信接口模块1702可以配置为提供可靠的、安全的和/或已认证的通信。对于本文中描述的每种通信，可以提供用于确保可靠通信(即，保证的消息传递)的信息，例如，作为消息报头和/或脚注的一部分(例如，包/消息排序信息、(多个)封装报头和/或(多个)脚注、大小/时间信息以及传输验证信息(诸如，CRC和/或奇偶校验值)。可以使通信是安全的，例如，通过使用一种或者多种密码协议和/或算法(诸如但不限于：DES、AES、RSA、Diffie-Hellman和/或DSA)来进行编码或者加密和/或解密和解码。也可以使用其它密码协议和/或算法，或者除了本文中列出的那些密码协议和/或算法之外，还可以使用其它密码协议和/或算法以保护并且然后恢复通信。

处理器1703可以包括一个或者多个通用处理器和/或一个或者多个专用处理器(例如，中央处理单元、数字信号处理器、图形处理单元、专用集成电路等)。处理器1703可以配置为执行包括在数据存储1704中的计算机可读程序指令1706和/或如本文描述的其它指令。

数据存储1704可以包括可以由至少一个处理器1703读取和/或访问的一种或者多种计算机可读存储介质。该一种或者多种计算机可读存储介质可以包括易失性和/或非易失性存储组件，诸如，光学的、磁性的、有机的或者其它存储器或者磁盘存储装置，该易失性和/或非易失性存储组件可以整体地或者部分地与至少一个处理器1703集成。在一些实施例中，可以通过使用单个物理装置(例如，一个光学物理装置、磁物理装置、有机物理装置或者其它存储器或者磁盘存储单元)来实施数据存储1704，而在其它实施例中，可以通过使用两个或者更多个物理装置来实施数据存储1704。

数据存储1704可以包括计算机可读程序指令1706，并且在一些情况下，可以包括附加数据。在一些实施例中，数据存储1704可以另外包括执行本文描述的场景、方法和技术的至少一部分和/或本文描述的装置和网络的功能性的至少一部分所需的存储。计算机可读程序指令1706可以包括至少用于与装置无关的软件110、与装置有关的软件120、TISS160和/或任何其它本文描述的软件的指令。

在一些实施例中，计算装置1700可以包括一个或者多个传感器。(多个)传感器可以配置为测量在计算装置1700的环境中的状况并且提供有关该环境的数据。该数据可以包括但不限于：有关计算装置1700的位置数据、有关计算装置1700的周转速度(包括速度和/或方向的周转速度)数据、有关计算装置1700的加速度数据以及有关计算装置1700的环境的其它数据。一个或者多个传感器可以包括但不限于：(多个)全球定位系统(GPS)传感器、(多个)位置传感器、(多个)陀螺仪、(多个)加速度计、(多个)磁力计、(多个)摄像头、(多个)光传感器、(多个)红外线传感器以及(多个)麦克风。传感器的其它示例也是可能的。

基于云的服务器

图17B描绘了根据至少一些示例实施例的布置为基于云的服务器系统的计算集群1709a、1709b、1709c的网络1606。计算集群1709a、1709b和/或1709c可以代表一个或者多个计算装置，该设备可以产生和/或利用一个或者多个使用与图像生成相关的本文所述技术写入的存储器，引导和/或其他图像。例如算法A1。具体地，计算集群1709a、1709b和/或1709c被配置为执行与以下中的一个或者多个相关的一个或者多个功能：系统100、计算装置110、被测装置110a、110b、110c、110d、110e、110f、测试套件150、TISS 160、测试设施300、810、830、850、1612、1614、目标系统310、主机计算装置340、测试消息传递350、测试系统400、测试实体计算装置410、云计算装置420、网络/防火墙430、场景500、550、600、800、系统700、测试报告710、720、722、730、分类软件740、分类算法750。ECCCD 870、1616、网络800、网络1606、服务器装置1608、1610、可编程装置1604a、1604b、1604c、1604d、1604e、1604f和方法1800。

测试设施1612、1614和/或ECCCD 1616的模块/组件中的一些或者全部模块/组件可以是基于云的装置，该基于云的装置存储基于云的应用和/或服务的程序逻辑和/或数据。在一些实施例中，测试设施1612、1614和/或ECCCD 1616可以在驻留在单个计算中心中的单个计算装置上。在其它实施例中，测试设施1612、1614和/或ECCCD 1616可以包括单个计算中心中的多个计算装置，或者甚至多个计算中心中的多个计算装置，该多个计算中心位于不同的地理位置。例如，图16描绘了驻留在不同的物理位置中的测试设施1612、1614和ECCCD 1616中的每一个。

在一些实施例中，与测试设施1612、1614和/或ECCCD 1616相关联的软件和数据可以被编码为存储在非暂时性有形计算机可读介质(或计算机可读存储介质)中并且可由可编程装置1604a至1604f或者其它计算装置中的一个或者多个访问的计算机可读信息。在一些实施例中，与测试设施1612、1614和/或ECCCD 1616相关联的数据可以存储在单个磁盘驱动器、闪存驱动器或者其它有形存储介质上，或者可以实施在多个磁盘驱动器、闪存驱动器或者位于一个或者多个不同的地理位置处的其它有形存储介质上。

在图17B中，测试设施1612、1614和/或ECCCD 1616的功能可以分布在三个计算集群1709a、1709b和1709c之间。计算集群1709a可以包括通过本地集群网络1712a连接的一个或者多个计算装置1700a、集群存储阵列1710a和集群路由器1711a。同样，计算集群1709b可以包括通过本地集群网络1712b连接的一个或者多个计算装置1700b、集群存储阵列1710b和集群路由器1711b。同样，计算集群1709c可以包括通过本地集群网络1712c连接的一个或者多个计算装置1700c、集群存储阵列1710c和集群路由器1711c。

在一些实施例中，计算集群1709a、1709b和1709c中的每一个可以具有相等数量的计算装置、相等数量的集群存储阵列和相等数量的集群路由器。然而，在其它实施例中，每个计算集群可以具有不同数量的计算装置、不同数量的集群存储阵列和不同数量的集群路由器。每个计算集群中的计算装置、集群存储阵列和集群路由器的数量可以取决于分配给每个计算集群的一个或者多个计算任务。

例如，在计算集群1709a中，计算装置1700a可以配置为执行测试设施1612、1614和/或ECCCD 1616的各种计算任务。在一个实施例中，测试设施1612、1614和/或ECCCD 1616的各种功能性可以分布在计算装置1700a、1700b和1700c中的一个或者多个之间。可以与计算集群1709a中的计算装置1700a类似地配置计算集群1709b和1709c中的计算装置1700b和1700c。另一方面，在一些实施例中，计算装置1700a、1700b和1700c可以配置为执行不同的功能。

在一些实施例中，与测试设施1612、1614和/或ECCCD 1616相关联的计算任务和存储数据可以至少部分地基于以下因素而分布在计算装置1700a、1700b和1700c上：服务器装置708和/或710的一些或者全部组件/模块的存储和/或处理要求、测试设施1612、1614和/或ECCCD 1616的存储和/或处理能力、在每个计算集群中的计算装置之间以及计算集群它们本身之间的网络链路的时延和/或可能影响整个系统架构的成本、速度、容错性、弹性、效率和/或其它设计目标的其它因素。

计算集群1709a、1709b和1709c的集群存储阵列1710a、1710b和1710c可以是包括磁盘阵列控制器的数据存储阵列，该磁盘阵列控制器配置为管理对硬盘驱动器组的读写访问。单独地或者与其相应的计算装置结合，磁盘阵列控制器也可以配置为管理存储在集群存储阵列中的数据的备份或者冗余副本以防止磁盘驱动器或者其它集群存储阵列发生故障和/或网络发生故障，这些故障阻止一个或者多个计算装置访问一个或者多个集群存储阵列。

与测试设施1612、1614和/或ECCCD 1616的功能可以分布在计算集群1709a、1709b和1709c中的计算装置1700a、1700b和1700c上的方式相似，针对这些组件的数据的各个有效部分和/或备份部分可以分布在集群存储阵列1710a、1710b和1710c上。例如，一些集群存储阵列可以配置为存储测试设施1612、1614和/或ECCCD 1616的一个或者多个模块/组件的数据，而其它集群存储阵列可以存储测试设施1612、1614和/或ECCCD 1616的其它模块/组件的数据。此外，一些集群存储阵列可以配置为存储被存储在其它集群存储阵列中的数据的备份版本。

计算集群1709a、1709b和1709c中的集群路由器1711a、1711b和1711c可以包括配置成为计算集群提供内部通信和外部通信的联网设备。例如，计算集群1709a中的集群路由器1711a可以包括一个或者多个互联网交换和路由装置，该一个或者多个互联网交换和路由装置配置为：(i)经由本地集群网络1712a来提供计算装置1700a与集群存储阵列1710a之间的局域网通信，并且(ii)经由与网络1606的广域网连接1713a来提供计算集群1709a与计算集群1709b和1709c之间的广域网通信。集群路由器1711b和1711c可以包括与集群路由器1711a相似的网络设备，并且集群路由器1711b和1711c可以对计算集群1709b和1709b执行集群路由器1711a对计算集群1709a执行的相似网络功能。

在一些实施例中，集群路由器1711a、1711b和1711c的配置可以至少部分地基于计算装置和集群存储阵列的数据通信要求、集群路由器1711a、1711b和1711c中的网络设备的数据通信能力、本地网络1712a、1712b、1712c的时延和吞吐量、广域网链路1713a、1713b和1713c的时延、吞吐量和成本和/或可能影响适度系统架构的成本、速度、容错性、弹性、效率和/或其它设计目标的其它因素。

示例操作方法

图18是图示了根据至少一些示例实施例的方法1800的流程图。方法1800可以由主机计算装置执行，诸如但不限于：诸如上面在图17A的上下文中讨论的一个或者多个计算装置1700。例如，计算装置1700的数据存储1704可以存储计算机可读指令1706，这些计算机可读指令1706在由计算装置1700的一个或者多个处理器1703执行时可以使计算装置1700至少执行方法1800的在本文中所描述的特征。

方法1800可以在框1810中开始，在该框1810中，提供主机计算装置。该主机计算装置可以执行测试基础架构系统软件，该测试基础架构系统软件用于通过使用具有待由多个DUT执行的多个测试的测试套件来测试多个DUT。诸如上面至少在图3和图7至图16的上下文中讨论的，多个DUT可以包括第一DUT和第二DUT，其中，第一DUT和第二DUT共享公共设计，以及其中，多个测试包括第一测试和第二测试。

在一些实施例中，诸如上面至少在图3和图7至图16的上下文中讨论的，多个测试可以包括用于测试包括与装置无关的软件部分的软件测试图像的一个或者多个测试。在这些实施例中的特定实施例中，诸如上面至少在图7至图16的上下文中讨论的，用于测试包括与装置无关的软件部分的软件测试图像的一个或者多个测试包括用于测试与软件测试图像相关联的API的一个或者多个测试。在这些实施例中的另一特定实施例中，多个DUT可以配置为执行包括测试图像和与装置有关的软件部分的软件图像；然后，方法1800可以进一步包括：诸如上面至少在图7至图16的上下文中讨论的，在第一地理位置处生成测试图像；以及在与第一地理位置不同的第二地理位置处生成包括与装置有关的软件部分的软件图像。在这些实施例中的又一特定实施例中，诸如上面至少在图7至图16的上下文中讨论的，在执行第一测试之前将测试套件从第一地理位置传送至第二地理位置。

甚至在其它实施例中，诸如上面至少在图7至图16的上下文中讨论的，公共设计可以包括公共硬件设计，其中，第一DUT可以包括公共硬件设计的第一实施方式，以及其中，第二DUT可以包括公共硬件设计的第二实施方式。在再一些实施例中，诸如上面至少在图7至图16的上下文中讨论的，公共设计包括公共软件设计。在这些实施例中的一些实施例中，诸如上面至少在图7至图16的上下文中讨论的，公共软件设计包括用于与装置有关的软件的公共设计和用于与装置有关的软件的公共设计中的一个或者多个。

在又一些实施例中，诸如上面讨论的，第一DUT可以包括参考硬件，并且第二DUT可以包括除了参考硬件之外的硬件。

在框1820中，诸如上面至少在图7至图16的上下文中讨论的，主机计算装置可以确定在至少第一DUT上在第二测试之前执行第一测试。在一些实施例中，多个DUT中的每个DUT可以利用公共硬件组件；然后，确定是否要在第二DUT上执行第一测试包括：诸如上面至少在图7的上下文中讨论的，从第一测试结果中选择第一失败的测试结果，这些第一失败的测试结果针对由第一DUT对第一测试的失败的执行；对第一失败的测试结果进行分析以确定公共硬件组件是否与第一失败的测试结果相关联；以及在确定公共硬件组件与第一失败的测试结果相关联之后，确定不在第二DUT上执行第一测试。在其它实施例中，诸如上面至少在图7至图16的上下文中讨论的，主机计算装置可以确定在至少第一DUT和第二DUT上在第二测试之前执行第一测试。

在框1830中，诸如上面至少在图7至图16的上下文中讨论的，主机计算装置可以接收针对由第一DUT执行的失败的第一测试的第一测试结果。

在框1840中，诸如上面至少在图7至图16的上下文中讨论的，主机计算装置可以基于第一测试结果并且基于第一DUT与第二DUT共享公共设计来确定在第二DUT上在第一测试之前执行第二测试。

在一些实施例中，诸如上面至少在图7至图16的上下文中讨论的，基于第一测试结果并且基于第一DUT与第二DUT共享公共设计来确定在第二DUT上在第一测试之前执行第二测试可以包括：基于与分类层级相关联的一个或者多个分类标准来确定在第二DUT上在第一测试之前执行第二测试。在其它实施例中，诸如上面至少在图9的上下文中讨论的，多个DUT与多个与装置相关的实体相关联；然后，确定在第二DUT上在第一测试之前执行第二测试可以包括：确定至少失败的第一测试在与至少阈值数量的多个与装置相关的实体相关联的一个或者多个DUT上未通过。在又一些实施例中，诸如上面至少在图9的上下文中讨论的，多个DUT与多个与装置相关的实体相关联；然后，确定在第二DUT上在第一测试之前执行第二测试可以包括：确定至少失败的第一测试在与至少阈值百分比的多个与装置相关的实体相关联的一个或者多个DUT上未通过。

在框1850中，诸如上面至少在图7至图16的上下文中讨论的，主机计算装置随后可以指示第二DUT在执行第一测试之前执行第二测试。

在一些实施例中，诸如上面至少在图7至图16的上下文中讨论的，方法1800可以进一步包括：生成测试基础架构系统的基于第二测试的执行的输出。在这些实施例中的特定实施例中，诸如上面至少在图7至图16的上下文中讨论的，测试基础架构系统的基于第二测试的执行的输出可以包括以下中的一个或者多个：在多个DUT中的至少一个DUT上通过第二测试的指示、在多个DUT中的至少一个DUT上未通过第二测试的指示、以及针对多个DUT中的至少一个DUT免除第二测试的指示。在这些实施例中的更多特定实施例中，诸如上面至少在图7至图16的上下文中讨论的，方法1800可以进一步包括：在测试基础架构系统处获得针对在第二DUT上执行第二测试的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否通过了第二测试；以及在确定第二DUT通过第二测试之后，生成在至少第二DUT上通过第二测试的指示。

在这些实施例中的其它实施例中，诸如上面至少在图7至图16的上下文中讨论的，方法1800可以进一步包括：在测试基础架构系统处获得针对在第二DUT上执行第二测试的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否未通过第二测试；以及在确定第二DUT未通过第二测试之后，生成在至少第二DUT上未通过第二测试的指示。在这些实施例中的又一些实施例中，诸如上面至少在图7的上下文中讨论的，多个DUT可以进一步包括第三DUT，并且方法1800可以进一步包括：在测试基础架构系统处获得针对在第二DUT上执行第二测试的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否未通过第二测试；以及在确定第二DUT未通过第二测试之后，生成针对至少第三DUT免除第二测试的指示。

甚至在其它实施例中，诸如上面至少在图7的上下文中讨论的，要执行的软件的系统图像与第一软件版本相关联；然后，方法1800可以进一步包括：通过另外在执行了等于或者超过第一软件版本的软件版本的一个或者多个DUT上执行第一测试来获得相关版本测试结果；对相关版本测试结果进行分析以确定在一个或者多个DUT上的第一测试是否成功；以及在确定在一个或者多个DUT上的第一测试成功之后，确定不在第二DUT上执行第一测试。

在又一些实施例中，诸如上面至少在图8至图16的上下文中讨论的，方法1800可以进一步包括：至少将第一测试结果与和生态系统协调员相关联的计算装置通信。在再一些实施例中，诸如上面至少在图4和图7的上下文中讨论的，多个测试可以包括对与至少第一DUT相关联的第一HAL的第一HAL测试；然后，方法1800可以进一步包括：确定是否要在第一DUT上执行第一HAL测试；以及在确定要在第一DUT上执行第一HAL测试之后，在第一DUT上执行第一HAL测试。在这些实施例中的一些实施例中，诸如上面至少在图4和图7的上下文中讨论的，第一HAL可以是多个HAL的一部分，并且在第一DUT上执行第一HAL测试可以包括：确定与多个HAL相关联的HAL实例名称列表；确定HAL实例名称列表中的一个或者多个组合，其中，一个或者多个组合中的每个组合包括多个HAL中的每个HAL的实例名称；确定是否对一个或者多个HAL实例名称的特定HAL实例名称组合执行HAL测试；以及在确定对特定HAL实例名称组合执行HAL测试之后，在第一DUT上执行第一HAL测试。

附加示例实施例

提供以下条款作为对本公开的进一步描述。

条款1-一种方法，其包括：提供执行测试基础架构系统软件的主机计算装置，该测试基础架构系统软件用于通过使用具有待由多个DUT执行的多个测试的测试套件来测试多个DUT，该多个DUT包括第一DUT和第二DUT，其中，第一DUT和第二DUT共享公共设计，以及其中，多个测试包括第一测试和第二测试；通过使用主机计算装置来确定在第二测试之前，在至少第一DUT上执行第一测试；在主机计算装置处接收针对由第一DUT执行的失败的第一测试的第一测试结果；基于第一测试结果并且基于第一DUT与第二DUT共享公共设计，确定在第一测试之前在第二DUT执行第二测试；以及主机计算装置随后指示第二DUT在执行第一测试之前执行第二测试。

条款2-根据条款1的方法，其进一步包括：生成测试基础架构系统的基于第二测试的执行的输出。

条款3-根据条款2的方法，其中，测试基础架构系统的基于第二测试的执行的输出包括以下中的一个或者多个：在多个DUT中的至少一个DUT上通过第二测试的指示、在多个DUT中的至少一个DUT上未通过第二测试的指示、以及针对多个DUT中的至少一个DUT免除第二测试的指示。

条款4-根据条款3的方法，其中，该方法进一步包括：在测试基础架构系统处获得针对第二测试在第二DUT上执行的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否通过第二测试；以及在确定第二DUT通过第二测试之后，生成在至少第二DUT上通过第二测试的指示。

条款5-根据条款3或者条款4的方法，其中，该方法进一步包括：在测试基础架构系统处获得针对第二测试在第二DUT上的执行的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否未通过第二测试；以及在确定第二DUT未通过第二测试之后，生成在至少第二DUT上未通过第二测试的指示。

条款6-根据条款3至5中任一项的方法，其中，多个DUT进一步包括第三DUT，以及其中，该方法进一步包括：在测试基础架构系统处获得针对第二测试在第二DUT上的执行的第二测试结果；在测试基础架构系统处基于第二测试结果来确定第二DUT是否未通过第二测试；以及在确定第二DUT未通过第二测试之后，生成至少针对第三DUT免除第二测试的指示。

条款7-根据条款1至6中任一项的方法，其中，多个测试包括用于测试包括与装置无关的软件部分的软件测试图像的一个或者多个测试。

条款8-根据条款7方法，其中，用于测试包括与装置无关的软件部分的软件测试图像的一个或者多个测试包括用于测试与软件测试图像相关联的API的一个或者多个测试。

条款9-根据条款7或者条款8的方法，其中，多个DUT被配置为执行包括测试图像和与装置有关的软件部分的软件图像，以及其中，该方法进一步包括：在第一地理位置处生成测试图像；以及在与第一地理位置不同的第二地理位置处生成包括与装置有关的软件部分的软件图像。

条款10-根据条款9的方法，其中，在执行第一测试之前将测试套件从第一地理位置传送至第二地理位置。

条款11-根据条款1至10中任一项的方法，其中，多个DUT中的每个DUT利用公共硬件组件，以及其中，确定是否要在第二DUT上执行第一测试包括：从第一测试结果中选择第一失败的测试结果，该第一失败的测试结果针对由第一DUT对所述第一测试的一次或者多次失败的执行；对第一失败的测试结果进行分析以确定公共硬件组件是否与第一失败的测试结果相关联；以及在确定公共硬件组件与第一失败的测试结果相关联之后，确定不在第二DUT上执行第一测试。

条款12-根据条款1至11中任一项的方法，其中，要执行的系统软件图像与第一软件版本相关联，以及其中，该方法进一步包括：通过另外在执行了等于或者超过第一软件版本的软件版本的一个或者多个DUT上执行第一测试来获得相关版本测试结果；对相关版本测试结果进行分析以确定第一测试在一个或者多个DUT上是否成功；以及在确定第一测试在一个或者多个DUT上成功之后，确定不在第二DUT上执行第一测试。

条款13-根据条款1至12中任一项的方法，其进一步包括：至少将第一测试结果与和生态系统协调员相关联的计算装置通信。

条款14-根据条款1至13中任一项的方法，其中，多个测试包括对与至少第一DUT相关联的第一HAL的第一HAL测试，以及其中，该方法进一步包括：确定是否要在第一DUT上执行第一HAL测试；以及在确定要在第一DUT上执行第一HAL测试之后，在第一DUT上执行第一HAL测试。

条款15-根据条款14的方法，其中，第一HAL是多个HAL的一部分，并且在第一DUT上执行第一HAL测试包括：确定与多个HAL相关联的HAL实例名称列表；确定HAL实例名称列表中的一个或者多个组合，其中，一个或者多个组合中的每个组合包括多个HAL中的每个HAL的实例名称；确定是否针对一个或者多个HAL实例名称的特定HAL实例名称组合执行HAL测试；以及在确定针对特定HAL实例名称组合执行HAL测试之后，在第一DUT上执行第一HAL测试。

条款16-根据条款1至15中任一项的方法，其中，公共设计包括公共硬件设计，其中，第一DUT包括公共硬件设计的第一实施方式，以及其中，第二DUT包括公共硬件设计的第二实施方式。

条款17-根据条款1至16中任一项的方法，其中，公共设计包括公共软件设计。

条款18-根据条款17的方法，其中，公共软件设计包括用于与装置有关的软件的公共设计和用于与装置有关的软件的公共设计中的一个或者多个。

条款19-根据条款1的方法，其中，基于第一测试结果并且基于第一DUT与第二DUT共享公共设计来确定在第一测试之前在第二DUT上执行第二测试包括：基于与分类层级相关联的一个或者多个分类标准来确定在第一测试之前在第二DUT上执行第二测试。

条款20-根据条款1的方法，其中，多个DUT与多个与装置相关的实体相关联，以及其中，确定在第一测试之前在第二DUT上执行第二测试包括：确定与至少阈值数量的多个与装置相关的实体相关联的一个或者多个DUT上至少未通过所述失败的第一测试。

条款21-根据条款1的方法，其中，多个DUT与多个与装置相关的实体相关联，以及其中，确定在第一测试之前在第二DUT上执行第二测试包括：确定与至少阈值百分比的多个与装置相关的实体相关联的一个或者多个DUT上至少未通过所述失败的第一测试。

条款22-根据条款1的方法，其中，第一DUT包括参考硬件，以及其中，第二DUT包括除了参考硬件之外的硬件。

条款23–一种主机计算装置，其包括：一个或者多个处理器；以及一种或者多种非暂时性计算机可读介质，该一种或者多种非暂时性计算机可读介质存储有计算机可读指令，这些计算机可读指令在由一个或者多个处理器执行时使该主机计算装置实施包括根据条款1至22中任一项的方法的功能。

条款24–一种主机计算装置，其包括：用于实施根据条例1至22中任一项的方法的部件。

条款25–一种制品，该制品包括：一种或者多种非暂时性计算机可读介质，该一种或者多种非暂时性计算机可读介质存储有计算机可读指令，这些计算机可读指令在由主机计算装置的一个或者多个处理器执行时使主机计算装置实施包括根据条款1至22中任一项的方法的功能。

条款26-一种装置，其包括：用于实施根据条款1至22中任一项的方法的部件。

以上详细描述参照附图描述了所公开的系统、装置和方法的各种特征和功能。在附图中，相似的符号通常识别相似的组件，除非上下文另有指示。在详细描述、附图和权利要求书中所描述的说明性实施例不旨在是限制性的。在不脱离本文所提出的主题的精神和范围的情况下，可以利用其它实施例，并且可以进行其它改变。将容易理解的是，可以按照多种多样的不同配置(本文明确地对所有不同配置进行了预期)来布置、替换、组合、分离和设计本公开的各个方面(如本文一般地描述的和在附图中图示的)。

针对附图中的并且如本文讨论的梯形图、场景和流程图中的任何一个或者全部，每个框和/或每种通信可以表示根据示例实施例的信息处理和/或信息传输。替代实施例包括在这些示例实施例的范围内。例如，在这些替代实施例中，可以按照与示出的或者讨论的顺序颠倒的顺序来执行被描述为框、传输、通信、请求、响应和/或消息的功能，包括大体上同时或者按照相反的顺序，这取决于所涉及的功能性。进一步地，可以与本文所讨论的梯形图、场景和流程图中的任何一个一起使用更多的或者更少的框和/或功能，并且这些梯形图、场景和流程图可以部分地或者整体地彼此组合。

表示信息处理的框可以与可以配置为执行本文描述的方法或者技术的特定逻辑功能的电路系统对应。可替代地或者此外，表示信息处理的框可以与模块、片段或者程序代码的一部分对应，并且可以包括相关的或者其它数据。程序代码可以包括可由处理器执行以实施方法或者技术中的特定逻辑功能或者动作的一个或者多个指令。程序代码和/或相关数据可以存储在任何类型的计算机可读介质上，诸如，存储装置，包括磁盘或者硬盘驱动器或者其它存储介质。

计算机可读介质还可以包括非暂时性计算机可读介质，诸如，与寄存器存储器、处理器高速缓冲存储器和随机存取存储器(RAM)一样在短时间段内存储数据的非暂时性计算机可读介质。计算机可读介质还可以包括在较长的时间段内存储程序代码和/或数据的非暂时性计算机可读介质，诸如，辅助的或者持久性长期存储装置，例如，如同只读存储器(ROM)、光盘或者磁盘、压缩盘只读存储器(CD-ROM)。计算机可读介质还可以是任何其它易失性或者非易失性存储系统。例如，可以将计算机可读介质视为计算机可读存储介质或者有形存储装置。

此外，表示一次或者多次信息传输的框可以与在相同物理装置中的软件模块和/或硬件模块之间的信息传输对应。然而，其它信息传输可以在不同物理装置中的软件模块和/或硬件模块之间。

虽然本文已经公开了各个方面和实施方式，但是对于本领域的技术人员而言，其它方面和实施例将是显而易见的。本文所公开的各个方面和实施例用于进行说明，而不旨在是限制性的，其中，真正的范围由以下权利要求书指示。

Claims (26)

1.一种方法，包括：

提供执行测试基础架构系统软件的主机计算装置，所述测试基础架构系统软件用于通过使用具有待由多个被测装置DUT执行的多个测试的测试套件来测试所述多个DUT，所述多个DUT包括第一DUT和第二DUT，其中，所述第一DUT和所述第二DUT共享公共设计，以及其中，所述多个测试包括第一测试和第二测试；

通过使用所述主机计算装置确定在所述第二测试之前在至少所述第一DUT上执行所述第一测试；

在所述主机计算装置处接收针对由所述第一DUT执行的失败的第一测试的第一测试结果；

基于所述第一测试结果并且基于所述第一DUT与所述第二DUT共享所述公共设计，确定在所述第一测试之前在所述第二DUT上执行所述第二测试；以及

所述主机计算装置随后指示所述第二DUT在执行所述第一测试之前执行所述第二测试。

2.根据权利要求1所述的方法，进一步包括：

生成所述测试基础架构系统的基于所述第二测试的执行的输出。

3.根据权利要求2所述的方法，其中，所述测试基础架构系统的基于所述第二测试的执行的所述输出包括以下中的一个或者多个：在所述多个DUT中的至少一个DUT上通过所述第二测试的指示、在所述多个DUT中的至少一个DUT上未通过所述第二测试的指示以及针对所述多个DUT中的至少一个DUT免除所述第二测试的指示。

4.根据权利要求3所述的方法，其中，所述方法进一步包括：

在所述测试基础架构系统处获得针对所述第二测试在所述第二DUT上的执行的第二测试结果；

在所述测试基础架构系统处基于所述第二测试结果来确定所述第二DUT是否通过所述第二测试；以及

在确定所述第二DUT通过所述第二测试之后，生成在至少所述第二DUT上通过所述第二测试的指示。

5.根据权利要求3或者权利要求4所述的方法，其中，所述方法进一步包括：

在所述测试基础架构系统处获得针对所述第二测试在所述第二DUT上的执行的第二测试结果；

在所述测试基础架构系统处基于所述第二测试结果来确定所述第二DUT是否未通过所述第二测试；以及

在确定所述第二DUT未通过所述第二测试之后，生成在至少所述第二DUT上未通过所述第二测试的指示。

6.根据权利要求3至5中的任一项所述的方法，其中，所述多个DUT进一步包括第三DUT，以及其中，所述方法进一步包括：

在所述测试基础架构系统处获得针对所述第二测试在所述第二DUT上的执行的第二测试结果；

在所述测试基础架构系统处基于所述第二测试结果来确定所述第二DUT是否未通过所述第二测试；以及

在确定所述第二DUT未通过所述第二测试之后，生成针对至少所述第三DUT免除所述第二测试的指示。

7.根据权利要求1至6中的任一项所述的方法，其中，所述多个测试包括用于测试包括与装置无关的软件部分的软件测试图像的一个或者多个测试。

8.根据权利要求7所述的方法，其中，用于测试包括所述与装置无关的软件部分的软件测试图像的所述一个或者多个测试包括用于测试与所述软件测试图像相关联的应用编程接口API的一个或者多个测试。

9.根据权利要求7或者权利要求8所述的方法，其中，所述多个DUT被配置为执行包括所述测试图像和与装置有关的软件部分的软件图像，以及其中，所述方法进一步包括：

在第一地理位置处生成所述测试图像；以及

在与所述第一地理位置不同的第二地理位置处生成包括所述与装置有关的软件部分的所述软件图像。

10.根据权利要求9所述的方法，其中，在执行所述第一测试之前将所述测试套件从所述第一地理位置传送至所述第二地理位置。

11.根据权利要求1至10中的任一项所述的方法，其中，所述多个DUT中的每个DUT利用公共硬件组件，以及其中，确定是否要在所述第二DUT上执行所述第一测试包括：

从所述第一测试结果中选择第一失败的测试结果，所述第一失败的测试结果针对由所述第一DUT对所述第一测试的一次或者多次失败的执行；

对所述第一失败的测试结果进行分析以确定所述公共硬件组件是否与所述第一失败的测试结果相关联；以及

在确定所述公共硬件组件与所述第一失败的测试结果相关联之后，确定不在所述第二DUT上执行所述第一测试。

12.根据权利要求1至11中的任一项所述的方法，其中，要执行的所述系统软件图像与第一软件版本相关联，以及其中，所述方法进一步包括：

通过另外在执行了等于或者超过所述第一软件版本的软件版本的一个或者多个DUT上执行所述第一测试来获得相关版本测试结果；

对所述相关版本测试结果进行分析以确定所述第一测试在所述一个或者多个DUT上是否成功；以及

在确定所述第一测试在所述一个或者多个DUT上成功之后，确定不在所述第二DUT上执行所述第一测试。

13.根据权利要求1至12中的任一项所述的方法，进一步包括：

将至少所述第一测试结果与和生态系统协调员相关联的计算装置通信。

14.根据权利要求1至13中的任一项所述的方法，其中，所述多个测试包括对与至少所述第一DUT相关联的第一硬件抽象层HAL的第一HAL测试，以及其中，所述方法进一步包括：

确定是否要在所述第一DUT上执行所述第一HAL测试；以及

在确定要在所述第一DUT上执行所述第一HAL测试之后，在所述第一DUT上执行所述第一HAL测试。

15.根据权利要求14所述的方法，其中，所述第一HAL是多个HAL的一部分，并且在所述第一DUT上执行所述第一HAL测试包括：

确定与所述多个HAL相关联的HAL实例名称的列表；

确定所述HAL实例名称的列表的一个或者多个组合，其中，所述一个或者多个组合中的每个组合包括所述多个HAL中的每个HAL的实例名称；

确定是否针对所述一个或者多个HAL实例名称的特定HAL实例名称组合执行HAL测试；以及

在确定针对所述特定HAL实例名称组合执行HAL测试之后，在所述第一DUT上执行所述第一HAL测试。

16.根据权利要求1至15中的任一项所述的方法，其中，所述公共设计包括公共硬件设计，其中，所述第一DUT包括所述公共硬件设计的第一实施方式，以及其中，所述第二DUT包括所述公共硬件设计的第二实施方式。

17.根据权利要求1至16中的任一项所述的方法，其中，所述公共设计包括公共软件设计。

18.根据权利要求17所述的方法，其中，所述公共软件设计包括用于与装置有关的软件的公共设计和用于与装置有关的软件的公共设计中的一个或者多个。

19.根据权利要求1所述的方法，其中，基于所述第一测试结果并且基于所述第一DUT与所述第二DUT共享公共设计来确定在所述第一测试之前在所述第二DUT上执行所述第二测试包括：基于与分类层级相关联的一个或者多个分类标准来确定在所述第一测试之前在所述第二DUT上执行所述第二测试。

20.根据权利要求1所述的方法，其中，所述多个DUT与多个与装置相关的实体相关联，以及其中，确定在所述第一测试之前在所述第二DUT上执行所述第二测试包括：确定与至少阈值数量的所述多个与装置相关的实体相关联的一个或者多个DUT上至少未通过所述失败的第一测试。

21.根据权利要求1所述的方法，其中，所述多个DUT与多个与装置相关的实体相关联，以及其中，确定在所述第一测试之前在所述第二DUT上执行所述第二测试包括：确定与至少阈值百分比的所述多个与装置相关的实体相关联的一个或者多个DUT上至少未通过所述失败的第一测试。

22.根据权利要求1所述的方法，其中，所述第一DUT包括参考硬件，以及其中，所述第二DUT包括除了所述参考硬件之外的硬件。

23.一种主机计算装置，包括：

一个或者多个处理器；以及

一个或者多个非暂时性计算机可读介质，所述一个或者多个非暂时性计算机可读介质存储有计算机可读指令，所述计算机可读指令在由所述一个或者多个处理器执行时使所述主机计算装置实施包括根据权利要求1至22中的任一项所述的方法的功能。

24.一种主机计算装置，包括：

用于实施根据权利要求1至22中的任一项所述的方法的部件。

25.一种制品，所述制品包括：一个或者多个非暂时性计算机可读介质，所述一个或者多个非暂时性计算机可读介质存储有计算机可读指令，所述计算机可读指令在由主机计算装置的一个或者多个处理器执行时使所述主机计算装置实施包括根据权利要求1至22中的任一项所述的方法的功能。

26.一种装置，包括：用于实施根据权利要求1至22中的任一项所述的方法的部件。

Images