敏捷自動化測試(3)——讓斷言不再成為自動化測試的負擔

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

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

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

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

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

　　相關廠商內容

　　一路走來技術人的創業故事

　　未來物聯網中智能硬件的角色

　　人工智能的技術版圖

　　GMTC全球移動技術大會，6折優惠，最后一周!

　　不要寫死!天貓App的動態化配置中心實踐

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

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

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

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

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

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

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

　　新租戶注冊;

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

　　審批后的租戶登錄系統;

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

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

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

　　斷言虛擬機是否創建成功;

　　租戶退出系統;

　　管理員登錄系統，刪除租戶;

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

　　租戶再次登錄系統，斷言是否無法登錄;

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

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

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

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