QTP 自动化测试框架：第一章 基本框架介绍及主要思想

        喜欢看代码的，请直接从第五章节开始，以下内容希望先看完，否则会有点晕

 

        QTP作为行业较早出现的自动化测试工具到现在最新的重新命名为UFT，虽然研究的人确实很多，价格也很昂贵，但无可否认的是它快速入门，(也许有人就会说录制的没什么用的，但我认为这个得根据实际来，如果UI很稳定，对象基本都是标准的，又没有太大时间成本去做的话，为什么不可以直接用，不一定是录制，直接写也可以)，特别是强大的对象库识别功能，支持多BS/CS结构，这是其它大多数功能自动化测试工具无法比的。有些自动化工作量几乎要把程序都重写一次了，这样的我觉得是没有任何意义的，直接让开发去搞好了。成本可能更低

       所以，在这我们就直奔主题，好的自动化测试框架，首先应该 是可扩展性强，跨平台支持广，特别是对于现在需求变动越来越频繁的情况下，不用专门的自动化开发人员投入太大精力维护变得越来越重要。

      今天介绍的自动化框架主要有以下几个特点：

      1.依赖于QTP本身，所以支持BS/CS   ，强大的对象库识别功能

      2.支持描述性对象库来作为补充

      3.维护功能简单，仅需要扩展对应的操作事件就行

      4.框架结构清晰，不会出现每一个测试都有一个文件夹的情况

      5.颠覆了传统使用QTP的思路，特别是执行测试的时候会有较大调整

      6.重新定义了测试报告样式，以支持调整后测试执行方式

      7.增加EXCEL简要报告

      8.可自动发送测试结果到指定的邮箱

      9.关键字驱动，同时也可以平常过渡至数据驱动方式

     10.框架稳定后，普通测试人员、甚至产品 都可组织测试

     11.支持场景恢复

 

 主要思想：

    QTP正常脚本 的运行方式是

  window(XX).object("ss").XX

   broswer(xxx).page.set...

如上。其实我们发现(参照其它框架思想)以上的结尾部分很多地方是重复用的，前面是对象，后面是事件。

  事件是有限个的，所以我们可以把它当作一个方法

  而window...page...这些其实就是对象，QTP强大 的功能在于它的对象库管理功能，这块终于可以派对上用场了，当然 有人说这样很验证管理，我一直想必不明白，有什么难管理的，不同模块分开管理能有什么问题，另外 本框架对此次部分进行了扩展，支持描述性编程，描述性文件当作对象库一样来处理，只不过传递参数的时候会有前缀标识，这样就读取描述对象库而不是共享对象库了。而且更大的一个好处是支持不同语言了，对象库完全 分享，即使业务有了变化 ，我们只需要调整EXCEL中的步骤及对象就行了，框架不要任何的修改，不涉及代码，普通的测试人员即可创建测试并运行，这样维护脚本就只需要很小的工作量，并且 支持多个平台，适用于公司 不同产品直接套用(当然 有些操作是需要对方法进行扩展的。)

 

  这里对象要转换成字符串，QTP已经做好了，可以 将对象库直接转换成XML文件，不过在做之前需要对转换后的XML文件进行深入理解，才能通过读取XML文件来拼接字符串。果然 这个功能是有目的的。

 

同时这里优化了一部分是action部分，正常情况下action与aciton之前是平行的，每一个测试的入口是action文件，但这样会带来一个问题，会有很大一堆 东西，所以我们调整，所以有的测试只从一个aciton走一次，剩下的工作就交由核心框架处理，通过循环一个EXCEL文件中的关键字来处理。

 

这样带一的一个问题是，测试报告，这里给了两种解决办法，一种是通过创建node改写已有的report.(有人说不太好用，但因为直接能插入截图，且是树形结构还是有它优势 的，所以这里保留)。另外 补充了一个EXCEL测试报告 ，可自己扩展，生产简要的测试报告。

 

最后还有一个问题是场景 恢复，之前  一大堆 在实际 中可能设置的比较复杂，并且不一定是我们想必要的，这里统一处理成当出错时直接跳过当前循环进入下一个测试(有人说这样不好，不过一般大多数情况你再次重新执行也无效)。运行过程中将运行中的如循环参数，测试模块名称，测试名称记录在恢复文件中，然后一旦捕获到报错信息时，重新启动QTP，运行测试，这个时候直接从中断地方的下一循环开始即可。

 

以上即为基本的思路。有更好的想法或意见请留言。

 

 

 

以下是基本结构图，执行模式

    
     

 
 2.  基本的结构图