轻量级自动化测试框架.pptx

单击此处编辑母版文本样式,第二级项目符号文本,第三级项目符号文本,第四级项目符号文本,第五级项目符号文本,单击此处编辑母版标题样式,#,轻量级自动化测试框架,QTP Based,目录,问题描述,解决方案,框架图示,数据的组织,驱动的逻辑,优势和缺点,参考资料,问题描述,前段时间，完成了一些自动化测试的工作，发现了几个问题：,脚本文件过大,经过检查分析，主要是两方面原因导致，一是对象库的文件，默认生成得每个空的对象库文件为,192K,，这样一个空的,QTP,脚本文件就至少需要,192K*2=384K,的空间（,Action0,和,Action1,），如果分割的,Action,多的话，占用的空间就更多。二是,Excel,的文件，同样由于分割,Action,，每个,Action,需要使用一个独立的,Sheet,，包括脚本中调用的,Action,，这个在复杂的脚本中，表现得更加明显，往往一个贷款发放的脚本会占用,34M,空间。,文件数量过多,一个最简单的,QTP,脚本，共有,4,个文件夹，,13,个文件，当分割,Action,较多时，文件数与,Action,的个数呈正比上升。,这两个问题，直接导致最终完成的工程文件达到,700800M,，文件数以万计。这还只包括了信贷与结算的主要业务。而其中真正有用的脚本，全部用文本来存储的话，不会超过,10M,。使用,Action,复用的方式带来了维护、转移、版本的巨大困难。,解决方案概述,用,VBS,的,Function,代替,QTP,脚本中的,Action,。,不使用,Action,复用，而使用,Function,的加载和调用。直接减少,QTP,脚本的数量。,使用单一的,QTP,脚本入口。,这样整个工程中，就只有一个,QTP,脚本，其他的都是,VBS,文件，并且没有了过多的,Excel,文件。确保冗余文件达到最少。,数据文件统一维护。,将所有脚本需要用到的测试数据统一放到一个或多个,Excel,文件中，方便了维护，同时也减少了,Excel,文件的数量。,框架图示,术语词汇表,定义在此培训中使用的术语,框架说明,采用了,(TestCase-Task),的模块化设计思想，业务数据驱动脚本的指导思想。框架并没有太多的新意，,对,AUT,测试对象的处理，全部交给测试工具和,Script,去处理，框架只处理业务层面的测试数据。,当页面元素是动态生成，或者写得不规范时，,Web,对象的识别是困难的，而且用,Excel,表格来记录一个个的,Web,对象,亦不见得实用。因此，对于,Web,对象的识别就全部放到脚本中去处理。幸好,QTP,提供的功能足以胜任这个工作。,框架中，最核心的可能是,Driver,脚本，但是在整个测试中，最核心的不是,Driver,，不是,Script,，而是业务测试数据。,孤立的来看自动化测试框架，是没有任何意义的。什么样的测试用例，决定什么样的框架。,体系结构,Test,Set,驱动脚本,初始化,解析,Test,Set,的数据文件,调用,TestCase,驱动脚本，向它传递测试用例的文件名,如果有必要，调用框架所必需的库函数,TestCase,驱动脚本,解析,TestCase,的数据文件,根据,TestCase,的解析结果，加载测试脚本，加载测试数据,根据,TestCase,的内容，调用,Task,的测试脚本，并且把测试数据的集合传递给测试脚本,如果有必要，调用框架所必需的库函数,Task,测试脚本,执行指定的任务（如输入数据，点击按钮等）,生成日志，以及测试报告,如果需要则调用用户自定义库函数,库函数,一般的和具体应用程序的函数可以被调用，以执行指定的任务。,框架的存储结构,简要审阅所演示的内容,确定应用培训的方法,请求有关培训单元的反馈,框架的存储结构,Project,文件夹，整个工程的最高一级目录，名称可以修改。,Driver,目录，这个是,QuickTest,的脚本文件，整个框架的入口。这个脚本包含了,testSet,和,testcase,的驱动脚本。,frameUtil,目录，存放用来支持框架的一些函数库。,logs,目录，存放脚本运行日志,testData,目录，存放测试用例以及测试数据的,Excel,文件,testScript,目录，存放,task,脚本，全部存储为,vbs,文件。,driver.vbs,文件，使用了,QTP,的,automation object model,，也是整个框架的入口。可以直接执行该,vbs,脚本，因此可以做成,Windows,的自动任务，在指定时间点执行。,testData,和,testScript,目录下的内容，是真正需要开发的。,数据的组织,Test Set,TestCase,Test Data,Test Data,Test Set,数据文件,Test,Set,数据文件是用来管理测试用例文件的，在这里，扮演了,TD,的管理测试用例和脚本的角色。很显然，这个数据文件没有,TD,的功能强大，不能体现测试用例对需求的覆盖，没有测试用例之间的树形结构,但是作为一个轻量级的测试框架，只要能够记录、管理,50100,个测试用例文件，就暂时够用了。,IDX,：,index,，“”表示该行数据有效，“,x,”表示该行数据无效。主要是考虑到,Excel,直接面对人，用,0,，,1,来标识有效无效，很不直观。,name,：测试用例的名字，用中文标示即可，这个字段只是让人看起来比较直观，并不会被用到。,table,：这个字段非常重要，它指向测试用例所在的,Excel,的文件名。可以带后缀，也可以不带后缀。不需要指定文件所在的路径。,sheet,：表示测试用例在,Excel,文件的,Sheet,名称。如果不填写的话，默认为第一个,Sheet,。,考虑到有些测试用例极其复杂，仅仅使用,Excel,形式的测试用例是远远不能实现其复杂的逻辑，也可以把测试用例写成,vbs,文件，直接执行该,vbs,脚本。目前暂未实现。,TestCase,数据文件,TestCase,数据文件中记录的就是测试用例，只要不是太过于复杂的测试流程，都可以直接写在,Excel,文件中，当然，需要符合一定的规范，很显然，这离自然语言还是有一定的距离。这种形式比较适合,step-by-step,的测试用例，并且粒度比较粗，减少了测试用例的步骤数。,IDX,：,index,，“”表示该行数据有效，“,x,”表示该行数据无效。,bizName,：被测试的业务的名称，比如说“银行收款”这个业务。事实上，这个名称需要与存储改业务的,task,脚本的名称保持一致，而且需要与,task,脚本中定义的,class,的名称也保持一致。在没有做名称的中英文对照字典之前，,bizName,最好使用英文名，所以最好使用“,collection,”，而不是“银行收款”。,taskName,：,task,的名称，原子业务的名称，比如新增、修改、删除等。这个名称与,task,脚本中定义的各个,Function,的名称应该保持一致。同样，暂时也最好不要使用中文。,TestCase,数据文件,bizDataTable,：测试数据所在的,Excel,的,Sheet,名称。比如说进行登陆操作时，需要输入用户名和密码等数据，这些数据单独放在某个,Excel,文件中的某个,Sheet,中，把这个,Sheet,的名称写到,bizDataTable,这个字段中即可，框架会自动去加载这个,Sheet,中的所有数据。,filter,：测试数据的过滤条件。可能准备的测试数据比较多，但是在当前这一个,step,中，只需要执行某一条或几条数据，就可以使用,filter,这个条件。比如说，登陆时，想用错误的用户名和密码来登陆，那么可以这样写：用户类型,=baduser,。当然“用户类型”是测试数据所在,Excel,表格中定义过了的字段。老实说，在这次完成的框架中，只有,filter,这个想法，觉得有点意思。感谢提出这个需求的同事。,Test,data,数据文件,Test,data,数据文件，用来存放测试数据。没有区分输入数据、验证数据、以及输出数据，总之，只要是测试过程中，需要用到的数据，都一古脑的做成一行，放到这个文件中。一是觉得这样在设计测试数据时，比较方便和直观，二是也没有更好的设计思想。,对业务的验证，按照设想，是通过日志文件和测试报告来体现的。所以把验证数据与输入数据放到一起，亦不会有太大的不妥。,数据文件总结,基于把测试设计和脚本开发分开的思路，设计了这三个,Excel,表格。测试设计时，主要是设计,testcase,和,test,data,这两个,Excel,表格。毕竟，这才是自动化测试最核心的价值所在。脚本写得再完美，没有好的测试设计、测试数据，对测试本身并不会有太大的帮助。,因此，希望尽可能把这些,Excel,表格做得更易用。所谓的框架，就是把这,3,个,Excel,表格串起来的东西。,驱动脚本的逻辑,Test,Set,驱动脚本伪码,TestCase,驱动脚本伪码,Task,脚本说明,Test,Set,驱动脚本伪码,将,test,set,数据所在的整个,Sheet,加载到,QuickTest,的,Runtime,Table,中。,检查,test,set,数据文件中一共有多少行记录需要执行。,读取一行数据。,如果该行的,IDX,的值为“”，那么调用执行,TestCase,驱动脚本，并且把测试用例所在的,Excel,文件名和,Sheet,名作为参数传给,TestCase,脚本。,转向第,3,步，直到所有数据被执行完毕。,删除加载到,Runtime,Table,中的所有数据。,TestCase,驱动脚本伪码,将,TestCase,所在的,Sheet,加载到,QuickTest,的,RunTime,Table,中。,检查,TestCase,数据文件中一共有多少行记录需要执行。,遍历整个,Sheet,，加载所有需要被用到的,Task,脚本：逐行读取有效数据（,IDX=,“”），如果,bizName,的值所指向的,Task,脚本没有被加载，那么加载之，直到所有数据被执行完毕。,遍历整个,Sheet,，加载所有需要被用到的,Test,data,数据：逐行读取有效数据（,IDX=,“”），如果,bizDataTable,的值所指向的,Sheet,（该,Sheet,的名称应该在本测试用例中是唯一的）没有被加载到,RunTime,Table,中，那么加载之，直到所有数据被执行完毕。,获取一行的测试步骤的数据。,如果该行的,IDX,的值为“”，那么解析,filter,信息，形成条件语句。,逐行读取,test,data,所在的,Sheet,，如果该行数据是满足条件语句的，那么调用,Task,脚本，执行对应的操作。,转向第,5,步，直到所有数据被执行完毕。,删除加载到,Runtime,Table,中的所有,Sheet,。,Task,脚本说明,Task,脚本的模板如下：,Class collection,银行收款,-,新增的,task,Function toInsert(Sheet_Name),Msgbox(DataTable(“,序号,”,Sheet_Name),End Function,银行收款,-,复核的,task,Function toCheck(Sheet_Name),Msgbox(DataTable(“,序号,”,Sheet_Name),End Function,End Class,Task,脚本说明,Task,脚本中，必须定义一个,Class,，这个,Class,的名称应该与文件的名称保持一致。目的主要是为了在调用某个,Function,时，如新增（,toInsert,），会去找指定,Class,的,toInsert,方法，而不会出现找错的情况。,各个,Function,脚本，需要全部使用描述性编程来实现，不能采用录制的方式生成。,使用参数化的测试数据，可以直接使用,QuickTest,的,DataTable,对象，只是,Sheet,名称不是,dtLocalSheet,，而是定义的变量,Sheet_Name,。不过用法是一样的。,脚本开发的工作，就是开发这些,Task,脚本。,优势和缺点,优势：,脚本文件少，并且占用的空间也少了。,可以使用版本控制工具对单个的数据文件或者,vbs,文件进行版本控制。,测试设计和脚本开发解耦。,测试用例和数据的展现更加人性化。,缺点：,异常的捕获考虑得很少。,日志只是输出到文件，不利于查看。如果把日志输出到数据库，就可以生成相应的测试执行报告。,测试用例的管理太过于简陋。,练习例子,1,、结合本测试框架，设计一个登入登出的测试脚本和用例数据。,2,、在,1,点基础上，加上一个流程测试脚本和用例数据。,3,、在测试用例里加入检查点（页面）。,4,、在测试用例里加入检查点（数据库）。,