敏捷自動化測試(8)

　　1、無需編寫任何斷言語句;

　　2、需要能夠提供可用于自動對比的歷史正確版本，特別適用于可以持續構建的項目;

　　3、能判斷出UI樣式和UI邏輯類的錯誤;

　　4、由于對比絕對精準，導致可能存在誤判，因此需要人工對差異圖片進行排查; 【注】由于很多Web頁面都有漸入漸出、點擊時按鈕變色等很炫的效果，所以在兩次截圖的瞬間可能頁面的動態樣式是不一樣的，這就是所謂的“誤判”。筆者對于一個“動態樣式”適中的項目采用這種斷言方式，統計結果表明誤判率在20%左右。

　　5、鑒于回歸測試的時候，通常大部分用例應該是可以通過的，所以“頁面級粗粒度斷言”的投入產出比非常占優勢!

　　三、 基于業務邏輯斷言

　　在測試設計時把有依賴關系的用例一起執行，如果某個步驟出現問題，即便不設置任何斷言語句，在當前步驟或后續步驟的測試用例也會執行失敗。下面以“增加、查詢、修改、刪除”這個最典型的流程來說明(如下圖所示)。

　　假定在“增加”環節出現問題，那么我們的測試用例執行情況可能出現如下幾種結果：

　　1、如果在“增加記錄A”的用例中包含對是否增加成功的斷言，那么測試用例從“增加記錄A”開始出錯;

　　2、如果在“增加記錄A”中不包含斷言，而是在“查詢A”的用例中包含是否有查詢結果的斷言，那么測試用例會從“查詢A”開始出錯;

　　3、如果在“查詢A”中也不包含斷言，那么測試用例會從“修改查詢結果”開始出錯。

　　所謂“基于業務邏輯斷言”，就是指上述第三種情況，其特點及應用場景如下：

　　1、無需編寫任何斷言語句，但測試設計要考慮業務邏輯順序;

　　2、與“頁面級粗粒度斷言”相比，不需要提供可用于對比的歷史正確版本，通常適用于項目剛開發或樣式做整體調整等情況;

　　3、斷言錯誤的位置不精準，可能延后;

　　4、執行過程每一步都做截圖備份(通過Selenium WebDriver可以很方便的實現)，可以非常有效的輔助定位準確的出錯原因;

　　5、鑒于回歸測試的時候，通常大部分用例應該是可以通過的，所以“基于業務邏輯斷言”的投入產出比非常占優勢!

　　四、 自定義擴展斷言

　　在人工測試時經常有些操作結果的正確與否在當前頁面無法做出判斷，需要到其它頁面甚至系統外部(比如，數據庫、輸出日志)獲取信息來做出判斷。以最常見的“基于數據庫進行斷言”為例，測試工具需要支持把斷言時用到“預期結果”和“實際結果”配置為對應的SQL語句。

　　以上介紹了從測試工具的角度可以提供的多種斷言機制，在自動化測試過程中應該根據項目實際情況，考慮采用上述多種斷言的組合，以彌補控件級細粒度斷言的不足。

　　本系列文章至此，已經分享了如何降低測試腳本的編寫、維護成本，如何在不失測試有效性的前提下減少斷言成本。改善上述兩大問題之后，自動化測試基本上就可以比較順利的開展了。接下來如何讓自動化測試的價值最大化呢?答案就是頻繁的執行測試腳本。因此下一步要做的就是持續集成(或者稱為每日構建)。下一篇文章會分享一個由測試團隊主導的持續集成案例，敬請關注!

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