CN104809071A - 一种代码测试方法及装置 - Google Patents

Abstract

本发明提供一种代码测试方法及装置，在测试每个被测试代码时，可以基于maven标准目录结构，创建被测试代码和测试代码的工程目录，然后将Cobertura测试包存储至工程目录中资源目录指定的存储位置中，并将被测试代码和测试代码的工程目录与预先创建的构建文件关联，使得构建文件可以调用Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况，这样对于每个被测试代码来说，只需要基于maven标准目录结构创建工程目录，基于工程目录来存储所用的Cobertura测试包并关联构建文件来获得代码覆盖率情况，提高测试的通用性。

Description

一种代码测试方法及装置

技术领域

本发明涉及软件测试技术领域，更具体地说，涉及一种代码测试方法及装置。

背景技术

软件测试是软件构建过程中非常重要的一环，通过软件测试可以发现软件隐藏的问题，并衡量软件的质量。在所有的软件测试中，单元测试是一个重要环节，其中单元测试是针对应用程序中可测试的最小单元的测试，所述最小单元一般指方法、类以及可实现一个功能的代码段(可以称为功能模块等被测试代码)。

目前单元测试的主要方法是获取应用程序中可测试的最小单元，将其使用的程序代码同应用程序代码的其余部分隔离开来进行测试。衡量最小单元的一个很重要的指标是最小单元的代码覆盖率。常用的代码覆盖率测试原理是将JUnit单元测试与字节码工具(byte-code-instrumentation)相结合，通过对编译后的java字节码文件进行插桩，使得在最小单元的测试执行过程中能自动统计每一行代码是否被执行，从而获得代码被覆盖的情况。据此原理，涌现出很多不同的覆盖率检验工具，但是现有的覆盖率检测工具的复用性不高。

发明内容

有鉴于此，本发明提供一种代码测试方法及装置，用于提高测试的复用性。为了实现该目的，本发明提供如下技术方案：

本发明提供一种代码测试方法，所述方法包括：

基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使所述被测试代码和测试代码的工程目录的结构为所述maven标准目录结构；

将Cobertura测试包存储至所述工程目录中资源目录指定的存储位置中；

将所述被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使所述构建文件调用所述Cobertura测试包将Ant工具和Cobertura工具结合来对所述被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况；

从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

利用Mock工具模拟未完成的协同对象，所述协同对象为所述被测试代码运行时所调用的对象，以辅助使处理后的所述被测试代码正常运行；

获取处理后的所述被测试代码的测试代码，并运行所述构建文件和所述测试代码，得到测试结果，所述测试结果用于指示所述被测试代码的代码覆盖率情况和运行情况。

优选地，所述构建文件的预先创建包括：

使用mkdir命令创建所述构建文件的临时目录，所述临时目录用于提供测试过程生成的临时文件的目录；

创建所述构建文件下的complie目标，所述complie目标用于调用Ant的javac任务对所述被测试代码和所述测试代码进行编译；

创建所述构建文件下的instrument目标，以调用Cobertura的instrument任务，对所述被测试代码中的被测java程序编译所得class文件进行插桩；

创建所述构建文件下的test目标以调用Ant的JUnit任务对所述被测试代码进行单元测试，在进行单元测试时通过所述test目标的name属性指定将要运行的所述测试代码的名称；

创建所述构建文件下的coverage-report目标，所述coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成所述测试结果中的代码覆盖率测试报告；

创建所述构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务；

创建所述构建文件下的clean目标以调用Ant的delete命令来删除所述临时目录下的所述临时文件。

优选地，从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元，包括：

通过第一正则表达式在所述instrument目标中选择所述被测试代码中需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

所述测试单元包括类和包。

优选地，剔除所述被测试代码中无需测试的测试单元，包括：

对所述被测试代码中的方法进行解析，得到所述方法的参数和返回类型；

基于所述方法的参数和返回类型，将所述被测试代码中的set方法、get方法和init方法剔除；

将所述instrument目标使用的方法和所述被测试代码中除set方法、get方法和init方法后剩余的每个方法分别与判定条件进行比较，得到比较结果，所述判定条件通过第二正则表达式表示；

当所述比较结果表明所述方法的参数信息满足所述判定条件时，将满足所述判定条件的方法剔除。

优选地，所述利用Mock工具模拟未完成的协同对象，包括：

导入与JMock工具相关的jar包，以使所述测试代码调用JMock工具封装的方法；

使用runwith来注释所述JMock工具内的测试运行器，所述测试运行器用于管理所述协同对象中的测试类；

创建Mockery的context对象和Mock对象；

通过contex创建Mock对象的实例，所述实例为利用Mock工具模拟的所述协同对象；

创建Exception对象来模拟所述实例的协同行为，所述协同行为用于使处理后的所述被测试代码可正常运行。

本发明还提供一种代码测试装置，所述装置包括：

创建单元，用于基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使所述被测试代码和测试代码的工程目录的结构为所述maven标准目录结构；

存储单元，用于将Cobertura测试包存储至所述工程目录中资源目录指定的存储位置中；

关联单元，用于将所述被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使所述构建文件调用所述Cobertura测试包将Ant工具和Cobertura工具结合来对所述被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况；

获取单元，用于从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

模拟单元，用于利用Mock工具模拟未完成的协同对象，所述协同对象为所述被测试代码运行时所调用的对象，以辅助使处理后的所述被测试代码正常运行；

测试单元，用于获取处理后的所述被测试代码的测试代码，并运行所述构建文件和所述测试代码，得到测试结果，所述测试结果用于指示所述被测试代码的代码覆盖率情况和运行情况。

优选地，所述装置还包括构建单元，用于预先创建所述构建文件；所述构建单元包括：

第一创建子单元，用于使用mkdir命令创建所述构建文件的临时目录，所述临时目录用于提供测试过程生成的临时文件的目录；

第二创建子单元，用于创建所述构建文件下的complie目标，所述complie目标用于调用Ant的javac任务对所述被测试代码和所述测试代码进行编译；

第三创建子单元，用于创建所述构建文件下的instrument目标，以调用Cobertura的instrument任务，对所述被测试代码中的被测java程序编译所得class文件进行插桩；

第四创建子单元，用于创建所述构建文件下的test目标以调用Ant的JUnit任务对所述被测试代码进行单元测试，在进行单元测试时通过所述test目标的name属性指定将要运行的所述测试代码的名称；

第五创建子单元，用于创建所述构建文件下的coverage-report目标，所述coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成所述测试结果中的代码覆盖率测试报告；

第六创建子单元，用于创建所述构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务；

第七创建子单元，用于创建所述构建文件下的clean目标以调用Ant的delete命令来删除所述临时目录下的所述临时文件。

优选地，所述获取单元从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元，包括：通过第一正则表达式在所述instrument目标中选择所述被测试代码中需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

所述测试单元包括类和包。

优选地，所述获取单元包括：

选择子单元，用于从所述被测试代码中选择需要测试的测试单元；

解析子单元，用于对所述被测试代码中的装置进行解析，得到所述装置的参数和返回类型；

第一剔除子单元，用于基于所述装置的参数和返回类型，将所述被测试代码中的set装置、get装置和init装置剔除；

比较子单元，用于将所述instrument目标使用的装置和所述被测试代码中除set装置、get装置和init装置后剩余的每个装置分别与判定条件进行比较，得到比较结果，所述判定条件通过第二正则表达式表示；

第二剔除子单元，用于当所述比较结果表明所述装置的参数信息满足所述判定条件时，将满足所述判定条件的装置剔除。

优选地，所述模拟单元包括：

导入子单元，用于导入与JMock工具相关的jar包，以使所述测试代码调用JMock工具封装的装置；

注释子单元，用于使用runwith来注释所述JMock工具内的测试运行器，所述测试运行器用于管理所述协同对象中的测试类；

第八创建子单元，用于创建Mockery的context对象和Mock对象；

第九创建子单元，用于通过contex创建Mock对象的实例，所述实例为利用Mock工具模拟的所述协同对象；

第十创建子单元，用于创建Exception对象来模拟所述实例的协同行为，所述协同行为用于使处理后的所述被测试代码可正常运行。

与现有技术相比，本发明的优点如下：

本发明提供的上述技术方案，在测试每个被测试代码时，可以基于maven标准目录结构，创建被测试代码和测试代码的工程目录，然后将Cobertura测试包存储至工程目录中资源目录指定的存储位置中，并将被测试代码和测试代码的工程目录与预先创建的构建文件关联，使得构建文件可以调用Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况，这样对于每个被测试代码来说，只需要基于maven标准目录结构创建工程目录，基于工程目录来存储所用的Cobertura测试包并关联构建文件来获得代码覆盖率情况，从而无需针对每个被测试代码来重新进行Ant构建过程，提高测试的通用性。

附图说明

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

图1为本发明实施例提供的代码测试方法的一种流程图；

图2为本发明实施例提供的工程目录的一种示意图；

图3为本发明实施例提供的可视化测试环境的一种示意图；

图4为图1所示代码测试方法中预先构建构建文件的流程图；

图5为图1所示代码测试方法中步骤104的流程图；

图6为图1所示代码测试方法中步骤105的流程图；

图7为本发明实施例提供的代码测试装置的一种结构示意图；

图8为本发明实施例提供的代码测试装置的另一种结构示意图；

图9为本发明实施例提供的代码测试装置中构建单元的结构示意图；

图10为本发明实施例提供的代码测试装置中获取单元的结构示意图；

图11为本发明实施例提供的代码测试装置中模拟单元的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本发明，首先对本发明涉及的一些专业术语进行说明：

Maven是基于项目对象模型(POM)，可以通过一小段描述信息来管理报告、文档以及项目的构建的软件项目管理工具，Maven包含一个项目对象模型(Project Object Model)、一组标准集合、一个项目生命周期(ProjectLifecycle)、一个依赖管理系统(Dependency Management System)和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑；

Cobertura是一种开源工具，其通过检测基本的代码，并观察在测试包运行时执行了哪些代码和没有执行哪些代码，来测量测试覆盖率；

Ant(Another Neat Tool)是一个基于Java的跨平台构建工具，可以实现项目的自动构建和部署等功能；

Mock工具是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法；

mkdir是UNIX操作系统中的目录操作命令，用来创建一个目录；

javac是java语言编程编译器，其中javac工具读由java语言编写的类和接口的定义，并将它们编译成字节代码的class文件，javac可以隐式编译一些没有在命令行中提及的源文件，并用-verbose选项可跟踪自动编译；

JUnit是由Kent Beck和Erich Gamma编写的一个Java语言的单元测试框架，目前多数Java的开发环境都已经集成了JUnit作为单元测试的工具；

JMock是基于Java开发，帮助创建mock这一模拟对象的工具，模拟对象可以取代真实对象的位置，用于测试一些与真实对象进行交互或依赖于真实对象的功能；

Mockery是简单而灵活的PHP mock对象框架，常用在PHPUnit，PHPSpec或者其他测试框架的单元测试中，其核心目标是提供一个双向测试框架，提供一个succint API，能清晰的定义所有可能的对象操作和交互，使用人类可读的Domain Specific Language(DSL)。

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

请参阅图1，其示出了本发明实施例提供的代码测试方法的一种流程图，可以包括以下步骤：

101：基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使被测试代码和测试代码的工程目录的结构为maven标准目录结构。在本发明实施例中，maven是目前常用的一种项目管理工具，其是基于项目对象模型并通过一段描述信息来管理项目的构建、报告和文档的软件项目管理工具。在众多工程师大量实践中得出一maven目录结构约定，该maven目录结构约定规定了较为合理的maven标准目录结构，因此在本发明实施例中基于maven标准目录结构，创建被测试代码和测试代码的工程目录。

其中被测试代码和测试代码的工程目录可以如图2所示，其示出了被测试代码的被测试代码目录和测试代码的目录以及使用的Cobertura测试包的资源目录，被测试代码目录用于指示被测试代码的代码的存储位置，测试代码目录用于指示测试代码的代码存储位置，Cobertura测试包的资源目录用于指示被测试代码测试过程中使用的Cobertura测试包的存储位置。因此基于maven标准目录结构创建的工程目录有利于测试包和代码的管理，以及有利于对测试包的复用。

102：将Cobertura测试包存储至工程目录中资源目录指定的存储位置中。其中Cobertura测试包是指Cobertura提供的用于对被测试代码进行测试的方法和类等。之所以使用Cobertura测试包是因为Cobertura测试包具有如下优点：

1)Cobertura的源码较容易理解，便于测试人员根据需要进行修改重构；

2)Cobertura支持Ant Task，且使得用户可以通过配置不同的参数属性，来获得预期的执行结果；

3)Cobertura提供了覆盖率指标检查任务，可以实现覆盖率的自动检查和判断。在代码测试过程中只需要更换新的被测试代码的代码，即可自动判断代码重构后是否满足单元测试代码覆盖率的要求，有利于测试的自动化；

4)Cobertura提供了多种目标任务来统计测试覆盖率，并且生成较美观易用的覆盖率测试报告，覆盖率测试报告用于指示代码覆盖率情况，通过其可直接定位到有问题的代码和未测试到的代码。

103：将所述被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使所述构建文件调用所述Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况。

在本发明实施例中，构建文件被预先构建，其默认命令可以是build.xml，build.xml定义一个唯一的项目(project元素)，每个项目下可以定义很多目标(target元素)，每个目标可以定义多个任务。在构建目标时必须调用所定义的任务，任务定义了Ant实际执行的命令。在执行命令时其可以调用Cobertura测试包将Ant工具和Cobertura工具结合，例如可以通过Ant工具将Cobertura工具集成到Eclipse中，得到可视化测试环境，如图3所示。

在该可视化测试环境中每个节点为构建文件中的一个目标，当检测到用户对某个节点的双击操作后，可以调用该节点所对应的目标来执行相应的命令以对被测试代码进行测试，如可以通过coverage-report目标得到被测试代码的代码覆盖率情况和利用test目标对待测试对象进行单元测试。其中代码覆盖率情况是指测试代码对被测试代码的代码的覆盖情况。

可以理解的是：Ant工具中的JUnit是一个JAVA单元测试框架，可以支持单元测试的管理和执行。当测试代码确定后，可以通过JUnit进行持久化管理并复用。因此进行代码测试时，只需要更新被测试代码的代码，然后运行测试代码即可实现单元测试。在此基础上再集成Cobertura每次运行单元测试时，便可同时得到代码覆盖率情况。因此对于每个被测试代码来说只需要将被测试代码的工程目录与预先创建的构建文件关联即可，无需对每个被测试代码基于Ant工具进行重新构建，从而提高测试的通用性。

在本发明实施例中，将被测试代码和测试代码的工程目录与预先创建的构建文件关联的一种方式是：在工程目录的config工程目录中添加外置属性文件build.properties，属性文件中每个变量通过相对路径的方式指向工程目录下相对应的子目录。即获取工程目录下每个子目录的相对路径，并将每个子目录的相对路径添加到预先创建的属性文件中，预先创建的属性文件中每个变量指向各自对应的每个子目录的相对路径。

然后在构建文件中使用project的XML标签作为构建文件中的根元素来定义这个项目。同时利用property file＝“build.properties”引用属性文件并将property的basedir设置为当前工程目录，这样被测试代码和测试代码的工程目录与构建文件关联上。

这里需要说明的一点是：相对路径是指由当前工程目录所在的路径与当前工程目录所依赖的其他目录的路径关系。在本发明实施例中，将当前工程目录所依赖的其他目录的路径关系表示为与当前工程根目录的相对路径时，无论任何被测试代码，只需要根据本发明中提供的maven标准目录结构来创建工程目录，其相对路径都是一样的，即可以直接运用本发明提供的构建文件进行代码覆盖率测试，而不需要每次都重建构建文件。

104：从被测试代码中选择需要测试的测试单元，并剔除被测试代码中无需测试的测试单元。在本发明实施例中，代码覆盖率＝已执行代码行数/参测代码总行数*100％。从代码覆盖率的计算方式可以看出，要提高代码覆盖率，可提高被测代码行数或减少参测代码总行数，因此为提高代码覆盖率，本发明实施例可以剔除被测试代码中无需测试的测试单元来减少参测代码总行数。

105：利用Mock工具模拟未完成的协同对象，其中协同对象为被测试代码运行时调用的对象，以辅助处理后的被测试代码正常运行。

例如假设被测试代码A在运行时需要调用协同对象B来执行相应的行为，这样被测试代码A才能正常运行，但是此时协同对象B还未完成开发，因此本发明实施例利用Mock工具模拟未完成的协同对象B，来模拟被测试代码调用协同对象B时协同对象B所执行的行为，以辅助被测试代码的正常运行。

106：获取处理后的被测试代码的测试代码，并运行构建文件和测试代码，得到测试结果，测试结果用于指示被测试代码的代码覆盖率情况和运行情况。其中运行情况为通过测试代码验证被测试代码是否正确实现所需功能的情况以及被测试代码是否能够正确运行的情况。

从上述技术方案可以看出，在测试每个被测试代码时，可以基于maven标准目录结构，创建被测试代码和测试代码的工程目录，然后将被测试代码使用的Cobertura测试包存储至工程目录中资源目录指定的存储位置中，并将被测试代码和测试代码的工程目录与预先创建的构建文件关联，使得构建文件可以调用Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况，这样对于每个被测试代码来说，只需要基于maven标准目录结构创建工程目录，基于工程目录来存储所用的Cobertura测试包并关联构建文件来获得代码覆盖率情况，从而无需针对每个被测试代码来重新进行Ant构建过程，提高测试的通用性。

在本发明实施例中，构建文件的预先构建过程如图4所示，可以包括以下步骤：

201：使用mkdir命令创建构建文件的临时目录，临时目录用于提供测试过程生成的临时文件的目录。其中临时文件是在在执行代码覆盖率测试的过程中生成的文件，如下述调用Ant的javac任务对被测试代码和测试代码进行编译后得到的class文件以及插桩后的class文件等。在本发明实施例中临时目录可以为工程目录下的一个子目录，如上述图2所示工程目录下的build目录。

202：创建构建文件下的complie目标，complie目标用于调用Ant的javac任务对被测试代码和测试代码进行编译。其中javac任务允许设置所有的编译器选项，如源代码目录、目标目录以及编译所依赖的其它资源等。在调用javac任务对被测试代码和测试代码进行编译后得到后缀为.class的文件，将.class的文件存储在临时目录下。

203：创建构建文件下的instrument目标，以调用Cobertura的instrument任务，对被测试代码中的被测java程序编译所得class文件进行插桩。其中插桩是一种成熟的工具，它是在被测程序中插入探针，然后通过探针的执行来获得程序运行时的一些数据。在这一步中对上一步骤得到的.class文件进行插桩，为了方便管理和使用，把插桩后的文件保存到临时目录的另一个目录下。

204：创建构建文件下的test目标以调用Ant的JUnit任务对被测试代码进行单元测试，在进行单元测试时通过test目标的name属性指定将要运行的测试代码的名称。

由于同一个项目有多个不同的测试代码，所以在调用JUnit任务时，通过name这个属性来说明现在要执行的测试代码是哪个(即指定测试代码的名称)。在调用JUnit任务进行单元测试的同时Cobertura将自动在后台统计每一行代码的执行情况，并将统计信息写入cobertura.ser文件，以便于得到代码覆盖率情况。

205：创建构建文件下的coverage-report目标，coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成测试结果中的代码覆盖率测试报告，其中代码覆盖率测试报告用于指示代码覆盖率情况。cobertura-report任务可以从上述cobertura.ser文件获取数据信息生成测试报告，并通过cobertura-report任务中的format参数来设置测试报告的类型，例如将测试报告设置为XML(eXtensible Markup Language，可扩展标记语言)类型或者HTML(HyperText Markup Language，超文本标记语言)类型。

在本发明实施例中，Cobertura可以提供一个接口如上述图2中的reports子目录，在点击该reports子目录后可以为用户展示被测试代码的测试覆盖详情。

206：创建构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务。在本发明实施例中代码覆盖率指标检查任务指定一衡量代码覆盖率的指标，以自动检查代码覆盖率情况。这样当代码修改或重构时，通过代码覆盖率指标检查任务可自动判断对代码的修改是否引起了测试质量的下降。

207：创建构建文件下的clean目标以调用Ant的delete命令来删除临时目录下的临时文件，以消除单元测试时临时文件对单元测试的影响。

基于上述构建文件的构建过程，本发明实施例提供的代码测试方法中步骤104的执行过程如图5所示，可以包括以下步骤：

1041：通过第一正则表达式在instrument目标中选择被测试代码中需要测试的测试单元，并剔除被测试代码中无需测试的测试单元。其中测试单元包括类和包。

在本发明实施例中，第一正则表达式用于指示哪些测试单元被列入单元测试的统计范围，哪些测试单元被剔除在统计范围之外，通过第一正则表达式的选取可以减少参测代码总行数，因此在被覆盖到的代码数量不变的基础上，整个代码覆盖率会较以前提高。

例如：<include name＝”**/.*class”>是利用第一正则表达式指定哪些需要被测试；<exclude name＝”**/*Test.class”>是利用第一正则表达式指定哪些需要被剔除。对于不同的被测试代码其第一正则表达式不同，本发明实施例不再对每个被测试代码的第一正则表达式进行说明。

在本发明实施例中通过修改Cobertura的源码，使Cobertura支持对类中方法的过滤。主要原则是提取需要过滤的方法的特征并据此设定判定条件，当满足过滤条件时返回对应的状态标识。最后根据状态标识将不同方法添加到需要过滤的方法的列表中进行剔除，具体过程如1042至1044。

1042：对被测试代码中的方法进行解析，得到方法的参数和返回类型。以基于方法的参数和返回类型来判断是否哪些需要剔除。

例如通过args＝Type.getArgumentTypes(methodDscriptor)和rt＝Type.getReturnType(methodDscriptor)来解析并取得方法的参数和返回类型。

1043：基于方法的参数和返回类型，将被测试代码中的set方法、get方法和init方法剔除。

在Cobertura中set方法均以字符“set”开头，不含有任何参数，且返回类型为void，因此可得到基于条件：if(methodName.startsWith(“set”)&&args.length＝＝1&&rt.equals(Type.VOID_TYPE))来直接过滤类中的set方法。

在Cobertura中get方法均以字符“get”开头，含有一个参数且返回类型为void，因此可得到条件：if((methodName.startWith(“get”)&&args.length＝＝0&&！rt.equals(Type.VOID_TYPE))来直接过滤类中的get方法。

同样当调用javac任务编译时，编译器会为每一个java类添加一个默认的无参构造方法。这个方法无需进行测试，因此也可以将其从覆盖率统计的范围中剔除。这个构造方法名称为“<init>”，无返回类型，由此可得到条件：if((methodName.equals(“<init>”)&&(args.length＝＝0))来剔除init方法。

1044：将instrument目标使用的方法和被测试代码中除set方法、get方法和init方法后剩余的每个方法分别与判定条件进行比较，得到比较结果，其中判定条件通过第二正则表达式表示，对于不同的被测试代码其第二正则表达式不同，本发明实施例不再对每个被测试代码的第二正则表达式进行说明。

例如可以通过调用oro-2.0.8.jar提供的正则表达式匹配算法来选取instrument目标使用的方法和被测试代码中除set方法、get方法和init方法后剩余的每个方法。具体如下：

method＝method.replace(‘\\’,’/’)；

method＝method.replace(‘/’,’.’)；

if(RegexUtil.matches(ignoreMethodAnnotations,methodName))

其中前两个语句是基于第二正则表达式的规则，将传入参数中的一些特殊字符进行替换；第三个语句的作用是调用oro-2.0.8.jar提供的正则表达式的算法确认当前被测试的方法是否和指定的要剔除的测试方法相匹配。

当比较结果表明当前测试的方法和指定的要剔除的测试方法相匹配时，表明方法的参数信息满足判定条件时，将满足判定条件的方法剔除；当比较结果表明当前测试的方法和指定的要剔除的测试方法不匹配时，表明方法的参数信息不满足判定条件时，保留不满足判定条件的方法。

1045：当比较结果表明方法的参数信息满足判定条件时，将满足判定条件的方法剔除。

此外，本发明实施例提供的代码测试方法中步骤105的执行过程如图6所示，可以包括以下步骤：

1051：导入与JMock工具相关的jar包，以使测试代码调用JMock工具封装的方法。

1052：使用runwith来注释JMock工具内的测试运行器，测试运行器用于管理协同对象中的测试类，其能够管理测试类的生命周期，包括创建类、调用测试以及搜集结果等。

1053：创建Mockery的context对象和Mock对象。

1054：通过contex创建Mock对象的实例，实例为利用Mock工具模拟的协同对象。

1055：创建Exception对象来模拟实例的协同行为，协同行为用于使处理后的被测试代码可正常运行。协同行为是为mock对象设置期望的行为，用于在被测试代码运行时辅助被测试代码，使得被测试代码可以正常运行。

如下所示语句给出利用Mock工具模拟未完成的协同对象的过程，其含义是：当参数为“argument-constraints”，并且对象的状态为state-name时，mock对象的方法(method)以指定的顺序被调用一次，并触发对应动作action(协同行为)，然后设置对象状态为new-state-name；

invocation-count(mock-object).method(argument-constraints)；//约束mock对象的调用次数以及约束method方法的参数；

inSequence(sequence-name)；//约束调用顺序；

when(state-machine.is(state-name))；//当mockery的状态为指定的state-name的时候触发；

will(action)；//方法触发的动作；

then(state-machine.is(new-state-name))；//方法触发后设置mockery的状态

与上述方法实施例相对应，本发明实施例还提供一种代码测试装置，其结构示意图如图7所示，可以包括：创建单元11、存储单元12、关联单元13、获取单元14、模拟单元15和测试单元16。其中，创建单元11，用于基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使被测试代码和测试代码的工程目录的结构为maven标准目录结构。在本发明实施例中，maven是目前常用的一种项目管理工具，其是基于项目对象模型并通过一段描述信息来管理项目的构建、报告和文档的软件项目管理工具。在众多工程师大量实践中得出一maven目录结构约定，该maven目录结构约定规定了较为合理的maven标准目录结构，因此在本发明实施例中基于maven标准目录结构，创建被测试代码和测试代码的工程目录。

其中被测试代码和测试代码的工程目录可以如图2所示，其示出了被测试代码的被测试代码目录和测试代码的测试代码目录以及使用的Cobertura测试包的资源目录，被测试代码目录用于指示被测试代码的存储位置，测试代码目录用于指示测试代码的存储位置，Cobertura测试包的资源目录用于指示被测试代码测试过程中使用的Cobertura测试包的存储位置。因此基于maven标准目录结构创建的工程目录有利于测试包和代码的管理，以及有利于对测试包的复用。

存储单元12，用于将Cobertura测试包存储至工程目录中资源目录指定的存储位置中。其中Cobertura测试包是指Cobertura提供的用于对被测试代码进行测试的方法和类等。之所以使用Cobertura测试包是因为Cobertura测试包具有如下优点：

1)Cobertura的源码较容易理解，便于测试人员根据需要进行修改重构；

2)Cobertura支持Ant Task，且使得用户可以通过配置不同的参数属性，来获得预期的执行结果；

3)Cobertura提供了覆盖率指标检查任务，可以实现覆盖率的自动检查和判断。在代码测试过程中只需要更换新的被测试代码的代码，即可自动判断代码重构后是否满足单元测试代码覆盖率的要求，有利于测试的自动化；

4)Cobertura提供了多种目标任务来统计测试覆盖率，并且生成较美观易用的覆盖率测试报告，覆盖率测试报告用于指示代码覆盖率情况，通过其可直接定位到有问题的代码和未测试到的代码。

关联单元13，用于将被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使构建文件调用Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到被测试代码的代码覆盖率情况。

在本发明实施例中，构建文件被预先构建，其默认命令可以是build.xml，build.xml定义一个唯一的项目(project元素)，每个项目下可以定义很多目标(target元素)，每个目标可以定义多个任务。在构建目标时必须调用所定义的任务，任务定义了Ant实际执行的命令。在执行命令时其可以调用Cobertura测试包将Ant工具和Cobertura工具结合，例如可以通过Ant工具将Cobertura工具集成到Eclipse中，得到可视化测试环境，如图3所示。

在该可视化测试环境中每个节点为构建文件中的一个目标，当检测到用户对某个节点的双击操作后，可以调用该节点所对应的目标来执行相应的命令以对被测试代码进行测试，如可以通过coverage-report目标得到被测试代码的代码覆盖率情况和利用test目标对待测试对象进行单元测试。其中代码覆盖率情况是指测试代码对被测试代码的代码的覆盖情况。

可以理解的是：Ant工具中的JUnit是一个JAVA单元测试框架，可以支持单元测试的管理和执行。当测试代码确定后，可以通过JUnit进行持久化管理并复用。因此进行代码测试时，只需要更新被测试代码的代码，然后运行测试代码即可实现单元测试。在此基础上再集成Cobertura每次运行单元测试时，便可同时得到代码覆盖率情况。因此对于每个被测试代码来说只需要将被测试代码的工程目录与预先创建的构建文件关联即可，无需对每个被测试代码基于Ant工具进行重新构建，从而提高测试的通用性。

在本发明实施例中，将被测试代码和测试代码的工程目录与预先创建的构建文件关联的一种方式是：在工程目录的config工程目录中添加外置属性文件build.properties，属性文件中每个变量通过相对路径的方式指向工程目录下相对应的子目录。即获取工程目录下每个子目录的相对路径，并将每个子目录的相对路径添加到预先创建的属性文件中，预先创建的属性文件中每个变量指向各自对应的每个子目录的相对路径。

然后在构建文件中使用project的XML标签作为构建文件中的根元素来定义这个项目。同时利用property file＝“build.properties”引用属性文件并将property的basedir设置为当前工程目录，这样被测试代码和测试代码的工程目录与构建文件关联上。

这里需要说明的一点是：相对路径是指由当前工程目录所在的路径与当前工程目录所依赖的其他目录的路径关系。在本发明实施例中，将当前工程目录所依赖的其他目录的路径关系表示为与当前工程根目录的相对路径时，无论任何被测试代码，只需要根据本发明中提供的maven标准目录结构来创建工程目录，其相对路径都是一样的，即可以直接运用本发明提供的构建文件进行代码覆盖率测试，而不需要每次都重建构建文件。

获取单元14，用于从被测试代码中选择需要测试的测试单元，并剔除被测试代码中无需测试的测试单元。在本发明实施例中，代码覆盖率＝已执行代码行数/参测代码总行数*100％。从代码覆盖率的计算方式可以看出，要提高代码覆盖率，可提高被测代码行数或减少参测代码总行数，因此为提高代码覆盖率，本发明实施例可以剔除被测试代码中无需测试的测试单元来减少参测代码总行数。

模拟单元15，用于利用Mock工具模拟未完成的协同对象，协同对象为被测试代码运行时所调用的对象，以辅助使处理后的被测试代码正常运行。例如假设被测试代码A在运行时需要调用协同对象B来执行相应的行为，这样被测试代码A才能正常运行，但是此时协同对象B还未完成开发，因此本发明实施例利用Mock工具模拟未完成的协同对象B，来模拟被测试代码调用协同对象B时协同对象B所执行的行为，以辅助被测试代码的正常运行。

测试单元16，用于获取处理后的被测试代码的测试代码，并运行构建文件和测试代码，得到测试结果，测试结果用于指示被测试代码的代码覆盖率情况和运行情况。

从上述技术方案可以看出，在测试每个被测试代码时，可以基于maven标准目录结构，创建被测试代码和测试代码的工程目录，然后将被测试代码使用的Cobertura测试包存储至工程目录中资源目录指定的存储位置中，并将被测试代码和测试代码的工程目录与预先创建的构建文件关联，使得构建文件可以调用Cobertura测试包将Ant工具和Cobertura工具结合来对被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况，这样对于每个被测试代码来说，只需要基于maven标准目录结构创建工程目录，基于工程目录来存储所用的Cobertura测试包并关联构建文件来获得代码覆盖率情况，从而无需针对每个被测试代码来重新进行Ant构建过程，提高测试的通用性。

在本发明实施例中，上述代码测试装置还可以包括：构建单元10，用于预先创建构建文件，如图8所示。其中构建单元的结构示意图如图9所示，可以包括：第一创建子单元100、第二创建子单元101、第三创建子单元102、第四创建子单元103、第五创建子单元104、第六创建子单元105和第七创建子单元106，其中，

第一创建子单元100，用于使用mkdir命令创建构建文件的临时目录，临时目录用于提供测试过程生成的临时文件的目录。其中临时文件是在在执行代码覆盖率测试的过程中生成的文件，如下述调用Ant的javac任务对被测试对象和测试代码进行编译后得到的class文件以及插桩后的class文件等。在本发明实施例中临时目录可以为工程目录下的一个子目录，如上述图2所示工程目录下的build目录。

第二创建子单元101，用于创建构建文件下的complie目标，complie目标用于调用Ant的javac任务对被测试代码和测试代码进行编译。其中javac任务允许设置所有的编译器选项，如源代码目录、目标目录以及编译所依赖的其它资源等。在调用javac任务对被测试代码和测试代码进行编译后得到后缀为.class的文件，将.class的文件存储在临时目录下。

第三创建子单元102，用于创建构建文件下的instrument目标，以调用Cobertura的instrument任务，对被测试代码中的被测java程序编译所得class文件进行插桩。其中插桩是一种成熟的工具，它是在被测程序中插入探针，然后通过探针的执行来获得程序运行时的一些数据。在这一步中对上一步骤得到的.class文件进行插桩，为了方便管理和使用，把插桩后的文件保存到临时目录的另一个目录下。

第四创建子单元103，用于创建构建文件下的test目标以调用Ant的JUnit任务对被测试代码进行单元测试，在进行单元测试时通过test目标的name属性指定将要运行的测试代码的名称。

由于同一个项目有多个不同的测试代码，所以在调用JUnit任务时，通过name这个属性来说明现在要执行的测试代码是哪个(即指定测试代码的名称)。在调用JUnit任务进行单元测试的同时Cobertura将自动在后台统计每一行代码的执行情况，并将统计信息写入cobertura.ser文件，以便于得到代码覆盖率情况。

第五创建子单元104，用于创建构建文件下的coverage-report目标，coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成测试结果中的代码覆盖率测试报告，其中代码覆盖率测试报告用于指示代码覆盖率情况。cobertura-report任务可以从上述cobertura.ser文件获取数据信息生成测试报告，并通过cobertura-report任务中的format参数来设置测试报告的类型，例如将测试报告设置为XML(eXtensible Markup Language，可扩展标记语言)类型或者HTML(HyperText Markup Language，超文本标记语言)类型。

在本发明实施例中，Cobertura可以提供一个接口如上述图2中的reports子目录，在点击该reports子目录后可以为用户展示被测试代码的测试覆盖详情。

第六创建子单元105，用于创建构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务。在本发明实施例中代码覆盖率指标检查任务指定一衡量代码覆盖率的指标，以自动检查代码覆盖率情况。这样当代码修改或重构时，通过代码覆盖率指标检查任务可自动判断对代码的修改是否引起了测试质量的下降。

第七创建子单元106，用于创建构建文件下的clean目标以调用Ant的delete命令来删除临时目录下的临时文件。

在本发明实施例中，获取单元14可以通过第一正则表达式在instrument目标中选择被测试代码中需要测试的测试单元，并剔除被测试代码中无需测试的测试单元，其中测试单元包括类和包。相应的获取单元14的结构示意图如图10所示，可以包括：选择子单元141、解析子单元142、第一剔除子单元143、比较子单元144和第二剔除子单元145。其中，

选择子单元141，用于从被测试代码中选择需要测试的测试单元。在本发明实施例中，第一正则表达式用于指示哪些测试单元被列入单元测试的统计范围，哪些测试单元被剔除在统计范围之外，通过第一正则表达式的选取可以减少参测代码总行数，因此在被覆盖到的代码数量不变的基础上，整个代码覆盖率会较以前提高。

例如：<include name＝”**/.*class”>是利用第一正则表达式指定哪些需要被测试；<exclude name＝”**/*Test.class”>是利用第一正则表达式指定哪些需要被剔除。对于不同的被测试代码其第一正则表达式不同，本发明实施例不再对每个被测试代码的第一正则表达式进行说明。

解析子单元142，用于对被测试代码中的装置进行解析，得到装置的参数和返回类型。例如通过args＝Type.getArgumentTypes(methodDscriptor)和rt＝Type.getReturnType(methodDscriptor)来解析并取得方法的参数和返回类型。

第一剔除子单元143，用于基于装置的参数和返回类型，将被测试代码中的set装置、get装置和init装置剔除。

在Cobertura中set方法均以字符“set”开头，不含有任何参数，且返回类型为void，因此可得到基于条件：if(methodName.startsWith(“set”)&&args.length＝＝1&&rt.equals(Type.VOID_TYPE))来直接过滤类中的set方法。

在Cobertura中get方法均以字符“get”开头，含有一个参数且返回类型为void，因此可得到条件：if((methodName.startWith(“get”)&&args.length＝＝0&&！rt.equals(Type.VOID_TYPE))来直接过滤类中的get方法。

同样当调用javac任务编译时，编译器会为每一个java类添加一个默认的无参构造方法。这个方法无需进行测试，因此也可以将其从覆盖率统计的范围中剔除。这个构造方法名称为“<init>”，无返回类型，由此可得到条件：if((methodName.equals(“<init>”)&&(args.length＝＝0))来剔除init方法。

比较子单元144，用于将instrument目标使用的装置和被测试代码中除set装置、get装置和init装置后剩余的每个装置分别与判定条件进行比较，得到比较结果，判定条件通过第二正则表达式表示，对于不同的被测试代码其第二正则表达式不同，本发明实施例不再对每个被测试代码的第二正则表达式进行说明。

例如可以通过调用oro-2.0.8.jar提供的正则表达式匹配算法来选取instrument目标使用的方法和被测试代码中除set方法、get方法和init方法后剩余的每个方法。具体如下：

method＝method.replace(‘\\’,’/’)；

method＝method.replace(‘/’,’.’)；

if(RegexUtil.matches(ignoreMethodAnnotations,methodName))

其中前两个语句是基于第二正则表达式的规则，将传入参数中的一些特殊字符进行替换；第三个语句的作用是调用oro-2.0.8.jar提供的正则表达式的算法确认当前被测试的方法是否和指定的要剔除的测试方法相匹配。

当比较结果表明当前测试的方法和指定的要剔除的测试方法相匹配时，表明方法的参数信息满足判定条件时，将满足判定条件的方法剔除；当比较结果表明当前测试的方法和指定的要剔除的测试方法不匹配时，表明方法的参数信息不满足判定条件时，保留不满足判定条件的方法。

第二剔除子单元145，用于当比较结果表明装置的参数信息满足判定条件时，将满足判定条件的装置剔除。

此外本发明实施例提供的代码测试装置中模拟单元15的结构示意图如图11所示，可以包括：导入子单元151、注释子单元152、第八创建子单元153、第九创建子单元154和第十创建子单元155。其中，

导入子单元151，用于导入与JMock工具相关的jar包，以使测试代码调用JMock工具封装的装置。

注释子单元152，用于使用runwith来注释JMock工具内的测试运行器，测试运行器用于管理协同对象中的测试类，其能够管理测试类的生命周期，包括创建类、调用测试以及搜集结果等。

第八创建子单元153，用于创建Mockery的context对象和Mock对象。

第九创建子单元154，用于通过contex创建Mock对象的实例，实例为利用Mock工具模拟的协同对象。

第十创建子单元155，用于创建Exception对象来模拟实例的协同行为，协同行为用于使处理后的被测试代码可正常运行。协同行为是为mock对象设置期望的行为，用于在被测试代码运行时辅助被测试代码，使得被测试代码可以正常运行。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种代码测试方法，其特征在于，所述方法包括：

基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使所述被测试代码和测试代码的工程目录的结构为所述maven标准目录结构；

将Cobertura测试包存储至所述工程目录中资源目录指定的存储位置中；

将所述被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使所述构建文件调用所述Cobertura测试包将Ant工具和Cobertura工具结合来对所述被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况；

从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

利用Mock工具模拟未完成的协同对象，所述协同对象为所述被测试代码运行时所调用的对象，以辅助使处理后的所述被测试代码正常运行；

获取处理后的所述被测试代码的测试代码，并运行所述构建文件和所述测试代码，得到测试结果，所述测试结果用于指示所述被测试代码的代码覆盖率情况和运行情况。

2.根据权利要求1所述的方法，其特征在于，所述构建文件的预先创建包括：

使用mkdir命令创建所述构建文件的临时目录，所述临时目录用于提供测试过程生成的临时文件的目录；

创建所述构建文件下的complie目标，所述complie目标用于调用Ant的javac任务对所述被测试代码和所述测试代码进行编译；

创建所述构建文件下的instrument目标，以调用Cobertura的instrument任务，对所述被测试代码中的被测java程序编译所得class文件进行插桩；

创建所述构建文件下的test目标以调用Ant的JUnit任务对所述被测试代码进行单元测试，在进行单元测试时通过所述test目标的name属性指定将要运行的所述测试代码的名称；

创建所述构建文件下的coverage-report目标，所述coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成所述测试结果中的代码覆盖率测试报告；

创建所述构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务；

创建所述构建文件下的clean目标以调用Ant的delete命令来删除所述临时目录下的所述临时文件。

3.根据权利要求2所述的方法，其特征在于，从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元，包括：

通过第一正则表达式在所述instrument目标中选择所述被测试代码中需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

所述测试单元包括类和包。

4.根据权利要求3所述的方法，其特征在于，剔除所述被测试代码中无需测试的测试单元，包括：

对所述被测试代码中的方法进行解析，得到所述方法的参数和返回类型；

基于所述方法的参数和返回类型，将所述被测试代码中的set方法、get方法和init方法剔除；

将所述instrument目标使用的方法和所述被测试代码中除set方法、get方法和init方法后剩余的每个方法分别与判定条件进行比较，得到比较结果，所述判定条件通过第二正则表达式表示；

当所述比较结果表明所述方法的参数信息满足所述判定条件时，将满足所述判定条件的方法剔除。

5.根据权利要求1所述的方法，其特征在于，所述利用Mock工具模拟未完成的协同对象，包括：

导入与JMock工具相关的jar包，以使所述测试代码调用JMock工具封装的方法；

使用runwith来注释所述JMock工具内的测试运行器，所述测试运行器用于管理所述协同对象中的测试类；

创建Mockery的context对象和Mock对象；

通过contex创建Mock对象的实例，所述实例为利用Mock工具模拟的所述协同对象；

创建Exception对象来模拟所述实例的协同行为，所述协同行为用于使处理后的所述被测试代码可正常运行。

6.一种代码测试装置，其特征在于，所述装置包括：

创建单元，用于基于maven标准目录结构，创建被测试代码和测试代码的工程目录，以使所述被测试代码和测试代码的工程目录的结构为所述maven标准目录结构；

存储单元，用于将Cobertura测试包存储至所述工程目录中资源目录指定的存储位置中；

关联单元，用于将所述被测试代码和测试代码的工程目录与预先创建的构建文件关联，以使所述构建文件调用所述Cobertura测试包将Ant工具和Cobertura工具结合来对所述被测试代码进行单元测试并得到所述被测试代码的代码覆盖率情况；

获取单元，用于从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

模拟单元，用于利用Mock工具模拟未完成的协同对象，所述协同对象为所述被测试代码运行时所调用的对象，以辅助使处理后的所述被测试代码正常运行；

测试单元，用于获取处理后的所述被测试代码的测试代码，并运行所述构建文件和所述测试代码，得到测试结果，所述测试结果用于指示所述被测试代码的代码覆盖率情况和运行情况。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括构建单元，用于预先创建所述构建文件；所述构建单元包括：

第一创建子单元，用于使用mkdir命令创建所述构建文件的临时目录，所述临时目录用于提供测试过程生成的临时文件的目录；

第二创建子单元，用于创建所述构建文件下的complie目标，所述complie目标用于调用Ant的javac任务对所述被测试代码和所述测试代码进行编译；

第三创建子单元，用于创建所述构建文件下的instrument目标，以调用Cobertura的instrument任务，对所述被测试代码中的被测java程序编译所得class文件进行插桩；

第四创建子单元，用于创建所述构建文件下的test目标以调用Ant的JUnit任务对所述被测试代码进行单元测试，在进行单元测试时通过所述test目标的name属性指定将要运行的所述测试代码的名称；

第五创建子单元，用于创建所述构建文件下的coverage-report目标，所述coverage-report目标用于调用Cobertura提供的cobertura-report任务来生成所述测试结果中的代码覆盖率测试报告；

第六创建子单元，用于创建所述构建文件下的coverage-check目标以调用Cobertura的代码覆盖率指标检查任务；

第七创建子单元，用于创建所述构建文件下的clean目标以调用Ant的delete命令来删除所述临时目录下的所述临时文件。

8.根据权利要求7所述的装置，其特征在于，所述获取单元从所述被测试代码中选择需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元，包括：通过第一正则表达式在所述instrument目标中选择所述被测试代码中需要测试的测试单元，并剔除所述被测试代码中无需测试的测试单元；

所述测试单元包括类和包。

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

选择子单元，用于从所述被测试代码中选择需要测试的测试单元；

解析子单元，用于对所述被测试代码中的装置进行解析，得到所述装置的参数和返回类型；

第一剔除子单元，用于基于所述装置的参数和返回类型，将所述被测试代码中的set装置、get装置和init装置剔除；

比较子单元，用于将所述instrument目标使用的装置和所述被测试代码中除set装置、get装置和init装置后剩余的每个装置分别与判定条件进行比较，得到比较结果，所述判定条件通过第二正则表达式表示；

第二剔除子单元，用于当所述比较结果表明所述装置的参数信息满足所述判定条件时，将满足所述判定条件的装置剔除。

10.根据权利要求1所述的装置，其特征在于，所述模拟单元包括：

导入子单元，用于导入与JMock工具相关的jar包，以使所述测试代码调用JMock工具封装的装置；

注释子单元，用于使用runwith来注释所述JMock工具内的测试运行器，所述测试运行器用于管理所述协同对象中的测试类；

第八创建子单元，用于创建Mockery的context对象和Mock对象；

第九创建子单元，用于通过contex创建Mock对象的实例，所述实例为利用Mock工具模拟的所述协同对象；

第十创建子单元，用于创建Exception对象来模拟所述实例的协同行为，所述协同行为用于使处理后的所述被测试代码可正常运行。