自動化測試框架: 用原型編寫用例？

最近在考慮自動化測試框架的時候，發現原來的想法，雖然解決了定位及訪問控件的困難。但是，用例代碼卻因此對程序實現細節有了很強的依賴。這些依賴可能對用例代碼的開發帶來一些困惑。
        在思考解決這個問題的時候，自然的方案，就是提供統一地訪問控件的方式，而不是原來那種直接生成對象的方式(參考自動化測試框架：測試編程框架)。這種訪問控件的方式，就好比訪問網頁一樣，輸入一個URL，就可以得到想要的控件。以此為基礎，編程過程中的代碼中雖然增加了對URL的輸入，但是卻因此去除了用例代碼對軟件實現的具體依賴。以后就算實現代碼變了，也基本不影響用例代碼。
        對比一下以往的對控件的定位方式，往往通過控件的隱含屬性：包括Text、ClassName,Index,ID等等。但獲取這些屬性的前提是使用工具去查看！這種方式的一個顯然的缺點是，這樣的代碼，可讀性是比較差的，而且和控件的綁定將變得更加緊密！
        分析了這些情況，選定了方案。那么，問題就剩下如何描述控件。
        描述的首先是元素選擇。在選擇的過程中，我將可選擇的元素約束在那些可以從界面上觀察到的屬性。經過分析，得到下面這些元素的列表：
1.控件本身的標題性文本。一些不含標題性文本的控件，可以通過提取一些內容信息，作為標志。
2.控件之間的相對位置。左右上下、父子關系。針對某些控件，特別是常用的文本編輯框、網格控件、ListView、TreeView等等都是沒有標題的。所以定位這些控件才是描述中最難把握的地方。在這個問題上，重點考慮的是利用那些可以描述的控件，加上位置的判斷，共同定位這些控件。
3.控件標準類型（非ClassName）。我們可以給各種控件進行歸類，這樣，在編寫腳本的時候，根據這些類型去定位控件，就比較容易了。特別是那種同類型只有一個的控件，就可以直接用類型定位了。
4.控件顯示順序（從左到右，從上到下）
        基于這些描述元素，基本上我們可以完成對所有控件的描述。
        回過頭來想一下，如果實現了這點（假定可以實現），那么我們會發現，我們其實可以針對軟件的原型進行編寫測試用例。這是可以理解的，因為原型和軟件，相同功能的控件都是同一類型的，這對我們用例的編寫，無疑提供了統一的平臺！只要利用好這個平臺，工作效果不可限量啊。
        只不過這時候的校驗代碼都是失敗的，但這不是正符合了測試驅動開發的精神了嘛？但不可否認，這是一個非常棒的想法！
        最后，有關自動化測試方面的思考，是一個慢慢細化的過程。在這方面的探索，我們還會繼續下去！

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