資訊專欄INFORMATION COLUMN
摘要：與單元測試不同，后者通常需要測試參數(shù)參數(shù)類型參數(shù)值參數(shù)數(shù)量返回值拋出錯誤等，目的在于保證特定函數(shù)能夠在任何情況下都穩(wěn)定可靠完成工作。單元測試假定只要所有函數(shù)都正常工作，那么整個產(chǎn)品就能正常工作。
上一篇文章發(fā)布后，竟然收獲到一些同學(xué)的注意，實(shí)在是意外之喜。不過我也發(fā)現(xiàn)，很多同學(xué)對 E2E 測試不夠了解，正好我廠的產(chǎn)品也沒做到能作為商用版發(fā)布的程度，所以這篇再來聊聊 E2E 測試吧。本文的測試均指自動化測試。
E2E，是“End to End”的縮寫，可以翻譯成“端到端”測試。它模仿用戶，從某個入口開始，逐步執(zhí)行操作，直到完成某項工作。與單元測試不同，后者通常需要測試參數(shù)、參數(shù)類型、參數(shù)值、參數(shù)數(shù)量、返回值、拋出錯誤等，目的在于保證特定函數(shù)能夠在任何情況下都穩(wěn)定可靠完成工作。單元測試假定只要所有函數(shù)都正常工作，那么整個產(chǎn)品就能正常工作。
相對來說，E2E 測試并沒有那么強(qiáng)調(diào)要覆蓋全部使用場景，它關(guān)注的是 一個完整的操作鏈?zhǔn)欠衲軌蛲瓿?/strong>。對于 Web 前端來說，還關(guān)注 界面布局、內(nèi)容信息是否符合預(yù)期。
比如，登陸界面的 E2E 測試，關(guān)注用戶是否能夠正常輸入，正常登錄；登陸失敗的話，是否能夠正確顯示錯誤信息。至于輸入不合法的內(nèi)容是否處理，沒有很大的關(guān)系。
Web 前端 E2E 測試的現(xiàn)狀Web 前端 E2E 自動化測試開展得不好。在我從業(yè)的這十幾年里，大部分產(chǎn)品的前端 E2E 測試都交給測試人員手工完成。我們稍稍分析一下，大概有三個原因：
1. 測試環(huán)境不好搭單元測試也好、接口測試也好，測試環(huán)境都很容易搭建。然而 Web 前端測試如果想達(dá)到目的，需要完整的桌面操作系統(tǒng)和瀏覽器環(huán)境，這種面向普通用戶的軟件對自動化工具并不友好。對系統(tǒng)要求也比較高，很難整合到開發(fā)測試工具鏈檔中。
解決方案當(dāng)然是有的，目前最流行的應(yīng)該是 Selenium WebDriver。不過對于小公司、小團(tuán)隊來說，在并不豐富的資料中摸著石頭過河實(shí)在不夠經(jīng)濟(jì)，而且，還有接下來的兩個問題。
2. 測試不好寫。目前的 Web 前端 E2E 測試工具局限于 XPath 技術(shù)棧。大家用選擇器查找 DOM 節(jié)點(diǎn)，校驗(yàn)其屬性和內(nèi)容，接著進(jìn)行交互。這樣做導(dǎo)致一個必然后果：寫測試的人員對頁面的 DOM 結(jié)構(gòu)必須了如指掌，才能用準(zhǔn)確目標(biāo)元素。
同時，在這個技術(shù)環(huán)境下寫就的測試用例，一旦 DOM 結(jié)構(gòu)出現(xiàn)變化，就要大規(guī)模的修改，甚至重寫。工作量很大，而且存在一些不穩(wěn)定因素。跟某團(tuán)隊 Leader 聊天，他就很擔(dān)心漫長的迭代過程中，DOM 結(jié)構(gòu)變化導(dǎo)致測試用例失效，繼而引發(fā)項目排期混亂。
結(jié)果，Web 前端 E2E 測試用例的只能由前端用 JS 寫，工作量大，維護(hù)負(fù)擔(dān)重，且存在一些風(fēng)險。大家都不愿意寫。
3. 有些東西不好測隨著用戶對產(chǎn)品的要求水漲船高，頁面邏輯越來越復(fù)雜，功能越發(fā)依賴 Ajax，甚至和后端徹底分離，成為單頁應(yīng)用（SPA）。這類產(chǎn)品與傳統(tǒng)的靜態(tài)頁服務(wù)不同，我們沒法偵聽 DOMReady 事件，也就難以找到合適的時間點(diǎn)啟動測試。
早些時候，我們只能依靠 setInterval() 輪詢。如今，通過 Puppeteer 或者瀏覽器擴(kuò)展都可以監(jiān)聽網(wǎng)絡(luò)連接，可以根據(jù)當(dāng)前保持的連接數(shù)來判斷請求是否完成。
不過這些做法仍然存在不小的實(shí)施難度。
4. 預(yù)期收益一般我跟很多技術(shù)老大聊過。大家的回答都是：沒寫，沒空，招測試。在加班成為常態(tài)的今天，在“看得到”的工作之外，再去做這些“看不到”的工作，實(shí)在有些吃力不討好。另一方面，測試寫得少，覆蓋率跟不上，還是得招測試，人工測試。
惡行循環(huán)就此產(chǎn)生：不想寫導(dǎo)致沒測試；那就招測試人員；有了專職測試我還寫什么測試……所以大家都不寫測試了。
對于中等以上規(guī)模的技術(shù)團(tuán)隊，招幾個測試也還行。對于整個公司就只有幾個人的創(chuàng)業(yè)團(tuán)隊來說，大多數(shù)時候只能裸奔……
更好的 Web 前端 E2E 測試工具行文至此，結(jié)論就很明顯了：我們需要全新的、更高級的 Web 前端 E2E 測試工具。這個工具需要同時滿足：
1. 有效可以準(zhǔn)確地描述 UI 的結(jié)構(gòu)
可以盡量全面的模擬用戶真實(shí)操作
覆蓋多種操作系統(tǒng)、適配各種瀏覽器
2. 使用成本低測試用例應(yīng)該盡量簡短，用最少的代碼描述出 UI，完成交互。
測試用例應(yīng)該和 DOM 實(shí)現(xiàn)解耦，用的盡量久，能不改就不改。
測試用例應(yīng)該讓所有人都學(xué)得會，寫得通
3. 提高開發(fā)效率應(yīng)該提供方便易用的編寫、測試環(huán)境，讓用戶可以輕松上手
需要能夠和常見的 CI 系統(tǒng)集成
我廠的解決方案最后回到我廠。
我們設(shè)計了一個全新的語言用來描述 UI，叫做 Navlang。我們可以用它描述各元素的相對位置，操作元素進(jìn)行交互。
它是一個描述性語言，只包含很簡單的邏輯——實(shí)際上 E2E 測試也不需要多復(fù)雜的邏輯，跑不通就是掛了，跑通了就沒問題。這樣一來，任何人，只要經(jīng)過簡單的培訓(xùn)，都可以寫出正確的測試用例。（HTML 就是最好的例子。前端很多都是頁面仔出身，比如我，相信大家對這類語言的易學(xué)易用都有所了解。）
因?yàn)槭钦Z言，所以它可以寫成代碼，可以被版本管理；因?yàn)槭切碌某橄?，所以它不?DOM 實(shí)現(xiàn)耦合，可以被反復(fù)使用，幾乎沒有維護(hù)成本。（只有界面變化才需要修改測試用例，此時無論如何都要修改測試用例）
目前這個工具已經(jīng)在我廠的開發(fā)體系中工作將近一年，為我廠產(chǎn)品的穩(wěn)定做出了非常重大的貢獻(xiàn)。
功能化之外，我們也在作產(chǎn)品化和商品化的努力。目前已經(jīng)基本完成瀏覽器擴(kuò)展功能，讓普通用戶可以通過瀏覽器擴(kuò)展編寫和運(yùn)行測試。接下來，我們還會提供基于 Node.js 的測試工具框架，幫助大家將測試集成到現(xiàn)有的 CI 系統(tǒng)當(dāng)中。
未來，這款產(chǎn)品會服務(wù)廣大小型公司和小型團(tuán)隊，幫助大家提升 Web UI 測試的效率。
好了，敬請期待下周的 Navlang 介紹吧。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/8944.html
摘要：進(jìn)行測試之理論是目前很火的一個測試組件，內(nèi)部綁定了之類的斷言為了讓代碼代碼更有說服力，減少提交測試錯誤，進(jìn)行測試顯然是非常有必要的。 cypress 進(jìn)行 e2e 測試之理論 cypress 是目前 e2e 很火的一個測試組件，內(nèi)部綁定了 macha、chai、chai-jquery 之類的斷言,為了讓代碼代碼更有說服力，減少提交測試錯誤，進(jìn)行 e2e 測試顯然是非常有必要的。 官網(wǎng)...
摘要：單元測試前端的單元測試目前有兩個比較熱的框架，一個是的方式，一個是。小伙伴們不用急，關(guān)于單元測試這塊，我會找時間寫博客的。首先前端的測試分為兩種，一個是單元測試，另一個就是測試了。? ? ? ? 因?yàn)楣卷椖恳胿ue框架，所以會用vue-cli來新建項目。用過vue的都知道，要全局安裝vue以及腳手架vue-cli，然后執(zhí)行vue init webpack projectname來新建vu...
摘要：約定我們假定要被測試的頁面是這樣的標(biāo)題開始編寫測試首先是導(dǎo)入。我們推薦使用的語法當(dāng)然您也可以用方式第一件事是構(gòu)造一個實(shí)例然后要轉(zhuǎn)到要被測試的頁面。 之前我曾經(jīng)在《Rize - 一個可以讓你簡單、優(yōu)雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當(dāng)時僅僅是介紹這個庫本身，關(guān)于如何使用，我沒有給太多的指導(dǎo)。 這篇文章講的是如何使用 Rize 來做 U...
摘要：約定我們假定要被測試的頁面是這樣的標(biāo)題開始編寫測試首先是導(dǎo)入。我們推薦使用的語法當(dāng)然您也可以用方式第一件事是構(gòu)造一個實(shí)例然后要轉(zhuǎn)到要被測試的頁面。 之前我曾經(jīng)在《Rize - 一個可以讓你簡單、優(yōu)雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當(dāng)時僅僅是介紹這個庫本身，關(guān)于如何使用，我沒有給太多的指導(dǎo)。 這篇文章講的是如何使用 Rize 來做 U...
摘要：約定我們假定要被測試的頁面是這樣的標(biāo)題開始編寫測試首先是導(dǎo)入。我們推薦使用的語法當(dāng)然您也可以用方式第一件事是構(gòu)造一個實(shí)例然后要轉(zhuǎn)到要被測試的頁面。 之前我曾經(jīng)在《Rize - 一個可以讓你簡單、優(yōu)雅地使用 puppeteer 的 Node.js 庫》一文簡單介紹過 Rize 這個庫。當(dāng)時僅僅是介紹這個庫本身，關(guān)于如何使用，我沒有給太多的指導(dǎo)。 這篇文章講的是如何使用 Rize 來做 U...
閱讀 1962·2021-11-24 09:39
閱讀 3542·2021-09-28 09:36
閱讀 3321·2021-09-06 15:10
閱讀 3477·2019-08-30 15:44
閱讀 1176·2019-08-30 15:43
閱讀 1826·2019-08-30 14:20
閱讀 2738·2019-08-30 12:51
閱讀 2059·2019-08-30 11:04
