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