王磊
(枣庄学院 计算机科学系,山东 枣庄,277160)
随着软件系统的日趋复杂以及回归测试等重复性测试在整个软件生命周期中所占的重要地位,我们必须使用自动化测试技术来提高我们的测试效率。自动化测试技术能帮助软件开发人员和测试人员在更短时间内开发出更高质量的产品,通过代替频繁重复的手工测试从而节省了大量的时间和开支。
但是利用捕捉/回放测试工具本身无法提供高效的测试。捕捉产生的脚本对于应用的变化过于敏感,以至于测试人员要不停地修改测试脚本。这样的测试脚本不是我们想要的。我们需要的是一个易于维护的,可以应用于各种不同应用的测试模型。
使用传统自动化测试方式对测试对象各规则要点进行测试的一般流程如图1所示,具体如下:首先等待测试对象构建生成;得到测试对象后,判断对象该规则要点的测试是否需要新的测试数据,例如测试对象“证件号码”的测试规则要点为:必须是数字、长度为4个字符。判断结果有两种情况:(1)如果测试需要新的测试数据,原来录制的测试脚本将不能继续使用,必须录制新的脚本以适应当前测试数据的改动,之后再回放测试脚本以验证测试对象该规则要点;(2)如果测试不需要新的测试数据,则直接回放原测试脚本验证对象规则。测试对象该规则要点验证完毕后,继续进行下一规则要点的验证,直至测试对象各规则要点验证完毕。
可见,按照传统方式进行测试具有:比较容易使用,测试人员不需要额外的编程经验;用例生产简单,需要设计的工作很少;直观的一步一步执行方式等优点。
图1 传统测试流程
但是,这种简单的录制、回放过程在实际应用中存在很多问题,最常见的一个问题是测试脚本难以重用,当对程序界面进行录制时,自动化功能测试工具记录程序执行的全部过程,测试逻辑、测试对象、执行动作和测试数据包含在一个脚本中,一旦测试的执行顺序或测试对象有任何变动,都可能造成测试用例被破坏,需要手工修改已录制好的相应测试脚本,或者重新进行一次录制。尤其对于测试对象中需要多条验证的测试规则,它的改动会引起大量测试工作的返工,所有相关脚本都会受到影响,造成测试脚本的日常维护工作量急剧加大,维护这样的脚本是十分困难的。
如何解决传统测试过程中遇到的这些问题呢?只有修改测试脚本的结构,才能从根本上解决这个问题:
可以在被测程序和生成的测试脚本之间增加一个模型层,它可以将界面上的所有元素映射成对应的逻辑对象,测试针对这些逻辑对象进行,界面元素的改变只会影响映射表,而不会影响测试。
把测试执行的动作和测试具体实现细节分离开来,用关键字描述测试执行动作,只说明该步测试执行什么动作而不管测试工具具体怎样执行。这样做是因为测试的实现细节通常和特定的测试执行工具有着密切的联系,比如QTP和RTF。这种分离使得关键字对于实现细节不敏感,有利于测试在不同工具间的移植。
最后,可以把测试执行过程中所需的测试数据从脚本中提取出来,在运行时由测试控制模块从数据库中读取预先定制好的数据,这样测试脚本和测试数据可以独立维护。
采用上述关键字驱动自动化测试的思想,使执行动作、测试对象和测试数据相互独立,最大程度的减少相互之间的影响,彻底解决了使用GUI自动化测试工具产生的问题。
该测试框架从逻辑上自底向上分为4层,如图2所示,分别是:由测试对象和识别脚本构成的模型层,由标签库和测试数据库构成的数据层,由控制文件构成的控制层以及由用例描述原语(ASL)构成的应用层。本文以自动化测试工具QTP为例,搭建具体的测试框架。
图2 软件自动化测试框架
框架最底部的模型层由测试工具识别的GUI控件对象以及对象的识别脚本构成,模型层负责将GUI控件对象和识别脚本分别组织并以友好的方式提供给数据层的标签库模块使用。
(1) 对象识别脚本
在使用QTP录制时,QTP自动记录GUI对象并生成测试脚本。该测试脚本包含了对GUI对象的识别、执行动作和测试数据,使得测试脚本难以重用和维护。本文在测试框架模型层中只保留对GUI对象的识别脚本,而把测试数据放到数据层、执行动作放到控制层管理,从而实现了相互之间的分离。
(2) GUI控件对象
在测试框架模型层中,通过对界面元素的分析(UI分析)并和QTP对象识别机制相映射来组织GUI控件对象。UI分析是从被测系统界面入手,记录页面层次并把该页面中的GUI对象以要素的形式记录到数据库中,如图3所示,以达到结构化、层次化管理对象的目的。
图3 GUI控件对象映射
数据层由标签库和测试数据库构成,标签库保存要素名和识别脚本的映射关系,测试数据库保存具体的测试数据。
(1) 标签库
标签库是针对某一个应用建立的,它可以通过学习而扩展,其中包含了图形用户界面交互的完整细节,包括GUI界面和对象。本文通过打标的方式来对具体交互细节进行封装:首先利用QTP录制待测系统的执行过程,获取各测试对象的脚本;然后对录制脚本进行打标,实现要素名和测试对象的对应;最后对打标后的脚本进行分解并提取识别脚本和标签,生成标签库。例如表1中测试脚本中的“开户.客户姓名”即为识别脚本Browser("系统-框架页面").Page("系统-框架面).Frame("Frame").WebEdit("textfield422")的标签。
表1 脚本标记实例
通过对QTP脚本的分析,脚本可以分解为下述范式,生成标签库程序按照相应范式对其分解、保存。
●browser.form.object.event value
该范式为B/S结构,其中browser指浏览器定位(URL),form指B/S结构中的页(page),object指用户界面的对象,event指用户操作事件,value指数据输入值。表2为B/S结构范式时的实例。
表2 B/S结构范式实例
●form.object.event value
当browser为空时,该范式退化C/S结构,其中form指C/S结构中的窗口表单(form),object指界面的对象,event指用户操作事件,value指数据输入值。表3为C/S结构范式时的实例。
表3 C/S结构范式实例
●object.event value
当form取特殊值时,该范式退化为字符仿真终端。在该范式中,关键字对应于event,输入参数对应于value。
本文设计的标签库以标准XML的形式存储,将要素名与QTP识别的图形界面和对象进行映射,以供ASL脚本解析时使用。标签库利用XML元素层次关系的表达,清楚定义了业务要素所属的场景。一个业务系统生成一个标签库,不同系统的标签库不能混用。标签库实例如表4所示。
表4 标签库实例
(2) 测试数据库
测试数据库提供具体的测试数据,其中测试数据与UI分析得到的测试对象相对应,每个测试对象根据系统需要,有不同的业务规则,如果业务规则比较复杂,则把业务规则分解成最小化的规则,也即测试点。针对每一个测试点,测试人员至少要准备2条测试数据,分别为正例和反例。正例是指符合该测试点测试数据;反例是指不符合该测试点的测试数据。执行测试时必须保证正例能通过而反例不能通过,否则就说明该处存在BUG,测试数据库实例如图4所示。
控制层为自动化测试框架提供了一个控制入口,测试工程师利用控制层实现具体的测试意图:测试工程师可以对测试的执行顺序根据需要进行调整,使得测试不必按录制顺序回放;可以通过关键字设置GUI对象的执行动作,实现各种操作;可以通过要素名匹配测试数据。控制文件如图5所示。
图4 测试数据库实例
其中“说明”部分为生成测试报告做准备,“开始”部分设置具体测试逻辑;本例中“key”为动作关键字,框架识别该关键字并生成具体测试工具的脚本实现UI对象的输入,还可以设置其他关键字,比如“click”为单击,“select”为选择下拉框,“mywait”为等待一段时间等;<MZ671_2.账号输入>为“MZ671_2”页面下的“账号输入”对象,程序通过标签库调用识别脚本和对象进行匹配,确定特定测试对象;“$账号$”为测试数据标志,通过测试数据库的匹配找到确定的测试数据。
图5 控制文件实例
应用层通过用例描述原语(ASL)具体实现测试的执行:ASL首先获取测试案例的某一控制文件,得到该测试逻辑并解析出测试数据标志和标签;然后通过要素标签在标签库中查找相应脚本,匹配测试数据库中测试数据,组合生成测试工具QTP可以执行的脚本;最后调用测试工具QTP实施自动化测试。
本文以1个应用来分析下如何在实际中实施关键字驱动的自动化测试。在某银行开户流程的测试中,要求对所有对象进行验证,以保证软件质量。假设每个测试对象仅需要测试1个正例和1个反例,n个对象的测试组合就是2n次,利用本测试框架,只在测试开始时建立框架体系,对控件对象识别、打标并生成标签库,对测试规则分析设计出测试用例。通过这种方式使测试逻辑、测试脚本和测试数据相互脱离,在回归测试中仅通过对控制文件的修改就可以对相同功能、不同数据的用例进行测试,同时,测试脚本不关心测试用例,测试的数据和业务逻辑都集成在测试数据表格之中,测试的设计就简化为测试数据表格的设计,程序运行实例如图6所示。
图6 测试框架工具运行实例
由上述测试实例可以看出,应用关键字驱动技术进行自动化测试,可以把测试工程师从繁琐的重复性劳动中解放出来,也为软件产品提供更为高效的、更为精准的测试,提高产品的竞争力。
[1]王磊,罗省贤.业务流程路径覆盖方法的研究与实现 [J].电子测试 ,2009(01):15-19, 52.
[2]陈越,刘强,陈玉健.基于GUI的面向对象软件回归测试技术研究[J].计算机应用研究, 2006, 23(5): 49-51.
[3]蔡维德,白晓颖,陈以农.浅谈深析面向服务的软件工程[M].北京:清华大学出版社, 2008: 3-11.
[4]Chen Y N, Tsai W T. Distributed Service-Oriented SoftwareDevelopment [M]. Dubuque: Kendall/Hunt Publishing,2008: 11 - 30, 271- 274.
[5]MENDEL JM, ROBERT I J, LIU Feilong. Interval type-2fuzzy logic systemsmade simple[J]. IEEE Transactions on Fuzzy Systems, 2006, 14(6): 808-821.
[6]陈薇,孙增圻.二型模糊系统研究与应用[J].模糊系统与数学, 2005, 19(1): 126-135.
[7]姚实颖,肖沙里.软件测试自动化建立可维护脚本[J].计算机工程, 2003 ,7 (11).
[8]黄陇,于洪敏.基于UML的软件测试自动化研究[J].计算机应用, 2004, 7 (7 ).
[9]黄茂生.三层脚本的自动化测试实现[J].软件可靠性与测评, 2005,12 (12).
[10]姚实颖,肖沙里,谭霞,唐跃林. 软件测试自动化中建立可维护脚本的技术[J].计算机工程, 2003,(11).