基于日志的测试全面性检测方法、装置、设备及存储介质

摘要

本申请公开一种基于日志的测试全面性检测方法、装置、设备及存储介质，其中，基于日志的测试全面性检测方法包括：从若干个服务器获取若干项目的代码运行产生的系统日志，并将若干项目的代码运行产生的系统日志写入目标数据库中；根据项目配置从目标数据库中匹配目标项目的系统日志；从目标项目的系统日志中获取目标项目的基础数据；根据基础数据计算得到目标项目的测试覆盖率、测试成功率；根据测试覆盖率、测试成功率作为分析结果发送至预设终端，以使得预设终端处的相关人员进行审计。用于对目标项目的代码的测试结果进行全面性的检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码测试。

说明书

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种基于日志的测试全面性检测方法、装置、设备及存储介质。

背景技术

目前，代码覆盖率或接口覆盖率形式进行测试情况检查的方法都存在不能进行项目及排期的测试全面性检查及风险预警的问题，即只能对某段代码进行检测，而无法反映代码所在项目的整体测试情况。

发明内容

本申请实施例的目的在于公开一种基于日志的测试全面性检测方法、装置、设备及存储介质，用于对目标项目的代码的测试结果进行全面性的检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码测试。

为此，本申请第一方面公开一种基于日志的测试全面性检测方法，所述方法包括：

从若干个服务器获取若干项目的代码运行产生的系统日志，并将所述若干项目的代码运行产生的系统日志写入目标数据库中；

根据项目配置从所述目标数据库中匹配目标项目的系统日志；

从所述目标项目的系统日志中获取所述目标项目的基础数据；

根据所述基础数据计算得到所述目标项目的测试覆盖率、测试成功率；

根据所述测试覆盖率、所述测试成功率作为分析结果发送至预设终端，以使得所述预设终端处的相关人员进行审计。

在本申请第一方面中，通过获取目标项目在测试产生的系统日志，可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

在本申请第一方面中，作为一种可选的实施方式，所述项目配置包括所述目标项目的开始时间、所述目标项目的结束时间；

以及，在所述根据所述测试覆盖率、所述测试成功率作为分析结果发送至预设终端之后，所述方法还包括：

获取当前系统时间；

根据所述目标项目的开始时间、所述目标项目的结束时间、所述当前系统时间计算所述目标项目的测试进度；

将所述目标项目的测试进度与预设进度阈值进行比较，若所述目标项目的进度小于所述预设进度阈值，则确定所述目标项目为滞后状态；

通过界面展示所述目标项目的滞后状态。

在本可选的实施方式中，根据目标项目的开始时间、目标项目的结束时间、当前系统时间能够计算目标项目的测试进度，进而能够将目标项目的测试进度与预设进度阈值进行比较，若目标项目的进度小于预设进度阈值，则可确定目标项目为滞后状态，并通过界面展示目标项目的滞后状态，最终便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请第一方面中，作为一种可选的实施方式，在所述确定所述目标项目为滞后状态之后，所述通过界面展示所述目标项目的滞后状态之前，所述方法还包括：

当所述目标项目的进度小于所述预设进度阈值时，根据所述目标项目的测试进度与预设进度阈值的比值确定所述目标项目的滞后风险等级。

在本可选的实施方式中，当目标项目的进度小于预设进度阈值时，能够根据目标项目的测试进度与预设进度阈值的比值确定目标项目的滞后风险等级，进而进一步便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请第一方面中，作为一种可选的实施方式，所述基础数据包括交易码、覆盖交易码、交易码的执行总次数、交易码执行成功次数。

在本申请第一方面中，作为一种可选的实施方式，所述根据所述基础数据计算得到所述目标项目的测试覆盖率、测试成功率，包括：

累计得到所述交易码的总次数和所述覆盖交易码的总次数；

将所述覆盖交易码的总次数与所述交易码的总次数的比值作为所述目标项目的测试覆盖率；

将所述交易码执行成功次数与所述交易码执行总次数的比值作为所述目标项目的测试成功率。

在本可选的实施方式中，通过累计得到交易码的总次数和覆盖交易码的总次数，进而能够将覆盖交易码的总次数与交易码的总次数的比值作为目标项目的测试覆盖率，与此同时，能够将交易码执行成功次数与交易码执行总次数的比值作为目标项目的测试成功率。

在本申请第一方面中，作为一种可选的实施方式，所述基础数据还包括响应码；

以及，所述方法还包括：

累计所述响应码的每个类型的总数，其中，所述响应码的类型为表征响应成功的响应码和表征响应失败的响应码中的一种；

根据所述响应码的每个类型的累计结果判断所述响应码只为一种类型，若是则生成覆盖不全的警告提示。

在本可选的实施方式中，当响应码只为一种类型，能够生成覆盖不全的警告提示，以便于操作人员及时了解目标项目的测试不全面。

在本申请第一方面中，作为一种可选的实施方式，所述方法还包括：

当所述目标项目被划分为若干个排期时，依次计算每个所述排期的测试覆盖率、测试成功率，并展示每个所述排期的测试覆盖率、测试成功率。

在本可选的实施方式中，当一个目标项目被划分为若干个排期进行测试时，通过计算每个排期的测试覆盖率、测试成功率，可向操作人员展示每个排期的测试覆盖率、测试成功率，这样一来，操作人员能够逐个了解每个排期的测试覆盖率、测试成功率，进而更加全面地了解目标项目中的测试覆盖率、测试成功率。

本申请第二方面公开一种基于日志的测试全面性检测装置，所述装置包括：

第一获取模块，用于从若干个服务器获取若干项目的代码运行产生的系统日志，并将所述若干项目的代码运行产生的系统日志写入目标数据库中；

匹配模块，用于根据项目配置从所述目标数据库中匹配目标项目的系统日志；

第二获取模块，用于从所述目标项目的系统日志中获取所述目标项目的基础数据；

第一计算模块，用于根据所述基础数据计算得到所述目标项目的测试覆盖率、测试成功率；

发送模块，用于根据所述测试覆盖率、所述测试成功率作为分析结果发送至预设终端，以使得所述预设终端处的相关人员进行审计。

本申请第二方面的装置通过本申请第一方面的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

本申请第三方面公开一种基于日志的测试全面性检测设备，所述设备包括：

处理器；以及

存储器，配置用于存储机器可读指令，所述指令在由所述处理器执行时，使得所述处理器执行如本申请第一方面公开的基于日志的测试全面性检测方法。

本申请第三方面的设备通过本申请第一方面的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

本申请第四方面公开一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行本申请第一方面公开的基于日志的测试全面性检测方法。

本申请第四方面的设备通过本申请第一方面的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。其中：

图1是本申请实施例公开的一种基于日志的测试全面性检测方法的流程示意图；

图2是本申请实施例公开的一种基于日志的测试全面性检测装置的结构示意图；

图3是本申请实施例公开的一种基于日志的测试全面性检测设备的结构示意图。

具体实施方式

请参阅图1，图1是本申请实施例公开的一种基于日志的测试全面性检测方法的流程示意图。如图1所示，该基于日志的测试全面性检测方法包括步骤：

101、从若干个服务器获取若干项目的代码运行产生的系统日志，并将若干项目的代码运行产生的系统日志写入目标数据库中；

102、根据项目配置从目标数据库中匹配目标项目的系统日志；

103、从目标项目的系统日志中获取目标项目的基础数据；

104、根据基础数据计算得到目标项目的测试覆盖率、测试成功率；

105、根据测试覆盖率、测试成功率作为分析结果发送至预设终端，以使得预设终端处的相关人员进行审计。

在本申请实施例中，通过获取目标项目在测试产生的系统日志，可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

在本申请实施例中，作为一种可选的实施方式，项目配置包括目标项目的开始时间、目标项目的结束时间；

相应地，在根据测试覆盖率、测试成功率作为分析结果发送至预设终端之后，本申请实施例方法还包括步骤：

获取当前系统时间；

根据目标项目的开始时间、目标项目的结束时间、当前系统时间计算目标项目的测试进度；

将目标项目的测试进度与预设进度阈值进行比较，若目标项目的进度小于预设进度阈值，则确定目标项目为滞后状态；

通过界面展示目标项目的滞后状态。

在本可选的实施方式中，根据目标项目的开始时间、目标项目的结束时间、当前系统时间能够计算目标项目的测试进度，进而能够将目标项目的测试进度与预设进度阈值进行比较，若目标项目的进度小于预设进度阈值，则可确定目标项目为滞后状态，并通过界面展示目标项目的滞后状态，最终便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请实施例中，作为一种可选的实施方式，在步骤：确定目标项目为滞后状态之后，步骤通过界面展示目标项目的滞后状态之前，本申请实施例的方法还包括：

当目标项目的进度小于预设进度阈值时，根据目标项目的测试进度与预设进度阈值的比值确定目标项目的滞后风险等级。

在本可选的实施方式中，当目标项目的进度小于预设进度阈值时，能够根据目标项目的测试进度与预设进度阈值的比值确定目标项目的滞后风险等级，进而进一步便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请实施例中，作为一种可选的实施方式，基础数据包括交易码、覆盖交易码、交易码的执行总次数、交易码执行成功次数。

相应地，步骤104：根据基础数据计算得到目标项目的测试覆盖率、测试成功率，包括子步骤：

累计得到交易码的总次数和覆盖交易码的总次数；

将覆盖交易码的总次数与交易码的总次数的比值作为目标项目的测试覆盖率；

将交易码执行成功次数与交易码执行总次数的比值作为目标项目的测试成功率。

在本可选的实施方式中，通过累计得到交易码的总次数和覆盖交易码的总次数，进而能够将覆盖交易码的总次数与交易码的总次数的比值作为目标项目的测试覆盖率，与此同时，能够将交易码执行成功次数与交易码执行总次数的比值作为目标项目的测试成功率。

在本申请实施例中，作为一种可选的实施方式，基础数据还包括响应码；

以及，本申请实施例的方法还包括步骤：

累计响应码的每个类型的总数，其中，响应码的类型为表征响应成功的响应码和表征响应失败的响应码中的一种；

根据响应码的每个类型的累计结果判断响应码只为一种类型，若是则生成覆盖不全的警告提示。

在本可选的实施方式中，当响应码只为一种类型，能够生成覆盖不全的警告提示，以便于操作人员及时了解目标项目的测试不全面。

在本申请实施例中，作为一种可选的实施方式，本申请实施例的方法还包括步骤：

当目标项目被划分为若干个排期时，依次计算每个排期的测试覆盖率、测试成功率，并展示每个排期的测试覆盖率、测试成功率。

在本可选的实施方式中，当一个目标项目被划分为若干个排期进行测试时，通过计算每个排期的测试覆盖率、测试成功率，可向操作人员展示每个排期的测试覆盖率、测试成功率，这样一来，操作人员能够逐个了解每个排期的测试覆盖率、测试成功率，进而更加全面地了解目标项目中的测试覆盖率、测试成功率。

请参阅图2，图2是本申请实施例公开的一种基于日志的测试全面性检测装置的结构示意图。如图2所示，该基于日志的测试全面性检测装置包括：

第一获取模块201，用于从若干个服务器获取若干项目的代码运行产生的系统日志，并将若干项目的代码运行产生的系统日志写入目标数据库中；

匹配模块202，用于根据项目配置从目标数据库中匹配目标项目的系统日志；

第二获取模块203，用于从目标项目的系统日志中获取目标项目的基础数据；

第一计算模块204，用于根据基础数据计算得到目标项目的测试覆盖率、测试成功率；

发送模块205，用于根据测试覆盖率、测试成功率作为分析结果发送至预设终端，以使得预设终端处的相关人员进行审计。

本申请实施例的装置通过本申请实施例一的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

在本申请实施例中，作为一种可选的实施方式，项目配置包括目标项目的开始时间、目标项目的结束时间；

相应地，本申请实施例的装置还包括：

第三获取模块，用于获取当前系统时间；

第二计算模块，用于根据目标项目的开始时间、目标项目的结束时间、当前系统时间计算目标项目的测试进度；

比较模块，用于将目标项目的测试进度与预设进度阈值进行比较，若目标项目的进度小于预设进度阈值，则确定目标项目为滞后状态；

第一展示模块，用于通过界面展示目标项目的滞后状态。

在本可选的实施方式中，根据目标项目的开始时间、目标项目的结束时间、当前系统时间能够计算目标项目的测试进度，进而能够将目标项目的测试进度与预设进度阈值进行比较，若目标项目的进度小于预设进度阈值，则可确定目标项目为滞后状态，并通过界面展示目标项目的滞后状态，最终便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请实施例中，本申请实施例的装置还包括：

确定模块，用于当目标项目的进度小于预设进度阈值时，根据目标项目的测试进度与预设进度阈值的比值确定目标项目的滞后风险等级。

在本可选的实施方式中，当目标项目的进度小于预设进度阈值时，能够根据目标项目的测试进度与预设进度阈值的比值确定目标项目的滞后风险等级，进而进一步便于操作人员了解项目整体的测试进度而进一步改善目标项目的测试。

在本申请实施例中，作为一种可选的实施方式，基础数据包括交易码、覆盖交易码、交易码的执行总次数、交易码执行成功次数。

相应地，第一计算模块204执行根据基础数据计算得到目标项目的测试覆盖率、测试成功率的具体方式为：

累计得到交易码的总次数和覆盖交易码的总次数；

将覆盖交易码的总次数与交易码的总次数的比值作为目标项目的测试覆盖率；

将交易码执行成功次数与交易码执行总次数的比值作为目标项目的测试成功率。

在本可选的实施方式中，通过累计得到交易码的总次数和覆盖交易码的总次数，进而能够将覆盖交易码的总次数与交易码的总次数的比值作为目标项目的测试覆盖率，与此同时，能够将交易码执行成功次数与交易码执行总次数的比值作为目标项目的测试成功率。

在本申请实施例中，作为一种可选的实施方式，基础数据还包括响应码；

以及，本申请实施例的装置还包括：

累计模块，用于累计响应码的每个类型的总数，其中，响应码的类型为表征响应成功的响应码和表征响应失败的响应码中的一种；

判断模块，用于根据响应码的每个类型的累计结果判断响应码只为一种类型，若是则生成覆盖不全的警告提示。

在本可选的实施方式中，当响应码只为一种类型，能够生成覆盖不全的警告提示，以便于操作人员及时了解目标项目的测试不全面。

在本申请实施例中，作为一种可选的实施方式，本申请实施例的装置还包括：

第三计算模块，用于当目标项目被划分为若干个排期时，依次计算每个排期的测试覆盖率、测试成功率；

第二展示模块，用于展示每个排期的测试覆盖率、测试成功率。

在本可选的实施方式中，当一个目标项目被划分为若干个排期进行测试时，通过计算每个排期的测试覆盖率、测试成功率，可向操作人员展示每个排期的测试覆盖率、测试成功率，这样一来，操作人员能够逐个了解每个排期的测试覆盖率、测试成功率，进而更加全面地了解目标项目中的测试覆盖率、测试成功率。

请参阅图3，图3是本申请实施例公开的一种基于日志的测试全面性检测设备的结构示意图。如图3所示，该基于日志的测试全面性检测设备包括：

处理器301；以及

存储器302，配置用于存储机器可读指令，指令在由处理器301执行时，使得处理器执行如本申请实施例一公开的基于日志的测试全面性检测方法。

本申请实施例的设备通过本申请实施例的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

本申请实施例公开一种存储介质，该存储介质存储有计算机程序，计算机程序被处理器执行本申请实施例一公开的基于日志的测试全面性检测方法。

本申请实施例的设备通过本申请实施例的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

本申请实施例公开一种计算机产品，计算机产品存储有计算机程序，计算机程序用于执行本申请实施例一的方法。

本申请实施例的计算机产品通过本申请实施例的方法，能够通过获取目标项目在测试产生的系统日志，进而可从系统日志中提取目标项目的基础数据，进而能够根据目标项目的基础数对目标项目的测试情况进行全面性检测，以便于操作人员更加全面的对目标项目的代码进行测试和便于操作人员改善目标项目的代码。

在本申请所公开的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

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