覆盖率测试方法及系统、处理器、存储介质与流程

本申请涉及软件测试领域，具体而言，涉及一种覆盖率测试方法及系统、处理器、存储介质。

背景技术：

为保证软件产品能够稳定运行，在开发软件的过程中以及软件产品发布之后，软件测试人员需要对软件进行测试。其中，代码覆盖率可以作为衡量测试覆盖程度的指标，此外，代码覆盖率还可用来评估测试用例执行的实际完成情况。

目前，主要采用黑盒测试方式对软件功能进行测试，通常通过用例评审的方式来保证功能用例对被测应用的覆盖率力度。而功能用例的覆盖率与软件测试人员的经验以及开发人员的参与度有关，无法做到对测试覆盖的量化评估。

对于一些测试场景比较复杂的客户端工具，例如，手机、车机(即安装在车辆内部中的车载信息娱乐产品，例如，收音机)，传统的测试方法无法评估实际场景的测试覆盖力度，极易出现覆盖不到的漏测情况，例如，客户端工具的部分代码或逻辑未执行。对于测试覆盖不到的情况无法进行风险评估，从而无法对风险进行有效预防。

另外，在大规模的测试中，客户端工具各模块的测试用例较多，软件测试人员只能根据实际经验对测试用例的执行时间进行估计，无法对其进行精确评估。

现有技术中的上述缺陷均降低了软件产品的代码覆盖率测试的准确度。

针对上述相关技术中代码覆盖率的测试准确度较低的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种覆盖率测试方法及系统、处理器、存储介质，以至少解决相关技术中代码覆盖率的测试准确度较低的技术问题。

根据本发明实施例的一个方面，提供了一种覆盖率测试方法，包括：获取待测应用的测试数据；根据测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

根据本发明实施例的另一方面，还提供了一种覆盖率测试方法，包括：接收客户端工具发送的插桩处理消息，插桩处理消息指示需插桩的待测应用；根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用通过客户端工具更新至待测设备后，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

根据本发明实施例的另一方面，还提供了一种覆盖率测试方法，包括：接收客户端工具发送的插桩后的待测应用，其中，由客户端工具根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用；对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

根据本发明实施例的另一方面，还提供了一种覆盖率测试系统，包括：至少一个客户端工具，用于执行客户端工具的覆盖率测试方法；至少一个测试设备，与至少一个客户端工具对应，用于执行测试设备端的覆盖率测试方法。

根据本发明实施例的另一方面，还提供了一种覆盖率测试系统，包括：客户端工具，用于从服务器获取待测应用的测试数据；将插桩处理消息发送至服务器，插桩处理消息指示需插桩的待测应用；服务器，用于根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用通过客户端工具更新至待测设备；客户端工具，还用于将插桩后的待测应用发送至测试设备；测试设备，用于对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果；客户端工具，还用于从测试设备获取覆盖率测试结果，并将覆盖率测试结果发送至服务器；服务器，用于将覆盖率测试结果进行html转换，生成覆盖率报告；客户端工具，还用于从服务器获取并输出覆盖率报告。

根据本发明实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行覆盖率测试方法。

根据本发明实施例的另一方面，还提供了一种处理器，该处理器用于运行程序，其中，程序运行时执行覆盖率测试方法。

在本发明实施例中，采用端到端覆盖的方式，通过客户端工具获取待测应用的测试数据，并根据测试数据对待测应用进行插桩，以得到插桩后的待测应用。然后，客户端工具将插桩后的待测应用发送至测试设备，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

在上述过程中，在客户端工具对待测应用的测试数据进行插桩之后，由测试设备对待测应用进行覆盖率测试。由于对待测应用的测试数据进行了插桩处理，因此，客户端工具可以得到待测应用中每个插桩位置处相关数据的信息，进而得到准确的覆盖率，避免了漏测的问题，提高了覆盖率的测试准确度。另外，由于测试设备与客户端工具之间可进行通信，因此，在测试设备得到覆盖率测试结果之后，测试设备和客户端工具均可对覆盖率的测试结果进行显示，从而避免了现有技术中覆盖率测试结果不可见的问题。

由此可见，本申请所提供的方案可以解决相关技术中代码覆盖率的测试准确度较低的技术问题。

附图说明

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

图1是根据本申请实施例的一种覆盖率测试系统的结构示意图；

图2是根据本申请实施例的一种覆盖率测试方法的流程图；

图3是根据本申请实施例的一种可选的客户端工具与测试设备的交互示意图；

图4是根据本申请实施例的一种可选的目标用例的拉取示意图；

图5是根据本申请实施例的一种可选的覆盖率测试方法的流程图；

图6是根据本申请实施例的一种可选的风险评估内容的示意图；

图7是根据本申请实施例的一种覆盖率测试方法的流程图；

图8是根据本申请实施例的一种覆盖率测试系统的结构示意图；

图9是根据本申请实施例的一种覆盖率测试方法的流程图；

图10是根据本申请实施例的一种可选的服务器与客户端工具的交互示意图；

图11是根据本申请实施例的一种可选的待测应用的插桩流程图；

图12是根据本申请实施例的一种可选的覆盖率报告的生成示意图；

图13是根据本申请实施例的一种可选的确定测试的执行时间的流程图；

图14是根据本申请实施例的一种可选的服务器端的目标结构示意图；

图15是根据本申请实施例的一种可选的覆盖率测试系统的交互示意图；

图16是根据本申请实施例的一种可选的覆盖率测试系统的结构示意图；

图17是根据本申请实施例的一种覆盖率测试装置的结构示意图；

图18是根据本申请实施例的一种覆盖率测试装置的结构示意图；

图19是根据本申请实施例的一种覆盖率测试装置的结构示意图；以及

图20是根据本申请实施例的一种计算机终端的结构框图。

具体实施方式

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

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

首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

用例，usecase，指在不展现系统或子系统内部结构的情况下，对系统或子系统中连贯的功能单元的定义和描述。

插桩，指在程序中插入额外的代码以获得程序在执行过程中的行为信息的方法。

黑盒测试，也称功能测试，指通过测试来检测程序所实现的每个功能是否符合预期。

实施例1

根据本申请实施例，提供了一种覆盖率测试方法实施例，需要说明的是，在本实施例中，采用纯客户端工具的方式(即客户端工具不与服务器进行交互)实现对覆盖率的测试。在本实施例中，通过端到端覆盖的方式获取应用测试过程中代码的覆盖情况，为测试人员提供测试用例的覆盖情况，有助于测试人员结合未覆盖的代码以及测试的执行情况对代码进行风险评估，进而排除应用或代码的潜在风险。

此外，还需要说明的是，代码覆盖率技术是通过运行经过编译插桩后的程序代码，结合源代码将实际代码运行的情况进行输出展示，进而对未执行的代码块进行风险评估的方法。对于不同的编程语言，可使用不同的覆盖率工具对应用进行覆盖率测试，其中，使用覆盖率测试工具可完成对程序代码的插桩以及覆盖率结果的生成。

在本实施例中，图1示出了一种覆盖率测试系统的结构示意图，在图1所示的覆盖率测试系统中可执行覆盖率测试方法。由图1可知，本申请所提供的覆盖率测试系统包括：(图1中仅示出了一个)至少一个客户端工具101和至少一个测试设备103(图1中仅示出了一个)。其中，至少一个客户端工具为具有显示功能的设备，例如，电脑；至少一个测试设备可以为电脑、手机、平板、智能手环、智能眼镜等可移动设备，也可以为不可移动设备，图1仅示出了测试设备为可移动的情况。另外，需要说明的是，在本实施例中，执行覆盖测试方法的执行主体为客户端工具。

具体的，图1中所示的客户端工具可执行图2所示的覆盖率测试方法，具体步骤如下：

步骤s202，获取待测应用的测试数据。

在步骤s202中，待测应用的测试数据包括待测应用版本以及待测应用(可以为但不限于待测应用的程序代码)。

在一种可选的方案中，待测应用的测试数据可以存储在客户端工具本地的存储区域(例如，本地数据库)中。当测试人员需要对待测应用进行测试时，测试人员通过输入设备(例如，鼠标、键盘)输入待测应用的标识信息，例如，待测应用的名称、id。在接收到测试人员输入的待测应用的标识信息之后，客户端工具从本地的存储区域中查找与标识信息对应的待测应用的测试数据。

步骤s204，根据测试数据，对待测应用进行插桩，得到插桩后的待测应用。

在步骤s204中，在得到测试数据之后，客户端工具可根据待测应用版本对待测应用进行插桩处理。在对待测应用进行插桩之前，客户端工具需要首先需要确定待测应用版本中的待测应用的版本是否已插桩。如果检测待测应用的版本未进行插桩，客户端工具再对待测应用进行插桩，并将插桩后的待测应用发送至测试设备中。

需要说明的是，在对待测应用进行插桩的过程中，客户端工具需要检测待测应用对应的编程语言，针对不同的编程语言对待测应用采用不同的插桩方式，例如，对于javascript语言使用istanbul工具进行插桩，对于java语言使用jacoco工具进行插桩，对于c/c++语言使用gcov工具进行插桩。

步骤s206，将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

需要说明的是，在接收到插桩后的待测应用之后，测试设备根据不同的插桩方式采用不同的测试方式对插桩后的待测应用进行覆盖率测试。在一种可选的实现方式中，客户端工具也可以在本地对插桩方式和测试方式进行适配，并将适配结果存储在客户端工具本地。在客户端工具完成了对待测应用的插桩之后，客户端工具在本地确定插桩后的待测应用的测试方式，并将插桩后的待测应用以及测试方式发送至测试设备。

另外，在测试设备对待测应用进行覆盖率测试得到覆盖率测试结果之后，测试设备可将覆盖率测试结果发送至客户端工具，由客户端工具生成覆盖率报告，并进行显示，以供测试人员进行分析。

基于上述步骤s202至步骤s206所限定的方案，可以获知，采用端到端覆盖的方式，通过客户端工具获取待测应用的测试数据，并根据测试数据对待测应用进行插桩，以得到插桩后的待测应用。然后，客户端工具将插桩后的待测应用发送至测试设备，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

容易注意到的是，在客户端工具对待测应用的测试数据进行插桩之后，由测试设备对待测应用进行覆盖率测试。由于对待测应用的测试数据进行了插桩处理，因此，客户端工具可以得到待测应用中每个插桩位置处相关数据的信息，进而得到准确的覆盖率，避免了漏测的问题，提高了覆盖率的测试准确度。另外，由于测试设备与客户端工具之间可进行通信，因此，在测试设备得到覆盖率测试结果之后，测试设备和客户端工具均可对覆盖率的测试结果进行显示，从而避免了现有技术中覆盖率测试结果不可见的问题。

由此可见，本申请所提供的方案可以解决相关技术中代码覆盖率的测试准确度较低的技术问题。

可选的，在得到待测应用的测试数据之后，客户端工具对待测应用进行插桩处理。首先，客户端工具根据待测应用版本，判断待测应用对应的版本是否已插桩。例如，待测应用版本包含每个待测应用的标识信息、每个待测应用的版本的插桩状态，以及待测应用的标识信息与插桩状态的对应关系。客户端工具在得到待测应用的标识信息之后，从待测应用版本中可查询到待测应用的插桩状态。若未插桩，则客户端工具对待测应用进行插桩处理，并将插桩后的待测应用发送至测试设备。

需要说明的是，在接收到插桩后的待测应用之后，测试设备按照不同编程语言插桩的技术方式，对待测应用进行场景测试，生成覆盖率测试结果。例如，对于javascript语言使用istanbul工具对待测应用进行场景测试，对于java语言使用jacoco工具对待测应用进行场景测试，对于c/c++语言使用gcov工具对待测应用进行场景测试。

在测试设备生成待测应用的覆盖率测试结果之后，客户端工具根据覆盖率测试结果生成覆盖率测试报告，具体方法可以包括：

步骤s2080，基于选择的待测应用，从测试设备拉取待测应用对应的覆盖率测试结果；

步骤s2082，将覆盖率测试结果进行超文本标记语言html转换，生成并输出覆盖率报告。

在一种可选的方案中，在测试设备生成待测应用的覆盖率测试结果之后，测试设备向客户端工具发送覆盖率测试结果生成的确认消息，客户端工具在接收到确认消息之后，根据待测应用的标识信息从测试设备确定待测应用对应的覆盖率测试结果，然后再从测试设备中拉取待测应用对应的覆盖率测试结果，并存储在本地的存储区域中，并将覆盖率测试结果进行超文本标记语言转换，生成覆盖率报告，并在客户端工具上进行展示。

需要说明的是，现有的测试方案无法评估测试人员在测试用例的具体执行时间，只能采取经验值，用例的测试时长无法控制。为解决上述问题，本申请所提供的覆盖率测试方法在将插桩后的待测应用发送至测试设备之后，还可实现测试的执行时长与测试用例的匹配，如图3所示的客户端工具与测试设备的交互示意图。由图3可知，该过程包括如下步骤：

步骤s31，客户端工具获取与待测应用关联的目标用例。具体的，客户端工具可从本地的存储区域中获取到与待测应用关联的目标用例。

步骤s32，客户端工具接收开始测试命令。具体的，测试人员通过点击客户端工具中的开始测试按钮，生成开始测试命令。

步骤s33，在接收到开始测试命令的情况下，客户端工具记录开始时间。

步骤s34，客户端工具向测试设备发送测试命令，其中，该测试命令用于指示测试设备清空测试设备中已有的测试结果，测试命令可以为但不限于adb命令。

步骤s35，测试设备在接收到测试命令之后，对目标用例所描述的场景进行测试，得到场景测试结果。

需要说明的是，在接收到测试命令之后，测试设备还可接收测试人员的操作信息，以根据测试人员的操作信息对目标用例进行测试，得到场景测试结果。

步骤s36，客户端工具接收结束测试命令。具体的，在测试设备对目标用例测试完成之后，用户可通过操作客户端工具中的结束按钮，生成结束测试命令。

步骤s37，在接收到结束测试命令的情况下，客户端工具记录结束时间。

步骤s38，客户端工具从测试设备拉取场景测试结果。

步骤s39，客户端工具依据开始时间、结束时间及从步骤s38中得到场景测试结果，更新目标用例的测试结果、执行对象及执行时间。

步骤s40，客户端工具从场景测试结果中解析出源代码文件列表。

步骤s41，客户端工具将源代码文件列表与目标用例进行关联。

至此，客户端工具便完成了测试的执行时长与测试用例的匹配。另外，在执行上述步骤s31至步骤s41之后，客户端工具可将执行上述步骤中的执行时间、执行对象、测试结果等内容存储在客户端工具本地的存储区域中。在确定每个用例的具体执行时间后，客户端工具可以通过统计分析的方式计算出测试待测应用的执行时长。

需要说明的是，目标用例对应的代码信息可以在源代码发生变动之后，源代码文件列表也将发生变化，客户端工具可根据变换后的源代码文件列表选取最小的回归测试用例集合，以进行回归测试。

在一种可选的方案中，如图4所示，目标用例的拉取过程可以包括如下步骤：

步骤s401，基于选择的待测应用，获取待测应用的用例。具体的，测试人员通过客户端工具的显示界面选择待测应用，客户端工具获取待测应用的标识信息，并根据标识信息从客户端工具本地得到待测应用对应的用例。

步骤s402，客户端工具将待测应用的当前版本与上一版本进行对比，获取变更代码列表。其中，客户端工具可通过git(一种分布式版本控制系统)或svn(一种开放源代码的版本控制系统)来获取版本变更过程中代码的变动情况，并生成变更代码列表。

步骤s403，客户端工具查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中。

步骤s404，客户端工具从变更代码列表中移除用例关联的代码列表。

步骤s405，客户端工具判断变更代码列表中是否还包含文件。其中，如果变更代码列表中不包含文件，则执行步骤s406，否则执行步骤s403。

步骤s406，客户端工具根据第二用例列表中的用例创建测试计划。

需要说明的是，在执行步骤s401至步骤s406之后，上述过程中所产生的数据可保存在客户端工具的本地内存中，例如，存储在数据库中，客户端工具可从数据库中获取测试计划对应的用例集合。

进一步地，在测试计划的创建完成之后，测试人员可确定需要额外增加代码覆盖的场景，并通过点击客户端工具中的测试工具来查看代码覆盖的增长情况。在这个过程中，客户端工具不会生成具体的覆盖率测试结果，而是仅提示测试人员本次测试覆盖与上次覆盖结果合并后的增长情况。如图5所示，上述过程可以包括如下步骤：

步骤s51，客户端工具从测试设备获取新的覆盖率测试结果。具体的，测试人员在查看覆盖率增长情况之后，通过客户端工具从测试设备上拉取新的覆盖率测试结果。

步骤s52，客户端工具解析新的覆盖率测试结果，生成第一对象，其中，第一对象可以为map对象。

步骤s53，客户端工具解析原覆盖率报告，生成第二对象，其中，第二对象是与第一对象的对象类型相同的对象，在第一对象为map对象的情况下，第二对象也可以为map对象。

步骤s54，客户端工具遍历第一对象，判断在第二对象中是否存在第一对象中的内容。其中，如果第二对象中存在第一对象的内容，则执行步骤s55，否则执行步骤s56。

步骤s55，客户端工具输出第一提示信息，第一提示信息用于指示覆盖率不变。

步骤s56，客户端工具输出第二提示信息，第二提示信息用于指示覆盖率增加。

需要说明的是，本申请所提供的覆盖率测试方法还可根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，其中，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。具体的，图6示出了一种风险评估内容的示意图，由图6可知，风险评估主要对以下三类进行风险评估，即文件未覆盖、函数未覆盖以及分支未覆盖。每种类型又包括四种情况，即无用代码、场景需补充、难以覆盖以及其他情况。其中，对于无用代码，可以采用移除无用代码的方式降低风险；对于场景需要补充的情况，可采用补充测试用例的方式降低风险；对于难以覆盖的情况，可采用风险评估说明的方式降低风险；对于其他情况，可通过扩展分类和评估的方式降低风险。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的覆盖率测试方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

实施例2

根据本申请实施例，还提供了一种覆盖率测试方法实施例，需要说明的是，图1中的测试设备可作为本实施例的执行主体，以执行图7所示的覆盖率测试方法，如图7可知，本申请所提供的覆盖率测试方法可以包括如下步骤：

步骤s702，接收客户端工具发送的插桩后的待测应用，其中，由所述客户端工具根据所述待测应用的测试数据，对所述待测应用进行插桩，得到所述插桩后的待测应用。

在上述步骤s702中，待测应用的测试数据包括待测应用版本以及待测应用(可以为但不限于待测应用的程序代码)。

在一种可选的方案中，当测试人员需要对待测应用进行测试时，测试人员通过客户端工具确定需要进行测试的待测应用，此时，客户端工具可得到测试人员所选择的待测应用的标识信息(例如，待测应用的名称)，进而根据待测应用的标识信息在客户端工具的本地查询得到待测应用的测试数据。然后，确定待测应用版本中的待测应用的版本是否已插桩。如果检测待测应用的版本未进行插桩，客户端工具再对待测应用进行插桩，并将插桩后的待测应用发送至测试设备中，测试设备即可获得插桩后的待测应用，并对插桩后的待测应用进行覆盖率测试。

步骤s704，对所述插桩后的待测应用进行覆盖率测试，得到所述待测应用的覆盖率测试结果。

在上述步骤s704中，在接收到插桩后的待测应用之后，测试设备按照不同编程语言插桩的技术方式，对待测应用进行场景测试，生成覆盖率测试结果。例如，对于javascript语言使用istanbul工具对待测应用进行场景测试，对于java语言使用jacoco工具对待测应用进行场景测试，对于c/c++语言使用gcov工具对待测应用进行场景测试。在测试设备对待测应用进行覆盖率测试得到覆盖率测试结果之后，测试设备可将覆盖率测试结果发送至客户端工具，由客户端工具生成覆盖率报告，并进行显示，以供测试人员进行分析。

基于上述步骤s702至步骤s704所限定的方案，可以获知，采用端到端覆盖的方式，通过客户端工具获取待测应用的测试数据，并根据测试数据对待测应用进行插桩，以得到插桩后的待测应用。然后，客户端工具将插桩后的待测应用发送至测试设备，测试设备接收客户端工具发送的插桩后的待测应用，并对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

容易注意到的是，在客户端工具对待测应用的测试数据进行插桩之后，由测试设备对待测应用进行覆盖率测试。由于对待测应用的测试数据进行了插桩处理，因此，客户端工具可以得到待测应用中每个插桩位置处相关数据的信息，进而得到准确的覆盖率，避免了漏测的问题，提高了覆盖率的测试准确度。另外，由于测试设备与客户端工具之间可进行通信，因此，在测试设备得到覆盖率测试结果之后，测试设备和客户端工具均可对覆盖率的测试结果进行显示，从而避免了现有技术中覆盖率测试结果不可见的问题。

由此可见，本申请所提供的方案可以解决相关技术中代码覆盖率的测试准确度较低的技术问题。

需要说明的是，本实施例中的覆盖率测试方法包括实施例1中测试设备所执行所有方法，在此不再赘述。

实施例3

根据本申请实施例，还提供了一种覆盖率测试方法实施例，需要说明的是，在本实施例中，执行覆盖率测试方法的执行主体为服务器，其中，服务器可以为图8所示的覆盖率测试系统中的服务器805。

此外，还需要说明的是，在图8所示的覆盖率测试系统的结构示意图中，测试设备801的数量可以为一个，也可以为多个(图8中仅示出了一个)。同样的，客户端工具803的数量可以为一个，也可以为多个(图8中仅示出了一个)。其中，客户端工具可以为具有显示功能的设备，例如，电脑；测试设备可以为电脑、手机、平板、智能手环、智能眼镜等可移动设备，也可以为不可移动设备。

在图8所示的覆盖率测试系统中，本申请还提供了图9所示的覆盖率测试方法。具体的，由图9所示，该方法主要包括如下步骤：

步骤s902，接收客户端工具发送的插桩处理消息，插桩处理消息指示需插桩的待测应用。

在一种可选的方案中，用户通过客户端工具选择需要进行测试的待测应用，例如，用户在客户端工具中输入待测应用的标识信息(例如，待测应用的名称)来确定待测应用。在确定需要进行测试的待测应用之后，客户端工具生成插桩处理消息，并将插桩处理消息发送至服务器，其中，插桩处理消息中可包含待测应用的标识信息。服务器在接收到客户端工具发送的插桩处理消息之后，根据插桩处理消息中的标识信息查询得到待测应用的测试数据，然后根据待测应用的测试数据对待测应用进行插桩处理。

步骤s904，根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用。

需要说明的是，待测应用的测试数据包括待测应用的待测应用版本以及待测应用(可以为但不限于待测应用的程序代码)。

在步骤s904中，在得到测试数据之后，服务器可根据待测应用版本对待测应用进行插桩处理。在对待测应用进行插桩之前，服务器首先需要确定待测应用版本中的待测应用的版本是否已插桩。如果检测待测应用的版本未进行插桩，服务器再对待测应用进行插桩，并将插桩后的待测应用发送至客户端工具。

此外，还需要说明的是，在对待测应用进行插桩的过程中，服务器需要检测待测应用对应的编程语言，针对不同的编程语言对待测应用采用不同的插桩方式，例如，对于javascript语言使用istanbul工具进行插桩，对于java语言使用jacoco工具进行插桩，对于c/c++语言使用gcov工具进行插桩。

步骤s906，将插桩后的待测应用通过客户端工具更新至待测设备后，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

需要说明的是，在接收到插桩后的待测应用之后，测试设备根据不同的插桩方式采用不同的测试方式对插桩后的待测应用进行覆盖率测试。在一种可实现的方式中，服务器也可对插桩方式和测试方法进行适配，并将适配结果存储在服务器中，例如，存储在服务器的数据库中。在完成对待测应用的插桩之后，服务器根据待测应用的插桩方式确定插桩后的待测应用的覆盖率测试方式，然后将插桩后的待测应用以及测试方式发送至客户端工具，再由客户端工具将插桩后的待测应用以及测试方式更新至测试设备。测试设备在接收到插桩后的待测应用以及测试方式之后，使用接收到的测试方式对待测应用进行覆盖率测试。

另外，在测试设备对待测应用进行覆盖率测试得到覆盖率测试结果之后，测试设备可将覆盖率测试结果发送至客户端工具，由客户端工具进行展示。同时，客户端工具将覆盖率测试结果上传至服务器，由服务器根据覆盖率测试结果生成覆盖率测试报告，并将覆盖率测试报告发送至客户端工具，由客户端工具展示给测试人员，以供测试人员进行分析。

基于上述步骤s902至步骤s906所限定的方案，可以获知，采用端到端覆盖的方式，通过服务器接收客户端工具发送的插桩处理消息，然后根据待测应用的测试数据对待测应用进行插桩，得到插桩后的待测应用，并将插桩后的待测应用发送至客户端工具，以便客户端工具将插桩后的待测应用发送至测试设备后，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果，其中，插桩处理消息指示需插桩的待测应用。

容易注意到的是，在服务器对待测应用的测试数据进行插桩之后，由测试设备对插桩后的待测应用进行覆盖率测试。由于对待测应用的测试数据进行了插桩处理，因此，服务器可以得到待测应用中每个插桩位置处相关数据的信息，进而得到准确的覆盖率，避免了漏测的问题，提高了覆盖率的测试准确度。另外，由于测试设备可通过客户端工具与服务器进行通信，因此，在测试设备得到覆盖率测试结果之后，服务器和客户端工具均可对覆盖率的测试结果进行显示，从而避免了现有技术中覆盖率测试结果不可见的问题。

由此可见，本申请所提供的方案可以解决相关技术中代码覆盖率的测试准确度较低的技术问题。

在一种可选的方案中，在接收客户端工具发送的插桩处理消息之前，服务器需要获取待测应用的测试数据，如图10所示的服务器与客户端工具的交互示意图，具体步骤如下：

步骤s10，客户端工具向服务器发送数据请求消息，其中，数据请求消息携带待测应用的标识。具体的，测试人员在客户端工具上选择需要进行测试的应用，客户端工具在确定测试人员已经选择待测应用之后，获取待测应用的标识，并根据待测应用的标识生成数据请求消息，然后将数据请求消息发送至服务器。

步骤s12，服务器接收数据请求消息。

步骤s14，服务器根据待测应用的标识，将测试数据发送至客户端工具，其中，测试数据包括待测应用及待测应用版本。可选的，服务器的存储区域中存储有待测应用的测试数据，在接收到客户端工具发送的数据请求之后，服务器根据待测应用的标识在服务器的存储区域(例如，数据库)中查找与标识对应的测试数据，并将查找到的测试数据发送至客户端工具。

步骤s16，客户端工具基于测试数据更新本地配置。其中，客户端工具根据接收到的待测应用以及待测应用版本对客户端工具的本地配置进行更新。

需要说明的是，在上述步骤s10至步骤s12所述的过程中，服务器在将测试数据发送至客户端工具的同时，服务器也得到了测试数据。服务器在得到测试数据之后，可根据测试数据对待测应用进行插桩处理，其中，服务器对待测应用的插桩流程如图11所示，具体步骤如下：

步骤s1101，根据待测应用版本，判断待测应用对应的版本是否已插桩。可选的，待测应用版本可以包含每个待测应用的标识信息、每个待测应用的版本的插桩状态，以及待测应用的标识信息与插桩状态的对应关系，服务器在得到待测应用版本之后，根据待测应用的标识在待测应用版本中查询待测应用的插桩状态。其中，如果待测应用对应的版本已经插桩，则服务器执行步骤s1102；否则，服务器执行步骤s1103。

步骤s1102，若已插桩，则服务器将插桩代码地址发送至客户端工具，以便客户端工具根据插桩代码地址提取插桩后的待测应用。

步骤s1103，若未插桩，则服务器根据测试数据对待测应用进行插桩，得到插桩代码地址，并将插桩代码地址发送至客户端工具，以便客户端工具根据插桩代码地址提取插桩后的待测应用。具体的，在检测到待测应用对应的版本未插桩之后，服务器生成待测应用的新版本对应的数据，并触发服务器中的插桩程序，以对待测应用新版本的插桩。

进一步地，根据图11所示的流程图可知，在根据测试数据对待测应用进行插桩之后，服务器还执行如下步骤：

步骤s1104，服务器接收客户端工具发送的插桩查询消息，插桩查询消息用于询问是否完成插桩。其中，客户端工具每隔预设时间向服务器发起插桩查询消息。

步骤s1105，服务器判断是否完成插桩。其中，如果检测到待测应用未完成插桩，则服务器执行步骤s1106；否则，服务器执行步骤s1107。

步骤s1106，若未完成插桩，将用于指示未完成插桩的第一状态信息发送至客户端工具。

步骤s1107，若已完成插桩，将用于指示已完成插桩的第二状态信息以及插桩代码地址发送至客户端工具。

需要说明的是，在接收到第一状态信息或第二状态信息之后，客户端工具根据第一状态信息或第二状态信息更新本地版本信息，并检测本地是否已有插桩后的待测应用。如果检测到本地已有插桩后的待测应用，则客户端工具对插桩后的待测应用进行解压，并将解压后的待测应用推送给测试设备；如果检测到本地没有插桩后的待测应用，在客户端工具从服务器下载插桩后的待测应用，并在对插桩后的待测应用进行解压后，将其推送给测试设备。

进一步地，在客户端工具从服务器中拉取插桩后的待测应用之后，客户端工具将插桩后的待测应用通过客户端工具更新至待测设备，测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。此时，测试人员通过客户端工具从测试设备拉取待测应用对应的覆盖率测试结果，并将覆盖率测试结果发送给服务器，由服务器生成覆盖率报告，如图12所示的覆盖率报告的生成示意图，由图12可知，该过程主要包括以下步骤：

步骤s1201，服务器接收待测应用的覆盖率测试结果。

步骤s1202，服务器将覆盖率测试结果进行html转换，生成覆盖率报告。

步骤s1203，服务器将用于指示报告生成中的第三状态信息发送至客户端工具。

步骤s1204，客户端工具在接收到服务器发送的第三状态信息之后，每隔预设时间向服务器发送报告查询消息，其中，报告查询消息用于询问是否生成覆盖率报告。

步骤s1205，服务器接收客户端工具发送的报告查询消息。

步骤s1206，服务器判断是否生成覆盖率报告。其中，如果检测到还未生成覆盖率报告，则服务器执行步骤s1207；否则，服务器执行步骤s1208。

步骤s1207，若未生成覆盖率报告，将第三状态信息发送至客户端工具，客户端工具执行步骤s1204继续向服务器发送报告查询消息，进而服务器继续判断是否生成覆盖率报告，直至生成覆盖率报告为止。

步骤s1208，若已生成覆盖率报告，将用于指示报告已生成的第四状态信息及报告下载地址发送至客户端工具，以便客户端工具根据报告下载地址下载覆盖率报告。

步骤s1209，在接收到第四状态信息以及报告下载地址之后，客户端工具根据报告下载地址下载覆盖率报告，并向测试人员展示覆盖率报告。

需要说明的是，现有的测试方案无法评估测试人员在测试用例的具体执行时间，只能采取经验值，用例的测试时长无法控制。为解决上述问题，本申请所提供的覆盖率测试方法在将插桩后的待测应用发送至测试设备之后，还可实现测试的执行时长与测试用例的匹配，如图13所示的确定测试的执行时间的流程图。由图13可知，该过程包括如下步骤：

步骤s1301，客户端工具对测试用例进行同步，并向服务器发送用例数据请求，其中，用例数据请求用于获取与待测应用关联的目标用例。

步骤s1302，服务器接收客户端工具发送的用例数据请求，并根据用例数据请求查询得到与待测应用关联的目标用例，可选的，服务器可从服务器本地的数据库中根据用例数据请求查询得到目标用例。

步骤s1303，服务器将目标用例发送至客户端工具。

步骤s1304，客户端工具接收目标用例。同时，客户端工具还可接收测试人员发出的开始测试命令，可选的，测试人员可通过客户端工具的输入设备(例如，鼠标、键盘等)向服务器发出开始测试命令。在接收到开始测试命令的情况下，客户端工具记录开始时间并向测试设备发送测试命令，其中，该测试命令用于指示测试设备清空测试设备中已有的测试结果，测试命令可以为但不限于adb命令。

步骤s1305，测试设备对目标用例所描述的场景进行测试，得到场景测试结果，并发送场景测试结果至客户端工具。

步骤s1306，客户端工具在接收到结束测试命令的情况下，记录结束时间并从测试设备拉取场景测试结果。

步骤s1307，客户端工具将目标用例的标识、开始时间、结束时间及场景测试结果发送至服务器。

步骤s1308，服务器接收客户端工具发送的目标用例的标识、开始时间、结束时间及场景测试结果。

步骤s1309，服务器根据客户端工具发送的目标用例的标识、开始时间、结束时间及场景测试结果更新目标用例的测试结果、执行对象及执行时间。

步骤s1310，服务器从场景测试结果中解析出源代码文件列表。

步骤s1311，服务器将源代码文件列表与目标用例进行关联。

至此，便完成了测试的执行时长与测试用例的匹配。另外，在执行上述步骤s1301至步骤s1311之后，服务器可将执行上述步骤中的执行时间、执行对象、测试结果等内容存储在服务器本地的存储区域中。在确定每个用例的具体执行时间后，服务器可以通过统计分析的方式计算出测试待测应用的执行时长。

需要说明的是，目标用例对应的代码信息可以在源代码发生变动之后，源代码文件列表也将发生变化，服务器可根据变换后的源代码文件列表选取最小的回归测试用例集合，以进行回归测试。

在一种可选的方案中，目标用例的拉取过程可以包括如下步骤：

步骤s1401，服务器基于选择的待测应用，获取待测应用的用例。具体的，测试人员通过客户端工具的显示界面选择待测应用，客户端工具将选择的待测应用的标识发送至服务器，服务器根据接收到的待测应用的标识确定待测应用对应的用例。

步骤s1402，服务器将待测应用的当前版本与上一版本进行对比，获取变更代码列表。其中，服务器可通过git(一种分布式版本控制系)或svn(一种开放源代码的版本控制系统)来获取版本变更过程中代码的变动情况，并生成变更代码列表。

步骤s1403，服务器查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中。

步骤s1404，服务器从变更代码列表中移除用例关联的代码列表。

步骤s1405，服务器判断变更代码列表中是否还包含文件。其中，如果变更代码列表中不包含文件，则执行步骤s1406，否则执行步骤s1403。

步骤s1406，若不包含任何文件，服务器根据第二用例列表中的用例创建测试计划。

需要说明的是，在执行步骤s1401至步骤s1406之后，上述过程中所产生的数据可保存在服务器的本地内容中，例如，存储在数据库中，客户端工具可从服务器的数据库中获取测试计划对应的用例集合。

进一步地，在测试计划的创建完成之后，测试人员可确定需要额外增加代码覆盖的场景，并通过点击客户端工具中的测试工具来查看代码覆盖的增长情况。在这个过程中，客户端工具不会生成具体的覆盖率测试结果，而是仅提示测试人员本次测试覆盖与上次覆盖结果合并后的增长情况。在测试人员触发查看覆盖率测试结果之后，客户端工具将新的覆盖率测试结果上传服务器。服务器根据覆盖率测试结果确定覆盖率增长的情况，具体步骤可以包括：

步骤s1501，服务器接收客户端工具发送的新的覆盖率测试结果。具体的，测试人员在查看覆盖率增长情况之后，客户端工具从测试设备上拉取新的覆盖率测试结果，并将新的覆盖率测试结果发送至服务器。

步骤s1502，服务器解析新的覆盖率测试结果，生成第一对象。其中，第一对象可以为map对象。

步骤s1503，服务器解析原覆盖率报告，生成第二对象，其中，第二对象是与第一对象的对象类型相同的对象，在第一对象为map对象的情况下，第二对象也可以为map对象。

步骤s1504，服务器遍历第一对象，判断在第二对象中是否存在第一对象中的内容。其中，如果第二对象中存在第一对象中的内容，则执行步骤s1505，否则执行步骤s1506。

步骤s1505，服务器将第一提示信息发送至客户端工具，其中，第一提示信息用于指示覆盖率不变。

步骤s1506，服务器将第二提示信息发送至客户端工具，其中，第二提示信息用于指示覆盖率增加。

需要说明的是，服务器还可配置待测应用的参数信息，参数信息包括以下至少之一：类别、名称、代码路径、版本信息、覆盖率测试结果的目录。其中，覆盖率测试结果的目录的结构包括：用于存放覆盖率测试结果和覆盖率报告的根目录；根目录下的至少一个子目录，用于存储不同应用的覆盖率测试结果；子目录下包括至少一个应用代码目录，用于存储提交测试代码稳定后对应的一个版本；应用代码目录包括结果目录及报告目录，结果子目录用于存储从客户端工具上传的覆盖率测试结果，报告子目录用于存储覆盖率报告。

在一种可选的方案中，如图14所示的服务器端的目录结构示意图，其中，cov_result为用于存放覆盖率测试结果和覆盖率报告的根目录。每一个待测应用在根目录下存在对应的一个子目录，子目录可以以“id_待测应用名称”的方式命名，如图14中的“id1_appname1”和“id2_appname2”，分别为id为id1、名称为appname1的子目录，id为id2、名称为appname2的子目录，其中，不同的待测应用的覆盖率测试结果同步后将保存至对应待测应用的子目录下。如图14所示，每个子目录包括至少一个应用代码目录，每个应用代码目录存储的是测试期间代码不发生变化的版本，其中，不同版本的覆盖率测试结果同步后保存至对应版本的应用代码目录下。另外，应用代码目录的命名方式可以为“应用名称_版本”，例如，图14中的“app1_version1”、“app1_version2”、“app1_version2”分别表示名称为app1的三个版本的应用代码目录。另外，如图14所示，应用代码目录包括结果目录(例如，图14中的“test1_result”)及报告目录(例如，图14中的“test1_report”)。

需要说明的是，对于javascript应用(其他应用存放格式类似，但具体结果文件名后缀会有不同)每次整体测试在客户端工具上会生成若干个json文件，在同步至服务器之后，整体将放在同一个测试结果目录下，如图14中的“test1_result”目录下，其中，目录名称的命名方式为“测试标识_result”。每次测试根据模块包含的文件列表以及合并结果存放到结果目录中，合并结果文件以模块名命名，如图14中的“module1.json”和“module2.json”。在进行逐条用例的精准测试过程后，测试结果同步到服务器的结果目录。每次测试，生成的报告根据模块分别存放在报告目录(如图14中的“test1_report”和“test2_report”)下的没模块测试结果目录(如图14中的“module1_report_dir”和“module2_report_dir”)中。

另外，待测应用的模块划分存放在服务器的列表表中，每一个模块包含若干条数据，每条数据中包括模块标识、代码相对目录以及其目录中例外的子目录和文件的相对路径列表。每次测试在报告生成前，服务器需要先合并生成模块的结果数据，例如，可通过将当前测试结果中模块对应文件列表的覆盖率数据合并到之前合并的结果文件中的方法生成模块的结果数据。

此外，还需要说明的是，本申请所提供的覆盖率测试方法还可根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，其中，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。具体的，图6示出了一种风险评估内容的示意图，由图6可知，风险评估主要对以下三类进行风险评估，即文件未覆盖、函数未覆盖以及分支未覆盖。每种类型又包括四种情况，即无用代码、场景需补充、难以覆盖以及其他情况。其中，对于无用代码，可以采用移除无用代码的方式降低风险；对于场景需要补充的情况，可采用补充测试用例的方式降低风险；对于难以覆盖的情况，可采用风险评估说明的方式降低风险；对于其他情况，可通过扩展分类和评估的方式降低风险。

实施例4

根据本申请实施例，还提供了一种用于实施上实施例1和实施例2中的覆盖率测试方法的覆盖率测试系统，如图1所示，该系统包括：至少一个客户端工具101(图1中仅示出了一个)以及至少一个测试设备103(图1中仅示出了一个)。

其中，至少一个客户端工具用于执行实施例1中的覆盖率测试方法，至少一个测试设备，与至少一个客户端工具对应，用于执行实施例2中的覆盖率测试方法。

需要说明的是，至少一个客户端工具以及至少一个测试设备所执行的方法，与实施例1和实施例2中所述的方法相同，在此不再赘述。

实施例5

根据本申请实施例，还提供了一种用于实施上实施例3中的覆盖率测试方法的覆盖率测试系统，如图8所示，该系统包括：测试设备801、客户端工具803以及服务器805。

具体的，图15示出了覆盖率测试系统的交互示意图，如图15所示，覆盖率测试系统的交互过程如下：

步骤s1601，客户端工具从服务器获取待测应用的测试数据，并更新本地的配置。

步骤s1602，客户端工具将插桩处理消息发送至服务器，其中，插桩处理消息指示需插桩的待测应用。可选的，测试人员通过客户端工具确定需要进行测试的待测应用。客户端工具在确定待测应用之后，将插桩处理消息发送至服务器，其中，插桩处理消息中包含有待测应用的标识，服务器根据待测应用的标识可确定插桩方式。。

步骤s1603，服务器根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用。

步骤s1604，服务器将插桩后的待测应用发送至客户端工具。

步骤s1605，客户端工具将插桩后的待测应用发送至测试设备。

步骤s1606，测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

步骤s1607，客户端工具从测试设备获取覆盖率测试结果，并将覆盖率测试结果发送至服务器。

步骤s1608，服务器将覆盖率测试结果进行html转换，生成覆盖率报告。

步骤s1609，客户端工具从服务器获取并输出覆盖率报告。

由上述内容可知，采用端到端覆盖的方式，通过客户端工具从服务器获取待测应用的测试数据，并将插桩处理消息发送至服务器。服务器根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用，并将插桩后的待测应用发送至客户端工具。然后，客户端工具将插桩后的待测应用发送至测试设备，测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果，客户端工具从测试设备获取覆盖率测试结果，并将覆盖率测试结果发送至服务器，然后，服务器将覆盖率测试结果进行html转换，生成覆盖率报告，最后，客户端工具从服务器获取并输出覆盖率报告。

容易注意到的是，在客户端工具对待测应用的测试数据进行插桩之后，由测试设备对待测应用进行覆盖率测试。由于对待测应用的测试数据进行了插桩处理，因此，客户端工具可以得到待测应用中每个插桩位置处相关数据的信息，进而得到准确的覆盖率，避免了漏测的问题，提高了覆盖率的测试准确度。另外，由于测试设备与客户端工具之间可进行通信，因此，在测试设备得到覆盖率测试结果之后，测试设备和客户端工具均可对覆盖率的测试结果进行显示，从而避免了现有技术中覆盖率测试结果不可见的问题。

由此可见，本申请所提供的方案可以解决相关技术中代码覆盖率的测试准确度较低的技术问题。

在一种可选的方案中，如图16所示的覆盖率测试系统的结构示意图，客户端工具的数量为多个，测试设备的数量为多个，其中，测试设备与客户端工具一一对应，即测试设备的数量与客户端工具的数量相同。

需要说明的是，在客户端工具和测试设备为多个的情况下，服务器所执行的覆盖率测试的方法与在客户端工具和测试设备的数量为一个的情况下相同，在此不再赘述。

实施例6

根据本申请实施例，还提供了一种用于实施上述覆盖率测试方法的覆盖率测试装置，如图17所示，该装置170包括：获取模块1701、插桩模块1703以及发送模块1705。

其中，获取模块1701，用于获取待测应用的测试数据；插桩模块1703，用于根据测试数据，对待测应用进行插桩，得到插桩后的待测应用；发送模块1705，用于将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

此处，需要说明的是，上述获取模块1701、插桩模块1703以及发送模块1705对应于实施例1中的步骤s202至步骤s206，三个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例一所公开的内容。

在一种可选的方案中，发送模块包括：第一生成模块。其中，第一生成模块，用于测试设备按照不同编程语言插桩的技术方式，对待测应用进行场景测试，生成覆盖率测试结果。

在一种可选的方案中，覆盖率测试装置还包括：拉取模块以及第二生成模块。其中，拉取模块，用于基于选择的待测应用，从测试设备拉取待测应用对应的覆盖率测试结果；第二生成模块，用于将覆盖率测试结果进行超文本标记语言html转换，生成并输出覆盖率报告。

此处，需要说明的是，上述拉取模块以及第二生成模块对应于实施例1中的步骤s2080至步骤s2082，两个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例一所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：第一获取模块、第一记录模块、第二记录模块、第二更新模块、解析模块以及关联模块。其中，第一获取模块，用于获取与待测应用关联的目标用例；第一记录模块，用于在接收到开始测试命令的情况下，记录开始时间并向测试设备发送测试命令，其中，由测试设备对目标用例所描述的场景进行测试，得到场景测试结果；第二记录模块，用于在接收到结束测试命令的情况下，记录结束时间并从测试设备拉取场景测试结果；第二更新模块，用于依据开始时间、结束时间及场景测试结果，更新目标用例的测试结果、执行对象及执行时间；解析模块，用于从场景测试结果中解析出源代码文件列表；关联模块，用于将源代码文件列表与目标用例进行关联。

在一种可选的方案中，覆盖率测试装置还包括：第二获取模块、第三获取模块、查询模块、移除模块、第一判断模块以及创建模块。其中，第二获取模块，用于基于选择的待测应用，获取待测应用的用例；第三获取模块，用于将待测应用的当前版本与上一版本进行对比，获取变更代码列表；查询模块，用于查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中；移除模块，用于从变更代码列表中移除用例关联的代码列表；第一判断模块，用于判断变更代码列表中是否还包含文件；创建模块，用于若不包含任何文件，根据第二用例列表中的用例创建测试计划。

此处，需要说明的是，上述第二获取模块、第三获取模块、查询模块、移除模块、第一判断模块以及创建模块对应于实施例1中的步骤s401至步骤s406，六个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例一所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：第四获取模块、第一解析模块、第二解析模块、第二判断模块、第一输出模块以及第二输出模块。其中，第四获取模块，用于从测试设备获取新的覆盖率测试结果；第一解析模块，用于解析新的覆盖率测试结果，生成第一对象；第二解析模块，用于解析原覆盖率报告，生成第二对象；第二判断模块，用于遍历第一对象，判断在第二对象中是否存在第一对象中的内容；第一输出模块，用于若第二对象中存在第一对象中的内容，输出第一提示信息，第一提示信息用于指示覆盖率不变；第二输出模块，用于若第二对象中不存在第一对象中的内容，输出第二提示信息，第二提示信息用于指示覆盖率增加。

此处，需要说明的是，上述第四获取模块、第一解析模块、第二解析模块、第二判断模块、第一输出模块以及第二输出模块对应于实施例1中的步骤s51至步骤s56，六个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例一所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：评估模块。其中，评估模块，用于根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。

实施例7

根据本申请实施例，还提供了一种用于实施上述覆盖率测试方法的覆盖率测试装置，如图18所示，该装置180包括：接收模块1801以及处理模块1803。

其中，接收模块1801，用于接收客户端工具发送的插桩后的待测应用，其中，由客户端工具根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用；处理模块1803，用于对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

此处，需要说明的是，上述接收模块1801以及处理模块1803对应于实施例2中的步骤s702至步骤s704，两个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例二所公开的内容。

实施例8

根据本申请实施例，还提供了一种用于实施上述覆盖率测试方法的覆盖率测试装置，如图19所示，该装置190包括：接收模块1901、插桩模块1903以及拉取模块1905。

其中，接收模块1901，用于接收客户端工具发送的插桩处理消息，插桩处理消息指示需插桩的待测应用；插桩模块1903，用于根据待测应用的测试数据，对待测应用进行插桩，得到插桩后的待测应用；拉取模块1905，用于将插桩后的待测应用通过客户端工具更新至待测设备后，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

此处，需要说明的是，上述接收模块1901、插桩模块1903以及拉取模块1905对应于实施例3中的步骤s902至步骤s906，三个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例三所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：第一接收模块以及第一发送模块。其中，第一接收模块，用于接收客户端工具的数据请求消息，数据请求消息携带待测应用的标识；第一发送模块，用于根据待测应用的标识，将测试数据发送至客户端工具，以便客户端工具基于测试数据更新本地配置，测试数据包括待测应用及待测应用版本。

在一种可选的方案中，插桩模块包括：第一判断模块、第二发送模块以及第三发送模块。其中，第一判断模块，用于根据待测应用版本，判断待测应用对应的版本是否已插桩；第二发送模块，用于若已插桩，将插桩代码地址发送至客户端工具，以便客户端工具根据插桩代码地址提取插桩后的待测应用；第三发送模块，用于若未插桩，根据测试数据对待测应用进行插桩，得到插桩代码地址，并将插桩代码地址发送至客户端工具，以便客户端工具根据插桩代码地址提取插桩后的待测应用。

此处，需要说明的是，上述第一判断模块、第二发送模块以及第三发送模块对应于实施例3中的步骤s1101至步骤s1103，三个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例三所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：第二接收模块、第二判断模块、第四发送模块以及第五发送模块。其中，第二接收模块，用于接收客户端工具发送的插桩查询消息，插桩查询消息用于询问是否完成插桩；第二判断模块，用于判断是否完成插桩；第四发送模块，用于若未完成插桩，将用于指示未完成插桩的第一状态信息发送至客户端工具；第五发送模块，用于若已完成插桩，将用于指示已完成插桩的第二状态信息以及插桩代码地址发送至客户端工具。

此处，需要说明的是，上述第二接收模块、第二判断模块、第四发送模块以及第五发送模块对应于实施例3中的步骤s1104至步骤s1107，四个模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例三所公开的内容。

在一种可选的方案中，覆盖率测试装置还包括：第三接收模块、生成模块、第六发送模块、第四接收模块、第三判断模块、第七发送模块以及第八发送模块。其中，第三接收模块，用于接收待测应用的覆盖率测试结果；生成模块，用于将覆盖率测试结果进行html转换，生成覆盖率报告；第六发送模块，用于将用于指示报告生成中的第三状态信息发送至客户端工具；第四接收模块，用于接收客户端工具发送的报告查询消息，报告查询消息用于询问是否生成覆盖率报告；第三判断模块，用于判断是否生成覆盖率报告；第七发送模块，用于若未生成覆盖率报告，将第三状态信息发送至客户端工具；第八发送模块，用于若已生成覆盖率报告，将用于指示报告已生成的第四状态信息及报告下载地址发送至客户端工具，以便客户端工具根据报告下载地址下载覆盖率报告。

在一种可选的方案中，覆盖率测试装置还包括：第五接收模块、第九发送模块、第六接收模块、更新模块、解析模块以及关联模块。其中，第五接收模块，用于接收客户端工具发送的用例数据请求，用例数据请求用于获取与待测应用关联的目标用例；第九发送模块，用于将目标用例发送至客户端工具，以便客户端工具在接收到开始测试命令的情况下，记录开始时间并向测试设备发送测试命令，其中，由测试设备对目标用例所描述的场景进行测试，得到场景测试结果，客户端工具在接收到结束测试命令的情况下，记录结束时间并从测试设备拉取场景测试结果；第六接收模块，用于接收客户端工具发送的目标用例的标识、开始时间、结束时间及场景测试结果；更新模块，用于更新目标用例的测试结果、执行对象及执行时间；解析模块，用于从场景测试结果中解析出源代码文件列表；关联模块，用于将源代码文件列表与目标用例进行关联。

在一种可选的方案中，覆盖率测试装置还包括：第一获取模块、第二获取模块、查询模块、移除模块、第四判断模块以及创建模块。其中，第一获取模块，用于基于选择的待测应用，获取待测应用的用例；第二获取模块，用于将待测应用的当前版本与上一版本进行对比，获取变更代码列表；查询模块，用于查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中；移除模块，用于从变更代码列表中移除用例关联的代码列表；第四判断模块，用于判断变更代码列表中是否还包含文件；创建模块，用于若不包含任何文件，根据第二用例列表中的用例创建测试计划。

在一种可选的方案中，覆盖率测试装置还包括：第七接收模块、第一生成模块、第二生成模块、第五判断模块、第十发送模块以及第十一发送模块。其中，第七接收模块，用于接收客户端工具发送的新的覆盖率测试结果；第一生成模块，用于解析新的覆盖率测试结果，生成第一对象；第二生成模块，用于解析原覆盖率报告，生成第二对象；第五判断模块，用于遍历第一对象，判断在第二对象中是否存在第一对象中的内容；第十发送模块，用于若第二对象中存在第一对象中的内容，将第一提示信息发送至客户端工具，第一提示信息用于指示覆盖率不变；第十一发送模块，用于若第二对象中不存在第一对象中的内容，将第二提示信息发送至客户端工具，第二提示信息用于指示覆盖率增加。

在一种可选的方案中，覆盖率测试装置还包括：配置模块。其中，配置模块，用于配置待测应用的参数信息，参数信息包括以下至少之一：类别、名称、代码路径、版本信息、覆盖率测试结果的目录。其中，覆盖率测试结果的目录的结构包括：用于存放覆盖率测试结果和覆盖率报告的根目录；根目录下的至少一个子目录，用于存储不同应用的覆盖率测试结果；子目录下包括至少一个应用代码目录，用于存储提交测试代码稳定后对应的一个版本；应用代码目录包括结果目录及报告目录，结果子目录用于存储从客户端工具上传的覆盖率测试结果，报告子目录用于存储覆盖率报告。

在一种可选的方案中，覆盖率测试装置还包括：评估模块。其中，评估模块，用于根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。

实施例9

本申请的实施例可以提供一种计算机终端，该计算机终端可以是计算机终端群中的任意一个计算机终端设备。可选地，在本实施例中，上述计算机终端也可以替换为移动终端等终端设备。

可选地，在本实施例中，上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。

在本实施例中，上述计算机终端可以执行覆盖率测试方法中以下步骤的程序代码：获取待测应用的测试数据；根据测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

可选地，图20是根据本申请实施例的一种计算机终端的结构框图。如图20所示，该计算机终端a可以包括：一个或多个(图中仅示出一个)处理器2002、存储器2004、以及外设接口2006。

其中，存储器可用于存储软件程序以及模块，如本申请实施例中的覆盖率测试方法和装置对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的覆盖率测试方法。存储器可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至终端a。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器可以通过传输装置调用存储器存储的信息及应用程序，以执行下述步骤：获取待测应用的测试数据；根据测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

可选的，上述处理器还可以执行如下步骤的程序代码：测试设备按照不同编程语言插桩的技术方式，对待测应用进行场景测试，生成覆盖率测试结果。

可选的，上述处理器还可以执行如下步骤的程序代码：基于选择的待测应用，从测试设备拉取待测应用对应的覆盖率测试结果；将覆盖率测试结果进行超文本标记语言html转换，生成并输出覆盖率报告。

可选的，上述处理器还可以执行如下步骤的程序代码：获取与待测应用关联的目标用例；在接收到开始测试命令的情况下，记录开始时间并向测试设备发送测试命令，其中，由测试设备对目标用例所描述的场景进行测试，得到场景测试结果；在接收到结束测试命令的情况下，记录结束时间并从测试设备拉取场景测试结果；依据开始时间、结束时间及场景测试结果，更新目标用例的测试结果、执行对象及执行时间；从场景测试结果中解析出源代码文件列表；将源代码文件列表与目标用例进行关联。

可选的，上述处理器还可以执行如下步骤的程序代码：基于选择的待测应用，获取待测应用的用例；将待测应用的当前版本与上一版本进行对比，获取变更代码列表；查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中；从变更代码列表中移除用例关联的代码列表；判断变更代码列表中是否还包含文件；若不包含任何文件，根据第二用例列表中的用例创建测试计划。

可选的，上述处理器还可以执行如下步骤的程序代码：从测试设备获取新的覆盖率测试结果；解析新的覆盖率测试结果，生成第一对象；解析原覆盖率报告，生成第二对象；遍历第一对象，判断在第二对象中是否存在第一对象中的内容；若第二对象中存在第一对象中的内容，输出第一提示信息，第一提示信息用于指示覆盖率不变；若第二对象中不存在第一对象中的内容，输出第二提示信息，第二提示信息用于指示覆盖率增加。

可选的，上述处理器还可以执行如下步骤的程序代码：根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。

本领域普通技术人员可以理解，图20所示的结构仅为示意，计算机终端也可以是智能手机(如android手机、ios手机等)、平板电脑、掌声电脑以及移动互联网设备(mobileinternetdevices，mid)、pad等终端设备。图20其并不对上述电子装置的结构造成限定。例如，计算机终端a还可包括比图20中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图20所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(read-onlymemory，rom)、随机存取器(randomaccessmemory，ram)、磁盘或光盘等。

实施例10

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例所提供的覆盖率测试方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：获取待测应用的测试数据；根据测试数据，对待测应用进行插桩，得到插桩后的待测应用；将插桩后的待测应用发送至测试设备，其中，由测试设备对插桩后的待测应用进行覆盖率测试，得到待测应用的覆盖率测试结果。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：测试设备按照不同编程语言插桩的技术方式，对待测应用进行场景测试，生成覆盖率测试结果。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：基于选择的待测应用，从测试设备拉取待测应用对应的覆盖率测试结果；将覆盖率测试结果进行超文本标记语言html转换，生成并输出覆盖率报告。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：获取与待测应用关联的目标用例；在接收到开始测试命令的情况下，记录开始时间并向测试设备发送测试命令，其中，由测试设备对目标用例所描述的场景进行测试，得到场景测试结果；在接收到结束测试命令的情况下，记录结束时间并从测试设备拉取场景测试结果；依据开始时间、结束时间及场景测试结果，更新目标用例的测试结果、执行对象及执行时间；从场景测试结果中解析出源代码文件列表；将源代码文件列表与目标用例进行关联。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：基于选择的待测应用，获取待测应用的用例；将待测应用的当前版本与上一版本进行对比，获取变更代码列表；查询变更代码列表中的第一个文件关联的第一用例列表，将第一用例列表中的第一用例添加至第二用例列表中；从变更代码列表中移除用例关联的代码列表；判断变更代码列表中是否还包含文件；若不包含任何文件，根据第二用例列表中的用例创建测试计划。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：从测试设备获取新的覆盖率测试结果；解析新的覆盖率测试结果，生成第一对象；解析原覆盖率报告，生成第二对象；遍历第一对象，判断在第二对象中是否存在第一对象中的内容；若第二对象中存在第一对象中的内容，输出第一提示信息，第一提示信息用于指示覆盖率不变；若第二对象中不存在第一对象中的内容，输出第二提示信息，第二提示信息用于指示覆盖率增加。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：根据待测应用的覆盖率测试结果，对待测应用进行风险评估，得到风险评估结果，风险评估结果用于指示未覆盖到的代码文件以及代码文件中函数、分支代码或代码行。

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

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

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

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

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

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

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