1. 端到端測(cè)試到底在測(cè)什么先說結(jié)論e2eend-to-end這個(gè)縮寫在我這個(gè)崗位每天都會(huì)出現(xiàn)它不是某個(gè)工具的名字而是一整套測(cè)試思路——把整個(gè)系統(tǒng)當(dāng)成一個(gè)黑盒從用戶視角走完一條完整的業(yè)務(wù)鏈路驗(yàn)證用戶能做的事情系統(tǒng)真的能讓他做成。舉個(gè)最直白的例子。你做一個(gè)電商網(wǎng)站單元測(cè)試只驗(yàn)證購(gòu)物車加一件商品后數(shù)量從0變成1接口測(cè)試只驗(yàn)證POST /cart 返回200。但用戶不會(huì)關(guān)心這些用戶關(guān)心的是打開首頁(yè)、搜商品、點(diǎn)加入購(gòu)物車、去結(jié)算、填地址、付款——這一串動(dòng)作能不能流暢走通。這個(gè)過程里任何一個(gè)環(huán)節(jié)出問題哪怕中間十個(gè)接口都返回正常用戶層面最終就是買不了東西。e2e測(cè)的就是這條完整鏈路。我剛工作那兩年也不太理解為什么要單獨(dú)搞e2e總覺得單元測(cè)試和接口測(cè)試覆蓋率夠了就萬事大吉。后來線上出過一次事故下單接口返回成功但前端跳轉(zhuǎn)支付頁(yè)的時(shí)候因?yàn)橐粋€(gè)字段名對(duì)不上頁(yè)面白屏。接口測(cè)試和單測(cè)全綠用戶就是付不了錢。那次之后我徹底想明白了測(cè)試金字塔再漂亮缺了e2e這層你永遠(yuǎn)不知道拼起來之后系統(tǒng)到底能不能用。這篇文章我用實(shí)際項(xiàng)目里的經(jīng)驗(yàn)把e2e從環(huán)境搭建、用例設(shè)計(jì)、執(zhí)行策略到問題排查完整拆一遍。適合剛接觸e2e的測(cè)試開發(fā)也適合寫了幾年e2e但總覺得用例跑不穩(wěn)的同學(xué)對(duì)照參考。2. 環(huán)境準(zhǔn)備工具選型和profile1配置的來龍去脈2.1 測(cè)試框架選型別盲目追新e2e的工具生態(tài)這幾年變化很快。老牌的Selenium還在但它走的是WebDriver協(xié)議啟動(dòng)瀏覽器、執(zhí)行命令的鏈路很長(zhǎng)跑起來慢而且對(duì)現(xiàn)代前端框架里那種動(dòng)態(tài)DOM的兼容性越來越吃力。Cypress當(dāng)年很火把執(zhí)行環(huán)境從瀏覽器外面挪到瀏覽器內(nèi)部速度確實(shí)快了一個(gè)量級(jí)但它有個(gè)天然的短板只能在Chromium系跑多瀏覽器覆蓋不方便而且它對(duì)多標(biāo)簽頁(yè)、跨域場(chǎng)景支持得很別扭。目前我主推Playwright。它是微軟開源的項(xiàng)目底層走的是CDPChrome DevTools Protocol啟動(dòng)速度和執(zhí)行穩(wěn)定性比Selenium強(qiáng)太多API設(shè)計(jì)上對(duì)等待策略做了內(nèi)置處理能自動(dòng)等元素可見、可點(diǎn)、可操作一個(gè)腳本能同時(shí)控Chromium、Firefox、WebKit三種內(nèi)核對(duì)用戶可能用不同瀏覽器訪問這個(gè)場(chǎng)景覆蓋得最省力。工具選型這件事我不建議糾結(jié)太久記住一個(gè)原則有長(zhǎng)期維護(hù)、社區(qū)活躍、API設(shè)計(jì)符合直覺、能覆蓋你的目標(biāo)瀏覽器。目前Playwright在這幾個(gè)維度上都是最優(yōu)解。2.2 e2e profile1是什么意思很多項(xiàng)目中你都會(huì)看到測(cè)試配置文件帶profile字樣的命名比如profile1其實(shí)就是一套端到端測(cè)試的崗位職責(zé)配置文件。不同項(xiàng)目叫法不太一樣有的叫env有的叫config有的叫profile。核心作用只有一個(gè)把跑哪套環(huán)境、連哪個(gè)服務(wù)、用哪組賬號(hào)、跑哪些用例這些決定測(cè)試行為的參數(shù)從代碼里抽離出來單獨(dú)管理。我習(xí)慣這樣組織profile1對(duì)應(yīng)默認(rèn)的本地開發(fā)和測(cè)試環(huán)境localhost 測(cè)試庫(kù) 測(cè)試賬號(hào)組profile2對(duì)應(yīng)預(yù)發(fā)布環(huán)境staging 預(yù)發(fā)布庫(kù) 隔離賬號(hào)組profile3對(duì)應(yīng)生產(chǎn)驗(yàn)證環(huán)境灰度域名 只讀賬號(hào) 核心鏈路用例這樣做的原因很樸素一套測(cè)試腳本如果能同時(shí)適配多套環(huán)境那它就是可復(fù)用的資產(chǎn)而不是一次性腳本。你想想開發(fā)環(huán)境、測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境本質(zhì)上是同一套業(yè)務(wù)代碼跑在不同配置下沒理由每次換環(huán)境就重寫一遍測(cè)試。2.3 項(xiàng)目目錄結(jié)構(gòu)和基礎(chǔ)配置先看一個(gè)我常用的項(xiàng)目初始化結(jié)構(gòu)e2e-project/ ├── package.json ├── playwright.config.ts ├── profiles/ │ ├── profile1.json │ ├── profile2.json └── tests/ ├── auth.spec.ts ├── order.spec.ts └── payment.spec.tspackage.json里需要裝的東西很少核心就一個(gè)npm init -y npm install -D playwright/test npx playwright installnpx playwright install這條命令會(huì)把三個(gè)內(nèi)核的瀏覽器二進(jìn)制下載到本地這一步在國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下有時(shí)候比較慢建議提前配好鏡像源或者手動(dòng)下載瀏覽器包放到緩存目錄能省不少時(shí)間。然后是配置文件核心部分// playwright.config.ts import { defineConfig, devices } from playwright/test; import profile1 from ./profiles/profile1.json; export default defineConfig({ testDir: ./tests, timeout: 60000, retries: 1, use: { baseURL: profile1.baseURL, trace: retain-on-failure, video: on-first-retry, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, ], });這里最關(guān)鍵的是讀取了profile1.json里的baseURL整個(gè)測(cè)試套件跑哪套環(huán)境完全由profile文件決定改測(cè)試代碼的頻次大大降低。3. 用例設(shè)計(jì)思路從業(yè)務(wù)鏈路反推測(cè)試步驟3.1 用戶旅程優(yōu)先e2e用例設(shè)計(jì)的最大誤區(qū)是照著接口文檔一個(gè)個(gè)點(diǎn)頁(yè)面。真正有效的做法是先從業(yè)務(wù)價(jià)值出發(fā)把用戶最常走的路徑列出來然后逐個(gè)覆蓋。以電商系統(tǒng)為例最高優(yōu)先級(jí)的用戶旅程有幾條登錄 - 搜索商品 - 加購(gòu)物車 - 結(jié)算 - 下單成功登錄 - 領(lǐng)取優(yōu)惠券 - 結(jié)算時(shí)校驗(yàn)價(jià)格 - 支付 - 訂單狀態(tài)更新未登錄 - 瀏覽商品 - 加購(gòu)物車 - 結(jié)算時(shí)引導(dǎo)登錄 - 登錄后訂單鏈路繼續(xù)這三條鏈路的共同點(diǎn)是每一步都依賴上一步成功任一處斷裂用戶行為就終止了。e2e的價(jià)值恰恰在于驗(yàn)證這種連續(xù)依賴。設(shè)計(jì)用例的時(shí)候我習(xí)慣先畫一條業(yè)務(wù)時(shí)序然后確認(rèn)每一步的頁(yè)面入口和斷言點(diǎn)。比如登錄后用戶名出現(xiàn)在頁(yè)面右上角是斷言點(diǎn)搜索結(jié)果的第一個(gè)商品標(biāo)題包含關(guān)鍵詞也是斷言點(diǎn)。斷言點(diǎn)不一定要多但必須要能證明這一步真的成功。3.2 用例數(shù)量控制不是越多越好很多人一上來就寫幾百條e2e用例跑一遍一兩個(gè)小時(shí)結(jié)果每天光排查flaky就花掉半天。e2e用例的定位是核心鏈路守門員不是全功能覆蓋者。全功能覆蓋應(yīng)該由單元測(cè)試和接口測(cè)試去完成。我個(gè)人的經(jīng)驗(yàn)是一個(gè)中等復(fù)雜度的后端系統(tǒng)e2e用例控制在30到50條比較合理。每條用例對(duì)應(yīng)一條關(guān)鍵用戶旅程或者一個(gè)核心業(yè)務(wù)規(guī)則。如果用例數(shù)量超過100條先看看是不是把本該在接口層測(cè)的東西寫到了e2e里。3.3 數(shù)據(jù)準(zhǔn)備與清理策略e2e測(cè)試最頭疼的問題是數(shù)據(jù)。測(cè)試環(huán)境的數(shù)據(jù)總量、污染程度、并發(fā)隔離方式直接決定了用例的穩(wěn)定性。我的做法是優(yōu)先用測(cè)試框架的API造數(shù)據(jù)不要通過UI一步步創(chuàng)建。比如注冊(cè)用戶這個(gè)前置條件直接調(diào)后端的注冊(cè)接口生成賬號(hào)比用UI跑一遍注冊(cè)流程快得多也省去UI注冊(cè)時(shí)的驗(yàn)證碼、短信等干擾。用例之間隔離每個(gè)用例盡量使用獨(dú)立數(shù)據(jù)。比如下單用例每次生成一個(gè)新的隨機(jī)手機(jī)號(hào)作為登錄賬號(hào)避免上一個(gè)用例殘留的訂單數(shù)據(jù)影響下一個(gè)用例。測(cè)試數(shù)據(jù)清理跑完用例后把創(chuàng)建的數(shù)據(jù)在teardown里清理掉。如果清理成本高至少保證測(cè)試數(shù)據(jù)有統(tǒng)一前綴便于定期批量清理。4. 從零寫一條完整的e2e用例4.1 登錄注冊(cè)模塊的e2e實(shí)戰(zhàn)我拿注冊(cè) 登錄這條鏈路來演示完整寫法。注冊(cè)登錄是幾乎所有系統(tǒng)的入口也是e2e里最容易出現(xiàn)理解偏差的模塊——很多人把它當(dāng)兩個(gè)用例寫其實(shí)從用戶視角來看注冊(cè)完之后自動(dòng)登錄這是一條連續(xù)旅程。import { test, expect } from playwright/test; test(新用戶注冊(cè)后自動(dòng)登錄并進(jìn)入首頁(yè), async ({ page }) { // 生成唯一手機(jī)號(hào)保證每次運(yùn)行不會(huì)撞庫(kù) const timestamp Date.now(); const phone 138${String(timestamp).slice(-8)}; const password Test12345; // 打開注冊(cè)頁(yè)面 await page.goto(/register); // 填寫注冊(cè)表單 await page.getByLabel(手機(jī)號(hào)).fill(phone); await page.getByLabel(設(shè)置密碼).fill(password); await page.getByLabel(確認(rèn)密碼).fill(password); // 提交注冊(cè) await page.getByRole(button, { name: 注冊(cè) }).click(); // 關(guān)鍵斷言注冊(cè)成功后應(yīng)自動(dòng)登錄并跳轉(zhuǎn)首頁(yè) await expect(page).toHaveURL(/\/home/); // 斷言登錄態(tài)右上角出現(xiàn)用戶昵稱或手機(jī)號(hào)掩碼 const userMenu page.getByTestId(user-menu); await expect(userMenu).toBeVisible(); await expect(userMenu).toContainText(phone.slice(0, 3) ****); });這里有幾個(gè)細(xì)節(jié)值得展開說。手機(jī)號(hào)用時(shí)間戳生成是為了防止測(cè)試環(huán)境里出現(xiàn)重復(fù)賬號(hào)如果不用時(shí)間戳第二次跑同一個(gè)用例就會(huì)遇到手機(jī)號(hào)已注冊(cè)的異常用例直接失敗但這不是被測(cè)系統(tǒng)的bug是測(cè)試代碼自己的問題。這類問題統(tǒng)稱為測(cè)試自身不穩(wěn)定因素要在設(shè)計(jì)階段就規(guī)避掉。getByLabel、getByRole、getByTestId這些是Playwright推薦的定位API優(yōu)先于className和id選擇器。原因在于className和id是前端代碼的實(shí)現(xiàn)細(xì)節(jié)重構(gòu)時(shí)很容易變而label、role、testid這些相對(duì)更接近用戶可見的語義穩(wěn)定性要好很多。我見過太多項(xiàng)目因?yàn)榍岸税杨惷麖腷tn-login改成了login-button結(jié)果整個(gè)e2e套件紅一片。用語義化定位器之后這種情況基本絕跡。4.2 電商下單全流程用例下單鏈路是e2e中最能體現(xiàn)端到端價(jià)值的場(chǎng)景。這里要覆蓋搜索、加購(gòu)、購(gòu)物車校驗(yàn)、結(jié)算、支付回調(diào)、訂單生成一整串流程。test(用戶購(gòu)買商品后訂單狀態(tài)為待支付, async ({ page }) { // 登錄這里直接調(diào)用接口造數(shù)據(jù)不走UI const phone 13800000001; await page.request.post(/api/auth/login, { data: { phone, password: Test12345 }, }); // 進(jìn)入首頁(yè)搜索商品 await page.goto(/); await page.getByPlaceholder(搜索商品).fill(無線耳機(jī)); await page.keyboard.press(Enter); // 第一個(gè)搜索結(jié)果點(diǎn)擊進(jìn)入詳情 const firstItem page.locator(.product-list-item).first(); await firstItem.click(); // 詳情頁(yè)加購(gòu) await page.getByRole(button, { name: 加入購(gòu)物車 }).click(); // 去購(gòu)物車頁(yè)結(jié)算 await page.goto(/cart); await expect(page.getByText(無線耳機(jī))).toBeVisible(); await page.getByRole(button, { name: 去結(jié)算 }).click(); // 結(jié)算頁(yè)確認(rèn)訂單 await page.getByRole(button, { name: 提交訂單 }).click(); // 跳轉(zhuǎn)支付頁(yè)驗(yàn)證訂單號(hào)存在 await expect(page).toHaveURL(/\/payment/); const orderNo await page.locator(.order-no).innerText(); expect(orderNo.length).toBeGreaterThan(0); });這條用例我特意把登錄前置到api層理由很簡(jiǎn)單登錄本身不是這條用例的測(cè)試目標(biāo)下單才是。如果讓每條下單用例都先走一遍UI登錄不但拖慢執(zhí)行時(shí)間還會(huì)因?yàn)榈卿浤K的偶發(fā)問題污染其他模塊的測(cè)試結(jié)果。e2e的粒度要遵循只測(cè)這條鏈路應(yīng)該測(cè)的東西這個(gè)原則。4.3 踩過的坑選擇器、等待和斷言時(shí)機(jī)寫e2e必然會(huì)遇到三個(gè)經(jīng)典問題。第一個(gè)是選擇器不穩(wěn)定。我剛才一直強(qiáng)調(diào)語義化定位器但這還不夠。很多現(xiàn)代前端框架比如Vue、React渲染是異步的數(shù)據(jù)加載中頁(yè)面先顯示骨架屏數(shù)據(jù)到了之后才渲染真實(shí)內(nèi)容。如果在骨架屏階段就去定位元素大概率會(huì)失敗。Playwright的自動(dòng)等待機(jī)制解決了一部分問題但仍要養(yǎng)成習(xí)慣關(guān)鍵交互前先斷言前置條件比如等加載完成標(biāo)識(shí)出現(xiàn)再點(diǎn)擊按鈕。第二個(gè)是等待策略。不要用硬編碼的sleep比如page.waitForTimeout(3000)。這類寫法是flaky用例的最大源頭——這3秒在網(wǎng)絡(luò)快的時(shí)候是浪費(fèi)在網(wǎng)絡(luò)慢的時(shí)候還不夠。正確做法是等待某個(gè)期望狀態(tài)出現(xiàn)Playwright里就是await expect(locator).toBeVisible()這類斷言式等待它會(huì)在元素滿足條件時(shí)立刻返回不滿足時(shí)一直重試直到超時(shí)。這套機(jī)制比固定等待穩(wěn)得多。第三個(gè)是斷言時(shí)機(jī)。很多新手在頁(yè)面跳轉(zhuǎn)后立刻斷言URL但跳轉(zhuǎn)過程可能還在路由切換中斷言太早就會(huì)失敗。正確做法是先斷言一個(gè)目標(biāo)頁(yè)面特有的元素再斷言URL。比如跳轉(zhuǎn)支付頁(yè)后先等支付金額這個(gè)元素可見再校驗(yàn)URL里有沒有payment字段順序別反過來。5. 執(zhí)行策略從本地調(diào)試到CI流水線5.1 本地運(yùn)行 Debug 模式不直接跑全量我在本地開發(fā)時(shí)很少一上來就跑全量測(cè)試那樣效率極低。Playwright提供了headed模式和調(diào)試模式我會(huì)先用--headed跑一條單用例肉眼確認(rèn)頁(yè)面行為對(duì)得上預(yù)期。如果中途出問題可以打開trace viewer回放每一步操作和頁(yè)面截圖定位是選擇器寫錯(cuò)還是頁(yè)面邏輯有變化。調(diào)試完之后再切回headless模式跑全量回歸。實(shí)際使用中trace這項(xiàng)功能特別值得開。它會(huì)在測(cè)試失敗時(shí)自動(dòng)記錄一段執(zhí)行軌跡包含網(wǎng)絡(luò)請(qǐng)求、DOM快照、控制臺(tái)日志、鼠標(biāo)鍵盤事件。排查線上環(huán)境復(fù)現(xiàn)不了的問題靠它基本能一次定位。5.2 CI里怎么跑e2e持續(xù)集成中跑e2e最怕兩件事環(huán)境不一致和并發(fā)沖突。我見過太多項(xiàng)目在本地跑得干干凈凈一上CI就各種失敗十有八九是環(huán)境差異導(dǎo)致的。我的做法是在CI里用容器來跑測(cè)試保證每次跑的瀏覽器版本、Node版本、依賴版本完全一致。GitHub Actions里可以這樣配置name: e2e-tests on: push: branches: [main] pull_request: jobs: e2e: runs-on: ubuntu-latest services: mysql: image: mysql:8.0 env: MYSQL_ROOT_PASSWORD: root ports: [3306:3306] steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test這個(gè)配置里把數(shù)據(jù)庫(kù)也作為服務(wù)一起起在CI里測(cè)試環(huán)境就能完整自包含不需要依賴外部環(huán)境。并發(fā)執(zhí)行方面Playwright默認(rèn)是跑在多個(gè)worker里的可以同時(shí)跑多個(gè)用例文件。但要特別注意多個(gè)worker同時(shí)操作同一個(gè)測(cè)試環(huán)境如果環(huán)境有共享數(shù)據(jù)就會(huì)產(chǎn)生互相干擾。比如兩個(gè)用例同時(shí)下單庫(kù)存數(shù)可能被兩個(gè)用例同時(shí)扣減最后斷言的口徑就亂了。我的方案是盡量讓每個(gè)用例的數(shù)據(jù)互相獨(dú)立如果實(shí)在沒辦法獨(dú)立就在playwright.config里把用例串行執(zhí)行export default defineConfig({ workers: process.env.CI ? 2 : 1, fullyParallel: false, });5.3 報(bào)告和失敗通知測(cè)試跑完報(bào)告必須讓人一眼看出哪破了、破在哪。Playwright默認(rèn)生成HTML報(bào)告包含每個(gè)用例的耗時(shí)、狀態(tài)、失敗截圖、trace回放入口。我會(huì)在CI里把報(bào)告上傳為artifact每次構(gòu)建完都能直接查看。失敗通知我用的是定時(shí)任務(wù)方式CI跑完如果非零退出就把結(jié)果推到團(tuán)隊(duì)的IM群里。這一步的核心價(jià)值在于快速響應(yīng)e2e掛了往往意味著主干鏈路有問題早一分鐘知道就少一批受影響的用戶。6. 常見問題與排查技巧實(shí)錄6.1 flaky測(cè)試的三大來源和解決思路flaky測(cè)試就是那種這次跑過、下次跑掛、重跑又過了的用例。它比穩(wěn)定的失敗更讓人頭疼因?yàn)槟悴淮_定是自己代碼的問題、測(cè)試的問題還是環(huán)境的問題。歸納下來98%的flaky來自下面三個(gè)地方來源典型表現(xiàn)解決方向異步渲染競(jìng)態(tài)頁(yè)面還沒渲染完就去點(diǎn)按鈕用斷言式等待替代固定sleep數(shù)據(jù)污染上一個(gè)用例殘留數(shù)據(jù)影響下一個(gè)每個(gè)用例獨(dú)立數(shù)據(jù)teardown清理環(huán)境抖動(dòng)網(wǎng)絡(luò)慢、第三方接口超時(shí)增加重試機(jī)制關(guān)鍵接口mock重試機(jī)制我建議謹(jǐn)慎使用。在CI里配置retries: 1是合理的超過3次重試就有問題了——它不是幫你解決問題而是幫你掩蓋問題。重試通過之后沒有人為這個(gè)flaky根因負(fù)責(zé)它就會(huì)一直潛伏下去。6.2 定位失敗用例的標(biāo)準(zhǔn)排查流程遇到用例失敗了我現(xiàn)在的排查流程基本固定分享出來給大家參考。第一步看失敗截圖不要急著猜。Playwright失敗時(shí)會(huì)自動(dòng)截圖先看截圖里頁(yè)面是什么狀態(tài)——是空白頁(yè)、是彈了報(bào)錯(cuò)、還是停留在上一步?jīng)]跳轉(zhuǎn)。這一眼能過濾掉一半的問題。第二步看trace。如果截圖看不出原因打開trace看操作回放重點(diǎn)看失敗前最后幾步的DOM狀態(tài)和網(wǎng)絡(luò)請(qǐng)求。如果某個(gè)接口返回了500那就是后端問題如果接口正常但斷言失敗那就是前端渲染問題。第三步看執(zhí)行日志?？刂婆_(tái)的報(bào)錯(cuò)信息有時(shí)候會(huì)直接給出線索比如Failed to fetch說明網(wǎng)絡(luò)層有問題Cannot read properties of undefined說明前端JS異常。這三步走完90%以上的問題都能定位到具體層級(jí)。我強(qiáng)烈建議大家養(yǎng)成這個(gè)習(xí)慣而不是一看到失敗就重跑一遍——重跑一百遍也只能碰到運(yùn)氣好的時(shí)候通過真正的問題始終沒有暴露。6.3 前端點(diǎn)擊無效的經(jīng)典案例復(fù)盤有一個(gè)問題我想單獨(dú)拿出來說因?yàn)閹缀趺總€(gè)團(tuán)隊(duì)都會(huì)遇到按鈕明明存在點(diǎn)擊了卻沒有反應(yīng)。這個(gè)問題的根源往往是元素被某個(gè)透明遮罩層擋著或者元素看起來在頁(yè)面上、但被判定為不可點(diǎn)擊。Playwright的click會(huì)自動(dòng)檢查元素是否接收事件如果檢測(cè)到遮罩會(huì)把click攔截就會(huì)報(bào)element is not receiving events。我踩過最深的一次坑是在一個(gè)彈窗組件里彈窗關(guān)閉按鈕點(diǎn)擊之后關(guān)閉動(dòng)畫還在執(zhí)行此時(shí)頁(yè)面上殘留一層透明的遮罩層再點(diǎn)其他按鈕就會(huì)被攔截。排查了很久才發(fā)現(xiàn)是動(dòng)畫時(shí)長(zhǎng)的問題。解決方案很土但很有效點(diǎn)擊之前先斷言遮罩層已經(jīng)消失。await page.locator(.modal-mask).waitFor({ state: hidden });這一行加下去問題沒有再出現(xiàn)過。這類問題提醒我一點(diǎn)e2e測(cè)試不只驗(yàn)證業(yè)務(wù)功能它還在驗(yàn)證用戶體驗(yàn)的真實(shí)反饋。動(dòng)畫未結(jié)束、按鈕變灰、加載中狀態(tài)這些在真實(shí)用戶眼里都是點(diǎn)不了的現(xiàn)象。測(cè)試把這些問題暴露出來對(duì)業(yè)務(wù)是好事。7. 一些經(jīng)驗(yàn)之外的個(gè)人體會(huì)做了幾年e2e之后我越來越覺得它不是一個(gè)純技術(shù)工作。寫用例的時(shí)候要想業(yè)務(wù)是怎樣的買商品要走多少步用戶什么時(shí)候會(huì)退出系統(tǒng)提示應(yīng)該出現(xiàn)在哪里排查問題的時(shí)候要判斷是自己代碼還是前端邏輯還是后端服務(wù)。它逼著人從代碼能不能跑往系統(tǒng)能不能用的方向思考。所以如果你問我e2e測(cè)試框架里哪個(gè)功能最值得投入時(shí)間學(xué)習(xí)我的答案不是選擇器、不是斷言API、不是并行執(zhí)行而是讀懂一條業(yè)務(wù)鏈路的能力。工具只是實(shí)現(xiàn)手段真正決定e2e項(xiàng)目?jī)r(jià)值的是你對(duì)業(yè)務(wù)的拆解能力。把一條業(yè)務(wù)鏈路拆清楚哪里是核心、哪里是分支、哪里可以妥協(xié)比掌握任何框架的細(xì)節(jié)都重要。最后分享一個(gè)實(shí)用小技巧e2e用例命名不要用模塊名要用用戶故事。比如用戶可以用優(yōu)惠券抵扣訂單金額就比coupon_order_test更容易讓人理解這條用例為什么存在。多人協(xié)作的時(shí)候其他同事看到用例名就知道這個(gè)測(cè)試在整個(gè)系統(tǒng)里保護(hù)的是什么。這個(gè)習(xí)慣的成本幾乎為零收益卻能持續(xù)很久。