CN103164335B - 检查单元测试质量的方法和系统 - Google Patents

Abstract

本申请公开了一种检查单元测试质量的方法和系统，属于计算机领域。该方法包括：利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据；获取单元测试用例检查规则；根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量；输出单元测试的质量检查结果。该系统包括：测试元获取模块、测试元数据获取模块、检查规则获取模块、规则检查模块和输出模块。本申请的技术方案可以提高单元测试的有效性。

Description

检查单元测试质量的方法和系统

技术领域

本申请涉及计算机领域，特别涉及一种检查单元测试质量的方法和系统。

背景技术

单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。例如，可能需要把一个很大的值放入一个有序列表(list)中去，然后确认该值出现在list的尾部。

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试不仅仅是作为无错编码的一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。

目前，单元测试的代码覆盖率虽然提高了，但由于单元测试的质量不能得到很好的保证，影响了单元测试的有效性。因此，急需一种有效的方案来检查单元测试的质量，以提升单元测试的有效性。

发明内容

为了提升单元测试的有效性，本申请提供了一种检查单元测试质量的方法和系统，技术方案如下：

一种单元测试质量的检查方法，包括：

利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据；

获取单元测试用例检查规则；

根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量；

输出单元测试的质量检查结果。

一种单元测试质量的检查系统，包括：

测试元数据获取模块，用于利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据；

检查规则获取模块，用于获取单元测试用例检查规则；

规则检查模块，用于根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量；

输出模块，用于输出单元测试的质量检查结果。

本申请的技术方案通过预设描述测试元的元语和单元测试用例检查规则，然后根据元语获取测试元对应的测试元数据，并利用测试元数据和单元测试用例检查规则，能够全面检查单元测试的质量，提高单元测试的有效性。

通过以下参照附图对本申请实施例的说明，本申请的上述以及其它目的、特征和优点将更加明显。

附图说明

下面将参照所附附图来描述本申请的实施例，其中：

图1是本申请实施例提供的检查单元测试质量的方法的流程图；

图2是本申请实施例提供的检查单元测试质量的系统的结构图；

图3是本申请实施例提供的检查单元测试质量的方法的详细流程图。

具体实施方式

下面结合附图详细描述本申请的具体实施例。应当注意，这里描述的实施例只用于举例说明，并不用于限制本申请。

影响单元测试的质量的因素包括但不限于以下几种：

第一、单元测试代码风格不规范，缺乏统一性。具体的表现形式包括但不限于以下几种：单元测试缺少断言；单元测试用例未包含预期结果；单元测试仅覆盖正常情况，对异常情况未考虑；测试方法的命名不统一；一些dao层的删除数据方法没有进行单元测试；单元测试数据繁多，有些方法参数/断言很多，所以会省略一些字段，可能会放过一些漏洞(bug)。

第二、单元测试用例设计不规范，系统测试功能覆盖面不全。具体的表现形式包括但不限于以下几种：不同的业务场景，靠人工修改参数来进行单元测试，而不是区分不同的测试用例来实现；dao层测试用例只有应用程序编程接口(ApplicationProgrammingInterface，API)调用；集成测试用例只包含了业务场景的简单串联，没有走到所有的关键路径；单元测试没有按等价类划分测试用例，一般一个方法只会对应一个测试用例，例如空值(null)、边界值、极限值并没有被覆盖，会漏掉一些异常漏洞(bug)。

第三、单元测试依赖外部环境变量，外部环境的不稳定会导致单元测试的不稳定性。具体的表现形式包括但不限于以下几种：服务(Service)单元测试时需要屏蔽所有外部环境因素；私有方法应该独立测试；避免单元测试之间的依赖关系；有的类中变量是以注入的方式赋值，该赋值在方法中需要使用到，需要对这些变量也做一下覆盖测试，看赋值是否正确。

为了解决现有技术中存在的问题，本申请通过预设用于描述测试元的元语和单元测试用例检查规则，然后根据元语获取测试元对应的测试元数据，并利用测试元数据和单元测试用例检查规则能够全面检查单元测试的质量，提高单元测试的有效性。

下面结合具体的实施例对本申请进行详细的描述。

实施例一

本申请实施例提供了一种检查单元测试质量的方法，如图1所示，包括：

步骤101，利用面向切面编程方式，根据预设的用于描述测试元的元语获取该测试元对应的测试元数据；进一步地，该步骤包括：根据目标切面维度从单元测试集和/或目标应用程序获取目标切面信息；将该目标切面信息细分为最小单位的测试信息，该最小单位的测试信息为该测试元，在内存中存储该测试元及其对应的测试元数据；获取预设的元语，利用该预设的元语、该测试元和该测试元数据的关联关系从内存中获取该测试元对应的测试元数据。优选地，为了提高系统运算速度，降低运算成本和减少错误发生，可以在获取元语后，根据预设的元语过滤条件，从获取的元语中过滤冗余的元语。在本实施例中，目标切面信息可以包括以下信息中的一种或其组合：单元测试类的方法、目标应用程序任意类的方法和单元测试断言方法。

步骤102，获取单元测试用例检查规则。优选地，为了提高系统运算速度，降低运算成本和减少错误发生，可以在获取单元测试用例检查规则后，根据预设的检查规则过滤条件，从该获取的单元测试用例检查规则中过滤冗余的单元测试用例检查规则。

步骤103，根据该测试元数据和该单元测试用例检查规则检查单元测试质量。进一步地，该步骤包括：将该测试元数据替代该单元测试用例检查规则中的元语，以检查该测试元数据是否符合该单元测试用例检查规则，从而得到单元测试的质量检查结果。

步骤104，输出单元测试的质量检查结果。优选地，为了便于用户以后的对比或查阅，可以在输出单元测试的质量检查结果之后或之前，存储质量检查结果。进一步地，为了便于直观形象地分析质量检查结果，可以对输出的质量检查结果或存储的质量检查结果进行报表分析。

本申请实施例通过预设描述测试元的元语，然后根据元语获取测试元对应的测试元数据，并利用测试元数据和单元测试用例检查规则，能够全面检查单元测试的质量，提高单元测试的有效性。

实施例二

如图2所示为检查单元测试质量的方法的应用架构图，该架构图使用的是编程语言为jdk1.6及以上，开发框架为maven3，扩展包依赖ASPECTJ1.5以上，但该使用的编程语言，开发框架和扩展包等只是为了举例需要，本申请的保护范围并不限于此。在图2中，该架构包括：ASPECTJ框架、目标应用程序、单元测试集和检查单元测试质量的系统。

ASPECTJ框架作为目标应用程序的运行代理，同时起着作为检查单元测试质量的系统的支撑工具的作用。需要说明的是，由于采用的编程语言不同，起支撑工具作用的框架可以根据编程语言的不同而进行相应的选择，并不限于ASPECTJ框架。

检查单元测试质量的系统是本实施例的核心，其使用面向切面编程(AspectOrientedProgramming，AOP)方式织入到目标应用程序和单元测试集来运行。该系统可以Jar方式集成到目标应用程序中，当单元测试运行时，该系统自动对单元测试用例进行检查。具体地，该系统包括：测试元数据获取模块、设置模块和检查模块。其中，测试元数据获取模块包括切面信息获取单元和测试元数据存储单元。设置模块包括：元语设置单元、检查规则设置单元、元语过滤单元和检查规则解析单元。检查模块包括：测试元数据提取单元、检查规则获取单元、检查规则过滤单元、规则检查单元、质量结果存储单元、输出单元和报表分析单元。

图3所示为本申请实施例的单元测试质量的检查方法的详细流程图，参考图2和图3，并结合具体的示例对本申请进行详细的描述，具体如下：

在步骤301中，切面信息获取单元获取目标切面信息。

具体地，在单元测试运行中，切面信息获取单元从不同的目标切面维度织入，获取到目标切面维度对应的目标切面信息，并将目标切面信息细分成最小单位的测试信息，本实施例将该最小单位的测试信息定义为测试元，该测试元可以是包.类.方法名、参数表、数据或断言等，但本实施例并未将测试元限制在上述示例。

在本实施例中，切面信息获取单元拦截到单元测试运行的测试方法，进而拦截到测试方法所调用的目标应用程序方法以及拦截到单元测试断言方法。具体地，该目标切面信息包括：单元测试类的方法、目标应用程序任意类的任意方法和单元测试断言方法。本实施例提供的目标切面信息的示例如下：

需要说明的是，上述三类目标切面信息只是本实施例的一个示例，本实施例的保护范围也可以是上述三类目标切面信息之一或者其中任意两种目标切面信息的组合。在以后的应用中，用户还可以根据需要添加其他目标切面信息，在此不再赘述。

在步骤302中，测试元数据存储单元从目标切面信息中获取测试元，并将测试元及其对应的测试元数据写入到内存池中。其中，获取的测试元包括提取类名、方法名、参数表、数据、断言等。本实施例提供的测试元存储结构的示例如下：

|-TestMeta-targetClass、targetMethod、testCaseClass、...

List-|-TestMeta-targetClass、targetMethod、testCaseClass、...

|-TestMeta-targetClass、targetMethod、testCaseClass、...

其中，“targetClass”、“targetMethod”和“testCaseClass”即为元语，分别描述目标程序类，目标方法和测试用例类等测试元，而测试元数据存储在元语对应的内存中。

在步骤303中，元语设置单元根据用户的指令按照预先的元语设置规则设置用来描述测试元语，并将设置的元语存储在内存中。例如，用元语“assertions”描述的测试元为“断言”。其中，设置的元语存储在内存中。测试元是以元语为关键字存储在内存池中的，因此可以根据元语来查找测试元对应的测试元数据。通过将测试元对应的测试元数据代入到单元测试用例检查规则中，替代其中的元语，可以达到执行单元测试用例检查规则的目的。需要说明的是，元语可以是可扩展标记语言(ExtensibleMarkupLanguage，XML)配置文件，也可以是数据库表，本实施例对此不作限制。

元语描述测试元是在单元测试用例检查规则中进行定义的，如下所示为一个单元测试用例检查规则：

其中，assertions即为元语，表示断言测试元的集合；而测试元是以元语为关键字存储在内存池中的，因此可以根据元语来查找测试元对应的测试元数据。

在步骤304中，检查规则设置单元通过引用元语，使用伪代码来定义单元测试用例检查规则。其中，单元测试用例检查规则可以XML文件形式或嵌入式数据库形式存在，但本实施例的保护范围并不以此为限。以下为单元测试用例检查规则的一个示例：

此单元测试用例检查规则的含义为，检查单元测试类的类名申明方式是否为：“目标应用程序类+Test”。

在步骤305中，元语过滤单元可以根据用户设定的元语过滤条件，对冗余的元语进行过滤。例如，用户设定元语过滤条件为：

该元语过滤条件表示，所有检查时经过的targetClass测试元，凡是名称中不带“telek”的一律过滤掉，即不检查。例如有一目标应用程序类，名称为“com.testbird.hello.HelloBean”，由于该类名中不包含“telek”，那么此类名所产生的测试元将不被检查是否符合单元测试用例检查规则。

需要说明的是，步骤305属于优选的步骤，通过该过滤步骤可以防止检查不在单元测试的测试目标范围内的类，以避免系统性能下降和产生错误结果。

在步骤306中，检查规则解析单元利用Stax技术将单元测试用例检查规则解析成对象。Stax技术是流式解析XML的工具；它只是在读取XML文件时会经过每个XML节点，从而提取节点信息；节点信息包括：节点名称、节点属性名称、节点属性值、节点内的文本、节点内的CDATA。例如，对于节点：

Stax技术会提取节点名称Hello、节点属性名name、节点属性值Tom、文本内容美国加州人，此处CDATA与节点文本相同。

需要说明的是，由于系统应用的框架、编程语言的不同，所使用的解析工具也会相应不同，本实施例的保护范围并不限于上述Stax解析工具。

在步骤307中，检查规则获取模块通过检查规则解析模块获取已解析成对象的单元测试用例检查规则。

在本实施例中，检查规则获取模块获取的单元测试用例检查规则在步骤306中已经描述，在此不再赘述。

在步骤308中，检查规则过滤单元利用预设的检查规则过滤条件过滤掉冗余的单元测试用例检查规则。需要说明的是，步骤308属于优选的步骤，通过该过滤步骤可以防止检查不在单元测试的测试目标范围内的类，以避免系统性能下降和产生错误结果。

在步骤309中，测试元数据提取单元获取预设的元语，利用获取的元语，并根据元语、测试元和测试元数据的关联关系遍历内存池，获取与测试元对应的测试元数据。

在本步骤中，对于目标程序“com.testbird.hello.HelloBean”而言，如果元语为“targetClass”，则测试元数据提取单元获取的测试元数据为“HelloBean”。

需要注意的是，如果在步骤305中已经过滤掉冗余的元语，则本步骤中无需再进行过滤。反之，如果在步骤305中未过滤掉冗余的元语，则本步骤中，需要在获取到预设的元语后，再根据元语过滤条件过滤到冗余的元语。

在步骤310中，规则检查模块对单元测试用例逐个检查，并获得单元测试的质量检查结果。

具体地，规则检查模块将获取的测试元数据，代入到获取的单元测试用例检查规则中，替代元语，以检查单元测试用例的质量，得到单元测试的质量检查结果。

例如，获取的单元测试用例检查规则见步骤306，测试元数据为HelloBean，将测试元数据代入到获取的单元测试用例检查规则中，则具体的执行语句为：

规则检查模块提取className变量的值，结果为true，即符合单元测试用例检查规则要求。

在步骤311中，输出模块输出单元测试的质量检查结果。具体地，输出模块使用log4j配置输出以日志形式存在的质量检查结果，日志输出文件保存在可配置的路径下，未配置时，默认输出在工具Jar的当前目录下。需要说明的是，单元测试的质量检查结果并不必须以日志形式存在，用户可以根据需要得到以其他形式存在的单元测试的质量检查结果。

在步骤312中，存储模块存储单元测试的质量检查结果。具体的单元测试的质量检查结果包括但不限于以下内容：测试用例的检查时间、检查的单元测试类、测试方法、失败级别、失败提示。需要说明的是，在本实施例中，存储模块使用ibatis读写单元测试的质量检查结果到derby数据库。需要说明的是，本实施例中使用的读写工具并不限于ibatis，用户可以根据需要选择其他读写工具。本实施例并不限于使用derby数据库存储单元测试的质量检查结果，也可以是其他类型的数据库，或是根据用户需要选择其他类型的存储单元。此外，存储模块可以先存储单元测试的质量检查结果，然后由输出模块输出单元测试的质量检查结果；也可以先由输出模块输出单元测试的质量检查结果，然后再由存储模块进行存储。设置存储模块的目的是可以方便以后进行质量检查结果调取和比较。

在步骤313中，报表分析模块对单元测试的质量检查结果进行分析，以报表的形式显示单元测试的质量检查结果。报表分析模块可以直接对输出模块输出的单元测试的质量检查结果进行分析，也可以直接对存储模块存储的单元测试的质量检查结果进行分析。设置报表分析模块的目的是，通过报表分析可以方便用户直观形象地进行分析、统计和检查。

需要说明的是，本市实施并不对限定上述步骤301-313的顺序，用户为了实现本申请的目的可以根据实际需要进行顺序调整。例如，步骤301-302可以和步骤303-306互换顺序，其他步骤做相应调整。

本申请实施例通过预设用于描述测试元的元语和单元测试用例检查规则，然后根据元语获取测试元对应的测试元数据，并利用测试元数据和单元测试用例检查规则能够全面检查单元测试的质量，提高单元测试的有效性。

虽然已参照典型实施例描述了本申请，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本申请能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (16)

1.一种单元测试质量的检查方法，其特征在于，包括：

利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据；

获取单元测试用例检查规则；

根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量；

输出单元测试的质量检查结果；

其中利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据，包括：

根据目标切面维度从单元测试集和/或目标应用程序获取目标切面信息；

将所述目标切面信息细分为最小单位的测试信息，所述最小单位的测试信息为所述测试元，在内存中存储所述测试元及其对应的测试元数据；

获取预设的元语，利用所述预设的元语、所述测试元和所述测试元数据的关联关系从内存中获取所述测试元对应的测试元数据。

2.如权利要求1所述的方法，其特征在于，所述目标切面信息包括以下信息任意一种或其组合：

单元测试类的方法、目标应用程序任意类的方法和单元测试断言方法。

3.如权利要求1所述的方法，其特征在于，所述获取预设的元语之后，包括：

根据预设的元语过滤条件，从所述获取的元语中过滤冗余的元语。

4.如权利要求1所述的方法，其特征在于，所述根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量，包括：

将所述测试元数据替代所述单元测试用例检查规则中的元语，以检查所述测试元数据是否符合所述单元测试用例检查规则，从而得到单元测试的质量检查结果。

5.如权利要求1至4任意一项所述的方法，其特征在于，获取所述单元测试用例检查规则之前，还包括：

根据用户指令设置所述单元测试用例检查规则；

将所述单元测试用例检查规则解析成对象。

6.如权利要求1至4任意一项所述的方法，其特征在于，获取所述单元测试用例检查规则之后，包括：

根据预设的检查规则过滤条件，从所述获取的单元测试用例检查规则中过滤冗余的单元测试用例检查规则。

7.如权利要求1至4任意一项所述的方法，其特征在于，所述输出单元测试的质量检查结果的步骤之后，包括：

存储所述单元测试的质量检查结果。

8.如权利要求1至4任意一项所述的方法，其特征在于，所述输出单元测试的质量检查结果之后，还包括：对所述单元测试的质量检查结果进行报表分析，生成报表分析结果。

9.一种单元测试质量的检查系统，其特征在于，包括：

测试元数据获取模块，用于利用面向切面编程方式，根据预设的用于描述测试元的元语获取所述测试元对应的测试元数据；

检查规则获取模块，用于获取单元测试用例检查规则；

规则检查模块，用于根据所述测试元数据和所述单元测试用例检查规则检查单元测试质量；

输出模块，用于输出单元测试的质量检查结果；

其中所述测试元数据获取模块，包括：

切面信息获取单元，用于根据目标切面维度从单元测试集和/或目标应用程序获取目标切面信息；

测试元数据存储单元，用于将所述目标切面信息细分为最小单位的测试信息，所述最小单位的测试信息为所述测试元，并存储所述测试元及其对应的测试元数据；

测试元数据提取单元，用于获取预设的元语，利用所述预设的元语、所述测试元和所述测试元数据的关联关系从内存中提取所述测试元对应的测试元数据。

10.如权利要求9所述的系统，其特征在于，所述目标切面信息包括以下信息任意一种或其组合：

单元测试类的方法、目标应用程序任意类的方法和单元测试断言方法。

11.如权利要求9所述的系统，其特征在于，还包括：元语过滤模块，用于根据预设元语过滤条件，从所述获取的预设的元语中过滤冗余的元语。

12.如权利要求9所述的系统，其特征在于，所述规则检查模块，具体用于将所述测试元数据替代所述单元测试用例检查规则中的元语，检查所述测试元数据是否符合所述单元测试用例检查规则，从而得到单元测试的质量检查结果。

13.如权利要求9至12任意一项所述的系统，其特征在于，还包括：

检查规则设置模块，用于根据用户指令设置所述单元测试用例检查规则；

检查规则解析模块，用于将所述单元测试用例检查规则解析成对象。

14.如权利要求9至12任意一项所述的系统，其特征在于，还包括：检查规则过滤模块，用于根据预设的检查规则过滤条件，从所述获取的单元测试用例检查规则中过滤冗余的单元测试用例检查规则。

15.如权利要求9至12任意一项所述的系统，其特征在于，还包括：存储模块，用于存储所述单元测试的质量检查结果。

16.如权利要求9至12任意一项所述的系统，其特征在于，报表分析模块，用于对所述单元测试的质量检查结果进行报表分析，生成报表分析报告。