51Testing软件测试论坛

标题: QTP 自动化测试框架剖析 [打印本页]

作者: hsjzfling 时间: 2011-7-25 20:10
标题: 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:11
本帖最后由 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插件了呢？同理，我们自己的框架也可以从这方面思考，不断强化和完善框架的能力的。

作者: lyscser 时间: 2011-7-26 10:10
写得很好，量体裁衣四个字很精辟啊，一句道出自动化的真谛

作者: efficient 时间: 2011-7-29 08:35

写的不错

作者: 17800455 时间: 2011-7-30 22:53
确实不错。值得支持。

作者: wugecat 时间: 2011-8-1 09:46
好

作者: archonwang 时间: 2011-8-1 17:39
杯具的自动化，在缺乏有效的保障运维机制之前，自动化的初期投入吓退了希望通过自动化快速得到结果的人群。

——如果你的产品/项目没有这种机制，请先建立机制再实行自动化。

作者: Drnmmond 时间: 2011-8-2 11:25
写的灰常好，但目前能做到自动化前期投入的公司很少呢（大公司除外）

作者: jassica 时间: 2011-8-2 12:00
写得很好，支持一下

作者: 云层 时间: 2011-8-2 14:51
最近难得看到的有内涵的帖子

作者: qiujialei 时间: 2011-8-4 18:07
很不错，量体裁衣呵呵

作者: 383270701 时间: 2011-8-7 15:41
确实是这样，自动化是一个需要考虑产入产出的实际成本

作者: SilenceHost 时间: 2012-4-28 10:22
写的很不错，受教了。
自动化资源匮乏的时候就应该有匮乏的应对之策。

作者: shanfeng1419 时间: 2012-5-7 11:29
学习了

作者: jeall 时间: 2012-5-7 15:12
学习

作者: hbycyf123 时间: 2012-5-17 22:20
学习

作者: 刘锦秋 时间: 2012-5-18 17:26
现在的行情是大家都推崇自动化，感觉学了自动化很牛X，学了有啥用，很多公司都用不上，还不如把手工测试做好，踏实点。

作者: lantianwei 时间: 2012-5-21 15:41
写的不错，赞一个~

作者: sunstear 时间: 2012-5-22 14:56
慢慢学习吧，虽然自动化技术不强。也是一个实用过程。楼主分析的很好，投入自动化需要，量体裁衣。不是所有项目都需要自动化，都需要搭建自动化测试框架。根据情况而定。

作者: kerryliyan 时间: 2012-5-23 13:57
框架还是挺重要啊个人觉得

作者: hbycyf123 时间: 2012-6-5 11:52
不错，框架很重要！

作者: mitsui 时间: 2012-7-12 16:27
受益匪浅

作者: AntonioNikki 时间: 2012-7-12 16:59
zhuan yi xia

作者: fengdishudu444 时间: 2012-7-13 13:37
学习了

作者: ljw375 时间: 2012-7-13 14:16
先保存下来，回去慢慢研究

作者: Qxlee 时间: 2012-7-31 15:31
marked

作者: shingo0109 时间: 2012-8-2 10:07
学习了，支持一下

作者: 班小丸 时间: 2012-8-6 10:19
马克，一会看。

作者: HGBAC 时间: 2012-10-19 14:36
我是个新手，项目组就我一个人，我也想用框架，但没资源，没实力，真郁闷

作者: 931743010 时间: 2012-10-19 22:58
顶下

作者: louqqson008 时间: 2012-10-22 09:50
目前部门经理希望我使用自动化测试，但很多项目都不怎么适合自动化，例如：项目周期短，给我测试时间短，（目前我的自动化还只是建立在对象库而进行的，所以需要项目开发人员，把项目基本完成时才能进入）

作者: lw8934 时间: 2012-11-21 19:04
写得很好~学习了

作者: 小牛吃老牛 时间: 2012-11-23 17:33
xiel

作者: heqingbluesky 时间: 2013-4-7 15:48
为啥以前我都没有看到？
其实，自动化或者不自动化，都不是最关键。
关键是，抓住测试的核心 - 质量的控制和成本的控制......

作者: tanky 时间: 2013-4-10 16:30
"饱受歧视的QC+QTP框架"

具体什么地方被歧视，能说说吗？

作者: cxwtomcat 时间: 2013-4-14 15:15
楼主的帖子很有内涵，商业的工具或者自开发的工具没有最完美，只有最合适，谢谢分享您的心得体会。

作者: springwan 时间: 2013-10-31 10:58
写的非常好,
里面的心得真是受益非浅

作者: Miss_love 时间: 2013-11-14 10:03
自动化方面的小白，过来学习了。

作者: lamaryy 时间: 2013-11-14 16:41
写得很好，支持一下！

作者: zhangq0813 时间: 2013-12-3 15:39
写的真心好，让我对框架的理解又更深了一步，非常感谢

作者: xchen 时间: 2014-6-16 17:05
大概明白了关键字驱动的含义，应是将一些操作步骤用一个关键字代替，这样比较简化；数据驱动应是通过数据来控制脚本的运行次数。

作者: auto_tester 时间: 2014-6-17 09:28
不错！收藏了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)