一、 控件級細粒度斷言
即前面提到的最常見的斷言方式。在測試過程中,可以在任何位置增加斷言腳本,來判斷頁面指定控件是否存在、控件顯示值是否為預期結果等。通常建議只對關鍵校驗點進行斷言。
二、 頁面級粗粒度斷言
通過對比前(之前測試通過)后(后續持續發布)版本在測試用例路徑和輸入參數相同的情 況下,整個頁面內容(包括截圖和數據)是否嚴格相同來做粗粒度斷言。
通過頁面截圖進行斷言有兩個實現要點:首先要選擇一個合適的截圖方案(筆者推薦采用Selenium WebDriver提供的TakesScreenshot接口);其次需要提供圖片對比工具,以便測試人員可以一眼看出兩個版本頁面截圖的差異。
下面是筆者在測試框架中實現的截圖自動化對比功能的實際效果。下圖中左側部分是“實際結果截圖”、右側是“預期結果截圖”、中間部分是差異對比,測試人員一眼便可看出其中的Bug:“表格行選中的翻頁緩存(在當前頁選中幾條記錄,翻到下一頁再翻回本頁,需要保持之前的行選中狀態)功能丟失了”。
通過頁面數據進行斷言的實現方式相對簡單一些,首先要提取頁面上所有的數據(或文本),接著進行格式化,然后再自動化對比。 “頁面級粗粒度斷言”的特點及應用場景如下:
無需編寫任何斷言語句;
需要能夠提供可用于自動對比的歷史正確版本,特別適用于可以持續構建的項目;
能判斷出UI樣式和UI邏輯類的錯誤;
由于對比絕對精準,導致可能存在誤判,因此需要人工對差異圖片進行排查; 【注】由于很多Web頁面都有漸入漸出、點擊時按鈕變色等很炫的效果,所以在兩次截圖的瞬間可能頁面的動態樣式是不一樣的,這就是所謂的“誤判”。筆者對于一個“動態樣式”適中的項目采用這種斷言方式,統計結果表明誤判率在20%左右。
鑒于回歸測試的時候,通常大部分用例應該是可以通過的,所以“頁面級粗粒度斷言”的投入產出比非常占優勢!
三、 基于業務邏輯斷言
在測試設計時把有依賴關系的用例一起執行,如果某個步驟出現問題,即便不設置任何斷言語句,在當前步驟或后續步驟的測試用例也會執行失敗。下面以“增加、查詢、修改、刪除”這個最典型的流程來說明(如下圖所示)。
假定在“增加”環節出現問題,那么我們的測試用例執行情況可能出現如下幾種結果:
如果在“增加記錄A”的用例中包含對是否增加成功的斷言,那么測試用例從“增加記錄A”開始出錯;
如果在“增加記錄A”中不包含斷言,而是在“查詢A”的用例中包含是否有查詢結果的斷言,那么測試用例會從“查詢A”開始出錯;
如果在“查詢A”中也不包含斷言,那么測試用例會從“修改查詢結果”開始出錯。
所謂“基于業務邏輯斷言”,就是指上述第三種情況,其特點及應用場景如下:
無需編寫任何斷言語句,但測試設計要考慮業務邏輯順序;
與“頁面級粗粒度斷言”相比,不需要提供可用于對比的歷史正確版本,通常適用于項目剛開發或樣式做整體調整等情況;
斷言錯誤的位置不精準,可能延后;
執行過程每一步都做截圖備份(通過Selenium WebDriver可以很方便的實現),可以非常有效的輔助定位準確的出錯原因;
鑒于回歸測試的時候,通常大部分用例應該是可以通過的,所以“基于業務邏輯斷言”的投入產出比非常占優勢!
四、 自定義擴展斷言
在人工測試時經常有些操作結果的正確與否在當前頁面無法做出判斷,需要到其它頁面甚至系統外部(比如,數據庫、輸出日志)獲取信息來做出判斷。以最常見的“基于數據庫進行斷言”為例,測試工具需要支持把斷言時用到“預期結果”和“實際結果”配置為對應的SQL語句。
原文轉自:http://www.infoq.com/cn/articles/Agile-test-automation-3