這幾年只要聊到前端質(zhì)量保障E2E測(cè)試一定是繞不開的話題。手里壓著幾條手工回歸用例每次發(fā)版前都得熬夜點(diǎn)一遍線上出個(gè)事故第一句就是測(cè)過(guò)了嗎——這種處境我經(jīng)歷過(guò)太多次。E2E測(cè)試要解決的就是這個(gè)信任問(wèn)題它把真實(shí)用戶路徑跑通跑爛把應(yīng)該沒(méi)問(wèn)題變成確實(shí)沒(méi)問(wèn)題。這篇文章我把自己的實(shí)戰(zhàn)經(jīng)驗(yàn)完整拆出來(lái)從框架選型到環(huán)境profile管理從用例設(shè)計(jì)到坑位排查給一份可以直接落地的參考。1. 為什么全團(tuán)隊(duì)都該重視E2E測(cè)試1.1 從一個(gè)真實(shí)的線上事故說(shuō)起幾年前我做電商項(xiàng)目一次小版本迭代把購(gòu)物車的優(yōu)惠券計(jì)算邏輯改壞了。單元測(cè)試全綠——因?yàn)閱螠y(cè)只驗(yàn)證了優(yōu)惠券類里的折扣計(jì)算函數(shù)沒(méi)驗(yàn)證從加入購(gòu)物車到結(jié)算頁(yè)展示折扣這條完整路徑。結(jié)果上線后用戶提交訂單時(shí)發(fā)現(xiàn)金額翻倍整個(gè)客服團(tuán)隊(duì)炸了一晚上。這個(gè)事故讓我徹底想明白一個(gè)事軟件的質(zhì)量不在某個(gè)函數(shù)里而在用戶完整的操作鏈路里。用戶不關(guān)心你內(nèi)部模塊怎么劃分他只關(guān)心找到商品—加入購(gòu)物車—下單支付—看到憑證這條流程能不能通。E2E測(cè)試的本質(zhì)就是把這些關(guān)鍵鏈路當(dāng)成一個(gè)整體來(lái)驗(yàn)證模擬真實(shí)用戶的操作行為從打開瀏覽器到看到最終結(jié)果全程覆蓋。那次事故之后我們緊急補(bǔ)了一批關(guān)鍵路徑的回歸測(cè)試但當(dāng)時(shí)用的還是最原始的Selenium腳本跑一次全量用例要一個(gè)多小時(shí)而且極其不穩(wěn)定。后來(lái)才逐步迭代到Playwright方案穩(wěn)定性上來(lái)了時(shí)間也降到了十幾分鐘。這也是我為什么覺得E2E測(cè)試對(duì)于任何有用戶界面、有核心業(yè)務(wù)流程的項(xiàng)目來(lái)說(shuō)不是可選項(xiàng)而是必修課。1.2 端到端測(cè)試到底在驗(yàn)證什么很多人對(duì)E2E的理解停留在點(diǎn)幾個(gè)按鈕看頁(yè)面有沒(méi)有反應(yīng)這太淺了。E2E測(cè)試要驗(yàn)證的核心是三件事缺一不可。第一是業(yè)務(wù)邏輯的正確性。比如說(shuō)注冊(cè)流程填入用戶名、密碼、手機(jī)號(hào)點(diǎn)擊注冊(cè)系統(tǒng)要完成校驗(yàn)、創(chuàng)建賬號(hào)、跳轉(zhuǎn)登錄頁(yè)、發(fā)送驗(yàn)證消息這一連串操作最終用戶能順利登錄。任何一個(gè)環(huán)節(jié)出了問(wèn)題接口報(bào)錯(cuò)也好、前端沒(méi)跳轉(zhuǎn)也罷這條業(yè)務(wù)鏈路就是斷的。E2E測(cè)試就是來(lái)抓這種每個(gè)環(huán)節(jié)看著都沒(méi)事合起來(lái)就出事的玄學(xué)問(wèn)題。第二是跨系統(tǒng)的數(shù)據(jù)一致性。現(xiàn)代應(yīng)用很少有單體的前端、后端、消息隊(duì)列、數(shù)據(jù)庫(kù)、第三方支付平臺(tái)各自獨(dú)立。從頁(yè)面上觸發(fā)一個(gè)操作數(shù)據(jù)要正確流轉(zhuǎn)到后端存儲(chǔ)再把結(jié)果返回到界面呈現(xiàn)。E2E測(cè)試坐在用戶視角這個(gè)位置能發(fā)現(xiàn)數(shù)據(jù)在多個(gè)系統(tǒng)間傳遞時(shí)的丟失、錯(cuò)亂、遲滯問(wèn)題。第三是回歸保障。每次需求迭代都可能碰壞老功能E2E測(cè)試作為最后的防線在發(fā)布前跑一遍用自動(dòng)化測(cè)試代替人工以最快的速度完成回歸。它不追求能發(fā)現(xiàn)多么精妙的邏輯漏洞追求的是核心路徑別被改壞這個(gè)底線。1.3 別再把E2E和集成測(cè)試混為一談我經(jīng)常在團(tuán)隊(duì)評(píng)審里遇到一個(gè)爭(zhēng)論某個(gè)接口測(cè)試算不算E2E我的判斷標(biāo)準(zhǔn)非常簡(jiǎn)單——有沒(méi)有打開真實(shí)的瀏覽器界面有沒(méi)有執(zhí)行真實(shí)用戶的交互行為有沒(méi)有在完整的運(yùn)行環(huán)境中走通業(yè)務(wù)場(chǎng)景。接口測(cè)試關(guān)注的是服務(wù)端給我這個(gè)請(qǐng)求返回什么響應(yīng)它驗(yàn)證的是后端模塊之間的協(xié)作E2E測(cè)試關(guān)注的是用戶做了這些操作后界面和系統(tǒng)給出完整反饋驗(yàn)證的是整個(gè)產(chǎn)品對(duì)外承諾的兌現(xiàn)情況。兩者是互補(bǔ)關(guān)系不該互相替代。單元測(cè)試、接口測(cè)試、E2E測(cè)試的正確關(guān)系就像組裝一臺(tái)車單元測(cè)試檢查螺絲強(qiáng)度接口測(cè)試檢查傳動(dòng)軸轉(zhuǎn)動(dòng)是否正常E2E測(cè)試才是一腳油門踩下去看車能不能穩(wěn)穩(wěn)跑完整個(gè)賽道。2. 框架選型與profile設(shè)計(jì)動(dòng)手前必須想清楚的事2.1 三大主流框架的真實(shí)差距E2E測(cè)試的框架選型決定了后續(xù)所有的開發(fā)體驗(yàn)和穩(wěn)定性我這些年實(shí)際上手過(guò)的框架有三個(gè)Selenium、Cypress、Playwright。光看網(wǎng)上文章可能覺得差不多實(shí)際用起來(lái)差異很大。Selenium是老江湖生態(tài)成熟啥都能干但問(wèn)題也明顯——執(zhí)行速度慢對(duì)異步操作的處理特別生硬寫出來(lái)的代碼動(dòng)不動(dòng)就是顯式等待、顯式等待、再顯式等待。而且它的架構(gòu)是客戶端—WebDriver—瀏覽器驅(qū)動(dòng)中間隔了好幾層環(huán)境變量稍微有點(diǎn)問(wèn)題就起不來(lái)?，F(xiàn)在除了維護(hù)老項(xiàng)目我基本不推薦新項(xiàng)目再用它起步。Cypress體驗(yàn)好API設(shè)計(jì)得對(duì)前端工程師非常友好支持實(shí)時(shí)重載和time travel調(diào)試測(cè)試跑起來(lái)還能邊跑邊看每步操作截圖。但它有一個(gè)硬傷只支持瀏覽器環(huán)境內(nèi)運(yùn)行跨瀏覽器覆蓋能力弱對(duì)多標(biāo)簽頁(yè)和iframe的支持也比較費(fèi)勁。如果你的項(xiàng)目是純Web端單頁(yè)面應(yīng)用Cypress是不錯(cuò)的選項(xiàng)。Playwright是我現(xiàn)在的主力。它最大的三個(gè)優(yōu)勢(shì)第一內(nèi)置了自動(dòng)等待機(jī)制不用手寫各種sleep和waitForTimeout腳本穩(wěn)定性顯著提升第二支持Chromium、Firefox、WebKit三套瀏覽器引擎一套用例可以同時(shí)覆蓋多個(gè)瀏覽器第三定位器API設(shè)計(jì)得極其優(yōu)雅getByRole、getByLabel這類語(yǔ)義化定位器直接解決了選擇器脆弱這個(gè)老大難問(wèn)題。配合trace viewer做失敗排查調(diào)試效率直接翻倍。兼容性和穩(wěn)定性放在一起對(duì)比結(jié)論就很明顯了。我見過(guò)太多團(tuán)隊(duì)在Selenium上耗費(fèi)大量精力維護(hù)selectors等到引入Playwright之后同樣的用例集穩(wěn)定率從85%提升到了98%以上。2.2 選型判斷維度框架選型不能只看技術(shù)名氣要結(jié)合實(shí)際項(xiàng)目情況。我一般會(huì)問(wèn)自己四個(gè)問(wèn)題逐個(gè)過(guò)一遍再做決定。第一個(gè)問(wèn)題項(xiàng)目主要形態(tài)是什么。純Web單頁(yè)應(yīng)用三個(gè)框架都不算難選但如果是企業(yè)內(nèi)部復(fù)雜的后臺(tái)系統(tǒng)表格多、彈窗多、iframe多Playwright的iframe管理和自動(dòng)等待優(yōu)勢(shì)就很突出。如果是混合應(yīng)用Web加桌面殼Cypress可能會(huì)因?yàn)榄h(huán)境限制踩到坑。第二個(gè)問(wèn)題團(tuán)隊(duì)的編程語(yǔ)言背景。Playwright官方支持TypeScript、JavaScript、Python、Java、.NET對(duì)前端團(tuán)隊(duì)來(lái)說(shuō)TS是標(biāo)配Cypress只支持JS/TSSelenium幾乎什么語(yǔ)言都能寫。如果團(tuán)隊(duì)是后端轉(zhuǎn)前端測(cè)試的Python版Playwright上手也很快。第三個(gè)問(wèn)題CI/CD的集成成本。Playwright官方提供Docker鏡像一個(gè)命令就能拉起帶全套瀏覽器依賴的測(cè)試環(huán)境在GitLab CI或GitHub Actions里集成非常順暢。Cypress需要額外處理它的cypress/browsers鏡像Selenium則需要自己維護(hù)selenium-grid成本更高。第四個(gè)問(wèn)題長(zhǎng)期維護(hù)的可持續(xù)性。測(cè)試代碼也是代碼是要伴隨項(xiàng)目活好幾年的。Playwright的自動(dòng)等待機(jī)制、trace viewer、UI mode這些調(diào)試工具能讓日常維護(hù)成本大幅下降。一個(gè)團(tuán)隊(duì)每天花一小時(shí)跟測(cè)試代碼搏斗和一個(gè)星期都不看一眼測(cè)試代碼維護(hù)體驗(yàn)天差地別。2.3 profile1測(cè)試環(huán)境的配置哲學(xué)做E2E測(cè)試一個(gè)很容易被忽視但極其重要的部分是環(huán)境配置管理。很多項(xiàng)目直接在代碼里寫死測(cè)試環(huán)境的地址結(jié)果在測(cè)試環(huán)境跑著沒(méi)問(wèn)題換到預(yù)發(fā)布環(huán)境就一臉懵為什么登錄不上為什么接口返回?cái)?shù)據(jù)不對(duì)我的做法是引入profile配置體系把環(huán)境差異全部收攏到獨(dú)立的配置文件里。以Playwright項(xiàng)目為例我維護(hù)了一套profiles目錄每個(gè)profile對(duì)應(yīng)一個(gè)運(yùn)行環(huán)境profile1測(cè)試環(huán)境test數(shù)據(jù)可以隨意造是日常跑全量回歸的主戰(zhàn)場(chǎng)profile2預(yù)發(fā)布環(huán)境staging數(shù)據(jù)相對(duì)干凈用于上線前的最后驗(yàn)證profile3本地環(huán)境dev配合mock數(shù)據(jù)使用日常開發(fā)聯(lián)調(diào)用每個(gè)profile文件里我會(huì)定義baseURL、apiBaseURL、adminAccount、regularUserAccount、testDataDir這些關(guān)鍵配置。運(yùn)行時(shí)通過(guò)環(huán)境變量切換當(dāng)前生效的profile執(zhí)行命令類似E2E_PROFILEprofile1 npx playwright test E2E_PROFILEprofile2 npx playwright test這套設(shè)計(jì)帶來(lái)的直接收益是測(cè)試代碼本身不感知環(huán)境差異不管在哪個(gè)環(huán)境跑同一套用例都能正確登錄、正確填數(shù)據(jù)、正確斷言。環(huán)境相關(guān)的臟活累活全被profile層消化掉了再加環(huán)境對(duì)應(yīng)的secret.json配置就可以放心地在不同環(huán)境間切換執(zhí)行。3. 從零搭建E2E測(cè)試的完整實(shí)操記錄3.1 環(huán)境初始化與依賴安裝先說(shuō)明一下我推薦的底座組合Node.js 18npm或yarn包管理器Playwright測(cè)試框架TypeScript語(yǔ)言。整個(gè)初始化流程每一步都要清楚不然后面出問(wèn)題你都不知道去哪查。以我之前搭建的一個(gè)中后臺(tái)項(xiàng)目為例。項(xiàng)目用npm管理依賴執(zhí)行初始化命令mkdir e2e-tests cd e2e-tests npm init -y npm install -D playwright/test npx playwright installnpx playwright install這一步容易出坑。它會(huì)下載對(duì)應(yīng)版本的瀏覽器內(nèi)核包括Chromium、Firefox、WebKit如果你在公司代理環(huán)境下執(zhí)行可能因?yàn)榫W(wǎng)絡(luò)限制下載不完整。我的做法是先確認(rèn)下載源能正常訪問(wèn)如果下載失敗去看看~/.cache/ms-playwright目錄下的文件是不是完整不完整就刪掉重新執(zhí)行安裝命令。接著創(chuàng)建Playwright配置文件playwright.config.tsimport { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, fullyParallel: true, workers: 4, retries: process.env.CI ? 2 : 0, reporter: [ [list], [html, { open: never }], [json, { outputFile: results/report.json }] ], use: { baseURL: process.env.E2E_BASE_URL || http://localhost:3000, headless: true, screenshot: only-on-failure, trace: retain-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, ], });幾個(gè)我刻意配置的點(diǎn)retries在CI環(huán)境設(shè)為2本地跑不重試這樣既能應(yīng)對(duì)偶發(fā)網(wǎng)絡(luò)波動(dòng)又不會(huì)掩蓋本地問(wèn)題trace: retain-on-failure只有在用例失敗時(shí)才保留trace避免磁盤空間被大量無(wú)用的trace文件占滿fullyParallel打開后多個(gè)文件能并行跑整個(gè)回歸時(shí)間能顯著縮短。3.2 定位器選擇穩(wěn)定優(yōu)先的實(shí)踐寫E2E測(cè)試最核心的實(shí)操技能就是選擇合適的定位器。定位器選得好測(cè)試腳本能穩(wěn)定跑幾個(gè)月不改選得不好每次頁(yè)面樣式一調(diào)整腳本就嘩啦啦倒一片。我用了這么多年的經(jīng)驗(yàn)定位器的優(yōu)先級(jí)是這樣排的語(yǔ)義化定位器優(yōu)先于結(jié)構(gòu)定位器結(jié)構(gòu)定位器優(yōu)先于文本定位器文本定位器優(yōu)先于CSS/XPATH。換句話說(shuō)getByRole(button, { name: 提交 })比page.locator(.submit-btn)好得多。因?yàn)檎Z(yǔ)義化定位器依賴的是元素的角色和可訪問(wèn)名稱這跟用戶感知是一致的前端重構(gòu)DOM只是改了class名也不會(huì)影響它。在實(shí)際項(xiàng)目中我遇到的最棘手場(chǎng)景是動(dòng)態(tài)生成的表格和列表。數(shù)據(jù)是接口返回的每一行的DOM結(jié)構(gòu)理論上相同但行內(nèi)的操作按鈕需要精確定位到某一行。這時(shí)候我通常會(huì)組合使用定位方式外層用getByRole(row)拿到行集合然后通過(guò)filter({ hasText: 訂單號(hào)xxx })篩出目標(biāo)行再在行內(nèi)用getByRole(button, { name: 詳情 })操作按鈕。const targetRow page .getByRole(row) .filter({ hasText: SO-20240601-001 }); await targetRow.getByRole(button, { name: 詳情 }).click();這種寫法對(duì)抗DOM結(jié)構(gòu)變化的能力非常強(qiáng)也是我在團(tuán)隊(duì)里反復(fù)強(qiáng)調(diào)的規(guī)范。寫測(cè)試的時(shí)候想清楚用戶真正是怎么找到這個(gè)元素的才能穩(wěn)定又準(zhǔn)確地定位到它。3.3 環(huán)境profile與用例組織寫完配置和定位器接下來(lái)是把profile和測(cè)試用例組織起來(lái)。Profile不僅是基礎(chǔ)配置它還能決定測(cè)試數(shù)據(jù)的選擇策略。我在profile1測(cè)試環(huán)境里通常會(huì)配置完整的測(cè)試賬號(hào)組一個(gè)超管賬號(hào)、一個(gè)普通用戶、一個(gè)只讀用戶。測(cè)試用例在執(zhí)行時(shí)從當(dāng)前profile中讀取對(duì)應(yīng)的賬號(hào)信息而不是在用例里硬編碼。比如下面的profiles/profile1.json{ name: profile1, env: test, baseURL: https://test.example.com, accounts: { admin: { username: e2e_admin, password: encoded-pass }, regular: { username: e2e_user, password: encoded-pass } }, paymentMockEnabled: true, couponSeedData: data/coupons-test.json }然后寫一個(gè)讀取profile的工具函數(shù)在global setup階段一次性加載到全局變量里測(cè)試用例直接引用不用每個(gè)用例反復(fù)讀文件。測(cè)試用例的組織上我遵循的是按業(yè)務(wù)模塊建目錄、按核心場(chǎng)景建文件的方式。比如tests/auth/login.spec.ts放登錄相關(guān)用例tests/checkout/place-order.spec.ts放下單相關(guān)用例。每個(gè)用例內(nèi)部再用test.step把關(guān)鍵操作步驟分組這樣失敗時(shí)能非常直觀地看到卡在哪一步。import { test, expect } from playwright/test; test(普通用戶能完成完整下單流程, async ({ page }) { await test.step(登錄系統(tǒng), async () { await page.goto(/login); await page.getByLabel(用戶名).fill(process.env.E2E_ADMIN_USER); await page.getByLabel(密碼).fill(process.env.E2E_ADMIN_PASS); await page.getByRole(button, { name: 登錄 }).click(); await expect(page).toHaveURL(/\/dashboard/); }); await test.step(將商品加入購(gòu)物車, async () { await page.goto(/product/1001); await page.getByRole(button, { name: 加入購(gòu)物車 }).click(); }); await test.step(提交訂單并完成支付, async () { await page.getByRole(button, { name: 去結(jié)算 }).click(); await page.getByRole(button, { name: 提交訂單 }).click(); await expect(page.getByText(支付成功)).toBeVisible(); }); });這套組織方式的好處很明顯測(cè)試的語(yǔ)義層級(jí)和業(yè)務(wù)層級(jí)完全對(duì)齊新同學(xué)看測(cè)試代碼就像讀需求文檔一樣清楚。3.4 跑起來(lái)執(zhí)行、報(bào)告與調(diào)試一切就緒之后第一次執(zhí)行我建議先單文件跑一遍確認(rèn)環(huán)境沒(méi)問(wèn)題再全量跑。Playwright在這方面有一個(gè)很有用的--debug模式可以逐步執(zhí)行每個(gè)操作并實(shí)時(shí)查看頁(yè)面快照。npx playwright test tests/auth/login.spec.ts --debug全量執(zhí)行時(shí)配置文件里已經(jīng)設(shè)好了4個(gè)worker并行整個(gè)測(cè)試套件的執(zhí)行時(shí)間取決于用例數(shù)量和操作復(fù)雜度。我在一個(gè)中等規(guī)模的后臺(tái)系統(tǒng)上全量大概60個(gè)用例耗時(shí)為10到15分鐘在可接受范圍內(nèi)。運(yùn)行完的產(chǎn)物是關(guān)鍵HTML報(bào)告、JSON報(bào)告、失敗截圖、失敗trace。HTML報(bào)告會(huì)在playwright-report目錄生成里面能看到每個(gè)用例的執(zhí)行時(shí)長(zhǎng)、每一步的通過(guò)狀態(tài)、失敗時(shí)的網(wǎng)絡(luò)請(qǐng)求信息。最實(shí)用的是trace文件可以直接在Playwright的trace查看器里回放整個(gè)測(cè)試過(guò)程的頁(yè)面狀態(tài)、網(wǎng)絡(luò)請(qǐng)求和瀏覽器控制臺(tái)日志排查失敗原因就像回看錄像一樣清晰。遇到失敗用例我的第一反應(yīng)從來(lái)不是去改代碼重跑而是先打開trace從頭看到尾理解瀏覽器到底經(jīng)歷了什么再做判斷。有時(shí)候是應(yīng)用真的出了bug有時(shí)候是測(cè)試數(shù)據(jù)被污染少數(shù)情況下才是選擇器寫得不對(duì)。分清這三種情況修復(fù)思路就會(huì)非常明確。4. 那些年我踩過(guò)的E2E測(cè)試坑4.1 測(cè)試不穩(wěn)定的頭號(hào)元兇選擇器如果E2E測(cè)試只能記住一個(gè)避坑經(jīng)驗(yàn)我一定會(huì)說(shuō)永遠(yuǎn)不要再依賴動(dòng)態(tài)變化的選擇器。這里說(shuō)的動(dòng)態(tài)變化包括前端框架渲染的隨機(jī)id、點(diǎn)擊后動(dòng)態(tài)替換的class名、根據(jù)用戶信息變化的人的工號(hào)或訂單號(hào)。我最痛的一次教訓(xùn)是一個(gè)列表頁(yè)的編輯按鈕一開始用page.locator(.btn-edit)定位。下個(gè)迭代產(chǎn)品經(jīng)理讓UI調(diào)整了按鈕樣式class從btn-edit變成了btn-edit--blue整個(gè)套件掛了8個(gè)用例。后來(lái)全部改成getByRole(button, { name: 編輯 })從此這類問(wèn)題徹底消失。還有一類坑是要特別注意的頁(yè)面出現(xiàn)了重復(fù)的文本導(dǎo)致getByText(確認(rèn))匹配到了兩個(gè)元素測(cè)試直接報(bào)strict mode violation。這種問(wèn)題在列表頁(yè)和多標(biāo)簽頁(yè)里特別常見。解決辦法是先用更精確定位器縮小范圍比如先定位到目標(biāo)卡片區(qū)域再在里面按文本查找子元素。4.2 網(wǎng)絡(luò)請(qǐng)求等待的隱性陷阱剛接觸Playwright那陣子我總擔(dān)心頁(yè)面異步請(qǐng)求沒(méi)完成就執(zhí)行下一步于是到處寫page.waitForTimeout(3000)結(jié)果用例變得又慢又脆。后來(lái)才搞清楚Playwright的自動(dòng)等待機(jī)制本來(lái)就覆蓋了大部分情況點(diǎn)擊按鈕后它會(huì)等待目標(biāo)元素變得可交互斷言時(shí)它會(huì)自動(dòng)輪詢直到條件成立或超時(shí)。真正需要手動(dòng)處理的是那些頁(yè)面加載了但接口還在pending的情況。我后來(lái)整理了一套更可靠的等待策略優(yōu)先用導(dǎo)航等待比如點(diǎn)擊后期望跳轉(zhuǎn)新的URL就寫await page.waitForURL(**/order/success)其次是等待特定元素可見比如文字?jǐn)嘌曰蛟劁秩尽Ｖ挥械搅藢?shí)在沒(méi)辦法的場(chǎng)景比如某個(gè)第三方組件的行為無(wú)法被常規(guī)期望覆蓋我才考慮用expect.poll做輪詢等待。千萬(wàn)不要迷信固定等待我見過(guò)太多項(xiàng)目因?yàn)閷懥舜罅縲aitForTimeout導(dǎo)致測(cè)試套件又慢又飄。等得久不等于等得對(duì)等對(duì)應(yīng)該是等一個(gè)明確的條件。4.3 并行執(zhí)行下的一地雞毛并行執(zhí)行本來(lái)是提升效率的好事但有一個(gè)前置條件沒(méi)滿足并行就會(huì)變成災(zāi)難——那就是測(cè)試數(shù)據(jù)隔離。早期的項(xiàng)目里登錄用同一個(gè)賬號(hào)下單用同一組測(cè)試商品數(shù)據(jù)。一旦并行跑起來(lái)多個(gè)用例同時(shí)往購(gòu)物車?yán)锛由唐?、同時(shí)提交訂單彼此覆蓋數(shù)據(jù)用例各種失敗。這個(gè)問(wèn)題排查起來(lái)特別浪費(fèi)時(shí)間因?yàn)槭≡蚩瓷先ズ翢o(wú)規(guī)律。我的解決方案是用獨(dú)立測(cè)試數(shù)據(jù)加賬號(hào)池。每個(gè)用例執(zhí)行前通過(guò)API接口創(chuàng)建一份專屬數(shù)據(jù)用例結(jié)束后再通過(guò)測(cè)試專用清理接口刪除掉。這一步必須在每個(gè)用例的setup階段完成不依賴上一個(gè)用例留下的任何狀態(tài)。這樣并行再多路數(shù)據(jù)也是各玩各的互不干擾。賬號(hào)池的維護(hù)也有小技巧。通常我不會(huì)真的創(chuàng)建幾百個(gè)賬號(hào)而是準(zhǔn)備固定數(shù)量的幾組賬號(hào)每組賬號(hào)使用不同的數(shù)據(jù)集。測(cè)試執(zhí)行時(shí)用隨機(jī)數(shù)決定當(dāng)前用例綁定哪一組然后在這組內(nèi)操作。遇到執(zhí)行失敗或數(shù)據(jù)污染就通過(guò)專門的恢復(fù)任務(wù)把這組賬號(hào)重置到初始狀態(tài)。4.4 成本失控的必修課用例瘦身E2E測(cè)試寫多了之后我逐漸意識(shí)到一個(gè)事實(shí)不是用例越多越好而是每一條用例都必須有它存在的理由。E2E測(cè)試的成本是顯性的——它要真實(shí)驅(qū)動(dòng)瀏覽器要構(gòu)造完整的數(shù)據(jù)鏈路要消耗CI資源維護(hù)成本遠(yuǎn)超單元測(cè)試和接口測(cè)試。我給用例瘦身的兩個(gè)核心原則。第一堅(jiān)持二八法則只覆蓋最有業(yè)務(wù)價(jià)值的核心路徑比如登錄、注冊(cè)、下單、支付、退款、用戶權(quán)限管理這類流程一些邊緣邏輯比如某個(gè)表單的必填校驗(yàn)提示文案放到組件測(cè)試?yán)锶ヲ?yàn)證就好。第二每個(gè)用例只驗(yàn)證一個(gè)核心目標(biāo)不要在一路流程里塞進(jìn)七八個(gè)斷言點(diǎn)。斷言太多會(huì)讓用例失敗時(shí)的排查范圍變得模糊也不利于局部修復(fù)。把長(zhǎng)鏈路的E2E和輕量級(jí)的組件測(cè)試合理分工整體成本才能被控制住。另外定期清理重復(fù)用例也很重要。團(tuán)隊(duì)里不同人寫的用例經(jīng)常會(huì)出現(xiàn)功能重疊比如有人寫了通過(guò)登錄頁(yè)面登錄后進(jìn)入工作臺(tái)另外一個(gè)人又寫了從工作臺(tái)入口跳轉(zhuǎn)登錄頁(yè)登錄后返回。這類用例保留一條就夠了跑兩遍的結(jié)果只是多燒一遍CI資源沒(méi)有帶來(lái)額外保障。我在實(shí)際使用中還有一個(gè)體會(huì)E2E測(cè)試在絕大多數(shù)情況下應(yīng)該跑在干凈的測(cè)試環(huán)境上而不是對(duì)著本地mock數(shù)據(jù)跑。Mock數(shù)據(jù)能模擬成功路徑但模擬不出真實(shí)接口的響應(yīng)延遲、網(wǎng)絡(luò)抖動(dòng)、數(shù)據(jù)庫(kù)異常這些真實(shí)世界的煙火氣。只在某些特定場(chǎng)景下——比如第三方支付平臺(tái)不能在測(cè)試環(huán)境真實(shí)調(diào)用時(shí)——才去對(duì)極少數(shù)外部依賴做mock。這既保證了測(cè)試的真實(shí)性又避免了把整套測(cè)試環(huán)境搞得太復(fù)雜。還有一個(gè)值得說(shuō)的經(jīng)驗(yàn)是E2E測(cè)試的維護(hù)不能靠某一個(gè)人要和功能開發(fā)流程綁定起來(lái)。每次需求評(píng)審時(shí)評(píng)估一下哪些核心場(chǎng)景需要新增E2E用例代碼審查時(shí)順帶看一下相關(guān)測(cè)試腳本是否同步更新。讓測(cè)試代碼和業(yè)務(wù)代碼同步演進(jìn)而非事后補(bǔ)寫長(zhǎng)期下去維護(hù)成本才是可控的。工具鏈再成熟框架再自動(dòng)化最終人還是核心。把E2E測(cè)試沉淀成團(tuán)隊(duì)的一種工作習(xí)慣像寫功能代碼一樣認(rèn)真對(duì)待測(cè)試代碼它回報(bào)給你的是發(fā)版時(shí)再也不需要提心吊膽的那份踏實(shí)。