CN112003976A - 硬编硬解测试方法及装置 - Google Patents

Abstract

本公开关于一种硬编硬解测试方法及装置，涉及测试技术领域。该方法包括：接收客户端发送的第一请求；响应于第一请求，向客户端发送基准配置信息或预存的目标名单；获取客户端的第一名单；第一名单是基于客户端的测试结果生成的；测试结果是客户端基于基准配置信息及目标名单测试确定的；根据第一名单更新目标名单。这种方式能够自动化完成硬编硬解测试，并自动完善目标名单，减少工作人员的工作量，提高测试的便利性。

Description

硬编硬解测试方法及装置

技术领域

本公开涉及测试技术领域，尤其涉及一种硬编硬解测试方法及装置。

背景技术

在电子设备中，经常存在需要进行编解码的场景，例如拍摄编码场景、编辑转码场景等，由于不同机型的电子设备的硬编硬解能力是不统一的，因此，在这些场景中，为了完成编解码的操作，需要首先确定电子设备的机型是否具有硬编硬解的能力，若电子设备的机型具有硬编硬解的能力，则采用硬编硬解的方式进行编解码，若电子设备的机型不具有硬编硬解的能力，则会采用软编软解的方式进行编解码。

在相关技术中，在确定一个机型的硬编硬解能力的过程中，需要由人工来构建机型硬编硬解的黑白名单，或者由人工控制设备进行硬编硬解测试，这种方式工作量大，不够便利。

发明内容

本公开提供一种硬编硬解测试方法、装置、服务器及介质，以至少解决相关技术中硬编硬解测试工作量大，不够便利的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种硬编硬解测试方法，应用于第一服务端，包括：

接收客户端发送的第一请求；

响应于所述第一请求，向所述客户端发送基准配置信息或预存的目标名单；

获取所述客户端的第一名单；所述第一名单是基于所述客户端的测试结果生成的；所述测试结果是所述客户端基于所述基准配置信息及所述目标名单测试确定的；

根据所述第一名单更新所述目标名单。

一种可选的实施例中，所述第一请求包括测试请求或目标名单获取请求。

一种可选的实施例中，所述向所述客户端发送基准配置信息之前，还包括：

基于所述第一请求为所述测试请求，读取预存的机型候选名单；

根据所述客户端的目标机型是否属于所述机型候选名单，确定所述目标机型对应的所述基准配置信息。

一种可选的实施例中，所述读取预存的机型候选名单，包括：

根据所述测试请求是否满足预设测试条件，确定是否读取所述机型候选名单；

基于所述测试请求满足所述预设测试条件，读取所述机型候选名单。

一种可选的实施例中，所述预设测试条件基于预设采样率和日活跃用户数量确定。

一种可选的实施例中，所述预设测试条件基于预设采样率和日活跃用户数量确定，包括：

根据所述日活跃用户数量与所述预设采样率的乘积，确定预设时长内的设备测试数量；

确定所述测试请求是否为所述预设时长内接收到的前N个测试请求，N为小于或等于所述设备测试数量的正整数；

基于所述测试请求为所述预设时长内接收到的前N个测试请求，确定所述测试请求满足所述预设测试条件。

一种可选的实施例中，所述根据所述客户端的目标机型是否属于所述机型候选名单，确定所述目标机型对应的所述基准配置信息，包括：

基于所述目标机型属于所述机型候选名单，确定所述机型候选名单中所述目标机型对应的配置规则，根据所述配置规则生成所述基准配置信息；

基于所述目标机型不属于所述机型候选名单，根据预存的默认配置信息生成所述基准配置信息。

一种可选的实施例中，还包括：

基于所述第一请求为所述目标名单获取请求，读取预设存储设备内保存的所述目标名单。

一种可选的实施例中，所述获取所述客户端的第一名单，包括：

定时向第二服务端发送名单获取请求；

接收所述第二服务端根据所述名单获取请求返回的所述第一名单；所述第一名单是所述第二服务端基于所述客户端的所述测试结果生成的。

一种可选的实施例中，包括：

所述客户端基于所述目标机型不属于所述目标名单，在冷启动后，根据所述基准配置信息进行所述硬编硬解基准测试，并将所述测试结果上传至所述第二服务端。

一种可选的实施例中，所述根据所述第一名单更新所述目标名单，包括：

在所述第一名单的第一版本信息高于所述目标名单的第二版本信息的情况下，根据所述第一名单更新所述目标名单。

一种可选的实施例中，所述目标名单包括以下至少一种：硬编硬解黑名单、硬编硬解白名单以及硬解芯片白名单。

根据本公开实施例的第二方面，提供一种硬编硬解测试装置，应用于第一服务端，包括：

第一接收模块，被配置为执行接收客户端发送的第一请求；

第一发送模块，被配置为执行响应于所述第一请求，向所述客户端发送基准配置信息或预存的目标名单；

第一名单获取模块，被配置为执行获取所述客户端的第一名单；所述第一名单是基于所述客户端的测试结果生成的；所述测试结果是所述客户端基于所述基准配置信息及所述目标名单测试生成的；

更新模块，被配置为执行根据所述第一名单更新所述目标名单。

一种可选的实施例中，所述装置还包括：

名单读取模块，被配置为执行基于所述第一请求为测试请求，读取预存的机型候选名单；

信息确定模块，被配置为执行根据所述客户端的目标机型是否属于所述机型候选名单，确定所述目标机型对应的所述基准配置信息。

一种可选的实施例中，所述名单读取模块被配置为执行：根据所述测试请求是否满足预设测试条件，确定是否读取所述机型候选名单；基于所述测试请求满足所述预设测试条件，读取所述机型候选名单。

一种可选的实施例中，所述名单读取模块被配置为具体执行：根据所述日活跃用户数量与所述预设采样率的乘积，确定预设时长内的设备测试数量；确定所述测试请求是否为所述预设时长内接收到的前N个测试请求，N为小于或等于所述设备测试数量的正整数；基于所述测试请求为所述预设时长内接收到的前N个测试请求，确定所述测试请求满足所述预设测试条件。

一种可选的实施例中，所述信息确定模块被配置为执行：基于所述目标机型属于所述机型候选名单，确定所述机型候选名单中所述目标机型对应的配置规则，根据所述配置规则生成所述基准配置信息；基于所述目标机型不属于所述机型候选名单，根据预存的默认配置信息生成所述基准配置信息。

一种可选的实施例中，所述装置还包括：

目标名单获取模块，被配置为执行基于所述第一请求为目标名单获取请求，读取预设存储设备内保存的所述目标名单。

一种可选的实施例中，所述第一名单获取模块被配置为执行：定时向第二服务端发送名单获取请求；接收所述第二服务端根据所述名单获取请求返回的所述第一名单；所述第一名单是所述第二服务端基于所述客户端的所述测试结果生成的。

一种可选的实施例中，所述更新模块具体被配置为执行：

在所述第一名单的第一版本信息高于所述目标名单的第二版本信息的情况下，根据所述第一名单更新所述目标名单。

根据本公开实施例的第三方面，提供一种服务器，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的硬编硬解测试方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由服务器的处理器执行时，服务器能够执行如第一方面所述的硬编硬解测试方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括程序或指令，以使程序或指令被执行时，实现如第一方面所述的硬编硬解测试方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本实施例中，在客户端需要确定自身机型的硬编硬解能力时，可以向第一服务端发送第一请求，第一服务端即会向客户端返回基准配置信息以及目标名单，在客户端会根据基准配置信息以及目标名单进行硬编硬解基准测试，后续第一服务端会获取基于测试结果生成的第一名单，并根据第一名单更新完善目标名单。可见，本实施例中，不需要人工进行参与，客户端仅需要向第一服务端发送第一请求，即能够完成硬编硬解基准测试，确定自身的硬编硬解能力，且第一服务端还能够根据测试结果不断完善目标名单，从而不断加大目标名单对机型的覆盖范围，这种方式减少了硬编硬解测试过程中工作人员的工作量，提高了测试的便利性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种硬编硬解测试***的框图。

图2是根据一示例性实施例示出的一种硬编硬解测试方法的架构图。

图3是根据一示例性实施例示出的一种生成基准配置信息的流程图。

图4是根据一示例性实施例示出的另一种硬编硬解测试方法的架构图。

图5是根据一示例性实施例示出的一种第一服务端侧的硬编硬解测试方法的流程图。

图6是根据一示例性实施例示出的一种硬编硬解测试装置的框图。

图7是根据一示例性实施例示出的一种服务器的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

随着电子设备的发展，电子设备的类型越来越丰富，不同的厂商、不同的芯片、不同的机型下的电子设备，其硬编硬解能力都有可能不同，因此，在电子设备需要进行编解码的场景下，例如消费端播放场景、编辑预览场景、拍摄编码场景、编辑转码场景等，需要首先确定电子设备的机型的硬编硬解能力。其中，这里的硬编指的是硬编码，即将数据直接嵌入到程序或其他可执行对象的源代码中的软件开发实践。硬解指的是硬解码，即通过硬件实现的解码。

本公开提供了一种硬编硬解测试***，参见图1所示，图1是根据一示例性实施例示出的一种硬编硬解测试***的框图。该***可以包括：第一服务端110、多个客户端120以及预设存储设备140。第一服务端110与客户端120通过网络进行通信连接。

其中，第一服务端110，可以用于基于客户端120的测试请求生成基准配置信息发送至客户端120，也可以用于基于客户端120的名单获取请求从预设存储设备140中获取目标名单发送给客户端120；还可以用于根据客户端120测试结果更新预设存储设备140中的目标名单。

可选的，上述第一服务端110可以为服务器或服务器集群等，具体的，第一服务端110可以为业务处理服务器。本公开不限定第一服务端110的具体类型。

客户端120可以用于向第一服务端110发送测试请求来获取基准配置信息，或者，客户端120还可以用于向第一服务端110发送名单获取请求来获取目标名单，例如目标名单为测试黑名单或测试白名单等。客户端120在获取基准配置信息和目标名单后，基于客户端120不属于该目标名单，则在客户端120冷启动后，基于基准配置信息可进行基准测试，并生成测试结果。

可选的，客户端120在执行硬编硬解基准测试时，具体可以是由客户端120中的目标应用程序执行硬编硬解基准测试操作，这里的目标应用程序可以为客户端120中需要进行编解码的应用程序，或者也可以为客户端120中专门设置的、用于进行硬编硬解基准测试的应用程序。

在一些实施例中，客户端120可以是可移动电子设备，如手机、pad、笔记本电脑、可穿戴智能设备等，或者也可以是非移动电子设备，如计算机等。本公开不限定客户端120的的具体类型。

预设存储设备140用于存储目标名单，例如，这里的预设存储设备140可以为分布式存储(Redis)或者其他存储设备等。该预设存储设备140可以设置于第一服务器110上，也可以独立存在。

为方便理解，以下以第一服务端110为服务器，客户端120为手机进行介绍。

手机向服务器发送第一请求，服务器接收到第一请求后，会将基准配置信息和目标名单发送给手机，若手机的型号不属于目标名单，则手机会根据基准配置信息进行硬编硬解基准测试，得到测试结果，后续服务器获取基于手机的测试结果生成的第一名单，并根据第一名单更新目标名单，从而将手机的型号是否具有硬编硬解能力的相关信息添加至目标名单中进行保存。

在一些实施例中，该***还可以包括第二服务端130。客户端120还用于将测试结果上报至第二服务端130。

第二服务端130可以用于接收客户端120上报的测试结果，并根据测试结果生成第一名单；基于第一服务端110发送的名单获取请求返回第一名单至第一服务端110。

其中，上述实施例中，根据测试结果生成第一名单的操作是由第二服务端130执行的，在其他实施例中，该操作也可以由第一服务端110执行，本公开对此不作限定。

可选的，上述第二服务端130可以为服务器或服务器集群等，具体的，第二客户端120可以为hive服务器，hive服务器是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的结构化查询语言(Structured QueryLanguage，SQL)查询功能。本公开不限定第二服务端130的具体类型。

在本公开的一个实施例中，以第一服务端110为服务器sever，第二服务端130为服务器hive，客户端120为手机，第一名单包括硬解白名单hive表和硬编白名单hive表进行介绍。

手机向服务器sever发送第一请求，服务器sever接收到第一请求后，会将基准配置信息和目标名单发送给手机，若手机的型号不属于目标名单，则手机会根据基准配置信息进行硬编硬解基准测试，得到测试结果hive表，并将测试结果hive表上报服务器hive，服务器hive根据测试结果生成硬解白名单hive表和硬编白名单hive表。后续服务器sever定时获取硬解白名单hive表和硬编白名单hive表，并根据硬解白名单hive表和硬编白名单hive表更新目标名单，从而将手机的型号是否具有硬编硬解能力的相关信息添加至目标名单中进行保存。

基于上述硬编硬解测试***，本公开还提供了一种硬编硬解测试方法，图2是根据一示例性实施例示出的一种硬编硬解测试方法的架构图，如图2所示，该方法包括以下步骤。

客户端向第一服务端发送第一请求。

其中，这里的第一请求可以包括测试请求或目标名单获取请求。测试请求是用于向第一服务端请求基准配置信息的，目标名单获取请求是用于向第一服务端请求目标名单的。客户端可以同时向第一服务端发送测试请求和目标名单获取请求，或者也可以顺序发送，即首先发送测试请求，接收第一服务端返回的基准配置信息后再发送目标名单获取请求，或者也可以首先发送目标名单获取请求，接收第一服务端返回的目标名单后，根据目标名单选择是否发送测试请求等。在一些实施例中，测试请求和目标名单获取请求中还可以包括客户端的目标型号以及自身的标识信息等，例如自身的硬件标识符以及IP地址等，方便第一服务端通过通信连接返回信息至客户端。

此外，客户端可以在接收到用户的测试输入的情况下，向第一服务端发送第一请求；或者，也可以在客户端运行的程序场景需要利用硬编能力或硬解能力的情况下，客户端自动向第一服务端发送第一请求。

第一服务端响应于第一请求，向客户端发送基准配置信息或预存的目标名单。

在一些实施例中，第一服务端根据第一请求的信息执行不同的操作，具体操作如下：

第一服务端基于第一请求为测试请求，向所述客户端发送基准配置信息。其中，基准配置信息是用于供客户端完成硬编硬解基准测试的信息。基准配置信息至少可以包括以下信息中的一种或多种：硬编硬解基准测试需要依赖的最小客户端版本、采样率、自动化硬编测试版本信息、自动化硬解测试版本信息、高级视频编码(Advanced Video Coding，AVC)-MCS硬解测试使能信息、AVC-MCBB硬解测试使能信息、高效率视频编码(HighEfficiency Video Coding，HEVC)-MCS硬编测试使能信息、HEVC-MCBB硬解测试使能信息、最大解码数及其他可用于客户端硬编硬解基准测试的信息。在一些实施例中，采样率用于控制测试设备数。自动化硬编测试版本信息和所述自动化硬解测试版本信息分别用于进行强制硬编测试和强制硬解测试。AVC-MCS硬解测试使能信息用于开启AVC硬解Surface(MediaCodec Surface，MCS)测试，AVC-MCBB硬解测试使能信息用于开启AVC硬解Bytebuffer(MediaCodec Bytebuffer，MCBB)测试。HEVC-MCS硬编测试使能信息用于开启HEVC硬解MCS测试，HEVC-MCBB硬解测试使能信息用于开启HEVC硬解MCBB测试。其中，AVC为h264格式的视频，HEVC指的是h265格式的视频，h264和h265指的是两种压缩编码方式。其中，MediaCodec指的是用于对音视频进行编解码的类，Surface是MediaCodec支持的一种数据类型。

另外，第一服务端基于第一请求为目标名单获取请求，向客户端发送预存的目标名单。在一些实施例中，响应于第一请求为目标名单获取请求，第一服务端读取预设存储设备内保存的目标名单，并将目标名单发送至客户端。在一些实施例中，上述目标名单可以包括以下至少一种：硬编硬解黑名单、硬编硬解白名单以及硬解芯片白名单。

可选的，客户端发送的目标名单获取请求中，可以包括想要获取的目标名单的类型，第一服务端可以根据目标名单获取请求中携带的目标名单的类型，从分布式存储中有针对性的获取对应类型的目标名单。基于此，使得客户端可以仅获取自己需要的名单，而不需要获取全部类型的名单，减少了第一服务端与客户端之间的数据传输量。例如，目标名单获取请求中包括硬编硬解黑名单的标识，则第一服务端仅从Redis中获取硬编硬解黑名单返回客户端。

在其他实施例中，客户端发送的目标名单获取请求中，也可以仅限定获取白名单还是黑名单，若获取白名单，则将全部类型的白名单(即硬编硬解白名单以及硬解芯片白名单)均发送至客户端。或者，客户端也可以不能选择目标名单的类型，第一服务端会将全部类型的目标名单返回客户端，这种方式能够保证客户端能够尽可能了解自身的硬编硬解能力，减少客户端的测试次数。

在另一些实施例中，第一服务端在获取读取目标名单之后，向客户端发送目标名单之前，还可以包括：第一服务端根据目标名单构建硬件配置信息(HardwareConfig)。

本实施例中，第一服务端能够根据客户端的目标名单获取请求以及读取的目标名单，生成硬件配置信息，硬件配置信息可以包括客户端的目标机型以及该目标机型是否处于黑名单中以及是否处于白名单等。这种情况下，使得客户端在接收到硬件配置信息后，能够直接了解自身是否处于黑白名单，而不需要客户端再进行判断，提高了客户端的便利性。例如，硬件配置信息可以包括：机型xxxx；是否处于硬解硬编黑名单：否；是否处于硬编硬解白名单：是；是否处于硬解芯片白名单：否。当然，本公开不限定硬件配置信息中包含的具体内容信息。

客户端基于基准配置信息及目标名单确定硬编硬解基准测试的测试结果。

在一些实施例中，客户端根据目标名单能够确定自身的目标机型是否在目标名单中，若在目标名单中，则客户端可以直接根据目标名单中的信息确定自身机型的硬编硬解能力，后续不需要再进行硬编硬解基准测试，从而简化测试次数，使得已经测试过的机型能够共享测试结果，而不需要每台设备均进行硬编硬解基准测试。若目标机型不在目标名单中，则客户端需要根据基准配置信息完成硬编硬解基准测试，得到测试结果。例如，目标名单包括硬编白名单，则若目标机型处于硬编白名单的话，则客户端能够直接确定自身机型具有硬编能力，因此不再需要进行硬编测试。反之，若目标名单包括硬解黑名单，若目标机型处理硬解黑名单，则客户端能够直接确定自身机型不具有硬解能力，因此也不需要再进行硬解测试。

在一些实施例中，客户端基于目标机型不属于目标名单，则客户端无法确定自身目标机型的硬编硬解能力，因此客户端在冷启动后，需要根据基准配置信息进行硬编硬解基准测试，得到测试结果。在具体实施例中，客户端在冷启动后，客户端的***空闲时，启动测试服务，根据基准配置信息进行硬编硬解基准测试，这种情况能够避免硬编硬解能力对客户端的其他功能造成影响。

在另一些实施例中，若客户端会将自身硬编硬解的测试结果保存至本地，则客户端会基于目标机型不属于目标名单且本地无测试结果，在冷启动后，根据基准配置信息进行硬编硬解基准测试。即客户端只有在自身机型不属于目标名单且本地也没有测试结果的情况下，才进行硬编硬解基准测试，从而进一步减少了测试的次数。

其中，上述硬编硬解基准测试可以包括多个测试阶段。可选的，可以包括5个测试阶段，AVC硬解MCS测试、AVC硬解MCBB测试、HEVC硬解MCS测试、HEVC硬解MCBB测试、AVC硬编测试。这里的每个阶段都可以被打断，如果其中一个阶段被打断，则本次测试终止，下次冷启后，再继续开始剩余阶段的测试。在一些实施例中，测试终止后，在下次冷启动时，也可以重新进行整个硬编硬解基准测试。

可选的，客户端的测试结果是指在客户端进行冷启动后进行硬编硬解基准测试生成的测试结果。客户端在生成测试结果后，可以将测试结果保存至本地，并且可以将测试结果直接发送至第一服务器，或者可以根据测试结果生成第一名单。本公开对此不作限定。

第一服务端获取客户端的第一名单。

其中，第一名单包括但不限于客户端的硬编能力信息和硬解能力信息。第一名单可以包括以下至少一项：硬解白名单hive表和、硬编白名单hive表、硬解黑名单hive表、硬编黑名单hive表以及硬解芯片白名单hive表。例如，客户端的目标机型处于硬解白名单hive表，则表明目标机型具有硬编能力。

在一些实施例中，第一服务端可以直接获取客户端的测试结果，并根据测试结果生成第一名单。或者在客户端自己生成第一名单的情况下，第一服务端可以直接获取客户端生成的第一名单。

第一服务端根据第一名单更新目标名单。

更新的方式可以是第一服务端直接将第一名单中包含的信息添加至目标名单中的对应名单内。例如，第一名单包括硬解白名单hive表的情况下，则直接将硬解白名单hive表中的信息添加至目标名单中的硬解白名单中。

由于之前的目标名单中不包括客户端的目标机型的硬编硬解能力信息，因此在客户端完成硬编硬解测试后，需要依据测试结果对目标名单进行更新，使得更新后的目标名单中包括目标机型的硬编硬解能力信息。通过这种方式不断完善目标名单，使得后续与客户端同机型的设备进行硬编硬解测试时，即能够直接根据目标名单了解自身的硬编硬解能力，而不再需要进行测试，从而实现了测试结果共享的目的。

在一些实施例中，第一服务端在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，根据第一名单更新目标名单。其中，第一名单还包括第一版本信息，该第一版本信息为生成第一名单时生成的，第一版本信息用于表征第一名单中的名单信息的版本。

本实施例中，第一服务端在利用第一名单更新目标名单时，也会利用第一名单的第一版本信息更新目标名单的第二版本信息，例如第一名单的第一版本信息为01，目标名单原本的第二版本信息为01，则更新后，目标名单的第二版本信息为02。因此，只有在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，才表明第一名单比目标名单要新，因此能够根据第一名单更新目标名单。这种设置版本信息的方式，避免了重复更新目标名单，或者利用旧数据错误更新目标名单的情况出现，保证了目标名单的准确性。

结合上述实施例，参见图3，图3是根据一示例性实施例示出的另一种硬编硬解测试方法的架构图。本公开提供的硬编硬解测试方法可以包括：

客户端向第一服务端发送测试请求。

第一服务端响应于第一请求，向客户端发送基准配置信息。

客户端向第一服务端发送目标名单获取请求。

上述部分与图2描述的方案类似，为避免重复，在此不再赘述。

第一服务端读取预设存储设备内保存的目标名单，并发送目标名单至客户端。

其中，预设存储设备用于存储目标名单，这里的预设存储设备可以为分布式存储(Redis)或者其他存储设备等。该预设存储设备可以设置于第一服务器上，也可以独立存在。

客户端基于目标机型不属于目标名单，在冷启动后，根据基准配置信息进行硬编硬解基准测试。

客户端将测试结果上传至第二服务端。

即客户端在生成测试结果后，可以将测试结果上传第二服务端，第二服务端指的是用于获取测试结果并生成第一名单的服务端。例如，第二服务端可以为hive服务器。

第二客户端基于测试结果生成第一名单。

第二服务端基于客户端上报的测试结果生成第一名单。其中，第二服务端可以将客户端上报的测试结果保存至测试结果hive表中，之后定时从测试结果hive表中读取信息生成第一名单，这里的第一名单可以包括硬解白名单hive表和/或硬编白名单hive表等，或者第一名单还可以包括以下至少一项：硬解白名单hive表和、硬编白名单hive表、硬解黑名单hive表、硬编黑名单hive表以及硬解芯片白名单hive表。

第一服务端定时向第二服务端发送名单获取请求。

其中，第一服务端可以每隔预设时长向第二服务端发送名单获取请求，例如，每隔3小时向第二服务端发送名单获取请求。或者第一服务端也可以在固定时刻向第二服务端发送名单获取请求，例如每天12点向第二服务端发送名单获取请求。

第二服务端根据名单获取请求返回的第一名单至第一服务端。

这种情况下，不需要第一服务端来生成第一名单，而是由第二服务端根据客户端的测试结果生成第一名单，从而简化了第一服务端的工作内容，使得第一服务端与第二服务端能够分工合作。

在一些实施例中，第二服务端在生成第一名单时，还可以为第一名单生成第一版本信息，例如第一版本号。第一版本信息越新，则第一版本信息越大。例如上一次生成的第一名单的第一版本信息为01，本次生成的第一名单的第一版本信息为02。同样，目标名单也设置有对应的第二版本信息，第二版本信息与第一版本信息采用相同的编码方式，即目标名单越新，第二版本信息越大。这里的版本信息能够记录第一名单和目标名单内数据产生的先后顺序，从而避免出现利用第一名单重复更新目标名单的情况，保证了目标名单的准确性。

第一服务端根据第一名单更新目标名单。该部分与图2描述的方案类似，为避免重复，在此不再赘述。

本实施例中，仅在客户端的目标机型不属于目标名单的情况下才进行硬编硬解基准测试，减少了设备的测试次数，且使客户端能够快速了解自身的硬编硬解能力。并且，第一服务端能够根据客户端的机型为其准确的分配合适的基准配置信息，使得客户端能够执行满足自身需求的硬编硬解基准测试。此外，第一服务端还能够根据客户单的测试结果对目标名单进行更新，保证了后续其他相同型号的客户端不再需要进行相同的测试，实现了测试结果对于同型号设备的共享。本实施例能够自动化进行，不需要人工参与，减少了工作人员的工作量，提高了测试效率。

基于上述实施例，在一些具体实现方式中，参见图4，图4是根据一示例性实施例示出的一种生成基准配置信息的流程图。上述第一服务端响应于第一请求，向客户端发送基准配置信息，可以包括以下步骤。

在步骤S410中，第一服务端基于第一请求为测试请求，读取预存的机型候选名单(Benchmark Candidate)。

这里的机型候选名单指的是预先设定的、待测试的一些机型的名单，并且预先为这些名单中的机型设置有对应的基准配置信息，以及一些测试时的特殊要求等。

在一些实现方式中，上述读取预存的机型候选名单，可以包括：

第一服务端根据测试请求是否满足预设测试条件，确定是否读取机型候选名单；

第一服务端基于测试请求满足预设测试条件，读取机型候选名单。

本实现方式中，设置了预设测试条件，只有满足预设测试条件的情况下，才读取机型候选名单，并下发基准配置信息。若不满足预设测试条件，则不能读取机型候选名单，也不能下发基准配置信息，即此时客户端不能进行硬编硬解基准测试。这种情况下，能够对进行硬编硬解基准测试的客户端进行一定的限制，例如对客户端的型号进行限制，仅满足特定型号的客户端能够进行硬编硬解基准测试，或者对第一服务端接收到的测试请求的数量进行限制等，这种限制能够对客户端或者第一服务端起到一定的保护作用，具体的预设测试条件可以根据实际需求进行设置。

在一种实现方式中，上述预设测试条件基于预设采样率和日活跃用户数量确定。这里的预设采样率可以为kpn纬度的采样率，预设采样率用于控制进行硬编硬解基准测试的设备的数量。预设采样率的数值为预先设置的固定值，该数值不会自行发生改变，例如可以为0.08，预设采样率可根据第一服务端的实际情况进行设定。日活跃用户数量(DailyActive User，DAU)可以由第一服务端向需要客户端中的目标应用程序对应的业务服务端获取。DAU会自行发生变化，因此为了保证准确性，可以每隔特定时长，例如24个小时，即向业务服务端获取一次DAU。这种方式能够根据每日执行业务的用户数量来确定是否允许客户端执行硬编硬解测试请求，考虑到了第一服务端的工作能力，避免给第一服务端造成过大的工作压力。

在另一具体实现方式中，上述预设测试条件基于预设采样率和日活跃用户数量确定，可以包括：

第一服务端根据日活跃用户数量与预设采样率的乘积，确定预设时长内的设备测试数量；

第一服务端确定测试请求是否为预设时长内接收到的前N个测试请求，N为小于或等于设备测试数量的正整数；

第一服务端基于测试请求为预设时长内接收到的前N个测试请求，确定测试请求满足预设测试条件。

本实现方式中，通过日活跃用户数量与预设采样率的乘积，能够了解到预设时长内允许多少台设备进行硬编硬解基准测试，即仅限制当日活跃的总设备中一定比例的设备能够进行硬编硬解基准测试。因此，若客户端发送的测试请求属于前N个，则允许客户端进行硬编硬解基准测试。这种方式能够限定预设时长内进行硬编硬解基准测试的设备数量，降低第一服务端的工作压力。

举例来看，例如，当日获取到的日活跃用户数量为10000，预设采样率为0.08，则设备测试数量＝10000*0.08＝800，预设时长为1天，则仅当天接收到的前800个测试请求对应的客户端能够进行硬编硬解基准测试，其他测试请求对应的客户端即不能进行硬编硬解基准测试。

在步骤S420中，第一服务端确定目标机型是否属于机型候选名单。

在步骤S430中，第一服务端基于目标机型属于机型候选名单，确定机型候选名单中目标机型对应的配置规则，根据配置规则生成基准配置信息(Benchmark Config)。

在步骤S440中，第一服务端基于目标机型不属于机型候选名单，根据预存的默认配置信息生成基准配置信息。

在本实现方式中，对于机型候选名单中的各个机型，预先设置有对应的配置规则，若目标机型属于机型候选名单，则按照对应的配置规则生成相匹配的基准配置信息，若目标机型不属于机型候选名单，则直接按照通用的默认配置信息作为基准配置信息。由于不同机型需要测试的性能可能不同，例如机型1仅需要测试硬编能力，机型2仅需要测试硬解能力，则机型1对应的基准配置信息仅需要包括硬编配置信息即可，机型2同理。这种方式不仅能够满足特定机型的特殊测试需求，并且能够避免客户端执行一些不必要的测试内容，提高了测试的针对性和测试效率。机型候选名单可由工作人员预先编辑后保存至第一服务端内，或者保存至与第一服务端连接的存储设备内，后续工作人员可根据需求对机型候选名单进行编辑。

在一些实施例中，在第一服务端接收到第一名单后，还可以将客户端的目标机型从机型候选名单中删除，使得后续工作人员不需要手动删除测试完成的机型，简化了工作人员的操作。

基于上述硬编硬解测试方法，以下对第一服务端的具体工作内容进行介绍，其中部分内容已在上述方法实施例中进行阐述，因此在后续第一服务端的工作内容介绍中，不再重复介绍。图5是根据一示例性实施例示出的一种第一服务端侧的硬编硬解测试方法的流程图，该方法包括以下步骤。

在步骤S510中，第一服务端接收客户端发送的第一请求。

其中，这里的第一请求可以包括测试请求或目标名单获取请求。客户端可以同时向第一服务端发送测试请求和目标名单获取请求，或者也可以顺序发送，即首先发送测试请求，接收第一服务端返回的基准配置信息后再发送目标名单获取请求，或者也可以首先发送目标名单获取请求，接收第一服务端返回的目标名单后，根据目标名单选择是否发送测试请求等。在一些实施例中，测试请求和目标名单获取请求中还可以包括客户端的目标型号以及自身的标识信息等，例如自身的硬件标识符以及IP地址等，方便第一服务端通过通信连接返回信息至客户端。

在步骤S520中，第一服务端基于第一请求为测试请求，向客户端发送基准配置信息。

基准配置信息至少可以包括以下信息中的一种或多种：硬编硬解基准测试需要依赖的最小客户端版本、采样率、自动化硬编测试版本信息、自动化硬解测试版本信息、AVC-MCS硬解测试使能信息、AVC-MCBB硬解测试使能信息、HEVC-MCS硬编测试使能信息、HEVC-MCBB硬解测试使能信息、最大解码数及其他可用于客户端硬编硬解基准测试的信息。

在步骤S530中，第一服务端基于第一请求为目标名单获取请求，向客户端发送预存的目标名单。

在一些实施例中，响应于第一请求为目标名单获取请求，第一服务端读取预设存储设备内保存的目标名单，并将目标名单发送至客户端。在一些实施例中，上述目标名单可以包括以下至少一种：硬编硬解黑名单、硬编硬解白名单以及硬解芯片白名单。

可选的，客户端发送的目标名单获取请求中，可以包括想要获取的目标名单的类型，第一服务端可以根据目标名单获取请求中携带的目标名单的类型，从分布式存储中有针对性的获取对应类型的目标名单。

其中，步骤S520和S530可以并行执行，也可以顺序执行，本公开不限定这两个步骤的先后顺序。

在步骤S540中，第一服务端获取客户端的第一名单；第一名单是基于客户端的测试结果生成的；测试结果是客户端基于基准配置信息及目标名单测试确定的。

在一些实施例中，第一服务端可以直接获取客户端的测试结果，并根据测试结果生成第一名单。或者在客户端自己生成第一名单的情况下，第一服务端可以直接获取客户端生成的第一名单。

在步骤S550中，第一服务端根据第一名单更新目标名单。

更新的方式可以是第一服务端直接将第一名单中包含的信息添加至目标名单中的对应名单内。

本实施例中，在客户端需要确定自身机型的硬编硬解能力时，可以向第一服务端发送第一请求，第一服务端即会向客户端返回基准配置信息以及目标名单，在客户端会根据基准配置信息以及目标名单进行硬编硬解基准测试，后续第一服务端会获取基于测试结果生成的第一名单，并根据第一名单更新完善目标名单。可见，本实施例中，不需要人工进行参与，客户端仅需要向第一服务端发送第一请求，即能够完成硬编硬解基准测试，确定自身的硬编硬解能力，且第一服务端还能够根据测试结果不断完善目标名单，从而不断加大目标名单对机型的覆盖范围，这种方式减少了硬编硬解测试过程中工作人员的工作量，提高了测试的便利性。

在一些实施例中，S520中，第一服务端向客户端发送基准配置信息之前，还可以包括：

第一服务端基于第一请求为测试请求，读取预存的机型候选名单；

第一服务端根据客户端的目标机型是否属于机型候选名单，确定目标机型对应的基准配置信息。

本实施例中，处于机型候选名单内的机型与未处于机型候选名单内的机型，其对应的基准配置信息可能不同。这种情况下，即能够保证在自动化测试的过程中，也能够保证完成对于部分机型的一些特殊的测试要求，提高测试效果。机型候选名单可由工作人员预先编辑后保存至第一服务端内，或者保存至与第一服务端连接的存储设备内，后续工作人员可根据需求对机型候选名单进行编辑。

基于上述实施例，在一些具体实现方式中，上述读取预存的机型候选名单，可以包括：

第一服务端根据测试请求是否满足预设测试条件，确定是否读取机型候选名单；

第一服务端基于测试请求满足预设测试条件，读取机型候选名单。

本实现方式中，设置了预设测试条件，只有满足预设测试条件的情况下，才读取机型候选名单，并下发基准配置信息。若不满足预设测试条件，则不能读取机型候选名单，也不能下发基准配置信息，即此时客户端不能进行硬编硬解基准测试。这种情况下，能够对进行硬编硬解基准测试的客户端进行一定的限制，例如对客户端的型号进行限制，仅满足特定型号的客户端能够进行硬编硬解基准测试，或者对第一服务端接收到的测试请求的数量进行限制等，这种限制能够对客户端或者第一服务端起到一定的保护作用。

可选的，上述预设测试条件基于预设采样率和日活跃用户数量确定。这种方式能够根据每日执行业务的用户数量来确定是否允许客户端执行硬编硬解测试请求，考虑到了第一服务端的工作能力，避免给第一服务端造成过大的工作压力。

在具体实施例中，上述预设测试条件基于预设采样率和日活跃用户数量确定，可以包括：

第一服务端根据日活跃用户数量与预设采样率的乘积，确定预设时长内的设备测试数量；

第一服务端确定测试请求是否为预设时长内接收到的前N个测试请求，N为小于或等于设备测试数量的正整数；

第一服务端基于测试请求为预设时长内接收到的前N个测试请求，确定测试请求满足预设测试条件。

本实施例中，通过日活跃用户数量与预设采样率的乘积，能够了解到预设时长内允许多少台设备进行硬编硬解基准测试，即仅限制当日活跃的总设备中一定比例的设备能够进行硬编硬解基准测试。因此，若客户端发送的测试请求属于前N个，则允许客户端进行硬编硬解基准测试。这种方式能够限定预设时长内进行硬编硬解基准测试的设备数量，降低第一服务端的工作压力。

在一些实施例中，上述第一服务端根据客户端的目标机型是否属于机型候选名单，确定目标机型对应的基准配置信息，可以包括：

第一服务端基于目标机型属于机型候选名单，确定机型候选名单中目标机型对应的配置规则，根据配置规则生成基准配置信息；

第一服务端基于目标机型不属于机型候选名单，根据预存的默认配置信息生成基准配置信息。

在本实现方式中，对于机型候选名单中的各个机型，预先设置有对应的配置规则，若目标机型属于机型候选名单，则按照对应的配置规则生成相匹配的基准配置信息，若目标机型不属于机型候选名单，则直接按照通用的默认配置信息作为基准配置信息。由于不同机型需要测试的性能可能不同。这种方式不仅能够满足特定机型的特殊测试需求，并且能够避免客户端执行一些不必要的测试内容，提高了测试的针对性和测试效率。

在另一些实施例中，S530中，第一服务端基于第一请求为目标名单获取请求，向客户端发送目标名单之前，该方法还包括：第一服务端读取预设存储设备内保存的目标名单。

本实施例中，目标名单保存至预设存储设备内，这种方式能够避免目标名单占用第一服务端的存储空间，且这种单独存储的方式，也方便了其他设备对目标名单进行访问。

在另一些实施例中，上述S540可以包括：

第一服务端定时向第二服务端发送名单获取请求；其中，第一服务端可以每隔预设时长向第二服务端发送名单获取请求，例如，每隔3小时向第二服务端发送名单获取请求。或者第一服务端也可以在固定时刻向第二服务端发送名单获取请求，例如每天12点向第二服务端发送名单获取请求。

第一服务端接收第二服务端根据名单获取请求返回的第一名单；第一名单是第二服务端基于客户端的测试结果生成的。

在本实施例中，不需要第一服务端来生成第一名单，而是由第二服务端根据客户端的测试结果生成第一名单，从而简化了第一服务端的工作内容，使得第一服务端与第二服务端能够分工合作。

在又一些实施例中，上述S550可以包括：

第一服务端在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，根据第一名单更新目标名单。

本实施例中，第二服务端在生成第一名单时，还会为第一名单生成第一版本信息，例如第一版本号，第一版本信息越新，则第一版本信息越大。同样，目标名单也设置有对应的第二版本信息，第二版本信息与第一版本信息采用相同的编码方式，即目标名单越新，第二版本信息越大。第一服务端在利用第一名单更新目标名单时，也会利用第一名单的第一版本信息更新目标名单的第二版本信息。因此，只有在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，才表明第一名单比目标名单要新，因此能够根据第一名单更新目标名单。这种设置版本信息的方式，避免了重复更新目标名单，或者利用旧数据错误更新目标名单的情况出现，保证了目标名单的准确性。

基于相同的发明构思，本公开实施例还提供了一种硬编硬解测试装置，该装置应用于第一服务端。图6是根据一示例性实施例示出的一种硬编硬解测试装置框图。参照图6，该装置包括第一接收模块610、第一发送模块620、第一名单获取模块630、更新模块640。

第一接收模块610，被配置为执行接收客户端发送的第一请求。

其中，这里的第一请求可以包括测试请求或目标名单获取请求。测试请求是用于向第一服务端请求基准配置信息的，目标名单获取请求是用于向第一服务端请求目标名单的。客户端可以同时向第一服务端发送测试请求和目标名单获取请求，或者也可以顺序发送，即首先发送测试请求，接收第一服务端返回的基准配置信息后再发送目标名单获取请求，或者也可以首先发送目标名单获取请求，接收第一服务端返回的目标名单后，根据目标名单选择是否发送测试请求等。在一些实施例中，测试请求和目标名单获取请求中还可以包括客户端的目标型号以及自身的标识信息等，例如自身的硬件标识符以及IP地址等，方便第一服务端通过通信连接返回信息至客户端。

第一发送模块620，被配置为执行响应于第一请求，向客户端发送基准配置信息或预存的目标名单。

具体的，基于第一请求为测试请求，生成基准配置信息，并向客户端发送基准配置信息。基于第一请求为目标名单获取请求，向客户端发送预存的目标名单。

第一名单获取模块630，被配置为执行获取客户端的第一名单；第一名单是基于客户端的测试结果生成的；测试结果是客户端基于基准配置信息及目标名单测试生成的。

在一些实施例中，第一服务端可以直接获取客户端的测试结果，并根据测试结果生成第一名单。或者在客户端自己生成第一名单的情况下，第一服务端可以直接获取客户端生成的第一名单。

更新模块640，被配置为执行根据第一名单更新目标名单。

更新的方式可以是第一服务端直接将第一名单中包含的信息添加至目标名单中的对应名单内。

本实施例中，在客户端需要确定自身机型的硬编硬解能力时，可以向第一服务端发送第一请求，第一服务端即会向客户端返回基准配置信息以及目标名单，在客户端会根据基准配置信息以及目标名单进行硬编硬解基准测试，后续第一服务端会获取基于测试结果生成的第一名单，并根据第一名单更新完善目标名单。可见，本实施例中，不需要人工进行参与，客户端仅需要向第一服务端发送第一请求，即能够完成硬编硬解基准测试，确定自身的硬编硬解能力，且第一服务端还能够根据测试结果不断完善目标名单，从而不断加大目标名单对机型的覆盖范围，这种方式减少了硬编硬解测试过程中工作人员的工作量，提高了测试的便利性。

在一些实施例中，该装置还可以包括：

名单读取模块，被配置为执行基于第一请求为测试请求，读取预存的机型候选名单；

信息确定模块，被配置为执行根据客户端的目标机型是否属于机型候选名单，确定目标机型对应的基准配置信息。

本实施例中，处于机型候选名单内的机型与未处于机型候选名单内的机型，其对应的基准配置信息可能不同。这种情况下，即能够保证在自动化测试的过程中，也能够保证完成对于部分机型的一些特殊的测试要求，提高测试效果。机型候选名单可由工作人员预先编辑后保存至第一服务端内，或者保存至与第一服务端连接的存储设备内，后续工作人员可根据需求对机型候选名单进行编辑。

基于上述实施例，在一些具体实现方式中，上述名单读取模块可以被配置为执行：

根据测试请求是否满足预设测试条件，确定是否读取机型候选名单；基于测试请求满足预设测试条件，读取机型候选名单。

本实现方式中，设置了预设测试条件，只有满足预设测试条件的情况下，才读取机型候选名单，并下发基准配置信息。若不满足预设测试条件，则不能读取机型候选名单，也不能下发基准配置信息，即此时客户端不能进行硬编硬解基准测试。这种情况下，能够对进行硬编硬解基准测试的客户端进行一定的限制，例如对客户端的型号进行限制，仅满足特定型号的客户端能够进行硬编硬解基准测试，或者对第一服务端接收到的测试请求的数量进行限制等，这种限制能够对客户端或者第一服务端起到一定的保护作用。

在一些实施例中，上述条件确定单元可以被配置为执行：

根据日活跃用户数量与预设采样率的乘积，确定预设时长内的设备测试数量；确定测试请求是否为预设时长内接收到的前N个测试请求，N为小于或等于设备测试数量的正整数；基于测试请求为预设时长内接收到的前N个测试请求，确定测试请求满足预设测试条件。

本实施例中，通过日活跃用户数量与预设采样率的乘积，能够了解到预设时长内允许多少台设备进行硬编硬解基准测试，即仅限制当日活跃的总设备中一定比例的设备能够进行硬编硬解基准测试。因此，若客户端发送的测试请求属于前N个，则允许客户端进行硬编硬解基准测试。这种方式能够限定预设时长内进行硬编硬解基准测试的设备数量，降低第一服务端的工作压力。

在一些实施例中，上述信息确定模块可以被配置为执行：

基于目标机型属于机型候选名单，确定机型候选名单中目标机型对应的配置规则，根据配置规则生成基准配置信息；基于目标机型不属于机型候选名单，根据预存的默认配置信息生成基准配置信息。

在本实现方式中，对于机型候选名单中的各个机型，预先设置有对应的配置规则，若目标机型属于机型候选名单，则按照对应的配置规则生成相匹配的基准配置信息，若目标机型不属于机型候选名单，则直接按照通用的默认配置信息作为基准配置信息。由于不同机型需要测试的性能可能不同。这种方式不仅能够满足特定机型的特殊测试需求，并且能够避免客户端执行一些不必要的测试内容，提高了测试的针对性和测试效率。

在另一些实施例中，该装置还可以包括：

目标名单获取模块，被配置为执行基于第一请求为目标名单获取请求，读取预设存储设备内保存的目标名单。

本实施例中，目标名单保存至预设存储设备内，这种方式能够避免目标名单占用第一服务端的存储空间，且这种单独存储的方式，也方便了其他设备对目标名单进行访问。

在另一些实施例中，上述第一名单获取模块630可以被配置为执行：

定时向第二服务端发送名单获取请求；接收第二服务端根据名单获取请求返回的第一名单；第一名单是第二服务端基于客户端的测试结果生成的。

其中，第一服务端可以每隔预设时长向第二服务端发送名单获取请求，例如，每隔3小时向第二服务端发送名单获取请求。或者第一服务端也可以在固定时刻向第二服务端发送名单获取请求。

在本实施例中，不需要第一服务端来生成第一名单，而是由第二服务端根据客户端的测试结果生成第一名单，从而简化了第一服务端的工作内容，使得第一服务端与第二服务端能够分工合作。

在又一些实施例中，上述更新模块640具体可以被配置为执行：

在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，根据第一名单更新目标名单。

本实施例中，第二服务端在生成第一名单时，还会为第一名单生成第一版本信息，例如第一版本号，第一版本信息越新，则第一版本信息越大。同样，目标名单也设置有对应的第二版本信息，第二版本信息与第一版本信息采用相同的编码方式，即目标名单越新，第二版本信息越大。第一服务端在利用第一名单更新目标名单时，也会利用第一名单的第一版本信息更新目标名单的第二版本信息。因此，只有在第一名单的第一版本信息高于目标名单的第二版本信息的情况下，才表明第一名单比目标名单要新，因此能够根据第一名单更新目标名单。这种设置版本信息的方式，避免了重复更新目标名单，或者利用旧数据错误更新目标名单的情况出现，保证了目标名单的准确性。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种服务器的框图。

基于同一发明构思，在示例性实施例中，还提供了一种服务器700，包括：处理器700、通信接口706、用于存储所述处理器700可执行指令的存储器704和通信总线702；其中，所述处理器700被配置为执行所述指令，以实现上述方法中第一服务端或第二服务端实现的步骤。其中，处理器700、通信接口706和存储器704通过通信总线702完成相互间的通信。

基于同一发明构思，在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由上述服务器700执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种硬编硬解测试方法，应用于第一服务端，其特征在于，包括：

接收客户端发送的第一请求；

响应于所述第一请求，向所述客户端发送基准配置信息或预存的目标名单；

获取所述客户端的第一名单；所述第一名单是基于所述客户端的测试结果生成的；所述测试结果是所述客户端基于所述基准配置信息及所述目标名单测试确定的；

根据所述第一名单更新所述目标名单。

2.根据权利要求1所述的硬编硬解测试方法，其特征在于，所述第一请求包括测试请求或目标名单获取请求。

3.根据权利要求2所述的硬编硬解测试方法，其特征在于，所述向所述客户端发送基准配置信息之前，还包括：

基于所述第一请求为所述测试请求，读取预存的机型候选名单；

根据所述客户端的目标机型是否属于所述机型候选名单，确定所述目标机型对应的所述基准配置信息。

4.根据权利要求3所述的硬编硬解测试方法，其特征在于，所述读取预存的机型候选名单，包括：

根据所述测试请求是否满足预设测试条件，确定是否读取所述机型候选名单；

基于所述测试请求满足所述预设测试条件，读取所述机型候选名单。

5.根据权利要求4所述的硬编硬解测试方法，其特征在于，所述预设测试条件基于预设采样率和日活跃用户数量确定。

6.根据权利要求5所述的硬编硬解测试方法，其特征在于，所述预设测试条件基于预设采样率和日活跃用户数量确定，包括：

根据所述日活跃用户数量与所述预设采样率的乘积，确定预设时长内的设备测试数量；

确定所述测试请求是否为所述预设时长内接收到的前N个测试请求，N为小于或等于所述设备测试数量的正整数；

基于所述测试请求为所述预设时长内接收到的前N个测试请求，确定所述测试请求满足所述预设测试条件。

7.根据权利要求3所述的硬编硬解测试方法，其特征在于，所述根据所述客户端的目标机型是否属于所述机型候选名单，确定所述目标机型对应的所述基准配置信息，包括：

基于所述目标机型属于所述机型候选名单，确定所述机型候选名单中所述目标机型对应的配置规则，根据所述配置规则生成所述基准配置信息；

基于所述目标机型不属于所述机型候选名单，根据预存的默认配置信息生成所述基准配置信息。

8.根据权利要求1所述的硬编硬解测试方法，其特征在于，所述获取所述客户端的第一名单，包括：

定时向第二服务端发送名单获取请求；

接收所述第二服务端根据所述名单获取请求返回的所述第一名单；所述第一名单是所述第二服务端基于所述客户端的所述测试结果生成的。

9.根据权利要求8所述的硬编硬解测试方法，其特征在于，所述根据所述第一名单更新所述目标名单，包括：

在所述第一名单的第一版本信息高于所述目标名单的第二版本信息的情况下，根据所述第一名单更新所述目标名单。

10.一种硬编硬解测试装置，应用于第一服务端，其特征在于，包括：

第一接收模块，被配置为执行接收客户端发送的第一请求；

第一发送模块，被配置为执行响应于所述第一请求，向所述客户端发送基准配置信息或预存的目标名单；

第一名单获取模块，被配置为执行获取所述客户端的第一名单；所述第一名单是基于所述客户端的测试结果生成的；所述测试结果是所述客户端基于所述基准配置信息及所述目标名单测试生成的；

更新模块，被配置为执行根据所述第一名单更新所述目标名单。

Images