事件的起因在于老板最近的兩次“故障”，一次去年的，一次最近。共同原因都是腳手架在發(fā)布平臺發(fā)布打包時出錯，導(dǎo)致線上應(yīng)用白屏不可用。
最神奇的是，事后多次 Code Review，結(jié)果還是沒有發(fā)現(xiàn)任何能夠?qū)е略搯栴}的 bug，最后推測有可能是服務(wù)器在發(fā)布打包的時候出了問題。
當(dāng)老板第 N + 1 次吐槽因為他寫的工程化工具領(lǐng)來的天外飛鍋，我突然思考起來，如何才能避免這種天外飛鍋。
歸根結(jié)底，導(dǎo)致這類線上故障的原因都是在于打包上線的代碼沒有經(jīng)過驗證。針對這個問題，有兩種方法可以解決：
治本，由于請求地址不同，預(yù)發(fā)（測試）版本不可直接發(fā)線上，而線上版本缺少了上線之前的驗證過程。所以，可以通過在發(fā)布系統(tǒng)的預(yù)發(fā)和線上之間，新增一個 beta 發(fā)布，beta 發(fā)布使用線上發(fā)布的打包流程，不同的是，只允許內(nèi)網(wǎng)訪問，專門用于內(nèi)部測試。有人可能會問，哪怕添加了 beta 發(fā)布，依然無法保證線上發(fā)布重新打包的時候不出錯呀？重點來了，這種解決方案的核心就在于，beta 發(fā)布測試通過后，直接將 beta 發(fā)布的打包產(chǎn)物進行線上發(fā)布，因為不需要二次打包，所以避免了打包過程中產(chǎn)生新的問題。由于添加 beta 發(fā)布需要不同崗位，比如運維、后端、移動端的協(xié)作，所以實施難度較大。
治標(biāo)，既然線上版本上線之前驗證不了，那么上線之后立刻回歸驗證，如果發(fā)現(xiàn)問題，立刻手動回滾。正所謂沒有人發(fā)現(xiàn)的故障就不是故障，perfect！
正如之前所說的，治本的方法實施難度較大，所以，我們重點關(guān)注治標(biāo)的方法，即上線之后進行回歸驗證。
說到這里，問大家一個問題，需求上線之后，作為前端，大家會主動進行回歸驗證而不是等測試進行驗證嗎？
不管你們會不會，反正我是不會[doge]。
在這種情況下，前端 UI 自動化測試閃亮登場。
眾所周知，測試是一個很重要的環(huán)節(jié)，由于它的重要性，甚至軟件工程中出現(xiàn)了 TDD 這種說法。
在之前，所謂的前端測試，更多的是在頁面上點點點，進行人肉測試，毫無疑問，效率低下。
所以，有了前端自動化測試，使用機器代替人工。一般來說，前端自動化測試分為兩種：單元測試以及 e2e 測試（UI 自動化測試）。
單元測試本質(zhì)上是一種白盒測試，是對程序中的最小可測試單元進行測試。
e2e 測試本質(zhì)上是一種黑盒測試，相當(dāng)于模擬用戶訪問應(yīng)用程序，主要檢查界面或功能是否正確。
相比于單元測試，UI 自動化測試更多的是站在用戶角度，從用戶的角度發(fā)現(xiàn)問題。但是，由于它其實是一種黑盒測試，所以效率相對于白盒測試要低一些。
Selenium：e2e 測試鼻祖級的框架，有多種編程語言的版本，如果你去問問你們公司的測試，那么你一定會發(fā)現(xiàn)，他們正在用 Python 版本的 Selenium 寫自動化測試腳本。值得一提的是，它是基于 webdriver 而不是 webkit 內(nèi)核實現(xiàn)的，所以，Selenium 的瀏覽器兼容性相對于其他瀏覽器要好很多。
PhantomJS：開創(chuàng)性的 headless（無頭）測試框架，何為 headless？即沒有 UI 界面的瀏覽器。headless 最大好處在于可以像單元測試一樣，在命令行中跑 e2e 測試。
nightmare：一句話——加強版的 PhantomJS，相對于 PhantomJS，無論是開發(fā)還是運行效率都得到了很大的提升。
tips：nightmare 還有個優(yōu)點——它提供了一個 Chrome 插件 daydream，該插件可以通過錄制屏幕，自動化生成測試代碼，懶人福音。
nightwatch：名字和 nightmare 很像，但是完全不一樣的一個 e2e 框架，使用 Node 調(diào)用 webdriver 實現(xiàn)。相對于 Selenium，開發(fā)和運行效率更高，最重要的是，迭代很活躍，這點，用開源產(chǎn)品的用戶懂得都懂。
cypress：我接觸的第一個 e2e 測試框架，測試界面和文檔做到極致的一個產(chǎn)品，推薦大家可以試一試。
puppeteer：e2e 測試框架的集大成者，默認以 headless 模式運行，但是也可以通過配置變?yōu)?Chromium 運行。開發(fā)效率以及運行效率一流，最重要的是，它像 nightmare 一樣，提供了測試代碼生成插件——puppeteer-recorder。
綜上所述，如果考慮瀏覽器兼容性，使用 nightwatch，反之，選擇 cypress 或者 puppeteer，如果需要 headless 或者自動化生成代碼的功能，那就使用 puppeteer。
從自動化測試的收益來說，自動化測試有個公式：
自動化的收益 = 迭代次數(shù) * 全手動執(zhí)行成本 - 首次自動化成本 - 維護次數(shù) * 維護成本
簡而言之，迭代越頻繁，維護成本越高的項目，添加自動化測試的價值越高。在基建項目或頻繁迭代項目中引入前端 UI 自動化測試，可以大大減少每次迭代后手動測試的時間。比起手動測試，前端 UI 自動化測試測試的更快也更徹底。
另一個方面，隨著前端技術(shù)的高速發(fā)展，各個公司的前端開發(fā)、監(jiān)控體系已經(jīng)很完善了，但是缺少前端在測試方向上的延伸。而前端 UI 自動化測試最大的價值，就是在前端部分，彌補開發(fā)和監(jiān)控之間的空白區(qū)域，形成一個完整的閉環(huán)，三管齊下，極大地保障了項目的質(zhì)量。
針對前端 UI 自動化測試，我思考了很久，個人認為主要有兩大方向：
針對單個項目，進行一系列關(guān)鍵功能的測試，不過如果需要追求測試覆蓋率的話，比較耗費時間，算是一種比較常規(guī)、精細的測試方案，所以比較適合一些長期維護的基建項目或者大型業(yè)務(wù)項目，缺點在于活動頁基本覆蓋不了。
針對所有項目，添加一個自動化測試的腳手架（或者平臺化），能夠通過配置項，自動訪問目標(biāo)頁面，并進行一系列的 e2e 測試，根據(jù)不同的結(jié)果采取截圖、生成 pdf、報警等不同處理方案。
第二個方案，即通用化方案也是我最近開發(fā)的重點方向，接下來我應(yīng)該會專門寫一篇文章，大概介紹下該方案的設(shè)計以及具體實現(xiàn)（如果我沒有懶癌發(fā)作的話[doge]）。
聯(lián)系客服
