qileilove

　　目前業界常見的自動化測試工具在斷言方面大多都是采用“指哪兒打哪兒”的細粒度模式，即，在自動化測試過程中只能對設置為斷言條件的字段（頁面元素）進行斷言。而且這些測試工具即使提供錄制腳本的功能，但對于斷言往往還需要測試人員手工補充插入。

　　除了補充、維護斷言條件的工作量大之外，這種斷言模式還存在一些明顯的不足，下面結合一個實際的例子（如下圖）進行分析：

　　● 無法感知未設為斷言對象的字段上發生的錯誤

　　以上圖為例，如果在“增加用戶”的測試腳本之后只對列表中的“用戶姓名是否存在” 進行斷言，那么就可能遺漏“入職日期沒有提交成功”的錯誤。而且由于頁面的信息量往往很大，我們是不可能對所有字段都設置為斷言條件的。

　　● 難以對于UI樣式或UI邏輯進行斷言

　 　以上圖為例，有一個UI樣式類的缺陷（左側菜單樹的根節點“console”下面多出來一條虛 線）和一個UI邏輯類的缺陷（右側用戶列表只有一頁，但“下一頁”和“最后一頁”圖標依然是可以點擊的，即沒有灰顯）。此類缺陷即使對于經驗豐富、心思縝 密的測試人員，在人工測試時也是很可能發現不了的，并且在自動化測試過程中也很難進行斷言。

　　即使存在上述問題，測試腳本中是否有充分的斷言，依然是評判自動化測試有效性的一個重要指標。但實施過自動化測試的人應該都會有這樣的體會：“大部分斷言在大部分情況下只是佐證軟件是運行正常的”。

　　當然，所有人都應該是非常期待看到這樣的結果，畢竟誰也不希望每次回歸測試時都是用例大面積不通過。只是辛辛苦苦寫這些斷言語句的測試人員心里未免有些“小遺憾”。

　　本系列上篇文章中談到“很多人一提到自動化測試腳本，馬上就想到需要提供錄制工具”，但如果換個角度思考，很可能就是“柳暗花明又一村”。

　　在這里，我們同樣換個角度思考，假設我們的自動化測試主要目標是為了證明軟件運行正常，那么我們會怎么做？

　　筆者這邊的一個經驗就是“按照完整的業務流程來組織測試用例，只對少量、必要的關鍵點進行斷言”。以“租戶對虛擬化資源的申請使用”為例，來具體看看測試用例的組織方式：

　　1、新租戶注冊；

　　2、管理員登錄系統，對注冊租戶進行審批，然后退出系統；

　　3、審批后的租戶登錄系統；

　　4、租戶申請所需要的虛擬化資源（比如，40G硬盤、2核CPU、2G內存），然后退出系統；

　　5、管理員登錄系統，對租戶申請的資源進行審批，然后退出系統；

　　6、租戶登錄系統，在已申請資源的基礎上創建安裝指定操作系統的虛擬機；

　　7、斷言虛擬機是否創建成功；

　　8、租戶退出系統；

　　9、管理員登錄系統，刪除租戶；

　　10、斷言租戶之前申請的資源是否被完全釋放；

　　11、租戶再次登錄系統，斷言是否無法登錄；

　　上述測試用例就是按照完整的業務流程進行組織，并且只對少量關鍵點（7、10、11）進行斷言，如果整個用例可以運行通過，就能證明這個業務是沒有問題的。

　　另外還有一個值得考慮的現象，就是相對于自動化測試而言，一個優秀的測試人員在人工測試時是如何判斷功能正確與否的呢？他不會死板的只盯著某幾 個輸入域的值，他一定還會同時關注頁面上所有數據的正確性、會更加關注業務流程是否正確、會更敏銳的發現頁面樣式或UI邏輯類的缺陷。

　　為了兼顧“證明軟件正常運行”和“人性化的識別軟件缺陷”，一個優秀的測試工具應該考慮提供以下多種斷言機制。

　　一、控件級細粒度斷言即前面提到的最常見的斷言方式。在測試過程中，可以在任何位置增加斷言腳本，來判斷頁面指定控件是否存在、控件顯示值是否為預期結果等。通常建議只對關鍵校驗點進行斷言。

　　二、頁面級粗粒度斷言通過對比前（之前測試通過）后（后續持續發布）版本在測試用例路徑和輸入參數相同的情 況下，整個頁面內容（包括截圖和數據）是否嚴格相同來做粗粒度斷言。

　　通過頁面截圖進行斷言有兩個實現要點：首先要選擇一個合適的截圖方案（筆者推薦采用Selenium WebDriver提供的TakesScreenshot接口）；其次需要提供圖片對比工具，以便測試人員可以一眼看出兩個版本頁面截圖的差異。

　　下面是筆者在測試框架中實現的截圖自動化對比功能的實際效果。下圖中左側部分是“實際結果截圖”、右側是“預期結果截圖”、中間部分是差異對 比，測試人員一眼便可看出其中的Bug：“表格行選中的翻頁緩存（在當前頁選中幾條記錄，翻到下一頁再翻回本頁，需要保持之前的行選中狀態）功能丟失 了”。

　　通過頁面數據進行斷言的實現方式相對簡單一些，首先要提取頁面上所有的數據（或文本），接著進行格式化，然后再自動化對比。 “頁面級粗粒度斷言”的特點及應用場景如下：

　　● 無需編寫任何斷言語句；

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

　　● 能判斷出UI樣式和UI邏輯類的錯誤；

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

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

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

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

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

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

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

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

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

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

　　● 斷言錯誤的位置不精準，可能延后；

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

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

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

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

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

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

相關鏈接：

我們的測試為什么不夠敏捷

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