從業務測試需求痛點到自動化測試平臺設計開發

少年發表於2020-12-24

目錄

前言

這段時間用愛發電，在 UI 自動化測試平臺上做了全新的探索和設計，在落地性，效益性，業務性等方面做了進一步思考和優化。

從 系統需求設計 + 技術框架選型 + 資料表結構設計 + 後端開發 + 前端開發 + 映象打包部署 + docker 容器化上線 + CI/CD 相容設計，都由我一個人獨立設計開發完成的，挑戰很大，但是能順利完成，也算是給自己 2020 年一個滿意的答卷，當然更滿意的其實是開啟了 UI 自動化測試平臺新世界的大門。

系統從 0 到 1 大概花了兩個月，基本下班有時間都在寫，11 月份主要是在 業務需求痛點整理與思考 系統方案設計 技術實現的可行性 系統技術架構的擴充套件性和優越性 核心 demo 的實現 等方面進行研究和探索，12 月份就是 CRUD 及業務落地 demo 展示。

個人認為 11 月份其實才是最核心的思考，畢竟不結合業務的設計和不優化技術框架設計的開發都是為未來迭代埋雷。12 月份則落實這份思考，用成果展示出來。

在此分享一下我的一些心得體會， 這可能比我告訴你如何 CRUD 更有用。

UI自動化的現狀

市面上開源的優秀的 UI 自動化平臺很少，至少比介面自動化平臺少得多，原因其實也很簡單:

1.難度大。

介面自動化平臺本質上都只是在圍繞 request 做文章，到 UI 自動化平臺，除了思考 selenium + appium （目前普遍都是這個核心），還需要去思考頁面變化大，元素管理難度大，落地成本高，任務排程方式，用例執行方式等等問題，以及不一定會思考的問題，比如如何優化這些缺點，以及如何做進一步的提升？

2.成本高。

此前也曾寫過一個 UI 的自動化測試平臺 Autotest_platform，主要是以 selenium 為核心，POM 為用例管理機制，定製關鍵字封裝通用的方法，並通過填表格的方式完成 UI 測試用例的編寫。

然而就算用 POM 模式去管理，維護成本一樣很高，當然僅用作穩定的迴歸測試，還是很有價值的。

3.發展快。

UI 自動化測試框架，除了 selenium，appium，其他優秀的框架比如 cypress 以及 puppeteer 都在持續不斷地迭代優化，成為新秀。

甚至，為了降低 UI 自動化的成本，很多的框架都支援通過錄制的方式生成 UI 自動化指令碼。當然錄製有它的好，也有它的不好。

所以總結的現狀就是:

  • 平臺化的 UI 自動化大都基於 (selenium / appium) 等以 python / java 為體系。
  • 指令碼化的 UI 自動化框架新秀都基於 (cypress / puppeteer) 等以 nodejs 為體系。

我為什麼要做UI自動化平臺

  • 做自動化框架的話，要 部門 / 組 的人起碼都會寫 UI 自動化指令碼，但是大部分 UI 測試其實都是點點點，平臺落地性比框架大。
  • 自動化指令碼框架也要維護，為什麼不直接做成平臺？起碼做成平臺以後，在維護用例方面不需要會寫程式碼的人。
  • 平臺在人員管理，專案管理，用例管理，結果展示，資料統計等方面肯定更佔優勢。

我想做一個什麼樣的UI自動化平臺

業務測試痛點

先說下我的業務測試痛點:

  • 很容易大變動 UI 的點點點，UI 自動化成本非常高。
  • 既然大變動那肯定沒有迴歸測試，但是迴歸測試是很有必要的，因為不是全部都大變動，其實只是少數大變動而已。
  • 測試環境，預釋出環境，灰度釋出環境，線上環境，每個流程其實都在做重複的事情。
  • UI 異常流程測試，經常需要抓包工具來對某個流程裡面每個 url 的各個狀態來 mock / breakpoint / abort 等等等。
  • 測埋點。

由業務痛點提煉出來的需求

1.需要解決成本高且無迴歸測試問題。

  • 如果平臺能夠支援用 錄製方式生成的指令碼 來作為用例管理，成本不就減低了嗎？

比如這樣:

2.需要整合抓包工具的功能在 UI 流程的測試中。

比如這樣:

3.能測埋點。

我大概是離不開測埋點這個命了，反正到手的業務基本都有這個需求，測起來其實是非常繁瑣的。

從 2019 年開始就跟它抗爭。

摸索了很多，然後到 2020 年又優化一版。

當然都是指令碼框架的形式，需要把它們整合在平臺上。

比如這樣:

4.系統要高相容性和高擴充套件性

雖然目前業務測試主要是基於 puppeteer 來做，但是路不能走窄，至少還能相容其他測試框架，也可以擴充套件做壓測等等。

比如這樣:

5.非同步與同步的用例執行

  • 同步: 要能實時獲取結果和截圖線上除錯指令碼

既然是在平臺上設計用例，那肯定要能實時返回結果以供我除錯，而不是說每次我都要執行完了才去結果頁裡面看結果，多麻煩，而且指令碼錯了我都不知道錯哪裡。

比如這樣:

  • 非同步: 指令碼我除錯好了，就直接一鍵幫我跑吧，我最後再看報告看看哪些用例不通過。

那這種時候很明顯需要一個非同步的任務集合。

比如這樣:

由需求設計系統

經過上面的思考，所以專案的需求很清楚了。

專案背景

  • 前端頁面變動大，無 UI 自動化，迴歸測試成本高。
  • 異常測試需要重複抓包中斷或 mock，測試周期長，成本高。
  • 開源自動化測試 UI 平臺大都基於 python + selenium 開發，無法支援快速錄製測試，埋點測試，頁面效能測試等功能。

專案需求

  • 能夠支援擴充套件任意前端測試框架如 puppeteer/cypress/selenium/appium 等用例。
  • 能夠通用於所有前端系統介面的 UI 自動化測試。
  • 能夠通過快速錄製指令碼的方式生成測試用例。
  • 能夠支援適配任何系統的埋點測試。
  • 能夠支援任意 mock 資料測試。
  • 能夠支援頁面效能測試。

開發難點

  • 沒得抄。

開源沒有這種系統設計，這是一個全新的探索和優化設計，那隻能從頭來搞了。

為了更快落地投入使用，能不重複造輪子就不造，比如前端就用餓了麼元件 CRUD。

但是後端的核心還是得自己寫。

  • 工作量大。

畢竟前後端都是自己設計自己寫。

  • 難度大。

後端畢竟是 nodejs 而不是 python，那其實技術棧要求還是比較高的。

系統架構設計必須是優越的，具備高擴充套件性，高相容性，高執行性，等等。

新型UI自動化平臺的可行性探索

所以平臺的核心實現是什麼？需要解決什麼樣的問題？

如果不攻克這些難關，那麼平臺的方案設計是無法實現的。

基本問題

  • 前端傳過來錄製好的指令碼本質上只是個 string，如何執行錄製的指令碼用例？
  • 對於 puppeteer 裡面支援的 api，比如那些 mock，埋點監聽，頁面效能分析等功能，如何在 UI 用例中使用？
  • 執行完用例以後，如何拿到我想要的斷言結果資訊？

優化問題

  • 要對接 selenium/puppeteer/appium... 等不同的測試框架，如何去適配對接相容？
  • 測試用例數量非常多的場景下，如何提高執行速度？
  • 在除錯測試用例過程中，如何同步獲取到測試用例結果？基於 puppeteer 的 js 測試指令碼都是非同步設計，非同步容易實現，同步如何實現？
  • 在除錯測試用例過程中，從同步獲取的測試用例結果資料中，截圖是動態的，如何在前端動態展示？
  • 在除錯測試用例過程中，同步獲取測試結果會頻繁讀寫資料庫，如何優化？

如果能解決如上的所有問題，那麼系統就具備可行性，擴充套件性，優越性。

從上面業務測試需求痛點的舉例和系統的截圖，其實都表明我已經給所有的問題做出瞭解答和優化，UI 自動化測試平臺，自此開啟了一條全新的大門。

當然，如何解決這些問題就是一個需要更長篇幅才能說清楚的事情了，這次主題主要是分享 從業務測試需求痛點到自動化測試平臺設計開發 這一步過程中的思考。

除此之外其實還有很多的坑，一路開發過來，都是辛酸淚。

所幸快速成長，所幸披荊斬棘，所以就有這個平臺，這次歷程分享。

PS：技術交流 QQ 群 552643038

相關文章