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