CN104809071B - 一种代码测试方法及装置 - Google Patents
一种代码测试方法及装置 Download PDFInfo
- Publication number
- CN104809071B CN104809071B CN201510246190.XA CN201510246190A CN104809071B CN 104809071 B CN104809071 B CN 104809071B CN 201510246190 A CN201510246190 A CN 201510246190A CN 104809071 B CN104809071 B CN 104809071B
- Authority
- CN
- China
- Prior art keywords
- code
- test
- tested
- creating
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000010998 test method Methods 0.000 title abstract description 13
- 238000012360 testing method Methods 0.000 claims abstract description 381
- 238000000034 method Methods 0.000 claims description 148
- 238000010276 construction Methods 0.000 claims description 53
- 230000014509 gene expression Effects 0.000 claims description 34
- 230000008569 process Effects 0.000 claims description 27
- 230000011273 social behavior Effects 0.000 claims description 15
- 238000004088 simulation Methods 0.000 claims description 5
- 230000008676 import Effects 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims description 2
- 230000000875 corresponding effect Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 11
- 239000011800 void material Substances 0.000 description 8
- 230000006399 behavior Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000000007 visual effect Effects 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 239000000523 sample Substances 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000013522 software testing Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
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 ObjectModel)、一组标准集合、一个项目生命周期(Project Lifecycle)、一个依赖管理系统(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 MarkupLanguage，可扩展标记语言)类型或者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(eXtensibleMarkup 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对象来模拟所述实例的协同行为，所述协同行为用于使处理后的所述被测试代码可正常运行。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510246190.XA CN104809071B (zh) | 2015-05-14 | 2015-05-14 | 一种代码测试方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510246190.XA CN104809071B (zh) | 2015-05-14 | 2015-05-14 | 一种代码测试方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104809071A CN104809071A (zh) | 2015-07-29 |
| CN104809071B true CN104809071B (zh) | 2017-08-11 |
Family
ID=53693913
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510246190.XA Active CN104809071B (zh) | 2015-05-14 | 2015-05-14 | 一种代码测试方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104809071B (zh) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106484606B (zh) * | 2015-09-01 | 2019-07-26 | 阿里巴巴集团控股有限公司 | 一种代码提交方法和设备 |
| CN105630671B (zh) * | 2015-12-16 | 2019-03-08 | 北京奇虎科技有限公司 | 代码覆盖率报告的生成方法及装置 |
| CN106407313B (zh) * | 2016-08-30 | 2020-01-21 | 华为技术有限公司 | 一种目录过滤方法及设备 |
| CN108228229B (zh) * | 2016-12-19 | 2021-04-13 | 深圳业拓讯通信科技有限公司 | 一种Maven依赖的管理方法以及系统 |
| CN108415821A (zh) * | 2017-02-09 | 2018-08-17 | 腾讯科技（深圳）有限公司 | 测试报告的生成方法及装置 |
| CN108491193A (zh) * | 2018-04-11 | 2018-09-04 | 厦门海迈科技股份有限公司 | Eclipse RCP产品构建方法、装置、终端及介质 |
| CN108647107A (zh) * | 2018-05-14 | 2018-10-12 | 浪潮软件集团有限公司 | 一种微服务开发框架的统一异常处理方法 |
| CN108984393A (zh) * | 2018-06-12 | 2018-12-11 | 苏宁易购集团股份有限公司 | 一种单元测试代码自动生成方法及装置 |
| CN109460357B (zh) * | 2018-10-19 | 2021-10-29 | 北京新能源汽车股份有限公司 | 一种代码覆盖率的测试方法、装置和设备 |
| CN109344081B (zh) * | 2018-10-31 | 2022-03-11 | 杭州安恒信息技术股份有限公司 | 基于标签脚本实现自动化覆盖率统计的方法及装置 |
| CN109669914A (zh) * | 2018-11-15 | 2019-04-23 | 深圳壹账通智能科技有限公司 | 项目文件存储方法、装置、设备及计算机可读存储介质 |
| CN109542789B (zh) * | 2018-11-26 | 2022-03-25 | 泰康保险集团股份有限公司 | 一种代码覆盖率统计方法及装置 |
| CN110399132B (zh) * | 2019-06-18 | 2023-12-22 | 平安科技（深圳）有限公司 | 项目代码的维护方法、装置、计算机设备和存储介质 |
| CN113760736A (zh) * | 2021-02-08 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | 一种测试方法、装置和系统 |
| CN113377677B (zh) * | 2021-07-08 | 2024-06-28 | 中国工商银行股份有限公司 | 一种单元测试方法及装置 |
| CN113806219B (zh) * | 2021-08-23 | 2024-06-11 | 北京达佳互联信息技术有限公司 | 测试结果确定方法、装置、电子设备及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103761184A (zh) * | 2013-12-31 | 2014-04-30 | 华为技术有限公司 | 程序的代码段测试方法、装置和系统 |
| CN103885873A (zh) * | 2012-12-20 | 2014-06-25 | 上海明想电子科技有限公司 | 一种自动化集成测试的方法 |
| US8813031B2 (en) * | 2012-03-02 | 2014-08-19 | Oracle International Corporation | System and method for automatically resolving dependencies of Java Archive files for use with Maven |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100131930A1 (en) * | 2008-11-21 | 2010-05-27 | International Business Machines Corporation | Selective Code Coverage Instrumentation |
-
2015
- 2015-05-14 CN CN201510246190.XA patent/CN104809071B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8813031B2 (en) * | 2012-03-02 | 2014-08-19 | Oracle International Corporation | System and method for automatically resolving dependencies of Java Archive files for use with Maven |
| CN103885873A (zh) * | 2012-12-20 | 2014-06-25 | 上海明想电子科技有限公司 | 一种自动化集成测试的方法 |
| CN103761184A (zh) * | 2013-12-31 | 2014-04-30 | 华为技术有限公司 | 程序的代码段测试方法、装置和系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104809071A (zh) | 2015-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104809071B (zh) | 一种代码测试方法及装置 | |
| Xiao et al. | Precise identification of problems for structural test generation | |
| Nguyen et al. | An observe-model-exercise paradigm to test event-driven systems with undetermined input spaces | |
| US20120110560A1 (en) | Data type provider for a web semantic store | |
| Sarma et al. | Model-based testing in industry: a case study with two MBT tools | |
| CN112395184A (zh) | 一种信息获取方法、设备和计算机存储介质 | |
| US20120110548A1 (en) | Data type provider for an operating system instrumentation store | |
| Xu et al. | Testing aspect‐oriented programs with finite state machines | |
| Wang et al. | Dynamic fan-in and fan-out metrics for program comprehension | |
| CN109508203A (zh) | 版本一致性确定方法、装置及系统 | |
| Bruntink | Testability of object-oriented systems: a metrics-based approach | |
| Satrijandi et al. | Efficiency measurement of Java Android code | |
| Khan et al. | Software Testability in Requirement Phase: A Review | |
| Potuzak et al. | Interface-based semi-automated testing of software components | |
| Lemos et al. | Visualization, analysis, and testing of Java and Aspectj programs with multi-level system graphs | |
| Chirila et al. | Towards a software quality assessment model based on open-source statical code analyzers | |
| US9471788B2 (en) | Evaluation of software applications | |
| US20230221975A1 (en) | Methods, systems, and computer readable media for customizing data plane pipeline processing using berkeley packet filter (bpf) hook entry points | |
| Zhao et al. | Developing analysis and testing plug‐ins for modern IDEs: an experience report | |
| Huajie et al. | An Instrumentation Tool for Program Dynamic Analysis in Java | |
| Joseph et al. | A Software Code Complexity Framework; Based on an Empirical Analysis of Software Cognitive Complexity Metrics using an Improved Merged Weighted Complexity Measure. | |
| Dawes et al. | Analysis Tools for the VyPR Performance Analysis Framework for Python | |
| de Boer et al. | Run-time verification of black-box components using behavioral specifications: An experience report on tool development | |
| Chauhan et al. | Evaluation Of Metrics And Assessment Of Quality Of Object Oriented Software | |
| Paiva et al. | Automated Specification-based Testing of Interactive Components with AsmL. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| EXSB | Decision made by sipo to initiate substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |