干測(cè)試這些年最常被問的一句話就是“你測(cè)的到底是不是真實(shí)用戶會(huì)走的路”。這個(gè)問題光靠單元測(cè)試答不上來得靠e2e。今天聊的這個(gè)“e2e”項(xiàng)目不單單是“端到端測(cè)試”這個(gè)詞本身而是一個(gè)真實(shí)落地過的測(cè)試工程實(shí)踐。里面的profile1也不是什么高深術(shù)語(yǔ)它是一套封裝好的端到端測(cè)試場(chǎng)景配置——說白了就是把“用戶在真實(shí)瀏覽器里打開你的產(chǎn)品、一步步完成核心任務(wù)”這一整套流程用自動(dòng)化腳本固定下來跑一次就能告訴你哪里斷了。這篇東西適合誰(shuí)看就是那些已經(jīng)寫過一點(diǎn)接口測(cè)試、想往上層走走的測(cè)試開發(fā)以及每天都在被“測(cè)試環(huán)境沒問題啊”這句話折磨的前后端同學(xué)?？赐昴阒辽倌馨裡2e的工程骨架搭起來知道profile1這種配置該怎么設(shè)計(jì)遇到定位不到元素的時(shí)候不會(huì)第一反應(yīng)是“換個(gè)xpath試試”。1. 端到端測(cè)試想解決的問題和profile1的由來1.1 為什么單元測(cè)試全綠了線上還是崩說個(gè)挺典型的場(chǎng)景。你負(fù)責(zé)一個(gè)電商項(xiàng)目后端接口測(cè)了一百多個(gè)覆蓋率快90%了前端組件測(cè)試也寫了每個(gè)按鈕點(diǎn)擊都有斷言。結(jié)果上線第二天用戶投訴說下單按鈕點(diǎn)了沒反應(yīng)。查了半天發(fā)現(xiàn)是某個(gè)接口在特定場(chǎng)景下返回的字段結(jié)構(gòu)變了前端拿著新結(jié)構(gòu)去渲染直接白屏。單元測(cè)試和接口測(cè)試各自都在自己的“小院子”里驗(yàn)證院墻之間那段路誰(shuí)也不負(fù)責(zé)。這就是e2e存在的理由。它不關(guān)心你某一個(gè)函數(shù)寫得對(duì)不對(duì)也不關(guān)心接口契約是否嚴(yán)格匹配它只關(guān)心一件事把產(chǎn)品當(dāng)成一個(gè)黑盒用真實(shí)用戶的視角走完一條核心業(yè)務(wù)鏈路整條鏈路能不能通。用戶注冊(cè)能不能完成、登錄狀態(tài)能不能保持、購(gòu)物車?yán)锛拥臇|西結(jié)算時(shí)還在不在、支付回調(diào)回來之后訂單狀態(tài)對(duì)不對(duì)——這些跨模塊、跨系統(tǒng)、跨端口的協(xié)作問題只有e2e能兜住。我見過很多團(tuán)隊(duì)把e2e當(dāng)成“重復(fù)手工回歸”的替身這其實(shí)是一個(gè)很窄的理解。e2e更大的價(jià)值是約束它逼著團(tuán)隊(duì)把用戶路徑顯性化把所有外部依賴數(shù)據(jù)庫(kù)狀態(tài)、第三方服務(wù)、消息隊(duì)列的約定固化下來。一旦這條路徑上某個(gè)環(huán)節(jié)悄悄變了e2e會(huì)第一時(shí)間拉響警報(bào)而不是等用戶來當(dāng)測(cè)試員。1.2 profile1到底是什么從測(cè)試數(shù)據(jù)到環(huán)境配置的打包很多剛接觸e2e的人會(huì)問profile是什么意思我最初也困惑過。后來在工程里反復(fù)折騰才明白profile本質(zhì)上就是“一組環(huán)境與數(shù)據(jù)預(yù)設(shè)的總和”。你想想一套e2e腳本要跑起來光有代碼是不夠的。它得知道我現(xiàn)在打的是哪套環(huán)境的域名用哪個(gè)賬號(hào)登錄這個(gè)賬號(hào)有沒有初始化數(shù)據(jù)測(cè)試商品庫(kù)存多少支付方式是走模擬網(wǎng)關(guān)還是沙箱這些如果寫死在代碼里換套環(huán)境就得改代碼改完還得重新部署太蠢了。profile1就是把這些東西打包成一個(gè)命名配置。我習(xí)慣用profile1表示“第一套完整可用的端到端測(cè)試基準(zhǔn)環(huán)境”。具體來說它包含四塊內(nèi)容環(huán)境指向baseURL、網(wǎng)關(guān)地址、回調(diào)地址身份憑據(jù)測(cè)試賬號(hào)、密碼、token、密鑰數(shù)據(jù)準(zhǔn)備預(yù)置用戶、預(yù)置商品、優(yōu)惠券、訂單號(hào)規(guī)則行為參數(shù)超時(shí)時(shí)間、重試次數(shù)、是否啟用模擬支付為什么要單獨(dú)抽一個(gè)profile因?yàn)閑2e最怕“環(huán)境漂移”。今天是staging環(huán)境明天數(shù)據(jù)庫(kù)被某個(gè)人手動(dòng)改了一條數(shù)據(jù)后天又有人說“我在本地把后端起起來就行了吧”結(jié)果同一個(gè)腳本在不同人手里跑出完全不同的結(jié)果。有了profile1所有人都對(duì)著同一個(gè)基準(zhǔn)環(huán)境說話腳本參數(shù)對(duì)了結(jié)果就是可復(fù)現(xiàn)的。這套思路并不是我發(fā)明的很多成熟框架里的test profile、environment config都是同一個(gè)道理只是很多小團(tuán)隊(duì)沒意識(shí)到它值得被認(rèn)真設(shè)計(jì)。2. 工具選型與核心細(xì)節(jié)e2e工程怎么搭才穩(wěn)2.1 主流e2e框架怎么選別只看誰(shuí)火2024年聊e2e繞不開三個(gè)框架Selenium、Cypress、Playwright。我三個(gè)都寫過說說真實(shí)感受。Selenium是老前輩生態(tài)最全什么瀏覽器都能驅(qū)動(dòng)理論上的兼容性天花板最高。但它的問題也最明顯慢而且API設(shè)計(jì)停留在“模擬人操作瀏覽器”的層面沒有太多面向測(cè)試的語(yǔ)義。寫久了會(huì)有一種“我在替用戶點(diǎn)鼠標(biāo)而不是在測(cè)產(chǎn)品”的割裂感。如果團(tuán)隊(duì)里全是Java出身的老測(cè)試用Selenium可能順手一些但我個(gè)人不推薦新項(xiàng)目再選它除非你有很強(qiáng)的多瀏覽器廠商兼容需求。Cypress是后來居上者它的殺手锏是開發(fā)者體驗(yàn)。時(shí)間旅行式的調(diào)試、自動(dòng)等待、斷言風(fēng)格和Mocha/Chai一脈相承前端同學(xué)上手幾乎是零門檻。但它有個(gè)硬傷只支持自家控制的瀏覽器環(huán)境多標(biāo)簽頁(yè)和跨域場(chǎng)景處理起來很別扭。如果你測(cè)的產(chǎn)品是純內(nèi)部系統(tǒng)、技術(shù)棧又偏前端Cypress能讓你爽到飛起。Playwright是我現(xiàn)在的主力。它最大的優(yōu)勢(shì)是所有主流瀏覽器統(tǒng)一API而且內(nèi)置了自動(dòng)等待和網(wǎng)絡(luò)攔截這意味著你不需要像Selenium那樣手動(dòng)寫一堆WebDriverWait也不需要像Cypress那樣為了繞過跨域限制折騰插件。再加上它支持移動(dòng)端模擬、可以同時(shí)維護(hù)多個(gè)上下文做復(fù)雜業(yè)務(wù)鏈路的時(shí)候省力非常明顯。我給你的建議很簡(jiǎn)單團(tuán)隊(duì)前端基因強(qiáng)、產(chǎn)品形態(tài)是單頁(yè)應(yīng)用優(yōu)先Cypress需要強(qiáng)兼容、強(qiáng)并行、鏈路特別復(fù)雜直接上Playwright除非公司有嚴(yán)格的既有技術(shù)棧綁定否則別碰Selenium。2.2 profile1的目錄設(shè)計(jì)與配置要點(diǎn)選完框架接下來就是工程結(jié)構(gòu)。一個(gè)能長(zhǎng)期維護(hù)的e2e項(xiàng)目千萬(wàn)不要把所有腳本堆在一個(gè)文件夾里。我按照這個(gè)結(jié)構(gòu)來組織e2e/ ├── profiles/ │ ├── profile1.json │ └── profile2.json ├── tests/ │ ├── smoke/ │ ├── regression/ │ └── business/ ├── pages/ │ ├── login.page.js │ ├── cart.page.js │ └── order.page.js ├── utils/ │ ├── api.helper.js │ └── data.factory.js ├── reports/ └── playwright.config.jsprofiles目錄專門放各類profiletests按測(cè)試級(jí)別和業(yè)務(wù)模塊拆分pages放頁(yè)面對(duì)象utils放公共方法。這套結(jié)構(gòu)符合Page Object Model的經(jīng)典思想目的就一個(gè)把“用例”和“實(shí)現(xiàn)細(xì)節(jié)”解耦。你測(cè)試腳本里只描述“用戶做什么”不關(guān)心“具體的元素選擇器是什么”一旦前端改了按鈕的class名你只需要改pages目錄里那個(gè)頁(yè)面對(duì)象而不是全項(xiàng)目搜索替換。以profile1.json為例我會(huì)寫成這樣{ name: profile1, baseURL: https://staging.example.com, apiBaseURL: https://api.staging.example.com, credentials: { defaultUser: { username: e2e_tester_01, password: Passw0rd!Test } }, testData: { productId: P10086, couponCode: E2E-SAVE-10 }, payment: { mode: mock, callbackUrl: https://webhook.staging.example.com/pay/callback }, timeout: 30000, retries: 2, video: off, screenshot: only-on-failure }配置里每一項(xiàng)都是有講究的。比如timeout不要默認(rèn)用框架的5秒e2e走的是真實(shí)瀏覽器接口響應(yīng)、前端渲染、資源加載都是全鏈路30秒是我試過比較穩(wěn)妥的基準(zhǔn)。retries設(shè)2是因?yàn)閑2e偶爾會(huì)因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者第三方服務(wù)偶發(fā)超時(shí)而失敗重跑一次往往就過了但你得保證重試的是整條用例而不是用例里的某個(gè)步驟否則容易踩臟數(shù)據(jù)。screenshot設(shè)成失敗時(shí)截圖這是排查問題的最低需求別為了省空間關(guān)掉它。2.3 數(shù)據(jù)準(zhǔn)備profile1里不寫死數(shù)據(jù)的藝術(shù)配置里寫測(cè)試數(shù)據(jù)是必要的但你要小心一件事不要把e2e用例改成依賴固定主鍵數(shù)據(jù)的家伙。比如測(cè)試商品IDP10086今天它是存在的明天數(shù)據(jù)庫(kù)重建商品沒了你的用例就開始飄紅。更穩(wěn)的做法是通過API在測(cè)試執(zhí)行前動(dòng)態(tài)創(chuàng)建數(shù)據(jù)profile1里放的是“種子數(shù)據(jù)”或“數(shù)據(jù)生成規(guī)則”不是“永固數(shù)據(jù)”。我一般會(huì)在utils/data.factory.js里暴露幾個(gè)方法像這樣async function createTestUser(apiContext, profile) { const username e2e_${Date.now()}_${Math.floor(Math.random() * 1000)}; const response await apiContext.post(${profile.apiBaseURL}/users, { data: { username, password: Passw0rd!Test, role: buyer } }); return { username, password: Passw0rd!Test, userId: response.data.id }; }這樣每條用例跑的時(shí)候都有獨(dú)立的測(cè)試賬號(hào)互相不干擾也可以重復(fù)跑。用固定賬號(hào)容易撞數(shù)據(jù)比如上一次跑完購(gòu)物車沒清空這一次斷言購(gòu)物車數(shù)量是0直接掛。這就是為什么e2e工程里“數(shù)據(jù)獨(dú)立性”比“用真實(shí)數(shù)據(jù)”更重要——真實(shí)數(shù)據(jù)往往是臟的而臟數(shù)據(jù)會(huì)讓你的測(cè)試結(jié)果變得不可信。3. 實(shí)操?gòu)牧闩芡ㄒ粋€(gè)profile1場(chǎng)景3.1 環(huán)境準(zhǔn)備用5分鐘把Playwright拉起來下面我以Playwright為例帶你把一個(gè)profile1場(chǎng)景從零跑通。首先安裝依賴npm init -y npm install -D playwright/test npx playwright install第一條命令創(chuàng)建項(xiàng)目第二條裝測(cè)試框架第三條下載瀏覽器內(nèi)核。這里有個(gè)細(xì)節(jié)npx playwright install默認(rèn)只裝Chromium如果你要測(cè)Safari和Firefox得用npx playwright install --all。公司內(nèi)部系統(tǒng)一般Chromium夠用商業(yè)項(xiàng)目建議全裝。安裝完創(chuàng)建一個(gè)playwright.config.js最簡(jiǎn)配置長(zhǎng)這樣const { defineConfig } require(playwright/test); const profile1 require(./profiles/profile1.json); module.exports defineConfig({ testDir: ./tests, timeout: profile1.timeout, retries: profile1.retries, use: { baseURL: profile1.baseURL, screenshot: profile1.screenshot, viewport: { width: 1280, height: 720 }, ignoreHTTPSErrors: true }, reporter: [[list], [html, { outputFolder: reports }]] });你會(huì)發(fā)現(xiàn)配置文件本身也不硬編碼路徑而是從profile1.json里讀取公共參數(shù)。這就是配置統(tǒng)一管理的價(jià)值以后要換到profile2腳本一行不用改只要把這個(gè)入口文件換成profile2.json即可。3.2 編寫第一個(gè)e2e用例登錄、加購(gòu)、下單、斷言我拿一個(gè)電商業(yè)務(wù)來示例這是e2e最經(jīng)典的場(chǎng)景。新建tests/business/order.flow.spec.jsconst { test, expect } require(playwright/test); const { LoginPage } require(../../pages/login.page); const { ProductPage } require(../../pages/product.page); const { CartPage } require(../../pages/cart.page); const { CheckoutPage } require(../../pages/checkout.page); const { createTestUser } require(../../utils/data.factory); test.describe(核心交易鏈路 - profile1, () { let testUser; test.beforeAll(async ({ request }) { testUser await createTestUser(request, profile1); }); test(登錄 → 搜索商品 → 加購(gòu) → 結(jié)算 → 生成訂單, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testUser.username, testUser.password); await expect(page).toHaveURL(/\/home/); const productPage new ProductPage(page); await productPage.search(端到端測(cè)試專用商品); await productPage.openFirstProduct(); await productPage.addToCart(); const cartPage new CartPage(page); await cartPage.goto(); await expect(cartPage.cartItemCount).toHaveText(1); const checkoutPage new CheckoutPage(page); await checkoutPage.proceedToCheckout(); await checkoutPage.selectDefaultAddress(); await checkoutPage.submitOrder(); await expect(checkoutPage.orderSuccessMessage).toBeVisible(); const orderNo await checkoutPage.getOrderNumber(); expect(orderNo).toMatch(/^ORD\d{12}$/); }); });這段測(cè)試描述的就是一個(gè)完整用戶旅程。注意幾個(gè)關(guān)鍵點(diǎn)beforeAll里用request夾具調(diào)用API創(chuàng)建用戶一來確保數(shù)據(jù)獨(dú)立二來幫你省掉截圖驗(yàn)證碼等注冊(cè)環(huán)節(jié)的負(fù)擔(dān)只聚焦核心鏈路。每個(gè)頁(yè)面都是pages目錄下的頁(yè)面對(duì)象測(cè)試代碼里不出現(xiàn)具體CSS選擇器可讀性非常高。斷言盡量靠近用戶感知比如“購(gòu)物車數(shù)量是不是1”“訂單號(hào)是不是ORD開頭12位數(shù)字”而不是“某個(gè)隱藏input的value是什么”。頁(yè)面對(duì)象login.page.js可以這樣寫class LoginPage { constructor(page) { this.page page; this.usernameInput page.locator(#username); this.passwordInput page.locator(#password); this.loginButton page.locator(button[typesubmit]); } async goto() { await this.page.goto(/login); } async login(username, password) { await this.usernameInput.fill(username); await this.passwordInput.fill(password); await this.loginButton.click(); await this.page.waitForLoadState(networkidle); } } module.exports { LoginPage };有人會(huì)問為什么login方法里要等networkidle而不是直接斷言跳轉(zhuǎn)因?yàn)辄c(diǎn)擊登錄后路由跳轉(zhuǎn)是異步的斷言URL會(huì)偶爾抓到舊地址。等networkidle再斷言URL成功率會(huì)高不少。但要注意networkidle并不是銀彈如果頁(yè)面里有一個(gè)長(zhǎng)輪詢請(qǐng)求它會(huì)讓你等很久——這時(shí)候你就得改成等待某個(gè)具體的UI元素比如首頁(yè)的用戶頭像出現(xiàn)在頁(yè)面上這樣更精準(zhǔn)。3.3 跑起來以及怎么讀懂報(bào)告運(yùn)行指令很簡(jiǎn)單npx playwright test --configplaywright.config.js如果你想只跑profile1相關(guān)的用例可以在測(cè)試描述上打tag然后過濾npx playwright test --grep profile1跑完會(huì)生成HTML報(bào)告里面有每個(gè)步驟的截圖、瀏覽器控制臺(tái)日志、網(wǎng)絡(luò)請(qǐng)求明細(xì)和耗時(shí)分布。我最常用的排查姿勢(shì)是先看失敗步驟的截圖確認(rèn)是不是元素沒出現(xiàn)再看控制臺(tái)有沒有JS報(bào)錯(cuò)比如某個(gè)接口500了最后看network面板把那個(gè)請(qǐng)求的響應(yīng)體拉出來對(duì)比字段十有八九能定位到問題。還有一個(gè)小技巧加上--headed參數(shù)讓瀏覽器窗口顯示出來你會(huì)親眼看到整個(gè)操作過程能發(fā)現(xiàn)很多“腳本在跑但產(chǎn)品明顯卡了一下”這類問題。4. 常見問題與排查技巧實(shí)錄4.1 元素定位為什么明明在頁(yè)面上腳本就是找不到e2e踩坑第一名永遠(yuǎn)是元素定位。常見的情況有三種元素被遮擋、元素在iframe里、元素是動(dòng)態(tài)渲染出來的。被遮擋通常發(fā)生在彈窗、浮層、蒙層上。解決辦法是等待遮擋元素消失或者不可見await expect(page.locator(.modal-mask)).toBeHidden({ timeout: 10000 }); await page.locator(#submit-btn).click();iframe里的元素需要先切換到frame上下文不要直接在page上定位。Playwright里這樣處理const frame page.frameLocator(#payment-iframe); await frame.locator(#card-number).fill(4242424242424242);動(dòng)態(tài)渲染的元素則最煩人尤其是列表加載用了虛擬滾動(dòng)只有滾動(dòng)到可視區(qū)域才真正渲染出來。解決辦法是滾動(dòng)到目標(biāo)位置再定位const productCard page.locator(.product-item, { hasText: 端到端測(cè)試專用商品 }); await productCard.scrollIntoViewIfNeeded(); await productCard.click();經(jīng)驗(yàn)法則能用文本定位的不要用索引定位能等可見的不要等存在能滾到的不要直接點(diǎn)。這三條做到了90%的定位問題都能繞過去。4.2 等待策略別讓sleep毀掉你的一下午新手寫e2e最愛的就是sleep(3000)好像一個(gè)固定等待能解決所有“沒加載出來”的問題。但sleep恰恰是e2e最危險(xiǎn)的寫法它在快的環(huán)境里白白浪費(fèi)時(shí)間在慢的環(huán)境里依然會(huì)掛還掩蓋了真實(shí)的渲染問題。正確姿勢(shì)是使用自動(dòng)等待和顯式斷言。Playwright的click、fill這些操作默認(rèn)就有可操作性檢查會(huì)自動(dòng)等待元素穩(wěn)定。真正需要操心的是那些JavaScri異步數(shù)據(jù)渲染的點(diǎn)。我不建議在寫用例之前就到處鋪等待更好的做法是先跑一遍看哪里掛了再針對(duì)性地加等待。很多掛點(diǎn)在報(bào)告里看網(wǎng)絡(luò)請(qǐng)求時(shí)間就一目了然比盲猜靠譜得多。當(dāng)然也有正常的設(shè)計(jì)手段。比如網(wǎng)絡(luò)請(qǐng)求后等待特定數(shù)據(jù)字段出現(xiàn)await page.waitForResponse(resp resp.url().includes(/api/order) resp.status() 200);或者等一個(gè)骨架屏消失await expect(page.locator(.skeleton-screen)).toHaveCount(0);4.3 profile1環(huán)境漂移排查一套腳本在不同地方跑出不同結(jié)果這是profile類配置最容易遇到的問題。profile1在CI上跑得好好的本地一跑就掛或者兩個(gè)開發(fā)本地跑同一個(gè)用例結(jié)果一個(gè)過、一個(gè)掛。核心原因基本可以鎖死成這幾個(gè)本地hosts指向不同、本地改了環(huán)境變量、測(cè)試賬號(hào)權(quán)限不同、數(shù)據(jù)庫(kù)數(shù)據(jù)被手動(dòng)改過。排查次序我給你排好了先看網(wǎng)絡(luò)請(qǐng)求打的是不是同一個(gè)域名這能篩出一半問題。再看有沒有本地代理攔截。然后對(duì)比測(cè)試賬號(hào)在兩端的數(shù)據(jù)快照用createTestUser創(chuàng)建的用戶通常數(shù)據(jù)一致但如果用了公共賬號(hào)這一步很容易翻車。最后看一眼是不是有人改了profile1配置但沒提交到倉(cāng)庫(kù)。我在工程里有個(gè)硬規(guī)矩CI跑的必須是打包好的profile1配置不允許CI里再手動(dòng)拼JSON。這樣能最大限度保證“大家跑的是同一個(gè)e2e”也方便回溯是哪次提交開始讓用例變紅的。4.4 處理前端穩(wěn)定性問題偶發(fā)失敗不是玄學(xué)還有一種很氣人的情況同一個(gè)用例連跑三次中間失敗一次再跑又全綠了。這就是“flaky test”。很多人第一反應(yīng)是加大retries次數(shù)把失敗掩蓋過去。短期可以但長(zhǎng)期下去你的通知渠道里全是“重試后通過”的假警報(bào)大家就會(huì)對(duì)紅燈麻木e2e的價(jià)值就被磨掉了。處理flaky test的正確思路是找到不穩(wěn)定源頭。最常見的是第三方圖片加載慢、埋點(diǎn)請(qǐng)求報(bào)錯(cuò)、字體加載閃動(dòng)、動(dòng)態(tài)圖表渲染時(shí)序不穩(wěn)定。我一般先看失敗截圖截圖里如果元素已經(jīng)出現(xiàn)但斷言失敗多半是時(shí)序問題改用輪詢斷言如果截圖里就是白屏那就得看控制臺(tái)和網(wǎng)絡(luò)定位是資源加載還是接口報(bào)錯(cuò)。profile1里我建議把video從off改成on只在失敗時(shí)保留視頻片段。這個(gè)文件占用不了多少空間但排查偶發(fā)失敗時(shí)視頻回放能直接告訴你腳本執(zhí)行到哪一步開始變形的特別管用。4.5 一個(gè)速查表常見問題對(duì)照現(xiàn)象可能的根因快速排查路徑元素定位超時(shí)動(dòng)態(tài)渲染/iframe/遮擋先截圖滾動(dòng)等待可見換文本定位登錄后URL斷言失敗路由異步跳轉(zhuǎn)等networkidle或等待具體UI元素接口請(qǐng)求報(bào)404baseURL配置錯(cuò)誤/profile指向錯(cuò)誤環(huán)境查看網(wǎng)絡(luò)請(qǐng)求地址對(duì)比profile1配置測(cè)試數(shù)據(jù)沖突固定賬號(hào)被多任務(wù)復(fù)用改用動(dòng)態(tài)創(chuàng)建測(cè)試數(shù)據(jù)用例偶發(fā)失敗網(wǎng)絡(luò)波動(dòng)/第三方資源慢開啟視頻錄制分析失敗前5秒記錄瀏覽器兼容性差異不同瀏覽器CSS實(shí)現(xiàn)不同切換到不同browser engine跑同一用例對(duì)比這張表對(duì)應(yīng)了我這幾年e2e工作里九成的問題。每次用例報(bào)紅不要急著改代碼先按表里的路徑做一次快速定位基本能把問題收斂到小范圍。5. 實(shí)測(cè)后的幾點(diǎn)體會(huì)最后說點(diǎn)個(gè)人經(jīng)驗(yàn)。e2e這個(gè)東西最坑的并不是寫用例本身而是讓用例持續(xù)穩(wěn)定地跑下去。我在項(xiàng)目里維護(hù)profile1的真實(shí)感受是每一個(gè)配置項(xiàng)都是跟環(huán)境管理者博弈出來的結(jié)果今天他改了一個(gè)第三方服務(wù)的回調(diào)地址明天數(shù)據(jù)庫(kù)換了密碼如果沒有profile這層的集中管理這些變化會(huì)散落在各個(gè)腳本里變成定時(shí)炸彈。如果你剛接觸e2e我建議別一上來就追求500條用例的覆蓋率。老老實(shí)實(shí)先挑一條最核心的鏈路最好的候選就是“用戶注冊(cè)或登錄→做一次核心操作→關(guān)鍵結(jié)果出現(xiàn)”把它跑穩(wěn)再逐步加分支場(chǎng)景。等這條鏈路穩(wěn)定了你自然會(huì)發(fā)現(xiàn)產(chǎn)品那邊再有人拍胸脯說“這地方?jīng)]問題”你可以直接甩給他一條剛跑完的profile1執(zhí)行報(bào)告——數(shù)據(jù)永遠(yuǎn)比口頭承諾更有說服力。還有一個(gè)小技巧分享給做e2e久了的同學(xué)定時(shí)任務(wù)里跑e2e別只看通過率要看“失敗后恢復(fù)的速度”。如果一條用例跑掛之后下一次跑要花多長(zhǎng)時(shí)間才能恢復(fù)數(shù)據(jù)、清完臟狀態(tài)、重新創(chuàng)建賬號(hào)這個(gè)速度決定了你的自動(dòng)化真正能跑多大體量。profile1里的數(shù)據(jù)工廠和API清理方法就是為這個(gè)準(zhǔn)備的。把這些做好了e2e就不是消耗你們團(tuán)隊(duì)精力的玩具而是真正能兜住產(chǎn)品底線的防線。