一种设备出厂检测方法、装置、设备及存储介质与流程

本申请涉及设备检测领域，尤其涉及一种设备出厂检测方法、装置、设备及存储介质。

背景技术：

通常设备在出厂发货前，都必须经历出厂检测的过程，来保证设备符合品质要求，在出厂检测的过程中，为了判断各项信息是否完备、准确，通常都需要对每个判断逻辑进行代码逻辑的编写。常用的出厂检测方案主要有两种：1)通过出厂检测工具采集设备的各项信息，然后通过硬编码的代码逻辑，对要检测的各项信息进行是否符合要求的判断，如果所有判断都通过，则出厂检测通过，否则，则为不通过。2)在运行出厂检测工具时，再依次按照要求去采集各项设备信息，如果能采集到符合要求的各项设备信息，则出厂检测通过，否则，则为不通过。

本申请的发明人在研究过程中发现，现有的出厂检测方法，只是采集信息的时机和方式不同，但均需要在代码逻辑中硬编码对设备信息是否符合要求的判断，其具有如下缺点：一是当检测需求有变动时，需要修改代码进行工具的变更发布，响应速度慢；二是每次变更对需要直接修改代码，非常容易引入错误，从而导致实际上不符合要求的设备被检测通过，或者原本符合要求的设备被视为不通过，更严重的是频繁的变更易使得出厂检测工具不可用，从而直接影响设备的快速出厂与发货，进而影响业务。

技术实现要素：

本申请所要解决的技术问题在于，提供一种设备出厂检测方法、装置、设备及存储介质，能够解决现有技术中存在的上述问题。

为了解决上述技术问题，一方面，本申请提供了一种设备出厂检测方法，所述方法包括：采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值；将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据；从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述；利用所述验证文件对所述目标数据进行验证。

另一方面，本申请提供了一种设备出厂检测装置，所述装置包括：信息采集模块，用于采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值；目标数据生成模块，用于将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据；验证文件获取模块，用于从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述；目标数据验证模块，用于利用所述验证文件对所述目标数据进行验证。

另一方面，本申请提供了一种设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行如上述的方法。

另一方面，本申请提供了一种计算机存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如上述的方法。

在本申请实施例中，通过采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值，将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据，并从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述，以及利用所述验证文件对所述目标数据进行验证。如此，可以在代码检测规则需要进行变化时，直接对结构化的各个验证信息进行变更，从而可以高效灵活地进行出厂检测规则的变更，并且，也避免了现有技术中代码的变更与服务的发布，大大提升了出厂检测服务的灵活性和安全性。

附图说明

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

图1是本申请实施例提供的硬件环境示意图；

图2是本申请实施例提供的一种设备出厂检测方法的流程图；

图3是本申请实施例提供的应用示意图；

图4是本申请实施例提供的一种设备出厂检测方法中利用所述验证文件对所述目标数据进行验证的流程图；

图5是本申请实施例提供的一种设备出厂检测方法中利用所述第一验证条件对所述目标对象值进行验证的流程图；

图6是本申请实施例提供的一种设备出厂检测方法中在所述从所述目标数据中查找与所述目标对象标识对应的目标对象值的步骤之前还包括的步骤的流程图；

图7是本申请实施例提供的一种设备出厂检测方法中另一种利用所述验证文件对所述目标数据进行验证的流程图；

图8是本申请实施例提供的一种设备出厂检测方法中另一种利用所述验证文件对所述目标数据进行验证的流程图；

图9是本申请实施例提供的一种设备出厂检测方法中利用所述第三验证条件对所述目标对象值进行验证，利用所述第四验证条件对所述附加对象值进行验证的流程图；

图10是本申请实施例提供的一种设备出厂检测装置的结构示意图；

图11是本申请实施例提供的一种设备出厂检测设备的结构示意图。

具体实施方式

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

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

本申请涉及以下关键术语，以下为各关键术语的含义。

json：json(javascriptobjectnotation,js对象简谱)是一种轻量级的数据交换格式。它基于ecmascript(欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得json成为理想的数据交换语言，其易于人阅读和编写，同时也易于机器解析和生成，能有效地提升网络传输效率。

jsonschema：jsonschema(json模式)是一种基于json格式定义json数据结构的规范。其用于：描述现有数据格式；干净的人类和机器可读的文档；完整的结构验证，有利于自动化测试，可用于验证客户端提交的数据。从表现形式上来说，jsonschema实际上也还是json数据。jsonschema制定了一系列规范，使得我们可以使用它来定义json数据的格式。这有点像我们先定义了“语言”是什么怎么用，然后可以用“语言”来规定什么是诗词歌赋。“诗词歌赋”以及“诗词歌赋的定义”实际上也都还是“语言”。简单来说，我们有json数据a，我们可以定义json数据b用来描述a的结构。这时候json数据b也就是jsonschema，它可以描述以及验证json数据。

出厂检测：一般来说，设备出厂，都会经历出厂检测，有时候也称为oqc(outgoingqualitycontrol，出货检验)或称为：成品出厂检验、出厂质量控制，是指设备在出厂之前为保证出厂设备满足客户品质要求所进行的检验，只有经检验合格的设备才能予以放行出厂。

本发明实施例提供了一种设备出厂检测方法，可选地，在本发明实施例中，上述的设备出厂检测方法可以应用于如图1所示的第一终端101和服务器102所构成的硬件环境中。如图1所示，服务器102通过网络与第一终端101进行连接，上述网络包括但不限于：广域网、城域网或局域网，第一终端101并不限定于pc、手机、平板电脑等。本发明实施例的设备出厂检测方法可以由第一终端101来执行，所述第一终端101中可以安装有用于供出厂测试人员测试用的客户端。

作为一个可能的实施方式，终端101和服务器102均可以是区块链系统中的节点设备，能够将获取到以及生成的信息共享给区块链系统中的其他节点设备，实现多个节点设备之间的信息共享。区块链系统中的多个节点设备可以配置有同一条区块链，该区块链由多个区块组成，并且前后相邻的区块具有关联关系，使得任一区块中的数据被篡改时都能通过下一区块检测到，从而能够避免区块链中的数据被篡改，保证区块链中数据的安全性和可靠性。

以下结合图2对本发明实施例提供的一种设备出厂检测方法进行说明，如图2所示，所述方法包括：

步骤s201：采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值；

在本申请实施例中，所述对象标识为设备中的各项信息中的标识，可以用于区分设备中的各项信息，所述对象值为设备中各项信息的具体内容，例如，“device_sn”为一个对象标识，“sfadskfjdsakjfjkd”为一个对象值。

对于每个待出厂设备，其设备信息可以包括多个对象标识以及与每个对象标识一一对应的对象值，例如，设备信息可以包括设备序列号标识、版本标识等，相应的，设备信息中还可以包括与设备序列号标识对应的设备序列号，与版本标识对应的版本号等。

步骤s203：将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据；

在本申请实施例中，可以将所述对象标识作为关键字，将所述对象值作为该关键字的值，以组装成结构化的待验证的目标数据。

具体的，可以将所述对象标识和所述对象值以键值对的形式组装成json数据结构体，例如，对于设备序列号标识和与其对应的设备序列号，其组装的json数据结构体如下：

{

"device_sn":"sfadskfjdsakjfjkd"

}

步骤s205：从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述；

在本申请实施例中，所述服务器中可以存储有在不同时间点上传的若干验证文件，在获取用于对目标数据进行验证的验证文件时，可以基于服务器中各个验证文件的上传时间从所述服务器中拉取最新更新的验证文件。

现有技术中，对于验证文件制定用户(即检测规则指定人)来说，通常的方案需要和出厂检测服务的维护人员进行沟通，以对检测规则进行变更，然后等待维护人员修改代码、变更服务，往往需要较长时间才能发布新的检测规则，而通过本申请实施例的方法，使得后续可以响应于验证文件制定用户的修改指令，对各个结构化验证信息进行修改，例如，可以直接对其中的键值进行修改，并可以基于修改后的验证信息生成修改后的验证文件，以及可以响应于所述验证文件制定用户的上传指令，将所述修改后的验证文件上传至所述服务器。

在实际应用中，如图3所示，通过将验证文件从硬编码中抽取出来，并存储在服务器中，当存在新的测试需求时，验证文件制定用户(即检测规则指定人)可以直接对从服务器拉取的结构化的验证文件进行修改，并可以将修改后的验证文件实时存储到服务器中，当有设备进行出厂检测时，可以实时查询到最新的检测规则，这样就将规则的更新，从代码的变更与服务的发布，改为了配置存储的变更，大大提升了出厂检测服务的稳定性。

步骤s207：利用所述验证文件对所述目标数据进行验证。

在本申请实施例中，通过采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值，将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据，并从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述；利用所述验证文件对所述目标数据进行验证。如此，可以在代码检测规则需要进行变化时，直接对结构化的各个验证信息进行变更，从而可以高效灵活地进行出厂检测规则的变更，并且，也避免了现有技术中代码的变更与服务的发布，大大提升了出厂检测服务的灵活性和安全性。

在一些实施例中，所述验证文件包括第一验证信息，所述第一验证信息包括目标对象标识和第一验证条件，相应的，如图4所示，所述利用所述验证文件对所述目标数据进行验证(即步骤s207)可以包括：

步骤s401：从所述目标数据中查找与所述目标对象标识对应的目标对象值，其中，所述目标对象标识和所述第一验证条件在所述第一验证信息中以键值对的形式进行描述；

其中，所述目标对象标识由验证文件制定用户根据测试需求确定，所述目标对象标识通常为至少一个所述对象标识中的一种，例如，所述设备信息包括设备序列号标识和版本标识，当验证文件制定用户想要对与版本标识对应的版本号进行测试，则可以将所述第一验证信息中的所述目标对象标识设定为版本标识。

所述第一验证条件设定了与所述目标对象标识对应的目标对象值需要满足的条件，例如，所述目标对象标识为版本标识，对应的目标对象值为版本号，所述第一验证条件中则设定版本号需要满足的条件。

可选的，可以将所述目标对象标识和所述第一验证条件以键值对的形式描述在jsonschema中，当然，也可以利用json或key-value等形式简单的直接进行检测规则的描述。

步骤s403：利用所述第一验证条件对所述目标对象值进行验证；

步骤s405：在所述目标对象值通过所述第一验证条件的验证时，确认所述目标数据通过所述验证文件的验证。

例如，当版本号通过第一验证条件中设定的版本号需要满足的条件如格式要求时，则说明版本号通过第一验证条件的验证，也说明目标数据通过验证文件的验证。

在实际应用中，可以在代码检测规则需要进行变化时，直接对结构化的第一验证信息中的第一验证条件进行变更，从而可以高效灵活地进行出厂检测规则的变更，并且，也避免了现有技术中代码的变更与服务的发布，大大提升了出厂检测服务的灵活性和安全性。

在一些实施例中，如图5所示，所述利用所述第一验证条件对所述目标对象值进行验证(即步骤s403)可以包括：

步骤s501：利用所述第一验证条件对所述目标对象值进行验证，其中，所述第一验证条件中包括至少一个第一验证项目子标识和至少一个第一验证子条件，所述第一验证项目子标识和所述第一验证子条件在所述第一验证条件中以键值对的形式进行描述；

步骤s503：在所述目标对象值通过所述第一验证条件中所有所述第一验证子条件的验证时，确定所述目标数据通过所述第一验证信息的验证。

其中，所述第一验证项目子标识可以包括：目标对象值的数据类型(对应的第一验证子条件可以为预设字符类型如字符串类型、整数类型等)、目标对象值的长度(对应的第一验证子条件可以为第二预设长度范围)、目标对象值的数值大小(对应的第一验证子条件可以为预设大小范围)、目标对象值的字段值的格式(对应的第一验证子条件可以为预设字母格式如全部为大写字母)等等。

当所述目标对象值通过所述第一验证条件中所有所述第一验证子条件的验证时，说明所述目标对象值通过所述第一验证条件的验证，也说明所述目标数据通过所述第一验证信息的验证。

在实际应用中，通过对第一验证条件进行结构化的细化表达，使得在代码检测规则需要进行较小的变化时，例如，在只需要对某一个验证项目子标识对应的验证子条件进行改动时，用户可以根据验证项目子标识与验证子条件的对应关系，直接对相应的验证子条件进行改动，而无需对其余验证项目子标识以及其余验证子条件做改动，从而可以大大提升代码检测规则变更的效率，并可以有效保证代码规则变更的安全性。

在一些实施例中，所述验证文件中还包括第三验证信息，相应的，如图6所示，在所述从所述目标数据中查找与所述目标对象标识对应的目标对象值的步骤(即步骤s401)之前，所述方法还可以包括：

步骤s601：利用所述第三验证信息对所述目标数据进行验证，其中，所述第三验证信息中包括第二关键字和预设数据类型，所述第二关键字和所述预设数据类型在所述第三验证信息中以键值对的形式进行描述，所述第三验证信息通过所述第二关键字设定待验证的所述目标数据的数据类型需要为预设数据类型；

步骤s603：在所述目标数据的数据类型为所述预设数据类型时，确定所述目标数据通过所述第三验证信息的验证，并执行所述利用所述第一验证条件对所述目标对象值进行验证的步骤。

其中，所述预设数据类型可以是指对象，对象是指一组“键值对”的集合，是一种无序的复合数据集合。

所述第二关键字用于设定待验证的所述目标数据的数据类型需要为预设数据类型，例如，第三验证信息为："type":"object",其中，type为第二关键字，其用于设定目标数据的数据类型需要为对象(即object)。

在实际应用中，通过第三验证信息的设置，可以保证组装的待验证的目标数据的数据类型是没有问题的，并在此基础上利用各个验证信息对所述目标数据进行进一步的检测，从而避免了由于目标数据组装错误导致的测试失败，大大提高了设备出厂检测的效率。

在一个具体的实施例中，可以将所述目标对象标识和所述第一验证条件以键值对的形式描述在jsonschema中，并可以将所述验证项目子标识和所述验证子条件在所述第一验证条件中以键值对的形式进行描述。例如，在目标对象标识为设备序列号标识时，其在jsonschema中的描述如下：

在上述的jsonschema中，对json数据结构体进行了下列要求：

1)json数据结构体必须是一个对象类型；

2)json数据结构体中的"device_sn"数据，必须是一个字符串类型，且长度最长是23位，最短也是23位；

3)json数据结构体中必须包含"device_sn"这个数据；

4)json数据结构体中允许包含其他数据。

其中，在关键字properties的值中，“device_sn”为设备序列号标识；

"type":"string","minlength":23,"maxlength":23为第一验证条件，该设备序列号标识和该第一验证条件以键值对的形式进行描述。

经过以上规则要求，即可保障检测的逻辑，即设备序列号必须为23位的字符串。相似度，利用这种方式，也可以进行其他各式各样的检测规则的判断，如：设备序列号不能为空、设备序列号必须全部为大写字母、设备的操作系统必须为android系统、设备的系统版本必须大于xxx版本以及设备的某状态必须为xxx状态等。

据此，当检测规则需要变化时，如需要将设备序列号的长度要求从23位改为22位，无需对代码做出变更，也无需对出厂检测服务进行变更发布，只需要将jsonschema改为：

可见，在实际应用中，当用户需要将设备序列号的长度要求从23位变更为22位，只需要将与minlength对应的值由23修改为22，以及将与maxlength对应值由23修改为22，而无需对验证项目子标识如maxlength做改动，也无需对其余验证项目子标识如type以及其余验证子条件如string做改动，从而可以大大提升代码检测规则变更的效率，并可以有效保证代码规则变更的安全性。

除了方便灵活高效地进行出厂检测规则的变更外，由于jsonschema本身也是一种json数据结构体，符合json数据的规则，因此也可以接入已有的工具，对jsonschema本身是否格式正确做出校验判断，在规则的变更阶段，就可以由机器杜绝人为疏忽导致的错误规则，从而提高出厂检测规则的安全性，避免影响出厂检测服务本身的稳定性。

并且，由于json是一种广泛使用的数据结构体，各编程语言均对json有相应的处理工具，同样也都能够支持通过jsonschema对json数据进行格式校验，因此，改造和接入成本很低。

在一些实施例中，所述验证文件中还包括第二验证信息，所述第二验证信息中包括第一关键字和预设对象标识，相应的，如图7所示，所述利用所述验证文件对所述目标数据进行验证(即步骤s207)可以包括：

步骤s701：查询所述目标数据中是否包括所述预设对象标识，其中，所述第一关键字和所述预设对象标识在所述第二验证信息中以键值对的形式进行描述，所述第二验证信息通过所述第一关键字设定所述目标数据中的至少一个对象标识需要为预设对象标识；

步骤s703：在所述目标数据中包括所述预设对象标识时，确定所述目标数据通过所述验证文件的验证。

其中，所述预设对象标识为用户提前设定的所述目标数据中必须具有的对象标识，如根据测试需求，待验证的目标数据中必须具有预设硬件信息如摄像头信息或设备序列号信息，那么，所述预设对象标识即为摄像头信息标识或设备序列号标识。

所述第一关键字用于设定待验证的所述目标数据中的至少一个对象标识需要为预设对象标识，例如，第二验证信息为："required":["device_sn"],其中，required为第一关键字，其用于设定目标数据中的至少一个对象标识需要为设备序列号标识(即device_sn)。

在实际应用中，通过对第二验证信息进行结构化的表达，使得在目标数据中必须具有的标识需要进行变化时，只需要对所述第二验证信息中的预设对象标识进行修改，而无需对第一关键字如required做改动，并且，由于第二验证信息独立于第一验证信息，用户也无需对第一验证信息做改动，从而可以大大提升代码检测规则变更的效率，并可以有效保证代码规则变更的安全性。

在一些实施例中，由于设备本身在不断升级演进，对于新版本所述设备与老版本的设备，可能需要不同的检测规则，在常规的方案中，只能根据设备的版本加上分支逻辑进行处理，久而久之就会变得无法维护，为了解决此类问题，所述验证文件中还可以包括第四验证信息，所述第四验证信息和所述第一验证信息通过第三关键字关联，所述第四验证信息中包括所述目标对象标识、第三验证条件、第四验证条件以及与所述目标对象标识关联的附加对象标识，所述目标对象标识和所述第三验证条件在所述第四验证信息中以键值对的形式进行描述，所述附加对象标识和所述第四验证条件在所述第四验证信息中以键值对的形式进行描述；相应的，如图8所示，所述利用所述验证文件对所述目标数据进行验证(即步骤s207)可以包括：

步骤s801：利用所述第三验证条件对所述目标对象值进行验证，并从所述目标数据中查找与所述附加对象标识对应的附加对象值，利用所述第四验证条件对所述附加对象值进行验证；

步骤s803：在所述目标数据同时通过所述第三验证条件和所述第四验证条件的验证时，确定所述目标数据通过所述第四验证信息的验证；

步骤s805：在所述目标数据通过所述第一验证信息或所述第四验证信息的验证时，则确定与所述目标数据通过所述验证文件的验证。

其中，所述第三关键字用于表征所述目标数据只需通过所述第一验证信息和所述第四验证信息中任意一个的验证，即通过所述验证文件的验证，所述第三关键字可以为anyof。

所述第三验证条件设定了与所述目标对象标识对应的目标对象值需要满足的不同于所述第一验证条件的条件，例如，所述目标对象标识为版本标识，对应的目标对象值为版本号，所述第一验证条件中设定版本号需要满足的第一条件，所述第三验证条件中则设定版本号需要满足的第二条件，所述第一条件不同于所述第二条件。

所述附加对象标识与所述目标对象标识是关联的或是相关的，例如，所述目标对象标识为版本标识，所述附加对象标识可以为与所述版本标识相关的中央处理器标识。

所述第四验证条件设定了与所述附加对象标识对应的附加对象值需要满足的条件，例如，所述附加对象标识为中央处理器标识，对应的附加对象值为中央处理器数值，所述第四验证条件中设定中央处理器数值需要满足的条件。

与所述第一验证条件类似，所述第三验证条件具体可以设定所述目标对象值的数据类型、所述目标对象值的长度、所述目标对象值的大小等需要满足预设的格式要求，所述第四验证条件具体可以设定所述附加对象值的数据类型、所述附加对象值的长度、所述附加对象值的大小等需要满足预设的格式要求。

在实际应用中，利用第三关键字如anyof的能力，可以兼容多个不同目标对象(如多个不同版本)制定不同的检测规则，避免了根据设备的不同目标对象如不同版本增加分支逻辑进行处理，从而降低了检测规则的维护难度。

在一些实施例中，如图9所示，所述利用所述第三验证条件对所述目标对象值进行验证，利用所述第四验证条件对所述附加对象值进行验证可以包括：

步骤s901：利用所述第三验证条件对所述目标对象值进行验证，其中，所述第三验证条件中包括至少一个所述第一验证项目子标识和至少一个第二验证子条件，所述第一验证项目子标识和所述第二验证子条件在所述第三验证条件中以键值对的形式进行描述；

步骤s903：在所述目标对象值通过所述第三验证条件中所有所述第二验证子条件的验证时，确定所述目标数据通过所述第三验证条件的验证；

步骤s905：利用第四验证条件对所述附加对象值进行验证，其中，所述第四验证条件中包括至少一个第二验证项目子标识和至少一个第三验证子条件，所述第二验证项目子标识和所述第三验证子条件在所述第四验证条件中以键值对的形式进行描述；

步骤s907：在所述附加对象值通过所述第四验证条件中所有所述第三验证子条件的验证时，确定所述目标数据通过所述第四验证条件的验证。

其中，所述第三验证条件中至少有一个所述第二验证子条件与所述第一验证子条件互补，例如，第一验证子条件设定为"maxmum":21，第二验证子条件则设定为"minimum":22。

与所述第一验证项目子标识类似，所述第二验证项目子标识可以包括：目标对象值的数据类型(对应的第三验证子条件可以为预设字符类型如字符串类型、整数类型等)、目标对象值的长度(对应的第三验证子条件可以为第二预设长度范围)、目标对象值的数值大小(对应的第三验证子条件可以为第一预设大小范围)等等。

例如，对于中央处理器信息的检测，如果低版本不需要检测，而高版本需要检测，则可以进行如下处理：

在上述jsonschema中，描述了对于版本为21的设备，不需要判断中央处理器信息，对于版本为22的设备，则需要进行中央处理器信息的检测。

其中，第一验证信息为："app_version":{"type":"integer","maxmum":21}，其中，app_version为版本标识(即目标对象标识)，{"type":"integer","maxmum":21}中的内容为与版本标识对应的第一验证条件，在第一验证条件中，type或maxmum为第一验证项目子标识，integer或21为与所述第一验证项目子标识对应的第一验证子条件；

第四验证信息为："app_version":{"type":"integer","minimum":22},"cpu":{"type":"string","minlength":1}，其中，app_version为版本标识(即目标对象标识)，{"type":"integer","minimum":22}中的内容为与版本标识对应的第三验证条件，cpu为中央处理器标识(即附加对象标识)，{"type":"string","minlength":1}中的内容为与中央处理器标识对应的第四验证条件；

在第三验证条件中，type或minimum为第一验证项目子标识，integer或22为与所述第一验证项目子标识对应的第二验证子条件；在第四验证条件中，type或minlength为第二验证项目子标识，string或1为与所述第二验证项目子标识对应的第三验证子条件。

在实际应用中，利用第三关键字如anyof的能力，可以兼容多个不同目标对象(如多个不同版本)制定不同的检测规则，避免了根据设备的不同目标对象如不同版本增加分支逻辑进行处理，从而降低了检测规则的维护难度；并且，通过对第一验证条件、第三验证条件和第四验证条件进行结构化的细化表达，使得在代码检测规则需要进行较小的变化时，例如，在只需要对某一个验证项目子标识对应的验证子条件进行改动时，用户可以根据验证项目子标识与验证子条件的对应关系，直接对相应的验证子条件进行改动，而无需对其余验证项目子标识或其余验证子条件做改动，从而可以大大提升代码检测规则变更的效率，并可以有效保证代码规则变更的安全性。

未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的方法。

本发明实施例还提供了一种设备出厂检测装置，请参见图10，所述装置包括：

信息采集模块1010，用于采集待出厂设备的设备信息，所述设备信息包括至少一个对象标识和至少一个与所述对象标识对应的对象值；

目标数据生成模块1020，用于将所述对象标识和所述对象值以键值对的形式组装成待验证的目标数据；

验证文件获取模块1030，用于从服务器中拉取最新更新的验证文件，所述验证文件为包括至少一个验证信息的集合，所述集合中的每个验证信息均以键值对的形式进行描述；

目标数据验证模块1040，用于利用所述验证文件对所述目标数据进行验证。

在一些实施例中，所述验证文件包括第一验证信息，所述第一验证信息包括目标对象标识和第一验证条件，相应的，所述目标数据验证模块可以包括：

第一查找子模块，从所述目标数据中查找与所述目标对象标识对应的目标对象值，其中，所述目标对象标识和所述第一验证条件在所述第一验证信息中以键值对的形式进行描述；

第一验证子模块，用于利用所述第一验证条件对所述目标对象值进行验证；

第一验证确认子模块，用于在所述目标对象值通过所述第一验证条件的验证时，确认所述目标数据通过所述验证文件的验证。

在一些实施例中，所述第一验证子模块可以包括：

第一验证单元，用于利用所述第一验证条件对所述目标对象值进行验证，其中，所述第一验证条件中包括至少一个第一验证项目子标识和至少一个第一验证子条件，所述第一验证项目子标识和所述第一验证子条件在所述第一验证条件中以键值对的形式进行描述；

第一验证确认单元，用于在所述目标对象值通过所述第一验证条件中所有所述第一验证子条件的验证时，确定所述目标数据通过所述第一验证条件的验证。

在一些实施例中，所述验证文件中还包括第二验证信息，所述第二验证信息中包括第一关键字和预设对象标识，相应的，所述目标数据验证模块还可以包括：

第二查找子模块，用于查询所述目标数据中是否包括所述预设对象标识，其中，所述第一关键字和所述预设对象标识在所述第二验证信息中以键值对的形式进行描述，所述第二验证信息通过所述第一关键字设定所述目标数据中的至少一个对象标识需要为预设对象标识；

第二验证文件验证确认子模块，用于在所述目标数据中包括所述预设对象标识时，确认所述目标数据通过所述验证文件的验证。

在一些实施例中，所述验证文件中还包括第三验证信息，相应的，所述目标数据验证模块还可以包括：

第三验证子模块，用于利用所述第三验证信息对所述目标数据进行验证，其中，所述第三验证信息中包括第二关键字和预设数据类型，所述第二关键字和所述预设数据类型在所述第三验证信息中以键值对的形式进行描述，所述第三验证信息通过所述第二关键字设定待验证的所述目标数据的数据类型需要为预设数据类型；

第三验证信息验证确认子模块，用于在所述目标数据的数据类型为所述预设数据类型时，确定所述目标数据通过所述第三验证信息的验证。

在一些实施例中，所述验证文件中还包括第四验证信息，所述第四验证信息和所述第一验证信息通过第三关键字关联，所述第四验证信息中包括所述目标对象标识、第三验证条件、第四验证条件以及与所述目标对象标识关联的附加对象标识，所述目标对象标识和所述第三验证条件在所述第四验证信息中以键值对的形式进行描述，所述附加对象标识和所述第四验证条件在所述第四验证信息中以键值对的形式进行描述，相应的，所述目标数据验证模块还可以包括：

第四验证子模块，用于利用所述第三验证条件对所述目标对象值进行验证，并从所述目标数据中查找与所述附加对象标识对应的附加对象值，利用所述第四验证条件对所述附加对象值进行验证；

第四验证信息验证确认子模块，用于在所述目标数据同时通过所述第三验证条件和所述第四验证条件的验证时，确定所述目标数据通过所述第四验证信息的验证；

第五验证文件验证子确认模块，用于在所述目标数据通过所述第一验证信息或所述第四验证信息的验证时，则确定与所述目标数据通过所述验证文件的验证。

在一些实施例中，所述第四验证子模块可以包括：

第三验证条件验证单元，用于利用所述第三验证条件对所述目标对象值进行验证，其中，所述第三验证条件中包括至少一个所述第一验证项目子标识和至少一个第二验证子条件，所述第一验证项目子标识和所述第二验证子条件在所述第三验证条件中以键值对的形式进行描述；

第三验证条件验证确认单元，用于在所述目标对象值通过所述第三验证条件中所有所述第二验证子条件的验证时，确定所述目标数据通过所述第三验证条件的验证；

第四验证条件验证单元，用于利用第四验证条件对所述附加对象值进行验证，其中，所述第四验证条件中包括至少一个第二验证项目子标识和至少一个第三验证子条件，所述第二验证项目子标识和所述第三验证子条件在所述第四验证条件中以键值对的形式进行描述；

第四验证条件验证确认单元，用于在所述附加对象值通过所述第四验证条件中所有所述第三验证子条件的验证时，确定所述目标数据通过所述第四验证条件的验证。

本实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如本实施例上述任一方法。

本实施例还提供了一种设备，其结构图请参见图11，该设备1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对设备中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在设备1100上执行存储介质1130中的一系列指令操作。设备1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm等等。本实施例上述的任一方法均可基于图11所示的设备进行实施。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本申请的范围。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。