该方法主要特点：

　　1、将模块分类别进行管理

　　2、将对象从QTP仓库对象中抽取出来，用外部描述的方式生成

　　3、将测试主过程方法的脚本与最终生成测试结果的脚本进行分离

　　4、解决了失败的框架1中的文件目录组织的问题

　　5、将配置文件进行了单独管理

　　6、将系统测试用例与数据建立了一一对应的关系

　　7、使用了QTP的场景恢复技术，考虑了QTP出现异常时的情况

　　实际编写过程中出现的困难：

　　1、拥有失败的框架1中的（2、4、5、6）的问题

　　2、建立数据与测试用例一一对应关系，耗去了不少时间，并且这些数据只能够在此系统使用一次。更糟糕的是系统测试用例有些用例是概括性的，而我们在整理用例时不得不把这些用例更加详细的细化，而此又用去了不少时间。

　　3、由于使用了Write_ExcelCell函数，使得我们的测试用例必须分多个Excel进行管理，并且每个需要根据每个模块的用例重新构建一个写Excel函数。另外，采用此种方法在长时间的测试过程中，excel2007有可能会遇到一些异常问题，导致excel.exe进程不能及时关掉，重而导致QTP脚本在下一次写结果的时候无法写入，造成excel中的结果为空。

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/54/n-247254.html

　　框架是什么？框架要做到什么样的效果？

　　框架就是一种脚本组织和管理的方式，并附有一系列的规则的要求，除要能够满足“失败的框架1”中的要求外，似乎还需要以下要求：

　　1、要能提供详尽的日志，最好是每个执行步骤的日志。

　　2、要能够很好的处理测试用例与对应数据的依存关系。

　　3、要能保持适量封装的函数，并且能够使这些函数尽量的多次重用，所谓的多次有可能是针对本系统的也有可能是多个不同系统的。

　　4、要在QTP出现异常时及时的通知到我们，让我们能够及时的知道有此异常。

　　5、要抛弃那些不稳定、不好用的方法，转而使用能够提供稳定运行、简单好用的方法。

　　6、要代码不仅当时能够自己看懂，而且过了很久也要能看懂，并且还要能让其它人看懂。

　　7、要数据能够尽量的重用，最好做到原始数据能多系统共用。

　　8、要使常量尽量的统一在一起，以便维护。

　　该方法可取之处在哪儿：

　　1、文件目录简洁，操作不复杂。

　　2、将配置常量集中管理。

　　3、将脚本划分为QTP基本函数、测试系统常用函数、测试函数、实现函数。