自動化測試框架：測試編程框架

做任何事，要牢記你的用戶是誰！設計一個框架，要知道你的用戶的使用需求是什么，這樣，框架設計才可能容易被接受，離成功也就越進一步了。

框架的用戶是測試人員。測試人員的特點是：

熟悉或精通業務 了解程序元素，但不了解程序結構 實現細節更是難以洞察

因此，在設計初期，就考慮將控件的訪問封裝起來。對于測試人員來說，所有的控件都已經封裝好了，他們只需要調用就可以了。

這一點，應該已經初步解決問題了。但是我們并沒有滿足這一點。

對于軟件測試來講，他們了解的是業務元素，而我們常規做法，是把控件封裝成編程元素。這是不一樣的。舉個例子：

我們在界面編程的時候，命名一個按鈕控件，叫btnOk，標題是“確定”。對于程序員來說，btnOk可能是自然的標識名稱，而對于測試來說，“確定”反而是更自然的選擇。

我們考慮，測試最后編程的代碼，應該接近DSL（domain-specific language領域描述語言）?？赡苡羞@樣的幾種方式：

設置文本(標題編輯框, "新的標題") 標題編輯框.設置文本("新的標題")

由于我采用了VCL的控件封裝策略，所以傾向于使用接口的訪問方式（使用.的方式），向測試人員開放接口。在這點上和同事有過爭論。不過后來，對測試人員做過簡單調查，發現第二種方式還是可以接受的。

下面的考慮問題是，這些控件的訪問代碼，怎么讓測試寫了？最直接想到的方法，就是通過遍歷窗體，通過訪問每一個控件，逐個封裝成代碼，這樣測試就不需要關心這段復雜代碼的編寫了。

比如：

TMyFormTestCase=class
private
  FEdit1: IEdit;
public
  property Edit: IEdit read FEdit1;
  procedure DoTestCase; override;
end;

其中DoTestCase是真正完成業務功能的虛擬函數。通過覆蓋，完成實際業務代碼。屬性Edit直接封裝給測試人員調用。但是，注意到業務代碼和我們自動生成的代碼混合在一起，這有兩個壞處：

自動生成的代碼，需要和編寫的代碼進行混合處理。降低了自動化的可能性。 兩者混合，其實是增加了測試學習的成本。相反，如果隔離，可以使得應用變得簡單。

原文轉自：http://www.anti-gravitydesign.com