QTP 自动化测试框架剖析
本帖最后由 hsjzfling 于 2011-7-25 20:16 编辑QTP 自动化测试框架剖析
前言：本文旨在阐述QTP自动化测试框架特性及何从选择，而不会介绍具体如何去编写自动化测试框架，只想索取代码的朋友可以略过本文。
这几年的QTP自动化测试生涯中，它山之石也采了不少，从早期的saffron到目前的hybrid关键字驱动框架，每个框架都或多或少有些可取的地方，也为自己设计各框架提供了不少思想的源泉，在剖析各种不同类型不同风格的框架之前，我想先问2个问题：
1. 我们为什么要用自动化测试？
2. 我们为什么要用自动化测试框架？
大家不妨先仔细思考下这两个问题，再继续看下文。
一个完整的框架需要包含些什么要素呢，我们可以看看QC+QTP这套原版框架提供了些什么功能。主要功能：
1. QC的Test Plan可以存放、管理QTP脚本、函数、数据等
2. Test Lab中可以计划-批量-分布式执行用例集
3. 通过QC来执行QTP脚本呢默认还会将On Error 设置为Next Step
4. 执行完了以后呢可以在Test Lab中查看各执行结果，同时也可以查看以往的历史结果
可选功能：
1. QTP自身提供了DataTable以供数据驱动使用
2. QTP提供了多种检查点
3. Action提供了公用模块的思想
4. 供业务专家使用的关键字视图
5. QC提供了BPT
6. 提交defect功能
7. QC中可以自动发送执行状态邮件
8. QC中可以设置执行状态参数
……
这里只是列举出一部分，但由此也可以看到，一套完整的框架需要能管理脚本，可以方便的执行，有错误处理机制，能生成报告，当然环境初始化也是必须的。我们通常讨论的框架大多是脱离QC的，因而这些功能都必须要依靠自己的代码来实现，而框架的扩展功能就可以参考可选功能中的点了。值得一提的是，框架中的东西是要能够几乎全部复用的，而不是换个项目框架就不灵了。这点其实不过分，饱受歧视的QC+QTP框架都能够满足这一点。
现在应该对框架有点初步了解了吧，不是什么玄乎的东西，只是由一个个大大小小的功能组合而成，评价一个框架好不好，就可以从这些点上一个个去考量，看看有哪些功能，是否好用。
再看看大家争论颇多的几个要点： 本帖最后由 hsjzfling 于 2011-7-25 20:17 编辑
接上
1. 是否数据驱动(DD)框架
数据驱动是相当常见于自动化测试之中的，它可以通过不同组数据的输入，走到不同的业务分支或者获得不同的测试结果。提供便利的数据读写、解析功能是非常有意义的。
参考下DataTable的能力，我们甚至可以在代码中不写任何循环语句，只是输入数据和进行相关设置，就可以达到执行多组指定数据进行循环测试的目的，满足这个条件才能称之为数据驱动框架。 在测试脚本中写上for next，do loop等语句只能说该测试脚本是数据驱动的脚本，而不能因为脚本使用了数据驱动，就说框架是数据驱动框架。
这里也不歧视非数据驱动框架，有些项目需求也不是很要进行海量数据的反复测试，而只是测试流程，比如用自动化覆盖冒烟测试和E2E测试。若目标项目基本都只是这样的需求，偶尔需要的时候写个循环也不是很费事。这样的情况下，去花费大量力气去做数据方面的处理就有点不合适了，功能越强大的框架，开发与维护它的成本就会越高
2. 是否描述性编程(DP)框架
本人是对象库拥护派，不过这里就不再赘述孰优孰劣了。有朋友在公司使用基于DP的框架，据说几年下来用的也挺好的，证明其实也是可行的。跟他们聊下来的感觉就是对QTP对象库的理解的差别，如同剑宗与气宗之争一样。如果你对对象库理解透彻，以对象库为主就是了，必要的时候也可以用DP;同样若是理解DP更多一些，那抛弃OR全部使用DP也不无不可。
3. 是否使用共享对象库(SOR)
框架如果是建立在使用对象库的基础上的话，那如何来管理对象库呢？这其实也是个值得研究下的，对象库管理机制的优劣，可以影响到项目的进度。
建议使用共享对象库，可以按大模块来划分，也可以按照应用程序来划分。在多人参与同一大型自动化项目的时候，使用共享对象库显得尤为重要。但对一些框架而言，甚至只能使用共享对象库。说白了，就是将对象库与代码分离开。
4. 是否关键字驱动(KD)框架
数据驱动的一个特点就是将测试数据与代码分离开，而关键字驱动的特点就是将业务与代码分离开。注意，这两者是没有从属关系的，也没有谁比谁高级这一说。看看QTP本身就是关键字驱动的，我们看看它提供的KD功能：对象+操作+值 这就是一个测试步骤。其实
KD就这么简单，同样没啥玄乎的，我们实现KD的时候，就是将代码封装成一个个关键字。
那要不要使用KD呢？可以想象下，将所有操作，业务流程等等都封装成一个个关键字，前期代码量必然是相当大的，如果封装的关键字平均下来每个都用不了几次，那花那么大力气去弄它是不是合适呢？如果封装的关键字平均下来每个用了几十次上百次，那合不合适呢？
对于一个大型的自动化项目来说，需要的人手必然也是不少的，而KD的特点是将业务与代码分离，就意味着不一定需要那么多自动化专家了，自动化专家专门写关键字的代码就好了，用例、流程、场景的编写与维护交给业务专家或者手工测试人员去完成就可以了，这无疑是一个很大的诱惑。 不过对于自动化规模不大的企业与小型项目来说，就不一定有必要这么做了，前期开发的投入，估计差不多都能将就着完成测试任务了。
5. 无框架
无框架就一定不好么？未必的。很多时候我们其实可以考虑无框架的，尤其是在资源有限的时候。
比如某公司从未有过自动化，也不用QC，忽然老大说我们引入QTP来做自动化试试看吧，招个QTPer进来，前期评估考量后发现该项目确实适合用QTP做自动化的，相信不少朋友有过这样的经历。这时候作为一个高级自动化工程师的你，会怎么去做呢？先花3个月来开发一套比较牛X的框架，然后再花3个月来写一套比较牛X的脚本？对一个从未有个自动化实施体验的老大来说，让一个高级的resource去花费大量的时间做一些看不到价值的东西，是很没底气和信心去期待结果的，很可能就会做着做着就不了了之了。
无框架的好处就是周期短，见效快。Hard coding录个脚本出来调通了用来跑个冒烟测试还是很划算的事情，自动化资源匮乏的时候就应该有匮乏的应对之策。领导们尝了甜头自然会逐渐加大在自动化方面的投入，然后再逐步开始建立自动化测试框架，这样才会比较容易获得成功。
6. 是否适合自动化需求
其实这点才是最重要的。前面已经提到过了，没资源的时候咱就无框架；有QC的话QC+QTP凑合用用也蛮不错的；大量的海量数据测试需求的时候就引入数据驱动框架；大型自动化团队或长期海量业务操作步骤，引入关键字驱动框架吧；数据复杂业务复杂呢，那就数据驱动+关键字驱动，也就是Hybrid关键字驱动框架了；理解DP多过OR那用DP就是了，基于DP的Hybrid关键字驱动框架也是有的……
回头来看看开篇提的两个问题：
Why Automation? ——提高测试效率
Why Framework? ——让自动化测试活动更便捷
一套强大的自动化测试框架可以让自动化活动变得有条不紊，大量简化自动化过程中的工作量。
那么实际工作中如何选择框架呢？功能强大的框架开发维护成本高，资源不够的情况下会举步维艰；功能简单的框架呢框架代码量小，但用着就没那么感觉美妙。How to choose？ 四个字：量体裁衣。
综上所述，没有最完美，只有最适合。
后记：应用于项目的框架需要有为项目定制的函数等等，不同项目可能连开发语言与运行环境都不一样，但企业级的自动化测试框架则是凌驾与其上的，不同项目增加些定制就可以了，谁能说QC+QTP只能做Web而不能做.Net了，一旦开发过一次Java插件，以后是不是都不用再开发Java插件了呢？同理，我们自己的框架也可以从这方面思考，不断强化和完善框架的能力的。 写得很好，量体裁衣四个字很精辟啊，一句道出自动化的真谛 {:3_79:} 写的不错 确实不错。值得支持。 好 杯具的自动化，在缺乏有效的保障运维机制之前，自动化的初期投入吓退了希望通过自动化快速得到结果的人群。
——如果你的产品/项目没有这种机制，请先建立机制再实行自动化。 写的灰常好，但目前能做到自动化前期投入的公司很少呢（大公司除外） 写得很好，支持一下:victory: 最近难得看到的有内涵的帖子 很不错，量体裁衣呵呵 确实是这样，自动化是一个需要考虑产入产出的实际成本 写的很不错，受教了。
自动化资源匮乏的时候就应该有匮乏的应对之策。 学习了 学习 学习 现在的行情是大家都推崇自动化，感觉学了自动化很牛X，学了有啥用，很多公司都用不上，还不如把手工测试做好，踏实点。 写的不错，赞一个~ 慢慢学习吧，虽然自动化技术不强。也是一个实用过程。楼主分析的很好，投入自动化需要，量体裁衣。不是所有项目都需要自动化，都需要搭建自动化测试框架。根据情况而定。 框架还是挺重要啊个人觉得
