CN104391796A - 一种测试用例解析方法 - Google Patents

Abstract

本发明提供一种测试用例解析方法，包括以下步骤：步骤S1、将测试用例文本逐行读入内存中；步骤S2、将单个测试用例片段拆分出来，每个测试用例片段作为单个元素依次写入链表caseList中；步骤S3、以链表caseList为输入，创建测试用例模型树；步骤S4、保存测试用例模型。本发明的测试用例解析方法不需要重复地复制测试用例文本；将分离出的测试用例模型以XML格式存储起来，便于二次开发和多样化呈现；任何应用程序只需要对测试用例模型进行编程就能很方便地操纵和传输测试用例文本。

Description

一种测试用例解析方法

技术领域

本发明涉及软件测试的技术领域，特别是涉及一种测试用例解析方法。

背景技术

测试用例(Test Case，TC)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。在自动化测试的开发过程中，测试脚本中往往包含测试用例说明，这部分文档事实上就是测试用例本身。

理论上来讲，当一个脚本开发完毕的同时，测试用例文本也应开发完毕。但是，问题在于，测试部的用例文本是存档在单独的库中的。如果测试用例文本需要镜像到多个不同的地点，就需要额外的同步动作。如果同时有不止一个工程师在开发测试用例文本，那么每个人都需要重复同样的动作，这势必造成巨大的浪费。

另外，在自动化测试工作在实施过程中不可避免地需要引入各种平台框架，这些平台框架通常都有自己的日志系统，其中信息部分都会需要测试用例文本作为支持。因此，对于多种平台框架，所需的测试用例文本呈现多样性的需要。

现有技术中，申请号为201110362223.9、发明名称为《测试用例与测试脚本同步的方法及装置》的中国专利中公开一种测试用例与测试脚本同步的方法，其包括：依次扫描测试脚本目录中包含的每一个测试脚本，确定该测试脚本发生变化时，获得该测试脚本的脚本信息，所述脚本信息包括脚本标识；根据预先存储的脚本标识与统一标识符的映射关系，查找所述脚本标识对应的统一标识符；将发生变化的测试脚本的脚本信息和查找到的统一标识符提交至用例管理TC系统，指示所述TC系统对自身存储的、所述统一标识符对应的测试用例与发生变化的测试脚本进行同步操作。由上可知，该申请是通过检测脚本变化从而在TC管理系统中进行标识，无法解决现有技术中测试用例文本多样性呈现和同步的问题。

另外，申请号为201310317357.8、发明名称为《一种基于XML的测试用例复用方法》的中国专利申请中公开一种基于XML的测试用例复用方法，其具体复用过程为：一、测试人员根据被测试软件的功能特点，定义需要的测试用例类型；二、根据所定义的测试用例从测试用例库中查找满足要寻求的测试用例；三、如果测试用例库中可以找到需要的测试用例，则从中提取出可复用的测试用例，程序结束；四、如果测试用例库中无法找到需要的测试用例，则设计此测试用例并用XML形式表示，验证其正确性，如果正确，添加到测试用例库中中，以便以后进行复用，程序结束。由上可知，该申请采用直接手动方式来编辑出XML测试用例，导致效率较低，操作较为复杂。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种测试用例解析方法，定义了一个标准的基于XML的测试用例模型(Test Case Model，TCM)，并提出了一种用于将某种特定格式的测试用例文本转化为TCM的方法，从而简化自动化测试开发的过程，提高工作效率。

为实现上述目的及其他相关目的，本发明提供一种测试用例解析方法，包括以下步骤：步骤S1、将测试用例文本逐行读入内存中；步骤S2、将单个测试用例片段拆分出来，每个测试用例片段作为单个元素依次写入链表caseList中；步骤S3、以链表caseList为输入，创建测试用例模型树；步骤S4、保存测试用例模型。

根据上述的测试用例解析方法，其中：所述测试用例文本须包括以下关键字：测试用例边界线、测试目标、测试case的位置、所在模块、脚本名字、测试步骤和测试结果；

所述测试用例边界线由若干个短划线“-”组成；

所述测试目标代表测试用例的测试标的，采用单行文本类型；

所述测试case的位置代表case存储位置，采用单行文本类型；

所述所在模块代表测试case文本属于哪个自动化测试模块，采用单行文本类型；

所述脚本名字代表所在测试脚本的名字，采用单行文本类型；

所述测试步骤代表一系列测试操作动作，采用多行文本类型；

所述测试结果代表一系列期望出现的结果标准值，采用多行文本类型。

进一步地，根据上述的测试用例解析方法，其中：所述步骤S2中，利用测试用例边界线将单个测试用例片段拆分出来。

根据上述的测试用例解析方法，其中：所述步骤S3中，循环读取链表caseList的元素，并将读取的元素解析后挂载到测试用例模型树根上来创建测试用例模型树。

根据上述的测试用例解析方法，其中：所述步骤S3中，创建测试用例模型树包括以下步骤：

步骤S41、创建空的测试用例模型；

步骤S42、判断从链表caseLine中获取一个元素是否成功，若是，转入步骤S43；若否，流程结束。

步骤S43、创建单个case子树，将新case子树挂载到测试用例模型树根上，转入步骤S42。

进一步地，根据上述的测试用例解析方法，其中：创建单个case子树时，对于单行文本信息，分别取出信息，将其制作成case子树的叶子；对于多行文本信息，转化成节点时，需要首先提取多行文本信息，再制作成步骤节点。

更进一步地，根据上述的测试用例解析方法，其中：提取多行文本信息时，利用首位行正则表达式匹配的方法，从单个测试用例文本中获取对应的多行片段。

根据上述的测试用例解析方法，其中：所述步骤S4中，测试用例模型保存到任意磁盘位置上。

根据上述的测试用例解析方法，其中：所述测试用例模型采用XML格式。

如上所述，本发明的测试用例解析方法，具有以下有益效果：

(1)不需要重复地复制测试用例文本；

(2)将分离出的测试用例文本以XML格式存储起来，便于二次开发和多样化呈现；

(3)任何应用程序只需要对TCM进行编程就能很方便地操纵和传输用例文本。

附图说明

图1显示为本发明的TCM模型的结构示意图；

图2显示为本发明的测试用例解析方法的流程图；

图3显示为本发明的裁剪用例的流程图；

图4显示为本发明的创建TCM树的流程图；

图5(a)显示为本发明的创建单个case子树的前半部分的流程图；

图5(b)显示为本发明的创建单个case子树的后半部分的流程图；

图6显示为本发明的提取多行文本的流程图；

图7显示为本发明的多行文本剪切的流程图；

图8显示为本发明的叶子结点生成的流程图。

图9(a)显示为本发明的制作步骤节点的前半部分流程图；

图9(b)显示为本发明的制作步骤节点的后半部分流程图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本发明的测试用例解析方法输入一份测试用例文本，输出是一份称之为TCM的XML格式的文本，从而为后续的测试用例的自动化管理提供标准模型。

下面将分别介绍作为输入的测试用例文本和作为输出的TCM。

具体地，测试用例文本的示例如下：

---------------------------------------------------------------------------------------------------------------

cdrouter_icmp_1

测试目标：验证ICMP Ping操作是否能正确通过无线路由器

测试case所在CDRouter位置：

所在模块：icmp.tcl

脚本名字：cdrouter_icmp_1

测试步骤：

步骤1：按照拓扑将CDRouter和被测设备连接。

从CDRouter LAN测192.168.2.101向Internet侧远端主机3.3.3.3发起ping10次。

步骤2：测试10ping响应是否均可以收到。

测试结果：

步骤1：抓包可以看到每次ping有两个ICMP Echo Request包可以抓到，一个是源IP192.168.2.101，第二个是经过路由器后转为源IP：192.168.200.2。

the first package：source IP：192.168.2.101，dst IP：3.3.3.3

the second package：source IP：192.168.200.2，dst IP：3.3.3.3

步骤2：10次ping响应ICMP Echo Reply均可以收到。

抓包可以看到每次ping有两个响应包，一个是接收者是路由器的WAN口(目的IP)是196.168.200.2，第二个是客户端侧(CDRouter LAN侧)IP是192.168.2.101

the first package：source IP：3.3.3.3，dst IP：192.168.200.2

the second package：source IP：3.3.3.3，dst IP：192.168.2.101

---------------------------------------------------------------------------------------------------------------

其中，需要说明的是，除了用例名和用例边界线之间不允许有空行之外，其他空行不受限。由于程序通过关键字捕获信息，所以测试用例文本中的关键字是不能够错的，共有7种，分别如下：

“-”：代表测试用例边界线，由若干个短划线“-”组成。

测试目标：代表测试用例的测试标的，采用单行文本类型。

测试用例(case)在CDRouter中的位置：代表case存储位置，采用单行文本类型。

所在模块：代表测试case文本属于哪个自动化测试模块；通常是一个脚本文件名字，采用单行文本类型。

脚本名字：代表所在测试脚本的名字，采用单行文本类型。

测试步骤：代表一系列测试操作动作，采用多行文本类型。其中，每个步骤关键字的后面跟着一个阿拉伯数字表示步骤序号，该序号不能是中文或罗马文字等其它类型的字符。

测试结果：代表一系列期望出现的结果标准值；通常与具体的测试步骤有关系，采用多行文本类型。

具体地，作为输出的TCM与测试用例文本相对应，TCM的具体示例如下：

其中，需要特别说明的是：

<all-case>：表示整个TCM的树根，其子节点均为case子树树根。“测试用例文本”中有多少用例，它就包含多少case子树；

<case>：表示单棵case子树的树根，是对测试用例文本的高度结构化抽象，其包含的是结构化了的单个测试用例文本信息。有了这个TCM，就可以很容易地对其进行应用编程；

<line>：表示单行步骤信息；图中虽然每个step子树仅仅包含一个line元素。但是实际上，具体包含多少个line，取决于“测试用例文本”中对应的“step_name”真正包含的文本行数，包括空行文本。

该TCM采用XML格式。

TCM的模型如图1所示，由图清晰地看出TCM的树形结构。

参照图2，本发明的测试用例解析方法包括以下步骤：

步骤S1、将测试用例文本逐行读入内存中。

具体地，将测试用例文本从计算机磁盘逐行读入内存中。

步骤S2、将单个测试用例片段拆分出来，每个测试用例片段作为单个元素依次写入链表caseLis中。

其中，利用测试用例边界线“----”将单个测试用例拆分出来。首先依次记录测试用例边界在文件中的读写指针的位置，并存入链表borderLocationList，然后依次循环读取相邻的测试用例片段。假设startFp，endFp分别为同一测试用例片段的上边界和下边界。控制文件读写指针移动到startFp位置上，开始读取文件内容，直到endFp为止。其间的文本即是测试用例片段。流程执行结果是生成了链表caseList。拆分测试用例片段的具体步骤如图3所所示。

步骤S3、以链表caseList为输入，创建TCM树。

其中，循环读取链表caseList的元素，并将其解析后挂载到TCM树根上来创建TCM树。参照图4，创建TCM树包括以下步骤：

步骤S41、创建空的TCM。

步骤S42、判断从链表caseLine中获取一个元素是否成功，若是，转入步骤S43；若否，流程结束。

步骤S43、创建单个case子树，将新case子树挂载到TCM树根上，转入步骤S42。

参照图5(a)和图5(b)，创建单个case子树时，对于测试目标、测试case所在CDRouter位置、所在模块、脚本名字等单行文本信息，分别取出信息，利用一个叫做“叶子结点生成”的流程，将其制作成case子树的叶子。对于测试步骤和测试结果等多行文本，转化成节点时，需要依次进行“提取多行文本”和“制作步骤节点”两个步骤，如图6和图9所示。

其中，提取多行文本主要就是利用首位行正则表达式匹配的方法，从单个测试用例文本lines中获取对应的多行片段。具体地，提取多行文本流程中调用了两个基本的子流程——“多行文本剪切”和“叶子结点生成”，参照图7和图8所示。这两个流程是基本流程，故在此不做详细描述。

步骤S4、保存TCM。

其中，TCM可以保存到任意磁盘位置上。

综上所述，本发明的测试用例解析方法不需要重复地复制测试用例文本；将分离出的测试用例文本以XML格式存储起来，便于二次开发和多样化呈现；任何应用程序只需要对TCM进行编程就能很方便地操纵和传输用例文本。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (9)

1.一种测试用例解析方法，其特征在于：包括以下步骤：

步骤S1、将测试用例文本逐行读入内存中；

步骤S2、将单个测试用例片段拆分出来，每个测试用例片段作为单个元素依次写入链表caseList中；

步骤S3、以链表caseList为输入，创建测试用例模型树；

步骤S4、保存测试用例模型。

2.根据权利要求1所述的测试用例解析方法，其特征在于：所述测试用例文本须包括以下关键字：测试用例边界线、测试目标、测试用例的位置、所在模块、脚本名字、测试步骤和测试结果；

所述测试用例边界线由若干个短划线“-”组成；

所述测试目标代表测试用例的测试标的，采用单行文本类型；

所述测试用例的位置代表测试用例的存储位置，采用单行文本类型；

所述所在模块代表测试用例文本属于哪个自动化测试模块，采用单行文本类型；

所述脚本名字代表所在测试脚本的名字，采用单行文本类型；

所述测试步骤代表一系列测试操作动作，采用多行文本类型；

所述测试结果代表一系列期望出现的结果标准值，采用多行文本类型。

3.根据权利要求2所述的测试用例解析方法，其特征在于：所述步骤S2中，利用测试用例边界线将单个测试用例片段拆分出来。

4.根据权利要求1所述的测试用例解析方法，其特征在于：所述步骤S3中，循环读取链表caseList的元素，并将读取的元素解析后挂载到测试用例模型树根上来创建测试用例模型树。

5.根据权利要求1所述的测试用例解析方法，其特征在于：所述步骤S3中，创建测试用例模型树包括以下步骤：

步骤S41、创建空的测试用例模型；

步骤S42、判断从链表caseLine中获取一个元素是否成功，若是，转入步骤S43；若否，流程结束。

步骤S43、创建单个case子树，将新case子树挂载到测试用例模型树根上，转入步骤S42。

6.根据权利要求5所述的测试用例解析方法，其特征在于：创建单个case子树时，对于单行文本信息，分别取出信息，将其制作成case子树的叶子；对于多行文本信息，转化成节点时，需要首先提取多行文本信息，再制作成步骤节点。

7.根据权利要求6所述的测试用例解析方法，其特征在于：提取多行文本信息时，利用首位行正则表达式匹配的方法，从单个测试用例文本中获取对应的多行片段。

8.根据权利要求1所述的测试用例解析方法，其特征在于：所述步骤S4中，测试用例模型保存到任意磁盘位置上。

9.根据权利要求1所述的测试用例解析方法，其特征在于：所述测试用例模型采用XML格式。