為何國內的前端對自動化測試好像不是很看重？

01-19

國外的前端框架也好，工程化工具也好，都有大量的篇幅去闡述自動化測試，就連個人項目都要加入測試，一些自動化測試工具比如mocha也感覺挺火的。為何國內很少有文章闡述這些，實際應用中也感覺用處不大，國內的前端大牛也很少講這方面的內容？是什麼造成了這種錯覺呢？

按照Martin Fowler的敏捷流暢度模型。一個團隊的能力，不僅僅依賴於個人的能力。同時依賴於管理結構。 M神，把團隊分成了4個階段，用到持續集成（包括自動化測試）的團隊，其實屬於3-4星。培養一個這樣的團隊，其實要很久。

Focus on Value 1星專註價值

團隊取得商業成功，開始有商業遠景。 ~ （大多是天使輪的公司）

個人覺得需要1-2年

Deliver Value 2星釋放價值

開始適應市場的節奏，可以規避很多風險（其實就是生成問題解決了，大多數融資到B輪的公司）

個人感覺還需要1-2年

Optimize Value 3星最優化價值

做最優秀的決策~

很多團隊無法到達這個水平

Optimize for System 系統性優化

阿里騰訊這樣的大企業才能達到。

應該說自動化測試是持續集成的一個部分，團隊為什麼要持續集成？是因為需要更快的迭代速度！但什麼樣的團隊有資格追求這樣的迭代速度？ 1. 已經創造價值的團隊 2. 團隊個人技術足夠好

在未來的幾年中——滿足這兩點的團隊數量，在國內會逐漸上升。大家要明白，和美國不同，中國的互聯網是爆髮式出來了。普遍從業人員都很年輕！所以說，不是我們不看重，而是沒有能力。

再說個個人的觀點，比如說那些培訓學校出來的人，幾年之後可以掌握自動化測試技術？個人覺得要5-10年。而什麼時候前端興起的？ 2013年後—— 所以，可以推測2018-2023年間，會有大量的人掌握自動化測試技術。

——————

看到很多贊，這裡稍微介紹一下測試。大家會發現react裡面有大量的測試代碼，是在做什麼呢？

說白了，測試就是在證明自己的東西是對的。證明其實是很巧妙的一件事情。但在證明自己是對的之前，還要思考下需不需要被證明?能不能被證明?證明方法對不對？測試的核心就是如此。

更說通俗點，測試一定要大處落墨。不是測試覆蓋率越高越好。

比如說有一個按鈕，我寫樣式是藍色的，我需要寫測試去證明他么? 當然不需要，因為已經顯然，我既然寫了樣式是藍色，那就應該有底層確保顯示是藍色。我再去寫dom測試去證明它是藍色的，價值不大。我不能把精力浪費在這裡。因為還有更重要的事情。

再看一個例子，一個無限輪播圖組件。要測什麼，比如：邊界條件下是否可以工作，就是滑倒最後一頁會不會進入第一頁?在輪播圖非常多的時候有沒有性能問題? 自動播放功能是不是work?我用輪播圖組件構造功能的時候，比如說scrollableTAB，tab如果也有滑動功能會不會和父組件手勢事件衝突?為什麼要測試這些?因為容易出bug。大家要理解其實需要測試的，就是這些容易出問題的地方。然後是如何證明呢？那就要有策略。比如說你模擬滑動事件，然後寫一個掃描器檢查dom。這顯然不是最好的做法，因為這樣證明太辛苦，所以不可行。一種比較可行的做法就是把輪播圖的渲染變成純函數，所以那些手勢,位置都變成了數據。於是操作也變成了純函數。然後我們的測試就很好構造了，其實就是只測模型層數據層。因為我們可以從模型層正確推導出渲染結果的正確。那有人會問，這樣測試覆蓋率就不是100了，因為總歸渲染層沒有覆蓋到啊。是滴啊，誰說測試要覆蓋100呢?渲染層不是做框架的團隊測過的嗎

然後現在解答下react自己測什麼。比如說react花了非常多的代價在測試自己的reconciliation演算法。為什麼測這個?因為這個太難寫，最容易出問題。所以react團隊要巧妙的去證明這個演算法work而且性能沒有問題。另外就是這個演算法迭代太難，如果沒有測試輔助重構都不敢。

UI要不要測試，取決於你們UI會不會出問題。舉個例子，如果你們UI上最會出問題的組件已經測試過了。UI依賴的服務層也測試過了。你難道還要寫程序證明我寫的css對不對嘛？當然不！當然對，這是很顯然的，當然和產品文檔保持了一致，不然我們再做什麼。

然後再說說要不要做UI自動化測試，這個測試是為了證明我們的產品是work的。大家思路一定要開闊，比如說模擬一個用戶去完成主用例，最後對比資料庫中的數據是否正確。這也許都是最笨的方法呢！因為可能還有千千萬萬的思路。因為，人類證明是可以很巧妙的。千萬不要認為自己很笨，大家會發現那些厲害的測試人員肯定是有抓有放的。

還有，有些測試場景也許人做更好。比如說還原設計稿。當然你也可以去對比圖片，但這裡需要一點機器學習的演算法，而且效果很難說了。

最後，沒有太好的證明方法的部分，或者證明代價太大了，建議先不要測試。直到你想到好的方法。把測試當成讓自己需求完成更快的工具，而不是開發的枷鎖。

給自己的專欄打個廣告，剛好有一篇文章介紹github測試覆蓋率工具

聊聊GITHUB上的那些小工具（一）

如果你偏要問「國內」，那是因為沒有人能夠把這東西和業務掛鉤，賣給老闆賣個好價錢。

有些事情不全看技術好還是不好，還要看買單的人願不願意。前端沒測試出了問題誰買單？前端要做測試又誰買單？如果都是工程師自己買單，那顯而易見每一個人都對自己的代碼特別自信而且都不願意寫測試。

你必須要能說服老闆，讓他明白出了問題對業務有多大的影響，讓他覺得做好測試能夠提升業務，最終讓他願意買單。只要老闆願意買單，他可以說「誰做好測試提升業務質量誰升官發財」，前端測試這件事情就能做好。

自動化測試的重點不是實現自動化測試或者把它加入到開發上線流程中，而是要對用例做收集管理，藉助豐富的用例來保證代碼質量。

而用例的收集管理是否可以成功，取決於業務是否穩定可預測。

現階段國內的IT行業還處於高速增長期，業務善變不穩定。尤其是UI的變化更是頻繁。此時收集管理用例成了西西弗斯的懲罰，消耗人力不說，還無法用來保證代碼質量。

對於與業務無關的底層框架、庫來說，自動化測試一直是存在的。但正如他們所處的位置，相對公司範圍，只會是小範圍小團隊對其它有依賴，難以擴大影響，在頻繁變更的業務線也無法推廣。

所以，我想，等高速增長期結束了，業務趨於穩定後，它才有可能被普遍重視吧。

前端變化快，UI 測試維護成本高，不一定會覆蓋全部，一般也就類庫組件，現在 vue react angular 都有相應的測試支持了。

我們 UC 有個小組前幾年也做了一個海豚，用來做半自動化的 UI 回歸測試，主要是抓頁面做基線 diff 後通知人工檢測，現在也在維護期了。

Node 的話，稍微正式一點的開源項目都有測試吧，像我們的庫覆蓋率就要求在 95% 以上，大部分都做到 100% 了。

沒出來講的原因，估計就像賀老說的，前幾年有一些，最近都沒啥新東西吧，就是 mocha, jest, ava 這些。當然，也可能是大牛們知道大家苦逼沒時間測試，講了也是浪費口水。

正常流程：前期投入資源測試 / 提高長期平均勞動效率 / 減少出事概率 / 員工在相同的時間可以做更多的事情 / 降低企業成本

國內互聯網行業：出事？加班就好了，反正是免費的 / 降低企業成本

美劇《矽谷》裡面有句振聾發聵的話，我回憶好像是

"What? You didn"t let users do the QA for you?"

首先，mocha 不是一個自動化測試工具，mocha 完成的工作應該歸入單元測試。單元測試寫不寫要看開發團隊的決策，我的意見是組件和庫必須寫而且強調覆蓋率，業務層就不強求了。

第二，我寫單元測試，我們的測試同學也寫介面測試，一直沒什麼問題。但是前端自動化測試這一步，確實一直有問題。最近測試又找到我，說這個事情，就是 react 寫的項目，用他們現有的自動化測試工具很難方便的定位可操作元素。我稍微研究了一下，還真是這樣。

不用 xpath 定位吧，因為基於 react 的組件庫基本上已經不用原始的標籤了，一個 Button 裡面其實有一大堆 dom 節點，也不好像原來直接寫 html 模板一樣直接拿業務 class 讓測試 select（就是那些j-打頭的 class）。

用 xpath 定位吧，自動化腳本是可以寫出來的，但是我們的項目現在沒有穩定下來，網頁稍微改改，用例掛一大片。測試光改用例都要累死了。

確實挺頭疼的。

我諮詢了一下目前正在使用自動化測試的團隊，發現他們真的在一遍一遍地改用例。

累不累啊……

只是最近一兩年這方面的分享比較少吧，大概是沒啥新東西好講了。之前我印象里聽過很多次，從單元測試到UI（端到端）測試都有。

自動化測試不少吧，少的是E2E測試。

根據測試金字塔和谷歌70/20/10原則，你的E2E測試必須基於有良好的單測和結合測試基礎上再搞才有意義。

可以捫心自問自己的團隊的單測真的持續集成起來了嗎？

沒有讓驢拉一個通宵拉不完的磨。

如果有，再加一個通宵。

我回答一下我們公司的情況外企對測試很看重在之前百度之類的國內公司大多根本就不強調測試，根本就沒怎麼寫過。

前端 unit test 覆蓋率必須達到 80%，否則就沒有達到Acceptance criteria，功能不能上線對於 angular 來說主要是寫 controller 和 directive 的測試，對於 React 來說，各種 component 都要寫（stateless 和 container），還有 Reducer 的測試也很重要。

E2E 也針對每個 feature 有很多 cases，主要是 protractor 寫的。每次 commit 都會觸發 jenkins 跑一遍測試。

後來換了老闆又提出來一項規定，『你怎麼保證你修改的 bug 以後不出 regression『，那就是每次bug 修改都要有相應的 unit test 覆蓋（如果能寫的話），這確實費時費力，有時候改了一行代碼，寫 test 的代碼量是修改代碼的好幾倍。

當我慢慢習慣了這種規則，發現 regression 的概率比原來低了很多，對自己的代碼功能也更有信心，對開發是大有裨益的。當然缺點就是費時間，當你提交了新的代碼，就要祈禱不要有原來的 UT 和 E2E 失敗。

我懷疑很多答主，都沒有真正地在項目上寫過測試。

一般情況下，我理解的自動化測試是指 UI 自動化測試。作為一個在前端項目里寫 UI 自動化測試的前端，我表示國內的資料很少。畢竟大部分前端，都不會考慮 UI 自動化測試。

至於單元測試，是我司對於項目的基本要求，其用於作為交付質量的保證——你懂的。

說說我們當前的項目（差不多接近兩年的歷史了，對於這樣的系統穩定性更重要），在上半年裡，採用的是 Protractor 來測試 Angular.js 做的前端項目。

而最近，則是開始使用 Gauge，與測試人員、業務人員一起寫 BDD。我們遇到的主要問題是，有一些常見的業務功能經常出問題。而這些問題，不能使用單元測試的完美解決。比如說，在項目上採用了類似於微前端的架構，這導致了很多跨組件的功能，不能使用單元測試解決。

Gauge 的優點在於使用 Markdown 編寫業務代碼。原本打算結合 Google 的 Puppeteer 與 Chrome 一起做，但是由於用戶主要使用的瀏覽器是 IE，所以就繼續用 Selenium 作為底層驅動。

Puppeteer 的 API 使用起來比 selenium-webdriver 更加方便。

然後，先讓簡單地介紹一下測試。要理解測試，最簡單的就是測試金字塔：

對應的即：

單元測試。
服務測試
UI 自動化測試

從圖中我們可以發現：單元測試應該要是最多的，也是最底層的。其次才是服務測試，最後才是 UI 自動化測試。

大量的單元測試可以保證我們的基礎函數是正常、正確工作的。而服務測試則是一門很有學問的測試，不僅僅只在測試我們自己提供的服務，也會測試我們依賴第三方提供的服務。在測試第三方提供的服務時，這就會變成一件有意思的事了。除此還有對功能和 UI 自動化測試，寫這些測試可以減輕測試人員的工作量——畢竟這些工作量轉向了開發人員來完成。

除此，在開源電子書《Growth: 全棧增長工程師指南》中，提到了 UI 測試的幾點問題：

從運行測試速度上來看，三種測試的運行速度是呈倒金字塔結構。即，單元測試跑得最快，開發速度也越快。隨後是服務測試，最後是 UI 自動化測試。
即使現在的 UI 自動化測試跑得非常快，但是隨著時間的推移，UI 自動化測試會越來越多。這也意味著測試來跑得越來越久，那麼人們就開始不想測試了。在我們之前的項目里，運行完所有的測試大概接近一個小時，我們開始在會議會爭論這些測試的必要性，也在想方設法減少這些測試。
如果一個測試可以在最底層寫，那麼就不要在他的上一層寫了，因為他的運行速度更快。

前端變化太快，測試比後端複雜點，總之，成本偏高

最近的工作跟測試杠上了。去年先是用jasmine作了個前端的單元測試組件，現在勉強做到持續集成，每次commit都會在jenkins上用phantomjs自動跑一遍所有的單元測試，如果有fail就發郵件到developer（因為一些奇怪的需求沒有用現成的karma等測試框架）。

大概長這樣：

然後又由於公司的項目要求，用selenium和appium搭了一個端到端測試的框架（java-client），對我們的hybrid app在ios android和windows平台進行測試。代碼大概長這樣

說幾點前端自動化測試的潛在缺點吧。

1.成本高

特別是端到端的測試的成本非常高。需要測試工程師和開發工程師協作才能完成端到端測試用例。並且一個UI上的小修改，都可能會fail掉多個用例，並且這些用例改起來並不簡單。經常會發生這種情況，修改代碼只花了1小時而修改用例花了一天。

在目前國內的測試人員成本還較低的情況下，用手動測試人員的時間換開發者的時間顯然是一個更經濟實惠的選擇

2.測試框架不穩定

這個有可能是測試框架選擇的問題，但是我目前確實還沒看到什麼成熟穩定的框架。這個問題從github上selenium和appium的issue數就可見端倪，經常會有一些莫名其妙的問題發生在不同的設備上，並且由於種種原因非常難復現。

3.覆蓋率低

在實際的開發過程中，總會發現一些東西因為種種的原因沒法進行自動化測試（比如傳說中的用戶體驗，手感，動畫效果等），就導致了在交付之前還是必須由測試人員手動測試過。

另外國內的產品環境趨於浮躁，對於前端這種變化極快的領域很難有足夠的時間來花上3個月半年去寫一套完整的測試。

說不定測試還沒寫完，老闆產品經理一拍腦袋UI就得重做了。

國內的前端框架和工具，雖然有一些很優秀的，但是從整體數量和質量上，感覺上(沒調查過，僅僅是日常接觸的感受)，不如國外。自動化測試一個很重要的目的是保障後期迭代和維護，而一些面向KPI的框架和工具，自然就不那麼看重，更不用說要求快速上線，但生命周期可能連一年都不到的應用了。

首先分成單元測試和端到端自動化測試。

單元測試是這樣的：很多人不願意做。不僅前端後端不太願意寫單元測試，自動化測試人員、測試工具開發人員被要求寫單元測試時也是不情願的。在之前的公司有一次我們組做一個測試工具（這工具本身也包括前端後端），連這個測試開發組的領導也明確表示單元測試可以先不做。然後各種bug，他想在這裡壓一下時間加快進度，最終反而拖慢進度。就這還是在一個很重視質量和測試的公司里測試開發發展水平較高的部門。

如果管理層要求很嚴，開發會去搞前端的單元測試的，要求不嚴或者只有測試在提單元測試，開發或者甚至是測試自己也會嘗試偷懶和糊弄說「這個測不了」。

然後端到端的自動化測試的事情，就是測試人員的事情了，前端很少來管這塊。（這就是最大的問題。換了一個人做測試導致原作者寫代碼時不考慮可測性）於是，頁面一變，測試重寫。

有次測試的qq群里有人問，為啥他測的頁面里有些他要操作的頁面元素沒有id，沒有name，就是一個光禿禿的標籤。然後大家各種出謀劃策……最後讓他寫xpath去了。那個提問人說，他們的前端跟她說，用了一個什麼前端的庫寫出來的頁面代碼就是這樣的。她也不懂前端，不知道到底是那個庫真這樣，還是開發在糊弄她。其他類似問題還有「多層嵌套的iframe」，「不知道怎麼操作的小控制項」，「頁面變太快，腳本來不及維護怎麼辦」等等，這類問題每天在測試的qq群里要被人問一遍。

總之很多頁面的可測試性真的很低，寫個測試腳本要花大力氣，再加上需求又老改，簡直是火上澆油。

最終，導致像這種基於前端界面搞的端到端自動化測試，很少有很成功的（然而還是很多單位搞這種自動化測試）。

小公司，一個人，工期短，需求總是變，還自動化測試？

作為一個前端，基本沒怎麼寫過測試（捂臉）

說幾個理由（借口）吧：

沒時間寫測試：有時間肯定就去做其他開發任務了。
不會寫測試：前端開發者還是基礎差些吧，測試這種選學內容會的人就比較少，然後很難在公司內推廣。。
測試不好寫：以前看過一點粗淺的測試相關的東西，感覺 ui 的測試要比後端難寫不少。
能解決的問題有限：因為存在用戶交互，感覺不會像後端測試那樣的高覆蓋率。而且寫出來不一定能保證都覆蓋到。還不如給 QA 去測。如果純處理邏輯的 js 代碼其實寫起來也是不難的。

E2E的測試現在越來越少了，因為維護成本太高了，但是組件級別的測試還是要寫的。

產品：自動化測試？能保證我的需求快速上線嗎？什麼？不行？那我不管，我必須明天上線。