CN108415821A - 测试报告的生成方法及装置 - Google Patents

Abstract

本发明公开了一种测试报告的生成方法及装置。其中，该方法包括：对目标文件进行插桩操作，得到插桩后的文件，其中，目标文件通过对待测试应用的源代码进行编译得到；对插桩后的文件进行打包操作，得到待测试应用的安装包，其中，安装包中包括插桩后的类文件，插桩后的类文件用于指示源代码中需要被测试到的代码；对安装包进行测试，生成测试指示文件，其中，测试指示文件用于指示在进行测试的过程中源代码中被实际测试到的代码；至少根据测试指示文件和插桩后的类文件生成测试报告，其中，测试报告至少用于指示需要被测试到的代码与被实际测试到的代码之间的比对关系。本发明解决了相关技术中测试覆盖率收集效率低的技术问题。

Description

测试报告的生成方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种测试报告的生成方法及装置。

背景技术

现有测试覆盖率收集方法(例如，对安卓***进行测试)主要有Emma、cobertura、JaCoCo等。目前，大部分对测试覆盖率进行收集的技术方案只是实现了通过手动测试执行收集到测试覆盖率，测试覆盖率的收集效率较低。另一方面，现有技术方案主要为全量覆盖率的收集，生成的覆盖率报告主要为全量覆盖率，无法进行只包含改动代码的差异覆盖率分析。当需要分析某部分改动代码的覆盖率时，不能高效地进行分析，分析效率较低。例如，基于emma收集覆盖率，无法进行分支覆盖率分析，分析不全面。

针对相关技术中的测试覆盖率收集效率低的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种测试报告的生成方法及装置，以至少解决相关技术中测试覆盖率收集效率低的技术问题。

根据本发明实施例的一个方面，提供了一种测试报告的生成方法，包括：对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

根据本发明实施例的另一方面，还提供了一种测试报告的生成装置，包括：插桩模块，用于对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；打包模块，用于对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；测试模块，用于对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；生成模块，用于至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

在本发明实施例中，采用对待测试应用的源代码进行编译得到的目标文件进行插桩操作，并对插桩后得到的文件进行打包，得到待测试应用的安装包；对得到的安装包进行测试，生成测试指示文件，并根据生成的测试指示文件以及插桩后的类文件，生成测试报告的方式，通过对待测试应用的源代码进行编译后得到的目标文件进行插桩，可以根据需要选择需要插桩的目标文件，达到了有针对性测试的目的，从而实现了提高测试覆盖率分析效率的技术效果，进而解决了相关技术中测试覆盖率收集效率低的技术问题。

附图说明

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

图1是根据本发明实施例的一种测试报告的生成方法的应用环境示意图；

图2是根据本发明实施例的一种可选的测试报告的生成方法的流程图；

图3是根据本发明实施例的一种可选的测试报告的生成装置的示意图；

图4是根据本发明实施例的另一种可选的测试报告的生成方法的流程图；

图5是根据本发明实施例的一种可选的Jar包的示意图；

图6是根据本发明实施例的一种可选的通过Jenkins配置参数的示意图；

图7是根据本发明实施例的一种可选的生成的apk包和class文件的示意图；

图8(a)是根据本发明实施例的一种可选的在Jenkins配置svn地址的示意图；

图8(b)是根据本发明实施例的一种可选的在Jenkins配置用户名的示意图；

图9是根据本发明实施例的一种可选的配置构建描述的示意图；

图10是根据本发明实施例的一种可选的配置项目ID和创建精准入库任务的示意图；

图11是根据本发明实施例的一种可选的检验代码的脚本的示意图；

图12是根据本发明实施例的一种可选的编写的用于实现插桩的命令的示意图；

图13是根据本发明实施例的一种可选的编译打包的示意图；

图14是根据本发明实施例的一种可选的用于备份class的命令的示意图；

图15是根据本发明实施例的一种可选的保存存档文件的示意图；

图16是根据本发明实施例的一种可选的代码覆盖率生成工具的示意图；

图17是根据本发明实施例的一种可选的用于生成覆盖率报告的文件的示意图；

图18是根据本发明实施例的一种可选的修改后的build_property文件的示意图；

图19是根据本发明实施例的一种可选的生成的覆盖率报告的示意图；

图20是根据本发明实施例的一种可选的用于体现测试覆盖率情况的代码的示意图；

图21是根据本发明实施例的一种可选的测试报告生成设备的示意图。

具体实施方式

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

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

实施例1

在本发明实施例中，提供了一种上述测试报告的生成方法的实施例。作为一种可选的实施方式，该测试报告的生成方法可以但不限于应用于如图1所示的应用环境中，用于生成测试报告的设备102可以通过网络104与远端服务器106建立连接，并通过网络104调用远端服务器106的接口。上述应用场景仅是一种示例，本实施例中对此不做任何限定。

可选地，在本实施例中，上述用于生成测试报告的设备可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑及其他移动硬件设备。上述远端服务器可以包括但不限于以下至少之一：平板电脑、笔记本电脑、PC机等。可选地，在本实施例中，上述网络可以包括但不限于：有线网络，如广域网、城域网、局域网。上述仅是一种示例，本实施例中对此不做任何限定。

根据本发明实施例，提供了一种测试报告的生成方法，如图2所示，该方法包括：

步骤S202，对目标文件进行插桩操作，得到插桩后的文件，其中，上述目标文件通过对待测试应用的源代码进行编译得到；

步骤S204，对插桩后的文件进行打包操作，得到待测试应用的安装包，其中，上述安装包中包括插桩后的类文件，插桩后的类文件用于指示源代码中需要被测试到的代码；

步骤S206，对上述安装包进行测试，生成测试指示文件，其中，上述测试指示文件用于指示在进行测试的过程中源代码中被实际测试到的代码；

步骤S208，至少根据测试指示文件和插桩后的类文件生成测试报告，其中，上述测试报告至少用于指示需要被测试到的代码与被实际测试到的代码之间的比对关系。

可选地，在本实施例中，上述测试报告的生成方法可以但不限于应用于客户端获取代码测试覆盖率的场景中，如客户端使用JaCoCo结合测试项目获取android测试覆盖率的场景中，其中，代码测试覆盖率是指测试代码的执行过程中，被实际测试到的代码占需要被测试到的代码的比例。其中，上述客户端可以但不限于运行Android操作***。上述仅是一种示例，本实施例中对此不做任何限定。

具体地，在本实施例中，通过对待测试应用的源代码进行编译后得到的目标文件进行插桩，可以根据需要选择需要插桩的目标文件，从而实现针对性的插桩及测试，以克服相关技术中测试覆盖率收集效率低的技术问题，实现提高测试覆盖率分析效率的效果。

可选地，在本实施例中，上述目标文件可以包括但不限于对待测试应用的源代码进行编译得到的类文件的全部或者部分。在对待测试应用的源代码进行编译后，得到包括多个类文件(例如，500个、1000个等，根据待测试的应用不同，生成的类文件的数据也是不同的)；根据测试任务从得到的多个类文件中选择一个或多个类文件作为目标文件进行插桩操作。对目标文件进行插桩操作，也就是有选择的对编译后的待测试应用的源代码进行插桩。

作为一种可选的实施方式，在进行插桩时，客户端需要获知插桩前的类文件的正确位置，可以通过插桩前的类文件的位置信息参数进行确定。在获取到插桩前的类文件的位置后，可以通过调用用于对目标文件进行插桩的第一接口函数，对插桩前的类文件执行插桩操作，得到插桩后的类文件。第一接口函数可以将注入代码***到插桩前的类文件中。通过调用接口函数的方式对插桩前的类文件进行插桩操作，可以利用已有的接口函数对目标文件进行插桩，降低对客户端的性能要求，提高客户端对目标文件插桩的效率。

可以通过注入代码检测源代码中需要被测试到的代码是否被实际测试到，例如，如果需要被测试到的代码1实际被测试到，则将代码1对应的注入代码进行置位等修改操作，如果需要被测试到的代码2未被实际测试到，则不对代码2对应的注入代码进行修改(反之亦然，即，实际被测试到代码对应的注入代码不进行修改，未被实际测试到代码对应的注入代码进行修改)。通过注入代码的变化情况，即可反映需要被测试到的代码是否被实际测试到。上述仅为注入代码的示例，本实施例中对此不做任何限定。

可选地，在本实施例中，第一接口函数可以由已有的工程包提供。例如，在获取插桩前的类文件的位置以后，可以通过如下代码进行插桩操作：

<JaCoCo:instrument destdir＝"${classes_instr}">

<fileset dir＝"${classes}"includes＝"**/*.class"/>

</JaCoCo:instrument>

这里调用的第一接口函数为JaCoCo工程包提供的插桩函数，该工具包可以在对应的官网上进行下载，具体地第一接口函数的调用方式可以参考相关技术中。当然，这里的第一接口函数并不限于JaCoCo工程包提供的插桩函数，对于其他接口函数，只要具备执行根据插桩前文件的位置对目标文件进行插桩的功能，均可实现上述插桩操作。

作为另一种可选的实施方式，在进行插桩时，客户端可以直接获取插桩前的类文件的内容，例如，通过窗口获取，然后直接对获取的插桩前的类文件执行插桩操作。上述方式，需要客户端具备可以对插桩前的类文件的内容进行插桩的功能，对于客户端的性能要求较高。

可选地，在本实施例中，在对插桩后的文件进行打包操作之前，可以在打包相关的参数配置完成后(例如，通过Jenkins进行参数配置)，进行构建打包，得到待测试应用的安装包。打包得到的安装包可以为安卓安装包(Android Package，简称为apk包)，安装包中可以包括插桩后的类文件。在构建打包完成后，除了得到测试应用的安装包外，还可以保存有原来的类文件(可以包括插桩前的类文件以及不需要插桩的类文件)，以便于后续生成测试报告时使用。

上述Jenkins是基于Java开发的一种持续集成工具，用于监控及任务化运行持续重复的工作，功能包括：持续的软件版本发布/测试项目；监控外部调用执行的工作。

可选地，在得到待测试应用的安装包后，在对安装包进行测试前，可以通过调用第三接口函数清楚内存中的测试指示数据。这样，在对得到的安装包执行测试前，可以把以前遗留的测试指示数据清除掉，保证每次生成的测试指示文件都是当前测试的执行结果，避免了内存中已有的数据对测试结果的影响。

可选地，在本实施例中，得到待测试应用的安装包后，可以基于得到的安装包进行测试。作为一种可选的实施方式，对安装包的测试可以是在客户端本地进行的，在进行测试的过程中，源代码中被实际测试到的代码可以通过内存中的测试指示数据显示。可以根据插桩信息确定测试指示数据中对应于插桩后的类文件的部分。可以采用多种方式获取内存中的测试指示数据，例如，可以通过调用第二接口函数获取内存中的测试指示数据，也可以通过定义相应的获取函数进行测试指示数据的获取，还可以通过其他可以获取内存数据的方式，进行测试指示数据的获取。获取测试指示数据后，生成包含测试指示数据的测试指示文件，可以获得插桩后的类文件执行情况。作为另一种可选的实施方式，可以在能够进行安装包测试的网站上进行安装包的在线测试，由网站直接提供测试指示文件。

与在线测试获取测试指示文件相比，通过调用第二接口函数获取内存中的测试指示数据，生成测试指示文件，测试指示数据的获取时间更加灵活，可以离线进行测试指示文件的生成，减小测试指示文件的生成对网络的依赖性。

可选地，在本实施例中，在得到的安装包进行测试时，可以采用两种方式生成测试指示数据：一种通过专门用来生成测试指示数据的安装包，这种方式一般用于手工测试生成，通过手工测试生成测试指示数据；另一种是通过定时器的方式，在得到的安装包中新建一个定时器任务，定时收集生成的测试指示数据。

可选地，在本实施例中，生成的测试指示文件，可以是差异覆盖率的测试指示文件，也可以是全量覆盖率的测试指示文件。测试完成后，根据覆盖率结果衡量测试覆盖程度，主要分为两种：

(1)差异覆盖率：改动点的代码执行覆盖率情况；

(2)全量覆盖率：本次测试代码执行全部覆盖率情况。

差异覆盖率主要是根据开发代码变更的差异，得出改动代码的范围，生成的类文件只包含改动部分。这样，在分析得到覆盖率报告(即，前述测试指示报告)时，生成的报告文件就只包含差异部分，然后根据这个范围有针对性的只生成这部分改动的代码覆盖率结果。通过覆盖率结果反向衡量测试的充分性，更好的和精准评估的测试范围去做比较。

全量覆盖率，即全部代码的覆盖率结果，是把所有代码对应的类文件一起分析生成覆盖率文件(即，前述测试指示报告)。在对生成的全量覆盖率文件进行分析时，不一定要全部去分析，可以只需要关注测试功能所覆盖的那部分功能代码。

使用哪种覆盖率是由测试阶段的内容决定，比如，上线前测试、回归测试等，主要关注的是改动点的变化，使用差异覆盖率效果比较理想；如果是新增功能的测试，使用全量覆盖率效果比较理想。

可选地，在本实施例中，源代码中需要被测试到的代码可以包括多种，例如，源代码从修改前到修改后所改变的代码。也即，源代码中修改后的代码增加或者发生变化的代码。例如，源代码中相对于修改前新增加的一段函数代码，或者，源代码中相对于修改前被更改的一段函数代码。又例如，源代码中需要被测试到的代码可以包括某段关键代码或者指定代码。源代码中需要被测试到的代码包括源代码从修改前到修改后所改变的代码，可以实现对源代码中的改动代码的测试覆盖率分析，实现有针对性的测试。

可选地，在本实施例中，生成的测试指示文件可以包括插桩后的类文件的运行结果(覆盖率文件)，插桩后的类文件的运行结果可以由0和1组成，0表示插桩的代码未被实际测试到，1表示插桩的代码实际被测试到。插桩后的类文件的运行结果也可以为其他能够标识插桩的代码实际是否被执行的任意形式。

可选地，在本实施例中，可以根据测试指示文件和插桩后的类文件生成测试报告，也可以根据测试指示文件、源代码和插桩后的类文件生成测试报告，还可以根据测试指示文件、插桩后的类文件以及其他测试相关的文件生成测试报告。

作为一种可选的实施方式，在生成测试报告时，可以根据测试指示文件和插桩后的类文件生成测试报告：对插桩后的类文件和测试指示文件进行比较，得到比较结果，其中，比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；生成至少包括比较结果的测试报告。此时，生成的测试报告中可以指示出需要被测试到的代码中未被实际测试到的代码，或者指示需要被测试到的代码中被实际测试到的代码，或者两者的结合。根据测试指示文件和插桩后的类文件生成测试报告，生成的指示报告可以清楚、简明地指示插桩后的类文件的测试覆盖率，同时可以减少生成过程的资源消耗，节省测试报告的生成时间。

作为另一种可选地实施方式，在生成测试报告时，也可以根据测试指示文件、源代码和插桩后的类文件生成测试报告：对插桩后的类文件和测试指示文件进行比较，得到第一比较结果，其中，第一比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；将插桩后的类文件与源代码进行比较，得到第二比较结果，其中，第二比较结果至少用于指示插桩后的类文件对应的代码在源代码中的位置。根据测试指示文件、源代码和插桩后的类文件生成测试报告，生成的测试报告中可以指示插桩的类文件在源代码中对应的位置，提高测试报告包含信息的全面性。

可选地，在本实施例中，生成的测试报告中可以包括不限于：以进度条条形式表示的测试覆盖率(可以为未被实际测试到的代码与需要被测试到的代码的比例、被实际测试到的代码与需要被测试到的代码的比例、未被实际测试到的代码与被实际测试到的代码的比例、被实际测试到的代码与未被实际测试到的代码的比例等)，以百分比表示的测试覆盖率，未被实际测试到的代码的条数，被实际测试到的代码的条数，特定方法、类等对应的代码的测试覆盖率以及对应的被实际测试到的代码的条数、未被实际测试到的代码的条数等。生成的测试报告中包含的内容，可以根据需要进行设定。

可选地，第一接口函数、第二接口函数、第三接口函数可以来自于同一工程包(例如，JaCoCo)，也可以来自不同的工程包。只要可以实现前述各接口函数提供的功能(插桩、获取内存中的测试指示数据、清除内存中的测试指示数据)，均可以用来实现上述操作。

作为一种可选的方案，至少根据测试指示文件和插桩后的类文件生成测试报告包括：

S1，对插桩后的类文件和测试指示文件进行比较，得到比较结果，其中，比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；

S2，生成至少包括比较结果的测试报告。

可选地，作为一种可选的方案，在对插桩后的类文件和测试指示文件进行比较，得到比较结果之后、且在生成至少包括比较结果的测试报告之前，还包括：

S1，在源代码中标记出被实际测试到的代码和未被实际测试到的代码；

生成至少包括比较结果的测试报告包括：

S2，生成测试报告，其中，测试报告至少包括比较结果以及完成了标记的源代码。

通过在源代码中标记出际被测试到的代码和未被实际测试到的代码，可以直观展示需要测试的代码在源代码中的位置以及需要测试代码的执行情况(实际被测试到、未被实际测试到)，提高测试体验。

作为一种可选的方案，对目标文件进行插桩操作，得到插桩后的文件包括：

S1，获取插桩前的类文件的位置，其中，目标文件包括插桩前的类文件；

S2，调用第一接口函数、根据插桩前的类文件的位置对目标文件进行插桩操作，其中，第一接口函数用于将注入代码***到位置所指示的插桩前的类文件中，注入代码用于检测源代码中需要被测试到的代码是否被实际测试到。

作为一种可选的方案，对安装包进行测试，生成测试指示文件包括：

S1，调用第二接口函数获取内存中的测试指示数据，其中，测试指示数据用于指示在进行测试的过程中源代码中被实际测试到的代码；

S2，生成包含测试指示数据的测试指示文件。

作为一种可选的方案，在对安装包进行测试，生成测试指示文件之前，还可以调用第三接口函数清除内存中的测试指示数据。

作为一种可选的方案，源代码中需要被测试到的代码可以包括：源代码从修改前到修改后所改变的代码。

通过本申请提供的实施例，通过对待测试应用的源代码进行编译后得到的目标文件进行插桩，可以根据需要选择需要插桩的目标文件，从而实现针对性的插桩及测试，以克服相关技术中测试覆盖率收集效率低的技术问题，实现提高测试覆盖率分析效率的效果。

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

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

实施例2

根据本发明实施例，还提供了一种用于实施上述测试报告的生成方法的测试报告的生成装置，如图3所示，该装置包括：

1)插桩单元302，用于对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；

2)打包单元304，用于对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；

3)测试单元306，用于对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；

4)生成单元308，用于至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

可选地，在本实施例中，上述测试报告的生成装置可以但不限于应用于客户端获取代码测试覆盖率的场景中，如客户端使用JaCoCo结合测试项目获取android测试覆盖率的场景中，其中，代码测试覆盖率是指测试代码的执行过程中，被实际测试到的代码占需要被测试到的代码的比例。其中，上述客户端可以但不限于运行Android操作***。上述仅是一种示例，本实施例中对此不做任何限定。

具体地，在本实施例中，通过对待测试应用的源代码进行编译后得到的目标文件进行插桩，可以根据需要选择需要插桩的目标文件，从而实现针对性的插桩及测试，以克服相关技术中测试覆盖率收集效率低的技术问题，实现提高测试覆盖率分析效率的效果。

可选地，在本实施例中，上述目标文件可以包括但不限于对待测试应用的源代码进行编译得到的类文件的全部或者部分。在对待测试应用的源代码进行编译后，得到包括多个类文件(例如，500个、1000个等，根据待测试的应用不同，生成的类文件的数据也是不同的)；根据测试任务从得到的多个类文件中选择一个或多个类文件作为目标文件进行插桩操作。对目标文件进行插桩操作，也就是有选择的对编译后的待测试应用的源代码进行插桩。

作为一种可选的实施方式，在进行插桩时，客户端需要获知插桩前的类文件的位置，可以通过插桩前的类文件的位置信息参数进行确定。在获取到插桩前的类文件的位置后，可以通过调用用于对目标文件进行插桩的第一接口函数，对插桩前的类文件执行插桩操作，得到插桩后的类文件。第一接口函数可以将注入代码***到插桩前的类文件中。通过调用接口函数的方式对插桩前的类文件进行插桩操作，可以利用已有的接口函数对目标文件进行插桩，降低对客户端的性能要求，提高客户端对目标文件插桩的效率。

可以通过注入代码检测源代码中需要被测试到的代码是否被实际测试到，例如，如果需要被测试到的代码1实际被测试到，则将代码1对应的注入代码进行置位等修改操作，如果需要被测试到的代码2未被实际测试到，则不对代码2对应的注入代码进行修改(反之亦然，即，实际被测试到代码对应的注入代码不进行修改，未被实际测试到代码对应的注入代码进行修改)。通过注入代码的变化情况，即可反映需要被测试到的代码是否被实际测试到。上述仅为注入代码的示例，本实施例中对此不做任何限定。

可选地，在本实施例中，第一接口函数可以由已有的工程包提供。例如，在获取插桩前的类文件的位置以后，可以通过如下代码进行插桩操作：

<JaCoCo:instrument destdir＝"${classes_instr}">

<fileset dir＝"${classes}"includes＝"**/*.class"/>

</JaCoCo:instrument>

这里调用的第一接口函数为JaCoCo工程包提供的插桩函数，该工具包可以在对应的官网上进行下载，具体地第一接口函数的调用方式可以参考相关技术中。当然，这里的第一接口函数并不限于JaCoCo工程包提供的插桩函数，对于其他接口函数，只要具备执行根据插桩前文件的位置对目标文件进行插桩的功能，均可实现上述插桩操作。

作为另一种可选的实施方式，在进行插桩时，客户端可以直接获取插桩前的类文件的内容，例如，通过窗口获取，然后直接对获取的插桩前的类文件执行插桩操作。上述方式，需要客户端具备可以对插桩前的类文件的内容进行插桩的功能，对于客户端的性能要求较高。

可选地，在本实施例中，在对插桩后的文件进行打包操作之前，可以在打包相关的参数配置完成后(例如，通过Jenkins进行参数配置)，进行构建打包，得到待测试应用的安装包。打包得到的安装包可以为安卓安装包(Android Package，简称为apk包)，安装包中可以包括插桩后的类文件。在构建打包完成后，除了得到测试应用的安装包外，还可以保存有原来的类文件(可以包括插桩的类文件以及不需要插桩的类文件)，以便于后续生成测试报告时使用。

可选地，在得到待测试应用的安装包后，在对安装包进行测试前，可以通过调用第三接口函数清楚内存中的测试指示数据。这样，在对得到的安装包执行测试前，可以把以前遗留的测试指示数据清除掉，保证每次生成的测试指示文件都是当前测试的执行结果，避免了内存中已有的数据对测试结果的影响。

可选地，在本实施例中，得到待测试应用的安装包后，可以基于得到的安装包进行测试。作为一种可选的实施方式，对安装包的测试可以是在客户端本地进行的，在进行测试的过程中，源代码中被实际测试到的代码可以通过内存中的测试指示数据显示。可以根据插桩信息确定测试指示数据中对应于插桩后的类文件的部分。可以采用多种方式获取内存中的测试指示数据，例如，可以通过调用第二接口函数获取内存中的测试指示数据，也可以通过定义相应的获取函数进行测试指示数据的获取，还可以通过其他可以获取内存数据的方式，进行测试指示数据的获取。获取测试指示数据后，生成包含测试指示数据的测试指示文件，可以获得插桩后的类文件执行情况。作为另一种可选的实施方式，可以在能够进行安装包测试的网站上进行安装包的在线测试，由网站直接提供测试指示文件。

与在线测试获取测试指示文件相比，通过调用第二接口函数获取内存中的测试指示数据，生成测试指示文件，测试指示数据的获取时间更加灵活，可以离线进行测试指示文件的生成，减小测试指示文件的生成对网络的依赖性。

可选地，在本实施例中，在得到的安装包进行测试时，可以采用两种方式生成测试指示数据：一种通过专门用来生成测试指示数据的安装包，这种方式一般用于手工测试生成，通过手工测试生成测试指示数据；另一种是通过定时器的方式，在得到的安装包中新建一个定时器任务，定时收集生成的测试指示数据。

可选地，在本实施例中，生成的测试指示文件，可以是差异覆盖率的测试指示文件，也可以是全量覆盖率的测试指示文件。测试完成后，根据覆盖率结果衡量测试覆盖程度，主要分为两种：

(1)差异覆盖率：改动点的代码执行覆盖率情况；

(2)全量覆盖率：本次测试代码执行全部覆盖率情况。

差异覆盖率主要是根据开发代码变更的差异，得出改动代码的范围，生成的类文件只包含改动部分。这样，在分析得到覆盖率报告(即，前述测试指示报告)时，生成的报告文件就只包含差异部分，然后根据这个范围有针对性的只生成这部分改动的代码覆盖率结果。通过覆盖率结果反向衡量测试的充分性，更好的和精准评估的测试范围去做比较。

全量覆盖率，即全部代码的覆盖率结果，是把所有代码对应的类文件一起分析生成覆盖率文件(即，前述测试指示报告)。在对生成的全量覆盖率文件进行分析时，不一定要全部去分析，可以只需要关注测试功能所覆盖的那部分功能代码。

使用哪种覆盖率是由测试阶段的内容决定，比如，上线前测试、回归测试等，主要关注的是改动点的变化，使用差异覆盖率效果比较理想；如果是新增功能的测试，使用全量覆盖率效果比较理想。

可选地，在本实施例中，源代码中需要被测试到的代码可以包括多种，例如，源代码从修改前到修改后所改变的代码。也即，源代码中修改后的代码增加或者发生变化的代码。例如，源代码中相对于修改前新增加的一段函数代码，或者，源代码中相对于修改前被更改的一段函数代码。又例如，源代码中需要被测试到的代码可以包括某段关键代码或者指定代码。源代码中需要被测试到的代码包括源代码从修改前到修改后所改变的代码，可以实现对源代码中的改动代码的测试覆盖率分析，实现有针对性的测试。

可选地，在本实施例中，生成的测试指示文件可以包括插桩后的类文件的运行结果(覆盖率文件)，插桩后的类文件的运行结果可以由0和1组成，0表示插桩的代码未被实际测试到，1表示插桩的代码实际被测试到。插桩后的类文件的运行结果也可以为其他能够标识插桩的代码实际是否被执行的任意形式。

可选地，在本实施例中，可以根据测试指示文件和插桩后的类文件生成测试报告，也可以根据测试指示文件、源代码和插桩后的类文件生成测试报告，还可以根据测试指示文件、插桩后的类文件以及其他测试相关的文件生成测试报告。

作为一种可选的实施方式，在生成测试报告时，可以根据测试指示文件和插桩后的类文件生成测试报告：对插桩后的类文件和测试指示文件进行比较，得到比较结果，其中，比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；生成至少包括比较结果的测试报告。此时，生成的测试报告中可以指示出需要被测试到的代码中未被实际测试到的代码，或者指示需要被测试到的代码中被实际测试到的代码，或者两者的结合。根据测试指示文件和插桩后的类文件生成测试报告，生成的指示报告可以清楚、简明地指示插桩后的类文件的测试覆盖率，同时可以减少生成过程的资源消耗，节省测试报告的生成时间。

作为另一种可选地实施方式，在生成测试报告时，也可以根据测试指示文件、源代码和插桩后的类文件生成测试报告：对插桩后的类文件和测试指示文件进行比较，得到第一比较结果，其中，第一比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；将插桩后的类文件与源代码进行比较，得到第二比较结果，其中，第二比较结果至少用于指示插桩后的类文件对应的代码在源代码中的位置。根据测试指示文件、源代码和插桩后的类文件生成测试报告，生成的测试报告中可以指示插桩的类文件在源代码中对应的位置，提高测试报告包含信息的全面性。

可选地，在本实施例中，生成的测试报告中可以包括不限于：以进度条条形式表示的测试覆盖率(可以为未被实际测试到的代码与需要被测试到的代码的比例、被实际测试到的代码与需要被测试到的代码的比例、未被实际测试到的代码与被实际测试到的代码的比例、被实际测试到的代码与未被实际测试到的代码的比例等)，以百分比表示的测试覆盖率，未被实际测试到的代码的条数，被实际测试到的代码的条数，特定方法、类等对应的代码的测试覆盖率以及对应的被实际测试到的代码的条数、未被实际测试到的代码的条数等。生成的测试报告中包含的内容，可以根据需要进行设定。

可选地，第一接口函数、第二接口函数、第三接口函数可以来自于同一工程包(例如，JaCoCo)，也可以来自不同的工程包。只要可以实现前述各接口函数提供的功能(插桩、获取内存中的测试指示数据、清除内存中的测试指示数据)，均可以用来实现上述操作。

作为一种可选的方案，生成单元308包括：

比较模块，用于对插桩后的类文件和测试指示文件进行比较，得到比较结果，其中，比较结果至少用于指示需要被测试到的代码中未被实际测试到的代码；

第一生成模块，用于生成至少包括比较结果的测试报告。

可选地，作为一种可选的方案，该装置还包括：标记单元，其中，

标记单元，用于在对插桩后的类文件和测试指示文件进行比较，得到比较结果之后、且在生成至少包括比较结果的测试报告之前，在源代码中标记出被实际测试到的代码和未被实际测试到的代码；

第一生成模块，还用于生成测试报告，其中，测试报告至少包括比较结果以及完成了标记的源代码。

通过在源代码中标记出际被测试到的代码和未被实际测试到的代码，可以直观展示需要测试的代码在源代码中的位置以及需要测试代码的执行情况(实际被测试到、未被实际测试到)，提高测试体验。

作为一种可选的方案，对目标文件进行插桩操作，插桩单元302包括：

获取模块，用于获取插桩前的类文件的位置，其中，目标文件包括插桩前的类文件；

第一调用模块，用于调用第一接口函数、根据插桩前的类文件的位置对目标文件进行插桩操作，其中，第一接口函数用于将注入代码***到位置所指示的插桩前的类文件中，注入代码用于检测源代码中需要被测试到的代码是否被实际测试到。

作为一种可选的方案，测试单元306包括：

第二调用模块，用于调用第二接口函数获取内存中的测试指示数据，其中，测试指示数据用于指示在进行测试的过程中源代码中被实际测试到的代码；

第二生成模块，用于生成包含测试指示数据的测试指示文件。

作为一种可选的方案，该装置还包括：

调用单元，用于在对安装包进行测试，生成测试指示文件之前，调用第三接口函数清除内存中的测试指示数据。

实施例3

本发明实施例的应用环境可以但不限于参照实施例1中的应用环境，本实施例中对此不再赘述。本发明实施例中提供了用于实施上述测试报告的生成方法的一种可选的具体应用示例。

本实施例中所提供的测试报告的生成方法可以用于获取android测试覆盖率。在该方法中，使用JaCoCo结合被测项目进行android覆盖率的收集并生成报告结果；采用Apache Ant方式进行插桩打包；测试过程通过自动化工具收集覆盖率数据，最后通过自定义报告模版生成覆盖率报告。上述Apache Ant是一个将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具，大多用于Java环境中的软件开发。

本发明实施例中所提供的上述测试报告的生成方法，可以：

(1)基于JaCoCo进行覆盖率分析，支持多种覆盖率分析，如行覆盖、分支覆盖、方法覆盖等，分析更全面；

(2)结合自动化测试，当代码出现变更时，自动执行相应模块的自动化测试并收集覆盖率，分析改动代码是否被覆盖，效率更高；

(3)支持生成差异覆盖率报告，快速分析改动代码的覆盖情况，分析效率更高；

(4)从插桩打包、测试执行、到生成覆盖率报告，每一个步骤都可以实现成自动化，更高效率支持测试。

下面对该方法进行具体说明。图4是根据本发明实施例的另一种可选的测试报告的生成方法的流程图，如图4所示，该方法包括如下步骤：

步骤S402，代码打桩。

通过调用JaCoCo工程包的用于进行代码插桩的接口函数(作用同前述第一接口函数)，对被测对象进行代码插桩。

在进行代码插桩前，首先需要熟悉被测项目的打包构建流程，目前大部分被测对象是以build方式打包，属于Apache Ant方式(Apache Ant是一个将软件编译、测试、部署等步骤联系在一起加以自动化的工具，大多用于Java环境中的软件开发)。以Apache Ant方式插桩打包的流程如下：被测对象工程的build文件被修改，编译节点被修改，代码插桩注入。上述流程主要引入JaCoCo相关定义，以JaCoCo的规范进行插桩打包。整个修改流程可以做成全自动修改，打包成用于代码自动插桩的自动插桩包，例如，Java归档包(Java ARchive，简称为jar包)，jar包的名称可以为如下形式：autoinsertxml.jar。打包成的自动插桩包(例如，jar包)可以放到打包服务器后台指定的目录下。当触发构建打包时，便实现代码插桩修改。

下面以Apache Ant方式为例对生成自动插桩包的过程进行说明。

在进行代码插桩时，工程build文件进程被修改。通过引入JaCoCo定义，修改编译节点。JaCoCo提供了自己的代理，完成插桩的同时，还提供了丰富的dump(转储)输出机制，如file,tcp server,tcp client。覆盖率信息可以通过文件或是tcp的形式输出。这样外部程序可以很方便随时获取被测程序的覆盖率。

下面结合具体的代码说明插桩的实现方式。

文件开头的命名空间加入：

xmlns:JaCoCo＝"antlib:org.JaCoCo.ant"

引入JaCoCo的jar和相关定义：

<taskdef uri＝"antlib:org.JaCoCo.ant"resource＝"org/JaCoCo/ant/antlib.xml">

<classpath path＝"${basedir}/libs/JaCoCoant.jar"/>

重新定义class文件生成路径：

<property name＝"classes_instr"value＝"${temp}/classes_instr"/>

修改compile编译节点，插桩注入：

<JaCoCo:instrument destdir＝"${classes_instr}">

<fileset dir＝"${classes}"includes＝"**/*.class"/>

</JaCoCo:instrument>

修改打包package节点，主要是指定JaCoCo编译后的类路径：

<jar basedir＝"${classes_instr}"destfile＝"temp.jar"/>

修改混淆obfuscate节点，增加混淆所需要的：

<arg value＝"-libraryjars${lib}/JaCoCoagent.jar"/>

将delete、mkdir、unzip操作指向classes_instr。

修改分包splitClasses节点，指向classes_instr：

<arg value＝"${classes_instr}"/>

修改热补丁注入injectPatchCode节点，指向classes_instr：

<YYBInjectPatchCode inputDir＝"${classes_instr}"

修改dex节点，指向classes_instr：

<arg path＝"${classes_instr}"

修改dex_sub节点，指向classes_instr，同时在excludes中加入jacocoagent.jar：

<arg path＝"${classes_instr}"

fileset dir＝"${lib}"excludes＝"tmdownloadsdk.jar,tmapkpatch.jar,.....,jacocoagent.jar"/>

在sign_obfuscated的delete节点增加*.zip：

<fileset dir＝"${bin}"obfuscatedexcludes＝"*.apk*.txt*.plg*.jar*.zip"/>

在remove_temp的delete节点增加*.zip：

<fileset dir＝"${bin}"excludes＝"*.apk*.txt*.plg*.jar*.zip"/>

可以将上面的操作，做成全自动修改，打包成autoinsertxml.jar，放到打包服务器后台指定的目录下，jar包里详细内容可以如图5所示。

具体地，可以修改AndroidManifest.xml文件，增加一个覆盖率生成服务(这个后续的覆盖率生成工具用到)，修改build_common.xml文件，实现主干代码插桩修改，修改build_plugins.xml文件，实现插件代码的插桩修改。

需要说明的是，在本实施例中，以Apache Ant方式进行插桩打包的流程为例说明插桩的流程。对于插桩打包的方式，除了通过Apache Ant方式，也可以通过命令行方式、Apache Maven方式、Eclipse EclDmma Plugin方式等实现，具体的插桩打包方式，可以根据项目方式的不同而定。

步骤S404，打覆盖率包。

可以通过Jenkins配置参数后进行构建打包(如图6所示)。构建完成后，可以生成apk包和class文件(类文件，在后面生成覆盖率报告时使用)。构建完成生成的apk包和class文件可以如图7所示。

具体地，通过Jenkins配置参数，只要是在jenkins中实现配置的过程，如下：

(1)配置构建参数。

在Jenkins任务配置参数化构建的内容，如svn地址、用户名、密码、版本号、构建参数等(如图8所示)。

(2)配置构建描述(如图9所示)。

(3)配置项目ID和创建精准入库任务(如图10所示)。

(4)编写脚本，Check out代码(如图11所示)。

(5)编写命令，实现插桩，其中jar包为已经实现插桩过程自动化的可执行文件(如图12所示)。

(6)编译打包(如图13所示)。

(7)备份class，用于下一步生成覆盖率报告使用(如图14所示)。

(8)保存存档文件，包括class文件，以及apk包等(如图15所示)。

需要说明的是，上述过程仅是对Jenkins配置参数的一个示例，并不对Jenkins配置的参数类型、参数个数以及参数的配置顺序等做任何限定。

步骤S406，执行测试，收集覆盖率结果。

使用构建完成的包进行测试，这里，可以通过手工测试生成ec文件(覆盖率文件)，也可以结合自动化进行测试执行(例如，可以通过任务触发)，构建完成后自动化触发功能自动化测试，测试完成自动收集覆盖率结果(作用同前述覆盖率指示数据)，用于生成覆盖率报告(作用同前述测试报告)。

上述ec文件有两种生成方式，一种通过专门用来生成覆盖率文件的安装包(例如，APK)，这种方式一般用于手工测试生成，如图16所示，点击生成ec文件可自动dump下内存中覆盖率数据生成ec文件；另外一种是通过定时器的方式，在被测包里新建一个定时器JOB任务，定时去收集生成的覆盖率文件。

例如，对于上述通过专门用来生成覆盖率文件的安装包的方式，当触发生成ec文件时，实质上会启动被测包中的ResultManagerService服务，也就是dump覆盖率数据：在ResultManagerService服务启动时，会调用jacoco-cov-sdk.jar包中的ResultManager.dumpCoverageJacoco(true,filename)方法，该方法的主要功能就是反射调用jaCoCo的dump方法，来生成覆盖率数据。

对于上述通过定时器的方式，启动定时器，按指定的时间生成ec文件，指的就是一个Timer，按指定的时间周期去dump覆盖率数据。

在触发生成ec文件之前，可以先清除内存中已有的覆盖率数据。该操作会清除内存记录并且会删除SD卡中存在的ec文件。当触发这个操作时，实际会去启动测试包中添加的ReSetManagerService服务，也就是reset覆盖率数据：在ReSetManagerService启动时，调用jacoco-cov-sdk.jar包中的ResultManager.reSetCoverageJacoco()方法，该方法的主要功能就是反射调用jaCoCo的reset方法，来清理覆盖率数据。示例代码如下：

Class<？>RT＝Class.forName("org.jacoco.agent.rt.RT")；

Method methodGetAgent＝RT.getMethod("getAgent")；

Object objAgent＝methodGetAgent.invoke(null)；

//Get Agent Class

Class classAgent＝Class.forName("org.jacoco.agent.rt.internal_b0d6a23.Agent")；

//reset

Method methodDump＝classAgent.getMethod("reset")；

methodDump.invoke(objAgent,null).

步骤S408，生成覆盖率报告。

根据上述步骤生成的class文件、ec文件，通过编写report的build方式来生成报告结果。这里可以实现一个生成报告的模版，使用者只需要把class文件、ec文件、源码copy到本机上，修改相关的配置、生成报告即可。结合图17所示，具体操作可以如下：

(1)将覆盖率打包结果中的classes.zip放到模版根目录中并解压。

(2)根据打包时的svn地址和版本号，取下源码放入到src目录。

(3)将ec文件(如yyb1.ec、yyb2.ec、yyb3.ec)全部放到模版根目录中。

(4)修改build_property文件，名称写入到value中(去掉ec后缀，如图18所示)。

(5)build文件，如无路径变化，基本不用修改。

(6)除了主干代码，如果还有插件部分，build文件取build_group，分别为<groupname＝"YYB">、<group name＝"plugin_power_save">。

(7)执行ant，report目录就会生成。

report目录生成后，进去执行index就看到覆盖率报告(如图19所示)。还可以进入到实际代码查看覆盖情况，如图20所示，代码中具有阴影的部分为需要执行但是未被实际执行的代码。

步骤S410～步骤S412，分析覆盖率结果，补充测试验证。

分析覆盖率报告，根据覆盖率结果，补充测试点并进行验证。

此外，还可以将覆盖率与自动化结合进行测试。通过两者的结合，可以得到每个自动化用例的覆盖率数据，得出几个纬度的结果：用例和代码的映射关系。映射关系汇总后，可以按方法的调用频繁度来优化代码，优化调用频繁度高的代码，找出冗余代码等等。

具体地，在每个用例执行前，***清理覆盖率数据的方法，具体地，在自动化脚本基类的setUp()方法最后***清理覆盖率数据的方法，如下：

这样，每个用例开始执行前，就会把以前遗留的覆盖率数据清除掉，保证每次覆盖率都是一条用例的执行结果。在每个用例执行后，dump出覆盖率数据，如下：

这样运行所有的自动化用例后，一条用例对应于一个覆盖率文件，输出覆盖率文件，就可以生成覆盖率报告结果。另外，通过这种方式根据用例对应功能的特点，筛选出重点函数，形成一个比较精简的用例和代码映射关系出来，方便后续的改动点定位。

在本发明实施例的上述技术方案中，在关键环节实现自动化，如插桩打包环节结合Jenkins任务配置实现自动打包，在测试过程通过反射实现覆盖率数据的自动收集，测试报告通过自动义模版只要简单的配置便可快速生成报告有效提升覆盖率使用效率。同时，该方案可以把覆盖率与自动化执行相结合，并且根据项目实际情况生成全量或者差异覆盖率报告，提升测试和分析效率，有效评估测试质量。

通过本发明实施例的上述技术方案，通过覆盖率分析，可以有效评估测试质量，特别是在项目通过外包测试时非常有必要，对于测试人员，通过覆盖率分析，一方面可以评估测试质量，确认未覆盖测试点，避免漏测；另一方面，也可以发现冗余代码，改善代码质量，减少安装包大小。本方案把覆盖率分析各关键环节自动化，并结合自动化测试，有效提升测试效率和测试质量。

需要说明的是，在本发明实施例中，上述所示的各文件名称(例如，AndroidManifest.xml文件、build_common.xml文件)、路径名称、代码中所定义的各参数名称等仅为一种可能的实例，用于说明本实施例中的测试报告的生成方法，具体的文件名称、路径名称、参数名称等，本实施例中对此不做任何限定。

实施例4

根据本发明实施例，还提供了一种用于实施上述测试报告的生成方法的测试报告的生成设备，如图21所示，该设备包括：

1)处理器2102，设置为对目标文件进行插桩操作，得到插桩后的文件，其中，目标文件通过对待测试应用的源代码进行编译得到；还设置为对插桩后的文件进行打包操作，得到待测试应用的安装包，其中，安装包中包括插桩后的类文件，插桩后的类文件用于指示源代码中需要被测试到的代码；还设置为对安装包进行测试，生成测试指示文件，其中，测试指示文件用于指示在进行测试的过程中源代码中被实际测试到的代码；还设置为至少根据测试指示文件和插桩后的类文件生成测试报告，其中，测试报告至少用于指示需要被测试到的代码与被实际测试到的代码之间的比对关系；

2)存储器2104，与处理器2102连接，设置为存储测试指示文件和/或存储测试报告。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

实施例5

本发明的实施例中还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以位于网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S1，对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；

S2，对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；

S3，对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；

S4，至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，对所述插桩后的类文件和所述测试指示文件进行比较，得到比较结果，其中，所述比较结果至少用于指示所述需要被测试到的代码中未被实际测试到的代码；

S2，生成至少包括所述比较结果的测试报告。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例记载的方法步骤。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

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

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

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

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

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

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

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

Claims (13)

1.一种测试报告的生成方法，其特征在于，包括：

对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；

对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；

对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；

至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

2.根据权利要求1所述的方法，其特征在于，至少根据所述测试指示文件和所述插桩后的类文件生成测试报告包括：

对所述插桩后的类文件和所述测试指示文件进行比较，得到比较结果，其中，所述比较结果至少用于指示所述需要被测试到的代码中未被实际测试到的代码；

生成至少包括所述比较结果的测试报告。

3.根据权利要求2所述的方法，其特征在于，

在对所述插桩后的类文件和所述测试指示文件进行比较，得到比较结果之后、且在生成至少包括所述比较结果的测试报告之前，还包括：在所述源代码中标记出所述被实际测试到的代码和所述未被实际测试到的代码；

生成至少包括所述比较结果的测试报告包括：生成所述测试报告，其中，所述测试报告至少包括所述比较结果以及完成了所述标记的所述源代码。

4.根据权利要求1所述的方法，其特征在于，对目标文件进行插桩操作，得到插桩后的文件包括：

获取插桩前的类文件的位置，其中，所述目标文件包括所述插桩前的类文件；

调用第一接口函数、根据所述插桩前的类文件的位置对所述目标文件进行插桩操作，其中，所述第一接口函数用于将注入代码***到所述位置所指示的插桩前的类文件中，所述注入代码用于检测所述源代码中所述需要被测试到的代码是否被实际测试到。

5.根据权利要求1所述的方法，其特征在于，对所述安装包进行测试，生成测试指示文件包括：

调用第二接口函数获取内存中的测试指示数据，其中，所述测试指示数据用于指示在进行所述测试的过程中所述源代码中所述被实际测试到的代码；

生成包含所述测试指示数据的所述测试指示文件。

6.根据权利要求1至5中任一项所述的方法，其特征在于，在对所述安装包进行测试，生成测试指示文件之前，所述方法还包括：

调用第三接口函数清除内存中的测试指示数据。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述源代码中需要被测试到的代码包括：所述源代码从修改前到修改后所改变的代码。

8.一种测试报告的生成装置，其特征在于，包括：

插桩单元，用于对目标文件进行插桩操作，得到插桩后的文件，其中，所述目标文件通过对待测试应用的源代码进行编译得到；

打包单元，用于对所述插桩后的文件进行打包操作，得到所述待测试应用的安装包，其中，所述安装包中包括插桩后的类文件，所述插桩后的类文件用于指示所述源代码中需要被测试到的代码；

测试单元，用于对所述安装包进行测试，生成测试指示文件，其中，所述测试指示文件用于指示在进行所述测试的过程中所述源代码中被实际测试到的代码；

生成单元，用于至少根据所述测试指示文件和所述插桩后的类文件生成测试报告，其中，所述测试报告至少用于指示所述需要被测试到的代码与所述被实际测试到的代码之间的比对关系。

9.根据权利要求8所述的装置，其特征在于，所述生成单元包括：

比较模块，用于对所述插桩后的类文件和所述测试指示文件进行比较，得到比较结果，其中，所述比较结果至少用于指示所述需要被测试到的代码中未被实际测试到的代码；

第一生成模块，用于生成至少包括所述比较结果的测试报告。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：标记单元，其中，

所述标记单元，用于在对所述插桩后的类文件和所述测试指示文件进行比较，得到比较结果之后、且在生成至少包括所述比较结果的测试报告之前，在所述源代码中标记出所述被实际测试到的代码和所述未被实际测试到的代码；

所述第一生成模块，还用于生成所述测试报告，其中，所述测试报告至少包括所述比较结果以及完成了所述标记的所述源代码。

11.根据权利要求8所述的装置，其特征在于，所述插桩单元包括：

获取模块，用于获取插桩前的类文件的位置，其中，所述目标文件包括所述插桩前的类文件；

第一调用模块，用于调用第一接口函数、根据所述插桩前的类文件的位置对所述目标文件进行插桩操作，其中，所述第一接口函数用于将注入代码***到所述位置所指示的插桩前的类文件中，所述注入代码用于检测所述源代码中所述需要被测试到的代码是否被实际测试到。

12.根据权利要求8所述的装置，其特征在于，所述测试单元包括：

第二调用模块，用于调用第二接口函数获取内存中的测试指示数据，其中，所述测试指示数据用于指示在进行所述测试的过程中所述源代码中所述被实际测试到的代码；

第二生成模块，用于生成包含所述测试指示数据的所述测试指示文件。

13.根据权利要求8至12中任一项所述的装置，其特征在于，所述装置还包括：调用单元，用于在对所述安装包进行测试，生成测试指示文件之前，调用第三接口函数清除内存中的测试指示数据。