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

      进行软件系统的回归测试，已经有越来越多的组织在使用QTP。 QTP易学、上手快，其提供的帮助也非常详细，这是它的一个巨大优点。然而，众多的帮助或者范例都是基于一个个简单的Demo性质的toy案例，都是对某一个或者几个知识点的解说，缺少系统级别的介绍和说明：针对一个现实中完整的系统，如何组织相关的测试用列？如何设计测试数据？如何产生简洁、明了的测试结果？ n呴"+檍  
　　QTP在组织测试逻辑时，自身提供了testcase和action两种结构，这两种结构是包含和被包含的关系：一个testcase可以包括多个action。在action里面，众多的测试点可以按照实际逻辑进行组织。相比 testcase，action才是真正体现测试用例的地方：每个action都有自己对应的object repository；action可以设置为reused，进行复用；每个action都有自己DataSheet；测试用例的相互调用，也是通过 action来进行的... 相比较而言，testcase的概念在QTP中比较“弱”，只是提供一些公共设置的管理，如设置使用到的函数库，错误现场恢复，测试使用的相关参数设置。 浨_舻?f?  
　　根据经验，实际使用中，action跟我们接触的更多。 :a軐莾?时  
　　一、组织测试用例 x詗?M  
　　针对现实中一个完整的测试系统，测试用例到底应该如何组织呢？ 恝`獤儞?  
　　1）按照QTP testcase来组织 '鷮僻9D`?  
　　在QTP中建立多个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。 鲩Kq柴L? 
　　又比如系统中另外一个需要测试的replace window：

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