敏捷自動化測試(2)——像用戶使用軟件一樣享受自動化測試(2)

　　“賬號”輸入***、“密碼”輸入***、“姓名”輸入***、“性別”選擇***、“生日”輸入***、“國籍”選擇***，點擊“保存”按鈕。

　　這就可以理解為“根據界面編寫的測試腳本”。

　　我們在使用Web應用時，心里常常默念的還包括：“展開/收攏/選中”樹(Tree)的某個節點、數據表格(Grid)的下一頁/上一頁、選中數據表格(Grid)的某一行、點擊/關閉某個Tab頁，等等。

　　很多人在與筆者交流的過程中都會問“為什么還要手工編寫腳本，怎么不提供腳本錄制工具呢?”

　　因此在這里想澄清一下大家對“編寫”腳本的誤解，與傳統自動化測試工具相比，“此腳本”非“彼腳本”。

　　傳統的測試腳本是給特定測試工具執行時使用的，對人類而言可讀性極差，更別談手工編寫了，因此“錄制/回放”工具往往都是必備組件。即便如此，此類“錄制/回放”工具的實際使用效果，也是不盡如人意的。

　　從這種角度來看，“錄制”腳本是“下策”，“上策”應該是讓測試腳本大幅簡化，并且具備良好的可讀性和可維護性，以達到人工編寫很容易的程度。

　　——以上只是筆者的一點差異化見解，對業界優秀的測試工具沒有任何冒犯之意!

　　(二)降低測試腳本對技術實現依賴度的實現思路

　　Web頁面開發中的技術實現細節主要包括UI框架的選擇及版本升級、頁面樣式設計、頁面布局設計，因此我們的主要目標就是降低測試腳本對這些因素的依賴。

　　為了便于測試腳本的解析和組織管理，目前還不能直接寫形如“點擊(保存)按鈕”這樣的純自然語言，但可以設計成接近自然語言的領域專用語言(DSL:Domain Specific Language)，本文采用XML來實現這種DSL。比如：

　　這種超級清晰、簡短的測試腳本與實際海量的頁面源碼之間有一條鴻溝，我們可以通過“封裝”來屏蔽。下面以ExtJS的Button控件為例來示意如何完成這種封裝：

　　Button的界面展現如下：

　　實際生成的頁面源碼DOM結構如下(省略部分非關鍵屬性)：

　　我們封裝所要做的主要工作就是解析出測試腳本中定義的關鍵信息(button、保存、click)，結合對應頁面源碼的DOM結構，翻譯成W3C標準的定位方式(如，XPath)。通過XPath就可以定位到頁面上的任何控件。

　　對于測試腳本()，翻譯后的XPath可以是(//button/span[text()='Cancel'])。

　　同理，其它測試腳本還可以包括：

　　樹節點展開/關閉

　　Grid翻頁

　　它們的封裝實現比Button稍微復雜一些，但原理是一樣的。

　　(三)增強測試腳本瀏覽器兼容性的實現思路

　　這個就比較簡單了，只要選用標準化程度高、廠商支持度高、擴展性強的第三方底層實現即可，筆者推薦采用Selenium WebDriver。

　　通過上面的介紹，有些讀者或許會有個疑問：“如果一個Web應用沒有采用任何UI框架、而且編碼又極為不規范，那么你這種方案豈不就不適用了?”

　　答案是肯定的。但筆者認為此類Web應用如果想要發展下去，其瓶頸還停留在開發環節，對其進行自動化回歸測試的投入產出比不是很大。

　　此外，為了進一步提高Web應用的可測試性，筆者在實際工作中總結了一些前臺頁面開發的最佳實踐，供大家參考：

　　頁面采用單幀實現

　　如果頁面上的frame/iframe嵌套很多的話，控件的定位會比較麻煩，并且影響展現速度。

　　兼容Firefox

　　Firefox有很多強大插件，如Firebug、FirePath，非常有助于在開發、測試過程中的調試問題。

原文轉自：http://www.infoq.com/cn/articles/Agile-test-automation-2