自動化測試用例的原子性

原子性測試

爲了使自動化框架都成功,此概念對於理解至關重要:「原子自動化測試用例不應模仿端到端自動化用例。」

取而代之的是,自動化檢查應形成一個不可拆分的單元,一個用例只能測試一個功能點。由於測試的顆粒度非常小,這與編寫單元測試非常相似。

原子性的測試用例應該是這樣的:

  • 該測試用例儘可能少地斷言,通常只有一個或兩個斷言。
  • 測試避免與 「UI」界面交互,最多隻能在兩個頁面上進行。

在通常情況下,測試顆粒度越小。測試用例就會越複雜,但是將測試設計得儘可能小有很多優點。

原子性測試用例的優點

精準反饋

編寫原子性測試可以快速執行得到測試結果。測試報告的反饋是迅速而針對性的。檢查功能狀態的時間一般都是幾秒鐘內完成。

對於測試報告中的錯誤信息,很快能夠復現且排查BUG的根源,並迅速解決它。

縮短測試鏈

如果平均單個測試用例執行的時間能夠縮短一半,那麼測試效率會提升兩倍以上。因爲測試的時間越長,誤報的可能性越大,隨着干擾因素的不斷累計,失敗的可能也越大。

編寫原子測試用例可減少脆弱性,因爲它減少了該測試中可能出現的斷裂的數量。原子性測試用例能夠減少大量誤報,這又會促進出現問題的排查時間。

這是一個例子:

  • 打開網頁主頁
  • 斷言頁面已打開
  • 斷言某個元素存在
  • 打開搜索頁面
  • 搜索文章
  • 斷言該文章存在

使用自動化測試時,每一個步驟都有概率出現錯誤。例如,定位器或交互機制可能已更改而同步策略可能已過期。

因此一個自動化測試用例中的步驟越多,測試就越有可能中斷併產生誤報。

更高的測試覆蓋率

編寫原子測試的第三個好處是,如果原子測試用例失敗,它們將不會阻斷其他功能用例的測試。

換句話說,自動化測試用例可以對業務功能進行更全面的檢查,而不用擔心測試鏈斷裂導致後面的功能無法覆蓋。參考上面提到的測試:如果在步驟「斷言元素存在」中失敗,則可能永遠無法檢查搜索頁面或搜索功能是否正常。

若是在迴歸測試場景中,運行大規模測試用例的時候,原子性的測試用例將減少測試範圍。編寫原子測試用例的另一個巨大好處是,它們在運行時會更快,因爲完全可以進行並行化處理。參考:

通過「分佈式」「多線程」技術使用,測試用例執行時間大大減少,測試套件的執行時間可以成倍減少。

拆分UI自動化用例

你可能想知道如何拆分端到端測試用例爲原子性用例,這是一個很困難的挑戰,特別是對UI測試來講。參考:所謂UI測試

這是一個簡單的場景:

  • 打開購物網站首頁
  • 斷言頁面打開
  • 搜索商品
  • 斷言已找到商品
  • 加入購物車
  • 斷言已添加商品
  • 訂單信息補充
  • 結算
  • 斷言訂單成功

許多自動化工程師認爲這個測試用例必需完整執行整個測試鏈的流程。例如必須在搜索之前必需打開首頁之前,依此類推。原因是,如果購物車中沒有商品,又如何才能進入結帳流程?

注入數據

自動化測試最佳實踐方法是在UI交互之前注入數據以填充應用程序的狀態。

這將極大地幫助測試過程。例如:

您可以通過幾個選項控制應用程序的狀態:

  • 使用 API測試框架的方法將應用程序設置爲特定狀態
  • 使用 JavaScript修改頁面
  • 將數據注入數據庫以將應用程序設置爲特定狀態
  • 使用 cookie信息

如果可以在應用程序的接縫之間插入數據,則可以隔離每個步驟並對其進行單獨測試。

要考慮的一些選項:

  • 發送網絡請求以生成新的測試用戶
  • 發送網絡請求以填充購物車中的商品
  • 使用 Selenium打開瀏覽器到 「購物車」頁面
  • 使用網絡自動化執行結帳
  • 之後清理所有測試數據

使用HTTP接口

使用「API測試」與在每個測試步驟中使用自動化的「GUI」相比,它的功能更加強大且速度更快。

例如,一個HTTP請求可以在大約幾十毫秒內執行。

這意味着前置步驟中的需求只需不到一秒鐘即可完成。

測試用例需要完成的唯一步驟是使用Selenium(實際要測試的唯一部分)完成結帳過程。

使用JavaScript

登錄頁面是測試最常見的障礙之一,而且大多數應用程序都有必需經過這一步才能進入系統。

那麼,如何從測試中刪除它,使測試用例可以是原子性的?

這是一個例子:

在某一個帶有登錄屏幕的頁面:

  • 使用 「GUI」測試工具打開Web應用
  • 執行 「JavaScript」腳本
  • 登錄成功

現在,使用「GUI」自動化測試工具 執行要測試的單個原子測試用例。

無法注入數據進行Web應用程序測試嗎?

如果無法注入數據進行測試怎麼辦?

很多開發在進行軟件開發時候,根本不會考慮應用程序的可測試性。

如果無法注入數據進行測試,大概有兩個選項以供選擇:

  • 與軟件開發人員合作以使應用程序更具可測試性。
  • 「放棄」

溝通對於長期測試的成功至關重要 果應用程序不是測試友好型,不要自動化。


「FunTester」,非著名測試開發,文章記錄學習和感悟,歡迎關注,交流成長。
  • Gitee地址 https://gitee.com/fanapi/tester
  • GitHub地址 https://github.com/JunManYuanLong/FunTester

點擊閱讀原文,查看公衆號歷史文章

本文分享自微信公衆號 - FunTester(NuclearTester)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章