CN114328170A - 一种测试覆盖率确定方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及管理工具技术领域，具体涉及针对软件的故障检测，公开了一种测试覆盖率确定方法、装置、电子设备及存储介质，通过对待测试代码进行打桩处理，可以对测试过程中已执行的代码进行标记，进而确定本次测试对应的测试覆盖率。所述方法包括：首先在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序，然后将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中当桩点对应的代码被执行时表征桩点被触发，最后基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

Description

一种测试覆盖率确定方法、装置、电子设备及存储介质

技术领域

本申请涉及管理工具技术领域，尤其涉及一种测试覆盖率确定方法、装置、电子设备及存储介质。

背景技术

伴随网络技术的不断发展，保障网络设备的稳定运行以及安全运行的问题尤为重要。软件测试技术是软件开发过程中的一个重要组成部分，可以及时发现软件产品中存在的问题，比如测试结果与用户需求不一致，然后及时进行软件产品的改进。

软件测试的流程一般包括：首先确定软件测试中待测试的具体指标；然后根据待测试的具体指标确定测试用例以及测试脚本；再将测试用例输入测试脚本进行测试的执行；最后得到测试结果。

在进行软件测试时，测试用例部分缺失的情况会导致测试覆盖率低，因此需要利用流量回放技术进行软件测试。流量回放技术是指在生产环境下进行业务流量录制后，将录制的业务流量在生产环境或者测试环境中进行回放的一种测试技术。流量回放技术可以有效补充测试用例，还可以降低测试的成本，但是当生产环境下的业务流量很大时，利用流量回放技术难以逐一标记测试过程中已执行的代码，难以度量测试覆盖率。

发明内容

本申请实施例提供一种测试覆盖率确定方法、装置、电子设备及存储介质，通过对待测试代码进行打桩处理，可以对测试过程中已执行的代码进行标记，进而确定本次测试对应的测试覆盖率。

一方面，本申请一实施例提供了一种测试覆盖率确定方法，包括：

在待测试代码中添加桩点，并生成所述待测试代码对应的已添加桩点的可执行程序；

将本次测试的测试数据输入所述可执行程序，并获得所述可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发；

基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

可选地，所述测试数据包括：录制的多组流量数据，或按照预设逻辑编写的测试用例。

一方面，本申请一实施例提供了一种测试覆盖率确定装置，包括：

第一确定模块，用于在待测试代码中添加桩点，并生成所述待测试代码对应的已添加桩点的可执行程序；

测试模块，用于将本次测试的测试数据输入所述可执行程序，并获得所述可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发；

第二确定模块，用于基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

可选地，所述装置还用于：

在待测试代码中添加桩点对应的监测代码，所述监测代码用于当桩点对应的代码被执行时生成用于表征桩点被触发的指示信息。

可选地，所述第一确定模块，具体用于：

在所述待测试代码中指定类型语句对应的位置处添加桩点。

可选地，所述第二确定模块，具体用于：

统计被触发的桩点的数量，以获得第一数量；

基于所述第一数量和第二数量，确定本次测试对应的测试覆盖率，其中所述第二数量为所述待测试代码中包含的桩点的数量。

可选地，当所述指定类型语句被执行时存在至少两个判断结果时，监测代码生成的指示信息还包括：所监测的桩点对应的语句被执行时输出的判断结果；

所述第二确定模块，具体用于：

基于被触发的桩点对应的监测代码返回的指示信息中的判断结果，确定在本次测试中被触发的目标判断结果，其中，目标判断结果为所述待测试代码中的指定类型语句对应的判断结果；

基于所述被触发的目标判断结果的数量、以及所述待测试代码中包含的目标判断结果的总数，确定本次测试对应的测试覆盖率。

可选地，所述第一确定模块，具体用于：

在待测试代码中的各个处理逻辑单元对应的位置处添加桩点；

所述装置还用于：

基于所述待测试代码中各个处理逻辑单元之间的逻辑关系，确定出多个目标桩点序列，每个目标桩点序列包括：按照对应的处理逻辑单元被执行的先后顺序排列的至少一个桩点；

所述第二确定模块，具体用于：

基于所述逻辑关系、所述被触发的桩点、以及所述被触发的桩点的触发顺序，获得至少一个执行桩点序列；

基于获得的执行桩点序列的数量和目标桩点序列的数量，确定本次测试对应的测试覆盖率。

可选地，所述装置还用于：

获得每一测试数据对应的预期结果、以及所述可执行程序输出的所述每一测试数据对应的测试结果；

若所述每一测试数据的测试结果和预期结果不一致，则基于所述每一测试数据生成潜在缺陷清单。

可选地，所述测试数据包括：录制的多组流量数据，或按照预设逻辑编写的测试用例。

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

一方面，本申请一实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一种测试覆盖率确定各种可选实现方式中提供的方法。

本申请实施例提供的一种测试覆盖率确定方法、装置、电子设备及存储介质，首先在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序，然后将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中当桩点对应的代码被执行时表征桩点被触发，最后基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。利用本申请实施例提供的测试覆盖率确定方法，可以对待测试代码进行打桩处理，标记测试过程中已执行的代码，进而确定本次测试对应的测试覆盖率。

附图说明

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

图1为本申请实施例提供的测试覆盖率确定方法的应用场景示意图；

图2为本申请一实施例提供的测试覆盖率确定方法的流程示意图；

图3为本申请一实施例提供的测试覆盖率确定方法的流程示意图；

图4为本申请一实施例提供的测试覆盖率确定方法的流程示意图；

图5为本申请一实施例提供的测试覆盖率确定方法的流程示意图；

图6为本申请一实施例提供的待测试代码中各处理逻辑单元之间的逻辑关系的示意图；

图7为本申请一实施例提供的测试覆盖率确定方法的流程示意图；

图8为本申请一实施例提供的测试覆盖率确定装置的结构示意图；

图9为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分,在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

大数据(Big data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

打桩：是软件测试中单元测试的一种方法，作用是给待测试的代码提供返回值，通过在待测试代码中进行打桩处理，确定打桩后的桩点，将测试数据输入打桩后的待测试代码对应的可执行程序时，可以根据桩点位置的监测代码提供的返回值确定被触发的桩点。

桩点：是根据预设规则确定出的待检测代码中的待检测位置，例如可以根据指定类型语句确定待测试代码对应的桩点，也可以根据待测试代码中的各个处理逻辑单元确定待测试代码对应的桩点。

监测代码：是指用于监测待测试代码中的桩点所在位置处的代码是否被执行的函数，当监测到桩点所在位置处的代码时，监测代码可返回用于表征桩点被触发的指示信息，例如，指示信息可以包括桩点标识，桩点被触发的时间戳等。

测试覆盖率：是指测试过程中，待测试代码中被执行的代码数量与待测试代码中代码总数量的比值，例如测试覆盖率可以包括：函数覆盖率、语句覆盖率、判断覆盖率、条件覆盖率、条件/分支覆盖率、条件组合覆盖率、路径覆盖率等。

函数覆盖率(Function coverage)：是指测试过程中，待测试代码中被执行的函数的数量与待测试代码包含的函数的总数量的比值。

语句覆盖率(Statement coverage)：是指测试过程中，待测试代码中被执行的可执行语句的数量与待测试代码包含的可执行语句的总数量的比值。

判断覆盖(Decision coverage)：也叫分支覆盖(Branch coverage)，是指在测试时运行待测试代码后，待测试代码中所有判断语句的取真分支和取假分支被执行到的比率，其中，取真分支为判断结果为真的分支，取假分支为判断结果为假的分支，即判断覆盖率＝(判断结果被评价的次数)/(判断结果的总数)，判断结果被评价的次数是指测试过程中出现的判断结果的数量，判断结果的总数是指待测试代码中包含的判断结果的总数。

条件覆盖(Condition coverage)的含义是，在测试时运行待测试代码后，所有的判断语句中每个条件的可能取值(真和假)出现过的比率，即条件覆盖率＝(测试过程中出现的条件操作数值的数量)/(待测试代码中包含的条件操作数值的总数)，这里条件操作数值即所有的判断语句中每个条件的可能取值。

条件/分支覆盖率(Condition/Branch coverage)：也叫条件/判断覆盖率(Condition/Decision coverage)，是指设计足够的测试用例，使得判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次，即条件/分支覆盖率＝(测试过程中出现的条件操作数值或判断结果的数量)/(条件操作数值+判断结果总数)，这里条件操作数值即所有的判断语句中每个条件的可能取值。

条件组合覆盖率(Multiple Condition coverage)：是指测试过程中，设计足够的测试用例，使每个判断中条件的各种可能的组合都至少出现一次，即条件组合覆盖率＝(测试过程中出现的条件组合的数量)/(条件组合总数)。

路径覆盖率(Path Coverage)：是指在测试时运行待测试代码后，程序中所有可能的路径被执行过的比率，即路径覆盖率＝(至少被执行到一次的路径数的数量)/(总的路径数)。

流量回放：是指录制线上实际的流量数据，在开发或者测试环境中进行流量数据的回放，以便于确定开发或者测试环境的正常运行。

可执行程序(executable program，EP)：是指对待测试代码进行预处理、编译、汇编、以及链接后的生成的可直接执行的程序。

处理逻辑单元：是指实现某一功能的一段代码，具体根据预设逻辑规则以及功能划分，将待测试代码划分成多个处理逻辑单元。

在具体实践过程中，对软件测试时，易出现测试用例的部分缺失情况，进而导致测试覆盖率低，现有技术中一般采用流量回放技术进行软件测试，以有效补充测试用例，但是当待测试的软件中对应大量的流量时，利用流量回放技术难以逐一标记测试过程中已执行的代码，难以度量测试覆盖率。

为此，本申请提供了一种测试覆盖率确定方法，首先在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序，然后将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中当桩点对应的代码被执行时表征桩点被触发，最后基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。基于上述测试覆盖率确定方法，通过对待测试代码进行打桩处理，可以对测试过程中已执行的代码进行标记，进而确定本次测试对应的测试覆盖率。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

参考图1，其为本申请实施例提供的测试覆盖率确定方法的应用场景示意图。该应用场景包括待测试代码服务器101、自动打桩服务器102、测试数据服务器103、测试环境服务器104、测试结果服务器105和终端设备106。其中，待测试代码服务器101、自动打桩服务器102、测试数据服务器103、测试环境服务器104、测试结果服务器105与终端设备106之间通过无线或有线网络连接，终端设备106包括但不限于桌面计算机、移动电话、移动电脑、平板电脑、媒体播放器、智能可穿戴设备、智能电视等电子设备。待测试代码服务器101、自动打桩服务器102、测试数据服务器103、测试环境服务器104、测试结果服务器105可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

测试人员通过终端设备106分别向待测试代码服务器101以及测试数据服务器103发送测试请求，待测试代码服务器101根据接收到的测试请求，确定测试请求对应的待测试代码，并将测试请求对应的待测试代码发送至自动打桩服务器102，自动打桩服务器102对测试请求对应的待测试代码进行打桩处理，即在待测试代码中添加桩点，然后将经过打桩处理后的待测试代码发送至测试环境服务器104，测试环境服务器104对打桩处理后的待测试代码进行编译后，生成可执行程序，测试数据服务器103根据接收到的测试请求，确定测试请求对应的测试数据，并将测试数据发送至测试环境服务器104，测试环境服务器104接收到测试数据后，将测试数据输入可执行程序中，获得可执行程序运行过程中被触发的桩点，将被触发的桩点发送至测试结果服务器105，并且自动打桩服务器102在对测试请求对应的待测试代码进行打桩处理后，将待测试代码中包含的桩点发送至测试结果服务器105，测试结果服务器105根据被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

这里，终端设备106可以为分布式的测试系统，该测试系统为由多个本地服务器或云服务器基于分布式协议组成的分布式系统。

分布式系统是由一组通过网络进行通信，为了完成共同的任务而协调工作的节点(如计算机或设备)组成的系统。分布式系统可以利用普通的机器完成单个节点无法完成的计算、存储任务，可以利用更多的机器，处理更多的数据。

具体实施时，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，并且及时对单个节点的硬件的提升(加内存、加磁盘、使用更好的CPU)高昂到得不偿失的时候，以及，应用程序也不能进一步优化的时候，通常才需要考虑分布式系统，在此并不限定终端设备106具体的测试系统。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其它可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。

下面结合图1所示的应用场景，对本申请实施例提供的技术方案进行说明。

参考图2，本申请实施例提供一种测试覆盖率确定方法，具体包括以下步骤：

S201，在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序。

其中，待测试代码中的每个桩点具有唯一的桩点标识，以区分各个桩点。基于添加完桩点的待测试代码，生成对应的可执行程序。

具体地，可利用打桩模块扫描待测试代码，找到符合预设策略的代码，并在这些代码对应的位置处添加桩点。例如，可以通过待测试代码中指定类型语句对应的代码确定桩点，也可以通过待测试代码中的各个处理逻辑单元确定桩点，在此仅以这两种方式举例，并不限定确定待测试代码中桩点的具体方法。这里，打桩模块是进行集成测试过程中，从上往下的集成时，为待测试代码编制的模拟其下级代码功能的“替身”模块。

S202，将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发。

具体地，每一次测试包括至少一个测试数据。测试数据可以包括：录制的多组流量数据，或按照预设逻辑编写的测试用例。其中，录制的多组流量数据是指在待测试代码运行过程中采集待测试代码的实际输入数据，测试用例是指由测试人员根据测试目的编写的测试数据。

示例性地，测试数据为录制的多组流量数据时，录制的多组流量数据具体可以是已录制的微信系统中上亿级别数量用户的“转账”操作对应的业务请求对应的测试数据，将已录制的微信系统中上亿级别数量用户的“转账”操作对应的业务请求对应的测试数据输入可执行程序中，获得可执行程序运行过程中被触发的桩点。

示例性地，当录制的多组流量数据为用户通过A应用程序购买电影票的测试数据，但是需要测试用户通过B应用程序购买电影票的测试数据，则利用已录制的用户通过A应用程序购买电影票的测试数据，按照预设逻辑编写用户通过B应用程序购买电影票的测试数据，进而将编写完成的用户通过B应用程序购买电影票的测试数据输入B应用程序对应的可执行程序中，获得可执行程序运行过程中被触发的桩点。

S203，基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

具体地，基于被触发的桩点确定本次测试中已执行的代码的数量，基于待测试代码中设置的桩点确定需要执行的代码的数量，基于已执行的代码的数量和需要执行的代码的数量之间的比值，确定本次测试对应的测试覆盖率。

可选地，还可以在待测试代码中添加桩点对应的监测代码，以便于更准确的确定被触发的桩点的数量，具体包括以下步骤：

S2011，在待测试代码中添加桩点对应的监测代码，获得添加监测代码后的待测试代码对应的可执行程序。

其中，在待测试代码中添加桩点对应的监测代码之后，对添加监测代码后的待测试代码进行编译，以获得可执行程序。

这里，监测代码用于当桩点对应的代码被执行时生成用于表征桩点被触发的指示信息。

可选地，监测代码可以是预设函数形式，例如RecordStub(x)(记录桩点(x))，也可以根据预设规则确定监测代码，并且对于确定待测试代码在本次测试中对应的不同的测试覆盖率时，例如函数覆盖率、语句覆盖率、判断覆盖率、条件覆盖率、条件/判断覆盖率、条件组合覆盖率、路径覆盖率，监测代码既可以相同，也可以不相同，在此并不限定具体的监测代码，可根据实际的应用场景进行调整。

示例性地，在待测试代码中添加桩点1、桩点2、桩点3后，若监测代码为RecordStub(x)，则x为桩点对应的桩点标识1、2、3，也即分别对应的监测代码为RecordStub(1)、RecordStub(2)、RecordStub(3)。当在测试过程中测试到桩点1时，监测代码RecordStub(1)可以记录执行桩点1的时间、桩点1对应的测试数据、以及桩点1的桩点标识1，因此监测代码生成用于表征桩点被触发的指示信息可以是执行桩点1的时间、桩点1对应的测试数据、以及桩点1的桩点标识1。

S2012，将本次测试的测试数据输入可执行程序，基于可执行程序运行过程中各桩点的监测代码生成的指示信息，获得被触发的桩点。

S2013，基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

这里，步骤S2012、步骤S2013的具体实施方式可以分别与步骤S202、步骤S203相同，在此不再赘述。

本实施例提供的一种测试覆盖率确定方法，首先在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序，然后将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中当桩点对应的代码被执行时表征桩点被触发，最后基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。利用本实施例提供的测试覆盖率确定方法，可以对待测试代码进行打桩处理，标记测试过程中已执行的代码，进而确定本次测试对应的测试覆盖率，解决了现有技术中当生产环境下的业务流量很大时，利用流量回放技术难以逐一标记测试过程中已执行的代码，难以度量测试覆盖率的问题。

可选地，本申请一实施例中，还可以统计每个桩点被触发的次数，计算该桩点被触发的次数与本次测试中测试数据的总数的比值，以获得该桩点在本次测试中的被测试比例，以提供更多维度的测试评价数据。

示例性地，将所有测试数据输入可执行程序后，统计到本次测试中测试数据共测试了10次，若桩点1被触发2次，那么在本次测试中桩点1被触发的次数与本次测试中测试数据的总数的比值为20％；若桩点2被触发4次，那么在本次测试中桩点2被触发的次数与本次测试中测试数据的总数的比值为40％，根据获得的该桩点在本次测试中的被测试比例，以提供更多维度的测试评价数据。

当需要获得某种指定类型语句的测试覆盖率时，如函数覆盖率、语句覆盖率、判断覆盖率、条件覆盖率等，可在待测试代码中指定类型语句对应的位置处添加桩点，并在每个桩点附近设置对应的监测代码。当桩点被触发时，监测代码返回表示该桩点被触发的指示信息，该指示信息可包括被触发的桩点的桩点标识，还可以包括桩点被触发的时间戳。

基于此，参考图3，本申请实施例提供一种测试覆盖率确定方法，具体包括以下步骤：

S301，在待测试代码中指定类型语句对应的位置处添加桩点，并生成待测试代码对应的已添加桩点的可执行程序。

其中，指定类型语句可以是以下任意一种：函数语句(Function)、判断语句(Decision)、条件语句(Condition)等。

例如，以下代码就是一个函数：

int main()

{

count<<”hello world\n”；

return 0；

}

例如，“if a>1and b＝＝0”就是一个判断语句；条件语句就是判断语句中的条件，如上述判断语句“if a>1and b＝＝0”中的“a>1”和“b＝＝0”均可以是条件语句。

这里，上述仅是对待测试代码中指定类型语句对应的代码确定为桩点的举例，在此并不限定具体的指定类型语句，可根据实际应用场景进行调整。

S302，将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发。

这里，步骤S302的具体实施方式可以与步骤S202相同，在此不再赘述。

S303，统计被触发的桩点的数量，以获得第一数量。

其中，第一数量即为本次测试过程中被触发的桩点的数量。例如，本次测试的测试数据包括两个测试数据，第一个测试数据输入后，检测到被触发的桩点为桩点1、桩点2，第二个测试数据输入后检测到被触发的桩点为桩点2、桩点4，则本次测试中被触触发的桩点为桩点1、桩点2、桩点4，数量为3个。

S304，基于第一数量和第二数量，确定本次测试对应的测试覆盖率，其中第二数量为待测试代码中包含的桩点的数量。

具体地，将第一数量除以第二数量的结果确定为本次测试对应的测试覆盖率。

当需要获得的测试覆盖率为函数覆盖率时，指定类型语句为函数语句，若检测到待测试代码中存在10个函数，则在这10个函数所在的位置添加桩点，并在每个桩点位置附近添加对应的监测代码，一个桩点对应一个监测代码。当监测代码监测到对应桩点所在位置处的函数语句被执行时，可以返回用于表征该桩点被触发的指示信息。例如，当函数对应的监测代码获取到函数的计算结果后，该监测代码返回的指示信息可以包括该函数对应的桩点的桩点标识、该桩点被触发的时间戳；或者可在函数之后添加桩点对应的监测代码，当函数执行完之后，直接执行监测代码，即监测代码返回用于表征该桩点被触发的指示信息，同样，该指示信息可以包括该函数对应的桩点的桩点标识、该桩点被触发的时间戳。若在可执行程序运行过程中被触发的桩点为9个，则第一数量为9个，待测试代码中包含的桩点数量为10个，即第二数量为10个，此时本次测试对应的测试覆盖率为90％。

当需要获得的测试覆盖率为语句覆盖率时，指定类型语句为待测试代码中的可执行语句，如条件语句、判断语句等，可在待测试代码中每个可执行语句所在的位置处添加桩点，并在每个桩点位置附近添加对应的监测代码，一个桩点对应一个监测代码。当监测代码监测到对应桩点所在位置处的可执行语句代码被执行时，可以返回用于表征该桩点被触发的指示信息。例如，可在可执行语句之后添加桩点对应的监测代码，当可执行语句执行完之后，直接执行监测代码，即监测代码返回用于表征该桩点被触发的指示信息，同样，该指示信息可以包括该可执行语句对应的桩点的桩点标识、该桩点被触发的时间戳。若在可执行程序运行过程中被触发的桩点为9个，则第一数量为9个，待测试代码中包含的桩点数量为10个，即第二数量为10个，此时本次测试对应的测试覆盖率为90％。

本实施例提供的一种测试覆盖率确定方法，首先在待测试代码中指定类型语句对应的位置处添加桩点，并生成待测试代码对应的已添加桩点的可执行程序，然后将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发，最后统计被触发的桩点的数量，以获得第一数量，基于第一数量和第二数量，确定本次测试对应的测试覆盖率，其中第二数量为待测试代码中包含的桩点的数量。利用本实施例提供的测试覆盖率确定方法，可以准确具体地对测试过程中已执行的代码进行标记，进而确定本次测试对应的测试覆盖率。

当指定类型语句被执行时存在至少两个判断结果，且需要获得的是针对判断结果或判断结果的组合所对应的测试覆盖率时，如判断覆盖率、条件覆盖率、条件/分支覆盖率、条件组合覆盖率等，可在待测试代码中指定类型语句对应的位置处添加桩点，并在每个桩点附近设置对应的监测代码。此时，当桩点被触发时，对应的监测代码返回表示该桩点被触发的指示信息，该指示信息可包括被触发的桩点的桩点标识、桩点被触发的时间戳以及桩点对应的语句被执行时输出的判断结果。

基于此，参考图4，本申请实施例提供一种测试覆盖率确定方法，具体包括以下步骤：

S401，在待测试代码中指定类型语句对应的位置处添加桩点。

其中，指定类型语句可以是存在多个判断结果的语句，例如判断语句、条件语句等。

S402，在待测试代码中添加桩点对应的监测代码，并生成待测试代码对应的已添加桩点的可执行程序。

其中，每个桩点对应一个监测代码。

具体地，根据添加桩点对应的监测代码后的待测试代码，生成待测试代码对应的已添加桩点的可执行程序。

S403，将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点对应的监测代码返回的指示信息。

其中，监测代码返回的指示信息可包括被触发的桩点的桩点标识、桩点被触发的时间戳以及桩点对应的语句被执行时输出的判断结果。

S404，基于被触发的桩点对应的监测代码返回的指示信息中的判断结果，确定在本次测试中被触发的目标判断结果。

S405，基于被触发的目标判断结果的数量、以及待测试代码中包含的目标判断结果的总数，确定本次测试对应的测试覆盖率。

其中，目标判断结果为待测试代码中的指定类型语句对应的判断结果，即目标判断结果是指待测试代码中桩点对应的语句存在的所有可能的判断结果。

具体地，当本次测试结束后，基于通过步骤S403中获得的多个指示信息，确定在上述多个指示信息中出现的目标判断结果，以获得在本次测试中被触发的目标判断结果的数量，记为第三数量，即在本次测试过程中被测试到的目标判断结果的数量；然后，将第三数量除以待测试代码中包含的目标判断结果的总数，获得本次测试对应的测试覆盖率。

下面以以下待测试代码为例，对各个实施方式中的测试覆盖率确定方法进行举例说明：

下面分别以判断语句和条件语句为例，对在待测试代码中添加桩点和监测代码的过程进行说明。

当指定类型语句为判断语句时，可以在判断语句if a>1and b＝＝0对应的位置处添加桩点Z1，在判断语句if a＝＝2or x>1对应的位置处添加桩点Z2，并在桩点Z1位置附近添加对应的监测代码D1，在桩点Z2位置附近添加对应的监测代码D2。桩点Z1对应的语句被执行时输出的判断结果可以包括两种情况，即判断结果为真和判断结果为假，因此，监测代码D1用于监测桩点Z1对应的判断语句的判断结果，监测代码D2用于监测桩点Z2对应的判断语句的判断结果，待测试代码中包含的目标判断结果包括：桩点Z1对应的真、假两个判断结果，桩点Z2对应的真、假两个判断结果，即待测试代码中包含的目标判断结果的总数为4。

若监测代码D1获取到判断语句if a>1and b＝＝0的判断结果为真，则表示测试了判断语句if a>1and b＝＝0的取真分支，此时监测代码D1返回的指示信息可包括：桩点Z1的标识、桩点Z1被触发的时间戳以及判断结果为取真，基于该指示信息可确定桩点Z1的取真分支被测试了；若监测代码D1获取到判断语句if a>1and b＝＝0的判断结果为假，则表示测试了判断语句if a>1and b＝＝0的取假分支，此时监测代码D1返回的指示信息可包括：桩点Z1的标识、桩点Z1被触发的时间戳以及判断结果为取假，基于该指示信息可确定桩点Z1的取假分支被测试了。

当指定类型语句为条件语句时，可以在条件语句a>1对应的位置处添加桩点Z3，在条件语句b＝＝0对应的位置处添加桩点Z4，在条件语句a＝＝2对应的位置处添加桩点Z5，在条件语句x>1对应的位置处添加桩点Z6，并在桩点Z3、桩点Z4、桩点Z5和桩点Z6附近分别添加对应的监测代码D3、监测代码D4、监测代码D5、监测代码D6，其中监测代码D3用于监测桩点Z3对应的条件语句的判断结果，监测代码D4～D6的功能可参考监测代码D3，不再赘述。此时，待测试代码中包含的目标判断结果包括：桩点Z3对应的真、假两个判断结果，桩点Z4对应的真、假两个判断结果，桩点Z5对应的真、假两个判断结果，桩点Z6对应的真、假两个判断结果，即待测试代码中包含的目标判断结果的总数为8。

以监测代码D3为例，若监测代码D3获取条件语句a>1的判断结果为真，则表示测试了条件语句a>1的取真分支，此时监测代码D3返回的指示信息可包括：桩点Z3的标识、桩点Z3被触发的时间戳以及判断结果为取真，基于该指示信息可确定桩点Z3的取真分支被测试了；同样地，若监测代码D3获取到条件语句a>1的判断结果为假，则表示测试了条件语句a>1的取假分支，此时监测代码D3返回的指示信息可包括：桩点Z3的标识、桩点Z3被触发的时间戳以及判断结果为取假，基于该指示信息可确定桩点Z3的取假分支被测试了。

下面以上述待测试代码为例，对各种测试覆盖率的确定方法进行举例说明。

当测试覆盖率是判断覆盖率时，每个判断语句有两个判断结果：一个取真分支和一个取假分支。此时，目标判断结果的总数为待测试代码包含的判断语句的判断结果的数量，例如一共有2个判断语句，则目标判断结果的总数为4。

以上述待测试代码为例，已在待测试代码中判断语句对应的位置添加了桩点Z1和桩点Z2，以及监测代码D1和监测代码D2。将本次测试的测试数据输入可执行程序后，获取监测代码D1和监测代码D2返回的指示信息，若根据获取的指示信息确定桩点Z1的取真分支和桩点Z2的取真分支被测试了，而桩点Z1的取假分支和桩点Z2的取假分支未被测试，则可以确定第三数量为2，由于待测试代码中包含的目标判断结果的总数为4，那么本次测试对应的判断覆盖率为50％。

当测试覆盖率是条件覆盖率时，每个判断语句有两个判断结果：一个取真分支和一个取假分支，每个判断语句中每个条件语句也有两个判断结果：一个取真分支和一个取假分支，此时，目标判断结果的总数为待测试代码包含的条件语句的判断结果的数量，例如一共有4个条件语句，则目标判断结果的总数为8。

以上述待测试代码为例，已在待测试代码中条件语句对应的位置添加了桩点Z3、桩点Z4、桩点Z5和桩点Z6，以及对应的监测代码D3、监测代码D4、监测代码D5、监测代码D6。将本次测试的测试数据输入可执行程序后，获取监测代码D3～D6返回的指示信息，若根据获取的指示信息确定仅有桩点Z3的取真分支、桩点Z4的取真分支、桩点Z6的取假分支被测试了，而Z3的取假分支、桩点Z4的取假分支、桩点Z5的取真分支、桩点Z5的取假分支、桩点Z6的取真分支未被测试，则可以确定第三数量为3，由于待测试代码中包含的目标判断结果的总数为8，那么本次测试对应的条件覆盖率为37.5％。

当测试覆盖率是条件/分支覆盖率时，每个判断语句有两个判断结果：一个取真分支和一个取假分支，每个判断语句中每个条件语句也有两个判断结果：一个取真分支和一个取假分支，此时，目标判断结果的总数为待测试代码中包含的判断语句的判断结果和条件语句的判断结果的总数，例如一共有6个判断语句和条件语句，则目标判断结果的总数为12。

以上述待测试代码为例，已在待测试代码中添加了桩点Z1～Z6，以及对应的监测代码D1～D6。将本次测试的测试数据输入可执行程序后，获取执行过程中监测代码D1～D6返回的指示信息，若根据获取的指示信息确定桩点Z1～Z6的取真分支被测试了，但是桩点Z1～Z6的取假分支未被测试，则可以确定第三数量为6，由于待测试代码中包含的目标判断结果的总数为12，那么本次测试对应的条件/分支覆盖率为50％。

当测试覆盖率是条件组合覆盖率时，由于每个判断语句有两个判断结果：一个取真分支和一个取假分支，每个判断语句中每个条件语句也有两个判断结果：一个取真分支和一个取假分支，条件组合规则可以是将每个判断语句中的各个条件语句的判断结果进行组合，一个包含N个条件语句的判断语句可确定出的条件组合的数量为2ⁿ。例如，待测试代码中有两个判断语句，即判断语句1和判断语句2，且判断语句1中有两个条件语句即条件语句1和条件语句2，判断语句2中有两个条件语句即条件语句3和条件语句4，则根据条件组合规则，可得到8个条件组合：条件语句1的取真分支与条件语句2的取真分支、条件语句1的取真分支与条件语句2的取假分支、条件语句1的取假分支与条件语句2的取真分支、条件语句1的取假分支与条件语句2的取假分支、条件语句3的取真分支与条件语句4的取真分支、条件语句3的取真分支与条件语句4的取假分支、条件语句3的取假分支与条件语句4的取真分支、条件语句3的取假分支与条件语句4的取假分支，因此，目标判断结果的总数为8。

以上述待测试代码为例，即待测试代码中有两个判断语句，且每个判断语句中有两个条件语句，则由于已在待测试代码中条件语句对应的位置添加了桩点Z3、桩点Z4、桩点Z5和桩点Z6，以及对应的监测代码D3、监测代码D4、监测代码D5、监测代码D6。

假设本次测试包含两个测试数据，将第一个测试数据输入可执行程序，根据监测代码D3～D6返回的指示信息，确定测试到的条件组合，例如，根据获取的指示信息确定仅有桩点Z3的取真分支、桩点Z4的取真分支、桩点Z5的取假分支、桩点Z6的取假分支被测试了，可确定以下条件组合被测试到：桩点Z3的取真分支和桩点Z4的取真分支、以及桩点Z5的取假分支和桩点Z6的取假分支；再将第二个测试数据输入可执行程序，基于同样的方式确定以下条件组合被测试到：桩点Z3的取真分支和桩点Z4的取真分支、以及桩点Z5的取真分支和桩点Z6的取假分支；完成本次测试后，统计每个测试数据测试到的条件组合，得到本次测试测试到的组合条件为：桩点Z3的取真分支和桩点Z4的取真分支、以及桩点Z5的取假分支和桩点Z6的取假分支、以及桩点Z5的取真分支和桩点Z6的取假分支，因此本次测试中的第三数量为3，由于待测试代码中包含的目标判断结果的总数为8，那么本次测试对应的条件覆盖率为37.5％。

当需要获取的是路径覆盖率时，可在待测试代码中的各个处理逻辑单元对应的位置处添加桩点。参考图5，本申请实施例提供一种测试覆盖率确定方法，具体包括以下步骤：

S501，在待测试代码中的各个处理逻辑单元对应的位置处添加桩点，并生成待测试代码对应的已添加桩点的可执行程序。

具体地，路径覆盖率是指测试过程中，待测试代码中各处理逻辑单元之间逻辑关系组成的所有路径中被执行的路径数量占所有路径总数量的比值。如图6所示，提供了待测试代码中各处理逻辑单元之间的逻辑关系的示意图，将待测试代码中的各个处理逻辑单元确定为桩点，即处理逻辑单元1为桩点1，处理逻辑单元2-1为桩点2-1，处理逻辑单元2-2为桩点2-2，处理逻辑单元2-3为桩点2-3，处理逻辑单元2-4为桩点2-4，处理逻辑单元3-1为桩点3-1，处理逻辑单元3-2为桩点3-2，处理逻辑单元3-3为桩点3-3。

S502，基于待测试代码中各个处理逻辑单元之间的逻辑关系，确定出多个目标桩点序列，每个目标桩点序列包括：按照对应的处理逻辑单元被执行的先后顺序排列的至少一个桩点。

具体地，目标桩点序列(Stubs Data,SD)为遍历待测试代码中各个处理逻辑单元之间的逻辑关系后，确定所有的目标桩点序列。

示例性地，以图6为例，其中一条路径为：执行完处理逻辑单元1后，基于判断逻辑A的判断执行处理逻辑单元2-1，且执行完处理逻辑单元2-1后整个可执行程序结束，则基于上述逻辑关系可得到一个目标桩点序列，具体为：处理逻辑1，处理逻辑2-1，end；同样的，可基于待测试代码中各处理逻辑单元之间的逻辑关系，获得其它路径对应的目标桩点序列，具体包括：

处理逻辑1，处理逻辑2-2，end；

处理逻辑1，处理逻辑2-3，处理逻辑3-1，end；

处理逻辑1，处理逻辑2-3，处理逻辑3-2，end；

处理逻辑1，处理逻辑2-3，处理逻辑3-3，end；

处理逻辑1，处理逻辑2-4，处理逻辑3-3，end。

S503，将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发。

S504，基于逻辑关系、被触发的桩点、以及被触发的桩点的触发顺序，获得至少一个执行桩点序列。

具体地，将一个测试数据输入待测试代码对应的可执行程序后，根据被触发的桩点按照逻辑关系、以及被触发的桩点对应的时间戳，确定执行桩点序列。其中，针对每一个测试数据，可确定出至少一个执行桩点序列(Executed Stubs Sequence，ESS)。

示例性地，将一个测试数据输入可执行程序后，先触发了处理逻辑单元1对应的桩点，再触发了处理逻辑单元2-2对应的桩点之后，可执行程序结束，则该测试数据对应的执行桩点序列为：处理逻辑1，处理逻辑2-2，end；将另一个测试数据输入可执行程序后，先触发了处理逻辑单元1对应的桩点，然后触发了处理逻辑单元2-3对应的桩点，再触发了处理逻辑3-1对应的桩点之后可执行程序结束，则该测试数据对应的执行桩点序列为：处理逻辑1，处理逻辑2-3，处理逻辑3-1，end。

示例性地，将一个测试数据输入可执行程序后，可能同时触发了处理逻辑单元1和处理逻辑单元2；对于触发处理逻辑单元1的情况，然后又触发了处理逻辑单元3-1之后可执行程序结束，则可得到一个执行桩点序列1：处理逻辑1，处理逻辑3-1，end；对于触发处理逻辑单元2的情况，然后又触发了处理逻辑单元3-2之后可执行程序结束，则可得到一个执行桩点序列2：处理逻辑2，处理逻辑3-2，end；因此，该测试数据对应的执行桩点序列包括执行桩点序列1和执行桩点序列2。

基于上述方式获得每个测试数据对应的执行桩点序列。

S505，基于获得的执行桩点序列的数量和目标桩点序列的数量，确定本次测试对应的测试覆盖率。

具体地，当本次测试结束后，统计执行桩点序列的数量，并对获得的执行桩点序列进行去重操作，统计经去重操作后获得的执行桩点序列的数量，将该获得的执行桩点序列的数量除以目标桩点序列的数量，获得本次测试对应的测试覆盖率。

示例性地，假设目标桩点序列的数量为6，当本次测试结束后，统计到执行桩点序列1对应的数量为2，执行桩点序列2对应的数量为3，执行桩点序列3对应的数量为2，则去重后获得的执行桩点序列的数量为3，本次测试对应的测试覆盖率为50％。

另外，还可以统计去重操作过程中执行桩点序列分别对应的测试数据，存储该测试数据以及对应的执行桩点序列，并基于测试结果和预期结果的比对结果，生成潜在缺陷清单，后续将详细介绍生成潜在缺陷清单的方法。

可选地，还可以针对每一目标桩点序列，统计与该目标桩点序列相同的执行桩点序列在本次测试中的出现次数，计算该出现次数与本次测试中测试数据的总数的比值，以获得该目标桩点序列在本次测试中的被测试比例，以提供更多维度的测试评价数据。

示例性地，将本次测试中所有测试数据输入可执行程序后，统计到本次测试中测试数据共测试了10次，假设目标桩点序列对应的数量为4，其中分别为目标桩点序列1、目标桩点序列2、目标桩点序列3、目标桩点序列4，执行桩点序列对应的数量为3，其中分别为执行桩点序列1、执行桩点序列2、执行桩点序列3，并且目标桩点序列1与执行桩点序列1相同，目标桩点序列2与执行桩点序列2相同，目标桩点序列3与执行桩点序列3相同，执行桩点序列1在本次测试中出现的数量为5次，执行桩点序列2在本次测试中出现的数量为4次，执行桩点序列3在本次测试中出现的数量为1次，那么本次测试中目标桩点序列1在本次测试中被测试比例为50％，目标桩点序列2在本次测试中被测试比例为40％，目标桩点序列3在本次测试中被测试比例为10％。基于上述数据可知，针对目标桩点序列3进行测试的测试数据的比例较少，可适当增加针对目标桩点序列3的测试数据。

可选地，本申请的一实施例中，在确定本次测试对应的测试覆盖率之后，还可以获得每一测试数据对应的预期结果、以及可执行程序输出的每一测试数据对应的测试结果；若每一测试数据的测试结果和预期结果不一致，则基于每一测试数据生成潜在缺陷清单(Potential Bug List，PBL)。

具体实施时，潜在缺陷清单可包括：测试结果和预期结果不一致的测试数据，这些测试数据对应的测试结果、预期结果以及被触发桩点、测试覆盖率等相关数据。

示例性地，若测试数据输入待测试代码对应的可执行程序后，对应的预期结果为实现微信拍一拍功能中的拍一拍自己，但是可执行程序输出的测试数据对应的测试结果为拍一拍其他人，则测试结果和预期结果不一致，基于该测试数据生成潜在缺陷清单，其中，潜在缺陷清单包括本次的测试结果和预期结果，另外当计算路径测试覆盖率时，潜在缺陷清单中还可以包括执行桩点序列和目标桩点序列。

示例性地，如图7所示，示出了本申请一实施例提供的测试覆盖率确定方法的流程示意图，具体包括如下步骤：

S701，修改代码：根据需求或者上次测试过程生成的潜在缺陷清单对待测试代码V1进行修改，获得待测试代码V2。

S702，自动打桩：对待测试代码V2进行自动打桩处理，即在待测试代码V2中确定桩点位置，并在每个桩点处添加对应的监测代码，对添加完监测代码后的待测试代码V2进行编译，生成待测试代码V2对应的可执行程序。

其中，监测代码用于当桩点的代码被执行时生成用于表征桩点被触发的指示信息。

S703，测试环境部署：将待测试代码V2对应的可执行程序部署到测试环境集群中。

S704，执行测试：将测试数据输入可执行程序中，基于可执行程序中的监测代码返回的指示信息，获得可执行程序运行过程中被触发的桩点。

S705，统计结果：根据步骤S702自动打桩过程中生成的待测试代码V2中包含的桩点，以及步骤S704执行测试过程中生成的被触发的桩点，确定本次测试对应的测试覆盖率。

此外，步骤S705还可以包括：基于测试结果和预期结果不一致的测试数据、这些测试数据对应的测试结果、这些测试数据对应的预期结果以及被触发桩点、测试覆盖率等相关数据，生成潜在缺陷清单，以便于测试人员根据潜在缺陷清单对待测试代码V2进行修改，获得待测试代码V3，然后参考步骤S701～S705继续对待测试代码V3进行测试，如此循环，直至待测试代码不存在缺陷。其中，每一次循环中使用的测试数据可以相同，也可以不同。

实际应用中，同一待测试代码可能需要在不同的环境中运行，为此，在待测试代码中添加完桩点后，可根据不同的测试环境或生产环境，对添加了桩点的待测试代码进行编译，以获得不同测试环境或生产环境下的可执行程序，进而获得不同测试环境或生产环境下待测试代码的测试覆盖率。

如图8所示，基于与上述测试覆盖率确定方法相同的发明构思，本申请实施例还提供了一种测试覆盖率确定装置80，具体包括第一确定模块801、测试模块802和第二确定模块803。

第一确定模块801，用于在待测试代码中添加桩点，并生成待测试代码对应的已添加桩点的可执行程序；

测试模块802，用于将本次测试的测试数据输入可执行程序，并获得可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发；

第二确定模块803，用于基于被触发的桩点和待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

可选地，装置80还用于：

在待测试代码中添加桩点对应的监测代码，监测代码用于当桩点对应的代码被执行时生成用于表征桩点被触发的指示信息。

可选地，第一确定模块801，具体用于：

在待测试代码中指定类型语句对应的位置处添加桩点。

可选地，第二确定模块803，具体用于：

统计被触发的桩点的数量，以获得第一数量；

基于第一数量和第二数量，确定本次测试对应的测试覆盖率，其中第二数量为待测试代码中包含的桩点的数量。

可选地，当指定类型语句被执行时存在至少两个判断结果时，监测代码生成的指示信息还包括：所监测的桩点对应的语句被执行时输出的判断结果；

第二确定模块803，具体用于：

基于被触发的桩点对应的监测代码返回的指示信息中的判断结果，确定在本次测试中被触发的目标判断结果，其中，目标判断结果为待测试代码中的指定类型语句对应的判断结果；

基于被触发的目标判断结果的数量、以及待测试代码中包含的目标判断结果的总数，确定本次测试对应的测试覆盖率。

可选地，第一确定模块801，具体用于：

在待测试代码中的各个处理逻辑单元对应的位置处添加桩点；

装置80还用于：

基于待测试代码中各个处理逻辑单元之间的逻辑关系，确定出多个目标桩点序列，每个目标桩点序列包括：按照对应的处理逻辑单元被执行的先后顺序排列的至少一个桩点；

第二确定模块803，具体用于：

基于逻辑关系、被触发的桩点、以及被触发的桩点的触发顺序，获得至少一个执行桩点序列；

基于获得的执行桩点序列的数量和目标桩点序列的数量，确定本次测试对应的测试覆盖率。

可选地，装置80还用于：

获得每一测试数据对应的预期结果、以及可执行程序输出的每一测试数据对应的测试结果；

若每一测试数据的测试结果和预期结果不一致，则基于每一测试数据生成潜在缺陷清单。

可选地，测试数据包括：录制的多组流量数据，或按照预设逻辑编写的测试用例。

本申请实施例提供的测试覆盖率确定装置与上述测试覆盖率确定方法采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

基于与上述测试覆盖率确定方法相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)、服务器等。如图9所示，该电子设备90可以包括处理器901和存储器902。

处理器901可以是通用处理器，例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器902作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器902还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于：移动存储设备、随机存取存储器(RAM，Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、随机存取存储器(RAM，Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的测试覆盖率确定方法。

以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本申请实施例的方法，不应理解为对本申请实施例的限制。本技术领域的技术人员可轻易想到的变化或替换，都应涵盖在本申请实施例的保护范围之内。

Claims (10)

1.一种测试覆盖率确定方法，其特征在于，所述方法包括：

在待测试代码中添加桩点，并生成所述待测试代码对应的已添加桩点的可执行程序；

将本次测试的测试数据输入所述可执行程序，并获得所述可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发；

基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

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

在待测试代码中添加桩点对应的监测代码，所述监测代码用于当桩点对应的代码被执行时生成用于表征桩点被触发的指示信息。

3.根据权利要求2所述的方法，其特征在于，所述在待测试代码中添加桩点，具体包括：

在所述待测试代码中指定类型语句对应的位置处添加桩点。

4.根据权利要求3所述的方法，其特征在于，所述基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率，具体包括：

统计被触发的桩点的数量，以获得第一数量；

基于所述第一数量和第二数量，确定本次测试对应的测试覆盖率，其中所述第二数量为所述待测试代码中包含的桩点的数量。

5.根据权利要求3所述的方法，其特征在于，当所述指定类型语句被执行时存在至少两个判断结果时，监测代码生成的指示信息还包括：所监测的桩点对应的语句被执行时输出的判断结果；

所述基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率，具体包括：

基于被触发的桩点对应的监测代码返回的指示信息中的判断结果，确定在本次测试中被触发的目标判断结果，其中，目标判断结果为所述待测试代码中的指定类型语句对应的判断结果；

基于所述被触发的目标判断结果的数量、以及所述待测试代码中包含的目标判断结果的总数，确定本次测试对应的测试覆盖率。

6.根据权利要求2所述的方法，其特征在于，所述在待测试代码中添加桩点，具体包括：

在待测试代码中的各个处理逻辑单元对应的位置处添加桩点；

所述方法还包括：

基于所述待测试代码中各个处理逻辑单元之间的逻辑关系，确定出多个目标桩点序列，每个目标桩点序列包括：按照对应的处理逻辑单元被执行的先后顺序排列的至少一个桩点；

所述基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率，具体包括：

基于所述逻辑关系、所述被触发的桩点、以及所述被触发的桩点的触发顺序，获得至少一个执行桩点序列；

基于获得的执行桩点序列的数量和目标桩点序列的数量，确定本次测试对应的测试覆盖率。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

获得每一测试数据对应的预期结果、以及所述可执行程序输出的所述每一测试数据对应的测试结果；

若所述每一测试数据的测试结果和预期结果不一致，则基于所述每一测试数据生成潜在缺陷清单。

8.一种测试覆盖率确定装置，其特征在于，包括：

第一确定模块，用于在待测试代码中添加桩点，并生成所述待测试代码对应的已添加桩点的可执行程序；

测试模块，用于将本次测试的测试数据输入所述可执行程序，并获得所述可执行程序运行过程中被触发的桩点，其中，当桩点对应的代码被执行时表征桩点被触发；

第二确定模块，用于基于被触发的桩点和所述待测试代码中包含的桩点，确定本次测试对应的测试覆盖率。

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

10.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该计算机程序指令被处理器执行时实现权利要求1至7任一项所述方法的步骤。

Images