CN107145437A - 一种java注解测试方法及装置 - Google Patents

Abstract

本申请公开了一种java注解测试方法及装置。一种java注解测试方法包括：接收测试入口参数，根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；利用java拦截器机制，执行所获取到的注解逻辑；根据所述测试期望信息得到测试结果。与现有技术相比，本申请方案只需一个通用的测试模板，通过修改少量的测试入口参数，就可以实现对各类接口或方法注解的自动测试，而且测试的内容可以同时涵盖对注解自身逻辑正确的校验以及对方法或接口是否使用了正确注解的校验，从而有效地提升了测试效率，并且降低测试所需的时间人力成本。

Description

一种java注解测试方法及装置

技术领域

本申请涉及测试技术领域，尤其涉及一种java注解测试方法及装置。

背景技术

Annotation(注解)是JDK1.5及以后版本引入的一种特性。与类、接口、枚举属于同一层次。它可以声明在包、类、字段、方法、局部变量、方法参数等的前面，用来对这些元素进行说明和注释。注解是以‘@注解名’的形式存在于在代码中，注解不会直接影响到程序的语义，但是可以用于实现创建文档、跟踪代码中的依赖性、甚至执行基本编译的检查等功能。

除了java自带的基本内置注解，开发人员经常使用的是自定义注解，用来标识当前接口或者方法具有的特定属性，或者在调用方法前通过自定义的注解内容作一些基本判断进而判决调用方法后的逻辑分支。也就是说，作为整体java代码的一部分，接口或方法注解的正确性也会影响整个代码功能的实现。因此在测试阶段，如果在目标代码中对接口或方法定义了注解，则除了需要对常规的接口或方法实现代码进行测试之外，也有必要对接口或方法的注解进行测试。

现有对于接口或方法注解的测试主要有两种方式：一种是通过人工白盒测试来确认注解是否标注正确；另一种是通过单元或组件测试来验证注解的逻辑是否正确。两种方式都存在不具备重复可用性、效率低下的问题。此外，单元测试尽管能在一定程度上实现自动化，但是却存在应用场景受限的问题。

发明内容

针对上述技术问题，本申请提供一种java注解测试方法及装置，技术方案如下：

一种java注解测试方法，用于对被测目标的注解进行测试，所述被测目标包括java方法或java接口，该测试方法包括：

接收测试入口参数，所述测试入口参数包括：被测目标的标识信息及测试期望信息；

根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；

利用java拦截器机制，执行所获取到的注解逻辑；

根据所述测试期望信息得到测试结果。

一种java注解测试装置，用于对被测目标的注解进行测试，所述被测目标包括java方法或java接口，该测试装置包括：

入口参数接收模块，用于接收测试入口参数，所述测试入口参数包括：被测目标的标识信息及测试期望信息；

注解获取模块，用于根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；

注解逻辑执行模块，用于利用java拦截器机制，执行所获取到的注解逻辑；

测试结果输出模块，用于根据所述测试期望信息得到测试结果。

本申请所提供的技术方案，利用java的拦截器机制和反射机制实现对java注解的测试，与现有技术相比，本申请方案只需一个通用的测试模板，通过修改少量的测试入口参数，就可以实现对各类接口或方法注解的自动测试，而且测试的内容可以同时涵盖对注解自身逻辑正确性的校验以及对方法或接口是否使用了正确注解的校验，从而有效地提升了测试效率，并且降低测试所需的时间人力成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。此外，本申请中的任一实施例并不需要达到上述的全部效果。

附图说明

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

图1是本申请的java注解测试方法的第一种流程示意图；

图2是本申请的java注解测试方法的第二种流程示意图；

图3是本申请的java注解测试装置的第一种结构示意图；

图4是本申请的java注解测试装置的第二种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

为了方便理解本申请方案，首先介绍两个注解在java接口或方法中的应用实例。

应用实例1：

软件在接口或方法调用设计中都会去打印各种日志内容以辅助相关人员排查问题或者监控运行情况，而不同的接口或方法调用内容需要打印在不同的日志中，这种情况下，可以通过在接口或方法中添加注解的方式决定当前接口或方法被调用时需要打印信息到哪个日志中。举例如下：

@LogAnnotation(name＝"test.log")

public static void saying(){

}

上述代码中，“@LogAnnotation(name＝"test.log")”为注解内容，该注解实现的功能是：告知系统当本方法(saying)被调用时，需要打印信息到test.log日志文件中，而这个注解的正确性直接决定了能否将正确的信息打印到正确的日志中，也进一步决定和影响了后续系统问题排查和运行监控的正确性。

应用实例2：

@Zone(zoneCal＝"com.google.map.calculate”)

public static void showInfo(){

}

上述代码中，“@Zone(zoneCal＝"com.google.map.calculate”)”为注解内容，该注解实现的功能是：在执行给用户展示信息的方法(showinfo)前，通过googlemap的计算功能得到调用当前方法时的位置信息，进而在方法内部可以根据这个位置信息提供个性化的信息。但如果这里注解对应的类方法执行逻辑有问题，后续就可能提供给用户错误的信息，从而影响用户体验。

针对接口或方法注解，现有的一种测试方式是通过人工的方式对注解代码阅读判断，以确定注解的内容是否正确。这种方式不具备自动化执行性及重复执行性，实际测试效率非常低下，而且需要消耗大量的时间及人力成本。

当注解内容对应的是一个逻辑类时，可以通过单元测试或者组件测试方式自动校验这个类的处理逻辑是否正确，但是针对不同的注解，仍然需要单独编写单元测试脚本和准备对应的测试数据。另外这种方式的局限性在于：只能校验每个注解自身的逻辑正确性，无法保证对应的接口或方法添加的注解是正确的目标注解。例如，单元测试可以分别校验注解A和注解B的逻辑正确性，如果当前方法需要添加的是注解A，而实际编码时添加的是注解B，这种错误是单元测试无法发现的。事实上，对于目标接口或方法中实际是否使用了正确的注解逻辑类，仍然需要通过人工白盒测试来确认。

针对以上问题，本申请提供一种java注解测试方法，用于对java方法或java接口进行测试，参见图1所示，该方法可以包括以下步骤：

S101，接收测试入口参数，所述测试入口参数包括：被测目标的标识信息及测试期望信息；

S102，根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；

S103，利用java拦截器机制，执行所获取到的注解逻辑；

S104，根据测试期望信息得到测试结果。

本申请方案使用到了java自身的两种机制：拦截器机制和反射机制。

java中的拦截器用于动态拦截action调用的对象，它提供了一种机制，令开发者可以定义一段代码，该代码可以在一个action执行前或执行后实现一些特定的功能，也可以在一个action执行前阻止其执行。此外，java拦截器也提供了一种可以提取action中可重用部分的方式。

java反射机制是指：在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法；这种动态获取的信息以及动态调用对象的方法的功能称为java的反射机制。

为了实现对不同接口或方法注解的通用性测试，本申请方案通过java拦截器机制，设置对被测目标进行拦截，(这里的被测目标可以是带有注解的java方法或java接口)，以便在被测目标执行之前，先执行该被测目标的注解逻辑。其中被测目标的注解可以通过java反射机制获取。

可见，对于整个测试系统而言，只需要两类输入参数：被测目标的标识以及测试期望信息。其中被测目标的标识用于告知测试系统：需要对哪个接口或方法的注解进行测试；测试期望信息则用于系统进行比对校验，从而得到最终的测试结果。也就是说，针对不同的接口或方法，测试人员只需给将该接口或方法的名称、以及对该方法或接口注解的期望测试信息作为入口参数提供给测试系统，后续系统就能够完成对注解的测试工作。与现有的测试方案相比，不仅实现了自动化测试，而且可以在不同的方法或接口上复用同一套测试逻辑，有效地改善了总体的测试效率。

本申请方案的另一个优势在于：既可以实现对注解自身逻辑正确性的校验，也可以实现对方法或接口是否使用了正确注解的校验。图2示出了本申请java注解测试方法的另一种流程图，与图1相比，该流程具体划分出两个测试分支：其中S104a用于对注解自身逻辑正确性进行校验，S104b则用于对方法或接口是否使用了正确注解进行校验。

具体而言，在S101接收的测试入口参数中，“测试期望信息”可以包括两种：

1)期望注解逻辑值，也即在正确情况下，给定被测目标的注解逻辑执行后，应该得到正确的结果。

假设给定的被测目标为方法A，该方法A的注解逻辑执行后，应该得到的正确结果为x，则在S101将“方法A”和值x作为测试入口参数，提供给测试系统；

在S102，测试系统根据“方法A”利用反射机制获取方法A当前实际使用的注解；

在S103，系统利用拦截器机制执行当前测试实际获取到的注解逻辑并且得到执行结果，假设该值为x’。

需要说明的是，由于这里的测试需求仅包括对方法注解的测试，因此可以进一步利用拦截机制阻止被测目标(在本例中为方法A)的执行。

进而在S104a，通过判断注解逻辑的执行结果x’和期望注解逻辑值x是否匹配，就可以确定被测目标方法A的注解执行逻辑是否正确。

2)期望注解信息，也即在正确情况下，应该对给定被测目标添加什么注解。

假设给定的被测目标为方法A，该方法A应该添加的注解为注解A。则在S101中，将“方法A”和“注解A”作为测试入口参数，提供给测试系统；

在S102，测试系统根据“方法A”利用反射机制获取方法A当前实际使用的注解，假设获取的到的结果为“注解A’”；

进而在S104b，通过判断所获取到的注解(注解A’)与期望注解信息(注解A)是否匹配，就可以确定被测目标方法A是否使用了正确的注解。

当然，根据实际的测试需求，S104a和S104b两个测试分支既可以分别独立执行，也可以全部执行，本申请对此不做限定。

另外，在实际的测试需求中，有时可能仅希望对一些特定的注解进行测试，或者对于包含多个注解的方法或接口，仅希望对其中的部分注解进行测试。基于这中需求，可以设置注解过滤规则，用于定义哪些注解存在/不存在测试需求。进而，在S102获取被测目标的注解后，可以根据注解过滤规则对所获取到的注解进行过滤，仅保留具有测试需求的注解进行后续的测试项目(包括S103-S104a分支以及S104b分支)。其中，注解过滤规则可以以相对静态的方式预先配置在系统中，这种方式比较适用于对多个被测目标具有统一注解过滤的场景；此外，也可以将注解过滤规则以测试入口参数的形式提供给测试系统，以便于测试人员灵活配置测试需求；当然在实际应用中，上述两种方式也可以同时采用，即两种方式配置的规则可以同时生效。如有需要，可以进一步配置相应的优先级原则，以应付静态配置规则和动态配置的规则发生冲突的情形。

在本申请方案的另一个应用实例中，可以直接将上述注解测试的功能直接集成在对普通接口或方法的测试工具中，作为对一般接口或方法的测试工具的功能完善。

例如，对于如下方法：

@Zone(zoneCal＝"com.google.map.calculate”)

public static void showInfo(){

}

普通的方法测试脚本中，只会对showInfo方法的逻辑进行校验，但是不会对注解信息做任何校验处理。应用本申请方案，只需在原测试脚本中添加注解校验点，即可实现对注解本身逻辑正确性和/或目标方法被添加注解正确性的校验。由于拦截器机制具有阻止被测目标执行的功能，因此也可以实现对注解的测试过程和对方法的测试过程不发生重复或冲突。

相应于上述方法实施例，本申请还提供一种java注解测试装置，该装置用于对被测目标的注解进行测试，被测目标可以是java方法或java接口，参见图3所示，该装置可以包括：

入口参数接收模块110，用于接收测试入口参数，测试入口参数可以包括：被测目标的标识信息及测试期望信息；

注解获取模块120，用于根据被测目标的标识信息，利用java反射机制，获取被测目标的注解；

注解逻辑执行模块130，用于利用java拦截器机制，执行所获取到的注解逻辑；优选地，该装置还可以用于被测目标的执行。

测试结果输出模块140，用于根据测试期望信息得到测试结果。

在本申请的一种具体实施方式中，测试期望信息可以包括：期望注解逻辑值；

相应地，测试结果输出模块140可以具体用于：判断注解逻辑的执行结果与期望注解逻辑值是否匹配，以确定被测目标的注解执行逻辑是否正确。

在本申请的一种具体实施方式中，测试期望信息可以包括：期望注解信息；

相应地，测试结果输出模块140可以具体用于：判断所获取到的注解与期望注解信息是否匹配，以确定被测目标是否使用了正确的注解。

参见图4所示，本申请所提供的java注解测试装置还可以包括：

注解过滤模块150，用于在注解获取模块120获取被测目标的注解后，根据注解过滤规则，对所获取到的注解进行过滤，该注解过滤规则用于定义注解是否存在测试需求。具体可以是预先配置的注解过滤规则，也可以是入口参数接收模块110以测试入口参数形式接收的注解过滤规则(规则传输如图4虚线所示)。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (10)

1.一种java注解测试方法，用于对被测目标的注解进行测试，所述被测目标包括java方法或java接口，其特征在于，该测试方法包括：

接收测试入口参数，所述测试入口参数包括：被测目标的标识信息及测试期望信息；

根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；

利用java拦截器机制，执行所获取到的注解逻辑；

根据所述测试期望信息得到测试结果。

2.根据权利要求1所述的方法，其特征在于，所述测试期望信息包括：期望注解逻辑值；

所述根据测试期望信息得到测试结果，包括：判断注解逻辑的执行结果与所述期望注解逻辑值是否匹配，以确定被测目标的注解执行逻辑是否正确。

3.根据权利要求1所述的方法，其特征在于，所述测试期望信息包括：期望注解信息；

所述根据测试期望信息得到测试结果，包括：判断所获取到的注解与所述期望注解信息是否匹配，以确定被测目标是否使用了正确的注解。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述被测目标的注解后，根据注解过滤规则，对所获取到的注解进行过滤，所述注解过滤规则用于定义注解是否存在测试需求。

5.根据权利要求4所述的方法，其特征在于，所述注解过滤规则，包括：

预先配置的注解过滤规则，

和/或

以测试入口参数形式接收的注解过滤规则。

6.一种java注解测试装置，用于对被测目标的注解进行测试，所述被测目标包括java方法或java接口，其特征在于，该测试装置包括：

入口参数接收模块，用于接收测试入口参数，所述测试入口参数包括：被测目标的标识信息及测试期望信息；

注解获取模块，用于根据被测目标的标识信息，利用java反射机制，获取所述被测目标的注解；

注解逻辑执行模块，用于利用java拦截器机制，执行所获取到的注解逻辑；

测试结果输出模块，用于根据所述测试期望信息得到测试结果。

7.根据权利要求6所述的装置，其特征在于，所述测试期望信息包括：期望注解逻辑值；

所述测试结果输出模块，具体用于：判断注解逻辑的执行结果与所述期望注解逻辑值是否匹配，以确定被测目标的注解执行逻辑是否正确。

8.根据权利要求6所述的装置，其特征在于，所述测试期望信息包括：期望注解信息；

所述测试结果输出模块，具体用于：判断所获取到的注解与所述期望注解信息是否匹配，以确定被测目标是否使用了正确的注解。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括：

注解过滤模块，用于在所述注解获取模块获取所述被测目标的注解后，根据注解过滤规则，对所获取到的注解进行过滤，所述注解过滤规则用于定义注解是否存在测试需求。

10.根据权利要求9所述的装置，其特征在于，所述注解过滤规则，包括：

预先配置的注解过滤规则，

和/或

所述入口参数接收模块以测试入口参数形式接收的注解过滤规则。