一种测试处理方法、装置以及设备

技术领域

本说明书涉及测试技术领域，尤其涉及一种测试处理方法、装置以及设备。

背景技术

随着互联网技术的迅速发展和智能手机的使用普及，越来越多的应用涌现，更多的业务可以在线上进行。对于一些大中型应用而言，用户规模很大，也集成了越来越多的功能，在这种情况下，应用的研发迭代频繁，为了持续为用户提供可靠的服务，需要及时对应用进行测试。

目前，在应用迭代过程中，通常注重于对本次修改或增加的局部功能模块进行测试，而对于每次迭代后的应用的整体表现缺少了解，不容易及时发掘潜在的风险。

基于此，需要能够辅助测试更有效地进行的方案。

发明内容

本说明书一个或多个实施例提供一种测试处理方法、装置、设备以及存储介质，用以解决如下技术问题：需要能够辅助测试更有效地进行的方案。

为解决上述技术问题，本说明书一个或多个实施例是这样实现的：

本说明书一个或多个实施例提供的一种测试处理方法，包括：

获取待测试的目标源码；

对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

本说明书一个或多个实施例提供的一种测试处理装置，包括：

目标源码获取模块，获取待测试的目标源码；

探针插桩处理模块，对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

测试产物生成模块，根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

执行数据获取模块，接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

测试充分度确定模块，根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

本说明书一个或多个实施例提供的一种测试处理设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取待测试的目标源码；

对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

获取待测试的目标源码；

对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

本说明书一个或多个实施例采用的上述至少一个技术方案能够达到以下有益效果：能够在目标源码中大规模插桩探针得到测试产物包并注入上报脚本，在前端基于测试产物包进行测试的过程中，能够通过探针即时、高效且准确地采集到对应的前端代码运行情况，并及时上报后端，据此计算出对目标源码的测试充分度，通过测试充分度能够更全面地掌握对每次迭代后的应用的测试程度，进而更可靠地了解每次迭代后的应用的整体表现，并且根据需要对应用的局部功能模块的测试程度也能够充分了解，进而能够更有效地指导对应用的继续迭代研发或实际上线更新，有效降低了频繁迭代应用可能给业务带来的风险；不仅如此，还在插桩处理的相关过程中进行了代码文件体积缩减的优化处理，降低了前端负担。

附图说明

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

图1为本说明书一个或多个实施例提供的一种测试处理方法的流程示意图；

图2为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的插桩阶段的流程示意图；

图3为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的数据收集阶段的流程示意图；

图4为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的报告生成阶段的流程示意图；

图5为本说明书一个或多个实施例提供的一种缩减插桩相关文件体积的方案思路示意图；

图6为本说明书一个或多个实施例提供的方案优化前后的效果比对示意图；

图7为本说明书一个或多个实施例提供的一种测试处理装置的结构示意图；

图8为本说明书一个或多个实施例提供的一种测试处理设备的结构示意图。

具体实施方式

本说明书实施例提供一种测试处理方法、装置、设备以及存储介质。

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

应用前端面向用户，通过用户交互，在后端的支持下为用户提供在线服务。目前，伴随着前端业务快速迭代，质量保障成为重中之重，也为测试工作提出了更高的要求，一些由于漏测、提测质量不足等情况，会很大影响业务的迭代效率与质量。因此，本申请考虑将自测、验收尽可能量化，以主动有效地挖掘漏测和测试强度不足的风险，主要思路包括：基于大规模进行前端代码插桩探针，以及运行时上报探针结果，据此来量化测试充分度；不仅如此，还注意到插桩后文件体积暴涨的问题，因此还做了进一步地优化，来缩减插桩后文件体积。

下面基于这样的思路，继续详细说明本申请的方案。

图1为本说明书一个或多个实施例提供的一种测试处理方法的流程示意图。该流程可以应用后端(比如，应用服务器、测试服务器、风控服务器等)上执行，也可以由应用前端(比如，测试人员或实际用户的智能手机、平板电脑、智能手表等设备上运行的应用客户端、基于H5页面的浏览器、模拟器等)来支持和辅助部分步骤的详细实现。该方法可以应用于不同的业务领域中，来辅助对这些领域中所用到的应用的测试、开发或运营，这些领域比如包括：电子支付业务领域、电商业务领域、社交业务领域、游戏业务领域、公务业务领域等。

图1中的流程包括以下步骤：

S102：获取待测试的目标源码。

在本说明书一个或多个实施例中，目标源码比如是用于用于构建应用安装包、更新包或插件的代码，也可以是脚本等无需编译的解释性代码。在应用需要进行大小版本更新、新增插件等情况下，能够相应获取到新的目标源码，可能是对已有代码的修改，也可能是额外新增的代码。

S104：对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置。

在本说明书一个或多个实施例中，探针指：能够向其他代码中插入的一段执行特殊操作(比如，对执行次数或执行时间等指标计数、捕获运行时错误信息、记录日志信息等)的指令，用于记录对应代码行(简称为探针监测的代码)的执行情况；插桩指向目标源码中插入一个或多个探针，以便运行时统计代码行的执行情况。

在进行插桩处理时，针对所关注的很多代码分别插入探针，尤其是诸如涉及主要功能逻辑、重要条件分支等代码行或代码块，位置比如通过代码行号、代码中的定位符号等标识确定。

在本说明书一个或多个实施例中，在目标源码中插入的探针是大规模的，由此可能显著地影响插桩后文件的体积，本申请也重点关注这种情况下的体积优化，由此，对于探针的内容构造、部署方式和上报方式进行了相应优化。

S106：根据上报脚本和所述插桩处理后的目标源码，生成测试产物包。

在本说明书一个或多个实施例中，插桩的探针负责在代码执行时记录，而上报脚本则负责收集大规模的探针所记录的数据，并有能力在运行时上报，从而能够得到实时的全局代码执行情况。

将上报脚本、探针和目标源码进行了集成，生成可直接运行或需安装运行的测试产物包，前一种情况比如是为浏览器更新的前端脚本，后一种情况比如是应用的安装包或更新包。

在本说明书一个或多个实施例中，在生成测试产物包后，可以将测试产物包下发至前端使用。可以预先将多个前端划分集合，在插桩处理时，在目标源码中分别进行侧重于不同区域的局部插桩，相应得到多份不同的插桩后的源码，生成对应的测试产物包，向不同的前端集合发放，从而，能够加快全局效率。

进一步地，选择真实的大规模的线上用户的前端，作为测试产物包的待下发前端。根据预先采集的这些线上用户在应用内的操作习惯，划分这些用户的前端，使得触发应用同一个功能部分相对多的线上用户的前端被划分在同一个集合中，相应地，为该集合对应的该功能部分重点插桩探针并生成对应的测试产物包，将该测试产物包仅下发给对应的集合中的各前端。如此，有助于探针更全面地执行，有效地降低了全局的探针插桩量，并且尽量减少了对用户的打扰，又充分地利用了线上真实用户的测试能力。

S108：接收前端通过运行所述测试产物包，收集并上报的探针执行数据。

在本说明书一个或多个实施例中，对于需安装运行的测试产物包，前端安装后运行使用，对于可直接运行的测试产物包，则可以直接注入现有逻辑中运行或独立运行。

对于探针，其监测了一定范围的代码(比如，对应的某个代码行)，若在测试产物包运行的过程中，并未涉及该范围内的代码的运行，则未能触发探针有效地执行，则探针实质上未能收集到有效的代码运行情况，为了便于描述，在前端运行测试产物包的过程中，对于所监测的代码已经执行过的探针，称为已执行探针，反之则称为未执行探针。

探针执行数据则表明了对应的探针是否已执行，若有需要，还可以进一步地在探针执行数据中记录探针的执行次数、执行时间等更详细的信息，尤其是执行次数，由于代码的执行有基本环境和业务场景的配合，则对同一代码反复执行有助于暴露出测试时发生条件相对严格、不太容易复现的问题。

S110：根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

在本说明书一个或多个实施例中，对于测试人员而言，要测试目标源码则需要执行目标源码(比如，通过断点调试、黑盒测试等)，因此，探针执行数据能够反映出哪些代码很可能是为了测试而运行过的，尤其是在前端的使用者明确为测试人员的情况下。也即，可以认为若代码在前端运行过，则可能在该前端测试过，而若代码未在前端运行过，则在该前端未测试过。

在探针在目标源码中部署的范围足够充分的情况下，根据探针执行数据，能够确定目标源码中已执行代码的覆盖率，根据已执行代码的覆盖率来推断已测试代码的覆盖率，比如，可以近似地认为两者基本一致。根据已测试代码的覆盖率确定对所述目标源码的测试充分度，比如，可以基于覆盖率进一步考虑执行次数是否足够多，考虑局部代码执行的连贯性是否足够好、非常规的业务逻辑跳转的占比是否足够高等等。

以上一段列举的最后一种考虑因素为例。对于研发人员(主要包括本公司的开发、测试和产品人员)而言，在设计应用的功能和业务(统称为环节)的过程中，会主要考虑对该应用典型的操作模式，比如，在进入某个环节(比如，订单确认)后，接下来应该会进入某个环节(订单支付)，之后再会进入某个环节(回到主页或订单详情)，等等，从而会重点保证这样的典型操作模式的正常进行而不发生异常。但是，在实际应用中，一些用户未必会按照研发人员预想的那样操作，而异常往往就发生在这些用户的非典型操作过程中。

基于此，预先设计尽量多的典型操作模式，实现于多块局部代码的预定执行链。根据探针执行数据，从全局层面上分析确定同一个前端上的代码的实际执行链，将实际执行链在各预定执行链中进行匹配，确定未匹配成功的实际执行链，计算未匹配成功的实际执行链中包含的代码在目标源码中的覆盖率，该覆盖率越高越好，再根据该覆盖率确定对目标源码的测试充分度。如此，能够有效挖掘测试盲点，得到更可靠的测试充分度。

在本说明书一个或多个实施例中，若测试充分度足够，且已解决了比较致命的异常，则可以将本次迭代得到的应用版本上线使用，反之，可以继续对该应用版本继续测试。

通过图1的方法，能够在目标源码中大规模插桩探针得到测试产物包并注入上报脚本，在前端基于测试产物包进行测试的过程中，能够通过探针即时、高效且准确地采集到对应的前端代码运行情况，并及时上报后端，据此计算出对目标源码的测试充分度，通过测试充分度能够更全面地掌握对每次迭代后的应用的测试程度，进而更可靠地了解每次迭代后的应用的整体表现，并且根据需要对应用的局部功能模块的测试程度也能够充分了解，进而能够更有效地指导对应用的继续迭代研发或实际上线更新，有效降低了频繁迭代应用可能给业务带来的风险；不仅如此，还在插桩处理的相关过程中进行了代码文件体积缩减的优化处理，降低了前端负担。

基于图1的方法，本说明书还提供了该方法的一些具体实施方案和扩展方案，下面继续进行说明。

在一种具体实施方案中，将上述方法涉及的过程划分为三个阶段。包括：在后端执行的插桩阶段、在前端执行的数据收集阶段、在后端执行的报告生成阶段。

图2为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的插桩阶段的流程示意图。

对于图2，在生成测试产物包的过程中，根据插桩处理后的目标源码(目标文件)，进行构建和上报脚本注入，以得到稳定性较好、便于使用的一体化产物，假定基于执行覆盖率来确定测试充分度，则可以直观地将该一体化产物称为覆盖率版产物。

更具体地，可以利用插桩工具对目标源码插入多个探针，根据插桩处理后的目标源码，构建应用安装包，并在构建的过程中注入上报脚本，将构建出的注入了上报脚本的应用安装包，作为测试产物包，以便前端安装运行。在插桩过程中，还可以生成相应的独立映射文件，以便降低被插桩对象上增加的体积，后面具体说明。

另外，也可以在构建的同时完成插桩处理，不过这种方式，可能需要做额外的兼容处理。

图3为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的数据收集阶段的流程示意图。

对于图3，在前端上使用该覆盖率版产物，比如，具体为某个应用(APP)的客户端、或模拟器或浏览器。以应用为例，则相应的应用启动后，运行时收集探针执行数据。为了降低负担，采用增量的方式实时向后端上报，并且，上报时不需要关注过多冗余的文件信息，可以只上报探针及对应的执行次数，从而大大减少了上报报文。

图4为本说明书一个或多个实施例提供的图1的方案的一种实施方案包含的报告生成阶段的流程示意图。

在本说明书一个或多个实施例中，对上报得到的各探针执行数据进行合并计算(比如，根据所对应的代码版本号、代码提交标识进行合并)，生成探针执行全局数据，根据探针执行全局数据，确定已执行探针数量，根据已执行探针数量和插入已执行探针数量的探针总数量，确定对目标源码的测试充分度。在不考虑权重差异的情况，比如，将已执行探针数量与探针总数量的比值确定为覆盖率，再据此确定测试充分度。

对于图4，智能地生成报告以供测试人员使用。具体比如，获取预先转存的当前版本的目标源码，根据当前版本的目标源码和所述探针执行全局数据，自动生成反映测试充分度的代码执行整体覆盖率报告和/或变更代码执行覆盖率报告等。

需要说明的是，本申请的方案支持进行变更计算，从而能够在多次迭代应用版本时高效获取局部的测试充分度或测试充分度相应的提升程度。具体地，确定目标源码相对于指定版本的变更代码部分(比如，通过diff指令计算)，确定与变更代码部分匹配成功的探针执行数据(比如，根据代码版本号、变更代码部分对应的各代码提交标识，以及探针标识进行匹配)，根据匹配成功的探针执行数据，确定对目标源码中的所述变更代码部分的测试充分度。

在本说明书一个或多个实施例，申请人基于插桩收集探针的思路，采用了多种具体实施方案，在初始尝试的方案中，发现有一个值得注意和优化的问题，即插桩处理后的代码，相比于原来的目标源码体积会明显增长，尤其是在探针数量大规模的情况下，可能会引发代码体积暴涨。虽然可以通过压缩代码文件的方式，暂时性地降低代码文件体积，但是，在前端还会解压运行，仍然会给前端带来压力，因此，申请人对初始尝试的方案进行了优化，在优化后，平均插桩体积缩小5倍，可以作为参考。下面对体积优化的方案部分继续详细说明。

图5为本说明书一个或多个实施例提供的一种缩减插桩相关文件体积的方案思路示意图。

在图5中，进行体积优化的主要思路包括：生成独立的映射文件配合后端运行时映射使用，将代码文件中探针的描述信息简化，从而能够直接降低插桩代码量；将探针标识以全代码包文件的方式递增记录而非单文件递增记录，进而能够将收集探针的上报脚本逻辑，简化为仅需传入极少的探针信息即可，从而能够缩小上报脚本，而且探针本身的字符长度也将减少。

对于生成映射文件方面，具体地，在对目标源码进行插桩处理时，可以确定用于完整定义探针的探针定义数据；从探针定义数据中提取出至少部分探针描述信息，根据剩余的数据确定待插入的探针；根据至少部分探针描述信息，生成独立映射文件并保存在本地；将多个待插入的探针插入目标源码中对应的指定位置，以便前端在运行测试产物包时，通过调用独立映射文件使用探针。

例如，将coveragData中单文件的诸如statementMap、branchMap、fnMap、path、hash、s、f、b等数据，从生成的代码文件中提取出来，产出到reflect.json文件中，reflect.json文件不下发至前端，而是保存于后端，有前端在使用探针时，若需要用到时通过反射等方式调用，从而有效缩减了实际插桩至前端的代码量。

在简化探针描述方面，具体地，在确定用于完整定义探针的探针定义数据之后，在探针定义数据中确定多种类型的探针描述信息，在多种类型中确定简化类型，并在将探针描述信息中，属于简化类型以外的类型的探针描述信息，转换为简化类型的探针描述信息，以替代转换前的对应的探针描述信息使用。进一步地，在转换为简化类型的探针描述信息之后，可以将至少部分简化类型的探针描述信息划分在上述的剩余的数据内，则这部分数据会到达前端，相比于简化前降低了到达前端的数据量。

例如，将statement确定为简化类型，将statement、branch、function等一些描述信息都转换为statement的形式来描述，进而在前端均采用简化后的branch、function。

在缩小上报脚本方面，具体地，采用了探针标识全文件自增的方式，替代了优化前的单文件自增的方式，比如，单文件自增时，每个文件都要分别维护所插入的探针标识，则要维护多份诸如1～10...等顺序的标识，而全文件自增，只需要整体维护一份。在实际应用中，插入探针的代码文件数量很多，每个文件中可能又会有上百个探针。在这种情况下，采用全文件自增，后续收集和上报探针时，无需再上报大量文件的标识或路径，能做做到尽量简化的上报。在生成测试产物包，确定为多个探针定义的探针类型和全局自增的对应的探针标识，生成以探针类型和探针类型为传入参数的探针简化收集逻辑，作为至少部分上报脚本，将探针简化收集逻辑进行插入安排处理，以直接插入或运行时动态插入(这种方式可以在前端运行时再执行)插桩处理后的目标源码中的指定的全局对象中，根据插入安排处理后的全局对象，生成测试产物包。

例如，将收集探针的脚本逻辑，简化为仅需传入探针标识及类型即可，因此，从而能够将插入到全局对象中的收集脚本约缩小为原来的一半，探针字符长度也相应减少。

更直观地，参见，图6为本说明书一个或多个实施例提供的方案优化前后的效果比对示意图。

在图6中，示例性地采用了一部分代码文件(比如，某个页面ts文件)，优化前后的体积对比很明显，从85KB缩小到14KB。

在探针插入计数方式方面，用于对探针标识递增计数，从优化前的单文件自增优化为全文件自增。

在单个探针长度方面，增加了add_${hash}方法来接管探针数累加，在给出的探针示例中，优化后缩短了若干个字符。

在探针执行数据上报方面，优化后可以只做变更上报，而且由于使用了全文件自增因此无需上报标记文件信息，可以只上报有变化的探针及覆盖次数(比如，执行次数)。

由此可见，基于上面的这些优化，能够有效地缩减插桩相关文件体积，既有助于降低前端压力，也有助于后端更高效及时地获取探针执行数据。

基于同样的思路，本说明书一个或多个实施例还提供了上述方法对应的装置和设备，如图7、图8所示。装置和设备能够相应执行上述方法及相关的可选方案。

图7为本说明书一个或多个实施例提供的一种测试处理装置的结构示意图，所述装置包括：

目标源码获取模块702，获取待测试的目标源码；

探针插桩处理模块704，对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

测试产物生成模块706，根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

执行数据获取模块708，接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

测试充分度确定模块710，根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

可选地，所述测试产物生成模块706，根据所述插桩处理后的目标源码，构建应用安装包，并在所述构建的过程中注入所述上报脚本；

将所述构建出的注入了所述上报脚本的应用安装包，作为测试产物包，以便所述前端安装运行。

可选地，所述探针插桩处理模块704，确定用于完整定义探针的探针定义数据；

从所述探针定义数据中提取出至少部分探针描述信息，根据剩余的数据确定待插入的探针；

根据所述至少部分探针描述信息，生成独立映射文件并保存在本地；

将多个所述待插入的探针插入所述目标源码中对应的指定位置，以便所述前端在运行所述测试产物包时，通过调用所述独立映射文件使用所述探针。

可选地，所述探针插桩处理模块704，在所述确定用于完整定义探针的探针定义数据之后，在所述探针定义数据中确定多种类型的探针描述信息；

在所述多种类型中确定简化类型，并在将所述探针描述信息中，属于所述简化类型以外的类型的探针描述信息，转换为所述简化类型的探针描述信息，以替代转换前的对应的探针描述信息使用。

可选地，所述探针插桩处理模块704，在所述转换为所述简化类型的探针描述信息之后，将至少部分所述简化类型的探针描述信息划分在所述剩余的数据内。

可选地，所述测试产物生成模块706，确定为所述多个探针定义的探针类型和全局自增的对应的探针标识；

生成以所述所述探针类型和所述探针类型为传入参数的探针简化收集逻辑，作为至少部分上报脚本；

将所述探针简化收集逻辑进行插入安排处理，以直接插入或运行时动态插入所述所述插桩处理后的目标源码中的指定的全局对象中；

根据所述插入后的全局对象，生成测试产物包。

可选地，所述测试充分度确定模块710，根据所述探针执行数据，确定同一个所述前端上的代码的实际执行链；

将所述实际执行链在各预定执行链中进行匹配，所述预定执行链是根据预先设计的典型操作模式实现的；

计算未匹配成功的实际执行链中包含的代码在所述目标源码中的覆盖率；

根据所述覆盖率确定对所述目标源码的测试充分度。

可选地，所述测试充分度确定模块710，确定所述目标源码相对于指定版本的变更代码部分；

确定与所述变更代码部分匹配成功的探针执行数据；

根据所述匹配成功的探针执行数据，确定对所述目标源码中的所述变更代码部分的测试充分度。

可选地，所述测试充分度确定模块710，对上报得到的各探针执行数据进行合并计算，生成探针执行全局数据；

根据所述探针执行全局数据，确定已执行探针数量；

根据所述已执行探针数量和插入所述已执行探针数量的探针总数量，确定对所述目标源码的测试充分度。

可选地，所述测试充分度确定模块710，获取预先转存的当前版本的目标源码；

根据所述当前版本的目标源码和所述探针执行全局数据，自动生成反映测试充分度的代码执行整体覆盖率报告和变更代码执行覆盖率报告。

图8为本说明书一个或多个实施例提供的一种测试处理设备的结构示意图，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取待测试的目标源码；

对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

基于同样的思路，本说明书一个或多个实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

获取待测试的目标源码；

对所述目标源码进行插桩处理，以将多个探针插入所述目标源码中对应的指定位置；

根据上报脚本和所述插桩处理后的目标源码，生成测试产物包；

接收前端通过运行所述测试产物包，收集并上报的探针执行数据；

根据所述探针执行数据，确定对所述目标源码的测试充分度，以便根据所述测试充分度使用所述目标源码。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。