資訊專欄INFORMATION COLUMN
摘要：與單元測試不同，后者通常需要測試參數參數類型參數值參數數量返回值拋出錯誤等，目的在于保證特定函數能夠在任何情況下都穩定可靠完成工作。單元測試假定只要所有函數都正常工作，那么整個產品就能正常工作。
上一篇文章發布后，竟然收獲到一些同學的注意，實在是意外之喜。不過我也發現，很多同學對 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. 有效可以準確地描述 UI 的結構
可以盡量全面的模擬用戶真實操作
覆蓋多種操作系統、適配各種瀏覽器
2. 使用成本低測試用例應該盡量簡短，用最少的代碼描述出 UI，完成交互。
測試用例應該和 DOM 實現解耦，用的盡量久，能不改就不改。
測試用例應該讓所有人都學得會，寫得通
3. 提高開發效率應該提供方便易用的編寫、測試環境，讓用戶可以輕松上手
需要能夠和常見的 CI 系統集成
我廠的解決方案最后回到我廠。
我們設計了一個全新的語言用來描述 UI，叫做 Navlang。我們可以用它描述各元素的相對位置，操作元素進行交互。
它是一個描述性語言，只包含很簡單的邏輯——實際上 E2E 測試也不需要多復雜的邏輯，跑不通就是掛了，跑通了就沒問題。這樣一來，任何人，只要經過簡單的培訓，都可以寫出正確的測試用例。（HTML 就是最好的例子。前端很多都是頁面仔出身，比如我，相信大家對這類語言的易學易用都有所了解。）
因為是語言，所以它可以寫成代碼，可以被版本管理；因為是新的抽象，所以它不跟 DOM 實現耦合，可以被反復使用，幾乎沒有維護成本。（只有界面變化才需要修改測試用例，此時無論如何都要修改測試用例）
目前這個工具已經在我廠的開發體系中工作將近一年，為我廠產品的穩定做出了非常重大的貢獻。
功能化之外，我們也在作產品化和商品化的努力。目前已經基本完成瀏覽器擴展功能，讓普通用戶可以通過瀏覽器擴展編寫和運行測試。接下來，我們還會提供基于 Node.js 的測試工具框架，幫助大家將測試集成到現有的 CI 系統當中。
未來，這款產品會服務廣大小型公司和小型團隊，幫助大家提升 Web UI 測試的效率。
好了，敬請期待下周的 Navlang 介紹吧。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8944.html
摘要：進行測試之理論是目前很火的一個測試組件，內部綁定了之類的斷言為了讓代碼代碼更有說服力，減少提交測試錯誤，進行測試顯然是非常有必要的。 cypress 進行 e2e 測試之理論 cypress 是目前 e2e 很火的一個測試組件，內部綁定了 macha、chai、chai-jquery 之類的斷言,為了讓代碼代碼更有說服力，減少提交測試錯誤，進行 e2e 測試顯然是非常有必要的。 官網...
摘要：單元測試前端的單元測試目前有兩個比較熱的框架，一個是的方式，一個是。小伙伴們不用急，關于單元測試這塊，我會找時間寫博客的。首先前端的測試分為兩種，一個是單元測試，另一個就是測試了。? ? ? ? 因為公司項目要用vue框架，所以會用vue-cli來新建項目。用過vue的都知道，要全局安裝vue以及腳手架vue-cli，然后執行vue init webpack projectname來新建vu...
摘要：約定我們假定要被測試的頁面是這樣的標題開始編寫測試首先是導入。我們推薦使用的語法當然您也可以用方式第一件事是構造一個實例然后要轉到要被測試的頁面。 之前我曾經在《Rize - 一個可以讓你簡單、優雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當時僅僅是介紹這個庫本身，關于如何使用，我沒有給太多的指導。 這篇文章講的是如何使用 Rize 來做 U...
摘要：約定我們假定要被測試的頁面是這樣的標題開始編寫測試首先是導入。我們推薦使用的語法當然您也可以用方式第一件事是構造一個實例然后要轉到要被測試的頁面。 之前我曾經在《Rize - 一個可以讓你簡單、優雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當時僅僅是介紹這個庫本身，關于如何使用，我沒有給太多的指導。 這篇文章講的是如何使用 Rize 來做 U...
摘要：約定我們假定要被測試的頁面是這樣的標題開始編寫測試首先是導入。我們推薦使用的語法當然您也可以用方式第一件事是構造一個實例然后要轉到要被測試的頁面。 之前我曾經在《Rize - 一個可以讓你簡單、優雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當時僅僅是介紹這個庫本身，關于如何使用，我沒有給太多的指導。 這篇文章講的是如何使用 Rize 來做 U...
閱讀 1926·2021-11-24 09:39
閱讀 3515·2021-09-28 09:36
閱讀 3282·2021-09-06 15:10
閱讀 3433·2019-08-30 15:44
閱讀 1153·2019-08-30 15:43
閱讀 1797·2019-08-30 14:20
閱讀 2712·2019-08-30 12:51
閱讀 2031·2019-08-30 11:04
