Ruby+Watir测试自动化的新选择

 在半年前，我想很多人，包括我自己，都不知道watir是个什么东东。在国内几乎没有介绍的文章，尝鲜者聊聊。但半年后，随着用Ruby+Watir开发了一个具有较大规模的自动化测试框架，再回头看来，我个人认为，用RAW是做web自动化测试的第一选择。事实上，现在网上关于Watir的介绍和经验也多了起来。

   在用Watir之前，对于自动化测试工具，我只有一些使用Rational Robot的经验。Robot对于我来说最大的问题是，从一个C/C++/java程序员看来，它的scrīpt语言实在太不敢恭维了。包括语法'丑陋'，提供的外部库功能匮乏(net, file, remote control, database ....)，还有编辑器也非常简陋。总的来说，我在写robot scrīpt的时候，我都在怀念在eclipse里使用java无所不能的感觉。

   Robot并不全是坏的印象。它最cool的地方就是Record&Replay。但是，如果是对某个不断进化的产品进行测试，而且这个产品还不是那么简单。那么直接RecordReplay是远远不够的。套用一句不知道是哪个专家说的“自动化测试程序也是程序”，也需要设计，也需要架构，也需要设计模式。

   其他商业的自动化测试工具我还简单体验过Silktest，也是我所在公司曾经采用的。但它的scrīpt语言更不讨人喜欢，而且据使用它的同事说稳定性存在问题。更好的工具比如Mercury的QTP，我没有使用过。

   现在看来Ruby+Watir确实是一个正确的选择，但半年前这并不是显而易见的。公司原来的测试工具是silktest，并在上面开发了一定量的testcases。不过由于人力不够和lisense的问题，这个测试套件已经有很长一段时间停步不前了，并没有随着产品的更新而更新。silktest形如鸡肋，Robot，QTP...价格又高不可攀，而对于一个做产品的公司来说，自动化测试似乎是不可避免的，所以公司招聘了一个自动化测试Consultant，希望她能带来价廉物美的利器。而这个consultant此前就在用Ruby+Watir做项目。

   Consultant带来了Ruby+Watir，并计划做一个SmokeTest suite，集成进Nightly build。她希望能在QA组里找一个助手，因为我以前就做了一些自动互测试的工具并在team里使用，所以我也参加了进来。当然这个时候，我对Watir一无所知，而Ruby，虽然曾经进入了我的视野，但在一年前，我选择了Python作为我的第一脚本语言。

   2个人的Team建立了。计划是consultant着手搭建框架，我先学习Ruby和Watir。随后的一个月，我不得不放下放下ruby，而参加更紧迫的产品releas测试。当然我还是抽空翻看了ProgramingRuby 2Ed一书，写了一些程序来热身一下，虽然是蜻蜓点水，但也被ruby的优美和强大折服。当consultant再次来到中国，我对她准备如何实现这个框架还是一无所知。我也不知道我得职责到底是什么。

   当我提出我得问题后，consultant给我看了她已经完成的一些东西，我看了感觉比较失望。因为从她的代码看，她并不想提供一个框架，只是针对smoketest提供一些例程。对这些例程配合不同的输入数据，构成smoketest的全部。而我此时已经雄心勃勃，希望看到的是一个精心设计的面向对象框架，对QA所面对的产品的功能有一个比较完备的抽象层，－它不仅仅是为了Smoketest

   这个框架要实现的目标就是，在它基础上应该能够把大部分(>80%)的Manual test比较轻松的翻译为自动化脚步。对每一个step都能直接而且方便的翻译为一句ruby 语句。也就是说需要达到一种效果：读自动化脚本就像在读用人类语言描述的testcase。自动化脚本完全是在描述测试逻辑，这真是一个够“理想化”的目标！


   我提出了我的想法，发给她一份我对整个框架设计的构思。她显然并不愿意大动干戈。我于是试图说服我们这边的QA Manager趁此机会做一个全功能的测试框架，并获得了成功。consultant只能作出让步，但要求不能miss smoketest的目标。当然我同意了。

   接下来的一个月consultant休假，她给我了一份list，罗列了要达到的目标，然后就闪人了。我则全心投入了实现这个框架的工作。


   经过几个月的开发，重要的是在给同事们使用后并得到了好多反馈。最后我觉得是初步达到了目标。随后，我会谢谢在这个过程中遇到的问题，解决的方法和得到的经验。

原文转自：http://www.ltesting.net