1. 當(dāng)“e2e”只剩一個(gè)詞我面對的空輸入困局拿到這個(gè)題目的時(shí)候我盯著屏幕愣了幾秒。項(xiàng)目標(biāo)題只有三個(gè)字符——“e2e”正文空白關(guān)鍵詞空白摘要描述也是空白。這大概是做內(nèi)容拆解最極端的一種情況除了一個(gè)縮寫什么都沒有。但恰恰是這種“什么都沒有”的狀態(tài)反而逼著我把這個(gè)詞本身吃透。因?yàn)樵趯?shí)際工作中我們經(jīng)常會(huì)遇到類似的場景——需求方甩過來一個(gè)詞剩下的全靠你自己補(bǔ)全上下文?！癳2e”在技術(shù)圈里最常見的含義是end-to-end也就是“端到端”。這個(gè)詞最早在通信領(lǐng)域被廣泛使用指的是從發(fā)送端到接收端之間完整的數(shù)據(jù)傳輸鏈路中間不經(jīng)過任何協(xié)議轉(zhuǎn)換或中轉(zhuǎn)處理。后來這個(gè)概念被軟件工程、測試、機(jī)器學(xué)習(xí)、產(chǎn)品設(shè)計(jì)等多個(gè)領(lǐng)域借用衍生出了端到端測試、端到端加密、端到端流程、端到端模型等一系列用法。如果你是在一個(gè)技術(shù)團(tuán)隊(duì)里看到這個(gè)詞大概率它指的是端到端測試如果你是在產(chǎn)品文檔里看到它可能指的是端到端業(yè)務(wù)流程如果你是在AI相關(guān)的語境里看到它那很可能是端到端學(xué)習(xí)。我之所以要花篇幅把這個(gè)詞的多義性講清楚是因?yàn)榭蛰斎氡旧砭褪且环N信息。當(dāng)一個(gè)人只給你一個(gè)縮寫而不給任何上下文時(shí)說明這個(gè)詞在他的認(rèn)知里已經(jīng)是一個(gè)不需要解釋的共識(shí)。你要做的不是去問他“你什么意思”而是把這個(gè)詞在所有可能語境下的含義都梳理一遍然后判斷哪個(gè)最可能是他真正想聊的。這篇博文我就按“端到端測試”這個(gè)最主流的方向來展開同時(shí)也會(huì)覆蓋端到端思維在其他領(lǐng)域的應(yīng)用因?yàn)檫@三個(gè)字背后的方法論價(jià)值遠(yuǎn)不止測試這一個(gè)場景。適合讀這篇內(nèi)容的人大概有三類一是剛接觸端到端測試、不知道從哪里下手的新人二是團(tuán)隊(duì)里被安排去搭建e2e測試體系、但之前只寫過單元測試的開發(fā)者三是對“端到端”這個(gè)概念本身感興趣、想搞清楚它到底解決什么問題的人。不管你是哪一類我都會(huì)從最基礎(chǔ)的概念講起然后一步步深入到實(shí)操細(xì)節(jié)和踩坑經(jīng)驗(yàn)盡量讓每個(gè)階段的人都能拿到對自己有用的東西。2. 端到端測試到底在測什么從單元測試的盲區(qū)說起2.1 單元測試覆蓋不到的那片灰色地帶很多人第一次聽到“端到端測試”的時(shí)候第一反應(yīng)是“不就是測試嗎有什么區(qū)別”。區(qū)別大了。單元測試測的是一個(gè)函數(shù)、一個(gè)類、一個(gè)模塊它假設(shè)外部依賴都是正常的只驗(yàn)證內(nèi)部邏輯對不對。集成測試測的是幾個(gè)模塊拼在一起能不能正常工作但它通常還是會(huì)mock掉一些外部服務(wù)。而端到端測試顧名思義是把整個(gè)系統(tǒng)當(dāng)成一個(gè)黑盒從用戶發(fā)起請求開始到系統(tǒng)返回結(jié)果為止中間經(jīng)過的每一個(gè)環(huán)節(jié)——前端渲染、網(wǎng)絡(luò)請求、網(wǎng)關(guān)路由、業(yè)務(wù)邏輯、數(shù)據(jù)庫讀寫、緩存命中、消息隊(duì)列——全部走真實(shí)鏈路不做任何mock。我舉個(gè)具體的例子你就明白了。假設(shè)你做了一個(gè)電商下單功能單元測試會(huì)驗(yàn)證“計(jì)算訂單金額的函數(shù)在輸入三個(gè)商品時(shí)返回的總額是否正確”集成測試會(huì)驗(yàn)證“訂單服務(wù)調(diào)用庫存服務(wù)扣減庫存的接口是否返回成功”但端到端測試要驗(yàn)證的是一個(gè)真實(shí)用戶打開App搜索商品加入購物車點(diǎn)擊結(jié)算選擇地址確認(rèn)支付最后收到下單成功的提示并且數(shù)據(jù)庫里確實(shí)多了一條訂單記錄庫存也確實(shí)減少了。這中間任何一個(gè)環(huán)節(jié)出問題端到端測試都會(huì)失敗。這就是端到端測試的核心價(jià)值它測的不是某個(gè)零件好不好而是整臺(tái)機(jī)器能不能跑起來。單元測試全綠不代表系統(tǒng)能用這個(gè)道理在無數(shù)個(gè)項(xiàng)目里被反復(fù)驗(yàn)證過。我見過太多團(tuán)隊(duì)單元測試覆蓋率90%以上結(jié)果一上線用戶連登錄都登不進(jìn)去因?yàn)榈卿浗涌诘木W(wǎng)關(guān)配置寫錯(cuò)了而單元測試根本不經(jīng)過網(wǎng)關(guān)。2.2 端到端測試的邊界它不負(fù)責(zé)什么搞清楚端到端測試能做什么很重要但搞清楚它不做什么同樣重要。端到端測試不是萬能的它有幾個(gè)天然的邊界。第一它不負(fù)責(zé)驗(yàn)證代碼分支的覆蓋率。一個(gè)端到端測試用例可能走了主流程但代碼里那些異常分支、邊界條件、錯(cuò)誤處理邏輯它不一定能覆蓋到。這些是單元測試的活。第二它不負(fù)責(zé)性能驗(yàn)證。端到端測試關(guān)注的是功能是否正確不是響應(yīng)時(shí)間是否達(dá)標(biāo)。雖然你可以在端到端測試?yán)锛右恍r(shí)間斷言但真正的性能測試需要專門的工具和場景。第三它不負(fù)責(zé)安全測試。端到端測試可以驗(yàn)證權(quán)限控制是否生效但SQL注入、XSS、CSRF這些安全漏洞需要專門的安全測試手段。我經(jīng)常跟團(tuán)隊(duì)里的人說端到端測試的定位是驗(yàn)收層的守門員它站在最外層確保用戶能完成核心業(yè)務(wù)操作。它不追求覆蓋所有代碼路徑而是追求覆蓋所有關(guān)鍵用戶旅程。一個(gè)設(shè)計(jì)良好的端到端測試套件應(yīng)該能在十分鐘內(nèi)告訴你“系統(tǒng)的主流程是不是通的”而不是花兩個(gè)小時(shí)跑完所有邊角場景。2.3 端到端思維在其他領(lǐng)域的映射“端到端”這個(gè)詞之所以能跨領(lǐng)域流行是因?yàn)樗澈笥幸环N通用的思維方式從起點(diǎn)到終點(diǎn)不遺漏任何中間環(huán)節(jié)。這種思維在測試領(lǐng)域叫端到端測試在機(jī)器學(xué)習(xí)領(lǐng)域叫端到端學(xué)習(xí)在產(chǎn)品領(lǐng)域叫端到端流程在安全領(lǐng)域叫端到端加密。端到端學(xué)習(xí)的核心思想是不再把任務(wù)拆成多個(gè)獨(dú)立的模塊分別訓(xùn)練而是用一個(gè)模型直接從輸入映射到輸出。比如語音識(shí)別傳統(tǒng)做法是“音頻特征提取→音素識(shí)別→語言模型→文本輸出”端到端做法是“音頻輸入→神經(jīng)網(wǎng)絡(luò)→文本輸出”中間不需要人工設(shè)計(jì)特征和中間表示。這種思路的優(yōu)勢是減少了模塊間的誤差累積但代價(jià)是需要更多的數(shù)據(jù)和算力。端到端流程指的是從用戶發(fā)起需求到需求被滿足的完整鏈路中間不經(jīng)過人工轉(zhuǎn)接或系統(tǒng)切換。比如用戶提交一個(gè)工單系統(tǒng)自動(dòng)分派、自動(dòng)處理、自動(dòng)通知結(jié)果全程不需要人工介入這就是一個(gè)端到端的流程。端到端加密指的是數(shù)據(jù)在發(fā)送端加密、在接收端解密中間經(jīng)過的任何節(jié)點(diǎn)都無法解密內(nèi)容。你會(huì)發(fā)現(xiàn)這些不同領(lǐng)域的“端到端”都有一個(gè)共同點(diǎn)強(qiáng)調(diào)完整性、強(qiáng)調(diào)不中斷、強(qiáng)調(diào)從源頭到終點(diǎn)的全鏈路負(fù)責(zé)。理解了這一點(diǎn)你就能把端到端思維應(yīng)用到自己的工作中不管你是做測試、做產(chǎn)品還是做運(yùn)維。3. 搭建端到端測試體系從工具選型到第一個(gè)用例跑通3.1 工具選型別一上來就選最重的端到端測試的工具生態(tài)非常豐富從輕量級的HTTP客戶端到重量級的瀏覽器自動(dòng)化框架選擇很多。我見過不少團(tuán)隊(duì)一上來就選最重的方案結(jié)果維護(hù)成本高得嚇人最后測試套件變成沒人敢動(dòng)的祖?zhèn)鞔a。選型的原則應(yīng)該是從實(shí)際需求出發(fā)從輕到重逐步演進(jìn)。如果你的系統(tǒng)主要是API服務(wù)沒有復(fù)雜的前端交互那用HTTP客戶端直接調(diào)接口就夠了。Python的requests、Java的RestAssured、JavaScript的axios都可以配合pytest、JUnit、Jest這些測試框架寫起來很快跑起來也快。這種方案的優(yōu)勢是穩(wěn)定、快、容易調(diào)試缺點(diǎn)是覆蓋不了前端交互。如果你的系統(tǒng)有Web前端需要驗(yàn)證頁面渲染和用戶操作那就需要瀏覽器自動(dòng)化工具。Playwright和Cypress是目前比較主流的選擇。Playwright支持多瀏覽器、多語言API設(shè)計(jì)比較現(xiàn)代Cypress開發(fā)體驗(yàn)好調(diào)試方便但只支持JavaScript且多標(biāo)簽頁場景支持有限。Selenium是老牌方案生態(tài)最成熟但API比較底層寫起來啰嗦等待機(jī)制需要自己處理。如果你的系統(tǒng)是移動(dòng)端App那Appium是繞不開的選擇。它支持iOS和Android可以用同一套API寫測試但環(huán)境配置比較麻煩跑起來也慢。還有一種方案是用各平臺(tái)原生的測試框架比如Android的Espresso、iOS的XCUITest速度快但只能測單平臺(tái)。工具適用場景語言支持學(xué)習(xí)曲線執(zhí)行速度requests/RestAssured純API測試Python/Java/JS低快PlaywrightWeb端到端多語言中中CypressWeb端到端JavaScript低中SeleniumWeb端到端多語言高慢Appium移動(dòng)端多語言高慢我的建議是先用最輕的方案把核心流程跑通等團(tuán)隊(duì)對端到端測試有了感覺再根據(jù)實(shí)際需要引入更重的工具。不要為了“技術(shù)先進(jìn)”而選型要為了“解決問題”而選型。3.2 環(huán)境準(zhǔn)備最容易被低估的環(huán)節(jié)端到端測試和單元測試最大的區(qū)別之一就是它對環(huán)境的依賴度高得多。單元測試可以在本地隨便跑端到端測試需要一個(gè)完整的、可用的系統(tǒng)環(huán)境。這個(gè)環(huán)境包括被測系統(tǒng)的各個(gè)服務(wù)、數(shù)據(jù)庫、緩存、消息隊(duì)列、第三方依賴的mock或沙箱、測試數(shù)據(jù)、網(wǎng)絡(luò)配置。我踩過的最大的坑就是環(huán)境不穩(wěn)定。今天測試跑過了明天同樣的代碼跑不過查了半天發(fā)現(xiàn)是數(shù)據(jù)庫里有一條臟數(shù)據(jù)?；蛘邷y試環(huán)境被人手動(dòng)改了一個(gè)配置導(dǎo)致所有用例全掛。端到端測試的穩(wěn)定性首先取決于環(huán)境的穩(wěn)定性。我的做法是用容器化技術(shù)把整個(gè)測試環(huán)境打包每次跑測試之前重新拉起一套干凈的環(huán)境。Docker Compose適合本地開發(fā)和小規(guī)模測試Kubernetes適合大規(guī)模并行測試。數(shù)據(jù)庫用獨(dú)立的實(shí)例每次測試前清空并灌入固定的種子數(shù)據(jù)。第三方依賴如果沒法用真實(shí)服務(wù)就用mock server模擬確保返回結(jié)果是確定的。還有一個(gè)細(xì)節(jié)測試環(huán)境的網(wǎng)絡(luò)延遲和真實(shí)環(huán)境不一樣。本地跑得好好的到了CI環(huán)境就超時(shí)。所以端到端測試的超時(shí)時(shí)間要設(shè)置得比預(yù)期長一些并且要有重試機(jī)制。但重試不能濫用如果一個(gè)用例經(jīng)常需要重試才能過那說明它本身就不穩(wěn)定應(yīng)該去修它而不是靠重試掩蓋問題。3.3 第一個(gè)用例從登錄開始但別只測登錄寫第一個(gè)端到端用例的時(shí)候大多數(shù)人會(huì)選擇登錄功能。這很合理因?yàn)榈卿浭谴蠖鄶?shù)業(yè)務(wù)系統(tǒng)的入口而且邏輯相對簡單。但我想說的是登錄用例的價(jià)值不在于驗(yàn)證登錄本身而在于驗(yàn)證整個(gè)鏈路的連通性。前端能不能渲染登錄頁、表單提交能不能到達(dá)后端、后端能不能查到用戶、密碼校驗(yàn)邏輯對不對、session能不能正確寫入、登錄后的跳轉(zhuǎn)對不對——這一條鏈路跑通說明系統(tǒng)的基本骨架是好的。寫登錄用例的時(shí)候有幾個(gè)細(xì)節(jié)要注意。第一不要用真實(shí)的用戶賬號(hào)用專門創(chuàng)建的測試賬號(hào)密碼和權(quán)限都是固定的。第二不要依賴驗(yàn)證碼如果系統(tǒng)有驗(yàn)證碼讓開發(fā)在測試環(huán)境提供一個(gè)萬能驗(yàn)證碼或者關(guān)閉驗(yàn)證碼校驗(yàn)。第三登錄后的斷言不要只檢查“頁面跳轉(zhuǎn)了”要檢查“頁面上出現(xiàn)了只有登錄用戶才能看到的內(nèi)容”比如用戶名、頭像、退出按鈕。第四記得寫登出的用例因?yàn)榈浅錾婕皊ession清理和跳轉(zhuǎn)也是容易出問題的地方。登錄用例跑通之后下一步是核心業(yè)務(wù)主流程。比如電商系統(tǒng)就是“搜索→加購→下單→支付”社交系統(tǒng)就是“發(fā)帖→評論→點(diǎn)贊→刪除”。這些主流程用例的數(shù)量不用多但必須覆蓋用戶最常用的操作路徑。我的經(jīng)驗(yàn)是一個(gè)系統(tǒng)的端到端測試套件里主流程用例占30%異常場景用例占40%邊界條件用例占30%這個(gè)比例比較健康。3.4 斷言策略別只斷言HTTP狀態(tài)碼新手寫端到端測試最容易犯的錯(cuò)誤就是斷言寫得太淺。比如調(diào)一個(gè)接口只斷言HTTP狀態(tài)碼是200就認(rèn)為測試通過了。但200只代表請求被正確處理了不代表返回的數(shù)據(jù)是對的?？赡芙涌诜祷亓艘粋€(gè)空列表可能返回了一個(gè)錯(cuò)誤碼在body里可能返回的數(shù)據(jù)結(jié)構(gòu)和預(yù)期完全不一樣。好的斷言應(yīng)該分層。第一層是協(xié)議層HTTP狀態(tài)碼、響應(yīng)頭、Content-Type對不對。第二層是結(jié)構(gòu)層返回的JSON字段名、字段類型、嵌套結(jié)構(gòu)對不對。第三層是業(yè)務(wù)層返回的數(shù)據(jù)值是否符合預(yù)期比如訂單金額是不是等于商品單價(jià)乘以數(shù)量。第四層是狀態(tài)層操作完成后數(shù)據(jù)庫里的數(shù)據(jù)是不是變了緩存是不是更新了消息是不是發(fā)出去了。我一般會(huì)寫一個(gè)斷言輔助函數(shù)把常用的斷言邏輯封裝起來比如assertOrderCreated(orderId, expectedAmount)這樣用例代碼讀起來更清晰維護(hù)起來也方便。斷言失敗的時(shí)候要輸出足夠的信息不能只說“斷言失敗”要說“期望訂單金額是100實(shí)際是99.9”這樣排查問題的時(shí)候能省很多時(shí)間。4. 讓端到端測試真正跑起來CI集成與穩(wěn)定性治理4.1 什么時(shí)候跑觸發(fā)時(shí)機(jī)的選擇端到端測試寫好了接下來要決定什么時(shí)候跑。跑得太頻繁浪費(fèi)資源而且如果環(huán)境不穩(wěn)定頻繁失敗會(huì)讓人麻木跑得太少問題發(fā)現(xiàn)得晚修復(fù)成本高。我的經(jīng)驗(yàn)是分三個(gè)層次。第一個(gè)層次是提交時(shí)觸發(fā)。每次代碼合并到主分支之前跑一遍核心主流程的端到端測試。這個(gè)套件要小、要快最好在五分鐘內(nèi)跑完。它的目的是攔住那些明顯會(huì)破壞主流程的改動(dòng)。第二個(gè)層次是定時(shí)觸發(fā)。每天凌晨跑一遍完整的端到端測試套件包括異常場景和邊界條件。這個(gè)套件可以大一些跑半小時(shí)到一小時(shí)都可以。它的目的是發(fā)現(xiàn)那些不常走但重要的路徑上的問題。第三個(gè)層次是發(fā)布前觸發(fā)。每次準(zhǔn)備發(fā)布新版本之前跑一遍全量端到端測試并且要在和生產(chǎn)環(huán)境盡可能一致的預(yù)發(fā)布環(huán)境里跑。這個(gè)套件要覆蓋所有關(guān)鍵用戶旅程跑完才能發(fā)布。這三個(gè)層次的測試套件不是簡單的包含關(guān)系而是各有側(cè)重。提交時(shí)跑的是“冒煙測試”定時(shí)跑的是“回歸測試”發(fā)布前跑的是“驗(yàn)收測試”。它們的用例可以有重疊但斷言深度和覆蓋范圍不一樣。4.2 失敗分析區(qū)分真失敗和假失敗端到端測試最讓人頭疼的問題就是“假失敗”——代碼沒改環(huán)境沒變但測試就是掛了。假失敗的來源有很多網(wǎng)絡(luò)抖動(dòng)、第三方服務(wù)超時(shí)、數(shù)據(jù)庫連接池耗盡、測試數(shù)據(jù)被其他用例污染、瀏覽器渲染時(shí)機(jī)不確定。如果不加區(qū)分地把所有失敗都當(dāng)成真失敗去查團(tuán)隊(duì)會(huì)被搞得筋疲力盡。我的做法是給每個(gè)失敗用例打標(biāo)簽。第一類是確定性失敗同樣的代碼跑十次掛十次這種是真失敗要立刻查。第二類是間歇性失敗同樣的代碼跑十次掛兩三次這種大概率是環(huán)境或時(shí)序問題要記錄頻率優(yōu)先修那些頻率高的。第三類是環(huán)境性失敗比如數(shù)據(jù)庫連不上、服務(wù)沒起來這種不是測試本身的問題是環(huán)境的問題要修環(huán)境。對于間歇性失敗我一般會(huì)先看失敗時(shí)的截圖和日志。Playwright和Cypress都支持失敗自動(dòng)截圖和錄屏這個(gè)功能一定要開。很多時(shí)候看一眼截圖就知道問題在哪——比如頁面還沒加載完就開始點(diǎn)按鈕了或者彈了一個(gè)意料之外的提示框擋住了操作。這類問題的修復(fù)方式通常是加等待條件但等待條件要加得聰明不能無腦sleep(5)要用“等待某個(gè)元素出現(xiàn)”或“等待某個(gè)網(wǎng)絡(luò)請求完成”這種條件等待。4.3 測試數(shù)據(jù)管理別讓臟數(shù)據(jù)毀了一切端到端測試的數(shù)據(jù)管理是一個(gè)容易被忽視但極其重要的環(huán)節(jié)。如果測試數(shù)據(jù)不干凈用例之間會(huì)互相干擾導(dǎo)致莫名其妙的失敗。比如用例A創(chuàng)建了一個(gè)用戶用例B也創(chuàng)建了一個(gè)同名用戶結(jié)果用例B因?yàn)槲ㄒ患s束失敗了?；蛘哂美鼳刪除了某個(gè)商品用例B還在用這個(gè)商品下單結(jié)果下單失敗。我的做法是每個(gè)用例自己創(chuàng)建自己需要的數(shù)據(jù)用完自己清理。不要依賴全局的種子數(shù)據(jù)因?yàn)槿謹(jǐn)?shù)據(jù)一旦被某個(gè)用例改了其他用例就遭殃了。創(chuàng)建數(shù)據(jù)的時(shí)候用帶隨機(jī)后綴的標(biāo)識(shí)符比如test_user_${timestamp}_${random}避免命名沖突。清理數(shù)據(jù)的時(shí)候放在用例的teardown階段即使用例失敗了也要執(zhí)行清理。如果有些數(shù)據(jù)創(chuàng)建成本很高比如需要走審批流程才能創(chuàng)建的數(shù)據(jù)那可以用“數(shù)據(jù)池”的方式預(yù)先創(chuàng)建一批數(shù)據(jù)用例從池子里取用完還回去。但這種方式要小心并發(fā)問題多個(gè)用例同時(shí)取數(shù)據(jù)的時(shí)候要加鎖或者用隊(duì)列。還有一個(gè)技巧在測試環(huán)境里給測試數(shù)據(jù)打上特殊標(biāo)記比如用戶名的前綴是e2e_這樣清理的時(shí)候可以批量刪除不會(huì)誤刪人工創(chuàng)建的數(shù)據(jù)。4.4 并行執(zhí)行快是王道但別犧牲穩(wěn)定端到端測試跑得慢是一個(gè)普遍問題。一個(gè)完整的套件跑一兩個(gè)小時(shí)是常事如果每次提交都跑這么久開發(fā)體驗(yàn)會(huì)很差。并行執(zhí)行是提速的主要手段但并行會(huì)帶來新的問題資源競爭、數(shù)據(jù)沖突、端口占用。我的經(jīng)驗(yàn)是并行粒度要控制好。如果用例之間完全獨(dú)立可以按用例并行如果用例之間有依賴可以按測試文件并行如果測試文件之間也有依賴那就只能串行。Playwright和Cypress都支持并行執(zhí)行配置起來也不復(fù)雜但前提是用例本身是獨(dú)立的。并行執(zhí)行的時(shí)候每個(gè)worker要有自己獨(dú)立的數(shù)據(jù)庫schema或者獨(dú)立的測試數(shù)據(jù)命名空間。比如worker1用test_db_1worker2用test_db_2互不干擾。端口也要?jiǎng)討B(tài)分配不要寫死。如果被測系統(tǒng)有單點(diǎn)限制比如某個(gè)服務(wù)只能同時(shí)處理一個(gè)請求那并行度就不能超過這個(gè)限制。我一般會(huì)先串行跑一遍確認(rèn)所有用例都是穩(wěn)定的然后再開并行。并行之后如果出現(xiàn)新的失敗優(yōu)先懷疑是并行導(dǎo)致的數(shù)據(jù)沖突或資源競爭而不是業(yè)務(wù)邏輯問題。5. 端到端測試的常見誤區(qū)與我的踩坑記錄5.1 追求100%覆蓋端到端測試不是越多越好我見過一個(gè)團(tuán)隊(duì)寫了上千個(gè)端到端用例每次跑要三個(gè)小時(shí)而且經(jīng)常掛。他們的目標(biāo)是“端到端測試覆蓋所有功能”結(jié)果就是用例數(shù)量爆炸維護(hù)成本極高而且因?yàn)榕艿锰_發(fā)人員根本不愿意在提交前跑都是等CI掛了才去看。端到端測試的覆蓋目標(biāo)不應(yīng)該是“所有功能”而應(yīng)該是“所有關(guān)鍵用戶旅程”。什么是關(guān)鍵用戶旅程就是用戶為了完成某個(gè)核心目標(biāo)而必須經(jīng)過的路徑。比如電商系統(tǒng)的“下單支付”、社交系統(tǒng)的“發(fā)布內(nèi)容”、SaaS系統(tǒng)的“注冊開通”。這些旅程的數(shù)量通常不多一個(gè)中等規(guī)模的系統(tǒng)也就十幾到幾十個(gè)。把每個(gè)旅程的端到端用例寫扎實(shí)比寫一千個(gè)零散用例有價(jià)值得多。那其他功能怎么測用單元測試和集成測試。端到端測試是金字塔的塔尖不是塔基。塔基應(yīng)該是大量的單元測試中間是集成測試塔尖才是少量的端到端測試。如果倒過來維護(hù)成本會(huì)壓垮團(tuán)隊(duì)。5.2 忽視測試代碼的質(zhì)量測試代碼也是代碼很多團(tuán)隊(duì)把測試代碼當(dāng)成“二等公民”不review、不重構(gòu)、不寫注釋。結(jié)果就是測試代碼越來越亂新人看不懂老人不想改最后變成沒人敢動(dòng)的遺留系統(tǒng)。我踩過這個(gè)坑后來痛定思痛把測試代碼和業(yè)務(wù)代碼同等對待。測試代碼也要有良好的結(jié)構(gòu)。頁面對象模式Page Object Model是Web端到端測試的經(jīng)典模式把頁面元素和操作封裝成類用例代碼只調(diào)用類的方法不直接操作元素。這樣頁面改版的時(shí)候只需要改頁面對象類不需要改所有用例。API測試可以用“請求構(gòu)建器”模式把請求的構(gòu)造和斷言邏輯封裝起來用例代碼只關(guān)心業(yè)務(wù)語義。測試代碼也要有命名規(guī)范。用例名稱要能說明它在測什么比如test_user_can_checkout_with_valid_address而不是test_case_1。變量名要清晰不要用a、b、c這種。注釋要寫清楚為什么這么測而不是測什么。5.3 環(huán)境不一致導(dǎo)致的“在我機(jī)器上是好的”“在我機(jī)器上是好的”這句話在端到端測試?yán)镉绕渲旅Ｒ驗(yàn)槎说蕉藴y試依賴的環(huán)境最復(fù)雜本地環(huán)境和CI環(huán)境的差異最容易暴露問題。我遇到過本地跑得好好的到了CI就掛查了半天發(fā)現(xiàn)是CI環(huán)境的時(shí)區(qū)設(shè)置不一樣導(dǎo)致時(shí)間相關(guān)的斷言失敗。還遇到過本地用的是最新版的ChromeCI用的是舊版某個(gè)CSS選擇器行為不一樣。解決這個(gè)問題的根本方法是環(huán)境即代碼。把測試環(huán)境的配置、依賴版本、瀏覽器版本全部用代碼管理起來本地和CI用同一套配置。Docker鏡像是一個(gè)好方案把測試運(yùn)行器和瀏覽器都打包進(jìn)鏡像本地和CI用同一個(gè)鏡像環(huán)境差異就消除了。如果做不到完全一致至少要把關(guān)鍵依賴的版本鎖定比如瀏覽器版本、數(shù)據(jù)庫版本、Node版本。還有一個(gè)細(xì)節(jié)本地開發(fā)的時(shí)候很多人喜歡用headless模式跑測試覺得快。但headless模式和headed模式的行為有時(shí)候不一樣比如某些CSS動(dòng)畫在headless下不執(zhí)行導(dǎo)致元素位置計(jì)算錯(cuò)誤。我的建議是本地開發(fā)用headed模式調(diào)試CI用headless模式跑但CI的headless配置要和本地的headed配置盡可能一致。5.4 沒有失敗重試和告警機(jī)制端到端測試的失敗率天然比單元測試高因?yàn)橐蕾嚨沫h(huán)節(jié)多。如果沒有重試機(jī)制一個(gè)網(wǎng)絡(luò)抖動(dòng)就會(huì)導(dǎo)致整個(gè)CI失敗然后開發(fā)人員重新跑一遍過了就忽略了。這種“狼來了”的次數(shù)多了真正的失敗也會(huì)被忽略。重試機(jī)制要合理。我一般會(huì)配置最多重試兩次并且只對“間歇性失敗”的用例重試。如果一個(gè)用例連續(xù)三次都失敗那就不再重試直接報(bào)錯(cuò)。重試的時(shí)候要記錄日志方便后續(xù)分析哪些用例經(jīng)常需要重試這些用例就是穩(wěn)定性治理的重點(diǎn)對象。告警機(jī)制也很重要。端到端測試失敗之后要能通知到相關(guān)的開發(fā)人員。通知渠道可以是郵件、即時(shí)通訊工具、或者CI系統(tǒng)的通知。但告警不能太頻繁否則會(huì)被當(dāng)成噪音。我的做法是提交時(shí)觸發(fā)的測試失敗通知到提交者定時(shí)觸發(fā)的測試失敗通知到測試負(fù)責(zé)人發(fā)布前觸發(fā)的測試失敗通知到整個(gè)發(fā)布團(tuán)隊(duì)。6. 從端到端測試到端到端思維一種做事的方法論寫到這里我想把話題拉回到“端到端”這三個(gè)字本身。端到端測試只是端到端思維在軟件測試領(lǐng)域的一個(gè)應(yīng)用。這種思維的核心是對結(jié)果負(fù)責(zé)而不是對過程負(fù)責(zé)。在測試領(lǐng)域端到端測試對“用戶能完成操作”這個(gè)結(jié)果負(fù)責(zé)而不是對“某個(gè)函數(shù)返回了正確值”這個(gè)過程負(fù)責(zé)。在產(chǎn)品領(lǐng)域端到端流程對“用戶需求被滿足”這個(gè)結(jié)果負(fù)責(zé)而不是對“某個(gè)環(huán)節(jié)被處理了”這個(gè)過程負(fù)責(zé)。在運(yùn)維領(lǐng)域端到端監(jiān)控對“服務(wù)可用”這個(gè)結(jié)果負(fù)責(zé)而不是對“某個(gè)指標(biāo)正常”這個(gè)過程負(fù)責(zé)。這種思維方式的價(jià)值在于它能幫你跳出局部視角看到全局。當(dāng)你只關(guān)注一個(gè)函數(shù)的時(shí)候你可能會(huì)寫出很優(yōu)雅的代碼但這個(gè)函數(shù)在整個(gè)鏈路里可能根本不被調(diào)用。當(dāng)你只關(guān)注一個(gè)服務(wù)的時(shí)候你可能會(huì)把它優(yōu)化到極致但這個(gè)服務(wù)可能不是瓶頸。端到端思維逼著你從起點(diǎn)看到終點(diǎn)從用戶看到系統(tǒng)從輸入看到輸出。我在帶團(tuán)隊(duì)的時(shí)候經(jīng)常讓新人做一件事把你負(fù)責(zé)的功能從用戶點(diǎn)擊按鈕開始到用戶看到結(jié)果為止中間經(jīng)過的每一個(gè)環(huán)節(jié)都畫出來。很多人畫到一半就卡住了因?yàn)樗麄儼l(fā)現(xiàn)自己根本不了解上下游的服務(wù)。這個(gè)過程本身就是一種端到端思維的訓(xùn)練。當(dāng)你對整條鏈路都清楚了你寫代碼的時(shí)候就會(huì)知道哪些地方要加日志哪些地方要加監(jiān)控哪些地方要加容錯(cuò)。端到端測試的終極目標(biāo)不是寫出一堆用例而是建立一種對系統(tǒng)完整性的信心。這種信心來自于你知道每一個(gè)關(guān)鍵路徑都被驗(yàn)證過每一個(gè)環(huán)節(jié)都被覆蓋到每一個(gè)失敗都能被快速定位。這種信心是單元測試給不了的也是集成測試給不了的。它只能來自于端到端測試來自于你對整條鏈路的掌控。最后分享一個(gè)我自己的小習(xí)慣每次端到端測試跑完不管成功還是失敗我都會(huì)花兩分鐘看一眼測試報(bào)告里的執(zhí)行時(shí)間。如果某個(gè)用例的執(zhí)行時(shí)間突然變長了即使它通過了我也會(huì)去查一下原因。因?yàn)閳?zhí)行時(shí)間變長往往是性能退化的早期信號(hào)早發(fā)現(xiàn)早處理比等到用戶投訴了再查要輕松得多。這個(gè)習(xí)慣幫我提前發(fā)現(xiàn)過好幾次數(shù)據(jù)庫索引失效和緩存穿透的問題算是端到端測試帶來的額外收益。