CN117851107A - 可动态扩容的分布式自动测试向量生成方法、装置及系统 - Google Patents

Abstract

本申请公开了一种可动态扩容的分布式自动测试向量生成方法、装置及系统。其中，该系统包括：管理节点，在云平台中调整计算节点的数量，以与测试需求所需计算资源匹配；将全局队列中的测试任务分发给各计算节点；通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口；计算节点集合，各计算节点根据接收到的任务中的故障列表生成测试向量，进行故障仿真并将故障仿真中检测的故障反馈给管理节点；在接收到更新通知时将故障列表中新测故障的状态更新为已检测。本申请解决了传统分布式ATPG不能应付测试需求的快速变化的技术问题。

Description

可动态扩容的分布式自动测试向量生成方法、装置及系统

技术领域

本申请涉及芯片测试领域，具体而言，涉及一种可动态扩容的分布式自动测试向量生成方法、装置及系统。

背景技术

本部分旨在为权利要求书或说明书中陈述的内容提供背景或上下文，此处描述的内容不因为包括在本部分中就承认是现有技术。

分布式ATPG（Distributed Automatic Test Pattern Generation，简称Distributed ATPG）是一种在集成电路测试领域日益受到重视的创新技术，其核心目标是通过充分利用分布式计算资源，实现对复杂集成电路IC的高效、准确测试，该技术的引入旨在应对传统测试方法在处理大规模测试和数据时所面临的挑战，为集成电路设计和制造过程带来显著的优势，传统分布式ATPG的计算节点数通常是静态固定的，难以应对测试需求的快速变化。

现有的分布式ATPG方法存在以下6个方面的问题和缺点：

1）固定资源配置：普通分布式ATPG系统通常需要预先配置一定数量的计算节点和资源，这种固定的资源配置可能导致资源的浪费，因为在低负载时，某些节点可能处于闲置状态，而在高负载时可能不足以满足需求；2）性能瓶颈：固定资源配置可能导致性能瓶颈，当测试工作负载超过系统的能力时，系统可能无法满足测试需求，从而延长测试时间；3）缺乏弹性：普通分布式ATPG系统通常不具备弹性扩展能力，无法自动根据测试工作负载的变化来分配或释放资源，这可能需要手动干预和资源重新配置，导致管理复杂性和额外的维护工作；4）容错性不足：普通分布式ATPG系统可能缺乏高级的容错机制，当某个节点发生故障时，系统可能无法自动处理或重新分配任务，可能需要手动干预来解决问题；5）资源管理复杂性：这种系统可能需要更多的手动资源管理工作，包括节点配置、任务分配和资源调整，这增加了系统的复杂性和管理成本；6）不适用于大规模任务：普通分布式ATPG系统可能不太适合处理大规模测试任务，因为它们的资源配置和容量受到限制，可能无法满足大规模测试的需求。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种可动态扩容的分布式自动测试向量生成方法、装置及系统，以至少解决传统分布式ATPG不能应付测试需求的快速变化的技术问题。

根据本申请实施例的一个方面，提供了一种可动态扩容的分布式自动测试向量生成系统，包括：管理节点，用于在云平台中调整计算节点集合中计算节点的数量，以使计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，其中，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障；计算节点集合，计算节点集合中的各计算节点根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点；在接收到管理节点的新测故障的更新通知的情况下，将故障列表中新测故障的状态更新为已检测。

可选地，分布式自动测试向量生成系统还包括：etcd服务端，etcd服务端上部署有分布式键值存储系统的etcd服务端；管理节点和计算节点集合中的各个计算节点上均部署有分布式键值存储系统的etcd客户端；在计算节点启动时，运行etcd客户端，计算节点上的etcd客户端通过与etcd服务端之间的通信，将计算节点的地址信息注册到etcd服务端；在管理节点启动时，运行etcd客户端，管理节点上的etcd客户端通过与etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个计算节点之间的远程过程调用通道，管理节点与各个计算节点之间的远程过程调用通道并行运行；在管理节点启动后，管理节点上的etcd客户端通过与etcd服务端之间的通信，定期获取新增计算节点的地址信息，并根据获取的地址信息建立与新增计算节点之间的远程过程调用通道。

可选地，在计算节点启动后，计算节点上的etcd客户端通过与etcd服务端之间的通信，在etcd服务端更新计算节点的TTL；在管理节点启动后，管理节点上的etcd客户端通过与etcd服务端之间的通信，将自己的服务实例的相关信息（例如IP地址、端口号、服务名称、健康状态等）写入到etcd服务端的注册中心中，同时指定一个TTL（Time To Live）过期时间。etcd服务端会自动维护这些服务实例的心跳信息，当一个服务实例的心跳超时（即心跳间隔超过TTL），则etcd服务端会将其从注册中心中删除，通过心跳机制，管理节点能够获知当前各个计算节点的健康状态。

可选地，在计算节点启动后，开启负载报告线程，周期性地向管理节点报告计算节点的负载状况，管理节点根据计算节点的负载状况为计算节点分配任务。

可选地，在一个计算节点的任务队列为空时，从另一个计算节点的任务队列中窃取任务至自己的任务队列中；在从另一个计算节点的任务队列中窃取任务失败的情况下，从管理节点的全局队列中获取任务。

根据本申请实施例的另一方面，还提供了一种可动态扩容的分布式自动测试向量生成方法，包括：在云平台中调整计算节点集合中计算节点的数量，以使计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，其中，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障，计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点。

可选地，在管理节点启动时，运行etcd客户端，通过与etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个计算节点之间的远程过程调用通道，管理节点与各个计算节点之间的远程过程调用通道并行运行。

根据本申请实施例的另一方面，还提供了一种可动态扩容的分布式自动测试向量生成装置，包括：匹配单元，用于在云平台中调整计算节点集合中计算节点的数量，以使计算节点集合与测试需求所需计算资源匹配；分发单元，用于在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点；测试单元，用于在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，其中，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障，计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方法中任一实施例的步骤。

在本申请实施例中，在云平台中调整计算节点集合中计算节点的数量，以使计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，其中，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障，计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点，进而解决了传统分布式ATPG不能应付测试需求的快速变化的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的可动态扩容的分布式自动测试向量生成系统的示意图；

图2是根据本申请实施例的一种可选的可动态扩容的分布式自动测试向量生成方法的流程图；

图3是根据本申请实施例的一种可选的可动态扩容的分布式自动测试向量生成系统的示意图；

图4是根据本申请实施例的一种可选的任务窃取方案的示意图；

图5是根据本申请实施例的一种可选的可动态扩容的分布式自动测试向量生成装置的示意图；

图6是根据本申请实施例的一种终端的结构框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

传统分布式ATPG的计算节点数通常是静态固定的，难以应对测试需求的快速变化。无论是针对小规模测试还是大规模测试，传统的分布式ATPG都是采用一样的配置，容易造成资源浪费。

为了应对这些挑战，根据本申请实施例的一方面，提供了一种可动态扩容的分布式自动测试向量生成系统的实施例，可动态扩容的分布式自动测试向量生成（DynamicScalable Distributed ATPG），可动态扩容的分布式ATPG通过灵活的计算节点管理机制，实时评估任务的复杂度和系统的负载情况，自适应的增缩节点数量，使分布式ATPG能够更好的适应不同规模测试的需求，同时保证资源利用率的最大化和系统吞吐量的最大化。该方案采用了分布式键值存储系统etcd，以实现实时监听系统中各节点状态的变化，从而能够实现在系统运行时自动监测故障节点的下线情况，同时支持新节点的动态添加，以及对节点负载状况的实时报告和容量预警。

如图1所示，本申请的可动态扩容的分布式自动测试向量生成系统包括：

管理节点（即Master）11，用于在云平台中调整计算节点集合中计算节点（即SubMaster或者Slave）的数量，以使计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值Threshold时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，其中，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障。

基于历史的已测故障数量数据对故障同步阈值（即设定阈值Threshold）更新阈值计算公式如下：

1）管理节点设定一个固定大小（如N）的数组，保存近期各个计算节点汇报的新测故障数量（即第i个计算节点的新测故障数量，i的取值为正整数，最大值为计算节点的数量）并根据FIFO策略进行淘汰（即始终只保留最新的N个）；

2）在计算故障同步阈值的时候，由于存在某些计算节点测到的故障数量较多，某些计算节点测到的故障数量较少（即可能是游离在故障数量分布外的非正常点，会产生较大的影响），因此剔除掉数组中的最大值和最小值，之后计算这些故障数量的平均值，并记为；

3）根据预测的新测故障数量的平均值和计算节点的数量，根据如下公式计算出预估的故障同步阈值，其中表示计算节点数量，Interval表示至少每隔多少轮同步一次故障：

，

4）根据预估的故障同步阈值和前一次的实际故障同步阈值（计算方式与/>相同），计算本次实际的故障同步阈值，其中/>是动量系数：

，

5）该故障同步方法根据历史窗口获得的数据对当前故障阈值进行较为平滑的更新。

计算节点集合13，计算节点集合中的各计算节点根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点；在接收到管理节点的新测故障的更新通知的情况下，将故障列表中新测故障的状态更新为已检测。

可选地，分布式自动测试向量生成系统还包括：etcd服务端，etcd服务端上部署有分布式键值存储系统的etcd服务端；管理节点和计算节点集合中的各个计算节点上均部署有分布式键值存储系统的etcd客户端；在计算节点启动时，运行etcd客户端，计算节点上的etcd客户端通过与etcd服务端之间的通信，将计算节点的地址信息注册到etcd服务端；在管理节点启动时，运行etcd客户端，管理节点上的etcd客户端通过与etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个计算节点之间的远程过程调用通道，管理节点与各个计算节点之间的远程过程调用通道并行运行；在管理节点启动后，管理节点上的etcd客户端通过与etcd服务端之间的通信，定期获取新增计算节点的地址信息，并根据获取的地址信息建立与新增计算节点之间的远程过程调用通道。

在计算节点启动后，计算节点上的etcd客户端通过与etcd服务端之间的通信，将自己的服务实例信息（例如IP地址，端口号，服务名称，健康状态等）写入到etcd服务端中，同时指定一个TTL（Time To Live）过期时间。etcd服务端会自动维护这些服务实例的心跳信息，当一个服务实例的心跳超时（即心跳间隔超过TTL），则etcd服务端会将其从注册中心中删除，通过心跳机制，管理节点能够获知当前各个计算节点的健康状态。

在一个计算节点的任务队列为空时，从另一个计算节点的任务队列中窃取任务至自己的任务队列中；在从另一个计算节点的任务队列中窃取任务失败的情况下，从管理节点的全局队列中获取任务。

采用本申请的技术方案，可动态扩容的系统具有弹性，可以根据测试需求动态增加或减少测试节点和计算资源，这意味着系统可以在测试工作量增加时自动扩展，而在负载较低时减少资源，从而更有效地利用资源并节省成本；可动态扩容的系统能够适应不断增长的测试工作负载。当需要运行大规模测试程序时，系统可以自动扩展以处理更多的测试向量和数据，从而缩短测试时间，可以解决传统分布式ATPG不能应付测试需求的快速变化的技术问题。另外，可动态扩容的系统通常具有更强大的自动故障处理能力，当某个节点发生故障或失效时，系统可以自动检测并将任务重新分配给其他可用节点，从而保证测试的连续性和可靠性；可动态扩容的系统通常提供实时监控和报告功能，可以监测系统性能、资源利用率和任务进度，这有助于及时发现问题并采取必要的措施来优化测试流程。

在发明人的研究过程中，发现了一个关键问题：在处理不同电路时，必须在初始化阶段估算计算节点的数量，计算节点数量估算过多会导致整个系统资源的浪费，计算节点数量估算过少可能会导致系统资源的短缺。此外，如果在运行过程中出现计算节点不可用的情况，这会导致系统的CPU资源紧缺，测试向量生成速度减慢，甚至可能无法继续完成测试任务，造成系统的不稳定。

为了解决这一问题，根据本申请实施例的另一方面，还提供了一种可动态扩容的分布式自动测试向量生成方法的实施例，如图2所示，包括：

步骤S202，在云平台中调整计算节点集合中计算节点的数量，以使计算节点集合与测试需求所需计算资源匹配。

步骤S204，在进行测试时，将全局队列中的测试任务分发给计算节点集合中的各计算节点。

步骤S206，在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在新测故障的数量达到设定阈值（具体实现方式参考上文）时，将所有新测故障同步给计算节点集合中的各计算节点、并更新至历史数据窗口，云平台用于向使用者提供所需的运算资源，历史数据窗口用于保存历史上检测到的故障，计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给管理节点。

可选地，在管理节点启动时，运行etcd客户端，通过与etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个计算节点之间的远程过程调用通道，管理节点与各个计算节点之间的远程过程调用通道并行运行。

本申请引入动态扩容机制，这个机制允许在系统测试期间动态地增加计算节点的数量，以适应不同测试负载的需求，尤其在云计算的背景下，动态扩容和缩容机制可以充分利用云上资源的优势，这有助于加速分布式ATPG系统的运行速度，提高资源利用率，并确保我们能够有效地应对不断变化的测试需求。

引入动态扩容机制不仅能够提高系统的性能和弹性，还能够降低成本。通过根据实际需求分配和释放资源，可以避免不必要的资源浪费。这不仅对于大规模电路测试非常重要，还为未来的测试工作和研究提供了更多的灵活性和可持续性。

总之，动态扩容机制是我们研究中的一项关键创新，它可以显著改善分布式ATPG系统的性能，并在云计算环境中实现更高效的资源管理。这一创新有望为电路测试领域带来积极的影响，提高测试效率，降低成本，加速芯片的上市速度。

本发明设计了可动态扩容的分布式ATPG，目的是为了使分布式ATPG能够更好的适应不同规模测试的需求，在不同规模的商业RISCV基准电路上进行验证，对比固定计算节点的分布式ATPG框架，本方法能充分利用计算节点的资源达到更高的性能。作为一种可选的实施例，下文结合具体实施方式进一步详述本申请的技术方案：

本方法的整体系统设计如图3所示（GMS为Good Machine Simulation的缩写，TPG为Test Pattern Generation的缩写，FS为Fault Simulation的缩写），主要分为通信模块，计算模块，调度模块，服务中心模块。

通信模块采用的是google的grpc框架，实现主控节点和计算节点之间的通信。主控节点和每个计算节点之间使用独立的grpc channel，每个grpc channel配置接收和发送的消息包大小以及使用多条http stream，保证数据流的并行传输。

计算模块由所有计算节点参与，每个计算节点维护局部的任务队列，每次取出队首的任务执行，当局部任务队列为空时，该计算节点会随机从另一个工作节点的任务队列中获取其一半的任务，假如获取失败（其它工作节点的任务队列也为空），则从主控节点的全局队列中获取任务。

调度模块维护系统中所有节点的运行状态和负载情况，调度模块中使用etcd客户端监听etcd服务中的注册节点信息，当计算节点下线时，调度模块能够及时将分配的任务重新回收到全局任务队列中，保证任务的完备性。

服务中心模块采用docker启动的etcd服务，并将该etcd端口映射到本机端口，保证外部可访问性。etcd服务是一个分布式键值存储引擎，提供了etcd客户端连接并设置键值的方法，同时提供了etcd客户端能够获取已注册键的服务注册方法。所以我们可以根据一个固定的注册路径去注册和获取对应的ip地址和端口。因此我们选择键为/service/distributeATPG/，计算节点注册到该目录下能够被主控节点获知并建立连接，初始化以及分配任务。

整体系统的运行步骤如下：

（1）使用Docker run启动etcd服务，监听的ip地址为本地ip，监听端口分别为2379和2380，并通过端口映射到对应的本机端口2378和2379。

（2）启动计算节点，每个计算节点初始化自身状态和数据文件以及创建etcd客户端，并调用etcd客户端将本地ip地址+映射端口注册到etcd服务中的/service/distributeATPG/中。

（3）启动主控节点，主控节点初始化自身状态和数据文件以及创建一个额外的心跳监测线程去周期性检查etcd服务中的/service/distributeATPG/中已经注册的计算节点ip地址+端口，对每个ip地址+端口建立连接。

（4）在建立连接之后，主控节点先向每个计算节点发送一个初始化请求，获取每个计算节点的当前负载情况以及每个计算节点的计算资源和内存资源。根据当前每个计算节点的资源情况分配对应的任务数量。

Master模块（即主控节点）包含以下几个子模块：

1、初始化与任务划分模块：

首先，Master模块建立一个心跳监测线程周期性查看etcd服务中计算节点的注册情况，对于每个新加入的计算节点，Master模块需要初始化其状态并对分布式编程框架GPRC的channel进行配置，包括channel最大传输消息大小和channel标识 id。接着，Master模块需要创建与每个Slave的连接。然后，Master模块会读取并解析网表和向量格式文件。如果启用ATPG中的静态学习方法，Master模块需要先设置静态学习的参数并运行静态学习。随后，Master模块会创建故障列表，并将其划分为任务列表，每个任务由任务id和故障列表的子集组成。这样，Master相关的数据结构初始化就完成了。

2、任务分配和结果回收：

Master模块会并发传输网表和向量格式文件到每个Slave端，传输完成后，Slave端开始解析网表和向量格式文件，Master则阻塞等待所有Slave端的完成。Master模块随后会从任务列表中分派任务给每个Slave。一旦Slave获得任务，就会根据任务中的故障列表进行测试向量生成，然后进行故障仿真。Slave将仿真结果中标记为已测到的故障进行收集并返回给Master。此后，Master汇总Slave传回的已测故障并对其中新测故障进行统计。如果新测故障的数量超过了阈值，则Master会在下次分派任务中将所有新测故障同步到每个Slave上，Slave将更新自己的故障列表。当Master检测到所有任务完成时，它会发出结束信号并在所有Slave结束后停止运行。

3、负载均衡：

Master模块会周期性监测系统中Slave模块的状态，Slave模块在启动时会额外开启一个负载报告线程，周期性报告当前Slave模块的信息（包括当前CPU的利用率，内存利用率，任务完成时间等信息）给Master模块，Master模块根据CPU的利用率情况，适当减少或增加对这个Slave模块分发的任务数量，并在某些Slave模块负载失衡时能够对外部报警，通过管理员去调整整个系统。通过负载均衡机制，增加了分布式ATPG系统得健壮性和可用性。

4、最终生成的测试向量和测试报告：

最终，Master模块会生成测试向量和测试报告。测试向量将用于测试电路的正确性，测试报告则可以用来评估测试的效果和质量，测试报告包含故障覆盖率，测试向量数目，测试周期等关键指标。

Slave模块包含以下几个子模块：

1、接收Master分配的子故障列表：

在Slave模块中，它需要分批次接收Master分配的子故障列表，并根据这个列表来执行ATPG过程。同时Master会分配一些ATPG算法的初始化参数，用于初始化ATPG。

2、执行ATPG：

一旦Slave收到Master分配的任务，它就会根据任务中的故障列表进行测试向量生成，然后进行故障仿真。Slave将仿真结果中标记为已测到的故障进行收集并返回给Master。

3、任务窃取

参考图4，当Slave（记为Slave1）中的任务队列为空时，Slave1先查看邻居节点（即Slave2至Slavem，若其存在（m-1）个邻居节点）的任务数量，若邻居节点的任务数量超过其设定的任务队列长度一半Ti/2（i的取值为1至m，Ti表示第i个Slave，即Slavei的设定任务队列长度），则当前的Slave1可以从邻居节点中进行窃取，窃取的数量为，若窃取邻居节点后未满任务队列长度的一半则从全局队列中补足任务，保证任务分配的负载均衡。

采用本申请的技术方案：1）本发明提出的基于分布式键值数据库实现的计算节点服务注册和服务发现模块，服务节点定时进行健康检查。注册到服务目录中的信息设置一个较短的TTL（"Time to Live"的缩写，它是一种用于控制数据在计算机网络中存活时间的机制。TTL值通常与网络中的数据包或缓存条目相关联），etcd会周期性检查服务节点的运行状况，若服务节点运行正常，则更新对应服务节点的TTL，若当前时间超过TTL，证明该服务节点在周期检查中未响应，则认为该节点处于不健康的工作状态，通过周期检查，保证服务节点处于健康运行的状态。2）本发明提出计算节点负载均衡机制，由于计算节点的性能可能存在差异，为了保证每个计算节点的负载处在合理范围之中，需要监测计算节点的负载情况，并对任务进行调度。我们使用work-stealing的方法，空闲节点可以从随机工作节点的任务队列中窃取任务放到自身队列，如果窃取失败，则从全局队列中获取任务。3）本发明提出分布式ATPG系统计算上云，云计算平台允许根据实际需求动态分配和释放计算节点。这意味着在需要时可以快速增加节点以处理大规模测试任务，而在负载减轻时可以减少节点，从而更有效地利用资源。云计算平台通常提供按需计费的模式，这意味着只需在使用时支付计算资源的费用。这可以降低成本，因为不需要预先购买或租赁大量的硬件设备。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本申请各个实施例所述的方法。

根据本申请实施例的另一个方面，还提供了一种用于实施上述可动态扩容的分布式自动测试向量生成方法的可动态扩容的分布式自动测试向量生成装置。图5是根据本申请实施例的一种可选的可动态扩容的分布式自动测试向量生成装置的示意图，如图5所示，该装置可以包括：

匹配单元51，用于在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；

分发单元53，用于在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；

测试单元55，用于在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。

通过上述模块，在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。可以解决传统分布式ATPG不能应付测试需求的快速变化的技术问题。

根据本申请实施例的另一个方面，还提供了一种用于实施上述可动态扩容的分布式自动测试向量生成方法的服务器或终端。

图6是根据本申请实施例的一种终端的结构框图，如图6所示，该终端可以包括：一个或多个（图中仅示出一个）处理器601、存储器603、以及传输装置605，如图6所示，该终端还可以包括输入输出设备607。

其中，存储器603可用于存储软件程序以及模块，如本申请实施例中的可动态扩容的分布式自动测试向量生成方法和装置对应的程序指令/模块，处理器601通过运行存储在存储器603内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的可动态扩容的分布式自动测试向量生成方法。存储器603可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器603可进一步包括相对于处理器601远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置605用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置605包括一个网络适配器（Network Interface Controller，NIC），其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置605为射频（Radio Frequency，RF）模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器603用于存储应用程序。

处理器601可以通过传输装置605调用存储器603存储的应用程序，以执行下述步骤：

在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图6所示的结构仅为示意，终端可以是智能手机（如Android手机、iOS手机等）、平板电脑、掌上电脑以及移动互联网设备（Mobile InternetDevices，MID）、PAD等终端设备。图6其并不对上述电子装置的结构造成限定。例如，终端还可包括比图6中所示更多或者更少的组件（如网络接口、显示装置等），或者具有与图6所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器（Read-Only Memory，ROM）、随机存取器（RandomAccess Memory，RAM）、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行可动态扩容的分布式自动测试向量生成方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备（可为个人计算机、服务器或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种可动态扩容的分布式自动测试向量生成系统，其特征在于，包括：

管理节点，用于在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障；

所述计算节点集合，所述计算节点集合中的各计算节点根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点；在接收到所述管理节点的所述新测故障的更新通知的情况下，将所述故障列表中所述新测故障的状态更新为已检测。

2.根据权利要求1所述的分布式自动测试向量生成系统，其特征在于，

所述分布式自动测试向量生成系统还包括：etcd服务端，所述etcd服务端上部署有分布式键值存储系统的etcd服务；

所述管理节点和所述计算节点集合中的各个计算节点上均部署有所述分布式键值存储系统的etcd客户端；

在所述计算节点启动时，运行所述etcd客户端，所述计算节点上的etcd客户端通过与所述etcd服务端之间的通信，将所述计算节点的地址信息注册到所述etcd服务端；

在所述管理节点启动时，运行所述etcd客户端，所述管理节点上的etcd客户端通过与所述etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个所述计算节点之间的远程过程调用通道，所述管理节点与各个所述计算节点之间的远程过程调用通道并行运行；

在所述管理节点启动后，所述管理节点上的etcd客户端通过与所述etcd服务端之间的通信，定期获取新增计算节点的地址信息，并根据获取的地址信息建立与所述新增计算节点之间的远程过程调用通道。

3.根据权利要求2所述的分布式自动测试向量生成系统，其特征在于，

在所述计算节点启动后，所述计算节点上的etcd客户端通过与所述etcd服务端之间的通信，将所承载的服务实例的相关信息写入到所述etcd服务端的注册中心中，同时设定一个TTL过期时间；

所述etcd服务端自动维护所有服务实例的心跳信息，当一个服务实例的心跳间隔超过设定的TTL过期时间的情况下，则所述etcd服务端将心跳间隔超过设定的TTL过期时间的服务实例从注册中心中删除，所述管理节点通过心跳机制来获知各个计算节点当前的健康状态。

4.根据权利要求2所述的分布式自动测试向量生成系统，其特征在于，

在所述计算节点启动后，开启负载报告线程，周期性地向所述管理节点报告所述计算节点的负载状况，所述管理节点根据所述计算节点的负载状况为所述计算节点分配任务。

5.根据权利要求2所述的分布式自动测试向量生成系统，其特征在于，

在一个计算节点的任务队列为空时，从另一个计算节点的任务队列中窃取任务至自己的任务队列中；

在从另一个计算节点的任务队列中窃取任务失败的情况下，从所述管理节点的全局队列中获取任务。

6.一种可动态扩容的分布式自动测试向量生成方法，其特征在于，应用于权利要求1至5中任意一项所述的可动态扩容的分布式自动测试向量生成系统，包括：

在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；

在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；

在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值Threshold时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。

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

在管理节点启动时，运行etcd客户端，通过与etcd服务端之间的通信，获取各个计算节点的地址信息，并根据地址信息分别建立与各个所述计算节点之间的远程过程调用通道，所述管理节点与各个所述计算节点之间的远程过程调用通道并行运行。

8.一种可动态扩容的分布式自动测试向量生成装置，其特征在于，应用于权利要求1至5中任意一项所述的可动态扩容的分布式自动测试向量生成系统，包括：

匹配单元，用于在云平台中调整计算节点集合中计算节点的数量，以使所述计算节点集合与测试需求所需计算资源匹配；

分发单元，用于在进行测试时，将全局队列中的测试任务分发给所述计算节点集合中的各计算节点；

测试单元，用于在测试过程中，通过比对历史数据窗口和各计算节点检测到的故障确定新测故障，并在所述新测故障的数量达到设定阈值时，将所有新测故障同步给所述计算节点集合中的各计算节点、并更新至所述历史数据窗口，其中，所述云平台用于向使用者提供所需的运算资源，所述历史数据窗口用于保存历史上检测到的故障，所述计算节点集合中的各计算节点用于根据接收到的任务中的故障列表生成测试向量，然后利用生成的测试向量进行故障仿真并将故障仿真中检测的故障反馈给所述管理节点。

9.一种计算机可读的存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求6至7中任一项中所述的方法。

10.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求6至7任一项中所述的方法。