敏捷自動化測試（3）——讓斷言再也不成爲自動化測試的負擔

    做者: 殷坤  來源: InfoQ

　　在本系列的第一篇文章「咱們的測試爲何不夠敏捷」中，根據實例總結出敏捷自動化測試的兩大阻礙：「腳本維護困難」、「斷言條件繁瑣」。本文針對在不失自動化測試有效性的前提下如何下降斷言成原本分享一些實踐經驗。

　　目前業界常見的自動化測試工具在斷言方面大多都是採用「指哪兒打哪兒」的細粒度模式，即，在自動化測試過程當中只能對設置爲斷言條件的字段（頁面元素）進行斷言。並且這些測試工具即便提供錄製腳本的功能，但對於斷言每每還須要測試人員手工補充插入。

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

• 沒法感知未設爲斷言對象的字段上發生的錯誤

  以上圖爲例，若是在「增長用戶」的測試腳本以後只對列表中的「用戶姓名是否存在」 進行斷言，那麼就可能遺漏「入職日期沒有提交成功」的錯誤。並且因爲頁面的信息量每每很大，咱們是不可能對全部字段都設置爲斷言條件的。

• 難以對於UI樣式或UI邏輯進行斷言

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

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

　　固然，全部人都應該是很是期待看到這樣的結果，畢竟誰也不但願每次迴歸測試時都是用例大面積不經過。只是辛辛苦苦寫這些斷言語句的測試人員內心未免有些「小遺憾」。

　　本系列上篇文章中談到「不少人一提到自動化測試腳本，立刻就想到須要提供錄製工具」，但若是換個角度思考，極可能就是「柳暗花明又一村」。

　　在這裏，咱們一樣換個角度思考，假設咱們的自動化測試主要目標是爲了證實軟件運行正常，那麼咱們會怎麼作？

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

1. 新租戶註冊；
2. 管理員登陸系統，對註冊租戶進行審批，而後退出系統；
3. 審批後的租戶登陸系統；
4. 租戶申請所須要的虛擬化資源（好比，40G硬盤、2核CPU、2G內存），而後退出系統；
5. 管理員登陸系統，對租戶申請的資源進行審批，而後退出系統；
6. 租戶登陸系統，在已申請資源的基礎上建立安裝指定操做系統的虛擬機；
7. 斷言虛擬機是否建立成功；
8. 租戶退出系統；
9. 管理員登陸系統，刪除租戶；
10. 斷言租戶以前申請的資源是否被徹底釋放；
11. 租戶再次登陸系統，斷言是否沒法登陸；

　　上述測試用例就是按照完整的業務流程進行組織，而且只對少許關鍵點（七、十、11）進行斷言，若是整個用例能夠運行經過，就能證實這個業務是沒有問題的。

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

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

　　1、 控件級細粒度斷言

　　即前面提到的最多見的斷言方式。在測試過程當中，能夠在任何位置增長斷言腳本，來判斷頁面指定控件是否存在、控件顯示值是否爲預期結果等。一般建議只對關鍵校驗點進行斷言。

　　2、 頁面級粗粒度斷言

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

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

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

　　經過頁面數據進行斷言的實現方式相對簡單一些，首先要提取頁面上全部的數據（或文本），接着進行格式化，而後再自動化對比。 「頁面級粗粒度斷言」的特色及應用場景以下：

• 無需編寫任何斷言語句；
• 須要可以提供可用於自動對比的歷史正確版本，特別適用於能夠持續構建的項目；
• 能判斷出UI樣式和UI邏輯類的錯誤；
• 因爲對比絕對精準，致使可能存在誤判，所以須要人工對差別圖片進行排查； 【注】因爲不少Web頁面都有漸入漸出、點擊時按鈕變色等很炫的效果，因此在兩次截圖的瞬間可能頁面的動態樣式是不同的，這就是所謂的「誤判」。筆者對 於一個「動態樣式」適中的項目採用這種斷言方式，統計結果代表誤判率在20%左右。
• 鑑於迴歸測試的時候，一般大部分用例應該是能夠經過的，因此「頁面級粗粒度斷言」的投入產出比很是佔優點！

　　3、 基於業務邏輯斷言

　　在測試設計時把有依賴關係的用例一塊兒執行，若是某個步驟出現問題，即使不設置任何斷言語句，在當前步驟或後續步驟的測試用例也會執行失敗。下面以「增長、查詢、修改、刪除」這個最典型的流程來講明（以下圖所示）。

　　假定在「增長」環節出現問題，那麼咱們的測試用例執行狀況可能出現以下幾種結果：

1. 若是在「增長記錄A」的用例中包含對是否增長成功的斷言，那麼測試用例從「增長記錄A」開始出錯；
2. 若是在「增長記錄A」中不包含斷言，而是在「查詢A」的用例中包含是否有查詢結果的斷言，那麼測試用例會從「查詢A」開始出錯；
3. 若是在「查詢A」中也不包含斷言，那麼測試用例會從「修改查詢結果」開始出錯。

　　所謂「基於業務邏輯斷言」，就是指上述第三種狀況，其特色及應用場景以下：

• 無需編寫任何斷言語句，但測試設計要考慮業務邏輯順序；
• 與「頁面級粗粒度斷言」相比，不須要提供可用於對比的歷史正確版本，一般適用於項目剛開發或樣式作總體調整等狀況；
• 斷言錯誤的位置不精準，可能延後；
• 執行過程每一步都作截圖備份（經過Selenium WebDriver能夠很方便的實現），能夠很是有效的輔助定位準確的出錯緣由；
• 鑑於迴歸測試的時候，一般大部分用例應該是能夠經過的，因此「基於業務邏輯斷言」的投入產出比很是佔優點！

　　4、 自定義擴展斷言

　　在人工測試時常常有些操做結果的正確與否在當前頁面沒法作出判斷，須要到其它頁面甚至系統外部（好比，數據庫、輸出日誌）獲取信息來作出判斷。以最多見的「基於數據庫進行斷言」爲例，測試工具須要支持把斷言時用到「預期結果」和「實際結果」配置爲對應的SQL語句。

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

　　本系列文章至此，已經分享瞭如何下降測試腳本的編寫、維護成本，如何在不失測試有效性的前提下減小斷言成本。改善上述兩大問題以後，自動化測試 基本上就能夠比較順利的開展了。接下來如何讓自動化測試的價值最大化呢？答案就是頻繁的執行測試腳本。所以下一步要作的就是持續集成（或者稱爲每日構 建）。