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