覆盖率报告生成方法、装置、设备及存储介质

本发明涉及测试开发领域，尤其涉及一种覆盖率报告生成方法、装置、设备及存储介质。

代码覆盖(英语：Code coverage)是软件测试中的一种度量，描述程序中源代码被测试的比例和程度，所得比例称为代码覆盖率。代码覆盖率反映测试用例对被测软件覆盖程度的重要指标，是用来度量测试完整性的一个参考值，通过代码覆盖率数据可以评估测试是否充分。

现有的技术是使用jacoco等覆盖率工具收集测试覆盖率，得到的数据即为本次测试对于全量代码的覆盖情况，然而，在Android大型项目的落地方面，jacoco没有java服务端程序应用广泛。Jacoco官方只提供了gradle的基础插件用于插桩，只支持off-line模式，即依赖工程源码文件，编译后的字节码class文件以及覆盖率信息(运行时数据)生成报告，且Jacoco的gradle插件是对某个moudle代码的全量插桩，无法实现增量覆盖率统计，生成报告只提供API，没有实际Android应用实例，也没有成熟的流程。

本发明的主要目的在于解决现有的Android项目中只能Jacoco的gradle基的基础插件使用进行代码覆盖率的技术问题。

本发明第一方面提供了一种覆盖率报告生成方法，包括：获取自定义配置信息，根据所述自定义配置信息集成gradle插件；在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；将完成插桩操作的debug包对应的应用程序包安装至Android设备；当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

在本实施例中，在本发明第一方面的第一种实现方式中，所述在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包包括：在构建目标项目的debug包时，通过所述gradle插件进行插桩操作，生成插过桩的Class文件；对插过桩的Class文件进行编译打包，生成所述debug包对应的应用程序包。

在本实施例中，在本发明第一方面的第二种实现方式中，在所述在构建目标项目的debug包时，通过所述gradle插件进行插桩操作，生成插过桩的Class文件之前，还包括：获取预设的源文件和Class文件；在所述自定义信息中配置打开代码覆盖率开关。

在本实施例中，在本发明第一方面的第三种实现方式中，所述当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器包括：当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，生成代码覆盖率的日志信息；

对所述日志信息进行数据整合，生成含有代码覆盖率的ec文件；将所述ec文件上传至所述服务器。

在本实施例中，在本发明第一方面的第四种实现方式中，在所述将所述ec文件上传至所述服务器之后，还包括：将所述Class文件上传至所述服务器。在本实施例中，在本发明第一方面的第五种实现方式中，所述申请请求包括请求表单；所述当用户端在前端页面提交的申请请求时，根据所述申请请求从所述服务器中获取对应的代码执行信息，并生成对应的代码覆盖率报告包括：根据所述请求表单中的表单内容，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的代码覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的代码覆盖率报告。

在本实施例中，在本发明第一方面的第六种实现方式中，在所述根据所述请求表单中的表单内容，从所述服务器中获取对应的源文件、ec文件以及Class文件之后，还包括：从预设的gitlab中获取增量修改的源文件列表；根据所述请求表单中的表单内容和源文件列表，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的增量覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的增量覆盖率报告。

本发明第二方面提供了一种覆盖率报告生成装置，包括：插件集成模块，用于获取自定义配置信息，根据所述自定义配置信息集成gradle插件；插桩模块，用于在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；安装模块，用于将完成插桩操作的debug包对应的应用程序包安装至Android设备；记录模块，用于当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；全量报告生成模块，用于当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

在本实施例中，在本发明第二方面的第一种实现方式中，所述插桩模块具体用于：在构建目标项目的debug包时，通过所述gradle插件进行插桩操作，生成插过桩的Class文件；对插过桩的Class文件进行编译打包，生成所述debug包对应的应用程序包。

在本实施例中，在本发明第二方面的第二种实现方式中，所述覆盖率报告生成装置还包括预处理模块，所述预处理模块具体用于：在所述Class文件中添加预设的源文件；对所述gradle插件中配置打开代码覆盖率开关。

在本实施例中，在本发明第二方面的第三种实现方式中，所述记录模块具体用于：当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，生成代码覆盖率的日志信息；对所述日志信息进行数据整合，生成含有代码覆盖率的ec文件；将所述ec文件上传至所述服务器。

在本实施例中，在本发明第二方面的第四种实现方式中，所述覆盖率报告生成装置还包括Class文件上传模块，所述Class文件上传模块具体用于：将所述Class文件上传至所述服务器。

在本实施例中，在本发明第二方面的第五种实现方式中，所述全量报告生成模块具体用于：根据所述请求表单中的表单内容，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的代码覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的代码覆盖率报告。

在本实施例中，在本发明第二方面的第六种实现方式中，所述覆盖率报告生成装置还包括增量报告生成模块，所述增量报告生成模块具体用于：从预设的gitlab中获取增量修改的源文件列表；根据所述请求表单中的表单内容和源文件列表，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的增量覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的增量覆盖率报告。

本发明第三方面提供了一种覆盖率报告生成设备，包括：存储器和至少一个处理器，所述存储器中存储有指令，所述存储器和所述至少一个处理器通过线路互连；所述至少一个处理器调用所述存储器中的所述指令，以使得所述覆盖率报告生成设备执行上述的覆盖率报告生成方法的步骤。

本发明的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述的覆盖率报告生成方法的步骤。

本发明的技术方案中，获取自定义配置信息，根据所述自定义配置信息集成gradle插件；在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；将完成插桩操作的debug包对应的应用程序包安装至Android设备；当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

图1为本发明实施例中覆盖率报告生成方法的第一个实施例示意图；

图2为本发明实施例中覆盖率报告生成方法的第二个实施例示意图；

图3为本发明实施例中覆盖率报告生成方法的第三个实施例示意图；

图4为本发明实施例中覆盖率报告生成装置的一个实施例示意图；

图5为本发明实施例中覆盖率报告生成装置的另一个实施例示意图；

图6为本发明实施例中覆盖率报告生成设备的一个实施例示意图。

本申请实施例提供了一种覆盖率报告生成方法、装置、设备及存储介质，用于解决现有的在覆盖率报告生成过程中，仿真场景的全面和复杂性较低的技术问题。

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

为便于理解，下面对本发明实施例的具体流程进行描述，请参阅图1，本发明实施例中覆盖率报告生成方法的第一个实施例包括：

101、获取自定义配置信息，根据自定义配置信息集成gradle插件；

可以理解的是，本发明的执行主体可以为覆盖率报告生成装置，还可以是终端或者服务器，具体此处不做限定。本发明实施例以服务器为执行主体为例进行说明。

在实际应用中，jacoco提供了Maven和Gradle集成的插件适合在开发工具IDE中本地生成报告，而且配置class、src和ec文件的路径写完后是固定的，无法根据需要动态的决定需要收集覆盖率信息的类、模块，更无法远程实现报告预览和管理。而且这种方式在有多个module的项目中，需要在每个module中配置这样的任务，生成的报告分散存放在不同的模块，没有聚合报告，所以不方便查阅整个项目的覆盖率信息。

在本实施例中，通过实现插件接口，自定义gradle的插件，该插件可以传入自定义的配置，如是否开启覆盖率检测、服务器url地址、是否全量、增量、基准的分支名称(当前分支从哪个分支开出来，后面取差异改动要对比的分支)、限定要处理的包名、过滤的文件列表等信息，用于动态配置覆盖率报告的生成条件。在插件执行apply(Project Internalproject)方法时，获取是否开启覆盖率检测的开关，如果开启了，则动态注册几个task，如获取分支增量修改的task，文件上传的task，本地生成报告的task，自定义插桩的task、下载覆盖率ec文件的task等。

在本实施例中，在gradle配置时，往主工程的BuildConfig.java文件中写入自定义的配置信息：Jacoco启动的开关"IS_JACOCO_ENABLE"、当前分支名称"CURRENT_BRANCH_NAME"、当前提交点"CURRENT_COMMIT_ID"等，用于决定是否手机覆盖率信息，如果需要上传覆盖率，需要携带这些分支信息给后台服务器。

102、在构建目标项目的debug包时，通过gradle插件对目标项目的源码进行插桩操作，生成debug包对应的应用程序包；

在本实施例中，集成的gradle插件，可实现对指定包名的类插桩，在debug包构建过程中，插入探针，便于记录每行代码执行情况，Android应用编译时，，Jacoco初始化了一个Boolean类型的数组，用于记录每一个方法内部逻辑的执行情况，默认值是false表示没有执行，如果代码执行过，就会记录为true，这些探针会dump到本地文件保存下来。Android保存的覆盖率文件的拓展名为.ec文件，后续会上传到本覆盖率系统后台。

在本实施例中，在本实施例中，当对应用程序进行debug的编译时，就可以对应用程序进行离线的插桩，生成插桩后的应用程序包。也就是说，在引入该配置后，当对插过桩的Class文件进行编译时，就可以实现离线的插桩，从而生成插过桩的应用程序包。

103、将完成插桩操作的debug包对应的应用程序包安装至Android设备；

在本实施例中，将所述应用程序包文件安装到测试机中进行运行测试时，可进行手工测试或者Monkey自动化测试(Monkey测试是Android自动化测试的一种手段，通常是模拟用户的按键输入，触摸屏输入，手势输入等，看设备多长时间会出异常)，测试可用性强，适用范围广。

104、当Android设备运行debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将代码执行信息上传至服务器；

在本实施例中，安装对应的应用程序包，运行app，打开应用或者进入设置界面可dump覆盖率数据，保存到本地为.ec文件，然后上传.ec覆盖率文件到本系统对应的服务器。

105、当用户端在前端页面提交申请请求时，从服务器中获取申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

在本实施例中，后续前端页面根据条件提交生成报告请求，将同一个版本的.ec文件、src文件、class文件，进行分析处理，生成覆盖率报告。

在本实施例中，在前端页面和后端，其中，后端即为服务器，后端提供文件上传和下载服务，android客户端收集的覆盖率信息(.ec文件)，编译后上传的.src文件和.class文件，可以按应用名称、git提交点的commitId值等来命名文件目录，文件的保存路径的命名，依赖于后续前端提交表单的内容，需要一一对应，方便检索到对应的文件。

在本实施例中，前端展示报告的服务，是通过Node.js开启一个http-server服务，指定服务器某个文件路径，即可打开改路径下的静态页面。表单页面使用Vue+Webpack实现，与后端逻辑分离，页面只是用来收集生成报告所需的条件，并请求后端的接口，待后端生成报告后，返回报告相关的数据，web前端展示报告即可，前端页面包含覆盖率生成的条件表单编辑、提交功能，有已生成报告的在线预览、下载、管理界面，在前端页面上，可以选择对应的分支、两个提交点commitId，并勾选增量覆盖率，就可以通过使用gitlab的api，或者git diff命令，计算出两个提交点之间的diff文件列表，通过分支名和这些文件列表，去检索前面上传的.ec文件、src源码和class文件，从而针对这些增量修改的文件统计对应的覆盖率。如果不勾选增量覆盖率，就是统计所选分支项目代码的全量覆盖率，并生成对应的申请请求发送至后端，并接收后端返回的代码覆盖率信息并展示。

在本实施例中，通过获取自定义配置信息，根据所述自定义配置信息集成gradle插件；在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；将完成插桩操作的debug包对应的应用程序包安装至Android设备；当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

请参阅图2，本发明实施例中覆盖率报告生成方法的第二个实施例包括：

201、获取预设的源文件和Class文件；

在本实施例中，所述指定的源文件为gradle插件动态生成含有代码覆盖率信息的EC文件时，所需的相应源文件。

202、在自定义信息中配置打开代码覆盖率开关；

在本实施例中，获取是否开启覆盖率检测的开关，如果开启了，则动态注册几个task，如获取分支增量修改的task，文件上传的task，本地生成报告的task，自定义插桩的task、下载覆盖率ec文件的task等。

203、获取自定义配置信息，根据自定义配置信息集成gradle插件；

204、在构建目标项目的debug包时，通过gradle插件进行插桩操作，生成插过桩的Class文件；

205、对插过桩的Class文件进行编译打包，生成debug包对应的应用程序包；

206、将完成插桩操作的debug包对应的应用程序包安装至Android设备；

207、当Android设备运行debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将代码执行信息上传至服务器；

208、当用户端在前端页面提交申请请求时，从服务器中获取申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

本实施例在上一实施例的基础上，详细描述了在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包的过程，通过在构建目标项目的debug包时，通过所述gradle插件进行插桩操作，生成插过桩的Class文件；对插过桩的Class文件进行编译打包，生成所述debug包对应的应用程序包。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

请参阅图3，本发明实施例中覆盖率报告生成方法的第三个实施例包括：

301、获取自定义配置信息，根据自定义配置信息集成gradle插件；

302、在构建目标项目的debug包时，通过gradle插件进行插桩操作，生成插过桩的Class文件；

303、对插过桩的Class文件进行编译打包，生成debug包对应的应用程序包；

304、将完成插桩操作的debug包对应的应用程序包安装至Android设备；

305、当Android设备运行debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，生成代码覆盖率的日志信息；

306、对日志信息进行数据整合，生成含有代码覆盖率的ec文件；

307、将ec文件上传至服务器；

308、将Class文件上传至服务器；

在本实施例中，如果是全量报告，则遍历项目所有模块下的src目录(源码目录)，然后将所有src的根路径下的源码文件(.java或者.kt文件)，拷贝到指定目录(本方案存储在项目根目录同级的jacocoTemp目录中)，并压缩打包成zip文件：src.zip。如果是增量报告，则需要过滤掉不需要的源码，通过gitfdiff命名取出增量修改的文件，然后只需将增量修改过的源码拷贝到指定目录压缩并打包成src.zip文件。

在本实施例中，根据上面获取到的src文件列表，可以计算出项目编译后的class文件路径。因为java源码编译后的build文件夹里面生成的class文件的目录是固定的，src文件和.class字节码文件，路径是有既定的规则，可以将.java文件名改为.class文件，然后根据包名路径信息得到完整的字节码路径，即：项目根目录+模块名+build+java/kotlin字节码对应的目录。如源码所在的路径为："projectRootDir/appmodule/src/main/java/",那么.java源文件编译后的后的字节码文件，即.class文件的存储目录为"projectRootDir/appmodule/build/intermediates/javac/debug/classes",.kotlin文件编译后的路径为："projectRootDir/appmodule/build/tmp/kotlin-classes/debug"。遍历出所有的class文件后压缩成classes.zip，上传到服务器。

在本实施例中，上述步骤中生成的src.zip、classes.zip文件，是在gradle构建apk之后聚合并压缩的，压缩后开始上传到服务器，需要携带当前app名称、开发所在的分支名、当前分支最新的提交点、文件扩展名等信息作为文件上传的入参，用户服务器根据这些信息做差异化的存储管理。

309、当用户端在前端页面提交申请请求时，根据请求表单中的表单内容，从服务器中获取对应的源文件、ec文件以及Class文件；

310、根据预设的代码覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的代码覆盖率报告；

311、从预设的gitlab中获取增量修改的源文件列表；

312、根据请求表单中的表单内容和源文件列表，从服务器中获取对应的源文件、ec文件以及Class文件；

313、根据预设的增量覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的增量覆盖率报告。

在本实施例中，因为Android项目源码托管在gitlab，所以可通过gitlab的api获取增量修改的源码文件列表，生成报告时只处理增量修改的src和class文件。获取diff文件列表，需要传入一些参数：如两个对比的分支名称或者两个提交点hash值，from表示起始的提交点，to表示要对比差异的提交点，id为gitlab上面该项目的id，发送请求后，接口返回关于git提交的信息，其中包括文件修改后的路径，我们需要提取出这些修改的文件路径，然后去上传后的文件中过滤出我们想要的src、class文件，实现只针对修改的文件做report，通过gitlab的api就可以获取到两个提交点之间的diff文件,通过遍历获取newPath的值，接口获取到修改文件的相对路径，去src目录中检索即可获取到java或者kotlin的源码，去掉拓展名，换成.class即可匹配到class文件，ec文件则可以全部传入。ec文件如果跟源码或者class不匹配的覆盖率信息是不会被合并的，也就是会忽略而不会生成报告，通过diff的文本解析，可以解析出增量修改后的源码位置以及修改的内容。这样可以根据增量修改的信息，然后在生成报告时，进行源码内容匹配，标记出新增的代码，或者剔除掉不关注的信息。

本实施例在前实施例的基础上，详细描述了申请请求包括请求表单；所述当用户端在前端页面提交的申请请求时，根据所述申请请求从所述服务器中获取对应的代码执行信息，并生成对应的代码覆盖率报告的过程，通过根据所述请求表单中的表单内容，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的代码覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的代码覆盖率报告。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

上面对本发明实施例中覆盖率报告生成方法进行了描述，下面对本发明实施例中覆盖率报告生成装置进行描述，请参阅图4，本发明实施例中覆盖率报告生成装置一个实施例包括：

插件集成模块401，用于获取自定义配置信息，根据所述自定义配置信息集成gradle插件；

插桩模块402，用于在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；

安装模块403，用于将完成插桩操作的debug包对应的应用程序包安装至Android设备；

记录模块404，用于当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；

全量报告生成模块405，用于当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

本发明实施例中，所述覆盖率报告生成装置运行上述覆盖率报告生成方法，所述覆盖率报告生成装置通过获取自定义配置信息，根据所述自定义配置信息集成gradle插件；在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；将完成插桩操作的debug包对应的应用程序包安装至Android设备；当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

请参阅图5，本发明实施例中覆盖率报告生成装置的第二个实施例包括：

插件集成模块401，用于获取自定义配置信息，根据所述自定义配置信息集成gradle插件；

插桩模块402，用于在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；

安装模块403，用于将完成插桩操作的debug包对应的应用程序包安装至Android设备；

记录模块404，用于当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；

全量报告生成模块405，用于当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。

在本实施例中，在本发明第二方面的第一种实现方式中，所述插桩模块具体用于：在构建目标项目的debug包时，通过所述gradle插件进行插桩操作，生成插过桩的Class文件；对插过桩的Class文件进行编译打包，生成所述debug包对应的应用程序包。

在本实施例中，在本发明第二方面的第二种实现方式中，所述覆盖率报告生成装置还包括预处理模块406，所述预处理模块406具体用于：在所述Class文件中添加预设的源文件；对所述gradle插件中配置打开代码覆盖率开关。

在本实施例中，所述记录模块404具体用于：当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，生成代码覆盖率的日志信息；对所述日志信息进行数据整合，生成含有代码覆盖率的ec文件；将所述ec文件上传至所述服务器。

在本实施例中，所述覆盖率报告生成装置还包括Class文件上传模块407，所述Class文件上传模块407具体用于：将所述Class文件上传至所述服务器。

在本实施例中，所述全量报告生成模块405具体用于：根据所述请求表单中的表单内容，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的代码覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的代码覆盖率报告。

在本实施例中，所述覆盖率报告生成装置还包括增量报告生成模块408，所述增量报告生成模块408具体用于：从预设的gitlab中获取增量修改的源文件列表；根据所述请求表单中的表单内容和源文件列表，从所述服务器中获取对应的源文件、ec文件以及Class文件；根据预设的增量覆盖率函数，对服务器中获取对应的源文件、ec文件以及Class文件进行整合，生成对应的增量覆盖率报告。

本实施例在上一实施例的基础上，详细描述了各个模块的具体功能以及部分模块的单元构成，通过上述模块和单元构成获取自定义配置信息，根据所述自定义配置信息集成gradle插件；在构建目标项目的debug包时，通过所述gradle插件对目标项目的源码进行插桩操作，生成所述debug包对应的应用程序包；将完成插桩操作的debug包对应的应用程序包安装至Android设备；当所述Android设备运行所述debug包对应的应用程序时，根据插桩操作插入的探针记录代码执行信息，并将所述代码执行信息上传至服务器；当用户端在前端页面提交申请请求时，从所述服务器中获取所述申请请求对应的代码执行信息，并生成对应的代码覆盖率报告。本方法针对Gradle插件开发，用于自定义class、src路径，并上传文件，从而满足全量、增量覆盖率统计的需求。

上面图4和图5从模块化功能实体的角度对本发明实施例中的中覆盖率报告生成装置进行详细描述，下面从硬件处理的角度对本发明实施例中覆盖率报告生成设备进行详细描述。

图6是本发明实施例提供的一种覆盖率报告生成设备的结构示意图，该覆盖率报告生成设备600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，CPU)610(例如，一个或一个以上处理器)和存储器620，一个或一个以上存储应用程序633或数据632的存储介质630(例如一个或一个以上海量存储设备)。其中，存储器620和存储介质630可以是短暂存储或持久存储。存储在存储介质630的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对覆盖率报告生成设备600中的一系列指令操作。更进一步地，处理器610可以设置为与存储介质630通信，在覆盖率报告生成设备600上执行存储介质630中的一系列指令操作，以实现上述覆盖率报告生成方法的步骤。

覆盖率报告生成设备600还可以包括一个或一个以上电源640，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口660，和/或，一个或一个以上操作系统631，例如WindowsServe，MacOSX，Unix，Linux，FreeBSD等等。本领域技术人员可以理解，图6示出的覆盖率报告生成设备结构并不构成对本申请提供的覆盖率报告生成设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明还提供一种计算机可读存储介质，该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行所述覆盖率报告生成方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统或装置、单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。