目前，自動化測試框架已經基本成型。朋友們的一些建議，還在陸續消化中，在不久的將來或許都會加入到其中，謝謝大家的鼓勵和支援。
最近，在一次技術交流會中，我的一位同事向我提起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，確實有難度啊。控制項的呼叫必須做到自動識別了。可見，dsl的實現還是比較有挑戰的。而且這裡面也存在乙個疑問，dsl適合測試嗎？或者說我說的dsl原本是設計給需求人員或者程式設計師的，而不是特別給測試的。真正在自動化測試中的dsl，應該使用一種全新的方式去定義dsl。比如乙個簡單的input對話方塊，只有乙個value的edit控制項。那麼對於dsl描述，我希望是這樣的：在沒彈出對話方塊之前，就應該是：設定 屬性 新值。對於對話方塊的彈出是在dsl中不可預計的
不管怎麼說，實現的方案已經基本成熟了。我們也可以展望一下如果實現了ruby的指令碼支援，會帶來什麼。
對於ruby，我計畫是作為乙個測試步驟（teststep）加入到原有指令碼中。這樣既不會丟掉原有指令碼編輯的優勢，又同時擁有了強大擴充套件能力。
如果dsl實現了，那麼程式設計就會變得更加簡單。按照小賈的意思，使用者可能會放棄我原來的指令碼編輯器。不過我不同意:)
ruby指令碼的易用性，是經過眾多網友驗證的。而我們就會同時擁有這方面的優勢。其學習成本也是很低的。世界上有乙個強大的社群在支援著它。而且現在眾多廠商也開始退出ruby的編輯器，比如borland最近推出的3rdrail™。這樣我們編寫ruby的指令碼，就不需要我們自己造乙個輪子了。
anyway，擁抱ruby的這個選擇，也許會讓我們這個系統走向世界也說不定。
自動化測試框架 擁抱Ruby
目前，自動化測試框架已經基本成型。朋友們的一些建議，還在陸續消化中，在不久的將來或許都會加入到其中，謝謝大家的鼓勵和支援。最近，在一次技術交流會中，我的一位同事向我提起qtp quicktest pro 肯定了它的描述性程式設計和我們框架中的設計有類似之處，並指出qtp的可擴充套件性比較強，比如流程...
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...