End Class
1.7框架情况总结
? 优势:
– 脚本文件少,占用的空间也少,方便管理和维护。
– 可以使用版本控制工具对单个的数据文件或者vbs文件进行版本控制。 – 测试设计和脚本开发解耦。
– 测试用例和数据的展现更加人性化。 ? 缺点:
– 异常的捕获考虑得很少。
– 日志只是输出到文件,不利于查看。如果把日志输出到数据库,就可以生成相应的
测试执行报告。 – 测试用例的管理太过于简陋。 – 无法定制测试报告。
2.QTP的高级应用—描述性编程
在这个文档中,我只做简单的概述,相关资料请查阅:
svn://10.1.145.249/Autotest/DCSM_Autotest/02 New Tester Readme/自动化测试-新手包/03 资料查阅/描述性编程相关
描述性编程的意义:说白了就是丢掉QTP在录制过程中存储的对象库,采用一种描述的方式来表达浏览器上的控件。
描述编程的实质:就是利用测试对象(浏览器控件,例如WebButton等)本身的属性来定位测试过程中的控件,例如登录按钮其中有个属性叫“name”,值为“login”,QTP提供一种方式来描述这个按钮。
描述性编程的具体格式和做法,请参阅资料文档,这里就不做赘述了。推荐文档:《QTP描述性编程介绍.pdf》
三、木已成舟,只欠东风
实际上,以上的文档应该足以应付我们的自动化测试工具了,但总觉得差了点东西。什么东西呢?对,那就是经验和技巧了。在这一章节,我将主要针对在实际工作中能够应用到的相关经验和技巧做以说明。让大家少走弯路,尽快上手。
1. 理论知识都懂了,在实际工作中将如何开始自动化测试之旅呢?
答:
1) 前提: QTP已经成功安装。
2) 准备测试框架。将自动化测试框架从SVN中check下来。地址是:
svn://10.1.145.249/Autotest/DCSM_Autotest/DCNAutoTestFrame。建议将框架的目录,也
就是project目录直接放到某个盘符的根目录下,这样有助于框架寻找定位数据表和Task脚本。对照以上的框架介绍,熟悉框架内容。
3) 此时,如果测试用例已经设计完毕则直接拿着测试用例进入编码工作。如果没有,则先
设计测试用例(测试用例的设计技巧稍后奉上),在进行脚本开发,我们不推荐没有用例直接开发脚本,这样很可能造成文不对题而进行不必要的返工。 4) 设计测试用例是需要评审的,无论是同一设计或者是单独设计都需要至少将测试计划中
定义的三个角色(测试(框架)负责人、测试用例设计人员、自动化测试脚本开发人员)
召集一起进行评审,如果有必要最好请当时手工测试该模块的测试人员一起评审,审议通过够方可使用。评审的衡量标准主要是:测试数据的完整性,测试检查点设计的合理性,测试用例覆盖率的合理性,测试步骤的是否清晰等。
5) 测试脚本需要进行三个步骤才能够提交至SVN服务器。首先,不带测试数据(不在框架
中执行)的情况下调试通过,这个步骤是保证测试过程各个控件对象识别的正确性;其次,在本机带上测试数据(将脚本加入框架中执行)调试通过,这个步骤的要点是保证用例中提到检查点的覆盖程度和测试数据与脚本的匹配程度。最后,提交给负责人进行最终审核后,提交至SVN服务器,这一步重点保证脚本格式是否正确、注释是否完备、是否有重大检查点遗漏等。
6) 最终脚本的执行统一由测试(框架)负责人来负责。
7) 测试报告的搜集和发布也统一由测试(框架)负责人来负责。
2.设计自动化测试用例有何技巧?
答:
最好是找到该模块的测试人员,要一份之前通过评审的测试用例。我们可以以此为基准设计我们的测试用例。实际上,两种测试用例的内容是差不多的,只是侧重点和表达方式不同罢了。这样的好处在于,能够最大程度的重用或借鉴之前的测试用例,节省出来精力和时间用来设计测试数据,自动化测试用例的重点在于能够建立有效、完备的数据驱动,道理就在这。
在设计测试数据时,我们不要求把每个输入框的各种情况都要覆盖,但要求在这个测试用例中至少要将出现的各种输入异常考虑全面。
最好用某种方式将测试数据规划清楚。例如“管理员开户”的案例中用到的等价类划分法。这样的好处在于可以更加清晰,全面的设计测试数据,提高测试有效性。
3.脚本开发的三字箴言。
脚本的开发大体分为四步:找对象;编逻辑;写报告;入框架。
第一步:找对象。千万不要误会,我们这里的对象应该理解为测试对象,也就是web控件。根据本人的经验,首先要录一遍测试步骤,这样对象基本加入到QTP的测试库中,以便随时查看控件属性,查找并定位控件。要熟练使用Object Spy
,这个工具能够更完
整的将控件的属性显示出来,而且还能列出该控件支持的所有方法。其次,将录制时生成的脚本用描述性编程的方式修改或重写一下,然后将对象库中的对象删除,脚本依然能够运行,说明找对象成功。先录脚本的另一个好处是在编程时不用再考虑测试步骤的问题,因为步骤已经录好,只需专心找控件属性即可。还有一个提示是,录完脚本后可以将对应的测试步骤
当做注释copy到脚本文件中。
第二步:编逻辑。这里面出现最多的就是“IF else EndIf”了,这里可能会出现很多个IF嵌套,建议这种嵌套最多嵌三层,如果写多了,过一段时间后即便是开发脚本的人也不一定能够很清晰的读懂这里面的逻辑了。还有就是写足够的注释,至少要让接受这个脚本的人能读懂。
第三步:写报告。QTP自己集成了一个报告生成器,我们可以在代码中插入不同类型的报告描述,例如Reporter.ReportEvent micPass, \测试用例A-执行成功\“登录信息判断正确。”,将成功的标志插入到QTP报告中,并写上标题和描述。
第四步:入框架。脚本调试通过后一定要放到框架中跑几次,并认真的观察执行过程,在这个过程你能够发现自己脚本还有那些缺陷,包括逻辑缺陷和操作步骤缺陷等,完善脚本,提高脚本的健壮性。
4.step-by-step,手把手的教你如何完成一个自动化测试场景。
1) 安装QTP。
2) 将SVN上的相关文件下载到本地。svn://10.1.145.249/Autotest/DCSM_Autotest
3) 打开“DCNAutoTestFrame”文件夹,里面放着的就是自动化测试框架。浏览一遍框架存储
结构,查阅本文档的第二章的1.4,了解各文件夹的作用。
4) 开始设计测试用例,用例的设计涉及到两个Excel文档。
a) 打开“DCNAutoTestFrame”文件夹下的DCSMtestCases.xls(视业务系统的不同而不同)
文档,将待测试的用例信息放入表格中,填写时请认真阅读表格上方的提示信息。填写格式如下:
b) 在文件夹“testData”下找到相应的应用系统,创建一个Excel文件,名称可根据实
际业务功能命名,但要与上一个文档的sheet字段相同。例如,名称起做DCSMOpenAccount.xls,与上一个文档中的table字段相同。 这个文档共有两个部分的内容,一部分是用来关联数据和Task脚本文件的,放置在文档的第一个sheet,sheet的名称起做“testCase”与上一个文档中的sheet字段相同。另一部分是用来存储自动化测试数据的,通常放在testCase制表项的后面,每一个sheet中的数据对应一个功能用例,数据书写规则:第一行放置列标题,列表不可重名,列标题将在脚本中引用数据时当做参数使用,从第二行开始放置测试数据。两部分内容的对应关系如下图:
5) 开始开发脚本,具体方法请参照本章节的第3小节“脚本开发的三字箴言”,待脚本调试
通过后放入框架根目录的“testScript”下。
6) 支持所有的测试准备工作已经完毕,我们开始加载框架,运行脚本。
首先,打开QTP,Open框架根目录下的driver.vbs文件,注意这个脚本文件不准随意改动,否则测试脚本将无法正常执行。
然后,点击Run按钮,弹出对话框选择ResultReport的存储路径,我们将ResultReport存储在框架下面的“result”文件夹下,开始执行脚本。第一次运行脚本的时候最好要仔细观察脚本的运行过程,排查脚本的BUG。 最后,脚本执行完毕后将会自动弹出报告。 7) 通过测试报告分析脚本的运行情况。
四、大结局
虽然文档已经近尾声,但我们要清醒的认识到,自动化测试尤其是测试框架,不是一蹴而就的工作,他是一个持续改进,坚持不懈的过程。能够遇见的是,这个过程很可能是一个痛并快乐着的过程。衷心希望以上的内容不会成为废话一堆,最好能够直击你们的痛处,有任何建议请及时跟我联系,并亲切的指出其中的不足,我会虚心改正的。
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,免费范文网,提供经典小说综合文库QTP自动化测试教程(4)在线全文阅读。
相关推荐: