自动化测试框架比较
最近在研究自动化测试框架，也和网上的很多朋友聊了很多各种自动化框架的实现，我对其总结归纳比较下。当然，一家之言，仅供参考：
1、以QTP为核心的框架
QTP是大家最常用的测试工具。而现在很多公司用的自动化测试框架都是以此为核心的。我在触自动化测试之初最先上手的也是QTP。
以QTP为核心的自动化测试框架优点在于：适用性好，很多人都已经会用或者至少说可以简单应用，脚本也简单易懂，大多数无任何代码基础的测试人员都可以加入脚本录制和调试。
我本人一直对QTP不太感冒的原因也就是它的缺点：对象库。这个词对自动化测试的tester们实在是个巨大的打击。我不去一一细数其罪行，但是，关键字的框架，灵活度实在不敢恭维。再加上QTP在对flex等的支持上实在是也让人欲哭无泪。如果说还有其他的，就是一旦应用于企业自动化测试框架，必然需要购买正版，价格的问题。。。
2、RFT
Rational Functional Tester，IBM的产品。我一直对ibm产品颇具好感，不知道是不是由于第一台笔记本就买了IBM的缘故。跑题了，回来说这个框架。
优点：其一是相比起QTP框架，灵活度要高。因为它最核心的find()。每个脚本里都会大量出现类似“new uiTestObject(find(atDescendant(\”的语句，用来动态查找对象以解决对象识别问题。其二是对java的无缝连接，让很多人能更好更快的上手。
缺点：首先还是俗一点，说这个价格。高于QTP的价格让很多公司难以接受。第二，尽管ibm的团队非常强大，但是我们可以看到，由于种种原因，RFT的使用率比较低，这就导致网上关于该框架的疑难问题解决方案较少。第三，根据亲身经历，RFT的国内技术支持太弱，有问题很难请到，并且其技术支持人员测试技术能力都较差。
3、Ant+Selenium+Testng+Jenkins
这是我现在正在研究并使用的框架。（ps：jenkins这...还没用到。原来听说了hudson的强大，这个升级版估计会更有使用价值，未来研究）我这里说的selenium没有区分RC还是webdriver，两者各有千秋又互相补充，兼而用之即可。还是先说优点：第一：它开源不要钱！很多时候这是最关键的一点..当你在研究或推行一套框架的时候，价格是不得不考虑的因素。第二：灵活性，比RFT更加灵活，因为更加入了xpath（当然大型项目的脚本里xpath..慎用，尽量取id或稳定的属性）。加上配合IDE进行定位等，效果比较好。第三：相比rft，资料更全面，用该框架的也越来越多。据我了解，北京一些中型公司也在应用类似以selenium为核心的自动化测试框架。第四：就是开源性可以方便我们进行二次开发，例如提取对json和xml的处理来实现的数据驱动等。
缺点：第一：无论是RC还是Webdriver，对测试人员的编码水平有一定要求。同时ant，testng，hudson使用也都是小众，大多数人执行这个框架前需要有较长时间学习适应。第二：毕竟时间较短，不如QTP如此完善，但是我们可以期待其未来发展。也许3.0会带来一个巨大的变化。
4、Mcafe
我也不知道是不是这样拼这个框架，这是百度内部使用的一套自动化测试框架，或者叫平台。外面当然也买不到，我有幸见识了一次，包含了虚拟机的集成分配直至自动化测试执行，非常之惊艳。优点一大把缺点就是买都买不到。。。也给了我们一个方向，自主开发的自动化测试框架也许
才是最适合你的。
欢迎大家发表意见。
自动化测试 的优点
提高测试效率和降低测试成本
实现快速的回归测试，加快测试进度从而加快产品发布进度
更多的测试，提高测试覆盖率
保证一致性
提高测试的可靠性，避免人为因素
1.2. 为什么要做自动化测试框架
通过以往的尝试，发现真正实现自动化测试，并不是掌握了某个自动化测试工具，掌握了脚本的编写技术就能够达成，面对复杂的ERP系统，简单的录制/回放并不能达到自动化测试的要求，完全通过编写脚本的方式， 工作 量巨大且可维护性极差、不能复用。实现自动化就是为了能够提升测试效率，不具备可维护性、复用性差将成为导致自动化测试失败的最致命因素，付出巨大代价但起到的效果甚微。
基于以上因素并结合行业发展思路，在正式实施自动化之前，必须搭建一套适合的自动化测试框架，将脚本能够有效的组织、连贯应用起来，提高测试脚本的可维护性和可读性。
1.3. 希望达成的目标
搭建符合以下要求的自动化测试框架，使得未来自动化测试正式实施时能够有序、高效的开展：
高复用性
高可维护性
稳定性
快速编写脚本
自动执行
正确输出结果
能够不断提升自动化测试比例
1.4. 实现思路
分层设计：业务流程、功能点、操作组件
我们在进行测试时，首先会验证各个页面、各个字段的正确性，到验证功能点的正确性，再组
合各个功能点进行业务逻辑、业务流程的验证，最终确保系统满足业务需求。
* 对于自动化脚本，采用分层的思想，先实现最底层的操作组件，通过调用操作组件、及业务逻辑实现对功能点的验证，再通过调用业务逻辑组合功能点实现对业务流 程的验证。不同的业务流程，对于底层的操作组件、中间层的功能点函数是完全可以复用的，只是调用的业务逻辑的差异，或者是测试数据的差异性。
尽可能做到各脚本之间具备独立性，不相互依赖，便于进行各种基本场景的组合运行。
如销售系统中的选择房间操作，在做预约、小订、认购等操作时，都需要用到选择房产，因此可以将选择房产做为一个公共的操作组件，详细描述选择房产的操作 步骤，在测试新增预约、新增小订、新增认购等功能点时都需要调用到选择房产的操作组件，只是业务的校验逻辑与所选择的数据不一致。
再看业务流程，新增一个小订单后可以作废，也可以由小订转认购，业务流程就有两个：新增小订单—作废订单，新增小订单—转认购，这两个业务流程中“新增小订单”这个功能点是一致的，可以通过调用不同的用例数据组合成不同的业务流程。
● 脚本分离设计：对象、操作、测试数据、业务逻辑相互剥离、灵活调用
对某个功能进行自动化测试，实际上就是对这个功能涉及的对象进行操作，输入测试数据来验证其结果的正确性，复杂的验证点需要编写业务逻辑。如果全部用脚 本的方式编写，针对每一条测试数据就需要编写一份脚本，脚本量相当巨大，同时任何改动（程序、测试用例、GUI对象）都需要调整大量的脚本。
为了达到可维护性、可复用性，将对象、操作、测试数据、业务逻辑剥离、分开管理，通过调用关系去组合实现不同的测试用例。
对象资源库
测试数据资源库
操作组件（描述操作步骤）
脚本：业务逻辑
分离后，如果要增加测试用例，只需要维护测试数据，如果程序修改，增加了对象，那么只需要维护对象库、操作组件，增加对这个对象的操作。
封装基础函数、基本的业务逻辑、验证点
通过对基本业务逻辑、验证点的封装、调用，实现快速的脚本开发
如一个数据保存的功能，每一条数据在做了增、删、改的操作后，都需要验证保存至后台数据库 的数据正确性，通过预期结果与数据库实际产生的数据集进行比较验证，在获取数据库实际产生的数据集的方式是通用的，只是不同的功能所要验证的数据表、字段及Where条件不一致，获取数据集的方式就可以封装成一个基础函数，传入不同的SQL 语句做为参数即可。同时预期结果与实际结果集的比较也可以封装为基础函数。
再如，系统页面中在某些操作或条件下，部分字段是只读不允许编辑的，或者是隐藏不显示的，编写脚本时需要对每一个对象写一条语句验证其只读和隐藏属性的 正确性，如果将只读和隐藏属性
的验证进行封装，针对每一个页面进行验证，那么只需要传入这个页面只读或隐藏的对象名称，调用封装的函数执行验证。可以大大 减少脚本量，也更易于维护。
有效的执行体系
批量、定制执行、自动运行
自动化测试真正达到提升测试效率，需要实现无人值守情况下的批量自动执行，并且可以定制执行。
异常处理机制
脚本执行过程中，因程序错误或环境问题、脚本自身问题经常会出现非预期的错误：如意料外的弹出窗口、发现错误的数据、未找到对象、输入文件打不开或不能 读等，有些情况下当前用例出错，并不影响后续用例的执行，需要支持异常处理机制，终止执行或者终止当前用例，继续后续用例的执行，亦或者跳过当前步骤，继 续执行后续操作，并输出当前的错误报告。
*业务数据还原初始状态
自动化测试需要循环执行，执行完成后，需要恢复初始状态（主要是业务数据），以使得程序重新提交版本后能够循环执行，不断的对新版本进行回归验证。
版本管理
随着待验证版本的不一致，自动化测试脚本也会不断的更新、维护，同样需要进行版本管理。
结果体系
针以每条用例，输出用例执行结果
针对每个检查点，输出详细的检查点执行结果
输出执行日志
结构化管理
对象、操作组件、基础函数、测试数据、功能点脚本、业务流程组合，如此多的层级、调用关系，必须进行结构化管理，采用高度组织化的目录结构、分级管理，方便进行正确及快速的调用，方便能够快速定位、查找问题。
本帖最后由 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框架都能够满足这一点。 1. 是否数据驱动(DD)框架
数据驱动是相当常见于自动化测试之中的，它可以通过不同组数据的输入，走到不同的业务分支或者获得不同的测试结果。提供便利的数据读写、解析功能是非常有意义的。 参考下DataTable的能力，我们甚至可以在代码中不写任何循环语句，只是输入数据和进行相关设置，就可以达到执行多组指定数据进行循环测试的目的，满足这个条件才能称之为数据驱动框架。 在测试脚本中写上for next，do loop等语句只能说该测试脚本是数据驱动的脚本，而不能因为脚本使用了数据驱动，就说框架是数据驱动框架。
这里也不歧视非数据驱动框架，有些项目需求也不是很要进行海量数据的反复测试，而只是测试流程，比如用自动化覆盖冒烟测试和E2E测试。若目标项目基本都只是这样的需求，偶尔需要的时候写个循环也不是很费事。这样的情况下，去花费大量力气去做数据方面的处理就有点不合适了，功能越强大的框架，开发与维护它的成本就会越高
2. 是否描述性编程(DP)框架
本人是对象库拥护派，不过这里就不再赘述孰优孰劣了。有朋友在公司使用基于DP的框架，据说几年下来用的也挺好的，证明其实也是可行的。跟他们聊下来的感觉就是对QTP对象库的理解的差别，如同剑宗与气宗之争一样。如果你对对象库理解透彻，以对象库为主就是了，必要的时候也可以用DP;同样若是理解DP更多一些，那抛弃OR全部使用DP也不无不可。
3. 是否使用共享对象库(SOR)
框架如果是建立在使用对象库的基础上的话，那如何来管理对象库呢？这其实也是个值得研究下的，对象库管理机制的优劣，可以影响到项目的进度。
建议使用共享对象库，可以按大模块来划分，也可以按照应用程序来划分。在多人参与同一大型自