敏捷自動化測試(5)

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

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

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

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

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

<event id="[button]保存"  name="click"/>

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

　　Button的界面展現如下：

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

<div id="button-1032" class="x-btn x-box-item x-btn-default-small 
        x-noicon x-btn-noicon >
    <em id="button-1032-btnWrap">
        <button id="button-1032-btnEl" class="x-btn-center"
                 autocomplete="off" role="button">
            <span id="button-1032-btnInnerEl">Cancel
            <span id="button-1032-btnIconEl" class="x-btn-icon "/>
        </button>
    </em>
</div>

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

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

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

　　樹節點展開/關閉

<event id="[treeNode]部門" name="open"/>
<event id="[treeNode]部門" name="close"/>

　　Grid翻頁

<event id="[grid]人員列表" name="nextPage"/>

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

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

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

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

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

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

　　1、頁面采用單幀實現

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

　　2、兼容Firefox

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

原文轉自：http://www.uml.org.cn/Test/201307154.asp