敏捷自動化測試(3)-讓斷言不再成為自動化測試的負(fù)擔(dān)

第第頁敏捷自動化測試(3)——讓斷言不再成為自動化測試的負(fù)擔(dān)敏捷自動化測試(3)——讓斷言不再成為自動化測試的負(fù)擔(dān)

發(fā)表于：2023-04-26來源：infoq：殷坤點(diǎn)擊數(shù)：標(biāo)簽：

在本系列的第一篇文章“我們的測試為什么不夠敏捷”中，根據(jù)實(shí)例總結(jié)出敏捷自動化測試的兩大阻礙：“腳本維護(hù)困難”、“斷言條件繁瑣”。本文針對在不失自動化測試有效性的前

在本系列的第一篇文章"我們的（測試）為什么不夠敏捷'中，根據(jù)實(shí)例總結(jié)出敏捷（自動化）（測試）的兩大阻礙："腳本維護(hù)困難'、"斷言條件繁瑣'。本文針對在不失（自動化）測試有效性的前提下如何降低斷言成本來分享一些實(shí)踐經(jīng)驗(yàn)。

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

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

無法感知未設(shè)為斷言對象的字段上發(fā)生的錯誤

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

相關(guān)廠商內(nèi)容

一路走來技術(shù)人的創(chuàng)業(yè)故事

未來物聯(lián)網(wǎng)中智能硬件的角色

人工智能的技術(shù)版圖

GMTC全球移動技術(shù)大會，6折優(yōu)惠，最后一周!

不要寫死!天貓App的動態(tài)化配置中心實(shí)踐

難以對于UI樣式或UI邏輯進(jìn)行斷言

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

即使存在上述問題，測試腳本中是否有充分的斷言，依然是評判自動化測試有效性的一個重要指標(biāo)。但實(shí)施過自動化測試的人應(yīng)該都會有這樣的體會："大部分?jǐn)嘌栽诖蟛糠智闆r下只是佐證軟件是運(yùn)行正常的'。

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

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

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

筆者這邊的一個經(jīng)驗(yàn)就是"按照完整的業(yè)務(wù)流程來組織（測試用例），只對少量、必要的關(guān)鍵點(diǎn)進(jìn)行斷言'。以"租戶對虛擬化資源的申請使用'為例，來具體看看（測試用例）的組織方式：

新租戶注冊;

管理員登錄系統(tǒng)，對注冊租戶進(jìn)行審批，然后退出系統(tǒng);

審批后的租戶登錄系統(tǒng);

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

管理員登錄系統(tǒng)，對租戶申請的資源進(jìn)行審批，然后退出系統(tǒng);

租戶登錄系統(tǒng)，在已申請資源的基礎(chǔ)上創(chuàng)建安裝指定操作系統(tǒng)的虛擬機(jī);

斷言虛擬機(jī)是否創(chuàng)建成功;

租戶退出系統(tǒng);

管理員登錄系統(tǒng)，刪除租戶;

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

租戶再次登錄系統(tǒng)，斷言是否無法登錄;

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

另外還有一個值得考慮的現(xiàn)象，就是相對于自動化測試而言，一個優(yōu)秀的測試人員在人工測試時是如何判斷功能正確與否的呢?他不會死板的只盯著某幾個輸入域的值，他一定還會同時關(guān)注頁面上所有數(shù)據(jù)的正確性、會更加關(guān)注業(yè)務(wù)流