CN115292163A - 应用程序的检测方法、装置及计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种应用程序的检测方法、装置及计算机可读存储介质，涉及金融科技领域或其他相关领域。其中，该方法包括：获取应用程序的待检测信息；根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据；根据运行数据确定应用程序的状态信息。本申请解决了现有技术中人工检测应用程序的代码执行逻辑所导致的检测效率低的技术问题。

Description

应用程序的检测方法、装置及计算机可读存储介质

技术领域

本申请涉及金融科技领域或其他相关领域，具体而言，涉及一种应用程序的检测方法、装置及计算机可读存储介质。

背景技术

在应用程序的开发以及维护的过程中，对于新开发的应用程序或者改造后的应用程序，通常都需要进行一系列的检测，例如，对应用程序中发生更新的代码部分进行检测，以便确认代码执行逻辑是否符合开发人员的预期要求。

但是，在现有技术中，软件开发项目投产之后，大部分的应用程序依赖于人工方式分析代码的执行逻辑，例如，测试人员在应用程序上生成业务单据，并观察业务单据的流转过程以及相关生成结果，最后根据流转过程及相关生成结果确应用程序是否存在异常。但是，这种检测方式的检测结果难以把控，很大程度上依赖于测试人员的个人能力与经验，因此，不仅会影响到检测结果的准确性，而且会导致检测效率较低的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种应用程序的检测方法、装置及计算机可读存储介质，以至少解决现有技术中人工检测应用程序的代码执行逻辑所导致的检测效率低的技术问题。

根据本申请实施例的一个方面，提供了一种应用程序的检测方法，包括：获取应用程序的待检测信息；根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据；根据运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

进一步地，待检测信息至少包括如下之一：应用程序中更新的第一代码、应用程序中用于实现目标业务的第二代码以及应用程序中圈复杂度大于预设阈值的第三代码，目标业务为满足预设业务场景的业务，圈复杂度用于表征代码的复杂程度，圈复杂度与代码的复杂程度正相关。

进一步地，应用程序的检测方法还包括：获取应用程序中的多个业务场景标识，其中，每个业务场景标识与应用程序所要实现的业务场景相对应；从多个业务场景标识中确定目标业务场景标识，其中，目标业务场景标识所表征的业务场景为预设业务场景；根据目标业务场景标识，从程序脚本中确定第二代码。

进一步地，应用程序的检测方法还包括：获取应用程序当前版本的程序脚本以及上一版本的程序脚本；根据当前版本的程序脚本以及上一版本的程序脚本确定第一代码。

进一步地，应用程序的检测方法还包括：获取待检测信息的应用场景类型，其中，应用场景类型至少包括：前端应用场景、后端应用场景；根据应用场景类型确定埋点位置。

进一步地，应用程序的检测方法还包括：在应用场景类型为前端应用场景的情况下，获取待检测信息的代码格式；根据代码格式以及待检测信息在程序脚本的位置确定埋点位置。

进一步地，应用程序的检测方法还包括：在应用场景类型为后端应用场景的情况下，获取待检测信息的功能类型以及代码格式，其中，功能类型用于表征待检测信息所要实现的业务逻辑；根据功能类型、代码格式以及待检测信息在程序脚本中的位置确定埋点位置。

进一步地，应用程序的检测方法还包括：前端应用场景至少包括客户端展示场景以及网页展示场景，在根据运行数据确定应用程序的状态信息之前，在前端应用场景为客户端展示场景的情况下，将运行数据存储在预设存储区域中，并每间隔预设时长将运行数据发送至服务器中；在前端应用场景为网页展示场景的情况下，将运行数据存储在与网页相对应的数据库中，并在网页关闭时将运行数据发送至服务器中，其中，网页为根据待检测信息生成的展示网页。

进一步地，应用程序的检测方法还包括：在运行数据与预设的目标结果相匹配时，确定应用程序正常运行待检测信息，其中，目标结果表征应用程序在运行待检测信息时应生成的正常数据；在运行数据与目标结果不匹配时，确定应用程序在运行待检测信息时存在异常。

根据本申请实施例的另一方面，还提供了一种应用程序的检测装置，包括：获取模块，用于获取应用程序的待检测信息；第一确定模块，用于根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据；第二确定模块，用于根据运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的应用程序的检测方法。

根据本申请实施例的另一方面，还提供了一种电子设备，该电子设备包括一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述的应用程序的检测方法。

在本申请实施例中，采用通过埋点获取运行数据，并根据运行数据对应用程序进行检测的方式，在获取应用程序的待检测信息之后，根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据，最后根据运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

由上述内容可知，由于本申请是通过待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，因此本申请中的埋点可以准确地获取得到应用程序在运行待检测信息时所生成的运行数据，需要注意到的是，由于运行数据是应用程序实际生成的数据，因此，通过分析运行数据即可自动化地确定应用程序在运行过程中是否出现了异常情况，即可以确定应用程序的状态信息。本申请通过埋点自动化监控了待检测信息的执行过程以及相关生成结果，从而避免了现有技术中采用人工方式检测应用程序时所存在的检测效率低的问题。

由上述分析可知，通过本申请的技术方案，达到了自动检测应用程序的目的，实现了提高应用程序的检测效率以及准确度的效果，进而解决了现有技术中人工检测应用程序的代码执行逻辑所导致的检测效率低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的应用程序的检测方法的流程图；

图2是根据本申请实施例的一种可选的应用程序的检测装置的示意图；

图3是根据本申请实施例的一种可选的电子设备的示意图。

具体实施方式

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

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

另外，还需要说明的是，本公开所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。例如，本系统和相关用户或机构间设置有接口，在获取相关信息之前，需要通过接口向前述的用户或机构发送获取请求，并在接收到前述的用户或机构反馈的同意信息后，获取相关信息。

实施例1

根据本申请实施例，提供了一种应用程序的检测方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

另外，还需要说明的是，一种应用程序检测系统可以作为本申请实施例中的应用程序的检测方法的执行主体。该应用程序检测系统可以在电子设备上运行。

图1是根据本申请实施例的一种可选的应用程序的检测方法的流程图，如图1所示，该方法包括如下步骤：

步骤S101，获取应用程序的待检测信息。

在步骤S101中，待检测信息至少包括如下之一：应用程序中更新的第一代码、应用程序中用于实现目标业务的第二代码以及应用程序中圈复杂度大于预设阈值的第三代码，目标业务为满足预设业务场景的业务，圈复杂度用于表征代码的复杂程度，圈复杂度与代码的复杂程度正相关。

具体的，上述的第一代码可以是在对应用程序进行升级或者修改时，对应用程序的一部分代码进行更新后的代码，其中，更新操作至少包括：增加代码、删除代码、修改代码等等。由于第一代码是更新后的代码，因此，这些代码是必须要进行检测的，以确保验证更新后的代码符合预期要求。

上述的第二代码可以是应用程序中用于实现重要业务(对应目标业务)的代码，例如，以应用程序为一款金融软件为例，重要业务可以是大额交易、跨国交易、用户隐私数据加密等业务。其中，目标业务可以由技术人员通过设置预设业务场景所确定，例如，预设业务场景是跨国交易的业务场景，则该业务场景下的跨国贵金属交易业务、跨国期货交易业务等业务都属于目标业务。通过对第二代码进行检测，可以确保重要业务的稳定运行，提高应用程序的稳定性。

上述的第三代码可以是应用程序中复杂程度较高的代码，这些代码由于较为复杂，因此需要重点检测。具体的，可以将应用程序按照功能模块进行细化，得到多个子程序，然后基于每个子程序构建一个控制流图，最后根据控制流图计算该子程序的圈复杂度。需要注意到的是，复杂程度较高的代码更加容易出现执行错误的情况，因此，对第三代码进行检测，可进一步地提高应用程序的稳定性。

另外，应用程序是一个整体，在对部分代码进行了修改的情况下，其可能还会影响到未修改的代码的执行情况，如果开发人员事先没有了解到更新后的代码对于其他未修改的代码的相关影响，则很可能导致应用程序出现无法预知的异常。为了避免这种情况，本申请通过第一代码、第二代码以及第三代码三个维度对应用程序进行检测，不仅可以验证更新的代码的执行状况，还可以验证重要业务的运行情况以及复杂代码的执行情况，从而提高了对应用程序的检测全面性。

步骤S102，根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点。

在步骤S102中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据。

具体的，上述的埋点可以理解为是一种植入应用程序中的脚本，在应用程序运行至埋点位置时，通过埋点即可获取得到应用程序在该埋点位置所生成的数据。由于埋点可以在不影响应用程序的运行的情况下，监控应用程序生成的运行数据，因此，通过埋点可以实现对应用程序的监控。

另外，由于本申请主要是通过检测待检测信息实现检测应用程序的，因此，本申请首先是根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，然后在埋点位置生成埋点，以便准确地获取得到应用程序在运行待检测信息时生成数据。

步骤S103，根据运行数据确定应用程序的状态信息。

具体的，状态信息用于表征应用程序在运行待检测信息时的运行状态。在对应用程序进行检测之前，技术人员通常会根据待检测信息预先生成对应的目标结果，其中，目标结果表征应用程序在运行待检测信息时应生成的正常数据，换言之，目标结果是检测过程中的对照组数据，其是真实准确的。在此基础上，在得到运行数据之后，如果运行数据与目标结果相匹配，则可以确定应用程序正常运行待检测信息，应用程序为正常程序；如果运行数据与目标结果不匹配，则可以确定应用程序在运行待检测信息时存在异常，应用程序为异常程序。需要说明的是，相匹配可以是相同，也可以是符合目标结果所限定的条件。举例而言，如果目标结果是一个数值，则只有在运行数据和目标结果相同时，才能确定运行数据和目标结果相匹配；如果目标结果是一个数据范围，则只要在运行数据位于这个数据范围之内，便可以确定运行数据和目标结果相匹配。

另外，需要注意到的是，本申请在对应用程序进行检测时，可以在灰度环境下进行检测，具体的，可以先在灰度环境进行检测，在检测应用程序无异常之后，再在正式服务器中部署或者升级应用程序，这种检测方式可以确保应用程序的稳定性，有利于提高应用程序的用户使用体验。

由上述步骤S101至步骤S103的内容可知，在本申请实施例中，采用通过埋点获取运行数据，并根据运行数据对应用程序进行检测的方式，在获取应用程序的待检测信息之后，根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据，最后根据运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

由上述内容可知，由于本申请是通过待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，因此本申请中的埋点可以准确地获取得到应用程序在运行待检测信息时所生成的运行数据，需要注意到的是，由于运行数据是应用程序实际生成的数据，因此，通过分析运行数据即可自动化地确定应用程序在运行过程中是否出现了异常情况，即可以确定应用程序的状态信息。本申请通过埋点自动化监控了待检测信息的执行过程以及相关生成结果，从而避免了现有技术中采用人工方式检测应用程序时所存在的检测效率低的问题。

由上述分析可知，通过本申请的技术方案，达到了自动检测应用程序的目的，实现了提高应用程序的检测效率以及准确度的效果，进而解决了现有技术中人工检测应用程序的代码执行逻辑所导致的检测效率低的技术问题。

在一种可选的实施例中，应用程序检测系统可获取应用程序中的多个业务场景标识，其中，每个业务场景标识与应用程序所要实现的业务场景相对应。然后，应用程序检测系统从多个业务场景标识中确定目标业务场景标识，其中，目标业务场景标识所表征的业务场景为预设业务场景。最后，应用程序检测系统根据目标业务场景标识，从程序脚本中确定第二代码。

具体的，仍以应用程序为一款金融软件为例，金融软件中至少包括有业务场景标识1、业务场景标识2以及业务场景标识3，其中，业务场景标识1对应的是金融软件所要实现的跨国交易业务场景，业务场景标识2对应的是金融软件所要实现的大额交易业务场景，业务场景标识3对应的是金融软件所要实现的用户隐私数据加密业务场景。在此基础上，如果技术人员所预设的预设业务场景为跨国交易业务场景，则业务场景标识1即为目标业务场景标识。

需要说明的是，业务场景标识可以理解为是程序脚本中的业务描述代码，业务场景标识在程序脚本中是一定存在的，因此，在得到目标业务场景标识之后，应用程序检测系统可以根据业务场景标识在程序脚本中的位置或者描述信息，确定与预设业务场景相关的代码作为第二代码。例如，由于跨国交易业务是重要交易业务，因此将预设业务场景确定为跨国交易业务场景，跨国交易业务场景所对应的业务场景标识是业务场景标识1，在此基础上，如果在一行代码中发现了业务场景标识1，则确定这一行代码为第二代码。

在一种可选的实施例中，应用程序检测系统首先获取应用程序当前版本的程序脚本以及上一版本的程序脚本，然后根据当前版本的程序脚本以及上一版本的程序脚本确定第一代码。

具体的，通常而言，对应用程序进行检测，便是对应用程序当前版本的程序脚本进行检测，为了确保查找到当前版本的程序脚本中所有的更新内容，可以预先存储上一版本的程序脚本，然后将上一版本的程序脚本与当前版本的程序脚本进行比对，根据比对结果确定当前版本与上一版本中不同的代码，并将这些不同的代码确定为第一代码。

在一种可选的实施例中，应用程序检测系统获取待检测信息的应用场景类型，其中，应用场景类型至少包括：前端应用场景、后端应用场景，然后应用程序检测系统根据应用场景类型确定埋点位置。

可选的，不同的应用程序所应用的场景可能也不同，与之对应的，来自不同应用程序的待检测信息的应用场景也可能不同。通常而言，应用程序可以划分为两大应用场景，分别为前端应用场景与后端应用场景，因此，本申请将待检测信息的应用场景类型也划分为了前端应用场景以及后端应用场景。基于每种应用场景，应用程序检测系统确定埋点位置的方式也不同。

具体的，在应用场景类型为前端应用场景的情况下，应用程序检测系统首先获取待检测信息的代码格式，然后根据代码格式以及待检测信息在程序脚本的位置确定埋点位置。

可选的，上述前端应用场景可以划分为客户端、JS(java script,一种基于对象和事件驱动的解释型脚本语言)、RN(react native，一种开源的跨平台移动应用开发框架)。对于应用场景为前端应用场景的待检测信息，应用程序检测系统可按照方法粒度确定埋点位置，并在埋点位置生成埋点，以记录应用程序运行该待检测信息时的运行状况。具体的，方法粒度可以理解为是待检测信息的代码格式，举例而言，待检测信息可能是多个代码格式类型的代码文件，针对每种代码格式类型的代码文件，会对应有一种固定的埋点位置确定方法，例如，如果一个代码文件是XML格式类型，则确定该代码文件的末端为埋点位置。

另外，在应用场景类型为后端应用场景的情况下，应用程序检测系统获取待检测信息的功能类型以及代码格式，其中，功能类型用于表征待检测信息所要实现的业务逻辑。然后，应用程序检测系统根据功能类型、代码格式以及待检测信息在程序脚本中的位置确定埋点位置。

可选的，在应用场景类型为后端应用场景的情况下，应用程序检测系统可以按照功能分支粒度(对应功能类型)确定埋点位置，也可以按照方法粒度(对应代码格式)埋点。具体的，仍以应用程序为一款金融软件为例，待检测信息可以是金融软件上新增的两部分代码。其中，第一部分代码是要实现计算货品交易金额的业务逻辑，第二部分代码是要实现获取货品交易价格来源的业务逻辑。针对这两部分代码，应用程序检测系统可以采用不同的方式确定埋点位置，例如，对于第一部分代码，将埋点位置确定为在第一部分代码的结尾处；对于第二部分代码，将埋点位置确定为在第二部分代码的开头处。

另外，与前端应用场景一样，对于后端应用场景下的待检测信息，也可以根据代码格式确定埋点位置，在此不作过多赘述。

在一种可选的实施例中，表1示出了一种埋点的数据结构：

表1

需要说明的是，上述的子条目编号可以将业务需求与应用程序相关联，其中，业务需求中至少包括待检测信息所对应的目标结果。

在一种可选的实施例中，前端应用场景至少包括客户端展示场景以及网页展示场景，在前端应用场景为客户端展示场景的情况下，应用程序检测系统将运行数据存储在预设存储区域中，并每间隔预设时长将运行数据发送至服务器中；在前端应用场景为网页展示场景的情况下，应用程序检测系统将运行数据存储在与网页相对应的数据库中，并在网页关闭时将运行数据发送至服务器中，其中，网页为根据待检测信息生成的展示网页。

可选的，针对于前端应用场景中，可以根据展示方式的不同，继续划分为客户端展示场景以及网页展示场景。其中，在客户端展示场景下，应用程序检测系统会将埋点获取得到的运行数据暂时存储在预设存储区域中，例如，存储在应用程序检测系统所在的本地电脑上，然后定期每间隔一段预设时长将运行数据发送至服务器中。在网页展示场景下，由于网页都会有对应的数据库暂时存储信息，因此，应用程序检测系统会将网页展示场景下的运行数据存储在网页对应的数据库中，在网页关闭时，数据库自动地将运行数据发送至服务器中。

可选的，针对于后端应用场景，如果是根据功能类型确定的埋点位置，则应用程序检测系统将在埋点位置生成工具类EventTrackingOpStep作为埋点，并在获取得到运行数据后将运行数据存储至服务器中。如果是根据代码格式确定的埋点位置，则应用程序检测系统将在埋点位置生成工具类EventTrackingUtil，并在获取得到运行数据之后，将运行数据存储至服务器中。

在一种可选的实施例中，在运行数据与预设的目标结果相匹配时，应用程序检测系统确定应用程序正常运行待检测信息，其中，目标结果表征应用程序在运行待检测信息时应生成的正常数据；在运行数据与目标结果不匹配时，应用程序检测系统确定应用程序在运行待检测信息时存在异常。

具体的，在应用程序运行结束之后，应用程序检测系统可以从服务器中获取运行数据，然后解析分布式版本控制系统GIT版本库中的代码，得到预设的目标结果。通过比对运行数据与目标结果，如果两者相匹配，则确定应用程序正常运行待检测信息，应用程序为正常程序，如果两者不匹配，则确定应用程序在运行待检测信息时存在异常，应用程序为异常程序。

可选的，结合上述的数据结构表的内容，涉及到第一代码的验证情况，可以将第一代码对应的目标结果记录在埋点清单上，由于运行数据与目标结果可以通过子条目编号这一维度进行关联，因此，在将运行数据与埋点清单上的目标结果进行比对之后，可以导出未验证子条目清单，其中，未验证子条目清单上的运行数据是与目标结果不匹配的运行数据。后续技术人员可以根据实际需要自定义其他统计规则，例如覆盖率统计、灰度/非灰验证统计、客户端版本验证等。

需要注意到的是，与第一代码不同，第二代码是用于实现重要业务的代码，因此，第二代码在每次进行检测时都需要进行检测。在此基础上，可以将第二代码对应的目标结果以重要业务清单的形式进行记录，然后将第二代码所对应的运行数据与重要业务清单上的目标结果进行比对，导出未验证交易清单，其中，未验证交易清单上的运行数据是与重要业务清单上的目标结果不匹配的运行数据。

由上述分析可知，通过本申请的技术方案，达到了自动检测应用程序的目的，实现了提高应用程序的检测效率以及准确度的效果，进而解决了现有技术中人工检测应用程序的代码执行逻辑所导致的检测效率低的技术问题。

实施例2

根据本申请实施例，还提供了一种应用程序的检测装置，其中，图2是根据本申请实施例的一种可选的应用程序的检测装置的示意图，如图2所示，该装置包括：获取模块201，用于获取应用程序的待检测信息；第一确定模块202，用于根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据；第二确定模块203，用于根据运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

需要说明的是，上述获取模块201、第一确定模块202以及第二确定模块203对应于上述实施例1中的步骤S101至步骤S103，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。

可选的，上述的待检测信息至少包括如下之一：应用程序中更新的第一代码、应用程序中用于实现目标业务的第二代码以及应用程序中圈复杂度大于预设阈值的第三代码，目标业务为满足预设业务场景的业务，圈复杂度用于表征代码的复杂程度，圈复杂度与代码的复杂程度正相关。

可选的，上述获取模块还包括：第一获取模块、第三确定模块以及第四确定模块。其中，第一获取模块，用于获取应用程序中的多个业务场景标识，其中，每个业务场景标识与应用程序所要实现的业务场景相对应；第三确定模块，用于从多个业务场景标识中确定目标业务场景标识，其中，目标业务场景标识所表征的业务场景为预设业务场景；第四确定模块，用于根据目标业务场景标识，从程序脚本中确定第二代码。

可选的，上述获取模块还包括：第二获取模块以及第五确定模块。其中，第二获取模块，用于获取应用程序当前版本的程序脚本以及上一版本的程序脚本；第五确定模块，用于根据当前版本的程序脚本以及上一版本的程序脚本确定第一代码。

可选的，上述第一确定模块还包括：第三获取模块以及第六确定模块。其中，第三获取模块，用于获取待检测信息的应用场景类型，其中，应用场景类型至少包括：前端应用场景、后端应用场景；第六确定模块，用于根据应用场景类型确定埋点位置。

可选的，第六确定模块还包括：第四获取模块以及第七确定模块。其中，第四获取模块，用于在应用场景类型为前端应用场景的情况下，获取待检测信息的代码格式；第七确定模块，用于根据代码格式以及待检测信息在程序脚本的位置确定埋点位置。

可选的，第六确定模块还包括：第五获取模块以及第八确定模块。其中，第五获取模块，用于在应用场景类型为后端应用场景的情况下，获取待检测信息的功能类型以及代码格式，其中，功能类型用于表征待检测信息所要实现的业务逻辑；第八确定模块，用于根据功能类型、代码格式以及待检测信息在程序脚本中的位置确定埋点位置。

可选的，应用程序的检测装置还包括：第一发送模块以及第二发送模块。其中，第一发送模块，用于在前端应用场景为客户端展示场景的情况下，将运行数据存储在预设存储区域中，并每间隔预设时长将运行数据发送至服务器中；第二发送模块，用于在前端应用场景为网页展示场景的情况下，将运行数据存储在与网页相对应的数据库中，并在网页关闭时将运行数据发送至服务器中，其中，网页为根据待检测信息生成的展示网页。

可选的，上述的第二确定模块还包括：第九确定模块以及第十确定模块。其中，第九确定模块，用于在运行数据与预设的目标结果相匹配时，确定应用程序正常运行待检测信息，其中，目标结果表征应用程序在运行待检测信息时应生成的正常数据；第十确定模块，用于在运行数据与目标结果不匹配时，确定应用程序在运行待检测信息时存在异常。

实施例3

根据本申请实施例，还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述实施例1中的应用程序的检测方法。

实施例4

根据本申请实施例，还提供了一种电子设备实施例，其中，图3是根据本申请实施例的一种可选的电子设备的示意图，如图3所示，电子设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：

获取应用程序的待检测信息；根据待检测信息在应用程序所对应的程序脚本中的位置确定埋点位置，并在埋点位置生成埋点，其中，埋点用于采集运行数据，运行数据为应用程序在运行待检测信息时实际生成的数据；根据所述运行数据确定应用程序的状态信息，其中，状态信息用于表征应用程序在运行待检测信息时的运行状态。

可选的，待检测信息至少包括如下之一：应用程序中更新的第一代码、应用程序中用于实现目标业务的第二代码以及应用程序中圈复杂度大于预设阈值的第三代码，目标业务为满足预设业务场景的业务，圈复杂度用于表征代码的复杂程度，圈复杂度与代码的复杂程度正相关。

可选的，处理器执行程序时还实现以下步骤：获取应用程序中的多个业务场景标识，其中，每个业务场景标识与应用程序所要实现的业务场景相对应；从多个业务场景标识中确定目标业务场景标识，其中，目标业务场景标识所表征的业务场景为预设业务场景；根据目标业务场景标识，从程序脚本中确定第二代码。

可选的，处理器执行程序时还实现以下步骤：获取应用程序当前版本的程序脚本以及上一版本的程序脚本；根据当前版本的程序脚本以及上一版本的程序脚本确定第一代码。

可选的，处理器执行程序时还实现以下步骤：获取待检测信息的应用场景类型，其中，应用场景类型至少包括：前端应用场景、后端应用场景；根据应用场景类型确定埋点位置。

可选的，处理器执行程序时还实现以下步骤：在应用场景类型为前端应用场景的情况下，获取待检测信息的代码格式；根据代码格式以及待检测信息在程序脚本的位置确定埋点位置。

可选的，处理器执行程序时还实现以下步骤：在应用场景类型为后端应用场景的情况下，获取待检测信息的功能类型以及代码格式，其中，功能类型用于表征待检测信息所要实现的业务逻辑；根据功能类型、代码格式以及待检测信息在程序脚本中的位置确定埋点位置。

可选的，处理器执行程序时还实现以下步骤：前端应用场景至少包括客户端展示场景以及网页展示场景，在根据运行数据确定应用程序的状态信息之前，在前端应用场景为客户端展示场景的情况下，将运行数据存储在预设存储区域中，并每间隔预设时长将运行数据发送至服务器中；在前端应用场景为网页展示场景的情况下，将运行数据存储在与网页相对应的数据库中，并在网页关闭时将运行数据发送至服务器中，其中，网页为根据待检测信息生成的展示网页。

可选的，处理器执行程序时还实现以下步骤：在运行数据与预设的目标结果相匹配时，确定应用程序正常运行待检测信息，其中，目标结果表征应用程序在运行待检测信息时应生成的正常数据；在运行数据与目标结果不匹配时，确定应用程序在运行待检测信息时存在异常。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种应用程序的检测方法，其特征在于，包括：

获取应用程序的待检测信息；

根据所述待检测信息在所述应用程序所对应的程序脚本中的位置确定埋点位置，并在所述埋点位置生成埋点，其中，所述埋点用于采集运行数据，所述运行数据为所述应用程序在运行所述待检测信息时实际生成的数据；

根据所述运行数据确定所述应用程序的状态信息，其中，所述状态信息用于表征所述应用程序在运行所述待检测信息时的运行状态。

2.根据权利要求1所述的方法，其特征在于，所述待检测信息至少包括如下之一：所述应用程序中更新的第一代码、所述应用程序中用于实现目标业务的第二代码以及所述应用程序中圈复杂度大于预设阈值的第三代码，所述目标业务为满足预设业务场景的业务，所述圈复杂度用于表征代码的复杂程度，所述圈复杂度与所述代码的复杂程度正相关。

3.根据权利要求2所述的方法，其特征在于，获取应用程序的待检测信息，包括：

获取所述应用程序中的多个业务场景标识，其中，每个所述业务场景标识与所述应用程序所要实现的业务场景相对应；

从多个所述业务场景标识中确定目标业务场景标识，其中，所述目标业务场景标识所表征的业务场景为所述预设业务场景；

根据所述目标业务场景标识，从所述程序脚本中确定所述第二代码。

4.根据权利要求2所述的方法，其特征在于，获取应用程序的待检测信息，包括：

获取所述应用程序当前版本的程序脚本以及上一版本的程序脚本；

根据所述当前版本的程序脚本以及所述上一版本的程序脚本确定所述第一代码。

5.根据权利要求1所述的方法，其特征在于，根据所述待检测信息在所述应用程序所对应的程序脚本中的位置确定埋点位置，包括：

获取所述待检测信息的应用场景类型，其中，所述应用场景类型至少包括：前端应用场景、后端应用场景；

根据所述应用场景类型确定所述埋点位置。

6.根据权利要求5所述的方法，其特征在于，根据所述应用场景类型确定所述埋点位置，包括：

在所述应用场景类型为所述前端应用场景的情况下，获取所述待检测信息的代码格式；

根据所述代码格式以及所述待检测信息在所述程序脚本的位置确定所述埋点位置。

7.根据权利要求5所述的方法，其特征在于，根据所述应用场景类型确定所述埋点位置，包括：

在所述应用场景类型为所述后端应用场景的情况下，获取所述待检测信息的功能类型以及代码格式，其中，所述功能类型用于表征所述待检测信息所要实现的业务逻辑；

根据所述功能类型、所述代码格式以及所述待检测信息在所述程序脚本中的位置确定所述埋点位置。

8.根据权利要求5所述的方法，其特征在于，所述前端应用场景至少包括客户端展示场景以及网页展示场景，在根据所述运行数据确定所述应用程序的状态信息之前，所述方法还包括：

在所述前端应用场景为客户端展示场景的情况下，将所述运行数据存储在预设存储区域中，并每间隔预设时长将所述运行数据发送至服务器中；

在所述前端应用场景为网页展示场景的情况下，将所述运行数据存储在与网页相对应的数据库中，并在所述网页关闭时将所述运行数据发送至所述服务器中，其中，所述网页为根据所述待检测信息生成的展示网页。

9.根据权利要求1所述的方法，其特征在于，根据所述运行数据确定所述应用程序的状态信息，包括：

在所述运行数据与预设的目标结果相匹配时，确定所述应用程序正常运行所述待检测信息，其中，所述目标结果表征所述应用程序在运行所述待检测信息时应生成的正常数据；

在所述运行数据与所述目标结果不匹配时，确定所述应用程序在运行所述待检测信息时存在异常。

10.一种应用程序的检测装置，其特征在于，包括：

获取模块，用于获取应用程序的待检测信息；

第一确定模块，用于根据所述待检测信息在所述应用程序所对应的程序脚本中的位置确定埋点位置，并在所述埋点位置生成埋点，其中，所述埋点用于采集运行数据，所述运行数据为所述应用程序在运行所述待检测信息时实际生成的数据；

第二确定模块，用于根据所述运行数据确定所述应用程序的状态信息，其中，所述状态信息用于表征所述应用程序在运行所述待检测信息时的运行状态。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行权利要求1至9任一项中所述的应用程序的检测方法。

12.一种电子设备，其特征在于，包括一个或多个处理器和存储器，所述存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至9中任意一项所述的应用程序的检测方法。

Images