一种基于扩展的IFML的移动应用的测试用例生成方法

摘要

本发明涉及基于扩展的IFML模型的移动应用的测试用例生成方法，先建立模型，即针对待测试的移动应用绘制出其对应的IFML模型；建立模型所使用到的IFML，是在原IFML标准基础上，加入了针对移动应用建模的扩展内容，包括针对视图容器增添了扩展子类型工具栏ToolBar和屏幕容器，针对视图组件增添了扩展子类型移动控件，针对事件Event增添了扩展子类型移动端系统事件，移动端事件和移动端行为活动事件，针对行为活动增添了扩展子类型移动端行为活动。按照选定的测试覆盖准则生成符合要求的测试用例。

说明书

技术领域

本发明是一种基于扩展的IFML模型的移动终端应用的测试用例生成方法，主要涉及软件测试，IFML标准，基于模型的测试方法等技术。

背景技术

随着智能机与平板电脑的日渐普及，对应的软件市场也在飞速发展壮大。移动应用在拥有越来越丰富的功能的同时还需要应对因特殊的元素引起的各种各样的操作环境的变化，其程序复杂度也在呈现指数级的增长。本就作为软件生命周期中最为耗时的一个部分，移动应用测试的范围和工作量则更是大大增加了。

现有在工程中实际使用较为普遍的测试办法仍然以人工测试为主，毫无疑问这存在着许多缺点：人工测试需要消耗大量的人力和时间，推迟了产品进入市场的时间；同时正由于人工测试消耗巨大，往往只能使用随机测试方法对重要部分进行测试而忽略了其他部分，加上人工测试可能出现的错漏问题，导致测试覆盖程度不高，甚至测试过程本身也会出现错误。

人工测试高昂的代价使得无论是学术界还是工业界，都将目光投向了自动化测试。各式的自动化测试工具层出不穷，其中也包含了移动终端：它们在接受自行定义的操作行为序列后，可以在选定的终端和系统上运行测试用例，并分析这些操作是否出现缺陷或者错误并进行记录和提示。但作为工具输入的操作行为序列仍然需要人工生成，这依然是个消耗大量人力资源的工作，同时也是进一步提高自动化测试程度的瓶颈。其他的自动化测试方法还包括猴子测试等，这类测试虽然无需人工生成测试行为序列的，但存在着测试分布不均，测试覆盖程度不全较低面等重要的缺陷，一般只能适用在特定的应用或是应用的特定部分之上。

近年来，随着面向对象软件开发技术的广泛应用和软件测试自动化的要求,特别是基于UML模型的软件开发技术的逐渐普及,基于模型的软件测试方法逐渐得到了软件开发人员和软件测试人员的认可和接受。该测试方法所产生的测试模型有助于软件整体设计和调整，而基于模型自动生成的测试用例覆盖率更高，配合相应的自动化测试框架能够最大化地提高测试的自动化程度，并有效的降低人工测试所带来的巨大消耗。但可惜的是，虽然有越来越多这样的测试工具出现，但要应用在移动终端上还有较大的不足或者不适合的地方：其一是大部分使用的模型只为PC端或者网页端进行了设计而并未针对移动端进行特化；另一点则是测试用例依然采用了传统的设计方式，以功能为基础进行测试，而忽视了移动端所重视的界面与交互。

IFML标准作为OMG协会推出的针对前端交互流的建模语言，交互流建模语言(Interaction Flow Modeling Language，简称IFML)，能够很好地以图像的形式描述软件系统的前端设计中的展现内容，与用户之间的交互，以及行为控制等，恰当地迎合了移动终端强调前端交互的特点。因此使用IFML标准作为基础，采用基于模型的自动化测试方法，能够生成出更加合理的高效的针对移动终端的测试序列，这对进一步提高移动终端的自动化测试程度有较大帮助。

发明内容

本发明的目的在于，基于IFML(InteractionFlowModelingLanguage)标准，提出一种移动终端应用测试用例的自动生成方案，并结合目前已有的自动化测试工具，进一步提高移动终端的自动化测试程度。添加了移动应用建模的扩展。然后针对待测应用使用IFML建立模型测试用例。

一种基于扩展的IFML模型的移动应用的测试用例生成方法，其特征在于，其所述方法包括以下步骤：

建立模型，即针对待测试的移动应用绘制出其对应的IFML模型。建立模型所使用到的IFML，是在原IFML标准基础上，加入了针对移动应用建模的扩展内容，包括针对视图容器ViewContainer增添了扩展子类型工具栏ToolBar和屏幕容器Screen，针对视图组件ViewComponent增添了扩展子类型移动控件MoibleComponent，针对事件Event增添了扩展子类型移动端系统事件MobileSystemEvent，移动端事件MobileElementEvent和移动端行为活动事件MobileActionEvent，针对行为活动Action增添了扩展子类型移动端行为活动MobileAction。基于该扩展的IFML，根据待测移动应用的交互设计，绘制其对应的的IFML模型；

读取待测移动应用的IFML模型后，根据该模型模拟应用的使用情况并生成对应的测试用例。测试用例的生成步骤如下：

1)根据上述待测应用的IFML模型，确定应用的初始页面，并以该初始页面作为模型的起始状态。同时确定该IFML模型中所有的参数，并根据各参数的默认值DefaultValue表达式初始化参数的默认值；

2)根据当前初始化状态确定可见的视图容器与视图组件，并寻找出可触发的交互流；

3)选择其中未曾执行过的交互流，若当前所有可触发的交互流均被执行过或者无交互流可选择，则回退至执行上一条交互流之前状态，返回步骤2)；若无法回退，意味着所有状态下所有可触发的交互流均已被执行，即所有的测试用例生成完毕，测试用例生成过程就此结束；

4)根据上述选择的交互流，执行该交互流可能带有的参数的传递，同时根据交互流流出的视图元素将相应的容器与组件设为不可见，根据交互流指向的视图元素将相应的容器与组件设为可见，并生成对应的操作行为；

5)根据上述操作生成对应的操作行为，并进行记录；

6)重复2)、3)、4)、5)步骤，直到达到了预定的循环终止条件；期间，如果在该循环中记录下的一连串操作行为所组成的操作序列根据选择的测试覆盖准则覆盖了之前未曾覆盖的地方，则将该操作序列作为一条测试用例记录下来；

7)回退至上一条交互流之前状态，返回步骤2)。

在执行交互流时，对该IFML模型中的表达式进行解析，判断执行的交互流分支所需要的前置条件，并按照前置要求推算用户可能需要执行的输入内容。对该IFML模型中的表达式，即IFML标准中的Expression元素类型以及其子类型进行解析：具体包含InteractionFlowExpression，ActivationExpression，JavaExpression等(InteractionFlowExpression通常被Event所持有，以Expression的形式指示触发该Event后最终执行的InteractionFlow，即交互流为哪一条；ActivationExpression，为大部分的IFML元素类型所持有，以表达式的形式指示目前情况下该IFML元素是否可见可触发；JavaExpression通常用于辅助表示IFML元素的内部逻辑，如参数的DefaultValue属性即为JavaExpression类型，用于表示参数在未使用前的默认数值，如Action的JavaExpression也为该类型，用于表示Action执行的具体逻辑，其具体的内容为对IFML模型内各参数的改变)，并通过该解析执行表达式的内容或者获取前置条件等。

步骤7)回退操作的回退内容主要包含以下几点：已经执行过的交互流信息，当前各参数信息，当前可见的视图容器与视图组件，当前可触发的交互流信息，已经记录下的操作行为信息。

该测试用例生成方法采用多种测试覆盖准则，如条件覆盖准则，路径覆盖准则和边覆盖准则以及其衍生覆盖准则等。

步骤6)循环中止条件是指在测试用例生成前所设立的用以约束和控制测试用例生成的参数，如测试用例最大步骤数，测试用例最少步骤数，应用中循环的最大循环次数等，在模拟过程中每个交互流组都有对应的参数记录其相关的数据，用以判断目前该交互流组的模拟是否超出了的要求，如果超过了要求，则会终止该交互流阻的循环。

进一步，最终生成的测试用例本身具有较高的可读性，可以被当前的自动化测试工具接受并自动执行测试。

本发明基于的IFML标准来自于2015年3月OMG组织发布的IFML标准的1.0正式官方文档，该标准中有以下几个重要的概念需要进行说明：

1.ViewContainer，即视图容器，它代表的是一个整体性的界面。一个视图容器，其内部可以包含多个子元素；

2.ViewComponent，即视图组件，代表的是整体性界面上的一个控件。一个视图组件，不单独显示，一般由ViewContainer所持有；

3.InteractionFlow，即交互流，代表当前所在页面或容器向另一个页面或容器跳转的一个过程，代表视图焦点的转移；

4.Event，即事件，指的是可能会影响该应用系统状态的一个事件，其下含有多种子类型。它往往会持有多个可能被触发的交互流，但每次只能触发其中一条交互流；

5.Action，即事务活动，代表的是一块将被执行的事务逻辑，往往由event引起触发。同时它本身会含有对应的ActionEvent(event的一种)，在执行完事务逻辑后会自动产生新的交互流将视图焦点转到其他的元素上去；

6.Parameter，即参数信息，一般不单独存在，而是由其他成员持有，用于参与成员中Expression的计算，来表示持有元素的状态；

7.Expression，即内部逻辑表达式，它以特定的语言形式定义了一组表达式，这组表达式最终会给出一个结果，用于辅助IFML模型中参数的变化以及状态的判定等逻辑行为。

本发明针对上述所说的IFML标准进行了相应的扩展，具体扩展内容如下：

1)为ViewContainer类型元素添加了Screen与ToolBar子类型：Screen类型表示移动终端的整体性界面，ToolBar表示在该移动终端上可能出现的工具栏界面；

2)为ViewComponent类型元素添加了移动端子类型MobileComponent，并在其下再度添加了子类型Button，Text，Image和Icon：Button表示移动端上按钮类型的控件，强调可点击，可触发事件，Text表示大面积的文本内容控件，Image表示大型的图片控件，Icon表示小型的图标控件；

3)针对移动终端独有的界面，为ViewContainer类型元素添加了子类型MobileSystemContainer，为ViewComponent类型元素添加了子类型MobileSystemComponent，并在MobileSystemContainer下添加实例子类型SettingPanel和NotificationArea，在MobileSystemComponent下添加实例子类型SettingItem和Notification(分别与上述的SettingPanel和NotificationArea对应)：MobileSystemContainer与MobileSystemComponent表示移动端独有的视图容器和视图组件，SettingPanel表示移动端常有的设定界面，而SettingItem则表示其中的特定组件，NotificationArea表示移动端的消息提示栏界面，而Notification表示其中的消息提示信息；

4)为Action类型元素添加了移动终端子类型MobileAction，并在其下添加子类型实例CameraAction和MicrophoneAction，为ActionEvent类型元素添加了移动终端子类型MobileActionEvent，并在其下添加子类型实例CameraActionEvent和MicrophoneActionEvent：MobileAction和MobileActionEvent表示移动终端独有的行为活动和其触发的事件，CameraAction表示移动终端中的照相与摄影行为，CameraActionEvent则表示对应的行为所触发的事件，MicrophoneAction则表示移动终端的通话行为，MicrophoneActionEvent表示其对应的事件；

5)为Event下的SystemEvent子类型添加MobileSystemEvent子类型表示移动终端的系统事件，并添加子类型实例BatteryEvent，StorageEvent，SensorEvent，NotificationEvent和ConnectionEvent；为Event下的ViewElementEvent子类型元素添加MobileElementEvent子类型表示移动端的用户交互事件，并在其下添加子类型实例ClickEvent，LongPressEvent，SwipeEvent，TouchEvent，ScrollEvent：BatteryEvent表示移动端电源引起相关的事件，StorageEvent表示其存储相关触发的事件，SensorEvent表示传感器触发的事件，NotificationEvent表示移动端消息端推送触发的事件，ConnectionEvent表示移动端的连接(如网络连接，NFC，WIFI等)触发的事件，ClickEvent表示用户的点击操作触发的事件，LongPressEvent表示长按操作触发的事件，SwipeEvent表示左右滑动操作触发的事件，TouchEvent表示触摸操作触发的事件，ScrollEvent表示上下滑动触发的事件；

6)为Expression元素类型添加JavaExpression子类型用于辅助表示内部逻辑表达式，并为Action元素类型及其子类型添加JavaExpression成员变量表示其逻辑操作：该JavaExpression的内容具体为java语句与表达式，用于对IFML模型中的参数进行赋值以及改变；

有益效果，IFML标准是针对前端交互流的建模语言，能够很好地以图形的形式描述软件系统的前端设计中的展现内容，与用户之间的交互，以及行为控制等，恰当地迎合了移动终端强调前端交互的特点。使用IFML标准作为基础，采用基于模型的自动化测试方法，能够生成出更加合理的高效的针对移动终端的测试用例。因此基于IFML(InteractionFlowModelingLanguage)标准，实现移动终端应用测试用例的自动生成，并结合目前已有的自动化测试工具，进一步提高移动终端的自动化测试程度。测试用例为一组包含交互单元和交互操作信息的格式化的操作序列，可由多种自动化测试工具自动执行。本发明运用基于模型的测试方法，实现了移动应用测试用例的自动生成，提高了测试覆盖率。

附图说明

图1为本发明的测试用例生成方法实施例一和二的流程示意图。

图2为本发明的测试用例生成方法实施例一的具体流程图。

图3为本发明的测试用例生成方法实施例二的具体流程图。

图4为本发明的测试用例生成方法最终生成的测试用例示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

图1为本发明的测试用例生成方法实施例一和二的流程示意图。实施例一、二在整体流程上保持一致，其主要区别在于生成测试用例所使用到的方式。整个流程通过读取IFML模型来生成所需要的测试用例，主要分为两个部分:IFML模型读取与解析和基于IFML模型模拟生成测试用例。前一部分首先读取了IFML模型中的信息，然后针对该模型的不同信息进行基础的初始化：UML结构初始化表示其所依赖的UML数据结构的初始化，域值初始化表示该IFML模型中所使用到的参数信息的初始化，交互流初始化则表示该IFML模型中各元素实例以及其互相间的关系的初始化。后一部分则在前一部分的基础上通过IFML模型模拟被测试应用的使用情况，根据选择的覆盖准则生成对应的测试用例；在生成过程中需要针对IFML中的表达式进行解析，用于帮助条件的判定与前置输入的导出。

如图2所示，这是本发明的测试用例生成方法实施例一的通过IFML模型模拟被测试应用过程中获取符合要求的测试用例的具体流程图，包括如下步骤：

步骤101，参数初始化，此处通过解析和计算参数下的DefaultValue这一表达式属性，赋予参数最开始时默认的数值。

步骤102，通过IFML模型确定被测试应用的初始页面，即最初的ViewContainer视图容器，也就是视图焦点的所在。

步骤103，根据当前所在的视图容器确定当前可见的视图容器与视图组件，其中还需计算各组件上可能的ActivationExpression表达式元素，该表达式最终的计算结果会影响当前组件是否可见。

步骤104，根据步骤103中可见的视图容器与组件，从当前可触发的交互流中检查其中是否有未曾触发过的交互流，如果是则跳转至步骤107，不是则跳转至步骤105。

步骤105，检查当前状态下是否能够回退至上一条交互流执行前情境，即是否并未为最初始情境；如果是，则进入步骤106，不是则表明该仿真已经全部结束。

步骤106，回退至上一条交互流执行前的情境，回退的具体内容包括：已经执行过的交互流信息，当前各参数信息，当前视图焦点所在的视图容器，当前可触发的交互流信息，已经记录下的操作行为信息，重新开始执行步骤103。

步骤107，选择未触发过的交互流中的一条，并在当前情况下将该条交互流设置为已被触发。

步骤108，检查在选择当前的交互流后该情况是否达到了中止条件，具体为：之前所经历的步骤数是否超过了设定的最大数，当前该交互流的累计经历数量是否超过了设定的最大数(即是否达到了循环的最大数)。若满足条件，则表示此处为一个终结点，无法在此处继续仿真下去，直接跳转至步骤106进行回退；若不满足则，表示仍然有可能可以继续仿真下去，跳转进步骤109。

步骤109，检查当前选择的交互流是否含有兄弟交互流，即是否含有属于同一个事件元素的其他交互流。当有时，则意味着该事件元素还含有InteractionFlowExpression表达式元素用于辅助判断选择当前交互流是否可行，转入步骤110；当没有时，则该事件元素只能触发这一条交互流，无需进行判断，直接跳转至步骤112。

步骤110，计算上述的InteractionFlowExpression表达式元素，并推导出可能所需要的前置输入。

步骤111，将110步骤中获取的前置输入(可能没有)作为参数进行输入，检验该InteractionFlowExpression进行计算后是否最终选择当前的交互流，如果是，则表示输入推导合理，进入步骤112；如果否，则表示当前交互流无法选择，此情境下无法仿真，进入步骤106进行回退。

步骤112，根据交互流可能带有的参数绑定信息进行参数数值的传递。

步骤113，根据交互流指向的容器或组件确定当前所在的视图容器，完成视图焦点的转移，若本次交互流的触发者为Action元素类型，则还需执行该元素内部的逻辑表达式JavaExpression。

步骤114，根据该交互流以及上述可能的输入参数信息，生成对应的操作行为信息，并将其记录下来。

步骤115，检查在经过当前的交互流之后，根据事前定下的覆盖准则是否覆盖到了之前未曾覆盖到的部分，若是则跳转至步骤116；若不是则跳转至步骤103进行下一轮循环。

步骤116，将之前按照顺序记录下的操作行为信息作为一个整体，即一条操作序列，将其作为一条测试用例进行保存，并更新测试覆盖进度，最后也需跳转至步骤103进入下一轮循环。

如图3所示，这是本发明的测试用例生成方法实施例二的通过IFML模型拟被测试应用过程中获取符合要求的测试用例的具体流程图，包括如下步骤：

步骤201，通过IFML模型确定被测试应用的初始页面，即最初的ViewContainer视图容器，也就是视图焦点的所在。

步骤202，静态计算各交互流触发后可能触发的下一条交互流，无视实际情况中可能出现的交互流不可见以及InteractionFlowExpression选择问题。

步骤203，根据静态计算结果更新当前基础信息，包含：累计选择的交互流信息，目前所在视图容器，目前可能可以触发的交互流信息。

步骤204，检查在选择该交互流后是否达到中止条件，具体为：之前所经历的步骤)是否超过了设定的最大数，当前该交互流的累计经历数量是否超过了设定的最大数(即是否达到了循环的最大数)，等等。若满足条件，则跳转至步骤209；若不满足则跳转进步骤205。

步骤205，从当前可能可触发的交互流中检查其中是否有未曾触发过的交互流，如果是则跳转至步骤206，不是则跳转至步骤207。

步骤206，选择其中一条未触发过的交互流，将其记录下来，并标记为已触发，之后返回步骤202开始循环。

步骤207，检查当前状态下是否能够回退至上一条交互流选择前情境，即是否非初始情境；如果是，则进入步骤208，不是则表明该仿真已经全部结束。

步骤208，回退至上一条交互流选择前的情境，回退的具体内容仅仅包括已经选择过的交互流信息，并重新开始执行步骤202。

步骤209，确定该次遍历生成的候选交互流组，即在上述循环中被一条一条选择并记录下来的交互流选择信息，以此作为候选交互流组，在下面的步骤中检验该交互流组是否可以正确地执行，同时以该交互流组第一条交互流作为初始交互流进行下述循环。

步骤210，参数初始化，此处通过解析和计算参数下的DefaultValue这一表达式属性，赋予参数最开始时默认的数值。

步骤211，选择当前交互流开始循环，对交互流组的各条交互流进行一一的检验和执行。

步骤212，检查该交互流是否可见，具体为：检验该交互流所在的Event事件以及Event所在的ViewComponent视图组件其上是否具有ActivationExpression，如果有则计算该表达式的值，用以判断当前状态下其对应的元素实例是否可见，若可见，则跳转至步骤213；不可见则表示该交互流无法正确执行，跳转至步骤208进行回退。

步骤213，检查当前选择的交互流是否含有兄弟交互流，即是否含有属于同一个事件元素的其他交互流。当有时，则意味着该事件元素还含有InteractionFlowExpression表达式元素用于辅助判断选择当前交互流是否可行，转入步骤214；当没有时，则该事件元素只能触发这一条交互流，无需进行判断，直接跳转至步骤216。

步骤214，计算上述的InteractionFlowExpression表达式元素，并推导出可能所需要的前置输入。

步骤215，将214步骤中获取的前置输入(可能没有)作为参数进行输入，检验该InteractionFlowExpression进行计算后是否最终选择当前的交互流，如果是，则表示输入推导合理，进入步骤216；如果否，则表示当前交互流无法选择，模拟失败，跳转至步骤208进行回退。

步骤216，根据交互流可能带有的参数绑定信息进行参数数值的传递。

步骤217，根据交互流指向的容器或组件确定当前所在的视图容器，完成视图焦点的转移，若本次交互流的触发者为Action元素类型，则还需执行该元素内部的逻辑表达式JavaExpression。

步骤218，根据该交互流以及上述可能的输入参数信息，生成对应的操作行为信息，并将其记录下来。

步骤219，检查目前仿真执行的交互流是否为本次的交互流组中的最后一条，如果是则表明该交互流组全都经过了检验，全都能够正确地执行，跳转至步骤220，跳出上述循环；若并未最后一条，则表明后续还有未被检验的交互流，故跳转至步骤211重复循环。

步骤220，检验目前模拟的该路径，根据所选的测试覆盖准则是否覆盖到了之前未曾覆盖的地方，如果是，则跳转至步骤221；如果否，则跳转至步骤208进行回退。

步骤221，记录当前交互流组作为一条基础测试用例，并更新测试覆盖程度，最后跳转至步骤208进行回退。

如图4所示，这是本发明的测试用例生成方法最终生成的测试用例示意图：

图中为一条最终生成的测试用例的示意图，其本质为一组有固定顺序的操作行为组成的操作序列。

图中每个圆角框与从其导出的箭头表示为一个操作行为，圆角框表示触发该操作行为的具体控件，箭头表示具体的操作内容。

圆角框内type属性表示控件的类型：Screen代表整体页面，Button代表按钮类型控件，Image代表图像类型控件，Icon代表图标类型控件，Text代表大面积本文内容类型控件；name属性表示该控件的标题或是其上的标志性文本；id属性表示该控件的在程序中的具体标号，用于辅助该控件的定位。

箭头表示具体的操作内容，其操作主体即为该箭头导出的那一个圆角框(控件)。箭头上方(右方)代表操作的具体类型：Click代表点击操作；Swipe代表左右滑动操作，此时箭头下方(左方)会含有left(向左)或是right(向右)字符标识该滑动操作的具体方向；Scroll代表上下滑动操作，此时箭头下方(左方)会含有up(向上)或是down(向下)字符标识该滑动操作的具体方向；LongPress代表长按操作，此时箭头下方(左方)会含有XXs(多少秒)，XXm(多少分钟)字符用于表示长按的时间；Select代表从列表中选取一个的具体操作；input代表输入操作，此时箭头下方(左方)会构建方框，其中包含输入控件的name(控件的标题或是标志性文本)，id(控件在程序中的具体标号)以及value(本次操作中应当输入的数值)。