动化项目的时候，使用共享对象库显得尤为重要。但对一些框架而言，甚至只能使用共享对象库。说白了，就是将对象库与代码分离开。
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插件了呢？同理，我们自己的框架也可以从这方面思考，不断强化和完善框架的能力的。
现在应该对框架有点初步了解了吧，不是什么玄乎的东西，只是由一个个大大小小的功能组合而成，评价一个框架好不好，就可以从这些点上一个个去考量，看看有哪些功能，是否好用。