测试用例自动生成方法和装置
技术领域
本发明涉及软件测试技术领域,特别是涉及一种测试用例自动生成方法和装置。
背景技术
设计测试用例,是整个软件测试工作的最核心部分。目前绝大多数的测试设计方法,都属于测试设计“技巧”,如:等价类划分、边界值、因果图等,都是在具体设计测试数据时候来考虑如何根据测试数据的不同来设计测试用例。基于这些具体测试技巧,对整体测试用例设计水平的提升和帮助并不是很大。
基于前述所列方法,真正影响测试用例质量的是测试设计人员对被测试系统需求的理解及业务层面的理解。目前,还没有一种能够通过标准化的输入和处理来生成测试用例的方法,为此,本领域技术人员希望通过提供一种能够自动生成测试用例的方法,以提高现有测试阶段的测试效率。
发明内容
鉴于以上所述现有技术的缺点,本发明的目的在于提供一种测试用例自动生成方法和装置,用于解决现有生成测试用例质量不稳定以及测试效率不高的问题。
为实现上述目的及其他相关目的,本发明提供以下技术方案:
一种测试用例自动生成方法,所述方法包括以下步骤:对输入的需求定义测试项,得到测试需求;对所述测试需求进行路径扫描,对应得到若干测试场景;依据所述测试场景生成对应的测试数据,并将所述测试数据添加至与其对应的所述测试场景中形成测试用例,并输出所有所述测试用例。
优选地,输入的所述需求包括对所述需求采用UML形式来进行形式化表达得到的活动图。
优选地,所述对输入的需求定义测试项的方法包括:定义需求内容中需要进行测试的测试项;依据定义的所述测试项进行分析,判断是否需要增加需求项:若是,则对所述需求对应的活动图增加检测点,并转化为测试活动图后予以输出;若否,则输出测试活动图。
优选地,所述对需求对应的活动图增加检测点的方法包括:增加查询,并根据所述查询的结果进行校验,对应得到增加检测功能的所述检测点。
优选地,所述测试需求包括测试活动图。
另外,本发明还提供了一种测试用例自动生成装置,所述装置包括:需求输入模块,适于输入需求;测试需求生成模块,适于对输入的所述需求定义测试项,得到测试需求;测试场景生成模块,适于对所述测试需求进行路径扫描,对应得到若干测试场景;测试用例生成模块,适于依据所述测试场景生成对应的测试数据,并将所述测试数据添加至与其对应的测试场景中形成测试用例,并输出所有所述测试用例。
优选地,输入的所述需求包括对所述需求采用UML形式来进行形式化表达得到的活动图。
优选地,适于对输入的需求定义测试项的所述测试需求生成模块还包括:测试项定义单元,定义需求内容中需要进行测试的测试项;需求分析检查单元,依据定义的所述测试项进行分析,判断是否需要增加需求项:若是,则对所述需求对应的活动图增加检测点,并转化为测试活动图后予以输出;若否,则输出测试活动图。
优选地,还包括用于对所述需求对应的活动图增加检测点的需求增加检查单元,适于增加查询,并根据所述查询的结果进行校验,对应得到增加检测功能的所述检测点。
优选地,所述测试需求包括测试活动图。
如上所述,本发明至少具有以下有益效果:本发明通过建立一套设计测试用例的流程,通过标准化的输入、标准化的处理,生成更可靠的测试用例,提高了测试效率。
附图说明
图1显示为测试用例自动生成方法在一实施方式中的实现流程图;
图2显示为将需求转换为测试需求方法在一实施方式中的实现流程图;
图3显示为测试用例自动生成装置在一实施方式中的原理图;
图4显示为测试需求生成模块的一种实施原理图。
元件标号说明
300 装置
310 需求输入模块
320 测试需求生成模块
321 测试项定义单元
322 需求分析检查单元
323 需求增加检查单元
330 测试场景生成模块
340 测试用例生成模块
S101~S105 步骤
S201~S303 步骤
具体实施方式
以下通过特定的具体实例说明本发明的实施方式,本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用,本说明书中的各项细节也可以基于不同观点与应用,在没有背离本发明的精神下进行各种修饰或改变。需说明的是,在不冲突的情况下,以下实施例及实施例中的特征可以相互组合。
需要说明的是,以下实施例中所提供的图示仅以示意方式说明本发明的基本构想,遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制,其实际实施时各组件的型态、数量及比例可为一种随意的改变,且其组件布局型态也可能更为复杂。
实施例1
请参阅图1,为一种测试用例自动生成方法在一实施方式中的实现流程图,如图所示,以下将对该方法所涉及的步骤进行详细地说明。
步骤S101,对输入的需求定义测试项,得到测试需求。
在具体实施中,进行功能测试的时候,输入是需求。如果需要进行模型驱动,则需要对需求进行约束,也就是我们需要对需求进行形式化。需求的形式化是便于转换为测试需求。
具体地,需求的形式化,就是需要对需求的表述,可以包括从自然语言转换成为UML的形式。在测试中,主要采用UML的usecase图和活动图来表述。
此外,在对需求进行形式化以后,需要在输入需求的时候,导入对应的活动图,否则就需要测试需求分析做更多的工作,由人为地来解决没有必要需求,以及由人为来表述的问题。这样会导致理解的偏差和测试的不足。简单地来说,输入的所述需求可以包括对所述需求采用UML形式来进行形式化表达得到的活动图。
在具体实施中,将需求转换为测试需求的具体方法可以参考图2,为将需求转换为测试需求方法在一实施方式中的实现流程图,如图所示,所述方法可以包括以下步骤:
步骤S201,定义需求内容中需要进行测试的测试项;
步骤S203,依据定义的所述测试项进行分析,判断是否需要增加需求项:
步骤S203-1,若是,则对所述需求对应的活动图增加检测点,进入步骤S203-2;
步骤S203-2,若否,则将活动图转化为测试活动图,并予以输出。
从上述方法可以看出,测试需求包括测试活动图。更加具体地来说,转换的基础是定义测试项,也就是需要在本需求中定义那些内容是需要进行测试的。进而根据测试项对活动图进行分析,察看是否需要增加为了需求项(会转换成检查点)来增加检查节点。如果原来的活动图已经能够满足要求,就可以直接把需求活动图转换成为测试活动图;如果缺少,就需要对需求活动图增加检查点,主要是增加检查功能,最典型的是增加查询,并且可以根据查询结果进行校验。
步骤S103,对所述测试需求进行路径扫描,对应得到若干测试场景。
在具体实施中,在得到测试需求以后,需要把测试需求转换成为测试场景。具体可以采用的方法包括路径扫描,也即是检测从“开始”到“结束”节点之间有多少条路径,每条路径就是一个测试场景。
步骤S105,依据所述测试场景生成对应的测试数据,并将所述测试数据添加至与其对应的所述测试场景中形成测试用例,并输出所有所述测试用例。
在具体实施中,测试场景建立完成后还需要进行测试用例设计。从模型驱动的角度,测试用例就是给测试场景增加了测试数据来形成的,即:测试场景+测试数据=测试用例。因此,本方法步骤的重点就是设计测试数据(即提供对应的测试数据),或者添加测试数据给测试场景,形成测试用例,显然该测试用例可以包括很多个测试用例。
实施例2
请参见图3,为一种测试用例自动生成装置在一实施方式中的原理图,如图所示,装置包括需求输入模块、测试需求生成模块、测试场景生成模块及测试用例生成模块,其中,需求输入模块适于输入需求;测试需求生成模块适于对输入的所述需求定义测试项,得到测试需求;测试场景生成模块适于对所述测试需求进行路径扫描,对应得到若干测试场景;测试用例生成模块适于依据所述测试场景生成对应的测试数据,并将所述测试数据添加至与其对应的测试场景中形成测试用例,并输出所有所述测试用例。
考虑到本实施例中的技术方案和前述实施例1中的技术细节是一致的,为避免重复描述,本实施例中对于涉及的重复内容不再赘述。
在具体实施中,输入的所述需求包括对所述需求采用UML形式来进行形式化表达得到的活动图。
在具体实施中,请结合图4,为测试需求生成模块的一种实施原理图,如图所示,适于对输入的需求定义测试项的所述测试需求生成模块还包括:测试项定义单元,定义需求内容中需要进行测试的测试项;需求分析检查单元,依据定义的所述测试项进行分析,判断是否需要增加需求项:若是,则对所述需求对应的活动图增加检测点,并转化为测试活动图后予以输出;若否,则输出测试活动图。这里应当理解,本实施例中的测试需求包括测试活动图。
在具体实施中,再结合图4,还包括用于对所述需求对应的活动图增加检测点的需求增加检查单元,适于增加查询,并根据所述查询的结果进行校验,对应得到增加检测功能的所述检测点。
综上所述,本发明通过建立一套设计测试用例的流程,通过标准化的输入、标准化的处理,生成更可靠的测试用例,提高了测试效率。所以,本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
上述实施例仅例示性说明本发明的原理及其功效,而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下,对上述实施例进行修饰或改变。因此,举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变,仍应由本发明的权利要求所涵盖。