模块测试方法、装置及电子设备

技术领域

本申请涉及数据处理技术领域，尤其涉及大数据技术、及服务测试技术领域，具体涉及一种模块测试方法、装置及电子设备。

背景技术

在各种服务如地图服务上线之前，通过需要进行线下压测，以拦截服务模块的代码漏洞，具体做法通常是构造测试请求集，以命中服务模块的场景对服务模块进行代码测试。

目前，对服务模块进行线下压测的测试请求集通常为随机构造，即从服务的线上随机选取多个服务请求构造测试请求集，并基于该测试请求集，对服务模块进行代码测试。

发明内容

本公开提供了一种模块测试方法、装置及电子设备。

根据本公开的第一方面，提供了一种模式测试方法，包括：

获取待测试服务模块的第一测试请求集；其中，所述第一测试请求集包括对所述待测试服务模块的多个服务请求分别进行M个维度的分类得到的多个测试请求，M为正整数；

对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集；

在所述第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试。

根据本公开的第二方面，提供了一种模块测试装置，包括：

获取模块，用于获取待测试服务模块的第一测试请求集；其中，所述第一测试请求集包括对所述待测试服务模块的多个服务请求分别进行M个维度的分类得到的多个测试请求，M为正整数；

筛选模块，用于对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集；

测试模块，用于在所述第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器能够执行第一方面中的任一项方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行第一方面中的任一项方法。

根据本申请的技术解决了服务模块的测试效果比较差的问题，提高了服务模块的测试效果。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请第一实施例的模块测试方法的流程示意图；

图2是基于目标模型对第一测试请求集中测试请求进行筛选的流程示意图；

图3是基于代码覆盖率对第一测试请求集中测试请求进行筛选的流程示意图；

图4是用来实现第一实施例中一具体示例的模块测试方法的整体架构示意图；

图5是根据本申请第二实施例的模块测试装置的结构示意图；

图6是用来实现本申请实施例的信息点识别方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

第一实施例

如图1所示，本申请提供一种模块测试方法，包括如下步骤：

步骤S101：获取待测试服务模块的第一测试请求集；其中，所述第一测试请求集包括对所述待测试服务模块的多个服务请求分别进行M个维度的分类得到的多个测试请求，M为正整数。

本实施例中，模块测试方法涉及数据处理技术领域，尤其涉及大数据技术及服务测试技术领域，其可以应用于电子设备，该电子设备可以为服务器，也可以为终端，这里不做具体限定。

所述待测试服务模块可以为众多服务模块中的一个服务模块，所述众多服务模块可以构成一个整体的服务，该服务可以为地图服务。在该地图服务上线之前，通常需要对其进行线下压测，以将风险拦截于线下，减少线上地图服务的各个服务模块出现核心core、中央处理器激增和内存泄漏等问题，提高线上地图服务的稳定性和质量。

所述待测试服务模块即可以为地图服务的任一服务模块，而针对地图服务的每个服务模块均可以按照相同的方式进行测试。

所述待测试服务模块可以是由程序代码所构建的服务模块，对所述待测试服务模块测试的目的是：触发所述待测试服务模块运行，并尽可能地运行所述待测试服务模块的代码，以发现待测试服务模块的代码漏洞，进行待测试服务模块的性能和稳定性测试。

其测试的手段是：从地图服务的线上服务日志选取服务请求来构造测试请求集，基于构造的测试请求集对待测试服务模块进行测试，地图服务的线上服务日志指的是基于线上的历史服务请求所生成的日志。

其中，触发所述待测试服务模块运行的条件是测试请求中命中有待测试服务模块的关键参数，所述待测试服务模块的关键参数通常包括多个，且不同的测试请求中所包括的关键参数个数以及组合方式均可能不同，可以将关键参数的一种排列组合称之为一种测试场景。相应的，每一种测试场景所命中的待测试服务模块的代码分支可能会有所不同。

比如，待测试服务模块的关键参数包括A、B、C和D，一测试请求中包括关键参数A和B，说明该测试请求命中了待测试服务模块的一种场景。

又比如，另一测试请求中包括关键参数A、B和C，则说明该测试请求命中了待测试服务模块的另一种场景。

还比如，又一测试请求中包括关键参数C和D，则说明该测试请求命中了待测试服务模块的又一种场景。

为了尽可能地运行待测试服务模块的更多代码，所构造的测试请求集中的测试请求通常需要命中尽可能多的场景。

然而，相关技术中，由于测试请求集来自于线上服务日志，且为随机选取，因此通常会造成测试请求集中的场景热点问题，即测试请求集中的很多测试请求为相同场景，这会使待测试服务模块均运行同一分支代码。而对于那些不容易触发，需要较多条件(比如需要较多的关键参数)才能触发，或者服务请求的流量很低的场景，测试请求往往无法覆盖，以至于在测试过程中虽经过长时间压测，仍不能较好地拦截待测试服务模块的代码漏洞。

因此，采用随机方式构造的测试请求集，对于待测试服务模块的测试代码覆盖率往往达不到要求，测试效果比较差，地图服务上线后往往伴随着批量核心core、中央处理器突增等线上问题。

为了尽可能地使测试请求集命中待测试服务模块的更多场景，需要改变测试请求集的构造方式。该步骤中，通过对线上的多个服务请求分别进行M个维度的分类，来精细化构造测试请求集。

具体的，所述待测试服务模块的多个服务请求可以指的是地图服务的线上服务日志中的服务请求，该服务请求中可以包括触发待测试服务模块运行的关键参数，也可以不包括触发待测试服务模块的关键参数，这里不做具体限定。其中，地图服务的线上服务日志中的服务请求可以包括导航请求和出行请求等。

在实现过程中，模块测试装置可以获取地图服务的线上服务日志，并从线上服务日志中提取所述多个服务请求。

针对所述多个服务请求，可以分别对其进行M个维度的分类，所述M个维度可以包括时间维度、地域维度和服务请求来源维度等中至少一个维度。以所述M个维度包括上述三个维度为例，针对时间维度分类，所述多个服务请求可以分成多个时间段的服务请求，比如，包括早上的服务请求、中午的服务请求、傍晚的服务请求和夜晚的服务请求等。

针对地域维度分类，所述多个服务请求可以分成多个地域的服务请求，比如，包括南方地域的服务请求、北方地域的服务请求、东边地域的服务请求和西边地域的服务请求等。

针对服务请求来源维度分类，所述多个服务请求可以分成多个来源下的服务请求，比如，包括来自手机端的服务请求、来自个人计算机端的服务请求和来自开放平台的服务请求等。

通过分别在每个维度上对线上的多个服务请求进行分类，可以得到多个分类下的服务请求。

分类后，可以从这些分类下的服务请求分别选取一部分服务请求来构造第一测试请求集。其选取的方式可以为等比例选取，也可以为随机比例选取，或者也可以为根据每个维度下的服务请求特征信息进行选取，这里不做具体限定。总之，为了使测试请求集命中更多场景，每个分类下的服务请求均需要选取。

选取各个分类下的服务请求之后，可以将选取的服务请求进行聚合，得到包括各个分类下的服务请求的服务请求集。在选取的服务请求存在重复的情况下，还可以聚合时进行服务请求去重，之后通过转换工具将该服务请求集转换成第一测试请求集，所述第一测试请求集包括多个测试请求。

步骤S102：对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集。

上述步骤S101得到的第一测试请求集为测试请求全集，由于线上的服务请求数量巨大，选取服务请求后所构造的第一测试请求集中的测试请求数量也比较大，且第一测试请求集中还是包括了很多相同的场景。

因此，为了精简测试请求集的流量，提高待测试服务模块的测试效率，该步骤中可以对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集。

对所述第一测试请求集中的测试请求进行筛选可以理解为两种，第一种可以理解为从所述第一测试请求集中滤除一部分测试请求，剩下的测试请求则聚合成第二测试请求集。第二种可以理解为从所述第一测试请求集中匹配出一部分测试请求，匹配出的测试请求则聚合成第二测试请求集。

针对第一种，可以进行随机滤除，或者提取第一测试请求集中测试请求的参数，获取测试请求中待测试服务模块的关键参数，基于测试请求中待测试服务模块的关键参数的排列组合，确定测试请求命中的待测试服务模块的场景，将命中待测试服务模块相同场景的测试请求滤除。

针对第二种，可以采用至少一种筛选方式分别对第一测试请求集中的测试请求进行筛选，并将每种筛选方式匹配出的测试请求进行聚合，得到第二测试请求集。其中，在匹配出的测试请求存在重复的情况下，聚合时可以将其进行去重，最终得到用于测试的最小测试请求集。

其中，所述至少一种筛选方式可以包括基于所述待测试服务模块对应的预设匹配规则的筛选、基于目标模型(可以为深度学习模型)的筛选、基于所述第一测试请求集对所述待测试服务模块的代码覆盖率的筛选以及异常的测试请求和稀有的测试请求的积累中至少一种，以下对此进行详细说明。

步骤S103：在所述第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试。

该步骤中，为了评估第二测试请求集的有效性，可以对所述第二测试请求集进行验证，以确定第二测试请求集是否可用于后续的线下压测，提高待测试服务模块的测试效果。

具体的，可以设定第二测试请求集的评估方式，并设定其评估标准，其评估方式可以为所述第二测试请求集对所述待测试服务模块的覆盖率，该覆盖率可以为代码覆盖率，也可以为场景覆盖率，或者包括两者都可。其评估标准可以为代码覆盖率大于第二阈值如60％，和/或，场景覆盖率大于第三阈值如80％，其中，代码覆盖率可以为代码分支覆盖率和行覆盖率。

若评估方式中包括所述第二测试请求集对所述待测试服务模块的代码覆盖率，需要基于第二测试请求集对待测试服务模块进行压测，如压测1小时，基于压测1小时的待测试服务模块的代码覆盖率判定第二测试请求集是否有效，在代码覆盖率大于第二阈值的情况下，所述第二测试请求集对所述待测试服务模块的代码覆盖率验证通过。

所述第二测试请求集进行验证过程中基于第二测试请求集对待测试服务模块进行压测，与基于第二测试请求集对待测试服务模块进行实际压测的目的不同，对第二测试请求集进行验证过程中基于第二测试请求集对待测试服务模块进行压测的目的是确定第二测试请求集是否可用于实际压测，以在实际压测中可以发现尽可能多的问题。

因此，为了提高第二测试请求集的验证效率，在基于第二测试请求集对待测试服务模块进行压测过程中，可以持续调整第二测试请求集中的测试请求位置，将命中待测试服务模块的不同场景下的测试请求选取部分置于第二测试请求集的顶部，以使待测试服务模块在短时间内可以运行比较多的代码逻辑，减少无用压测时间，从而可以提高第二测试请求集的验证效率。

若评估方式中包括所述第二测试请求集对所述待测试服务模块的场景覆盖率，可以遍历第二测试请求集中每个测试请求，记录待测试服务模块的关键参数所出现的排列组合数量，以记录第二测试请求集所覆盖的场景数量。只有在场景数量达到要求后，如第二测试请求集中的测试请求出现的场景数量与总场景数量的比例达到第三阈值后，才确定所述第二测试请求集对所述待测试服务模块的场景覆盖率验证通过。

在所述第二测试请求集对所述待测试服务模块的代码覆盖率，和/或，场景覆盖率验证通过的情况下，基于所述第二测试请求集对所述待测试服务模块进行测试。

本实施例中，通过对线上的多个服务请求分别进行M个维度的分类，来精细化构造第一测试请求集，可以很好地避免现有技术中随机选取的服务请求为一个类别或者少量类别下的服务请求，从而可以很好地解决现有技术中测试请求全集中的场景热点问题，进而可以提高待测试服务功能的测试效果。并通过对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集，可以精简测试请求集的流量，提高待测试服务模块的测试效率。

之后，在第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，才确定第二测试请求集为最终的地图服务中待测试服务模块的测试请求集，从而可以保证每一份测试请求集的覆盖完整度，保证待测试服务模块的测试效果。

可选的，所述步骤S101具体包括：

分别对所述待测试服务模块的每个服务请求进行M个维度的分类，以得到每个服务请求的M个分类特征信息；

基于所述多个服务请求的分类特征信息确定每个维度的服务请求特征信息；

分别基于每个维度的服务请求特征信息在所述多个服务请求中进行采样，以得到所述M个维度的服务请求采样结果；

生成包括所述M个维度的服务请求采样结果的测试数据；

对所述测试数据进行转换，得到所述第一测试请求集。

本实施方式中，由于地图请求尤其是导航请求，与用户的使用时间强相关，因此可以从时间维度上对服务请求进行分类。

并且，由于路网密度、南北方出行习惯的不同，不同地域的出行请求也有较大差异，且起终点、算路长度以及算路偏好的不同，覆盖的服务场景亦不相同，因此也可以从地域维度上对服务请求进行分类。

另外，一个线上地图服务的服务请求来源可能有多种，如来自手机端、来自个人计算机端以及来自开放平台等，地图服务对于不同来源的服务请求，处理逻辑也不尽相同，因此也可以从服务请求来源维度上对服务请求进行分类。

为了尽可能覆盖更多的场景，以M为3为例，所述M个维度为时间维度、地域维度和服务请求来源维度。针对每个服务请求，可以分别对所述待测试服务模块的每个服务请求进行时间维度、地域维度和服务请求来源维度上的分类。

如一服务请求，与用户的使用时间强相关，其为用户早上的服务请求，则在时间维度上该服务请求的分类特征信息为早上的服务请求。并且，该服务请求为北方地域的服务请求，则在地域维度上该服务请求的分类特征信息为北方地域的服务请求。另外，该服务请求来自手机端，则在服务请求来源维度上该服务请求的分类特征信息为来自手机端的服务请求。

基于所述多个服务请求的分类特征信息可以确定每个维度的服务请求特征信息。比如，基于所述多个服务请求在时间维度上的分类特征信息，可以统计得出时间维度上的服务请求特征信息为早上和傍晚的服务请求比较多，而中午和夜晚的服务请求比较少。

而基于所述多个服务请求在地域维度上的分类特征信息，可以统计得出地域维度上东西南北地域的服务请求比例。基于所述多个服务请求在服务请求来源维度上的分类特征信息，可以统计得出各个来源下的服务流量。

之后，分别基于每个维度的服务请求特征信息在所述多个服务请求中进行采样，以得到所述M个维度的服务请求采样结果。

比如，在时间维度上的服务请求特征信息为早上和傍晚的服务请求比较多，而中午和夜晚的服务请求比较少，则在采样时，可以在早上的服务请求和傍晚的服务请求中进行高频采样，而在中午的服务请求和夜晚的服务请求中进行低频采样。另外，由于线上的服务请求数量比较多，为了进一步精细化选取服务请求，可以将时间细分至每秒，每分钟选取一定量的服务请求如前3秒的服务请求进行采样，在保留时间特征的同时减少服务请求量级。

而在地域维度上，可以按照东西南北地域的服务请求比例，选取不同地域的服务请求，以保证测试请求集命中更多场景。比如，东西南北地域的服务请求比例分别为1：2：3：4，若需要选取1000个服务请求，则可以从东边地域的服务请求中选取100个服务请求，从西边地域的服务请求中选取200个服务请求，从南方地域的服务请求中选取300个服务请求，从北方地域的服务请求中选取400个服务请求。

在服务请求来源维度上，可以按照相同比例选取不同来源下的服务请求，若某一来源下的服务流量较小，则可以提高采样的比例，防止场景覆盖不够充分。比如，可以分别按照0.01％的比例从各个来源下的服务请求中采样服务请求，若开放平台的服务流量较小，则可以按照1％的比例从开放平台下的服务请求中采样服务请求。

将所述M个维度的服务请求采样结果进行聚合，得到测试数据。其中，在聚合时若M个维度的服务请求采样结果的服务请求存在重复，则将重复的服务请求剔除即可，最终得到测试数据。

采用转换工具对所述测试数据进行转换，得到所述第一测试请求集。

本实施方式中，通过分别对所述待测试服务模块的每个服务请求进行M个维度的分类，这样，可以根据不同维度的服务请求特征信息，精细化选取所述多个服务请求中的服务请求，从而可以使构造的测试请求集命中更多场景，提高待测试服务模块的测试效果。

可选的，所述步骤S102具体包括：

基于所述待测试服务模块对应的预设匹配规则，对所述第一测试请求集中的测试请求进行筛选，得到满足所述预设匹配规则的第一子集；

基于目标模型对所述第一测试请求集中的测试请求进行筛选，得到第二子集；其中，所述第二子集包括基于所述目标模型所确定的有效类型的测试请求；

基于所述第一测试请求集对所述待测试服务模块的代码覆盖率，对所述第一测试请求集中的测试请求进行筛选，得到第三子集；

生成包括所述第一子集、第二子集和第三子集中至少一个子集的所述第二测试请求集。

本实施方式中，可以结合一种或多种筛选方式分别从所述第一测试请求集中匹配出一部分测试请求，最终基于匹配出的测试请求确定第二测试请求集。

主要的筛选方法可以包括：基于所述待测试服务模块对应的预设匹配规则的筛选、基于目标模型(可以为深度学习模型)的筛选和基于所述第一测试请求集对所述待测试服务模块的代码覆盖率的筛选，以下对此进行详细说明。

具体的，首先介绍基于所述待测试服务模块对应的预设匹配规则的筛选，该筛选方式为测试人员基于日常项目的测试经验，为待测试服务模块设置基本的匹配规则和匹配数量，比如，可以基于测试请求中单个关键参数取值的枚举值，或是和其他关键参数取值的排列组合的枚举值，来对所述第一测试请求集中的测试请求进行筛选。举个例子来说，测试人员基于测试经验，可知待测试服务模块中包括关键参数A，其取值通常为1、2和3，则可以设置匹配规则“A＝1，2或3”，将第一测试请求集中包括关键参数A的测试请求，以及关键参数A取值为1，2或3的测试请求筛选出来。

此部分的匹配规则主要来源于测试人员的日常测试以及线上问题请求的积累，针对该匹配规则，可以提供一个匹配规则的积累系统，可以将测试人员日常记录的匹配规则均保存至数据库中，用于构建测试请求集的定向筛选，此部分的匹配规则基于人工积累，可覆盖待测试服务模块的大部分主要请求场景。

基于目标模型的筛选：所述目标模型可以为深度学习模型，基于目标模型对所述第一测试请求集中的测试请求的筛选方式主要是：确定测试请求是否有效，在确定有效的情况下，保留该测试请求，确定无效的情况下，丢弃该测试请求。

所述目标模型在使用时，通常需要训练，以学习到测试请求的特征，具体的，参见图2，图2是基于目标模型对第一测试请求集中测试请求进行筛选的流程示意图，如图2所示，可以给测试请求设置若干特征，如：请求来源、地域、距离、请求时间、请求场景(包括通勤、高架桥、高速、小路等不同请求场景)和偏好等，通过特征标注方式挑选一批测试请求作为训练样本集，选用极端梯度提升(eXtreme Gradient Boosting，XGboost)或梯度下降树(Gradient Boosting Decison Tree，GBDT)等模型，利用训练样本集对目标模型进行训练。

训练后，将第一测试请求集中每个测试请求输入至该目标模型，通过该目标模型判定测试请求是否有效，以筛选出第二子集，该第二子集包括有效类型的测试请求。之后，为了更加准确地判定，可以将第二子集中的测试请求再次输入至目标模型，最终输出第二子集。

另外，基于目标模型的筛选方式可以作为基于所述待测试服务模块对应的预设匹配规则的筛选方式的补充，通过深度学习可以更精准地判定测试请求是保留还是丢弃。

基于所述第一测试请求集对所述待测试服务模块的代码覆盖率的筛选，该筛选方式主要从代码覆盖率角度来对第一测试请求集进行筛选，以匹配出可提高待测试服务模块的代码覆盖率的测试请求，其具体实现过程以下实施方式对此进行详细说明。

另外，该筛选方式是单纯从待测试服务模块的代码覆盖率对第一测试请求集中的测试请求进行筛选，可以配合其他筛选方式使用。

生成包括所述第一子集、第二子集和第三子集中至少一个子集的所述第二测试请求集。在采用多种筛选方式对所述第一测试请求集中的测试请求进行筛选时，可以得到多个子集，此时，可以将第一子集、第二子集和第三子集中至少两个子集进行聚合，聚合时若存在重复的测试请求，将重复的测试请求去重即可。

本实施方式中，通过一种或多种筛选方式对第一测试请求集中的测试请求进行筛选，以匹配出一部分测试请求，最终基于匹配出的测试请求确定第二测试请求集。这样，在保证待测试服务模块的场景覆盖率和代码覆盖率的同时，还能够精简测试请求集的流量，从而可以提升待测试服务模块的测试效率。

可选的，所述生成包括所述第一子集、第二子集和第三子集中至少一个子集的所述第二测试请求集，包括：

获取第一目标测试请求集，所述第一目标测试请求集包括所述第一子集、第二子集和第三子集中至少一个子集；

将所述第一目标测试请求集与第二目标测试请求集进行聚合，得到所述第二测试请求集；

其中，所述第二目标测试请求集包括预先存储的第一目标测试请求和/或第二目标测试请求，所述第一目标测试请求为所述第一测试请求集中出现概率小于第一阈值的测试请求，所述第二目标测试请求为使所述待测试服务模块出现异常的历史测试请求。

本实施方式中，所述第二测试请求集中不仅包括所述第一子集、第二子集和第三子集中至少一个子集即第一目标测试请求集之外，还可以包括第二目标测试请求集，所述第二目标测试请求集中包括第一目标测试请求和/或第二目标测试请求。

所述第一目标测试请求集虽然覆盖了待测试覆盖模块大部分场景，但是，对于一些稀有的测试请求即第一目标测试请求(通常出现概率比较小，可能为百万分之一)，上述筛选方式可能均无法覆盖此类测试请求。另外，对于异常的测试请求即第二目标测试请求，所述第一目标测试请求集也无法覆盖。

因此，针对这些测试请求，可以提供测试请求留存功能，即在每次筛选中将第一目标测试请求予以记录，而对于已知的线上异常的服务请求，也可以通过此类功能进行积累，最终基于积累的请求生成第二目标测试请求集。

本实施方式中，通过积累异常的和/或稀有的测试请求，并将其聚合，生成第二测试请求集，从而可以进一步提升测试请求集对待测试服务模块的场景覆盖率。

可选的，所述基于所述第一测试请求集对所述待测试服务模块的代码覆盖率，对所述第一测试请求集中的测试请求进行筛选，得到第三子集，包括：

将所述第一测试请求集分成多个测试子集；

针对所述多个测试子集中每个测试子集，基于所述测试子集对所述待测试服务模块进行测试；在所述测试子集相对于目标测试子集对所述待测试服务模块的代码覆盖率提高的情况下，保留所述测试子集；其中，所述目标测试子集为所述第一测试请求集中目标测试时段对所述待测试服务模块进行测试的测试子集，所述目标测试时段为相对于所述测试子集的测试时段的前一个测试时段；

基于保留的所述测试子集确定所述第三子集。

本实施方式中，在基于所述第一测试请求集对所述待测试服务模块的代码覆盖率的筛选方式中，参见图3，图3是基于代码覆盖率对第一测试请求集中测试请求进行筛选的流程示意图，如图3所示，可以将第一测试请求集进行细粒度划分，分成多个测试子集。并可以根据发压模块的每秒查询率(Queries-per-second，QPS)的不同，选取5000条或10000条测试请求作为一个时钟周期的测试子集，输入至发压模块不间断对待测试服务模块进行线下压测。

之后，实时监测待测试服务模块的代码覆盖率，以确定测试子集对待测试服务模块的代码覆盖率(可以为代码分支覆盖率或代码行覆盖率)是否有贡献，即确定一个时钟内代码覆盖率是否有所上升。若有所上升，则保留此测试子集，否则不保留。

当全部测试子集对待测试服务模块进行线下压测完毕后，可以将保留的测试子集聚合，之后打乱测试请求的顺序再进行细粒度划分，重新进行一次筛选，最后将保留的测试子集聚合得到第三子集。

本实施方式中，通过从待测试服务模块的代码覆盖率维度对第一测试请求集中的测试请求进行筛选，以得到第二测试请求集，可以保证第二测试请求集对待测试服务模块的代码覆盖率，从而可以提高待测试服务模块的测试效果。

可选的，所述在所述第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试，包括：

在所述第二测试请求集对所述待测试服务模块的代码覆盖率大于第二阈值，和/或，所述第二测试请求集对所述待测试服务模块的场景覆盖率大于第三阈值的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试；

其中，所述场景覆盖率为目标排列组合数量占所述待测试服务模块对应的目标参数的排列组合数量的比例，所述目标排列组合数量为所述第二测试请求集的测试请求中所述目标参数出现的排列组合数量。

本实施方式中，主要从代码覆盖率和/或场景覆盖率维度对第二测试请求集进行验证，在所述第二测试请求集对所述待测试服务模块的代码覆盖率大于第二阈值，和/或，所述第二测试请求集对所述待测试服务模块的场景覆盖率大于第三阈值的情况下，可以说明所述第二测试请求集对所述待测试服务模块的覆盖率验证通过。

其中，代码覆盖率表示待测试服务模块运行的代码分支占总代码分支的比例，或者代码行占总代码行的比例。第二阈值的设定可基于待测试服务模块本身的代码冗余度设定，如设定为60％。而场景覆盖率为目标排列组合数量占所述待测试服务模块对应的目标参数的排列组合数量的比例，所述目标排列组合数量为所述第二测试请求集的测试请求中所述目标参数出现的排列组合数量。

本实施方式中，通过对第二测试请求集进行验证，并从代码覆盖率和/或场景覆盖率维度方面设定评估标准，判定第二测试请求集是否达到了评估标准，在所述第二测试请求集对所述待测试服务模块的代码覆盖率大于第二阈值，和/或，所述第二测试请求集对所述待测试服务模块的场景覆盖率大于第三阈值的情况下，才基于所述第二测试请求集，对所述待测试服务模块进行测试。如此，通过对生成的第二测试请求集进行严格准出，保证了每一份测试请求集的代码覆盖和场景覆盖完整度。

以下以一种优选方式更加详细地阐述本方案的全部过程。

参见图4，图4是用来实现第一实施例中一具体示例的模块测试方法的整体架构示意图，如图4所示，为了实现模块测试方法，通常可以包括四个模块，分别为流量选取模块、聚合和转换模块、请求筛选模块和后验模块。

具体的，获取分布式存储系统hadoop集群存储的地图服务的线上日志，通过流量选取模块进行多维度的分类，分别基于时间维度分类、基于地域维度分类和基于服务请求来源维度分类，并基于分类后各维度的服务请求特征信息选取流量，得到选取的流量日志。

采用聚合和转换模块将各维度选取的流量日志进行聚合，并转换成原始的测试请求集。

之后，采用请求筛选模块对原始的测试请求集中测试请求进行筛选，得到流量精简的测试请求集。具体的，可以采用多种筛选方式并行筛选测试请求，分别为基于预设匹配规则筛选、基于代码覆盖率筛选、基于目标模型筛选，以及稀有和异常的请求积累。

采用后验模块对测试请求集进行验证，可以分别从对待测试服务模块的代码覆盖率和场景覆盖率进行验证，在验证通过的情况下，该测试请求集即可用于项目测试。

为了提高测试请求集的构造效率，可以在流量选取和请求筛选过程中均采取多进程并发的方式，多种筛选方式并行执行，在每个进程中再采取多线程并发，最大限度地使用中央处理器资源，提高测试请求集的构造效率。同时，可以在每步操作中设定报警阈值，当预期的请求数量低于此阈值后会自动报警，避免后续无用的操作而浪费时间。

另外，由于地图服务协议多种多样，为了使模块测试方法可适配多种协议请求，全部规则可支持正则匹配，并且对于不同协议的请求格式又进行了额外适配，满足了地图服务中不同服务模块的测试请求集的构造需求。同时，后验模块中引用了多种发压工具，支持多种协议请求的发送，最大限度地提升模块测试方法的通用性。

第二实施例

如图5所示，本申请提供一种模块测试装置500，包括：

获取模块501，用于获取待测试服务模块的第一测试请求集；其中，所述第一测试请求集包括对所述待测试服务模块的多个服务请求分别进行M个维度的分类得到的多个测试请求，M为正整数；

筛选模块502，用于对所述第一测试请求集中的测试请求进行筛选，以得到第二测试请求集；

测试模块503，用于在所述第二测试请求集对所述待测试服务模块的覆盖率验证通过的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试。

可选的，其中，所述获取模块501包括：

分类单元，用于分别对所述待测试服务模块的每个服务请求进行M个维度的分类，以得到每个服务请求的M个分类特征信息；

确定单元，用于基于所述多个服务请求的分类特征信息确定每个维度的服务请求特征信息；

采样单元，用于分别基于每个维度的服务请求特征信息在所述多个服务请求中进行采样，以得到所述M个维度的服务请求采样结果；

第一生成单元，用于生成包括所述M个维度的服务请求采样结果的测试数据；

转换单元，用于对所述测试数据进行转换，得到所述第一测试请求集。

可选的，其中，所述筛选模块502包括：

第一筛选单元，用于基于所述待测试服务模块对应的预设匹配规则，对所述第一测试请求集中的测试请求进行筛选，得到满足所述预设匹配规则的第一子集；

第二筛选单元，用于基于目标模型对所述第一测试请求集中的测试请求进行筛选，得到第二子集；其中，所述第二子集包括基于所述目标模型所确定的有效类型的测试请求；

第三筛选单元，用于基于所述第一测试请求集对所述待测试服务模块的代码覆盖率，对所述第一测试请求集中的测试请求进行筛选，得到第三子集；

第二生成单元，用于生成包括所述第一子集、第二子集和第三子集中至少一个子集的所述第二测试请求集。

可选的，其中，所述第二生成单元，具体用于获取第一目标测试请求集，所述第一目标测试请求集包括所述第一子集、第二子集和第三子集中至少一个子集；将所述第一目标测试请求集与第二目标测试请求集进行聚合，得到所述第二测试请求集；

其中，所述第二目标测试请求集包括预先存储的第一目标测试请求和/或第二目标测试请求，所述第一目标测试请求为所述第一测试请求集中出现概率小于第一阈值的测试请求，所述第二目标测试请求为使所述待测试服务模块出现异常的历史测试请求。

可选的，其中，所述第三筛选单元，具体用于将所述第一测试请求集分成多个测试子集；针对所述多个测试子集中每个测试子集，基于所述测试子集对所述待测试服务模块进行测试；在所述测试子集相对于目标测试子集对所述待测试服务模块的代码覆盖率提高的情况下，保留所述测试子集；其中，所述目标测试子集为所述第一测试请求集中目标测试时段对所述待测试服务模块进行测试的测试子集，所述目标测试时段为相对于所述测试子集的测试时段的前一个测试时段；基于保留的所述测试子集确定所述第三子集。

可选的，其中，所述测试模块503，具体用于在所述第二测试请求集对所述待测试服务模块的代码覆盖率大于第二阈值，和/或，所述第二测试请求集对所述待测试服务模块的场景覆盖率大于第三阈值的情况下，基于所述第二测试请求集，对所述待测试服务模块进行测试；

其中，所述场景覆盖率为目标排列组合数量占所述待测试服务模块对应的目标参数的排列组合数量的比例，所述目标排列组合数量为所述第二测试请求集的测试请求中所述目标参数出现的排列组合数量。

本申请提供的模块测试装置500能够实现上述模块测试方法实施例实现的各个过程，且能够达到相同的有益效果，为避免重复，这里不再赘述。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图6所示，是根据本申请实施例的模块测试方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图6所示，该电子设备包括：一个或多个处理器601、存储器602，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图6中以一个处理器601为例。

存储器602即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的模块测试方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的模块测试方法。

存储器602作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的模块测试方法对应的程序指令/模块(例如，附图5所示的获取模块501、筛选模块502和测试模块503)。处理器601通过运行存储在存储器602中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的模块测试方法。

存储器602可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据本申请实施例的模块测试方法的电子设备的使用所创建的数据等。此外，存储器602可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器602可选包括相对于处理器601远程设置的存储器，这些远程存储器可以通过网络连接至模块测试方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例的模块测试方法的电子设备还可以包括：输入装置603和输出装置604。处理器601、存储器602、输入装置603和输出装置604可以通过总线或者其他方式连接，图6中以通过总线连接为例。

输入装置603可接收输入的数字或字符信息，以及产生与本申请实施例的模块测试方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置604可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。

本实施例中，通过对线上的多个服务请求分别进行M个维度的分类，来精细化构造第一测试请求集，可以很好地避免现有技术中随机选取的服务请求为一个类别或者少量类别下的服务请求，从而可以很好地解决现有技术中测试请求全集中的场景热点问题，进而可以提高待测试服务功能的测试效果。因此，根据本申请实施例的技术方案，很好地解决了服务模块的测试效果比较差的问题。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。