CN114528214A - 单元测试方法和装置 - Google Patents

Abstract

本申请公开了一种单元测试方法和装置，该方法包括：从指定目录下获取预先配置的元数据文件，元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；对元数据文件进行解析，得到元数据文件中包括的测试用例和mock数据；根据测试用例、mock数据以及待测单元的测试方法生成单元测试计划；执行单元测试计划，得到单元测试计划的执行结果。本申请实施例在进行单元测试时可以无需每次编写测试用例，也无需编写mock代码，极大降低了单元测试的编写难度，提高了单元测试的测试效率。此外，通过元数据文件统一管理和维护单元测试所需的测试用例和mock数据，还可以保证整个单元测试的稳定性、可维护性和可持续化。

Description

单元测试方法和装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种单元测试方法和装置。

背景技术

单元测试一般是指对软件中的最小可测试单元进行检查和验证，以通过确保软件最小粒度的正确性来保证其整体的正确性。目前，在进行单元测试时，可以依赖单元测试框架实现，具体地，可以在既定的框架规则内编写测试用例，然后基于测试用例进行单元测试。

然而，在实际进行单元测试时，需要每次手动编写测试用例，且每个测试用例都是单独的测试方法，分散于各个单元测试类中，不便管理，此外，当待测单元内部依赖其他方法时，需要对被依赖的方法编写模拟(mock)代码，花费的时间较长，且不易实现。

发明内容

本申请实施例提供一种单元测试方法和装置，用于解决目前基于单元测试框架进行单元测试时，测试用例代码编写复杂，不易实现mock功能的问题。

为解决上述技术问题，本申请实施例是这样实现的：

第一方面，提出一种单元测试方法，包括：

从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

执行所述单元测试计划，得到所述单元测试计划的执行结果。

第二方面，提出一种单元测试装置，包括：

获取模块，从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

解析模块，对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

测试计划生成模块，根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

测试模块，执行所述单元测试计划，得到所述单元测试计划的执行结果。

第三方面，本申请提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的方法。

第四方面，本申请提供一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在对待测单元进行单元测试时，由于可以将单元测试所需的测试用例和mock数据预先配置到元数据文件中，并在生成单元测试计划时，通过解析元数据文件来获取测试用例和mock数据进而生成单元测试计划，因此，在进行单元测试时可以无需每次编写测试用例，也无需编写mock代码，直接从元数据文件中获取相应数据即可，极大降低了单元测试的编写难度，提高了单元测试的测试效率。此外，由于可以通过元数据文件统一配置单元测试所需的测试用例和mock数据，因此，可以便于对测试用例和mock数据的统一管理和维护，进而保证整个单元测试的稳定性、可维护性和可持续化。

附图说明

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

图1是本申请的一个实施例单元测试方法的流程示意图；

图2是本申请的一个实施例单元测试方法的流程示意图；

图3是本申请的一个实施例单元测试方法的流程示意图；

图4是本申请的一个实施例单元测试方法的流程示意图；

图5是本申请的一个实施例电子设备的结构示意图；

图6是本申请的一个实施例单元测试装置的结构示意图。

具体实施方式

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

本说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应理解这样使用的数据在适当情况下可以互换，以便本说明书实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，本说明书以及权利要求书中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。

本申请实施例提供的技术方案的核心发明构思是：在对待测单元进行单元测试之前，将单元测试所需的测试用例数据和mock数据统一配置到指定目录下的元数据文件中，在对待测单元进行单元测试时，可以自动从指定目录下获取对应的元数据文件，自动解析元数据文件获取其中的测试用例和mock数据，然后基于测试用例和、mock数据和待测单元的测试方法自动生成单元测试计划，执行该单元测试计划就可以得到待测单元的测试结果。本申请实施例提供的技术方案在进行单元测试时，可以无需每次编写测试用例，也无需编写mock代码，直接从元数据文件中获取相应数据即可，极大降低了单元测试的编写难度，提高了单元测试的测试效率。此外，由于可以通过元数据文件统一配置单元测试所需的测试用例和mock数据，因此，可以便于对测试用例和mock数据的统一管理和维护，进而保证整个单元测试的稳定性、可维护性和可持续化，同时也可以帮助开发人员专注测试逻辑的编写。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1是本申请的一个实施例单元测试方法的流程示意图。图1所示的单元测试方法的执行主体可以是用于进行单元测试的终端或电子设备等，图1所示的单元测试方法如下所述。

S102：从指定目录下获取预配置的元数据文件，元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据。

在对待测单元进行单元测试之前，可以将对待测单元进行单元测试所需的一个或多个测试用例以及mock数据配置到元数据文件中，并将元数据文件存放到指定目录下。当对待测单元进行单元测试时，可以从指定目录下获取预先配置的元数据文件。

上述指定目录可以是默认的目录，也可以是自定义的目录。指定目录的个数可以是一个或多个，在指定目录为一个的情况下，该指定目录下可用于存放多个元数据文件，一个元数据文件可用于对一个待测单元进行单元测试，多个元数据文件可用于对不同的待测单元进行单元测试。在指定目录为多个时，多个不同的指定目录下可以存放不同的元数据文件。

元数据文件可以称为单元测试元数据文件，可以是excel文件，可以是csv文件，还可以是其他可用于存放单元测试数据的文件，元数据文件中可以包括对待测单元进行单元测试所需的测试用例和mock数据。其中，测试用例的个数可以是一个或多个，即对待测单元进行单元测试时需要使用一个或多个测试用例，不同的测试用例可以服务于待测单元的不同测试方法，本申请实施例可以以测试用例的个数为多个，且该多个测试用例服务于待测单元的不同测试方法为例进行说明。

mock数据也可以称为模拟数据，具体可以是模拟某种真实场景发生时所需要和产生的数据，或者是模拟当前系统对外部系统依赖的某种数据。假如，当前需要测试A服务的某个功能，该功能依赖于B服务的某个功能的返回数据，但是B服务不稳定或者无法满足A服务对某种特殊数据的要求，此时可以通过模拟数据的方式模拟B服务的返回数据。其中，mock数据的个数也可以是一个或多个。

待测单元可以是软件中的最小可测试单元，具体可以是函数、方法、接口或某个功能等，这里不做具体限定。

S104：对元数据文件进行解析，得到元数据文件中包括的测试用例和mock数据。

在对元数据文件进行解析时，可以使用文件解析框架进行解析，或者，也可以使用其他文件解析方法实现，只要能得到元数据文件中的测试用例和mock数据即可，这里不对文件解析方法进行具体限定。

S106：根据测试用例、mock数据以及待测单元的测试方法生成单元测试计划。

元数据文件可以指定测试用例和mock数据具体服务于待测单元的哪个单元测试方法(以下简称测试方法)，在根据测试用例、mock数据以及待测单元的测试方法生成单元测试计划时，可以将测试用例和mock数据和待测单元的测试方法进行对应，然后就可以生成单元测试计划。

S108：执行单元测试计划，得到单元测试计划的执行结果。

本申请实施例提供的技术方案，在对待测单元进行单元测试时，由于可以将单元测试所需的测试用例和mock数据预先配置到元数据文件中，并在生成单元测试计划时，通过解析元数据文件来获取测试用例和mock数据进而生成单元测试计划，因此，在进行单元测试时可以无需每次编写测试用例，也无需编写mock代码，直接从元数据文件中获取相应数据即可，极大降低了单元测试的编写难度，提高了单元测试的测试效率。此外，由于可以通过元数据文件统一配置单元测试所需的测试用例和mock数据，因此，可以便于对测试用例和mock数据的统一管理和维护，进而保证整个单元测试的稳定性、可维护性和可持续化。

在一种实现方式中，元数据文件的文件名可以与待测单元对应的类的类名相同。比如，单元测试功能代码载体类名为CA，那么对应的元数据文件的文件名也应该为CA。这样，在上述S102中，在从指定目录下获取预先配置的元数据文件时，可以根据待测单元对应的类的类名，从指定目录下获取文件名与该类名相同的元数据文件。

具体地，在指定目录为一个的情况下，指定目录中可以存放多个元数据文件，一个元数据文件可以对应一个待测单元，即一个元数据文件中可以配置有用于对一个待测单元进行单元测试的测试用例和mock数据，不同的元数据文件可以对应不同的待测单元。针对任一元数据文件，该元数据文件的文件名可以与该元数据文件对应的待测单元的类的类名相同，不同的待测单元对应的类的类名可以不同。这样，在对某个待测单元进行单元测试并从指定目录下获取元数据文件时，可以根据待测单元对应的类的类名从指定目录下的多个元数据文件中查找文件名为该类名的元数据文件，在查找到文件名为该类名的元数据文件的情况下，可以获取查找到的元数据文件。在指定目录为多个的情况下，可以根据待测单元对应的类的类名从多个指定目录下依次查找文件名为该类名的元数据文件，在查找到文件名为该类名的元数据文件的情况下，可以从对应的指定目录下获取该元数据文件。

这样，由于可以将待测单元对应的元数据文件的文件名设置为待测单元对应的类的类名，因此，在获取元数据文件时，可以根据待测单元对应的类的类名自动识别出需要读取加载的元数据文件，提高文件的获取效率和准确率。此外，还需要说明的是，现有常用的框架都需要提前指定需要读取加载的文件，但是在多个单元测试编排执行的情况下就很难同时指定满足所有单元测试的元数据文件，而本申请实施例则可以通过执行计划中单元测试所在类的类名自动识别出需要读取加载的元数据文件，只要元数据文件的文件名与单元测试所在类的类名相同即可，不仅易于实现，还可以同时指定满足所有单元测试的元数据文件。

在一种实现方式中，元数据文件的测试用例中可以包括待测单元方法名称(测试目标)、测试环境、输入数据和参考结果。这里的测试用例中包括待测单元方法名称、测试环境、输入数据和参考结果，可以是测试用例中包括多条元数据，每条元数据包含待测单元方法名称、测试环境、输入数据和参考结果这四种数据类型，这些数据类型服务于具体的测试用例。

待测单元方法名称是一个自定义的名称，可以表征测试用例服务于哪个测试方法。本申请实施例中，测试用例中的待测单元方法名称需要与测试用例所服务的测试方法的方法名相同，这样，在上述S106中生成单元测试计划时，可以便于将测试用例与待测单元的测试方法进行一一匹配，进而在匹配的基础上生成单元测试计划。

测试环境可以是软件的运行环境所对应的测试环境。一般地，软件从研发到上线至少要经历开发、测试和生产三个阶段，而每个阶段会对其提供具体的运行环境，这里的测试环境是针对运行环境而言的。其中，不同的运行环境可以对应不同的配置、数据和网络情况，本申请实施例在测试用例中提供“测试环境”的字段，可以更有针对性的进行单元测试。

输入数据可以表征待测单元的入参，无论运行何种单元测试，都是需要具体数据来驱动的，进行驱动的数据就是这里所讲的“输入数据”。本申请实施例可以自动将输入数据解析为测试方法对应的入参数据结构。输入数据的数据来源可以包括简单值域(value_source)、枚举值域(enum_source)、指定方法来源(method_source)、csv格式数据来源(csv_source)、csv文件来源(csv_file)以及JSON字符串来源(json_source)中的至少一项。

简单值域就是通过常规的方法进行数据赋值，比如，“value＝{张三，18，重庆}”，这里的定义就是会依次赋值给对应单元测试方法的三个参数。枚举值域是简单值域的一种特殊形式，只能赋值给一个参数。

指定方法来源是在测试方法对应类中提前写好输入数据，当执行测试方法时，会自动找到该方法并生成输入数据。具体而言，指定方法来源就是用于确定某个单元测试方法的数据来源是由代码中哪一个方法提供的，如“methodSource＝Generate.getThree”。

csv文件来源相对要直观很多，可以直接将数据统一放到一个csv文件中，然后再将该文件放到指定的文件夹里，在这种数据来源下，本申请实施例会自动寻找对应的csv文件供应测试输入。

csv格式数据来源和csv文件来源可以看作是同一种来源类型，具体而言，若将csv格式的数据一同放入一个后缀名为“csv”的文件中，则可以得到csv文件来源，比如，“csvFile＝testCsvFile.csv”就是指定一个csv文件，在生成单元测试计划时，会去读取这个文件并获取文件中的csv格式的数据。csv格式和excel表格类似，如“csv＝{apple，10}”。

JSON字符串来源和csv格式数据来源类似，只是JSON字符串来源的格式不一样。比如，“json＝{name:张三，age：18}”，表示name字段的赋值张三，age字段赋值18。

参考结果即一轮测试执行完毕之后，在待测单元正常的情况下可以得到的执行结果，也是后续断言的数据来源。

在一种实现方式中，mock数据中可以包括与mock的数据对应的方法以及mock的具体数据，即可以在mock数据中定义mock数据目标方法(即与mock的数据对应的方法)以及具体mock数据(即mock的具体数据)这两种数据类型。比如，待测单元的单元测试需要mock服务B的getUser方法的数据，那么，mock数据可以定义为：mock_name＝B.getUser，mock_data＝{name:张三，age:18}，mock_name即为与mock的数据对应的方法，mock_data即为mock的具体数据。

这样，通过在mock数据中定义mock的数据所对应的方法以及mock的具体数据，可以在一个单元测试中有多个方法需要mock数据时，能够使不同的mock数据得到区分。

在一种实现方式中，考虑到元数据文件中不同的测试用例可以对应不同的mock数据(即不同的测试用例需要mock不同的数据)，不同的测试用例可以服务于待测单元的不同测试方法，因此，为了便于生成单元测试计划，在上述S104对元数据文件进行解析，得到元数据文件中包括的测试用例和mock数据后，还可以对测试用例和mock数据进行数据清洗，这里的数据清洗可以是数据预处理，具体可以包括以下步骤：

将测试用例和mock数据进行一一对应；

将测试用例和待测单元的测试方法进行一一对应。

具体地，测试用例中可以指定测试用例执行时需要mock的方法，在将测试用例和mock数据进行一一对应时，可以将测试用例中指定的需要mock的方法和mock数据中包括的与mock的数据对应的方法进行匹配，从而将测试用例和mock数据进行一一匹配。

在将测试用例和待测单元的测试方法进行一一对应时，可以采用以下任一种方式实现：

第一种方式：

根据待测单元的目标测试方法的方法名从测试用例中确定目标测试用例，目标测试用例对应的待测单元方法名称和目标测试方法的方法名相同；将目标测试用例和目标测试方法进行一一对应。

元数据文件中可以包括多个测试用例，每个测试用例中均包括待测单元方法名称。待测单元的测试方法可以由多个，每个测试方法也对应一个方法名。在将测试用例和测试方法进行一一对应时，可以根据测试用例中包括的待测单元方法名称和测试方法的方法名，将测试用例和测试方法一一匹配。具体地，以一个测试方法(以下可以称为目标测试方法)为例，可以根据该目标测试方法的方法名从测试用例中查找待测单元方法名称与该测试方法的方法名相同的测试用例，并将查找到的测试用例作为目标测试用例，然后将目标测试用例与该目标测试方法进行对应。这样，可以将不同的测试用例与待测单元的不同测试方法进行一一对应。

比如，待测单元的测试方法的方法名为“test”，则可以根据“test”从解析到的测试用例中查找待测单元方法名称为“test”的测试用例，然后将查找到的测试用例与测试方法“test”进行对应。

第二种方式：

在得到上述第一种方式中的目标测试用例后，从目标测试用例中确定具有预设参数个数和预设参数类型的第一目标测试用例；将第一目标测试用例和目标测试方法进行一一对应。

考虑到实际应用中，多个测试用例中包括的待测单元方法名称可能相同，但是每个测试用例对应的参数个数或者参数的数据类型不同，在这种情况下，在基于上述第一种方式将测试用例和测试方法进行一一对应后，得到的结果可能是无效的。为了得到有效的对应结果，在第二种方式中，可以在第一种方式的基础上进行进一步匹配。

具体地，以一个目标测试方法为例，在通过上述第一种方式得到该目标测试方法对应的目标测试用例后，可以进一步确定目标测试用例中具有预设参数个数和预设参数类型的目标测试用例(为了便于区分，可以表示为第一目标测试用例)，然后将第一目标测试用例与目标测试方法进行对应，实现精确匹配的目的。其中，预设参数个数和预设参数类型可以是目标测试方法对应的参数个数和参数类型。

比如，仍以上述待测单元的测试方法的方法名为“test”为例，在根据“test”确定得到多个待测单元方法名称为“test”的测试用例后，还可以从这些测试用例中进一步确定具有预设参数个数和预设参数类型的测试用例，然后将具有预设参数个数和预设参数类型的测试用例与测试方法“test”进行对应。这里的预设参数个数和预设参数类型可以是测试方法“test”对应的参数个数和参数类型。

在实际应用中，在将测试用例和测试方法进行一一对应时，可以根据实际的场景或需求确定采用上述第一种方式还是采用上述第二种方式，这里不做具体限定。

在一种实现方式中，在对测试用例和mock数据进行数据清洗后，即在将测试用例和mock进行一一对应，以及将测试用例和待测单元的测试方法进行一一对应后，还可以按照待测单元对应的类的类名，将测试用例和mock数据对应存储到中间件中，以及将测试用例和待测单元的测试方法对应存储到中间件中，即按照待测单元对应的类的类名，将清洗后的测试用例和mock数据存储到中间件中。

具体地，可以以待测单元对应的类的类名为索引，将该索引与测试用例和mock数据对应存储到中间件中，这样，可以以待测单元对应的类的类名为查询条件，在中间件中查找到用于对待测单元进行单元测试的测试用例和mock数据。其中，在存储测试用例和mock数据时，可以根据上述测试用例和mock数据的一一对应后结果，将测试用例和mock数据对应存储到中间件中，以及根据上述对测试用例和测试方法的一一对应结果，将测试用例和测试方法对应存储到中间件中。

这样，通过将测试用例和mock数据按照待测单元对应的类的类名存储到中间中，且将测试用例和mock数据对应存储到中间件中，以及将测试用例和测试方法对应存储到中间件中，因此，在后续需要使用这些测试用例和mock数据对待测单元进行单元测试时，可以直接根据待测单元对应的类的类名从中间件中获取，无需对元数据文件进行解析，也无需对测试用例和mock数据进行重复的数据清理，从而可以节省大量的cpu计算时间，提高对测试用例和mock数据的获取效率，进而提高单元测试的效率。

在一种实现方式中，在上述S106中根据测试用例、mock数据以及待测单元的测试方法生成单元测试计划时，可以先从上述中间件中获取对应的测试用例和mock数据，然后根据获取到的测试用例和mock数据，结合待测单元的测试方法生成单元测试计划。

具体地，首先，可以根据待测单元对应的类的类名，从中间件中获取与类名对应的测试用例和mock数据，其次，在获取到测试用例和mock数据后，可以根据获取到的测试用例和mock数据、测试用例和mock数据之间的一一对应关系以及测试用例和待测单元的测试方法之间的一一对应关系，生成单元测试计划。由于在生成单元测试计划时，可以从中间件中获取已经匹配好的测试用例和mock数据，因此可以提高数据获取效率，此外，由于可以基于已经匹配好的测试用例和mock数据之间的对应关系以及测试用例和测试方法之间的对应关系生成单元测试计划，因此可以快速生成单元测试计划，同时还可以保证后续单元测试计划的成功执行。

在一种实现方式中，在上述S106中生成单元测试计划后，还可以执行以下步骤中的至少一项：

将mock数据中的目标mock数据存储到单元测试计划的上下文中，目标mock数据为执行单元测试计划的过程中使用次数大于或等于预设次数的mock数据；

将目标测试用例执行过程中产生的数据存储到单元测试计划的上下文中，目标测试用例为执行过程中产生的数据会被其他测试用例使用的测试用例。

在进行单元测试时，某一个或多个mock数据可能会被多次使用，在这种情况下，为了便于单元测试时使用这些mock数据，可以将这些mock数据存储单元测试计划的上下文中，这样，当需要使用这些mock数据时，可以直接从上下文中读取即可。其中，上述预设次数可以根据实际情况进行设置，这里不做具体限定。

此外，在进行单元测试时，某一个或多个测试用例执行过程中产生的数据可能会被后一个或多个测试用例使用，在这种情况下，为了便于该一个或多个测试用例执行过程中产生的数据被其他测试用例使用，也可以将该一个或多个测试用例执行过程中产生的数据存储单元测试计划的上下文中，这样，当其他测试用例需要使用该一个或多个测试用例执行过程中产生的数据时，直接从上下文中读取即可。例如，测试用例A需要读取测试用例B执行过程中的某个结果的返回，那么在执行测试计划的时候就会将B的结果放入上下文中，会贯穿整个测试过程，直到执行结束。需要说明的是，若测试用例执行过程产生的数据会被结构型数据库存储，则可以将测试用例执行过程中产生的数据以结构型的方式存储到单元测试计划的上下文中。

在一种实现方式中，在生成单元测试计划之前，还可以执行以下步骤：

获取预配置的SQL文件，SQL文件中包括单元测试计划执行过程中使用的数据；

执行SQL文件，根据SQL文件中的数据生成数据表。

具体地，考虑到单元测试计划执行时会依赖一些既有数据，因此可以将这些既有数据预置到数据库中，以便在执行单元测试计划时使用，而SQL文件就是预置数据到数据库中的一种文件格式。其中，既有数据也可以理解为预备数据，是单元测试计划执行过程中会用到的数据，即SQL文件中可以存储单元测试计划执行过程中会使用的数据。

在将既有数据预置到SQL文件中后，在生成单元测试计划之前会自动读取并加载SQL文件。在加载SQL文件后，可以执行SQL文件以获取SQL文件中的数据，然后根据SQL文件中的数据生成一个或多个数据表，即将SQL文件中的数据存放到一个或多个数据表中。其中，在读取SQL文件时，可以判断SQL文件是否满足语法需求，若满足，则认为SQL文件合法并加载SQL文件，若不满足，则认为SQL文件不合法且不加载SQL文件。这里仅以SQL文件合法为例进行说明。

在根据SQL文件中的数据生成数据表后，在执行单元测试计划时，可以根据数据表中的数据执行该单元测试计划。具体的，在执行单元测试计划的过程中，可以从数据表中获取需要的数据，此外，也可以将单元测试计划执行过程中生成的数据存放到数据表中，以便在后续执行单元测试计划的过程中，若有需要可以从数据表相应数据。

本申请实施例在进行单元测试时，可以自动识别读取和解析预先配置的用于单元测试的元数据文件，通过配置文件的形式来确保整个单元测试的稳定性、可维护性和可持续化，同时也通过使用配置文件的形式来帮助开发人员专注与测试逻辑的编写。其中，在生成单元测试时，重点在于将配置文件中的数据与单元测试的一一匹配，只有在匹配成功之后整个测试计划才能正常的执行，也就是说，本申请实施例对元数据文件中的测试用例和mock数据的清洗(即将测试用例和mock数据进行一一对应，将测试用例和测试方法进行一一对应)以及基于测试用例和mock数据生成单元测试计划，在本申请实施例提供的技术方案中起支撑作用。

在一种实现方式中，上述S102中的预先配置的元数据文件中还可以包括断言数据，该断言数据用于对单元测试计划的执行进行断言，以供用户基于断言结果定位问题和发现问题。断言数据中可以包括断言类型、断言期望值、断言序号和断言结果失败的错误提示信息中的至少一项。断言类型用于定义判断期望值和实际值的方法，如equals、isTrue、isFalse和timeout等断言类型。断言序号用于指定当前断言规则用于哪一个断言。

在元数据文件中包括断言数据的情况下，在对元数据文件进行解析并得到断言数据后，还可以对断言数据进行数据清洗。断言是判断一个单元测试是否成功的条件，而断言中又分为期望值、实际值和断言行为，本申请实施例关注的是期望值和断言行为的处理，因为实际值就是单元测试的执行结果，断言行为在两值相等、是否为空和真假判断等基础行为之上，又增加了超时校验和重复压测等扩展行为。这样，在对断言数据进行数据清洗时，可以根据断言数据确定断言行为，然后将断言行为按照既定顺序进行排列组合即可，这里的排列组合可以理解为将断言行为翻译成机器能懂的语言。

在对断言数据进行数据清洗后，在执行单元测试计划后，可以根据清洗后的断言数据对单元测试计划的执行结果进行断言，即根据上述排列组合后的断言行为对单元测试计划的执行结果进行断言，得到断言结果。可选地，在得到断言结果后，可以生成执行报告，执行报告可以供用户查看单元测试的结果，同时还可以根据断言结果定位问题和发现问题。在输出执行报告之后系统会立马进入清理善后完成所剩下的收尾工作。

图2是本申请的一个实施例单元测试方法的流程示意图，图2所示的实施例以元数据文件中包括测试用例、mock数据以及断言数据为例进行说明，图2所示的实施例可以包括以下步骤。

S201：根据待测单元对应的类的类名，从指定目录下获取文件名与该类名相同的元数据文件。

S202：解析元数据文件，得到元数据文件中包括的测试用例、mock数据和断言数据。

测试用例中包括待测单元方法名称、测试环境、输入数据和参考结果，mock数据中包括与mock的数据对应的方法以及mock的具体数据，断言数据中包括断言类型、断言期望值、断言序号和断言结果失败的错误提示信息中的至少一项，具体可以参见图1所示实施例中对测试用例、mock数据和断言数据的详细说明，这里不再重复描述。

S203：将测试用例和mock数据进行一一对应。

S204：将测试用例和待测单元的测试方法进行一一对应。

S205：将断言数据对应的断言行为按照既定顺序排列组合。

S203至S205可以并行执行，或者不限定先后执行顺序。

S206：将测试用例和mock数据对应存储到中间件中，将测试用例和待测单元的测试方法对应存储到中间件中，将排列组合后的断言行为存储到中间件中。

S207：根据待测单元对应的类的类名，从中间件中获取与类名对应的测试用例和mock数据。

S208：根据测试用例、mock数据、测试用例和mock数据之间的对应关系以及测试用例和待测单元的测试方法之间的对应关系，生成单元测试计划。

S209：执行单元测试计划，得到执行结果。

S210：根据排列组合后的断言行为对单元测试计划的执行结果进行断言，得到断言结果并生成执行报告。

上述S201至S210的具体实现方式可以参见图1所示实施例中相应步骤的具体实现，且可以实现相应的技术效果，这里不再详细说明。

图3是本申请的一个实施例单元测试方法的流程示意图，图3所示的实施例以元数据文件中包括测试用例、mock数据以及断言数据为例进行说明，图3所示实施例中的各个步骤可以与图2所述实施例中的各个步骤相对应，具体可以包括以下步骤。

步骤1：从指定目录下拉取文件，得到单元测试元数据(即元数据文件)。此步骤可以对应图2所示实施例中的S201。

步骤2：解析元数据，得到单元测试用例、mock数据和断言配置。此步骤可以对应图2所示实施例中的S202。

步骤3：将解析到的数据加载到存储中间件中。此步骤可以对应图2所示实施例中的S203至S206。

步骤4：根据存储中间件中存储的数据匹配单元测试代码，生成单元测试计划。此步骤可以对应图2所示实施例中的S207和S208。

步骤5：执行单元测试得到执行结果。此步骤可以对应图2所示实施例中的S209。

步骤6：使用断言数据对执行结果进行自动断言判断，生成执行报告，并清楚所有执行数据，结束单元测试。此步骤可以对应图2所示实施例中的S210。

本申请实施例提供的技术方案，在对待测单元进行单元测试时，由于可以将单元测试所需的测试用例和mock数据预先配置到元数据文件中，并在生成单元测试计划时，通过解析元数据文件来获取测试用例和mock数据进而生成单元测试计划，因此，在进行单元测试时可以无需每次编写测试用例，也无需编写mock代码，直接从元数据文件中获取相应数据即可，极大降低了单元测试的编写难度，提高了单元测试的测试效率。此外，由于可以通过元数据文件统一配置单元测试所需的测试用例和mock数据，因此，可以便于对测试用例和mock数据的统一管理和维护，进而保证整个单元测试的稳定性、可维护性和可持续化。

图4是本申请的一个实施例单元测试方法的流程示意图。基于图4所示的流程图，在一种典型的应用场景中，本申请实施例提供的单元测试方法的具体实现方式如下：

步骤1：根据待测功能内部的逻辑编写单元测试方法，即图4所示流程图中使用虚线框起来的部分。这里编写的单元测试方法是后续配置文件(即元数据文件)中测试用例、mock数据和断言条件作用的主体，换言之，配置文件中所有的数据都为该测试方法服务。

步骤2：在编写完具体的单元测试方法之后，就需要根据单元测试配置测试用例、mock数据和断言数据，即配置图4所示流程图中的配置文件。这里特别需要注意的是，配置文件需和单元测试所在类的类名一致，且每个测试用例需配置对应的单元测试名(即待测单元方法名称)，以便在生成执行计划时将单元测试和配置文件数据匹配对应。

其中，测试用例需要配置当前测试用例的数据和参考值，以及是否依赖某个其它数据等等，重点需要关注测试用例的数据和参考值的格式，参考值主要以基础数据类型和JSON为主，测试用例可以配置junit5支持的格式和JSON，极大地满足开发人员对不同数据类型的需求。

此外，断言条件同样可以配置junit5支持所有种类的断言条件，同时还可以配置压测次数超时限制和执行过程中数据产生是否合法的校验等等扩展断言条件。

步骤3：在配置完成配置文件后，配置文件读取和解析器就会介入，并执行图4所示流程图中的读取配置文件和数据解析的步骤。具体而言，可以由用户启动测试，系统收到启动命令便会自动查找配置文件并对配置文件进行解析和清洗。在得到清洗数据后，单元测试执行计划生成器会介入，该生成器会把单元测试方法和配置数据一一匹配进而生成具体的执行计划(即单元测试计划)，然后将执行计划放入队列中，等待执行器执行。

步骤4：执行器从队列中取出执行计划并执行，在执行过程中会记录各个测试用例的执行结果，最后将所有执行结果汇总生成对应的执行报告。之后，可以启动清理善后程序，清理一切数据和缓存。

现有技术中测试用例和mock数据很难统一维护，一旦其中有个单元测试的环境出错就无法继续进行，无法保证整个单元测试的完整性，且随着需求的变化，单元测试也会随之变化，现有技术很难做到单元测试的长期可持续化。本申请实施例能够很好的解决以上问题，极大的提高了开发人员编写单元测试的效率和完善单元测试框架可支持的测试功能。此外，本申请实施例中使用配置文件统一维护测试用例，且所有的测试用例、mock数据和断言条件都可通过配置文件统一配置和维护，并且可以以jar包的方式打入需测试的项目，然后按照既定接口编写固定单元测试方法即可，同时还提供独立运行功能，从而极大的降低了单元测试编写的难度、提高了测试用例维护的可行性、保证了整个单元测试的可持续化。

本申请实施例提供了一种基于文件驱动的单元测试方法，excel或者csv文件(即元数据文件)可以作为单元测试元数据(即测试用例)、mock数据和断言条件的供应商，单元测试执行计划共享供应商提供的元数据和mock数据，并将供应商提供的断言条件作为执行计划中各单元测试的判断依据，帮助生成对应的执行报告。在保留单元测试现有规则特征的大前提下，本申请实施例还提供了一套基于元数据、mock数据和断言条件的动态单元测试框架。在进行单元测试时，首先通过文件解析框架解析对应目录下的元数据文件，获取单元测试元数据、mock数据和断言条件，然后动态单元测试框架根据文件指定测试功能、单元测试元数据和mock数据动态生成单元测试执行计划，最后将单元测试执行计划交给执行器执行，在执行的过程中按照解析出来的断言信息进行断言判断，最终生成执行报告。

需要说明的是，本申请实施例较为关键的一点就在于对Junit 5相关功能的扩展，比如使用Junit 5提供的TestExecutionExceptionHandler接口对测试异常的扩展处理、对LifecycleMethodExecutionExceptionHandler接口的扩展实现对测试生命周期的处理、对TestTemplateInvocationContextProvider接口的扩展来为测试模板提供调用上下文、对TestInstancePreDestroyCallback接口的扩展自定义测试实例销毁前的回调、通过@EnabledIf和@DisabledIf来自定义启用和禁用条件和对MethodOrderer接口的扩展自定义单元测试的执行顺序等等，其它Junit 5提供的扩展机制和接口可以使得本申请实施例提供的技术方案对处理单元测试具有更强的能力。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图5是本申请的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成单元测试装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

执行所述单元测试计划，得到所述单元测试计划的执行结果。

上述如本申请图5所示实施例揭示的单元测试装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1至图4的方法，并实现单元测试装置在图1至图4所示实施例中的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1至图4所示实施例的方法，并具体用于执行以下操作：

从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

执行所述单元测试计划，得到所述单元测试计划的执行结果。

图6是本申请的一个实施例单元测试装置60的结构示意图。请参考图6，在一种软件实施方式中，所述单元测试装置60可包括：获取模块61、解析模块62、测试计划生成模块63和测试模块64，其中：

获取模块61，从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

解析模块62，对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

测试计划生成模块63，根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

测试模块64，执行所述单元测试计划，得到所述单元测试计划的执行结果。

可选地，所述元数据文件的文件名与所述待测单元对应的类的类名相同；

其中，所述获取模块61，从指定目录下获取预先配置的元数据文件，包括：

根据所述待测单元对应的类的类名，从所述指定目录下获取文件名与所述类名相同的元数据文件。

可选地，所述测试用例中包括待测单元方法名称、测试环境、输入数据和参考结果；

其中，所述待测单元方法名称与所述测试用例所服务的测试方法的方法名相同；

所述输入数据表征待测单元的入参，所述输入数据的数据来源包括简单值域、枚举值域、指定方法来源、csv格式数据来源、csv文件来源以及JSON字符串来源中的至少一项。

可选地，所述mock数据中包括与mock的数据对应的方法以及mock的具体数据。

可选地，不同的测试用例对应不同的mock数据，不同的测试用例服务于所述待测单元的不同测试方法；

其中，所述解析模块62，在对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据后：

将所述测试用例和所述mock数据进行一一对应；

将所述测试用例和所述待测单元的测试方法进行一一对应。

可选地，所述解析模块62，将所述测试用例和所述待测单元的测试方法进行一一对应，包括：

根据所述待测单元的目标测试方法的方法名从所述测试用例中确定目标测试用例，所述目标测试用例对应的待测单元方法名称和所述目标测试方法的方法名相同；将所述目标测试用例和所述目标测试方法进行一一对应；或，

从所述目标测试用例中确定具有预设参数个数和预设参数类型的第一目标测试用例；将所述第一目标测试用例和所述目标测试方法进行一一对应。

可选地，所述解析模块62，还按照所述待测单元对应的类的类名，将所述测试用例和所述mock数据对应存储到中间件中，以及将所述测试用例和所述待测单元的测试方法对应存储到所述中间件中。

可选地，所述测试计划生成模块63，根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划，包括：

根据所述待测单元对应的类的类名，从所述中间件中获取与所述类名对应的所述测试用例和所述mock数据；

根据所述测试用例、所述mock数据、所述测试用例和所述mock数据之间的对应关系以及所述测试用例和所述待测单元的测试方法之间的对应关系，生成所述单元测试计划。

可选地，所述测试计划生成模块63，在生成单元测试计划后，还包括以下至少一项：

将所述mock数据中的目标mock数据存储到所述单元测试计划的上下文中，所述目标mock数据为执行所述单元测试计划的过程中使用次数大于或等于预设次数的mock数据；

将目标测试用例执行过程中产生的数据存储到所述单元测试计划的上下文中，所述目标测试用例为执行过程中产生的数据会被其他测试用例使用的测试用例。

可选地，所述测试计划生成模块63，在生成所述单元测试计划之前，获取预配置的SQL文件，所述SQL文件中包括所述单元测试计划执行过程中使用的数据；

执行所述SQL文件，根据所述SQL文件中的数据生成数据表；

其中，所述执测试模块64，执行所述单元测试计划，包括：

根据所述数据表中的数据执行所述单元测试计划。

可选地，所述元数据文件中还包括断言数据，所述断言数据中包括断言类型、断言期望值、断言序号和断言结果失败的错误提示信息中的至少一项；

其中，所述测试模块64，在得到所述单元测试计划的执行结果后，根据所述断言数据对所述单元测试计划的执行结果进行断言，得到断言结果。

本申请实施例提供的单元测试装置60还可执行图1至图4的方法，并实现单元测试装置在图1至图4所示实施例的功能，本申请实施例在此不再赘述。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (14)

1.一种单元测试方法，其特征在于，包括：

从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

执行所述单元测试计划，得到所述单元测试计划的执行结果。

2.如权利要求1所述的单元测试方法，其特征在于，所述元数据文件的文件名与所述待测单元对应的类的类名相同；

其中，所述从指定目录下获取预先配置的元数据文件，包括：

根据所述待测单元对应的类的类名，从所述指定目录下获取文件名与所述类名相同的元数据文件。

3.如权利要求1所述的单元测试方法，其特征在于，

所述测试用例中包括待测单元方法名称、测试环境、输入数据和参考结果；

其中，所述待测单元方法名称与所述测试用例所服务的测试方法的方法名相同；

所述输入数据表征待测单元的入参，所述输入数据的数据来源包括简单值域、枚举值域、指定方法来源、csv格式数据来源、csv文件来源以及JSON字符串来源中的至少一项。

4.如权利要求1所述的单元测试方法，其特征在于，

所述mock数据中包括与mock的数据对应的方法以及mock的具体数据。

5.如权利要求1所述的单元测试方法，其特征在于，不同的测试用例对应不同的mock数据，不同的测试用例服务于所述待测单元的不同测试方法；

其中，在对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据后，所述方法还包括：

将所述测试用例和所述mock数据进行一一对应；

将所述测试用例和所述待测单元的测试方法进行一一对应。

6.如权利要求5所述的单元测试方法，其特征在于，将所述测试用例和所述待测单元的测试方法进行一一对应，包括：

根据所述待测单元的目标测试方法的方法名从所述测试用例中确定目标测试用例，所述目标测试用例对应的待测单元方法名称和所述目标测试方法的方法名相同；将所述目标测试用例和所述目标测试方法进行一一对应；或，

从所述目标测试用例中确定具有预设参数个数和预设参数类型的第一目标测试用例；将所述第一目标测试用例和所述目标测试方法进行一一对应。

7.如权利要求5所述的单元测试方法，其特征在于，所述方法还包括：

按照所述待测单元对应的类的类名，将所述测试用例和所述mock数据对应存储到中间件中，以及将所述测试用例和所述待测单元的测试方法对应存储到所述中间件中。

8.如权利要求7所述的单元测试方法，其特征在于，所述根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划，包括：

根据所述待测单元对应的类的类名，从所述中间件中获取与所述类名对应的所述测试用例和所述mock数据；

根据所述测试用例、所述mock数据、所述测试用例和所述mock数据之间的对应关系以及所述测试用例和所述待测单元的测试方法之间的对应关系，生成所述单元测试计划。

9.如权利要求1所述的单元测试方法，其特征在于，在生成单元测试计划后，所述方法还包括以下至少一项：

将所述mock数据中的目标mock数据存储到所述单元测试计划的上下文中，所述目标mock数据为执行所述单元测试计划的过程中使用次数大于或等于预设次数的mock数据；

将目标测试用例执行过程中产生的数据存储到所述单元测试计划的上下文中，所述目标测试用例为执行过程中产生的数据会被其他测试用例使用的测试用例。

10.如权利要求1所述的单元测试方法，其特征在于，在生成所述单元测试计划之前，所述方法还包括：

获取预配置的SQL文件，所述SQL文件中包括所述单元测试计划执行过程中使用的数据；

执行所述SQL文件，根据所述SQL文件中的数据生成数据表；

其中，所述执行所述单元测试计划，包括：

根据所述数据表中的数据执行所述单元测试计划。

11.如权利要求1所述的单元测试方法，其特征在于，所述元数据文件中还包括断言数据，所述断言数据中包括断言类型、断言期望值、断言序号和断言结果失败的错误提示信息中的至少一项；

其中，在得到所述单元测试计划的执行结果后，所述方法还包括：

根据所述断言数据对所述单元测试计划的执行结果进行断言，得到断言结果。

12.一种单元测试装置，其特征在于，包括：

获取模块，从指定目录下获取预先配置的元数据文件，所述元数据文件中包括对待测单元进行单元测试所需的测试用例和mock数据；

解析模块，对所述元数据文件进行解析，得到所述元数据文件中包括的测试用例和mock数据；

测试计划生成模块，根据所述测试用例、所述mock数据以及所述待测单元的测试方法生成单元测试计划；

测试模块，执行所述单元测试计划，得到所述单元测试计划的执行结果。

13.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至11中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至11中任一项所述的方法。

Images