CN113342664B - 拨测方法、装置、存储介质及计算机设备 - Google Patents

Abstract

本申请涉及一种拨测方法、装置、存储介质及计算机设备，该方法包括：获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，根据目标服务请求的第一返回结果，分别获取对应的检测点；获取每个检测点对应的预期返回结果；从目标服务请求中提取出对应的目标服务请求的请求地址；根据对应的请求地址、检测点和预期返回结果分别生成对应的检测用例。通过本申请可以利用代码覆盖度，自动化生成拨测目标服务的检测用例。降低人工编写检测用户繁琐；避免检测点不全面不能全面对目标服务的各项功能进行检测；自动化；可应用于各种复杂业务场景。

Description

拨测方法、装置、存储介质及计算机设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种拨测方法、装置、存储介质及计算机设备。

背景技术

服务拨测是拨测服务可用性的监控方式。通过拨测节点对目标服务进行周期性拨测，检查衡量服务是否正常可用性。现有技术通常是人工提前录入一些专门检测特定检测点的业务检查用例，根据业务检测用例周期性请求服务。对于一些业务复杂场景，人工编写的方式耗费人力，并且容易遗漏检测点。

发明内容

为了解决上述用于拨测服务的检测用例编写繁琐且不够精准的技术问题，本申请实施例提供了一种拨测方法、装置、存储介质及计算机设备。

第一方面，本申请实施例提供了一种拨测方法，该方法包括：

获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；

根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；

根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；

获取每个检测点对应的预期返回结果；

从目标服务请求中提取出对应的目标服务的请求地址；

根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

可选地，该方法还包括：

调用每条检测用例以对目标服务进行拨测，得到对应的实际返回结果；

分别将实际返回结果与对应的预期返回结果进行对比，以判断目标服务是否可用。

可选地，根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，包括：

获取多个不同服务请求组合，每个服务请求组合包括至少一条服务请求；

分别获取各个服务请求组合中所有服务请求对应的代码覆盖数据的并集；

获取并集所包含的总代码覆盖数据与目标服务的总代码量的比值作为对应的总代码覆盖度；

获取总代码覆盖度达到代码覆盖度阈值的候选服务请求组合；

获取每个候选服务请求组合中服务请求的数量；

将所包含的服务请求的数量最少的候选服务请求组合作为目标服务请求组合。

可选地，代码覆盖度阈值为预设值，或，代码覆盖度阈值为所有服务请求组合中的最大代码覆盖度。

可选地，根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例，包括：

根据目标服务请求的检测点分别获取对应的请求参数；

根据目标服务请求的检测点和预期返回结果分别获取对应的检测规则；

根据对应的请求地址、请求参数、检测点、预期返回结果和检测规则分别生成对应的目标服务请求的检测用例。

可选地，调用每条检测用例以对目标服务进行拨测，得到对应的实际返回结果，包括：

分别调用每条检测用例以向目标服务发送拨测请求，拨测请求携带对应的目标服务请求的请求地址和对应的请求参数，以使目标服务根据请求参数返回对应的实际返回结果。

可选地，分别将实际返回结果与对应的预期返回结果进行对比，以判断目标服务是否可用，包括：

分别根据对应的检测规则将实际返回结果与对应的预期返回结果进行对比；

若存在任意一个实际返回结果与对应的预期返回结果不匹配，则判定目标服务不可用。

第二方面，本申请实施例提供了一种拨测装置，该装置包括：

数据采集模块，用于获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；

筛选模块，用于根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；

检测点获取模块，用于根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；

预期结果获取模块，用于获取每个检测点对应的预期返回结果；

提取模块，用于从目标服务请求中提取出对应的目标服务请求的请求地址；

检测用例生成模块，用于根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

第三方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时，使得处理器执行如前面任一项的方法的步骤。

第四方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时执行如前面任一项的方法的步骤。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：

本申请实施例通过获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；根据目标服务请求的第一返回结果，分别获取对应的检测点；获取每个检测点对应的预期返回结果；从目标服务请求中提取出对应的目标服务请求的请求地址；根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。通过本申请实施例可以利用代码覆盖度，自动化生成拨测目标服务的检测用例。降低人工编写检测用户繁琐，节省人力物力；避免检测点不全面，导致不能全面对目标服务的各项功能进行检测，可以全面检测目标服务的各项性能指标；自动化，省时省力；可应用于各种复杂业务场景，适用性广。

附图说明

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

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

图1为本申请一实施例提供的一拨测方法的流程示意图；

图2为本申请另一实施例提供的一拨测方法的流程示意图；

图3为本申请一实施例提供的一拨测装置的结构框图；

图4为本申请另一实施例提供的一拨测装置的结构框图；

图5为本申请一实施例提供的计算机设备的内部结构框图。

具体实施方式

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

本申请实施例提供的拨测方法应用于拨测系统。该拨测系统包括第一服务器和终端设备。第一服务器是拨测平台对应的服务器，终端设备和第一服务器通过网络连接。工程人员通过终端设备操作拨测平台，目标服务对应第二服务器。第一服务器和第二服务器通过网络连接。终端设备具体可以是台式终端或移动终端，移动终端具体可以手机、平板电脑、笔记本电脑等中的至少一种。第一服务器和第二服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

第一服务器通过第二服务器获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务对应的第二服务器接收到服务请求运行后返回至第一服务器的响应信息；第一服务器根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；获取每个检测点对应的预期返回结果；从目标服务请求中提取出对应的目标服务请求的请求地址；根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

图1为本申请一实施例提供的一拨测方法的流程示意图；参考图1，该拨测方法应用于拨测系统，该拨测方法包括以下步骤：

S100：获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果。

具体地，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息。

预设时间段内会有大量用户向目标服务发送服务请求，具体为线上服务请求。目标服务接收到每条服务请求后，都会根据对应的服务请求调用并执行对应的代码，并向对应的用户返回对应的第一返回结果。目标服务响应服务请求执行过的代码为代码覆盖数据。

获取预设时间段内的服务请求对应的代码覆盖数据和第一返回结果是为了将目标服务实际运行产生的数据作为样本数据，以根据样本数据自动生成该目标服务的检测用例。

在具体实施例中，本申请实施例可以采用测试覆盖工具持续收集预设时间段内的线上服务请求对应的覆盖数据。测试覆盖工具可以为JaCoCo或EMMA等测试覆盖工具，不局限于此。

具体地，拨测系统或拨测平台加载预先构建的测试覆盖工具，例如，JaCoCo、EMMA等测试覆盖工具。调用测试覆盖工具对目标服务进行代码覆盖率测试，以收集线上服务的代码覆盖数据，根据业务情况持续收集预设时间，尽可能获取到程序运行执行过的所有代码行，并且保存预设时间内访问的所有服务请求。再次利用测试覆盖工具，获取每一个服务请求执行过的代码(即，代码覆盖数据)。代码覆盖率即代码覆盖度，是指程序运行过程中，执行过的代码与代码总量的比例。

S200：根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合。

具体地，目标服务请求组合包括至少一条目标服务请求。目标服务根据每条服务请求会执行目标服务所包含的总代码中的部分代码。

因此，预设时间段内会收集大量服务请求对应的代码覆盖数据，每条服务请求对应的代码覆盖数据(已执行的代码)的代码量会小于等于目标服务的总代码量。

目标服务请求组合包含至少一条不同的目标服务请求，即，所包含的目标服务请求不同。每条目标服务请求均为预设时间段内获取的服务请求中的一条。

理论上服务请求组合可以有很多个，服务请求组合可以包括1条服务请求或2条服务请求或3条服务请求等不同数量的服务请求。目标服务请求组合是所有可能的服务请求组合中其总代码覆盖度达到预设条件的服务请求组合。

其中，总代码覆盖度表征一个服务请求组合中所有服务请求所包含的已执行的代码的总占比。更具体地，总占比为所包含的已执行的代码与目标服务所包含的总代码量的比值。

目标服务具有多种功能，用户可以根据需求向目标服务请求各种业务功能，服务请求对应的代码覆盖数据是目标服务执行对应业务功能所执行的代码数据，不同的业务功能执行的代码不同，即代码覆盖数据不同。

目标服务请求组合中所有目标服务请求对应的代码覆盖数据可以最大程度的代表目标服务的各种业务功能。

S300：根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点。

具体地，响应每个目标服务请求，目标服务都会返回一个第一返回结果。请求什么样的业务功能，就会返回对应的第一返回结果。因此从第一返回结果中可以获取到与业务功能对应的检测点。

从目标服务请求组合中可以获取到该目标服务的各个检测点。目标服务请求组合所包含的目标服务请求越全面，对应的检测点也会越全面。这样能够对目标服务的各项性能进行全面拨测。

检测点可以为code、data等节点数据。

S400：获取每个检测点对应的预期返回结果。

具体地，预设时间段内的第一返回结果都是目标服务返回的实际结果，只有目标服务的各项业务功能都可用，这些第一返回结果才可能都准确。但是目前目标服务的功能是否可用，是需要拨测的。因此，第一返回结果不能作为标准参考结果。在目标服务设计完成后，如果不出错，目标服务能够实现各种业务功能，其各种业务功能的理论结果或预期返回结果是已知或很容易获取到的。

在一个具体实施例中，可以通过可视化界面向工程人员展示检测点，工程人员根据检测点可以提供每个检测点对应的预期返回结果。即，通过可视化界面接收工程人员赋值的预期返回结果。

S500：从目标服务请求中提取出对应的目标服务请求的请求地址。

具体地，大量用户通过终端设备向同一个目标服务发送服务请求，服务请求中携带了对应的服务请求的请求地址，因此可以从服务请求中提取出对应的服务请求的请求地址。

目标服务的请求地址具体为统一资源定位符(URL)资源。

S600：根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

具体地，每个检测用例包括对应的请求地址、检测点和预期返回结果。检测点实质是需要重点关注的检查点，一个检测用例包括至少一个检测点。预期返回结果是检测用例中检测点的标准参考结果，每个检测点对应一个预期返回结果。根据每条目标服务请求的请求地址和检测点可以向目标服务发送拨测请求，目标服务根据拨测请求返回对应的实际结果，实际结果中包含了每个检测点的实际结果。根据检测用例中每个检测点的预期返回结果可以校验实际结果中每个检测点的实际结果是否正确，以此来判断目标服务是否可用。

通过本申请实施例可以利用代码覆盖度(代码覆盖度是指程序运行过程中，执行过的代码与代码总量的比例)，自动化筛选出总代码覆盖度达到预设条件的目标服务请求组合，根据目标服务请求组合中的目标服务请求对应的代码覆盖数据和第一返回结果获取检测点，以及自动生成用于拨测目标服务的检测用例。可以有效降低人工编写检测用户繁琐度，节省人力物力；且能够避免检测点不全面，导致不能全面对目标服务的各项功能进行检测；对于各种复杂业务场景，本申请都可适用。

图2为本申请另一实施例提供的一拨测方法的流程示意图；在图1的基础上，该方法还包括以下步骤：

S700：调用每条检测用例以对目标服务进行拨测，得到对应的实际返回结果；

S800：分别将实际返回结果与对应的预期返回结果进行对比，以判断目标服务是否可用。

具体地，检测用例生成后，可以分别调用每个检测用例对目标服务进行有针对性的拨测，得到对应的实际返回结果。根据检测用例的预期返回结果可以判断对应的实际返回结果是否正确，进而判断目标服务是否可用。

在一个具体实施例中，每隔预设拨测间隔重复步骤S100-S800以更新检测用例，并使用更新的检测用例对目标服务进行拨测。预设拨测间隔可以根据实际应用场景设置。

每隔预设拨测间隔对检测用例进行更新，并对目标服务周期性拨测可以保证自动生成的检查用例的时效性，根据业务特点(服务改动的频率)，周期性检测目标服务。

在一个实施例中，步骤S200具体包括以下步骤：

S210(图1中未示出)：获取多个不同服务请求组合，每个服务请求组合包括至少一条服务请求。

S220(图1中未示出)：分别获取各个服务请求组合中所有服务请求对应的代码覆盖数据的并集。

S230(图1中未示出)：获取并集所包含的总代码覆盖数据与目标服务的总代码量的比值作为对应的总代码覆盖度。

具体地，预设时间段内收集了很多服务请求对应的代码覆盖数据，理论上服务请求组合可以包括任意一个或多个服务请求。为了使目标服务请求组合中的所有服务请求尽可能覆盖到目标服务的所有业务功能，本申请实施例通过使服务请求组合中的所有服务请求对应的代码覆盖数据的并集尽可能接近该目标服务所包含的总代码量为目的，以筛选出最优的目标服务请求组合。

所有服务请求对应的代码覆盖数据的并集与目标服务所包含的总代码量的差异度可以通过总代码覆盖度体现。总代码覆盖度是并集所包含的总代码覆盖数据与所述目标服务的总代码量的比值。总代码覆盖度越大，表示并集所包含的总代码覆盖数据越多，越接近总代码量。也表示此服务请求组合越能全面体现目标服务的各项业务功能。

在一个具体实施例中，S210具体包括：从获取到的所有服务请求中剔除子服务请求，得到代码覆盖数据存在差异或不完全相同的多个第一候选服务请求；

子服务请求的代码覆盖数据为任意一个其他服务请求的代码覆盖数据的子集，子服务请求为预设时间段内获取的服务请求；

从多个第一候选服务请求中筛选出代码覆盖数据与其他任何第一候选服务请求对应的代码覆盖数据都没有交集的第二候选服务请求；

将除了第二候选服务请求以外的其他第一候选服务请求作为第三候选服务请求；

将第二候选服务请求作为必选候选请求，与一个或多个第三候选服务请求进行组合得到多个不同服务请求组合。

在一个具体实施例中，采用贪心算法获取各个服务请求组合中所有服务请求对应的代码覆盖数据的并集。

具体地，所有服务请求中，有的服务请求对应的代码覆盖数据可能是其他某个或多个服务请求对应的代码覆盖数据的子集。还有的服务请求对应的代码覆盖数据之间可能有交集。

将代码覆盖数据为其他代码覆盖数据的子集的服务请求作为其他代码覆盖数据对应的服务请求的子服务请求。剔除子服务请求可以减少数据的重复。

多个第一候选服务请求中包含至少一个第一候选服务请求，且，任意两个第一候选服务请求对应的代码覆盖数据有差异，且，没有子集关系。这样不仅可以保证所有第一候选服务请求对应的代码覆盖数据的并集尽可能覆盖多的代码，且，尽可能减少数据的重复。

任意一个第二候选服务请求为第一候选服务请求中其对应的代码覆盖数据与其他第一候选服务请求对应的代码覆盖数据没有交集的第一候选服务请求。为了保证最终得到的目标服务请求中所有目标服务请求对应的代码覆盖数据最多，因此，需要筛选出包含唯一代码覆盖数据的第二候选服务请求。第二候选服务请求是任意一个服务请求组合中的必选候选请求，必选候选请求对应的代码覆盖数据也是其他第一候选服务请求不包含的代码覆盖数据。

本实施例将第一候选服务请求划分为第二候选服务请求(必选服务请求)和第三候选服务请求(第一候选服务请求中除了第二服务请求以外的其他第一候选服务请求)。任意一个服务请求组合都必须包含第二候选服务请求。

通过本实施例可以剔除包含重复代码覆盖数据的子服务请求，筛选出必选服务请求，使得最后得到的每个服务请求组合所包含的代码覆盖数据尽可能全面(即尽可能包含该目标服务的所有代码)，且，尽可能减少代码覆盖数据的重复。

S240：获取总代码覆盖度达到代码覆盖度阈值的候选服务请求组合。

具体地，总代码覆盖度为服务请求组合中所有服务请求对应的代码覆盖数据的并集所包含的总代码覆盖数据与目标服务的总代码量的比值。

代码覆盖度阈值可以是预先设置的一个预设值，也可以是所有服务请求组合对应的所有总代码覆盖度中的最大代码覆盖度。

预设时间段可以是预先设置的一个时间段，也可以是最大代码覆盖度达到一个稳定不变的代码覆盖度所经历的一段时间。

所有服务请求组合中总代码覆盖度达到代码覆盖度阈值的服务请求组合可能有多个，即，候选服务请求组合可能有一个或多个。

S250：获取每个候选服务请求组合中服务请求的数量。

S260：将所包含的服务请求的数量最少的候选服务请求组合作为目标服务请求组合。

具体地，理论上，总代码覆盖度最大的候选服务请求组合能够最多和最全面的接近目标服务的总代码，但是总代码覆盖度最大的候选服务请求组合可能包含了非常多的重复代码覆盖数据，即所包含的目标服务请求的代码覆盖数据可能有非常多重合的数据。这样会导致最终得到的目标服务请求非常多，相应地，生成的检测用例也非常多。在使用生成的检测用例对目标服务进行拨测的时候会带来巨大的测试工作量。

因此需要兼顾总代码覆盖度最优且所包含的服务请求最少，来筛选出最终的目标服务请求组合。候选服务请求组合中的服务请求代表了相同的目标服务的业务功能，在多个候选服务请求组合中，选择服务请求数量最少的候选服务请求组合作为目标服务请求组合可以尽量减少提取重复的检测点，减小生成拨测相同业务服务的检测用例的可能，尽可能避免检测用例的重复。也能保证在拨测目标服务的时候不会对相同的业务服务反复拨测。

在一个实施例中，步骤S600具体包括：

S610(图1中未示出)：根据目标服务请求的检测点分别获取对应的请求参数。

具体地，请求参数与检测点具有对应关系。请求参数是向目标服务发送拨测请求或服务请求携带的参数，请求参数表征了请求的目的。

S620(图1中未示出)：根据目标服务请求的检测点和预期返回结果分别获取对应的检测规则。

具体地，检测规则具体为预期返回结果与实际返回结果的匹配或对比规则，即，根据预期返回结果如何检测实际返回结果是否正确的规则。每种检测点对应的预期返回结果不同，因此检测规则可能不同。例如，有的预期返回结果是字符串，有的可能是数组，有的可能是数值，因此需要设置不同的检测规则。

在一个具体实施例中，可以通过可视化界面向工程人员展示检测点和预期返回值，工程人员根据检测点和预期返回值的类型可以提供每个检测点对应的检测规则。即，通过可视化界面接收工程人员定义的检测规则。更具体地，可视化界面可以设置有规则的定义组件，工程人员通过定义组件，以定义检测规则。

S630：根据对应的请求地址、请求参数、检测点、预期返回结果和检测规则分别生成对应的目标服务请求的检测用例。

具体地，一个检测用例包括了对应的请求地址、请求参数、检测点、每个检测点的预期返回结果和检测规则，因为每个检测点对应的数据可能不同，因此，检测规则可能不同；请求地址和请求参数用于生成检测用例对应的拨测请求，预期返回结果和检测规则用于对返回的实际返回结果进行自动校验。

请求地址实际为URL地址；请求参数为调用目标服务某个业务功能时，提供给该目标服务所要执行的代码的赋值；拨测请求中携带了请求地址和请求参数；拨测平台的服务器调用检测用例时，根据请求地址和请求参数生成拨测请求，并向目标服务发送拨测请求；目标服务接收到拨测请求后根据请求地址和请求参数查询并执行对应的代码，并将得到的实际返回结果返回给拨测平台对应的服务器。

实际返回结果包括了每个检测点的实际结果，拨测平台对应的服务器根据检测用例中每个检测点的预期返回结果、对应的检测规则对每个检测点的实际结果进行检验，以判断每个检测点的实际结果是否准确或符合预期。如果实际返回结果中存在任意一个检测点的实际结果与预期返回结果差异性超过预期，则判定目标服务中该检测点所对应的子功能不能正常运行，进而判断目标服务的该业务功能是否正常可用。

在一个实施例中，步骤S700具体包括：分别调用每条检测用例以向目标服务发送拨测请求，拨测请求携带对应的目标服务请求的请求地址和对应的请求参数，以使目标服务根据请求参数返回对应的实际返回结果。

具体地，本申请实施例应用于拨测平台。每条检测用例用于检测目标服务的一项业务功能，拨测平台分别调用每条检测用例用于对目标服务的每项业务功能进行检测。

调用检测用例时，会生成拨测请求，拨测请求与服务请求类似，拨测请求是为了检测目标服务的性能的特定请求，服务请求是任意用户访问目标服务产生的请求。本申请实施例将用户访问目标服务产生的服务请求对应的相关数据作为样本数据，以自动生成该目标服务的检测用例。然后使用生成的检测用例对目标服务进行有针对性的检测。

步骤S800具体包括：

分别根据对应的检测规则将实际返回结果与对应的预期返回结果进行对比；

若存在任意一个实际返回结果与对应的预期返回结果不匹配，则判定目标服务不可用。

具体地，目标服务接收到拨测请求后会执行对应的代码，并返回对应的实际返回结果至拨测平台。

拨测平台会根据基于检测规则和预期返回结果对对应的实际返回结果进行检测，通过检测结果可以判断目标服务对应的业务功能是否可用。如果检测结果中存在任意一个实际返回结果与对应的预期返回结果不匹配，则判定目标服务不可用。如果所有检测结果均为实际返回结果与对应的预期返回结果匹配，则判定目标服务可用。

本申请实施例的拨测方法可以应用于软件服务业务监控平台，但不局限于此。

通过本申请实施例拨测检查用例自动化方式生成，减少人工成本。利用代码覆盖度作为衡量检测用例的一种指标，提高了检查用例的覆盖度。提高了检查用例的时效性，能够自动根据服务的改动情况自动调节测试用例。对于复杂业务场景自动化生成检测用例更加智能化。

下面以一个具体实施例来说明本申请的工作原理：

拨测系统或拨测平台加载预先构建的代码覆盖统计工具，持续收集目标服务接收到每个服务请求后运行过程中执行过的代码行得到代码覆盖数据，并建立服务请求与代码覆盖数据的映射关系。

获取到预设时间段内每条服务请求对应的代码覆盖数据后，对这些服务请求对应的代码覆盖数据通过贪心算法，获得总代码覆盖度尽可能大，且包含的服务请求的数量尽可能少的目标服务请求组合。

目标服务请求组合包括至少一条目标服务请求。总代码覆盖度为对目标服务请求组合中所有目标服务请求对应的代码覆盖数据求并集得到的已执行的代码量与目标服务所包含的总代码量的比值。

拨测系统或拨测平台还用于收集到每条目标服务请求对应的第一返回结果。通过对第一返回结果进行解析获取到每条目标服务请求对应的检查点。另外，在目标服务设计完成后，如果不出错，目标服务能够实现各种业务功能，其各种业务功能的理论结果或预期返回结果是已知的，因此，根据检查点可以从预设的期望表中能够查找到其预期返回结果，根据预期返回结果的数据类型可以获取到对应的检测规则，根据预期返回结果可以获取到对应的请求参数。再次，根据目标服务请求还可以提取出对应的请求地址。

拨测平台的服务器调用检测用例时，根据请求地址和请求参数生成拨测请求，其中，请求地址作为访问目标服务的URL地址，并向目标服务发送拨测请求；目标服务接收到拨测请求后根据请求地址和请求参数查询并执行对应的代码，并将得到的实际返回结果返回给拨测平台对应的服务器。

实际返回结果包括了每个检测点的实际结果，拨测平台对应的服务器根据检测用例中每个检测点的预期返回结果、对应的检测规则对每个检测点的实际结果进行检验，以判断每个检测点的实际结果是否准确或符合预期。如果实际返回结果中存在任意一个检测点的实际结果与预期返回结果差异性超过预期，则判定目标服务中该检测点所对应的子功能不能正常运行，进而判断目标服务的该业务功能是否正常可用。

每个检测用例用于检测目标服务不同的功能，因此，为了提高时效性，可以周期性重复调用一遍所有检测用例对目标服务进行一次全面探测，实现对目标服务的可用性进行自动化地周期性探测和监控，不仅减少了人工成本，也提高了监测的效率。

本申请实施例实现了拨测检测用例自动化生成，减少人工成本，利用代码覆盖度作为衡量检测用例的一种指标，提高了检测用例的覆盖度，另外，由于检测用例全自动化生成且可以动态收集新的数据，因此，能够自动根据目标服务的改动自动调整更新检测用例，提高了检测用例的时效性，使得检测用例能够有效地对目标服务进行探测。

应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

图3为本申请一实施例提供的一拨测装置的结构框图；该拨测装置包括：

数据采集模块100，用于获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；

筛选模块200，用于根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；

检测点获取模块300，用于根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；

预期结果获取模块400，用于获取每个检测点对应的预期返回结果；

提取模块500，用于从目标服务请求中提取出对应的目标服务请求的请求地址；

检测用例生成模块600，用于根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

图4为本申请另一实施例提供的一拨测装置的结构框图，在图3的基础上，该拨测装置还包括：

拨测模块700，用于调用每条检测用例以对目标服务进行拨测，得到对应的实际返回结果；

判断模块800，用于分别将实际返回结果与对应的预期返回结果进行对比，以判断目标服务是否可用。

在一个实施例中，筛选模块200具体包括：

组合模块，用于获取多个不同服务请求组合，每个服务请求组合包括至少一条服务请求；

数据处理模块，用于分别获取各个服务请求组合中所有服务请求对应的代码覆盖数据的并集；

计算模块，用于获取并集所包含的总代码覆盖数据与目标服务的总代码量的比值作为对应的总代码覆盖度；

第一子筛选模块，用于获取总代码覆盖度达到代码覆盖度阈值的候选服务请求组合；

统计模块，用于获取每个候选服务请求组合中服务请求的数量；

第二子筛选模块，用于将所包含的服务请求的数量最少的候选服务请求组合作为目标服务请求组合。

在一个实施例中，代码覆盖度阈值为预设值，或，代码覆盖度阈值为所有服务请求组合中的最大代码覆盖度。

在一个实施例中，检测用例生成模块600具体包括：

请求参数获取模块，用于根据目标服务请求的检测点分别获取对应的请求参数；

规则获取模块，用于根据目标服务请求的检测点和预期返回结果分别获取对应的检测规则；

子生成模块，用于根据对应的请求地址、请求参数、检测点、预期返回结果和检测规则分别生成对应的目标服务请求的检测用例。

在一个实施例中，拨测模块700具体用于：分别调用每条检测用例以向目标服务发送拨测请求，拨测请求携带对应的目标服务请求的请求地址和对应的请求参数，以使目标服务根据请求参数返回对应的实际返回结果。

在一个实施例中，判断模块800具体包括：

匹配模块，用于分别根据对应的检测规则将实际返回结果与对应的预期返回结果进行对比；

判定模块，用于若存在任意一个实际返回结果与对应的预期返回结果不匹配，则判定目标服务不可用。

图5为本申请一实施例提供的计算机设备的内部结构框图。如图5所示，该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、输入装置和显示屏。其中，该计算机设备的处理器用于提供计算和控制能力。存储器包括存储介质和内存储器。存储介质可以是非易失性存储介质，也可以是易失性存储介质。存储介质存储有操作系统，还可存储有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器实现拨测方法。该内存储器为存储介质中的操作系统和计算机可读指令的运行提供环境。该内存储器中也可储存有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行拨测方法。该计算机设备的网络接口用于与外部服务器通过网络连接通信。计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机可读指令(例如计算机程序)，处理器执行计算机可读指令时实现上述实施例中拨测方法的步骤，例如图1所示的步骤S100至步骤S600及该方法的其它扩展和相关步骤的延伸。或者，处理器执行计算机可读指令时实现上述实施例中拨测装置的各模块/单元的功能，例如图3所示模块100至模块600的功能。为避免重复，这里不再赘述。

处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

存储器可用于存储计算机可读指令和/或模块，处理器通过运行或执行存储在存储器内的计算机可读指令和/或模块，以及调用存储在存储器内的数据，实现计算机装置的各种功能。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。

存储器可以集成在处理器中，也可以与处理器分开设置。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；根据目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；获取每个检测点对应的预期返回结果；从目标服务请求中提取出对应的目标服务请求的请求地址；根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

在一个实施例中，处理器执行计算机程序时还实现上述任一项拨测方法的各个步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，第一返回结果为目标服务接收到服务请求运行后返回的响应信息；根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，目标服务请求组合包括至少一条目标服务请求；根据目标服务请求的第一返回结果，分别获取对应的检测点；获取每个检测点对应的预期返回结果；从目标服务请求中提取出对应的目标服务请求的请求地址；根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

在一个实施例中，计算机程序被处理器执行时还实现上述任一项拨测方法的各个步骤。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种拨测方法，其特征在于，所述方法包括：

获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，所述代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，所述第一返回结果为所述目标服务接收到服务请求运行后返回的响应信息；

根据所述服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，所述目标服务请求组合包括至少一条目标服务请求；

根据所述目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；

获取每个所述检测点对应的预期返回结果；

从所述目标服务请求中提取出对应的目标服务请求的请求地址；

根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

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

调用每条所述检测用例以对所述目标服务进行拨测，得到对应的实际返回结果；

分别将所述实际返回结果与对应的预期返回结果进行对比，以判断所述目标服务是否可用。

3.根据权利要求1所述的方法，其特征在于，所述根据所述服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，包括：

获取多个不同服务请求组合，每个所述服务请求组合包括至少一条所述服务请求；

分别获取各个所述服务请求组合中所有服务请求对应的代码覆盖数据的并集；

获取所述并集所包含的总代码覆盖数据与所述目标服务的总代码量的比值作为对应的总代码覆盖度；

获取总代码覆盖度达到代码覆盖度阈值的候选服务请求组合；

获取每个所述候选服务请求组合中服务请求的数量；

将所包含的服务请求的数量最少的候选服务请求组合作为目标服务请求组合。

4.根据权利要求3所述的方法，其特征在于，所述代码覆盖度阈值为预设值，或，所述代码覆盖度阈值为所有所述服务请求组合中的最大代码覆盖度。

5.根据权利要求2所述的方法，其特征在于，所述根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例，包括：

根据所述目标服务请求的检测点分别获取对应的请求参数；

根据所述目标服务请求的检测点和预期返回结果分别获取对应的检测规则；

根据对应的请求地址、请求参数、检测点、预期返回结果和检测规则分别生成对应的目标服务请求的检测用例。

6.根据权利要求5所述的方法，其特征在于，所述调用每条所述检测用例以对所述目标服务进行拨测，得到对应的实际返回结果，包括：

分别调用每条检测用例以向所述目标服务发送拨测请求，所述拨测请求携带对应的目标服务请求的请求地址和对应的请求参数，以使所述目标服务根据所述请求参数返回对应的实际返回结果。

7.根据权利要求5所述的方法，其特征在于，所述分别将所述实际返回结果与对应的预期返回结果进行对比，以判断所述目标服务是否可用，包括：

分别根据对应的检测规则将所述实际返回结果与对应的预期返回结果进行对比；

若存在任意一个实际返回结果与对应的预期返回结果不匹配，则判定所述目标服务不可用。

8.一种拨测装置，其特征在于，所述装置包括：

数据采集模块，用于获取预设时间段内每条服务请求对应的代码覆盖数据和第一返回结果，所述代码覆盖数据为待拨测的目标服务接收到服务请求后运行过程中执行过的代码，所述第一返回结果为所述目标服务接收到服务请求运行后返回的响应信息；

筛选模块，用于根据服务请求的代码覆盖数据获取总代码覆盖度达到预设条件的目标服务请求组合，所述目标服务请求组合包括至少一条目标服务请求；

检测点获取模块，用于根据所述目标服务请求的第一返回结果，分别获取每条目标服务请求对应的检测点；

预期结果获取模块，用于获取每个所述检测点对应的预期返回结果；

提取模块，用于从所述目标服务请求中提取出对应的目标服务请求的请求地址；

检测用例生成模块，用于根据对应的请求地址、检测点和预期返回结果分别生成对应的目标服务请求的检测用例。

9.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，使得所述处理器执行如权利要求1-7任一项所述的方法的步骤。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时执行如权利要求1-7任一项所述的方法的步骤。