在半年前，我想很多人，包括我自己，都不知道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，羅列了要達到的目標，然后閃人了。我則全心投入了實現這個框架的工作。
經過幾個月的開發，重要的是在給同事們使用后并得到了好多反饋。后我覺得是初步達到了目標。隨后，我會謝謝在這個過程中遇到的問題，解決的方法和得到的經驗。
