目前，自動化測試框架已經基本成型。朋友們的一些建議，還在陸續消化中，在不久的將來或許都會加入到其中，謝謝大家的鼓勵和支持。

最近，在一次技術交流會中，我的一位同事向我提起QTP(QuickTest Pro)，肯定了它的描述性編程和我們框架中的設計有類似之處，并指出QTP的可擴展性比較強，比如流程控制（IF、LOOP、SWITCH等）。特別是裝載數據批量操作軟件方面比較強。我深以為然。

因此，我開始和我的另一位同事小賈琢磨。我們有兩種選擇，一是在腳本編輯中擴展有關流程的節點（這點很像FinalBuilder），還有就是支持腳本語言。我們選擇了后者，因為第一種雖然可以擴展，但最終畢竟還是不靈活。

在對編程語法方面，一開始考慮的是PascalScript，因為我們都是使用的Delphi。但是考慮到測試人員并不是熟悉Delphi的，況且，對于腳本化編程，我最先想到的是Ruby，而不是Delphi。因此我做了一個大膽的假設，如果在我們引擎中，加入對Ruby的支持，應該怎么做呢？

首先是引擎調用Ruby腳本。我查找了一下資料。發現Delphi下有現成的開源控件，而且Ruby其實已經公布了API了。因此這不是問題了。

那么下面就是最重要的問題了，Ruby腳本如何調用引擎去控制控件？我將所有針對引擎的操作，都歸結于控件的操作，這簡化了依賴性。但是關鍵的問題還是在于技術上如何實現調用。

必須承認，我對Ruby的了解很少，這方面小賈是專家。在和小賈討論過程中，發現Delphi寫Ruby的擴展沒有明確的幫助，倒是有C的實現方式。我相信研究一下C的實現方式，應該可以找到Delphi的實現方式。

但在這個時候，我們忽然提到了Http。這讓我想起了引擎中已經存在的一個Http的Server。因此我提出直接通過Http調用引擎。這樣就跨越了語言的障礙。我們顯然是抓住了RPC的精髓。這個方案一下子得到了小賈的支持。

并且我還想到另外一個理由：先實現了再說（Do it First）。這點小賈更是同意。

在這個基礎上，小賈更是提出了利用Ruby定義DSL的方式，來進行編程。對于Ruby定義DSL我也是不怎么了解。在簡單研究過范例之后，發現有一定的可行性，但是難度也確實不小。

下面是我和小賈討論的一些內容，也能初步看出其中的難度。

有關DSL，還真麻煩。我考慮這樣的情況：DSL可以轉換成窗體實現。但是窗體實現并不完全對應DSL描述。事實上，對于客戶的應用來說，一個確定按鈕往往不是他的DSL描述的內容，包括所謂的Edit啊，Grid啊都不是的。這些只是實現某類DSL的方式。從反推的方式來設計DSL，確實有難度啊。控件的調用必須做到自動識別了。

比如一個簡單的Input對話框，只有一個Value的Edit控件。那么對于DSL描述，我希望是這樣的：在沒彈出對話框之前，就應該是：設置 屬性 新值。對于對話框的彈出是在DSL中不可預計的

可見，DSL的實現還是比較有挑戰的。而且這里面也存在一個疑問，DSL適合測試嗎？或者說我說的DSL原本是設計給需求人員或者程序員的，而不是特別給測試的。真正在自動化測試中的DSL，應該使用一種全新的方式去定義DSL。

不管怎么說，實現的方案已經基本成熟了。我們也可以展望一下如果實現了Ruby的腳本支持，會帶來什么。

1. 對于Ruby，我計劃是作為一個測試步驟（TestStep）加入到原有腳本中。這樣既不會丟掉原有腳本編輯的優勢，又同時擁有了強大擴展能力。
2. 如果DSL實現了，那么編程就會變得更加簡單。按照小賈的意思，用戶可能會放棄我原來的腳本編輯器。不過我不同意:)
3. Ruby腳本的易用性，是經過眾多網友驗證的。而我們就會同時擁有這方面的優勢。其學習成本也是很低的。世界上有一個強大的社區在支持著它。而且現在眾多廠商也開始退出Ruby的編輯器，比如Borland最近推出的3rdRail™。這樣我們編寫Ruby的腳本，就不需要我們自己造一個輪子了。

Anyway，擁抱Ruby的這個選擇，也許會讓我們這個系統走向世界也說不定。