CN115640181A - 一种图像处理器件的测试***和方法 - Google Patents

Abstract

本发明涉及硬件测试领域，特别是涉及一种图像处理器件的测试***和方法。主要包括：包括待测设备、测试目标、控制器和数据库服务器，待测设备***测试目标的图像处理器件接口中；测试目标执行具体的测试用例，测试目标支持通电即开机，每个所述测试用例使用同样的指定格式存放在独立的存储路径中；控制器控制测试目标依次执行每一个测试用例完成测试，收集整理测试结果，并输出测试结果；数据库服务器对控制器整理的测试结果进行存储，并进行基于数据的分析和查询。本发明能够实现芯片筛片测试和显卡量产测试两种场景下自动测试，并提高测试效率。

Description

一种图像处理器件的测试***和方法

技术领域

本发明涉及硬件测试领域，特别是涉及一种图像处理器件的测试***和方法。

背景技术

在图像处理器件(例如GPU和显卡)的生产过程中，需要对GPU芯片进行筛片测试，并对集成了GPU芯片后的量产显卡产品进行量产测试，以确保产品质量合格。

目前，GPU或显卡测试主要依赖手动测试，不仅效率低下，而且容易受到测试人员主观意志的影响。特别是在GPU芯片筛片测试和显卡量产测试两个环节，手动测试不但无法满足对测试效率和可靠性的要求，而且也无法保证功能的覆盖率。

鉴于此，如何克服现有技术所存在的缺陷，解决现有图像处理器件测试的测试效率和可靠性不足的现象，是本技术领域待解决的问题。

发明内容

针对现有技术的以上缺陷或改进需求，本发明解决了现有图像处理器件测试的测试效率低和可靠性不足的问题。

第一方面，本发明提供了一种图像处理器件的测试***，其包括待测设备、测试目标、控制器和数据库服务器，其中：

所述待测设备在筛片测试环境下为内嵌待测GPU芯片的SLT板，在量产测试环境下为待测显卡，所述待测设备***所述测试目标的图像处理器件接口中；

所述测试目标与待测设备一一对应，作为所述待测设备的工作平台，用于执行测试用例，其中，所述测试目标支持通电即开机，每个所述测试用例使用同样的指定格式存放在独立的存储路径中；

所述控制器用于控制所述测试目标依次执行每个所述测试用例完成测试，收集整理并输出测试结果，其中，所述测试结果包括所述GPU芯片的测试数据判定结果和/或显卡抓取的图像；

所述数据库服务器用于对所述控制器整理的所述测试结果进行存储，并进行基于数据的分析和查询。

优选的，所述控制器用于打开所述测试目标的电源以启动测试；所述测试目标用于按照预设顺序逐个执行测试用例，并通过UART接口向控制器返回测试结果，记录并整理每一个所述测试用例的结果以及处理测试过程中的异常情况。

优选的，还包括：运行在所述测试目标的操作***上的所述待测设备的GPU驱动程序，烧录在所述待测设备的NOR Flash中的MCU Firmware和VBIOS。

优选的，还包括：

所述测试目标还用于周期性向所述控制器发送心跳包，若所述控制器接收所述心跳包超时，所述控制器重启所述测试目标；

重启所述测试目标后，从头开始执行测试用例、从上一次失败的测试用例开始执行或从失败的测试用例的下一个测试用例开始执行；

当重启次数超过上限时，所述控制器关闭所述测试目标强制结束测试。

另一方面，本发明提供了一种图像处理器件的测试方法，基于如上所述的图像处理器件的测试***进行测试，其包括：

控制器控制测试目标开机，所述测试目标按照指定顺序获取测试用例，并依次执行每个所述测试用例；

所述控制器通过UART接口管理所述测试目标的测试进度，并获取每一个测试用例的测试结果；

汇总所有测试用例的测试结果并存入数据库服务器进行归档。

优选的，所述控制器通过UART接口管理测试目标的测试进度，包括：

在所述控制器和所述测试目标上运行测试框架，所述测试框架包括调度器、配置脚本、用例脚本和参考数据；

所述配置脚本和所述用例脚本为指定格式的文件，存放在同一个指定路径中，其中，所述配置脚本中包含每个测试用例对应的用例脚本，以及测试用例的执行顺序；

将所述参考数据和所述测试用例输出的数据进行对比，判断用例执行结果是否通过；

测试执行时，所述调度器根据所述配置脚本指定的顺序，通过UART接口向所述测试目标发送相应命令，控制所述测试目标依次执行测试用例对应的用例脚本。

优选的，所述通过UART接口向测试目标发送相应命令，包括：

对每一个进行测试的测试目标提供一个贯穿整个测试生命周期的UART命令监听线程，用于监听和处理控制器通过UART接口下发的命令；

对每一个进行测试的测试目标提供一个UART命令发送线程，所有向该测试目标发送的UART命令均由该UART命令发送线程完成。

优选的，所述配置脚本和所述用例脚本为指定格式的文件，对于用例脚本，包括：

单个用例脚本中包含一个独立的测试用例；

每个用例脚本中包含接口函数run()、result()和callback()；

run()用于根据控制器的命令执行测试用例，并返回测试结果；

result()用于在筛片测试环境下将测试用例的执行结果与参考数据对比，并返回对比结果；

callback()在测试用例执行完毕后触发调用，向控制器通知测试用例执行完毕。

优选的，所述获取每一个测试用例的测试结果，在非显示接口类测试时，包括：

在所述测试目标一侧完成全部测试用例的测试内容，将测试数据与参考数据进行对比，判定测试用例的执行结果是否通过；

所述测试目标向所述控制器返回判定结果，所述控制器获取所述测试目标返回的判定结果作为测试结果。

优选的，所述获取每一个测试用例的测试结果，在显示接口类测试时，包括：

所述测试目标根据测试用例抓取相应的实时图像，将抓取到的实时图像返回所述控制器；

所述控制器将抓取到的实时图像与参考图像对比，根据对比结果判定测试用例的执行结果是否通过。

根据本发明的又一方面，提供了一种电子设备，包括：处理器；与处理器通信连接的存储器；存储器存储有可被处理器执行的指令，指令被处理器执行，以使处理器能够执行上述图像处理器件的测试方法。

根据本发明的又一方面，提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令被处理器执行时实现上述图像处理器件的测试方法。

与现有技术相比，本发明实施例的有益效果在于：提供了一套图像处理器件自动化测试***，通过通电即开即的测试目标对GPU或显卡的自动化测试，通过使用指定格式和独立路径的测试用例提高了测试内容编排的灵活性，从而提高芯片筛片测试和显卡量产测试两种场景下的测试效率。

附图说明

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

图1为本发明实施例提供的一种图像处理器件的测试***架构示意图；

图2本发明实施例提供的一种图像处理器件的测试***多工位实施场景的架构示意图；

图3为本发明实施例提供的一种图像处理器件的测试方法流程图；

图4为本发明实施例提供的一种图像处理器件的测试方法软件模块示意图；

图5为本发明实施例中gTestCtrl项目目录结构示意图；

图6为本发明实施例中配置脚本文件格式示意图；

图7为本发明实施例提供的电子设备的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。正如本领域技术人员可以认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。

对本发明实施例中使用到的一些术语解释如下：

GPU：graphics processing unit，图形处理器；

DUT：Device Under Test，待测设备；

SLT：System Level Test，芯片***级测试，用于筛片；

DP：DisplayPort；

HWCI：Hardware Configuration Item，硬件配置项；

CSCI：Computer Software Configuration Item，软件配置项；

GUTF：GPU Unified Testcase Framework，GPU通用测试用例框架；

PCIe：peripheral component interconnect express，一种高速串行计算机扩展总线标准；

UART：Universal Asynchronous Receiver/Transmitter，通用异步接收/发送装置；

DBIF：Database Interface File，数据库接口文件；

HDMI：High Definition Multimedia Interface，高清多媒体接口；

DP：DisplayPort，一种标准化的数字式视频接口标准；

VBIOS：Video Basic Input Output System，视频基本输入输出***；

MCU：Microcontroller Unit，微控制单元。

如1所示，本实施例提供的图像处理器件的测试***包括四个HWCI，分别为：待测设备(DUT)、测试目标(Target)、控制器(Controller)和数据库服务器(DBServer)。

待测设备为需要进行测试的设备，在筛片测试环境下为内嵌待测GPU芯片的SLT板，在量产测试环境下为待测显卡，待测设备***测试目标的图像处理器件(例如GPU或显卡)接口中。实际实施中，待测设备可以***测试目标的PICe接口中，PCIe接口遵循PCIe4.0标准，用于将DUT连接到Target进行测试，Target的操作***中的GPU驱动程序(GPUDriver)通过PCIe接口控制待测GPU完成各种功能。

测试目标与待测设备一一对应，作为待测设备的工作平台，执行具体的测试用例，其中，所述测试目标支持通电即开机，每个所述测试用例使用同样的指定格式存放在独立的存储路径中。实际实施中，Target作为DUT的载体，可以使用具有PCIe插槽的Intel主机，或其它能够承载待测设备并便于测试程序运行的主机平台，用于执行具体的测试用例。电源控制(PowerCtrl)接口用于控制Target电源，启动测试时和Target状态异常时，均需要通过PowerCtrl接口控制Target重启，因此，Target必须支持通电即开机。

控制器控制测试目标依次执行每一个测试用例完成测试，收集整理测试结果，并输出测试结果。本实施例提供的测试***中，在筛片测试时，测试结果为GPU芯片的测试数据判定结果；在量产测试时，测试结果为显卡抓取的图像。实际实施中，Controller可以使用Intel平台的NUC或主机，作为整个测试***的主控，负责控制Target完成测试、收集整理测试结果和输出测试报告。使用UART串口用于Controller和Target之间的通信，以传输测试过程的控制控制命令。DUT的HDMI和DP接口分别通过HDMI/DP数字采集卡接入Controller，用于校验显示内容正确性。

数据库服务器对控制器整理的测试结果进行存储，并进行基于数据的分析和查询。实际实施中，DBServer可以使用远程数据库服务器，用于存储和查询测试结果。Controller通过DBIF将DUT测试结果实时存入数据库服务器中，数据库服务器通过DBIF提供网页界面支持条件查询。

测试过程中，上述硬件设备通过其上运行的CSCI进行控制，CSCI包括：gTestCtrl、gTestSrv、gTestDB、GPU Driver、MCU Firmware和VBIOS。每个CSCI的具体定义和实现在下文中详细叙述，也可以根据下述功能描述自行设计开发相应的CSCI。

gTestSrv是运行在Target上的测试服务程序，在Target开机后将自动运行。其功能是按照预先配置好的顺序逐个执行测试用例，并通过UART接口向gTestCtrl返回测试结果。对于显示接口类测试(如：HDMI/DP)，需要抓取接口输出的图像进行比对，因此将显示接口通过数字图像采集卡(以下简称“采集卡”)接入Controller，由gTestCtrl负责判断接口输出图像的正确性。

gTestCtrl是运行在Controller上的测试主控程序，负责打开Target电源以启动测试、记录并整理每一个测试用例的结果以及处理测试过程中的异常情况。进一步的，gTestCtrl还可以提供图形化界面，能实时显示测试过程，并能够实时显示采集卡抓取的图像，以便人工测试时测试员能够肉眼观察图像正确性，补充自动化测试无法覆盖的测试内容。

gTestDB是运行在DBServer上的数据库服务，提供DBIF接口存入和查询测试结果，并支持条件查询，以便于对测试结果进行分析。

在所有CSCI中，GPU Driver、MCU Firmware和VBIOS是保障图像处理器件运行的基本软件组件，由GPU开发者提供并保证其可靠性。为了便于在测试***的相应硬件设备上进行使用，测试设备中的GPU驱动程序运行在测试目标的操作***上，MCU Firmware和VBIOS烧录在测试设备的NOR Flash中。

对于每一个GPU或显卡进行测试时，由控制器打开测试目标的电源以启动测试。具体的，首先将DUT安装在Target上，在筛片测试环境下是待测GPU装入SLT板后***Target的PCIe插槽内，在显卡测试环境下直接将显卡***Target的PCIe插槽内。DUT安装好之后，通过gTestCtrl启动测试流程，gTestCtrl通过PowerCtrl接口控制Target启动或重新启动。

启动后，gTestSrv在测试开始前先需要对DUT和Target进行必要的初始化，例如：连接串口、读取配置文件获取测试用例列表。

初始化完成后，Target按照预设顺序逐个执行测试用例，并通过UART接口向控制器返回测试结果，记录并整理每一个测试用例的结果以及处理测试过程中的异常情况。具体的，gTestCtrl确认gTestSrv已上线后，向gTestSrv发送TEST_START，通知其测试开始。gTestSrv和gTestCtrl根据测试用例配置判断是否所有测试用例已经执行完毕。gTestCtrl向gTestSrv发送TC_START命令，并在参数中附带测试用例编号n，gTestSrv收到命令后开始执行第n个测试用例。gTestCtrl等待gTestSrv发送TC_RESULT命令通知当前测试用例执行结果。gTestCtrl收到测试用例执行结果后，应将该结果记录到数据库中，以便当前DUT测试完毕后进行汇总。全部测试用例执行完毕后，gTestSrv结束运行并将Target关机，为更换DUT和下一次测试做好准备。gTestCtrl结束对当前DUT的测试，整理测试结果存入数据库。记录测试结果，并准备下一轮测试。

进一步的，为了判断Target上电后是否正常工作，运行在Target上的gTestSrv启动线程每隔固定的时间间隔向运行在Controller上的gTestCtrl发送HEARTBEAT命令，表明其状态正常。gTestCtrl等待第一次HEARTBEAT心跳包确认gTestSrv已上线，然后向gTestSrv发送TEST_START，通知其测试开始。

由于测试执行过程中Target有可能卡死(例如GPU总线故障导致Target卡死)，测试目标周期性向控制器发送心跳包，若控制器接收心跳包超时，控制器重启测试目标。具体实施中，gTestSrv需要每隔5秒通过UART向gTestCtrl发送心跳包，一旦gTestCtrl超过5秒没有收到心跳包，它将控制Target重启，重新开始测试。gTestCtrl应能够配置重启后从头开始执行、从上一次失败的测试用例开始执行或从失败用例的下一个开始执行。且gTestCtrl应能够配置重试机制针对同一个DUT的最大次数。同时，gTestCtrl启动线程不间断检测gTestSrv发来的HEARTBEAT命令，若收到该命令，刷新心跳包更新时间。若超过5秒仍未收到该命令，则认为Target状态异常，应跳转到测试启动阶段，立即重启Target，以便重新开始测试。可以理解的是，上述时间间隔可根据实际需求进行设置，本发明对此不做限制。

由于本实施例中提供了发生异常时自动重启的机制，因此，gTestSrv在测试开始的初始化时还需要判断当前启动是否为异常重启。若是异常重启，则需要根据异常处理策略进行处理，重启测试目标后，从头开始执行测试用例、从上一次失败的测试用例开始执行或从失败的测试用例的下一个测试用例开始执行。从头开始执行测试用例、从上一次失败的测试用例开始执行或从失败的测试用例的下一个测试用例开始执行。当重启次数超过上限时，控制器关闭测试目标强制结束测试。

实际实施时，Target和DUT一一对应，共同组成一套测试工装(以下简称“工装”)。为了提高测试效率，Controller可以同时支持多个工装同时执行测试，且工装之间的测试进度应没有相关性，每个测试工位包含一个Controller和多个工装。

如图2所示，通常一个测试产线包括多个测试工位，共用一个DBServer。每轮测试完成后，Controller通过网络向DBServer上报测试结果，由DBServer记录到数据库中以备查询。进一步的，若需要对多个不同生产地点的测试进行统一管理，DBServer应部署在云端，应独立于每个生产地点运行。为了提高整个***健壮性，DBServer应拆分成本地服务器和中心服务器，每个生产地点部署一台本地服务器，和测试工位中的Controller处于同一局域网段，用于缓存测试结果数据；中心服务器位于云端，用于汇总所有本地服务器的数据，提供查询服务。

本实施例提供的图像处理器件的测试***，通过Controller启动Target，并控制Target自动执行测试用例，将Target的测试结果进行汇总和存储，实现了自动化的GPU筛片测试的和显卡的量产测试，避免了手动测试造成的测试效率低、可靠性差、功能测试的覆盖率不足等问题。

本实施例中还提供了一种图像处理器件的测试方法。如图3所示，可以通过以下步骤，使用实施例中提供的测试***完成图像处理器件的测试。

步骤101：控制器控制测试目标开机，测试目标按照指定顺序获取测试用例，并依次执行每个测试用例。

测试开始时，Controller控制Target开机，并进行相应的初始化。读取配置文件获取测试用例列表，并按照列表顺序执行测试用例。

步骤102：控制器通过UART接口管理测试目标的测试进度，并获取每一个测试用例的测试结果。

运行在Target上的gTestSrv分别在每个测试用例开始前和结束后通过UART接口向gTestCtrl发送通知，Controller根据通知和心跳包状态，通过UART接口发送测试用例对应的命令，以控制测试进度，并记录每一个测试用例的结果。为了提高测试效率，每个gTestCtrl同时控制多个Target进行测试，每个Target上的gTestSrv的测试进度相互独立。

步骤103：汇总所有测试用例的结果并存入数据库服务器进行归档。

所有测试用例都执行完毕后，汇总所有测试用例的结果并存入gTestDB归档，以便后期进行管理和分析。

经过本实施例中提供的步骤101至步骤103后，即可自动完成测试目标中承载的待测设备的测试。

在实际实施中，为了提高软件***的内部模块集成度和可扩展性，软件测试框架内部还可以细化为不同的软件模块。如图4所示，Controller上运行的gTestCtrl可以采用三层设计，最上层Application Layer，包含主程序Main；中间层是Business层，包含GUI、Scheduler、Testcase、DBIF、Config等模块；最下层是Hardware Abstraction Layer(HAL)，包含Capture、Uart和TargetCtrl模块。gTestSrv采用两层设计，上层是主程序Main，下层分为Config、Testcase、Scheduler、Uart和Utils五个模块。其中，Config模块用于处理配置文件；Testcase模块用于封装执行单个测试用例的所有逻辑；Scheduler用于按照指定顺序依次执行多个测试用例；Uart模块用于和gTestCtrl通信，封装了UART通信协议；Utils模块用于封装一些基础功能函数。

在实际实施中，为了提高方法的通用性和可扩展性，引入GPU通用测试用例框架(GPU Unified Testcase Framework，以下简称“框架”或“GUTF”)。控制器上运行测试框架，测试框架由调度器、配置脚本、用例脚本和参考数据组成。调度器即为Controller上运行的gTestCtrl以及Target上运行的gTestSrv中的Scheduler模块。

配置脚本、用例脚本和参考数据由调度器的具体执行流程互相独立，使框架具有充分的可扩展性，测试用例编写者在不修改测试程序任何一个软件组件源码的情况下，只需要遵循测试用例编写标准，就可以实现各种类型的测试用例，并能随意改变测试用例的执行顺序。

配置脚本和用例脚本为指定格式的文件，存放在同一个指定路径中。具体的，gTestCtrl项目目录结构如图5所示，分为存放src和script两个目录，src中存放源代码相关文件，script中存放测试用例的配置文件、用力模板、用力脚本和参考数据等资源。在具体实施中，配置脚本可以使用json格式，图4中，配置文件名为tcconfig.json。在具体实施中，script目录应使用独立的git仓管理，以便由不同的团队开发和维护，为了gTestCtrl和gTestSrv中script目录应为同一代码仓，为了确保两端执行内容一致，其内容应该完全相同。

具体实施中，用例脚本可以使用约定格式编写的python脚本，单个用例脚本中仅包含一个独立的测试用例，为了确保对每个测试用例独立管理，并便于对不同用例进行组合，不应该在同一个用例脚本中实现多个测试。为了便于调度器进行用例的调度和管理，每个用例脚本中必须实现了以下接口函数run()、result()和callback()。

(1)run()：由gTestSrv的Scheduler模块调用，用于根据控制器的命令执行测试用例，并返回测试结果。

(2)result()：由gTestCtrl的Scheduler模块调用，用于在筛片测试环境下将测试用例的执行结果与参考数据对比，并返回对比结果。

(3)callback()：由gTestCtrl的Scheduler模块在测试用例执行完毕后触发调用，向控制器通知测试用例执行完毕。

通过上述接口函数，可以实现测试用例的自动调度，以及测试结果的自动返回，在非人工调度的情况下完成所需的测试。

配置脚本中包含每个测试用例对应的用例脚本，以及测试用例的执行顺序，用例脚本文件名和执行顺序在配置脚本中定义，具体格式如图6所示，其中tc_list(testcaselist)为本次测试的测试用例的列表，每组{}中包含一个测试用例的相关属性，进行测试时根据列个表顺序依次。对于每个测试用例，tc_name(testcasename)为该测试用例的名称，tc_drsc(testcasedescription)为该测试用例的描述，tc_script(testcasescript)为该测试用例的用例脚本文件名，exit_on_fail/stop_on_fail表示当测试用例执行失败后的处理方式。在实际实施中，为了便于查看进行和管理测试顺序，配置脚本中的执行顺序也可以通过GUI进行显示，并由测试人员通过GUI进行编辑或修改，再生成新的配置脚本。进一步的，为了避免执行冲突，配置文件应维护版本号，如果应用程序版本和配置文件版本不匹配，程序应报错退出；如果配置文件不存在，程序启动时根据默认配置自动生成配置文件。

所述参考数据用于和测试用例输出的数据进行对比，从而判断用例执行结果是否通过，具体内容根据测试需要进行确定。

测试执行时，调度器根据配置脚本指定的顺序，通过UART接口向测试目标发送相应命令，控制测试目标依次执行测试用例对应的用例脚本。具体的Uart命令发送接收代码可以写入Uart模块中。Uart模块对每一个进行测试的测试目标提供一个贯穿整个测试生命周期，即贯穿整个gTestCtrl生命周期的UART命令监听线程，用于监听和处理控制器通过UART接口下发的命令。同时，Uart模块对每一个进行测试的测试目标提供一个UART命令发送线程，所有向该测试目标发送的UART命令均由该UART命令发送线程完成，以保证UART报文的完整性。

每个测试用例执行完成后，还需要对测试结果进行评判，针对图像处理器件的不同测试内容，需要进行不同方式的评判。

(1)对于非显示接口类测试用例。

非显示接口类测试用例一般包括各芯片管脚的通信功能、基本配置参数和运行参数的读写、基本运行状态、性能等，可以通过参数的数值或电平数值进行评判。在测试目标一侧完成全部测试用例的测试内容，将测试数据与参考数据进行对比，判定测试用例的执行结果是否通过。测试目标向控制器返回判定结果，控制器获取测试目标返回的判定结果作为测试结果。具体的，可以在测试用例的run()方法中实现全部测试步骤，并在方法结尾自行对测试结果进行判断，最终返回测试结果。在result()方法中仅需要等待调度器的命令返回的测试结果即可。

(2)对于显示接口类测试用例。

显示接口类的输出为图像或指定时间段内多次拍摄的图像序列，由于Target一侧无法感知显示接口输出的图像内容，因此无法独立完成测试结果的判断，需要gTestCtrl根据采集卡抓取的图像内容辅助判断。测试目标根据测试用例抓取相应的实时图像，将抓取到的实时图像返回控制器。控制器将抓取到的实时图像与参考图像对比，根据对比结果判定测试用例的执行结果是否通过。具体的，run()方法中仅需控制显示接口输出图像，在result()方法中调用图像抓取接口抓取实时图像，与预先准备好的参考图像进行对比，从而判断用例执行的结果是否通过。图像对比可以在显示器上显示后由测试人员人工对比，也可以通过图像识别或神经网络等方式进行特征对比。

获取测试结果后，还可以通过DBServer上的数据库对测试结果进行汇总和分析。具体实施中，可以使用gTestDB模块完成数据库相关的操作和管理，gTestDB是运行在DBServer上的数据库服务，提供DB Interface接口存入和查询测试结果，支持条件查询。为了便于扩展和用户查看，gTestDB可以使用B/S架构，包含Web前端、mysql数据库后端，Web前端负责Dut测试数据的展示，数据库后端负责测试数据的存储，DBServer分为本地服务器和中心服务器，通过配置文件配置数据是存到本地服务器或者中心服务器。本地服务器的数据在测试机连接以太网后，可以将本地数据传输到中心服务器。Web页面可查看中心服务器数据，支持在Web页面对数据的查询，Web页面设置用户登录权限，例如：每个加工地点人员只能查看本工厂的数据，GPU开发人员可以查看所有的数据。

由上可知，可以在上述实施例中提供的图像处理器件的测试***的硬件结构基础上，通过本实施例的方法完成图像处理器件的自动测试，并通过标准化的配置脚本和用例文件对测试用例的内容和顺序进行编排，提高了图像处理器件测试的自动化程度和测试效率。

图7为根据本申请一实施例的电子设备的结构框图。本申请实施例还提供了一种电子设备，如图7所示，该电子设备包括：至少一个处理器701，以及与至少一个处理器701通信连接的存储器703。存储器703内存储有可被至少一个处理器701执行的指令。指令被至少一个处理器701执行。处理器701执行该指令时实现上述实施例中的图像处理器件的测试方法。存储器703和处理器701的数量可以为一个或多个。该电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

该电子设备还可以包括通信接口705，用于与外界设备进行通信，进行数据交互传输。各个设备利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器701可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备上显示图形用户界面(Graphical User Interface，GUI)的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器***)。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器703、处理器701及通信接口705集成在一块芯片上，则存储器703、处理器701及通信接口705可以通过内部接口完成相互间的通信。

应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(Advanced RISC Machines，ARM)架构的处理器。

本申请实施例提供了一种计算机可读存储介质(如上述的存储器703)，其存储有计算机指令，该程序被处理器执行时实现本申请实施例中提供的方法。

可选的，存储器703可以包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需要的应用程序；存储数据区可存储根据驾驶场景重构方法的电子设备的使用所创建的数据等。此外，存储器703可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器703可选包括相对于处理器701远程设置的存储器，这些远程存储器可以通过网络连接至驾驶场景重构方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或多个(两个或两个以上)用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行***、装置或设备(如基于计算机的***、包括处理器的***或其他可以从指令执行***、装置或设备取指令并执行指令的***)使用，或结合这些指令执行***、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种图像处理器件的测试***，其特征在于，包括待测设备、测试目标、控制器和数据库服务器，其中：

所述待测设备在筛片测试环境下为内嵌待测GPU芯片的SLT板，在量产测试环境下为待测显卡，所述待测设备***所述测试目标的图像处理器件接口中；

所述测试目标与待测设备一一对应，作为所述待测设备的工作平台，用于执行测试用例，其中，所述测试目标支持通电即开机，每个所述测试用例使用同样的指定格式存放在独立的存储路径中；

所述控制器用于控制所述测试目标依次执行每个所述测试用例完成测试，收集整理并输出测试结果，其中，所述测试结果包括所述GPU芯片的测试数据判定结果和/或显卡抓取的图像；

所述数据库服务器用于对所述控制器整理的所述测试结果进行存储，并进行基于数据的分析和查询。

2.根据权利要求1所述的图像处理器件的测试***，其特征在于，所述控制器用于打开所述测试目标的电源以启动测试；所述测试目标用于按照预设顺序逐个执行测试用例，并通过UART接口向控制器返回测试结果，记录并整理每一个所述测试用例的结果以及处理测试过程中的异常情况。

3.根据权利要求1所述的图像处理器件的测试***，其特征在于，还包括：

运行在所述测试目标的操作***上的所述待测设备的GPU驱动程序，烧录在所述待测设备的NOR Flash中的MCU Firmware和VBIOS。

4.根据权利要求1所述的图像处理器件的测试***，其特征在于，还包括：

所述测试目标还用于周期性向所述控制器发送心跳包，若所述控制器接收所述心跳包超时，所述控制器重启所述测试目标；

重启所述测试目标后，从头开始执行测试用例、从上一次失败的测试用例开始执行或从失败的测试用例的下一个测试用例开始执行；

当重启次数超过上限时，所述控制器关闭所述测试目标强制结束测试。

5.一种图像处理器件的测试方法，其特征在于，基于如权利要求1-4中任一项所述的图像处理器件的测试***进行测试，包括：

控制器控制测试目标开机，所述测试目标按照指定顺序获取测试用例，并依次执行每个所述测试用例；

所述控制器通过UART接口管理所述测试目标的测试进度，并获取每一个测试用例的测试结果；

汇总所有测试用例的测试结果并存入数据库服务器进行归档。

6.根据权利要求5所述的图像处理器件的测试方法，其特征在于，所述控制器通过UART接口管理测试目标的测试进度，包括：

在所述控制器和所述测试目标上运行测试框架，所述测试框架包括调度器、配置脚本、用例脚本和参考数据；

所述配置脚本和所述用例脚本为指定格式的文件，存放在同一个指定路径中，其中，所述配置脚本中包含每个测试用例对应的用例脚本，以及测试用例的执行顺序；

将所述参考数据和所述测试用例输出的数据进行对比，判断用例执行结果是否通过；

测试执行时，所述调度器根据所述配置脚本指定的顺序，通过UART接口向所述测试目标发送相应命令，控制所述测试目标依次执行测试用例对应的用例脚本。

7.根据权利要求6所述的图像处理器件的测试方法，其特征在于，所述通过UART接口向测试目标发送相应命令，包括：

对每一个进行测试的测试目标提供一个贯穿整个测试生命周期的UART命令监听线程，用于监听和处理控制器通过UART接口下发的命令；

对每一个进行测试的测试目标提供一个UART命令发送线程，所有向该测试目标发送的UART命令均由该UART命令发送线程完成。

8.根据权利要求6所述的图像处理器件的测试方法，其特征在于，所述配置脚本和所述用例脚本为指定格式的文件，对于用例脚本，包括：

单个用例脚本中包含一个独立的测试用例；

每个用例脚本中包含接口函数run()、result()和callback()；

run()用于根据控制器的命令执行测试用例，并返回测试结果；

result()用于在筛片测试环境下将测试用例的执行结果与参考数据对比，并返回对比结果；

callback()在测试用例执行完毕后触发调用，向控制器通知测试用例执行完毕。

9.根据权利要求5-8中任一项所述的图像处理器件的测试方法，其特征在于，所述获取每一个测试用例的测试结果，在非显示接口类测试时，包括：

在所述测试目标一侧完成全部测试用例的测试内容，将测试数据与参考数据进行对比，判定测试用例的执行结果是否通过；

所述测试目标向所述控制器返回判定结果，所述控制器获取所述测试目标返回的判定结果作为测试结果。

10.根据权利要求5-8中任一项所述的图像处理器件的测试方法，其特征在于，所述获取每一个测试用例的测试结果，在显示接口类测试时，包括：

所述测试目标根据测试用例抓取相应的实时图像，将抓取到的实时图像返回所述控制器；

所述控制器将抓取到的实时图像与参考图像对比，根据对比结果判定测试用例的执行结果是否通过。

Images