在本系列的第一篇
文章“
我們的測(cè)試為什么不夠敏捷”中，根據(jù)實(shí)例總結(jié)出敏捷
自動(dòng)化測(cè)試的兩大阻礙：“腳本維護(hù)困難”、“斷言條件繁瑣”。本文針對(duì)在不失自動(dòng)化測(cè)試有效性的前提下如何降低斷言成本來(lái)分享一些實(shí)踐經(jīng)驗(yàn)。
目前業(yè)界常見(jiàn)的自動(dòng)化測(cè)試工具在斷言方面大多都是采用“指哪兒打哪兒”的細(xì)粒度模式，即，在自動(dòng)化測(cè)試過(guò)程中只能對(duì)設(shè)置為斷言條件的字段（頁(yè)面元素）進(jìn)行斷言。而且這些測(cè)試工具即使提供錄制腳本的功能，但對(duì)于斷言往往還需要測(cè)試人員手工補(bǔ)充插入。
除了補(bǔ)充、維護(hù)斷言條件的工作量大之外，這種斷言模式還存在一些明顯的不足，下面結(jié)合一個(gè)實(shí)際的例子（如下圖）進(jìn)行分析：
● 無(wú)法感知未設(shè)為斷言對(duì)象的字段上發(fā)生的錯(cuò)誤
以上圖為例，如果在“增加用戶(hù)”的測(cè)試腳本之后只對(duì)列表中的“用戶(hù)姓名是否存在” 進(jìn)行斷言，那么就可能遺漏“入職日期沒(méi)有提交成功”的錯(cuò)誤。而且由于頁(yè)面的信息量往往很大，我們是不可能對(duì)所有字段都設(shè)置為斷言條件的。
● 難以對(duì)于UI樣式或UI邏輯進(jìn)行斷言
以上圖為例，有一個(gè)UI樣式類(lèi)的缺陷（左側(cè)菜單樹(shù)的根節(jié)點(diǎn)“console”下面多出來(lái)一條虛 線(xiàn)）和一個(gè)UI邏輯類(lèi)的缺陷（右側(cè)用戶(hù)列表只有一頁(yè)，但“下一頁(yè)”和“最后一頁(yè)”圖標(biāo)依然是可以點(diǎn)擊的，即沒(méi)有灰顯）。此類(lèi)缺陷即使對(duì)于經(jīng)驗(yàn)豐富、心思縝 密的測(cè)試人員，在人工測(cè)試時(shí)也是很可能發(fā)現(xiàn)不了的，并且在自動(dòng)化測(cè)試過(guò)程中也很難進(jìn)行斷言。
即使存在上述問(wèn)題，測(cè)試腳本中是否有充分的斷言，依然是評(píng)判自動(dòng)化測(cè)試有效性的一個(gè)重要指標(biāo)。但實(shí)施過(guò)自動(dòng)化測(cè)試的人應(yīng)該都會(huì)有這樣的體會(huì)：“大部分?jǐn)嘌栽诖蟛糠智闆r下只是佐證軟件是運(yùn)行正常的”。
當(dāng)然，所有人都應(yīng)該是非常期待看到這樣的結(jié)果，畢竟誰(shuí)也不希望每次回歸測(cè)試時(shí)都是用例大面積不通過(guò)。只是辛辛苦苦寫(xiě)這些斷言語(yǔ)句的測(cè)試人員心里未免有些“小遺憾”。
本系列上篇文章中談到“很多人一提到自動(dòng)化測(cè)試腳本，馬上就想到需要提供錄制工具”，但如果換個(gè)角度思考，很可能就是“柳暗花明又一村”。
在這里，我們同樣換個(gè)角度思考，假設(shè)我們的自動(dòng)化測(cè)試主要目標(biāo)是為了證明軟件運(yùn)行正常，那么我們會(huì)怎么做？
筆者這邊的一個(gè)經(jīng)驗(yàn)就是“按照完整的業(yè)務(wù)流程來(lái)組織測(cè)試用例，只對(duì)少量、必要的關(guān)鍵點(diǎn)進(jìn)行斷言”。以“租戶(hù)對(duì)虛擬化資源的申請(qǐng)使用”為例，來(lái)具體看看測(cè)試用例的組織方式：
1、新租戶(hù)注冊(cè)；
2、管理員登錄系統(tǒng)，對(duì)注冊(cè)租戶(hù)進(jìn)行審批，然后退出系統(tǒng)；
3、審批后的租戶(hù)登錄系統(tǒng)；
4、租戶(hù)申請(qǐng)所需要的虛擬化資源（比如，40G硬盤(pán)、2核CPU、2G內(nèi)存），然后退出系統(tǒng)；
5、管理員登錄系統(tǒng)，對(duì)租戶(hù)申請(qǐng)的資源進(jìn)行審批，然后退出系統(tǒng)；
6、租戶(hù)登錄系統(tǒng)，在已申請(qǐng)資源的基礎(chǔ)上創(chuàng)建安裝指定操作系統(tǒng)的虛擬機(jī)；
7、斷言虛擬機(jī)是否創(chuàng)建成功；
8、租戶(hù)退出系統(tǒng)；
9、管理員登錄系統(tǒng)，刪除租戶(hù)；
10、斷言租戶(hù)之前申請(qǐng)的資源是否被完全釋放；
11、租戶(hù)再次登錄系統(tǒng)，斷言是否無(wú)法登錄；
上述測(cè)試用例就是按照完整的業(yè)務(wù)流程進(jìn)行組織，并且只對(duì)少量關(guān)鍵點(diǎn)（7、10、11）進(jìn)行斷言，如果整個(gè)用例可以運(yùn)行通過(guò)，就能證明這個(gè)業(yè)務(wù)是沒(méi)有問(wèn)題的。
另外還有一個(gè)值得考慮的現(xiàn)象，就是相對(duì)于自動(dòng)化測(cè)試而言，一個(gè)優(yōu)秀的測(cè)試人員在人工測(cè)試時(shí)是如何判斷功能正確與否的呢？他不會(huì)死板的只盯著某幾 個(gè)輸入域的值，他一定還會(huì)同時(shí)關(guān)注頁(yè)面上所有數(shù)據(jù)的正確性、會(huì)更加關(guān)注業(yè)務(wù)流程是否正確、會(huì)更敏銳的發(fā)現(xiàn)頁(yè)面樣式或UI邏輯類(lèi)的缺陷。
為了兼顧“證明軟件正常運(yùn)行”和“人性化的識(shí)別軟件缺陷”，一個(gè)優(yōu)秀的測(cè)試工具應(yīng)該考慮提供以下多種斷言機(jī)制。
一、控件級(jí)細(xì)粒度斷言即前面提到的最常見(jiàn)的斷言方式。在測(cè)試過(guò)程中，可以在任何位置增加斷言腳本，來(lái)判斷頁(yè)面指定控件是否存在、控件顯示值是否為預(yù)期結(jié)果等。通常建議只對(duì)關(guān)鍵校驗(yàn)點(diǎn)進(jìn)行斷言。
二、頁(yè)面級(jí)粗粒度斷言通過(guò)對(duì)比前（之前測(cè)試通過(guò)）后（后續(xù)持續(xù)發(fā)布）版本在測(cè)試用例路徑和輸入?yún)?shù)相同的情 況下，整個(gè)頁(yè)面內(nèi)容（包括截圖和數(shù)據(jù)）是否嚴(yán)格相同來(lái)做粗粒度斷言。
通過(guò)頁(yè)面截圖進(jìn)行斷言有兩個(gè)實(shí)現(xiàn)要點(diǎn)：首先要選擇一個(gè)合適的截圖方案（筆者推薦采用Selenium WebDriver提供的TakesScreenshot接口）；其次需要提供圖片對(duì)比工具，以便測(cè)試人員可以一眼看出兩個(gè)版本頁(yè)面截圖的差異。
下面是筆者在測(cè)試框架中實(shí)現(xiàn)的截圖自動(dòng)化對(duì)比功能的實(shí)際效果。下圖中左側(cè)部分是“實(shí)際結(jié)果截圖”、右側(cè)是“預(yù)期結(jié)果截圖”、中間部分是差異對(duì) 比，測(cè)試人員一眼便可看出其中的Bug：“表格行選中的翻頁(yè)緩存（在當(dāng)前頁(yè)選中幾條記錄，翻到下一頁(yè)再翻回本頁(yè)，需要保持之前的行選中狀態(tài)）功能丟失 了”。
通過(guò)頁(yè)面數(shù)據(jù)進(jìn)行斷言的實(shí)現(xiàn)方式相對(duì)簡(jiǎn)單一些，首先要提取頁(yè)面上所有的數(shù)據(jù)（或文本），接著進(jìn)行格式化，然后再自動(dòng)化對(duì)比。 “頁(yè)面級(jí)粗粒度斷言”的特點(diǎn)及應(yīng)用場(chǎng)景如下：
● 無(wú)需編寫(xiě)任何斷言語(yǔ)句；
● 需要能夠提供可用于自動(dòng)對(duì)比的歷史正確版本，特別適用于可以持續(xù)構(gòu)建的項(xiàng)目；
● 能判斷出UI樣式和UI邏輯類(lèi)的錯(cuò)誤；
● 由于對(duì)比絕對(duì)精準(zhǔn)，導(dǎo)致可能存在誤判，因此需要人工對(duì)差異圖片進(jìn)行排查； 【注】由于很多Web頁(yè)面都有漸入漸出、點(diǎn)擊時(shí)按鈕變色等很炫的效果，所以在兩次截圖的瞬間可能頁(yè)面的動(dòng)態(tài)樣式是不一樣的，這就是所謂的“誤判”。筆者對(duì) 于一個(gè)“動(dòng)態(tài)樣式”適中的項(xiàng)目采用這種斷言方式，統(tǒng)計(jì)結(jié)果表明誤判率在20%左右。
● 鑒于回歸測(cè)試的時(shí)候，通常大部分用例應(yīng)該是可以通過(guò)的，所以“頁(yè)面級(jí)粗粒度斷言”的投入產(chǎn)出比非常占優(yōu)勢(shì)！
三、 基于業(yè)務(wù)邏輯斷言在測(cè)試設(shè)計(jì)時(shí)把有依賴(lài)關(guān)系的用例一起執(zhí)行，如果某個(gè)步驟出現(xiàn)問(wèn)題，即便不設(shè)置任何斷言語(yǔ)句，在當(dāng)前步驟或后續(xù)步驟的測(cè)試用例也會(huì)執(zhí)行失敗。下面以“增加、查詢(xún)、修改、刪除”這個(gè)最典型的流程來(lái)說(shuō)明（如下圖所示）。
假定在“增加”環(huán)節(jié)出現(xiàn)問(wèn)題，那么我們的測(cè)試用例執(zhí)行情況可能出現(xiàn)如下幾種結(jié)果：
1、如果在“增加記錄A”的用例中包含對(duì)是否增加成功的斷言，那么測(cè)試用例從“增加記錄A”開(kāi)始出錯(cuò)；
2、如果在“增加記錄A”中不包含斷言，而是在“查詢(xún)A”的用例中包含是否有查詢(xún)結(jié)果的斷言，那么測(cè)試用例會(huì)從“查詢(xún)A”開(kāi)始出錯(cuò)；
3、如果在“查詢(xún)A”中也不包含斷言，那么測(cè)試用例會(huì)從“修改查詢(xún)結(jié)果”開(kāi)始出錯(cuò)。
所謂“基于業(yè)務(wù)邏輯斷言”，就是指上述第三種情況，其特點(diǎn)及應(yīng)用場(chǎng)景如下：
● 無(wú)需編寫(xiě)任何斷言語(yǔ)句，但測(cè)試設(shè)計(jì)要考慮業(yè)務(wù)邏輯順序；
● 與“頁(yè)面級(jí)粗粒度斷言”相比，不需要提供可用于對(duì)比的歷史正確版本，通常適用于項(xiàng)目剛開(kāi)發(fā)或樣式做整體調(diào)整等情況；
● 斷言錯(cuò)誤的位置不精準(zhǔn)，可能延后；
● 執(zhí)行過(guò)程每一步都做截圖備份（通過(guò)Selenium WebDriver可以很方便的實(shí)現(xiàn)），可以非常有效的輔助定位準(zhǔn)確的出錯(cuò)原因；
● 鑒于回歸測(cè)試的時(shí)候，通常大部分用例應(yīng)該是可以通過(guò)的，所以“基于業(yè)務(wù)邏輯斷言”的投入產(chǎn)出比非常占優(yōu)勢(shì)！
四、自定義擴(kuò)展斷言在人工測(cè)試時(shí)經(jīng)常有些操作結(jié)果的正確與否在當(dāng)前頁(yè)面無(wú)法做出判斷，需要到其它頁(yè)面甚至系統(tǒng)外部 （比如，數(shù)據(jù)庫(kù)、輸出日志）獲取信息來(lái)做出判斷。以最常見(jiàn)的“基于數(shù)據(jù)庫(kù)進(jìn)行斷言”為例，測(cè)試工具需要支持把斷言時(shí)用到“預(yù)期結(jié)果”和“實(shí)際結(jié)果”配置為 對(duì)應(yīng)的SQL語(yǔ)句。
以上介紹了從測(cè)試工具的角度可以提供的多種斷言機(jī)制，在自動(dòng)化測(cè)試過(guò)程中應(yīng)該根據(jù)項(xiàng)目實(shí)際情況，考慮采用上述多種斷言的組合，以彌補(bǔ)控件級(jí)細(xì)粒度斷言的不足。
本系列文章至此，已經(jīng)分享了如何降低測(cè)試腳本的編寫(xiě)、維護(hù)成本，如何在不失測(cè)試有效性的前提下減少斷言成本。改善上 述兩大問(wèn)題之后，自動(dòng)化測(cè)試基本上就可以比較順利的開(kāi)展了。接下來(lái)如何讓自動(dòng)化測(cè)試的價(jià)值最大化呢？答案就是頻繁的執(zhí)行測(cè)試腳本。因此下一步要做的就是持 續(xù)集成（或者稱(chēng)為每日構(gòu)建）。下一篇文章會(huì)分享一個(gè)由測(cè)試團(tuán)隊(duì)主導(dǎo)的持續(xù)集成案例，敬請(qǐng)關(guān)注！
原文：http://www.infoq.com/cn/articles/Agile-test-automation-3
相關(guān)鏈接：
我們的測(cè)試為什么不夠敏捷
敏捷自動(dòng)化測(cè)試（2）——像用戶(hù)使用軟件一樣享受自動(dòng)化測(cè)試