第八章：QTP自动化测试框架

1、 讲师：孙老师 （北风网版权所有) -QTP从零基础到精通进阶23/29/2022软件测试框架介绍软件测试框架介绍什么是框架framework ?v整个或部分系统的可重用设计，表现为一组抽象构件以及构件实例间交互的方法；v可被开发者定制的应用骨架。前者是从应用方面、而后者是从目的方面给出的定义。测试框架也是如此，测试框架出现的最终目的是花少量的资源来完成尽可能多的测试任务，所以测试框架的建立以及框架的重用性方面是最值得测试人员深入探究的地方。 33/29/2022软件测试框架介绍软件测试框架介绍什么是测试框架? 测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。测试

2、框架的好处在于：v 减少冗余代码、提高代码生产率、提高代码重用性和可维护性。提高开发速度，提升测试代码的执行效率；v 提高软件代码质量，同时引入重构概念，让代码更干净和富有弹性；v 提升系统的可信赖度，作为回归测试的一种实现方法支持修复后“再测试”，确保代码的正确性。43/29/2022自动化测试框架介绍自动化测试框架介绍自动化测试框架一般可以分为上下两个层次，上层是管理整个自动化测试的开发，执行以及维护，在比较庞大的项目中，它体现重要的作用，它可以管理整个自动测试，包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚本的开发，充分的使用相

3、关的测试工具，构建测试驱动，并完成测试业务逻辑。53/29/2022测试驱动测试驱动_A测试驱动是一个自动化测试框架的核心，其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动。v数据驱动测试驱动引擎从数据源获取测试数据，然后将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。一般数据源与测试结果存储在数据库、Excel文件、CSV文件等。数据驱动主要优点是：测试脚本与测试数据的分离，当应用功能变更时，只需要修改该功能部分的脚本；执行测试用例的人员不需要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的

4、，测试人员可以有选择的执行测试用例。63/29/2022测试驱动测试驱动_Bv关键字驱动关键字驱动的自动化测试框架是在数据驱动的基础上进行改进，数据源里包含的不只是数据，还有关键字，一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑，例如，登录、注销等。数据表通过关键字，查找映射表，执行相关的脚本。驱动引擎是对数据表的数据进行分析，根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断，以及测试报告的处理等73/29/2022测试脚本开发测试脚本开发_Av脚本划分为了方便以后脚本的维护问题，必须对脚本进行有效的分层

5、，同时，提高了脚本的复用率。公共类库 公共类库包括所有模块都可能用到的操作方法，其抽象了不同模块同性，比如操作excel表的方法、读写测试报告、驱动引擎等。模块特定类库在模块内部将可以为该模块共享使用的方法抽象出来，作为一个公共类。它可以是一个单的逻辑操作，也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。测试用例脚本测试用例脚在最上层，它根据测试点进行设计，面向具体的应用。它可直接调用公共类库或模块特定类库的方法，即调单个逻辑操作。它是单个或多个逻辑操作的集合，即一个测试用户脚本。83/29/2022测试脚本开发测试脚本开发_Bv脚本规范测试脚本的开发也要遵循编程的规则与标准

6、，应该统一规划，所有开发脚本的人员按照统一的规定进行编码。除了编程本身规范，还考虑测试用例与库函数名的命名。例如，项目M4.1客户端登录测试用例可命名为：TC_M4.1_client_login；读取excel表的函数可命名为：read_excel。93/29/2022测试用例测试用例v 测试用例粒度测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。应该根据每个系统的具体情况来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大，这样一旦出执行测试用例出错，不利于定位问题；但也不能太细化，太小则不方便执行。v 测试用例与测试套件

7、一个大型的项目有许功能模块，必然会产生大量的测试用例，怎样才能有效的管理这些测试用例呢？这就需要创建测试套件，通过测试套件将测试某一个模块或功能点的测试用例集合起来，方便运行与管理。例如，只验证“用户管理”模块功能，则只需要执行“用户管理”模块套件即可。103/29/2022选择适合自动化测试的用例选择适合自动化测试的用例通常适合自动化测试的用例有：v产品型项目产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。v回归测试回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做

8、回归测试工具。v机械并频繁的测试每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。有一些交互性比较强，需要人工干预的操作，就不要指望通过自动化测试来完成了。例如，用户使用U-Key登录。113/29/2022软件自动化框架的发展软件自动化框架的发展 基于界面的软件 自动化测试框架和工具的发展大致经历了三个阶段 1.简单的录制回放：由工具录制并记录操作的过程和数据形成脚本，通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起，几乎一个测试用例对应一个脚本，维护成本很高。而且即使界面的简单变化也需要重新录制，脚本可重复使用的效率低。 2.数据驱动 (data_driven

9、)的自动化测试：从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离，脚本的利用率、可维护性大大提高，但受界面变化的影响仍然很大。 3.关键字驱动(keyword_driven)的自动化测试：关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。 主要关键字包括三类：被操作对象(Item) 、操作(Operation)和值(value) ，用面向对象形式可将其表现为 Item.Operation(Value)。关键字驱动的主要思想是：脚本与数据分离、界面元素名

10、与测试内部对象名分离、测试描述与具体实现细节分离。 123/29/2022从上面可以看到，自动化测试框架和脚本的发展是和软件工程思想的发展一脉相承的。软件开发的模式从面向机器、到面向过程、再到面向对象、面向服务，是一个从底层到高层、从具体到抽象、复用的粒度从细到粗的发展过程。而软件开发中的模块化、层次化、松耦合等思想对自动化测试框架的设计都具有借鉴意义。目录目录l问题描述l解决方案1.框架图示2.数据的组织3.驱动的逻辑4.优势和缺点l参考资料问题描述问题描述l前段时间，完成了一些自动化测试的工作，发现了几个问题：1. 脚本文件过大经过检查分析，主要是两方面原因导致，一是对象库的文件，默认生成

11、得每个空的对象库文件为192K，这样一个空的QTP脚本文件就至少需要192K*2=384K的空间（Action0和Action1），如果分割的Action多的话，占用的空间就更多。二是Excel的文件，同样由于分割Action，每个Action需要使用一个独立的Sheet，包括脚本中调用的Action，这个在复杂的脚本中，表现得更加明显，往往一个贷款发放的脚本会占用34M空间。2. 文件数量过多一个最简单的QTP脚本，共有4个文件夹，13个文件，当分割Action较多时，文件数与Action的个数呈正比上升。问题描述问题描述l这两个问题，直接导致最终完成的工程文件达到700800M，文件数以万

12、计。这还只包括了信贷与结算的主要业务。而其中真正有用的脚本，全部用文本来存储的话，不会超过10M。使用Action复用的方式带来了维护、转移、版本的巨大困难。解决方案概述解决方案概述1.用VBS的Function代替QTP脚本中的Action。 不使用Action复用，而使用Function的加载和调用。直接减少QTP脚本的数量。2.使用单一的QTP脚本入口。 这样整个工程中，就只有一个QTP脚本，其他的都是VBS文件，并且没有了过多的Excel文件。确保冗余文件达到最少。3.数据文件统一维护。 将所有脚本需要用到的测试数据统一放到一个或多个Excel文件中，方便了维护，同时也减少了Excel

13、文件的数量。框架图示框架图示框架说明框架说明采用了(TestCase - Task)的模块化设计思想，业务数据驱动脚本的指导思想。框架并没有太多的新意，对AUT测试对象的处理，全部交给测试工具和Script去处理，框架只处理业务层面的测试数据。当页面元素是动态生成，或者写得不规范时，Web对象的识别是困难的，而且用Excel表格来记录一个个的Web对象,亦不见得实用。因此，对于Web对象的识别就全部放到脚本中去处理。幸好QTP提供的功能足以胜任这个工作。框架中，最核心的可能是Driver脚本，但是在整个测试中，最核心的不是Driver，不是Script，而是业务测试数据。孤立的来看自动化测试框

14、架，是没有任何意义的。什么样的测试用例，决定什么样的框架。体系结构体系结构1.Test Set驱动脚本驱动脚本 初始化 解析Test Set的数据文件 调用TestCase驱动脚本，向它传递测试用例的文件名 如果有必要，调用框架所必需的库函数2.TestCase驱动脚本驱动脚本 解析TestCase的数据文件 根据TestCase的解析结果，加载测试脚本，加载测试数据 根据TestCase的内容，调用Task的测试脚本，并且把测试数据的集合传递给测试脚本 如果有必要，调用框架所必需的库函数体系结构体系结构3.Task测试脚本测试脚本 执行指定的任务（如输入数据，点击按钮等） 生成日志，以及测试

15、报告 如果需要则调用用户自定义库函数4.库函数库函数 一般的和具体应用程序的函数可以被调用，以执行指定的任务。框架的存储结构框架的存储结构框架的存储结构框架的存储结构lProject文件夹，整个工程的最高一级目录，名称可以修改。lDriver目录，这个是QuickTest的脚本文件，整个框架的入口。这个脚本包含了testSet和testcase的驱动脚本。lframeUtil目录，存放用来支持框架的一些函数库。llogs目录，存放脚本运行日志ltestData目录，存放测试用例以及测试数据的Excel文件ltestScript目录，存放task脚本，全部存储为vbs文件。ldriver.vbs

16、文件，使用了QTP的automation object model，也是整个框架的入口。可以直接执行该vbs脚本，因此可以做成Windows的自动任务，在指定时间点执行。ltestData和testScript目录下的内容，是真正需要开发的。数据的组织数据的组织Test SetTestCaseTest DataTest DataTest Set 数据文件数据文件lTest Set数据文件是用来管理测试用例文件的，在这里，扮演了TD的管理测试用例和脚本的角色。很显然，这个数据文件没有TD的功能强大，不能体现测试用例对需求的覆盖，没有测试用例之间的树形结构但是作为一个轻量级的测试框架，只要能够记录

17、、管理50100个测试用例文件，就暂时够用了。lIDX：index，“”表示该行数据有效，“x”表示该行数据无效。主要是考虑到Excel直接面对人，用0，1来标识有效无效，很不直观。lname：测试用例的名字，用中文标示即可，这个字段只是让人看起来比较直观，并不会被用到。ltable：这个字段非常重要，它指向测试用例所在的Excel的文件名。可以带后缀，也可以不带后缀。不需要指定文件所在的路径。lsheet：表示测试用例在Excel文件的Sheet名称。如果不填写的话，默认为第一个Sheet。l考虑到有些测试用例极其复杂，仅仅使用Excel形式的测试用例是远远不能实现其复杂的逻辑，也可以把测试

18、用例写成vbs文件，直接执行该vbs脚本。目前暂未实现。TestCase数据文件数据文件lTestCase数据文件中记录的就是测试用例，只要不是太过于复杂的测试流程，都可以直接写在Excel文件中，当然，需要符合一定的规范，很显然，这离自然语言还是有一定的距离 。这种形式比较适合step-by-step的测试用例，并且粒度比较粗，减少了测试用例的步骤数。lIDX：index，“”表示该行数据有效，“x”表示该行数据无效。lbizName：被测试的业务的名称，比如说“银行收款”这个业务。事实上，这个名称需要与存储改业务的task脚本的名称保持一致，而且需要与task脚本中定义的class的名称也

19、保持一致。在没有做名称的中英文对照字典之前，bizName最好使用英文名，所以最好使用“collection”，而不是“银行收款”。ltaskName：task的名称，原子业务的名称，比如新增、修改、删除等。这个名称与task脚本中定义的各个Function的名称应该保持一致。同样，暂时也最好不要使用中文。TestCase数据文件数据文件lbizDataTable：测试数据所在的Excel的Sheet名称。比如说进行登陆操作时，需要输入用户名和密码等数据，这些数据单独放在某个Excel文件中的某个Sheet中，把这个Sheet的名称写到bizDataTable这个字段中即可，框架会自动去加载这

20、个Sheet中的所有数据。lfilter：测试数据的过滤条件。可能准备的测试数据比较多，但是在当前这一个step中，只需要执行某一条或几条数据，就可以使用filter这个条件。比如说，登陆时，想用错误的用户名和密码来登陆，那么可以这样写：用户类型=baduser。当然“用户类型”是测试数据所在Excel表格中定义过了的字段。老实说，在这次完成的框架中，只有filter这个想法，觉得有点意思。感谢提出这个需求的同事。Test data数据文件数据文件lTest data数据文件，用来存放测试数据。没有区分输入数据、验证数据、以及输出数据，总之，只要是测试过程中，需要用到的数据，都一古脑的做成一行

21、，放到这个文件中。一是觉得这样在设计测试数据时，比较方便和直观，二是也没有更好的设计思想。l对业务的验证，按照设想，是通过日志文件和测试报告来体现的。所以把验证数据与输入数据放到一起，亦不会有太大的不妥。数据文件总结数据文件总结l基于把测试设计和脚本开发分开的思路，设计了这三个Excel表格。测试设计时，主要是设计testcase和test data这两个Excel表格。毕竟，这才是自动化测试最核心的价值所在。脚本写得再完美，没有好的测试设计、测试数据，对测试本身并不会有太大的帮助。l因此，希望尽可能把这些Excel表格做得更易用。所谓的框架，就是把这3个Excel表格串起来的东西。驱动脚本的

22、逻辑驱动脚本的逻辑lTest Set 驱动脚本伪码lTestCase 驱动脚本伪码lTask 脚本说明Test Set 驱动脚本伪码驱动脚本伪码1.将test set数据所在的整个Sheet加载到QuickTest的Runtime Table中。2.检查test set数据文件中一共有多少行记录需要执行。3.读取一行数据。4.如果该行的IDX的值为“”，那么调用执行TestCase驱动脚本，并且把测试用例所在的Excel文件名和Sheet名作为参数传给TestCase脚本。5.转向第3步，直到所有数据被执行完毕。6.删除加载到Runtime Table中的所有数据。TestCase 驱动脚本伪

23、码驱动脚本伪码1.将TestCase所在的Sheet加载到QuickTest的RunTime Table中。2.检查TestCase数据文件中一共有多少行记录需要执行。3.遍历整个Sheet，加载所有需要被用到的Task脚本：逐行读取有效数据（IDX=“”），如果bizName的值所指向的Task脚本没有被加载，那么加载之，直到所有数据被执行完毕。4.遍历整个Sheet，加载所有需要被用到的Test data数据：逐行读取有效数据（IDX=“”），如果bizDataTable的值所指向的Sheet（该Sheet的名称应该在本测试用例中是唯一的）没有被加载到RunTime Table中，那么加载之，直到所有数据被执行完毕。5.获取一行的测试步骤的数据。6.如果该行的IDX的值为“”，那么解析filter信息，形成条件语句。7.逐行读取test data所在的Shee