使用RFT工具进行自动化测试初感

lovecy

在没做自动化测试之前，我一直担忧自动化测试将会取代手工测试，甚至曾经还担心因此而需要转行，否则就要丢饭碗。自从接触自动化测试以来，我发现自动化测试所能做的事实在有限，对于一般的基本功能验证，使用自动化来完成还是一个不错的选择，然而自动化毕竟是通过脚本运行测试，不可能有人的思维和逻辑，尤其是不会发散测试。从这一点上来说，自动化永远不可能代替手工测试。

    一个好的自动化测试顶多也就能完成测试工作的80%工作量，剩余的20%工作，还是需要测试人员去发散测试的。由于接触自动化测试也才不久，对于自动化测试所带来的理想目标也没个谱，所以以上所说只是在自己摸索使用过程中的一点感受而已。

    就我所使用的自动化测试工具（RFT）来说，它还是一款相当不错的工具的，特别是对于有Java编码基础的人来说，更是会喜欢上它。它与Java的无缝连接，使得要实现一个功能变得简单。RFT工具的原理应该是通过录制脚本，使得所操作的对象都记录在测试对象地图中，然后在回放的时候到测试对象地图中去找到相应的对象，通过识别属性来找到控件，完成回放测试。这很明显，如果在回放测试时界面上的控件属性改变以后，RFT工具就无法找到这个对象了，从而会报“找不到合理的值。。。”等错误。所以，如果还是需要使用原来录制好的脚本进行回放测试的话，就必须更新测试对象地图，也就是重新找过这些对象。可以想象一下，如果版本之间有大的改动的情况下，将会有多少对象需要重新找过，以便能够适应新的测试版本？显然，这种方式对于回归测试来说，需要更新的地方就比较多了。于是，这里有一个比较好用的功能，find()方法，它能够通过属性值动态查找测试对象中的控件，只要控件的那个属性没变化，不管你前端怎么变都没关系，反正在执行脚本时，它每次都会重新去找符合条件的对象。于是在脚本中会有大量的类似于new GuiTestObject(find(atDescendant(".xxxx","xxxx",".xxxx","xxxx"))).click();语句出现，find()方法就是通过在脚本中以动态方式查找对象，每次执行时都去查找，从而不至于出现由于界面的更改而需要大量修改脚本的局面。然而，这也是有点问题的，在大量new一个新对象以后，内存能否吃得消？这是我所遇到的一个疑惑。另外，在通过find()查找一个对象时，常常会因为执行语句太快的原因，使得报出无法找到对象的错误。尝试使用xxx.waitForExist()方法，不过从来就没成功过，真是奇怪。只能使用sleep(n)来让它硬性等待，尤其是在切换页面的时候，报无法找到对象的错误的概率大大提升。还有一个问题，那就是各位开发人员对控件的属性做的一点也不规范，参差不齐，不是缺了胳膊就少了腿。命名也极不规范，导致在动态查找时困难重重。想起来就气~~~~

　　因为刚接触RFT工具才做一个工程，所以对这个工具的使用也是一知半解，很多高效的函数功能我未能好好运用，没办法，一来没有看过别人是怎么做自动化测试的，心里面对自动化测试的概念没个谱，二来自己的编码水平也是赶鸭子上架硬着头皮搞的（搞多了倒是觉得现在已经基本够用了）。唯有以不断的学习中提高自己吧。不过可以看到，现在做的一个工程比上一个工程要顺畅多了，思路也是比较清晰了，只是在实际编写脚本时，会遇到很多没有想到的问题。

　 一句话，期待能够看看其他做自动化测试的XDJM们是如何做自动化的，也很想加入一个有真正自动化测试团队的公司，以正自己的思想。希望有同仁前辈能够指点一二，不甚感激！

jinlei303030

我和楼主一样感觉!

求高手!

garyliu

我说几句我的看法

1. “然而自动化毕竟是通过脚本运行测试，不可能有人的思维和逻辑，尤其是不会发散测试。从这一点上来说，自动化永远不可能代替手工测试”

自动化测试没必要去代替手工测试，二者是可以共存的，各有各的优势。汽车的诞生难道就是为了取代自行车？不是的。 另外你提到思维和逻辑的问题，计算机是没有思维的吧，本质上它只认识0和1，但人们通过编写代码赋予它实际生活的逻辑，它就可以实现人们的需求。自动化的脚本也是这个道理，随着时间的发展和技术的进步，也会越来越灵活。

2. "RFT工具的原理应该是通过录制脚本.......完成回放测试"

录制-回放只是其基本功能，方便一部分人使用而已。其实，真正在项目上用的话，都是自己写代码的，很少会用录制-回放的方法。建议楼主学习下IBM ITCL框架和3种测试框架：模型驱动，数据驱动和关键字驱动。

3. “各位开发人员对控件的属性做的一点也不规范，参差不齐，不是缺了胳膊就少了腿。命名也极不规范，导致在动态查找时困难重重”

其实这不是RFT的错，这是开发人员或者项目规范的问题，你应该question它们。

lovecy

楼上的哥啊~~~感谢你的提纲挈领啊。不过怎么感觉你是在咬文嚼字呢？呵呵...
回应一下你的几个问题：
(1)、我说“自动化永远不可能代替手工测试”，是解释我以前对自动化测试的一个误解，高估了自动化测试的能力。并不是说自动化和手工测试谁是谁非的问题。
(2)、先说RFT的原理是针对初学者的，后面我也说出了有更好的办法——动态查找。（见1楼“于是，这里有一个比较好用的功能，find()方法.....”）
(3)、我说找控件难找并没有责怪RFT工具的意思，这句话明显是在说开发人员做的不规范啊~~
哥哥啊，别打击我的信心行不？写点文章不容易啊，哈哈哈。尤其是使用RFT工具人，更是比较少啊，大家要互相鼓励，欢迎讨论技术，分享技术。

garyliu

To lovecy
我没有打击你的意思啊，真的
我从你的文章中摘录了一些话语，是想和大家分享一下我的某些看法，怕大家误读了RFT，不是针对你哦。
另外，我也给出了一些学习建议阿

当然，我不是说我有多厉害，我只是把我所了解的、知道的拿出来和大家讨论，这也符合你这篇文章的一个目的阿，相信大家讨论的越激烈，就越能得出真知灼见阿，这样我们大家就能共同进步了阿。。。

爱喝可乐的猫

嗯，现在感觉挺迷茫的，黑盒测试接触后，就知道需要的东西其实很少，也想真正见识一下厉害人物的自动化测试，感觉自动化测试离我好远，不知道下一步该怎么选择了，怎么进步了！

zm1015

其实自动化测试没有大家想的那么难，但是入门和高效之间的提高是关键也是难点。编程能力不是最主要的，但是确实是必不可少的 。我只是入门级别的。一起努力吧。

lovecy

原帖由 zm1015 于 2009-12-3 15:02 发表
其实自动化测试没有大家想的那么难，但是入门和高效之间的提高是关键也是难点。编程能力不是最主要的，但是确实是必不可少的 。我只是入门级别的。一起努力吧。

呵呵，我倒是觉得如果真的只使用RFT录制的脚本来测试的话，那是非常糟糕的，既没有处理逻辑，也不能随意替换参数，受限很大，我现在做自动化就主要是自己编写逻辑了，用RFT工具有点变成拿它来识别控件了。

lovecy

原帖由 爱喝可乐的猫 于 2009-12-2 10:39 发表
嗯，现在感觉挺迷茫的，黑盒测试接触后，就知道需要的东西其实很少，也想真正见识一下厉害人物的自动化测试，感觉自动化测试离我好远，不知道下一步该怎么选择了，怎么进步了！

建议是学习一些java语法语句，控制语句，能够实现简单编程

mentgmery

恩,值得研究

shanxi

原帖由 garyliu 于 2009-11-6 16:57 发表
其实，真正在项目上用的话，都是自己写代码的，很少会用录制-回放的方法。 ...

你说错了
大规模使用肯定仍然是录制回放，它的效率明显高于写code。

lovecy

要考虑重用性及测试逻辑问题的话，编程是少不了的。

我的自动化测试脚本中100%是用程序编写的
我使用RFT工具来仅仅是为了识别这个控件的属性
获取这个属性后，我用动态查找来找控件
没有保留一句录制的语句，在helper中也没有保留任何录制时写入的代码
难道是我走的路线错了？

shanxi

你没走错 你还没碰到大的自动化项目

当个人英雄主义 同 team的工作效率项冲突时，理所当然 应该选择team这边。

如果你的team就1～2个人做自动化，请忽略我说过的话，不适用你的场景。

[ 本帖最后由 shanxi 于 2009-12-14 13:02 编辑 ]

lovecy

呵呵，就我一个人在整自动化~~~现在已经整完了。。。
做完这个自动化，貌似有很多话想说，又不知道该如何说起。
貌似使用录制的脚本，回放时总是会有这样那样的问题~

dennyqiang

原帖由 shanxi 于 2009-12-8 16:26 发表


你说错了
大规模使用肯定仍然是录制回放，它的效率明显高于写code。

如果使用录制回放只是为了效率，这个目的未免有些单纯。我个人更趋向于使用find进行二次封装，开发适合自己公司使用的框架，并使用Try...Catch对过程中的异常进行捕获，使用If...Else对期望结果进行检查，基本上通过一系列改造，除了find以外，我们完全可以抛弃RFT的如helper, vp, data driven等特性。

有的人提出find效率太差，尽量使用录制的方式，将录制的对象进行改造，实现框架，我个人是反对这个观点的。
作为一个自动化测试程序，程序本身的运行效率问题不应该是我们设计框架时主要考虑的因素，比如程序运行1个小时和运行1个半小时对被测对象本身和我们的时间方面没有任何影响。而更多的应该考虑规范，开发测试代码的高效性和不同版本之间的维护成本。

再说了，目前还没有谁来证明find一定比录制的效率低，都是凭感觉，在这种情况下讨论find和录制没有多大意义。

shanxi

原帖由 dennyqiang 于 2009-12-24 16:32 发表


如果使用录制回放只是为了效率，这个目的未免有些单纯。我个人更趋向于使用find进行二次封装，开发适合自己公司使用的框架，并使用Try...Catch对过程中的异常进行捕获，使用If...Else对期望结果进行检查，基本上 ...

看来你也很偏激  测试自动化录制不就是为了降低成本 提高工作效率嘛 如果你手工做过一次的操作都能通过录制生成相应的脚本 你为何还固执地认为必须手工来做呢？

什么find，如果RFT这个工具连这个功能都封装的不好，那肯定就得用自己的录制工具
你有没有想过,IBM的测试工具没有HP的测试工具占有率高，是不是就是因为IBM的人都像你这样想的 手工写效率更高 类似这样的脑残决策使得测试成本因为录制工具的易用性差等急剧扩张呢？

我说的是基于项目经验来的，如果你的项目没有达到这个程度，请不要就此作出评论。

[ 本帖最后由 shanxi 于 2009-12-25 15:10 编辑 ]

C.K

我个人认为 什么时候用find（）为核心二次封装方法，什么时候用简单录制-回放功能，什么时候用IBM框架，这是要看具体项目的；
如：1）find方法：如果项目过程中，打版本比较多，对象选项比较多，对象数目变化比较频繁，界面不太复杂，这时候用find方法就非常好，可以 很好规避对象位置数量变化带来的对象识别问题。而且代码的重用和维护非常方便，基本上一个模块的代码可以多个界面重用。有时候会遇到上百个选项的问题，如果每个选项都录制的话，工作量是非常大的。
   2）录制-回放方法：如果项目界面结构比较稳定，对象选项不多且变化不大，界面较复杂，和后台交互比较多，这时侯find方法会效率上会比较差，采用录制回放加对象识别的方法就可以了。
   3）IBM框架：如果每个界面的对象出现率比较高，界面比较类似，但流程比较复杂，采用IBM框架可以更合适点，这样流程控制比较容易，代码重用和维护都比较好。
最后，并不是每个项目都采用固定方法或框架，如果项目中某些模块比较稳定，某些模块变化比较频繁，就可以采用
方法1和方法2结合，这样效率更高。
真是本人总结的一些想法和经验，大家有不同想法可以多加讨论，相互提高。

shanxi

实际上一个项目如果确定了要完全用录制回放来完成 就必须紧密配合该录制回放工具的开发人员或者部门去实现 录制回放不能实现的种种问题，比如准确性、性能、易用性等等各个方面。

无论是IBM的RFT 还是HP的QTP都存在一个很严重的问题：作为一个通用工具，它无法对一个特定项目进行优化。我想，即便你在IBM或者HP工作，你也不可能就你的项目要求对工具的开发人员提出意见，让他们尽快修改工具以满足录制回放的需要。

对有条件联系开发人员的情况是如此，更何况众多不能有这个通道的正版使用方！所以，对大部分使用者来说，顺应工具的架构，研究出各种方法适应工具的使用成为了大家日以继夜研究的“经验”。对商用工具的修改，在不遵守许可协议的条件下，对其进行反汇编以改进其录制回放的功能，是在是一个得不偿失的手段！

从效率上来讲，录制回放工具毋庸置疑。但录制回放功能自身的发展不能及时跟上测试需求的变化，我想这才是问题的核心。对于使用自有开发的录制回放工具或者开源框架的人来说，这些就不是问题了。

不会再在这个thread里面回复了，这种老问题，没什么参与的积极性了。

dennyqiang

shanxi说话总是牛*B哄*哄的，和脑残的人讨论自动化，多损您的形象啊。

lovecy

请两位高手理性对待辩论！
自动化框架这种东西没有谁好谁坏，A用A方法可能用的很爽，B用B方法可能用的很爽，两个人没有必要调换着用。
多学一种方法总是好的，我还是个新手，对框架方面还不清楚，或许还没用到过，或许已经用在具体的实践中了，只要自己觉得做法是可行的，那就OK了。能够在实践中不断的改善过程，那就是提高了。