自动化框架的一些构思

★通过QTP现有的功能管理脚本,对象和数据的缺点

1.脚本文件过大：

主要是两方面原因导致，

一是对象库的文件，默认生成得每个空的对象库文件为192K，这样一个空的QTP脚本文件就至少需要192K*2=384K的空间（Action0和Action1），如果分割的Action多的话，占用的空间就更多。

二是Excel的文件，同样由于分割Action，每个Action需要使用一个独立的Sheet，包括脚本中调用的Action，这个在复杂的脚本中，表现得更加明显。

2.文件数量过多：

 一个最简单的QTP脚本，有很多的文件和文件夹,当分割Action较多时，文件数与Action的个数呈正比上升。如果使用Action复用的方式的话，会在维护、转移、版本控件等方面存在巨大的困难。

3.不利于查看脚本：

 使用Action的方式来保存脚本，用户在查看相关脚本时，不得不需要打开QTP，然后再把相关Action导入进去，这样将不利于脚本的查看。也给脚本的维护增加了难度。

4.不便于脚本批量运行：

虽然QTP自带一个批量运行工具可以批量加载所要运行的Action。但是如果你想要重新调整Action的执行顺序的话，那你接下来就有的你忙了。

5.测试脚本维护量大,维护起来成本和时间大,维护难度上升

现在的脚本是对象,数据,和脚本都是保存到一起,放到一起管理的,所以维护的时候需要打开脚本,在脚本比较多的情况下,增加了维护的难度和量。

6.对异常窗口的处理能力弱

目前QTP对异常窗口的处理能力比较弱,现在的解决方式是用RecoverySenario或者在后面家IF判断来解决, 假如用RecoverySenario的话,判断的时间很慢,效率低,而且成功率也很低。

使用IF来判断的话工作量大,只要是有可能出现类似提示窗口的话都要进行判断。

★解决办法和方案

1.使用数据库或者XML来保存对象库信息

脚本所用到的对象统一放在数据库中，并将相同模块的对象放在一个表中。在运行相关模块的脚本前，先将某个模块的对象库通过存储过程提前加载进去。

2.使用Excel的文件来管理测试数据

将测试数据保存在单独的Excel文件中, 并将相同模块的数据放在一个sheet中。在运行脚本的时候用到测试数据的时候,通过字段名读取相关数据

3.使用Excel的文件来编写自动化测试用例

我们通过使用Excel文件来编写自动化测试用例,通过该文件的相关字段信息来动态生成自动化测试脚本,QTP中没有原始的自动化脚本,而只是调度各个模块的中央控制脚本,这样有利于以后的维护

4.使用Excel的文件来管理自动化测试用例并且批量运行脚本

将自动化测试用例保存到Excel中，可以很方便的更改测试的执行顺序，且每个测试人员都拥有一张TestPlan，可以更加清楚的了解测试人员编辑脚本的情况。

5.编写自定义函数

我们可以通过编写自定义函数来解决对象识别的问题,或者使自动化脚本操作和维护更加简单和方便

6.写一个单独的程序来监控异常窗口程序

写一个单独的窗口监控程序,自动监控异常的类似提示窗口的窗口程序,然后发现该窗口对该窗口进行处理

★框架需要的功能和结构说明

1.中央控制模块

调度所有模块的核心模块,用来通过自动化测试用例来动态生成脚本的核心脚本,在QTP中完成

2.数据模块

保存测试需要的数据,通过字段来读取数据,可以通过QTP插件或者自己编写VBS脚本来设置脚本的读取方式,使数据读取更加灵活

3.对象模块

对象的相关信息可以通过数据库或者XML来管理和存储,在对象比较多的情况下建议使用数据库进行管理,通过存储过程来读取对象,使相关的对象拼接成QTP可以识别的字符串

4.比较模块

没有验证的自动化测试等于没有起到什么作用,所以验证模块也是非常重要的模块,该模块目前为止只能通过自动化测试人员来编写完成,然后通过自动化测试用例中的标识来调用相关模块

5.自动化用例管理模块

通过Excel的文件来管理自动化测试用例,来控制自动化用例的顺序或者通过QC来管理自动化测试用例的调度和顺序

6.日志模块

跟踪脚本的运行过程,使我们能更方便的找到错误的位置

7.报告模块

生成自动化测试的报告,把该报告放到某个文件夹下,方便我们查看结果,一般使用Excel文件来生成报告

8.导入模块

通过该模块批量自动的将对象相关信息导入到数据库或者XML中