轻量级自动化测试框架-QTP Based解析.ppt

Confidential ?2008 iSoftStone Holdings Ltd. All Rights Reserved. iSoftStone Information Service Corporation 目录 问题描述 解决方案 框架图示 数据的组织 驱动的逻辑 优势和缺点 参考资料 问题描述 问题描述 前段时间，完成了一些自动化测试的工作，发现了几个问题： 脚本文件过大 经过检查分析，主要是两方面原因导致，一是对象库的文件，默认生成得每个空的对象库文件为192K，这样一个空的QTP脚本文件就至少需要192K*2=384K的空间（Action0和Action1），如果分割的Action多的话，占用的空间就更多。二是Excel的文件，同样由于分割Action，每个Action需要使用一个独立的Sheet，包括脚本中调用的Action，这个在复杂的脚本中，表现得更加明显，往往一个贷款发放的脚本会占用3~4M空间。 文件数量过多 一个最简单的QTP脚本，共有4个文件夹，13个文件，当分割Action较多时，文件数与Action的个数呈正比上升。 问题描述 这两个问题，直接导致最终完成的工程文件达到700~800M，文件数以万计。这还只包括了信贷与结算的主要业务。而其中真正有用的脚本，全部用文本来存储的话，不会超过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的功能强大，不能体现测试用例对需求的覆盖，没有测试用例之间的树形结构…但是作为一个轻量级的测试框架，只要能够记录、管理50~100