GUI自动化测试——框架及其状态模型

发表于:2009-8-18 13:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:网络转载

  GUI测试过程有如下几个阶段:

  1、 决定测试目标。在GUI测试的第一个阶段,首先要决定测试什么,即决定对哪些GUI事件或事件序列进行测试。

  2、 生成测试输入。GUI测试输入可以参照软件的规格说明或软件的结构,它由初始条件和事件序列构成。

  3、 生成预期输出。对应测试输入中事件序列的每个事件,生成每个事件执行后的预期结果。

  4、 测试的执行及验证。在测试输入中的初始条件下,顺序执行事件序列中的事件,并对比每个事件的预期输出与实际输出。当两者出现不匹配的情况时,表示当前测试不能通过。

  5、 判断测试的充分性。在执行了部分或全部的测试后,分析所有测试执行情况,判断是否达到预期的要求。

  6、 回归测试。当程序变更后,针对GUI的变化情况,选择部分的测试用例或重新生成新的测试用例对更改部分进行重新测试。

  对于大部分的GUI测试,都需要执行以上的6个步骤,其中每个步骤都可以手工完成或者依靠工具自动完成。现有一些独立的自动化技术或工具,如利用规范化的需求说明生成测试用例,利用有限状态机模型来生成测试用例,利用录制/回放工具来录制事件序列,利用对象捕获工具生成预期状态,利用脚本实现测试的自动执行,利用测试数据表驱动测试的自动执行,以及一些回归测试方法。虽然这些方法可以对测试的某个过程实现自动化,但是会由于其它非自动化过程而降低整体测试效率,难以体现自动化测试的优势。即便将所有过程的自动化工具和技术结合在一起,还要考虑到对所有技术的学习情况及其兼容性问题。因此,实际上很难有效的利用这些工具或技术来解决具体测试问题。

  现有的测试开发环境与MI及IBM测试框架虽然在一定程度上集成了各种测试技术,但是它们却存在种种问题。例如框架中测试用例的生成和维护不能自动执行,影响测试的效率;框架中手工生成检测点和验证点的方法影响了测试的效果;框架中的脚本构架影响了测试的可维护性;只能对较小规模的GUI进行全面的测试,影响测试的通用性等等。因此,要建立一个全面有效的GUI整体测试框架,必须要符合框架的高效性、兼容性、有效性、可维护性和通用性等方面的要求。

  1.整体测试框架

  作者构建的GUI整体测试框架如图1所示,它包括8个组成部分:GUI相关模型、测试相关数据、测试脚本架构、测试用例生成、测试执行和验证、测试用例维护、测试覆盖评估和核心控制引擎。其中GUI相关模型全面的描述了GUI的结构和功能,是其它组成部分的基础。测试相关数据和测试脚本架构控制了测试资源,将测试设计和测试执行相分离,为测试的自动执行提供支持。测试覆盖评估采用了一种基于事件的覆盖评估标准,利用GUI事件以及事件间的交互情况来判断测试是否达到预期的程度。

  核心控制引擎协调框架中的所有部分,共同完成GUI测试活动。在执行测试前,它首先审核测试相关数据的正确性和完整性,然后生成部分测试用例。经覆盖评估部分调整后,确定测试用例集合。在测试执行测试过程中,以测试相关数据和测试用例集合作为输入,运行测试执行和验证。当遇到问题时,停止当前执行并调用新的测试用例继续执行测试。在回归测试前,当被测程序有所变更时,测试用例维护部分重新对所有的测试用例进行维护,修复失效的测试用例。

图 1 整体测试框架

  框架的测试用例生成部分采用了一种基于覆盖的方法,自动生成能够快速满足覆盖标准的测试用例,并在生成测试用例的同时自动产生其预期输出。框架应用测试数据和测试脚本来实现测试执行过程的自动化。作者应用了一种新型的方法全面的对GUI测试用例进行维护,自动修复由于GUI的更改而失效的测试用例。这些技术符合整体框架的高效性要求。

  框架中的GUI相关模型,使测试的各个过程中所用的技术彼此兼容,全面的描述了GUI的结构和功能,可以有效的辅助测试用例生成和维护、执行和验证、以及覆盖评估等过程的实现,符合框架的兼容性要求。同时,这些GUI模型与应用平台无关,便于开发和使用,并且适用于不同规模的GUI程序,满足通用性的要求。

  框架的测试脚本和测试相关数据控制了测试资源,应用一套完全数据驱动脚本架构,使用独立的脚本处理所有的测试类型和测试项目,取消了对测试脚本维护的开销。另外,以测试数据驱动测试脚本执行,控制测试执行的流程和动作,将测试脚本的维护工作转移到数据表上,满足了整个框架的可维护性要求。

  替代传统的手工生成预期输出状态,框架采用一种全新的结果验证机制。在测试用例生成的同时,根据事件的类型及其所处环境自动产生预期输出,并从预期输出中获取必要信息与实际运行结果进行比较。这样解决了手工操作所遗漏的重要状态和关键属性等问题,满足了高整体框架的可靠性要求。

  2.GUI模型

  为了满足整体测试框架的要求,将多种测试技术集成在一起,需要应用统一的GUI模型。模型不但要全面有效的描述GUI的各种特性,还要有助于整体框架功能的实现,辅助测试用例生成和维护、测试执行与验证,以及测试覆盖评估等过程。另外,模型还应该适用于广泛的应用程序,且便于开发和使用。

  GUI的对象包含许多类型,如窗口、下拉菜单、按钮、滚动条等等,用户通过执行相应的动作与GUI进行交互。每个对象具有许多属性,这些属性值随条件的不同而改变。规模庞大的GUI可以被分割为许多较小的部分,它是具有层次性的,不同的模式窗口属于不同的层次。例如当执行某些动作打开模式窗口后,输入焦点会从原来的窗口中转移到当前模式窗口范围内。总结GUI的特点,对GUI可做如下定义:

  定义1:GUI是具有层次性的软件系统,每个层次包含多个对象,每个对象对应多个属性,不同的属性值使GUI具有不同的状态。通过接收用户和系统产生的事件,GUI的状态会发生改变,并以图形的形式做出相应的响应。

  GUI是以图形的形式显示的软件系统,它所包含对象的属性值随着条件的不同而变动,使GUI输出的也随之变化。由GUI变动产生的输出可以看作是它的状态,即一系列对象和这些对象所包含的属性的集合。GUI的状态可定义成三元组:

  1. O = {o1, o2, o3, …, om}

  2. P(o)={p1,p2,p3,…pn}, p = Property(object,value)

  3. S =P(o1)? P(o2)? …? P(om)

  对象集合O={o1,o2,o3,…,om}指GUI中包含的所有对象,属性集合P(o)={p1,p2,p3,…pn}指对象o?O所包含的全部属性。每个属性可以表示成p=property(object,value), 属性p为布尔值,表示该属性为真还是假;第一个参数是对象object?O,表示该属性所隶属的对象;Value指属性的值。例如属性p=Color(Label,red),表示当对象Label的颜色为red时,p=true;当对象Label的颜色不为red时,p=false。

  GUI的状态可以描述成是一些信息的集合,这些信息包括GUI的对象类型和对象的属性。例如图2(A)中是一个IE的打开对话框,以及“打开”标签和“取消”按钮的部分属性。图2(B)是该GUI的当前状态,它是由部分对象和对象的部分属性所构成。对象的属性在GUI的执行过程中是可变化的,在某些状态下属性的值为真,而在其它的状态下,属性的值可能为假,属性的变化使GUI的状态也随之改变。属性在某些条件下会变得没有意义。例如当窗口win存在时,属性background-color(win,red)是有意义的;当窗口win关闭后,属性background-color(win,red)就变得没有意义了。

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号