自動化測試框架：擁抱Ruby

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

最近，在一次技術交流會中，我的一位同事向我提起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的這個選擇，也許會讓我們這個系統走向世界也說不定。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1813804