一种测试用例运行方法及装置与流程

本发明属于测试技术领域，更具体地说，尤其涉及一种测试用例运行方法及装置。

背景技术：

测试用例是为测试某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径是否该特殊目标，因此测试用例是系统测试的核心所在。目前通常使用自然语言、结构化表格和编写脚本程序的方式描述测试用例，这三种方式编写程序脚本的方式最优，但是每次在修改测试用例时还需要修改脚本程序，增加测试用例的维护成本。

技术实现要素：

有鉴于此，本发明的目的在于提供一种测试用例运行方法及装置，用于降低测试用例的维护成本。技术方案如下：

本发明提供一种测试用例运行方法，所述方法包括：

获得用户使用自然语言编写的第一测试用例；

获得将所述第一测试用例形式化后得到的第二测试用例；

获得基于所述第二测试用例生成的配置文件；

对所述配置文件进行解析，得到所述配置文件中的语句，所述配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断；

执行所述配置文件中的语句，得到所述配置文件对应的能够被机器运行的测试用例的测试结果。

优选的，所述方法还包括：

获得用户对所述配置文件中待修改宏的修改，得到修改后的配置文件；

所述对所述配置文件进行解析，得到所述配置文件中的语句包括：对修改后的配置文件进行解析，得到所述修改后的配置文件中的语句。

优选的，所述对所述配置文件进行解析，得到所述配置文件中的语句包括：

构建所述配置文件的抽象语法树；

对所述抽象语法树中各个节点进行遍历，并在遍历过程中对各个节点的内容进行模式匹配，以确定所述各个节点的内容所代表的语句。

优选的，在构建所述配置文件的抽象语法树之前，还包括：对所述配置文件中的各条数据进行语法检查，若各条数据中任一条数据的语法有误，则输出提示信息；

若各条数据中任一条数据的语法正确，则触发执行构建所述配置文件的抽象语法树的步骤。

优选的，所述执行所述配置文件中的语句，得到所述配置文件对应的能够被机器运行的测试用例的测试结果包括：

将所述配置参数输入到所述输入命令中，并基于所述控制指令控制所述输入命令的执行；

获得所述输入命令执行后得到的输出数据，并基于所述输出数据期望判断逻辑对所述输出数据进行判断，得到所述输出数据的判断结果，所述输出数据的判断结果用于表明所述配置文件对应的能够被机器运行的测试用例的测试结果。

本发明还提供一种测试用例运行装置，所述装置包括：

用例获得单元，用于获得用户使用自然语言编写的第一测试用例，以及获得将所述第一测试用例形式化后得到的第二测试用例；

文件获得单元，用于获得基于所述第二测试用例生成的配置文件；

解析单元，用于对所述配置文件进行解析，得到所述配置文件中的语句，所述配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断；

执行单元，用于执行所述配置文件中的语句，得到所述配置文件对应的能够被机器运行的测试用例的测试结果。

优选的，所述文件获得单元，用于获得用户对所述配置文件中待修改宏的修改，得到修改后的配置文件；

所述解析单元，用于对修改后的配置文件进行解析，得到所述修改后的配置文件中的语句。

优选的，所述解析单元，用于构建所述配置文件的抽象语法树，并对所述抽象语法树中各个节点进行遍历，并在遍历过程中对各个节点的内容进行模式匹配，以确定所述各个节点的内容所代表的语句；

和/或

所述执行单元，用于将所述配置参数输入到所述输入命令中，并基于所述控制指令控制所述输入命令的执行，获得所述输入命令执行后得到的输出数据，并基于所述输出数据期望判断逻辑对所述输出数据进行判断，得到所述输出数据的判断结果，所述输出数据的判断结果用于表明所述配置文件对应的能够被机器运行的测试用例的测试结果。

本发明还提供一种处理器，所述处理器用于运行程序，所述程序运行时执行上述测试用例运行方法。

本发明还提供一种存储介质，所述存储介质上存储有计算机程序代码，所述计算机程序代码运行时实现上述测试用例运行方法。

从上述技术方案可知，在获得第二测试用例后，可以获得基于第二测试用例生成的配置文件，对配置文件进行解析，得到配置文件中的语句，执行配置文件中的语句，得到配置文件对应的能够被机器运行的测试用例的测试结果，这样就可通过执行配置文件中的语句的方式实现对能够被机器运行的测试用例的自动执行以及测试结果的自动获得，省去了手动触发测试用例执行的步骤。并且配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断，这就意味着配置文件可以体现测试用例的全部逻辑，因此在需要修改测试用例时仅需要修改配置文件即可，从而降低测试用例的维护成本。

附图说明

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

图1是本发明实施例提供的一种测试用例运行方法的流程图；

图2是本发明实施例提供的一种配置文件的示意图；

图3和图4是图2所示配置文件的抽象语法树；

图5是本发明实施例提供的另一种测试用例运行方法的流程图；

图6是本发明实施例提供的待修改宏修改的示意图；

图7是本发明实施例提供的一种测试用例运行装置的结构示意图。

具体实施方式

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

请参阅图1，其示出了本发明实施例提供的一种测试用例运行方法的流程图，用于降低测试用例的维护成本，可以包括以下步骤：

101：获得用户使用自然语言编写的第一测试用例。可以理解的是：所谓自然语言是一种自然地随文化演化的语言，如常用的汉语、英语等均是一种自然语言，该自然语言是测试人员(用户)在编写测试用例时常用的一种语言，通过自然语言编写的第一测试用例可便于不同测试人员理解该第一测试用例的测试目的，如表1所示，示出了一种使用自然语言编写的第一测试用例，该第一测试用例用于测试网络协议之maclearning。

表1使用自然语言编写的第一测试用例

但是第一测试用例在逻辑上容易产生歧义，因此使用自然语言编写的第一测试用例具有模糊性和歧义性，而且很难支持测试用例的自动化，为此需要对使用自然语言编写的第一测试用例进行转换，以消除第一测试用例在模糊性和歧义性方面的问题。

102：获得将第一测试用例形式化后得到的第二测试用例。其中形式化是逻辑学中的一个术语，所谓形式化是指以严格逻辑化方式来描述测试用例，如在本实施例中，将第一测试用例以伪代码形式描述，得到以伪代码形式描述的第二测试用例，以消除使用自然语言描述的第一测试用例的歧义性。

例如对上述表1所示的第一测试用例的伪代码形式如下：

103：获得基于第二测试用例生成的配置文件。在该配置文件中除需要写入配置参数之外，还需要写入输入命令、控制指令和输出数据期望逻辑判断，其中输入命令是测试用例针对的测试设备的各条命令，控制指令则是用于控制输入命令的执行逻辑以及输入命令执行正确性判断，输出数据期望逻辑判断则是对输入命令执行后得到的输出数据是否符合预期的判断，在实际应用中还可以指定输出数据对应的数据结构，使得配置文件不单单记录配置文件，还体现出测试用例的全部逻辑。

在本实施例中，配置文件可以但不限于josn格式，例如针对上述第二测试用例，其对应josn格式的配置文件如图2所示，在图2所示的json格式的配置文件以key-value不断嵌套的方式描述能够被机器运行的测试用例，其中每条输入命令step是多条命令的集合，每条输入命令step定义了返回提示符prompt、执行时间timeout、返回值(即输出数据)匹配match等等，其中match支持正则表达式，如果输入命令没有定义这些参数则按照默认参数设置，默认参数是在输入命令所在层级之上的共有层级来人为设置，此外对于针对复杂的循环操作在step中还可以加入循环控制命令。

配置文件中的control部分为控制step之间的执行逻辑的控制指令，parse部分为命令返回值解析，该命令返回值解析是指将每个step执行得到的输出数据域match匹配后，将匹配的输出数据存储某个数据结构中，如存储在数据结构map中。expect部分是期望逻辑条件表达式，以通过expect部分判断一个测试用例是否测试成功，如expect部分是一个期望值的逻辑表达式的有序集合，通过将parse部分得到的输出数据域except部分的逻辑表达式进行比对来确定测试用例是否测试成功，因此上述配置文件中的parse部分和expect部分为配置文件中的输出数据期望逻辑判断。

如图2所示except部分通过逻辑表达式给出两个判断条件，一个是对发包仪器端口2(ixia_port2)和端口3(ixia_port3)计数器值之和的限制，另外一个是对发包仪器端口1(ixia_port1)和对发包仪器端口3(ixia_port3)的计数器值的限制，而这些计数器值则是parse部分得到的输出数据，若parse部分得到的输出数据符合判断条件，则说明测试用例测试成功，否则测试失败。

104：对配置文件进行解析，得到配置文件中的语句。在本实施例中，得到配置文件中的语句的一种方式可以是：构建配置文件的抽象语法树，对抽象语法树中各个节点进行遍历，并在遍历过程中对各个节点的内容进行模式匹配，以确定各个节点的内容所代表的语句。

其中构建配置文件的抽象语法树的过程可参见现有抽象语法树的构建过程，对此本实施例不在阐述，如图3和图4所示，其示出了上述图2所示配置文件的部分抽象语法树。

在得到抽象语法树后可以基于遍历算法对抽象语法树中的各个节点进行遍历，如基于从左到右的遍历算法进行遍历，在遍历过程中可通过正则表达式方式对各个节点的内容进行模式匹配，以确定各个节点的内容所代表的语句，如上述配置参数、输入命令、控制指令和输出数据期望逻辑判断等，对于正则表达式进行模式匹配的过程本实施例不在阐述。

在这里需要说明的一点是：在构建配置文件的抽象语法树之前，需要对配置文件中的各条数据(如配置文件中的字段或由字段组成的一段代码)进行语法检查，若各条数据中任一条数据的语法有误，则输出提示信息；若各条数据中任一条数据的语法正确，则触发执行构建配置文件的抽象语法树，这样在执行配置文件的语句时降低因语法错误导致的测试失败。

105：执行配置文件中的语句，得到配置文件对应的能够被机器运行的测试用例的测试结果。如将配置参数输入到输入命令中，并基于控制指令控制输入命令的执行，获得输入命令执行后得到的输出数据，并基于输出数据期望判断逻辑对输出数据进行判断，得到输出数据的判断结果，其中输出数据的判断结果用于表明配置文件对应的能够被机器运行的测试用例的测试结果。

仍以上述图2所示配置文件为例，对于配置文件中包含cmd的语句中，cmds_cli对应测试用例对应的待测设备的输入命令，而cmds_ixia对应测试用例对应的发包仪器的输入命令，在执行输入命令时将配置参数，如图4中的1、10、cli、success输入到输入命令中，然后每执行完一个step后根据control字段后控制指令来判断下一步step；每执行完一个step将该step的数据输出到paesr部分给出的数据结构中，如输出到数据结构map中存储。比如语句“getixia_port1_numrxasixia_port1_num”，其含义是获取ixia发包仪器端口1的计数器并保存在变量ixia_port1_num，语句“getixia_port3_numrxasixia_port3_num_1”，其含义是获取ixia发包仪器端口3的计数器值并保存在变量ixia_port3_num_1，则数据结构map为{‘ixia_port1_num’‘1000’,‘ixia_port3_num_1’‘0’}。

在所有step执行完成后基于expect部分给出的逻辑表达式对数据结构map中存储的数据进行判断，若每个逻辑表达式得到的判断结果为真，则表明测试成功，若每个逻辑表达式中有一个逻辑表达式得到的判断结果为假，则表明测试失败。

在本实施例中，步骤104和步骤105可借助于一个解释器来实现，该解释器基于clojure语言，使得解释器基于clojure语言中宏的优势，使得在解释器执行上述步骤104和105的过程中可以对配置文件中的描述进行动态修改。

从上述技术方案可知，在获得第二测试用例后，可以获得基于第二测试用例生成的配置文件，对配置文件进行解析，得到配置文件中的语句，执行配置文件中的语句，得到配置文件对应的能够被机器运行的测试用例的测试结果，这样就可通过执行配置文件中的语句的方式实现对能够被机器运行的测试用例的自动执行以及测试结果的自动获得，省去了手动触发测试用例执行的步骤。并且配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断，这就意味着配置文件可以体现测试用例的全部逻辑，因此在需要修改测试用例时仅需要修改配置文件即可，从而降低测试用例的维护成本。

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

501：获得用户使用自然语言编写的第一测试用例。

502：获得将第一测试用例形式化后得到的第二测试用例。

503：获得基于第二测试用例生成的配置文件。

在本实施例中，步骤501至503：与上述步骤101至103相同，对此本实施例不在阐述。

504：获得用户对配置文件中待修改宏的修改，得到修改后的配置文件。之所以需要修改是为了使得配置文件更符合测试人员的认知，便于测试人员进行代码开发以实现测试用例的自动化，在本实施例中待修改宏是由测试人员指定的并修改。也就是说配置文件中的哪些语句(可以视为是待修改宏)需要修改和修改后的内容是什么均由测试人员指定。

例如if语句的语法为(iflogical-expressionexpression)，但是有时为了使得语法表示更加直观一些，将if语句替换为when语句即(whenlogical-expressionexpression)，此时就需要用defmacro这个关键字来重新定义个宏when来对if语句指示的功能进行修改。循环语句通常采用recur的形式来递归，但是有时会出现不知道recur为循环语句的情况，因此可以将其修改为测试人员熟悉的编程语言中的foreach语法，遍历某个可迭代对象并应用于body语句体中，如图6所示，这样就可以构建简洁清晰的符合测试人员要求的语法结构。

505：对修改后的配置文件进行解析，得到修改后的配置文件中的语句。

506：执行修改后的配置文件中的语句，得到修改后的配置文件对应的能够被机器运行的测试用例的测试结果。在本实施例中，步骤505和506请参阅上述方法实施例中的相关说明，对此本实施例不再阐述。

从上述技术方案可知，通过对配置文件中待修改宏的修改，使得修改后的配置文件符合测试人员要求的语法结构，以便于测试人员的理解，此外通过待修改宏的修改还可以将配置文件中冗余和冗长的代码进行修改，以缩减代码行和重复代码。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

与上述方法实施例相对应，本发明实施例还提供一种测试用例运行装置，其结构如图7所示，可以包括：用例获得单元11、文件获得单元12、解析单元13和执行单元14。

用例获得单元11，用于获得用户使用自然语言编写的第一测试用例，以及获得将第一测试用例形式化后得到的第二测试用例。

可以理解的是：所谓自然语言是一种自然地随文化演化的语言，如常用的汉语、英语等均是一种自然语言，该自然语言是测试人员(用户)在编写测试用例时常用的一种语言，通过自然语言编写的第一测试用例可便于不同测试人员理解该第一测试用例的测试目的。

但是使用自然语言编写的第一测试用例在逻辑上容易产生歧义，因此使用自然语言编写的第一测试用例具有模糊性和歧义性，而且很难支持测试用例的自动化，为此需要对使用自然语言编写的第一测试用例进行转换，以消除第一测试用例在模糊性和歧义性方面的问题。

其中形式化是逻辑学中的一个术语，所谓形式化是指以严格逻辑化方式来描述测试用例，如在本实施例中，将第一测试用例以伪代码形式描述，得到以伪代码形式描述的第二测试用例，以消除使用自然语言描述的第一测试用例的歧义性。

文件获得单元12，用于获得基于第二测试用例生成的配置文件。在该配置文件中除需要写入配置参数之外，还需要写入输入命令、控制指令和输出数据期望逻辑判断，其中输入命令是测试用例针对的测试设备的各条命令，控制指令则是用于控制输入命令的执行逻辑以及输入命令执行正确性判断，输出数据期望逻辑判断则是对输入命令执行后得到的输出数据是否符合预期的判断，在实际应用中还可以指定输出数据对应的数据结构，使得配置文件不单单记录配置文件，还体现出测试用例的全部逻辑。

在本实施例中，配置文件可以但不限于josn格式，具体请参阅上述方法实施例中的相关说明，对此本实施例不再阐述。

解析单元13，用于对配置文件进行解析，得到配置文件中的语句，配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断。在本实施例中，得到配置文件中的语句的一种方式可以是：构建配置文件的抽象语法树，对抽象语法树中各个节点进行遍历，并在遍历过程中对各个节点的内容进行模式匹配，以确定各个节点的内容所代表的语句。

其中构建配置文件的抽象语法树的过程可参见现有抽象语法树的构建过程，对此本实施例不在阐述，在得到抽象语法树后可以基于遍历算法对抽象语法树中的各个节点进行遍历，如基于从左到右的遍历算法进行遍历，在遍历过程中可通过正则表达式方式对各个节点的内容进行模式匹配，以确定各个节点的内容所代表的语句，如上述配置参数、输入命令、控制指令和输出数据期望逻辑判断等，对于正则表达式进行模式匹配的过程本实施例不在阐述。

执行单元14，用于执行配置文件中的语句，得到配置文件对应的能够被机器运行的测试用例的测试结果。如将配置参数输入到输入命令中，并基于控制指令控制输入命令的执行，获得输入命令执行后得到的输出数据，并基于输出数据期望判断逻辑对输出数据进行判断，得到输出数据的判断结果，其中输出数据的判断结果用于表明配置文件对应的能够被机器运行的测试用例的测试结果。

从上述技术方案可知，在获得第二测试用例后，可以获得基于第二测试用例生成的配置文件，对配置文件进行解析，得到配置文件中的语句，执行配置文件中的语句，得到配置文件对应的能够被机器运行的测试用例的测试结果，这样就可通过执行配置文件中的语句的方式实现对能够被机器运行的测试用例的自动执行以及测试结果的自动获得，省去了手动触发测试用例执行的步骤。并且配置文件中的语句至少有：配置参数、输入命令、控制指令和输出数据期望逻辑判断，这就意味着配置文件可以体现测试用例的全部逻辑，因此在需要修改测试用例时仅需要修改配置文件即可，从而降低测试用例的维护成本。

此外，本实施例中的文件获得单元12，用于获得用户对配置文件中待修改宏的修改，得到修改后的配置文件。之所以需要修改是为了使得配置文件更符合测试人员的认知，便于测试人员进行代码开发以实现测试用例的自动化，在本实施例中待修改宏是由测试人员指定的并修改。也就是说配置文件中的哪些语句(可以视为是待修改宏)需要修改和修改后的内容是什么均由测试人员指定。在测试人员修改配置文件并上传之后，文件获得单元12即可以得到修改后的配置文件。相应的，解析单元13用于对修改后的配置文件进行解析，得到修改后的配置文件中的语句，具体过程请参阅方法实施例中的相关说明。

通过对配置文件中待修改宏的修改，使得修改后的配置文件符合测试人员要求的语法结构，以便于测试人员的理解，此外通过待修改宏的修改还可以将配置文件中冗余和冗长的代码进行修改，以缩减代码行和重复代码。

此外，本发明实施例还提供一种处理器，处理器用于运行程序，程序运行时执行上述测试用例运行方法。

本发明还实施例提供一种存储介质，存储介质上存储有计算机程序代码，计算机程序代码运行时实现上述测试用例运行方法。

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

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

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

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