從一次故障聊聊前端 UI 自動化測試

背景

事件的原由在於老闆最近的兩次「故障」，一次去年的，一次最近。共同緣由都是腳手架在發佈平臺發佈打包時出錯，致使線上應用白屏不可用。

最神奇的是，過後屢次 Code Review，結果仍是沒有發現任何可以致使該問題的 bug，最後推測有多是服務器在發佈打包的時候出了問題。

當老闆第 N + 1 次吐槽由於他寫的工程化工具領來的天外飛鍋，我忽然思考起來，如何才能避免這種天外飛鍋。

歸根結底，致使這類線上故障的緣由都是在於打包上線的代碼沒有通過驗證。針對這個問題，有兩種方法能夠解決：

1. 治本，因爲請求地址不一樣，預發（測試）版本不可直接發線上，而線上版本缺乏了上線以前的驗證過程。因此，能夠經過在發佈系統的預發和線上之間，新增一個 beta 發佈，beta 發佈使用線上發佈的打包流程，不一樣的是，只容許內網訪問，專門用於內部測試。有人可能會問，哪怕添加了 beta 發佈，依然沒法保證線上發佈從新打包的時候不出錯呀？重點來了，這種解決方案的核心就在於，beta 發佈測試經過後，直接將 beta 發佈的打包產物進行線上發佈，由於不須要二次打包，因此避免了打包過程當中產生新的問題。因爲添加 beta 發佈須要不一樣崗位，好比運維、後端、移動端的協做，因此實施難度較大。
2. 治標，既然線上版本上線以前驗證不了，那麼上線以後馬上回歸驗證，若是發現問題，馬上手動回滾。正所謂沒有人發現的故障就不是故障，perfect！

正如以前所說的，治本的方法實施難度較大，因此，咱們重點關注治標的方法，即上線以後進行迴歸驗證。

說到這裏，問你們一個問題，需求上線以後，做爲前端，你們會主動進行迴歸驗證而不是等測試進行驗證嗎？

無論大家會不會，反正我是不會[doge]。

在這種狀況下，前端 UI 自動化測試閃亮登場。

什麼是前端 UI 自動化測試

衆所周知，測試是一個很重要的環節，因爲它的重要性，甚至軟件工程中出現了 TDD 這種說法。

在以前，所謂的前端測試，更多的是在頁面上點點點，進行人肉測試，毫無疑問，效率低下。

因此，有了前端自動化測試，使用機器代替人工。通常來講，前端自動化測試分爲兩種：單元測試以及 e2e 測試（UI 自動化測試）。

單元測試本質上是一種白盒測試，是對程序中的最小可測試單元進行測試。

e2e 測試本質上是一種黑盒測試，至關於模擬用戶訪問應用程序，主要檢查界面或功能是否正確。

相比於單元測試，UI 自動化測試更多的是站在用戶角度，從用戶的角度發現問題。可是，因爲它實際上是一種黑盒測試，因此效率相對於白盒測試要低一些。

前端 UI 自動化測試框架對比

Selenium：e2e 測試鼻祖級的框架，有多種編程語言的版本，若是你去問問大家公司的測試，那麼你必定會發現，他們正在用 Python 版本的 Selenium 寫自動化測試腳本。值得一提的是，它是基於 webdriver 而不是 webkit 內核實現的，因此，Selenium 的瀏覽器兼容性相對於其餘瀏覽器要好不少。

PhantomJS：開創性的 headless（無頭）測試框架，何爲 headless？即沒有 UI 界面的瀏覽器。headless 最大好處在於能夠像單元測試同樣，在命令行中跑 e2e 測試。

nightmare：一句話——增強版的 PhantomJS，相對於 PhantomJS，不管是開發仍是運行效率都獲得了很大的提高。

tips：nightmare 還有個優勢——它提供了一個 Chrome 插件 daydream，該插件能夠經過錄制屏幕，自動化生成測試代碼，懶人福音。

nightwatch：名字和 nightmare 很像，可是徹底不同的一個 e2e 框架，使用 Node 調用 webdriver 實現。相對於 Selenium，開發和運行效率更高，最重要的是，迭代很活躍，這點，用開源產品的用戶懂得都懂。

cypress：我接觸的第一個 e2e 測試框架，測試界面和文檔作到極致的一個產品，推薦你們能夠試一試。

puppeteer：e2e 測試框架的集大成者，默認以 headless 模式運行，可是也能夠經過配置變爲 Chromium 運行。開發效率以及運行效率一流，最重要的是，它像 nightmare 同樣，提供了測試代碼生成插件——puppeteer-recorder。

綜上所述，若是考慮瀏覽器兼容性，使用 nightwatch，反之，選擇 cypress 或者 puppeteer，若是須要 headless 或者自動化生成代碼的功能，那就使用 puppeteer。

使用前端 UI 自動化測試的價值

從自動化測試的收益來講，自動化測試有個公式：

自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本
複製代碼

簡而言之，迭代越頻繁，維護成本越高的項目，添加自動化測試的價值越高。在基建項目或頻繁迭代項目中引入前端 UI 自動化測試，能夠大大減小每次迭代後手動測試的時間。比起手動測試，前端 UI 自動化測試測試的更快也更完全。

另外一個方面，隨着前端技術的高速發展，各個公司的前端開發、監控體系已經很完善了，可是缺乏前端在測試方向上的延伸。而前端 UI 自動化測試最大的價值，就是在前端部分，彌補開發和監控之間的空白區域，造成一個完整的閉環，三管齊下，極大地保障了項目的質量。

將來的展望

針對前端 UI 自動化測試，我思考了好久，我的認爲主要有兩大方向：

1. 針對單個項目，進行一系列關鍵功能的測試，不過若是須要追求測試覆蓋率的話，比較耗費時間，算是一種比較常規、精細的測試方案，因此比較適合一些長期維護的基建項目或者大型業務項目，缺點在於活動頁基本覆蓋不了。
2. 針對全部項目，添加一個自動化測試的腳手架（或者平臺化），可以經過配置項，自動訪問目標頁面，並進行一系列的 e2e 測試，根據不一樣的結果採起截圖、生成 pdf、報警等不一樣處理方案。

第二個方案，即通用化方案也是我最近開發的重點方向，接下來我應該會專門寫一篇文章，大概介紹下該方案的設計以及具體實現（若是我沒有懶癌發做的話[doge]）。

若是有不一樣想法的同窗，歡迎一塊兒交流~

個人 github：github.com/KarthusLori…