学习<QTP 开发框架>

 

  今天有空学习了一下QTP的框架开发，主要学习了从如何构建QTP测试框架、QTP应用模式设计、以及举例用框架构建vbs测试Webservice脚本这几方面来写的QTP框架的开发。收获蛮多。。。

 

  一、如何构建一个QTP测试框架

     1.为什么要使用框架？

      框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。可用于减少冗余代码、提高代码生产率、提高代码重用性和可维护性。

     2.自动化测试框架的架构

      脚本层（业务组件开发），业务层（流程的开发和组织），数据层相分离，是框架组织总得方针，为开展工恩那个自动化测试提供一个高效、稳定、容易得测试实现。

 

 

      QTP在组织测试逻辑时，自身提供了testcase和action两种结构，这两种结构师包含和被包含的关系：一个testcase可以包括多个action。在action里面，众多的测试点可以按照实际逻辑进行组织。相比testcase，action才是真正体现测试用例的地方：每个action都有自己对应的object repository；action可以设置为reused，进行复用；每个acting都有自己的DataSheet；测试用例的相互调用，也是通过action来进行的...相比较而言，testcase的概念在QTP中比较“弱”，只是提供一些公共设置的管理，如设置使用到的函数库，错误现场恢复，测试使用的相关参数设置...

    根据经验，实际使用中，action跟我们接触的更多。

    一、组织测试用例

     针对现实中一个完整的测试系统，测试用例到底应该如何组织呢？

      1) 安装QTP testcase来组织

       在TTP中建立多个testcase，每个testcase对应实际系统的功能组；在每个QTp testcase中，通过action来组织每个测试用例。比如：现在测试用例需要测试Edit菜单下得Find功能。在这个测试用例中，有多个部分要测试：a）Find Next的功能；b)测试CountAll功能；C)测试Help的功能。对于Find Next，对每一种情况，如各个checkbox选中或不选时，又分别进行测试。所以，在这种组织模式下，可以将关于Find Next的测试点归类为一个action，将CountAll的所有测试点归类为另一个action......所以这些action，最后形成一个FindNext testcase。

 

 

又比如系统中另外一个需要测试的replace window:

 

同样可以在QTP中建立一个Replace的testcase，然后对每个要测试的功能组，建立action，在每个action内部，对各个相关的测试点进行测试。

这种测试框架组织模式的优点是：可以组织层次较多的测试用例，结构比较清晰。

 缺点是：在QTP中，由于testcase是最高一个级别的组织结构，这样，众多的testcase，其上面就缺少一层组织所有这些testcase，有点类似Visual Studio中得solution这个层次（solution下面包含project，project下包含各种文件和目录...）.这样，必须手工做额外的工作来弥补这一块，如：QTP只针对每个testcase产生一个测试result report，现在多个testcase，就缺少一个集成的测试结构，又比如，要自动运行这些testcase，必须基于这些testcase再建立一个更高层次的脚本来管理这些testcase。

  2) 按action来组织

     整个系统只建立一个testcase，所有的测试功能按照action分类。

     可以将上列中得Find和Replace由testcase级别降级为action，这样，导致每个action中，可能存在多组测试点，层次结构上少了一层，刚健不清晰简洁，尤其对于AUT（Application Under Testing，被测系统）层次结构比较复杂时。

   但是，这种模式的优势是：刚好符合QTP自身的组织结构（一个testcase，多个action），产生的result report也是一个集成好的，无须另外集成。

   3) 按照VBS函数来组织

     这种组织模式是建立一个testcase，只包含一个action，然后，所有的测试功能，全部组织成过程或者函数。只是这种情况下，庞大的过程函数库如何维护？这个问题能解决，似乎这也是一个可行的组织模式。