關於 E2E 測試

上一篇文章發佈後，居然收穫到一些同窗的注意，實在是意外之喜。不過我也發現，不少同窗對 E2E 測試不夠了解，正好我廠的產品也沒作到能做爲商用版發佈的程度，因此這篇再來聊聊 E2E 測試吧。

本文的測試均指自動化測試。

E2E，是「End to End」的縮寫，能夠翻譯成「端到端」測試。它模仿用戶，從某個入口開始，逐步執行操做，直到完成某項工做。與單元測試不一樣，後者一般須要測試參數、參數類型、參數值、參數數量、返回值、拋出錯誤等，目的在於保證特定函數可以在任何狀況下都穩定可靠完成工做。單元測試假定只要全部函數都正常工做，那麼整個產品就能正常工做。

相對來講，E2E 測試並無那麼強調要覆蓋所有使用場景，它關注的是 一個完整的操做鏈是否可以完成。對於 Web 前端來講，還關注 界面佈局、內容信息是否符合預期。

好比，登錄界面的 E2E 測試，關注用戶是否可以正常輸入，正常登陸；登錄失敗的話，是否可以正確顯示錯誤信息。至於輸入不合法的內容是否處理，沒有很大的關係。

Web 前端 E2E 測試的現狀

Web 前端 E2E 自動化測試開展得很差。在我從業的這十幾年裏，大部分產品的前端 E2E 測試都交給測試人員手工完成。咱們稍稍分析一下，大概有三個緣由：

1. 測試環境很差搭

單元測試也好、接口測試也好，測試環境都很容易搭建。然而 Web 前端測試若是想達到目的，須要完整的桌面操做系統和瀏覽器環境，這種面向普通用戶的軟件對自動化工具並不友好。對系統要求也比較高，很難整合到開發測試工具鏈檔中。

解決方案固然是有的，目前最流行的應該是 Selenium WebDriver。不過對於小公司、小團隊來講，在並不豐富的資料中摸着石頭過河實在不夠經濟，並且，還有接下來的兩個問題。

2. 測試很差寫。

目前的 Web 前端 E2E 測試工具侷限於 XPath 技術棧。你們用選擇器查找 DOM 節點，校驗其屬性和內容，接着進行交互。這樣作致使一個必而後果：寫測試的人員對頁面的 DOM 結構必須瞭如指掌，才能用準確目標元素。

同時，在這個技術環境下寫就的測試用例，一旦 DOM 結構出現變化，就要大規模的修改，甚至重寫。工做量很大，並且存在一些不穩定因素。跟某團隊 Leader 聊天，他就很擔憂漫長的迭代過程當中，DOM 結構變化致使測試用例失效，繼而引起項目排期混亂。

結果，Web 前端 E2E 測試用例的只能由前端用 JS 寫，工做量大，維護負擔重，且存在一些風險。你們都不肯意寫。

3. 有些東西很差測

隨着用戶對產品的要求水漲船高，頁面邏輯愈來愈複雜，功能愈加依賴 Ajax，甚至和後端完全分離，成爲單頁應用（SPA）。這類產品與傳統的靜態頁服務不一樣，咱們無法偵聽 DOMReady 事件，也就難以找到合適的時間點啓動測試。

早些時候，咱們只能依靠 setInterval() 輪詢。現在，經過 Puppeteer 或者瀏覽器擴展均可以監聽網絡鏈接，能夠根據當前保持的鏈接數來判斷請求是否完成。

不過這些作法仍然存在不小的實施難度。

4. 預期收益通常

我跟不少技術老大聊過。你們的回答都是：沒寫，沒空，招測試。在加班成爲常態的今天，在「看獲得」的工做以外，再去作這些「看不到」的工做，實在有些吃力不討好。另外一方面，測試寫得少，覆蓋率跟不上，仍是得招測試，人工測試。

惡行循環就此產生：不想寫致使沒測試；那就招測試人員；有了專職測試我還寫什麼測試……因此你們都不寫測試了。

對於中等以上規模的技術團隊，招幾個測試也還行。對於整個公司就只有幾我的的創業團隊來講，大多數時候只能裸奔……

更好的 Web 前端 E2E 測試工具

行文至此，結論就很明顯了：咱們須要全新的、更高級的 Web 前端 E2E 測試工具。這個工具須要同時知足：

1. 有效

1. 能夠準確地描述 UI 的結構
2. 能夠儘可能全面的模擬用戶真實操做
3. 覆蓋多種操做系統、適配各類瀏覽器

2. 使用成本低

1. 測試用例應該儘可能簡短，用最少的代碼描述出 UI，完成交互。
2. 測試用例應該和 DOM 實現解耦，用的儘可能久，能不改就不改。
3. 測試用例應該讓全部人都學得會，寫得通

3. 提升開發效率

1. 應該提供方便易用的編寫、測試環境，讓用戶能夠輕鬆上手
2. 須要可以和常見的 CI 系統集成

我廠的解決方案

最後回到我廠。

咱們設計了一個全新的語言用來描述 UI，叫作 Navlang。咱們能夠用它描述各元素的相對位置，操做元素進行交互。

它是一個描述性語言，只包含很簡單的邏輯——實際上 E2E 測試也不須要多複雜的邏輯，跑不通就是掛了，跑通了就沒問題。這樣一來，任何人，只要通過簡單的培訓，均可以寫出正確的測試用例。（HTML 就是最好的例子。前端不少都是頁面仔出身，好比我，相信你們對這類語言的易學易用都有所瞭解。）

由於是語言，因此它能夠寫成代碼，能夠被版本管理；由於是新的抽象，因此它不跟 DOM 實現耦合，能夠被反覆使用，幾乎沒有維護成本。（只有界面變化才須要修改測試用例，此時不管如何都要修改測試用例）

目前這個工具已經在我廠的開發體系中工做將近一年，爲我廠產品的穩定作出了很是重大的貢獻。

功能化以外，咱們也在做產品化和商品化的努力。目前已經基本完成瀏覽器擴展功能，讓普通用戶能夠經過瀏覽器擴展編寫和運行測試。接下來，咱們還會提供基於 Node.js 的測試工具框架，幫助你們將測試集成到現有的 CI 系統當中。

將來，這款產品會服務廣大小型公司和小型團隊，幫助你們提高 Web UI 測試的效率。

好了，敬請期待下週的 Navlang 介紹吧。