化：10個(gè)實(shí)用技巧助你縮短測試耗時(shí))
團(tuán)隊(duì)最近把前端端到端測試套件從 45 分鐘壓到了 12 分鐘核心就是用 Playwright 性能優(yōu)化那一套方法論重新梳理了一遍用例。說實(shí)話做自動化測試的人都有同感用例寫出來不難難得是跑得又快又穩(wěn)。尤其是當(dāng)用例數(shù)量上了三位數(shù)之后每次跑完看一眼耗時(shí)表心里那叫一個(gè)復(fù)雜。這篇文章整理的就是這些實(shí)測下來真正有用的干貨一共 10 個(gè)實(shí)用技巧從并行執(zhí)行、資源攔截、等待策略到數(shù)據(jù)預(yù)置基本覆蓋了 Playwright 縮短測試時(shí)間的主要方向。適合正在被測試耗時(shí)折磨的測試開發(fā)、前端工程化同學(xué)也適合剛上手 Playwright 但不想一上來就踩坑的新手。新手最需要知道的一點(diǎn)是Playwright 并不是一個(gè)慢工具它慢在“默認(rèn)配置”。瀏覽器啟動、圖片加載、動畫等待、trace 錄制、串行執(zhí)行這些默認(rèn)行為疊加在一起測一個(gè)頁面動輒十幾秒。優(yōu)化思路其實(shí)就一句話——不加載的資源不加載不必要的時(shí)間不等待能并行的用例不串行。1. 先弄清瓶頸測試慢在哪優(yōu)化才有方向1.1 我踩過的性能坑與常見瓶頸分布在做優(yōu)化之前我先花了一個(gè)下午給整個(gè)測試套件做了耗時(shí)畫像。這一步非常重要因?yàn)椤案杏X慢”和“真正慢在哪”往往是兩回事。我當(dāng)時(shí)的測試套件里單用例耗時(shí)有高有低高的能到 40 秒低的也要 6 秒平均下來跑一輪要 45 分鐘。耗時(shí)畫像統(tǒng)計(jì)下來瓶頸主要是這幾個(gè)啟動和關(guān)閉瀏覽器實(shí)例的時(shí)間占了大約 15%。這個(gè)問題在測試文件數(shù)量多的時(shí)候尤其明顯因?yàn)槊總€(gè)測試文件默認(rèn)都會啟動自己的瀏覽器實(shí)例。頁面加載時(shí)圖片、字體、視頻、第三方統(tǒng)計(jì)腳本全部加載多了不少等待時(shí)間這部分占了大概 20%。用例里大量使用sleep(3)或者固定等待以及一些 Web 應(yīng)用交互動畫要等 400ms 或 1s這類硬編碼等待疊加起來占到了 25%。數(shù)據(jù)準(zhǔn)備全靠 UI 操作一個(gè)創(chuàng)建流程跑一遍要 8 到 12 秒三個(gè)用例就快半分鐘了這占了 10%。CI 上還是單機(jī)串行執(zhí)行CPU 和內(nèi)存資源實(shí)際只用了四分之一。這個(gè)分布其實(shí)很典型。網(wǎng)絡(luò)帶寬越差、測試環(huán)境響應(yīng)越慢的環(huán)境里瀏覽器啟動和資源加載的占比還會更高。所以優(yōu)化后我立刻就能看到測試套件單跑執(zhí)行速度提升了大概 2 倍再疊加并行執(zhí)行才達(dá)到最終 12 分鐘的效果。1.2 十個(gè)技巧總覽與優(yōu)先級劃分我建議不要一開始就把十個(gè)技巧全部鋪開而是先把收益最大的幾個(gè)落地。下面這張表是我自己整理的一個(gè)優(yōu)先級參考后文會逐個(gè)展開。技巧核心動作預(yù)估收益實(shí)施成本1. 并行執(zhí)行Pytest 多 Worker 并發(fā)跑測試文件接近線性提升低2. CI 分片按 CI 機(jī)器分片并行接近線性提升低3. 資源攔截?cái)r截圖片、字體、媒體請求減少 20% ~ 40% 加載等待低4. 請求監(jiān)聽與超時(shí)監(jiān)聽請求合理硬超時(shí)快速失敗減少單用例無效等待低5. 去掉固定 sleep改為自動等待和輪詢斷言減少 20% ~ 30% 等待中6. 選擇器策略用 getByRole、getByText 替代脆弱選擇器提高定位穩(wěn)定性間接提速低7. 瀏覽器啟動參數(shù)headless、禁用 GPU、禁用沙箱、合屏渲染單用例節(jié)省 1~3 秒低8. 復(fù)用上下文與 API 預(yù)置數(shù)據(jù)用 request 上下文預(yù)置測試數(shù)據(jù)減少 30% 以上的 UI 前置操作中9. 診斷功能按需開啟關(guān)閉 trace、video只在失敗時(shí)錄制節(jié)省數(shù)秒到數(shù)十秒極低10. 緩存與語義化用例fixture 級緩存AI 語義自動生成用例長期維護(hù)收益高較高這十個(gè)技巧不是孤立使用的很多是配合關(guān)系。比如第 3 個(gè)資源攔截和第 4 個(gè)請求監(jiān)聽通常一起用第 8 個(gè) API 預(yù)置數(shù)據(jù)可以為第 1 個(gè)并行執(zhí)行減少很多不穩(wěn)定因素。下面我按章節(jié)把每個(gè)技巧的“為什么”和“怎么做”講透。2. 并行執(zhí)行與瀏覽器實(shí)例策略第一筆大收益2.1 Pytest 插件與多 Worker 配置如果你的測試框架用的是 Pytest那一定不要錯(cuò)過pytest-xdist。它在不改變用例代碼的前提下讓多個(gè) Worker 進(jìn)程并行跑不同的測試文件這是 Playwright 縮短測試時(shí)間最立竿見影的一招。配置起來很簡單。先在項(xiàng)目里安裝依賴pip install pytest-xdist然后在 pytest.ini 里加一行或者命令行直接指定-n auto[pytest] addopts -n autoauto會根據(jù)機(jī)器的 CPU 邏輯核數(shù)自動決定 Worker 數(shù)量。我的開發(fā)機(jī)是 8 核 16 線程實(shí)測 4 個(gè) Worker 時(shí)性價(jià)比最高因?yàn)闉g覽器進(jìn)程本身也要吃內(nèi)存開 8 個(gè) Worker 會導(dǎo)致內(nèi)存吃緊。在 CI 上我反而推薦先定一個(gè)保守?cái)?shù)值比如-n 4再根據(jù)內(nèi)存余量往上調(diào)。一個(gè)重要前提是并行意味著每個(gè) Worker 進(jìn)程都有自己的瀏覽器實(shí)例如果你的用例之間共享了本地?cái)?shù)據(jù)庫文件、共享了同一份靜態(tài)臨時(shí)文件或者依賴執(zhí)行順序那要先處理好這些隔離問題。pytest-xdist 的設(shè)計(jì)原則是“測試文件級并行”所以同一個(gè)文件里的用例默認(rèn)還是串行執(zhí)行的這就很安全。2.2 分片策略與 CI 資源利用如果你的 CI 機(jī)器不止一臺那還可以用 Playwright 官方的分片能力。分片比多 Worker 更徹底它是把整個(gè)測試集合按指定數(shù)量切成多個(gè)片每臺機(jī)器跑其中一部分。常見的做法是 GitHub Actions 里用matrix配一個(gè)并發(fā)矩陣strategy: fail-fast: false matrix: shardIndex: [1, 2, 3, 4]然后在執(zhí)行腳本里加npx playwright test --shard${{ matrix.shardIndex }}/4這樣 4 臺機(jī)器并行跑每一臺跑的用例不會重復(fù)。要注意的是分片并不保證每片用時(shí)完全均勻因?yàn)槊科锏挠美写笥行?。如果你有特別重的用例可以手動給它們標(biāo)上test.describe.configure({ mode: serial })或者放到獨(dú)立文件里避免一個(gè)重用例拖垮整片。我個(gè)人在 CI 上的組合拳是先把用例按業(yè)務(wù)模塊分成幾個(gè)測試目錄再把每個(gè)目錄拆成獨(dú)立 CI JobJob 內(nèi)再用-n 4做二級并行。兩層并行下來整個(gè)流水線從原來的 45 分鐘降到 15 分鐘以內(nèi)而且單個(gè) Job 的資源使用率非常平穩(wěn)。2.3 瀏覽器啟動參數(shù)與復(fù)用上下文默認(rèn)配置下 Playwright 在無頭模式會做很多防御性工作比如啟用 GPU 進(jìn)程、沙箱、硬件加速判斷。對于測試來說這些大部分可以關(guān)掉。下面是運(yùn)行速度影響最大的幾個(gè)啟動參數(shù)browser await playwright.chromium.launch( headlessTrue, args[ --disable-gpu, --disable-dev-shm-usage, --no-sandbox, --disable-extensions, --disable-background-timer-throttling, --disable-backgrounding-occluded-windows, --disable-renderer-backgrounding, --disable-ipc-flooding-protection, ] )這里解釋一下關(guān)鍵參數(shù)的作用--disable-gpu無頭模式本來就不需要 GPU 渲染加速關(guān)掉可避免 GPU 進(jìn)程崩潰導(dǎo)致的重試。--disable-dev-shm-usage在 Docker 容器里非常關(guān)鍵否則/dev/shm太小可能直接讓瀏覽器閃退。--disable-background-timer-throttling頁面切到后臺時(shí)瀏覽器會降低定時(shí)器頻率關(guān)掉后能保證前端輪詢邏輯在并發(fā)下正常工作。--no-sandbox僅在信任的測試環(huán)境里用核心原因是容器環(huán)境默認(rèn)沒有權(quán)限創(chuàng)建 sandbox。再想進(jìn)一步降開銷可以復(fù)用browser_context。多組用例共用同一個(gè)瀏覽器實(shí)例但是每個(gè)用例獨(dú)立context這樣能省掉每次啟動瀏覽器的幾秒鐘。簡單理解就是瀏覽器進(jìn)程只啟動一次頁面之間互不干擾的隔離由 context 保證。3. 網(wǎng)絡(luò)層攔截與資源瘦身少加載就是快3.1 用 route 攔截非關(guān)鍵資源網(wǎng)頁里總有那么一類資源對 UI 測試沒有任何影響但下載起來特別浪費(fèi)時(shí)間大圖、背景圖、字體文件、視頻、埋點(diǎn)統(tǒng)計(jì)腳本。Playwright 提供的route攔截能力可以讓你在請求發(fā)出前就把它直接中止或改寫為空響應(yīng)。最常見做法是攔截掉圖片和字體。以一個(gè)后臺管理系統(tǒng)為例頁面加載 80% 的流量都來自圖片和圖標(biāo)字體攔截之后單頁面加載時(shí)間從 6 秒降到 2.8 秒。代碼如下import re async def block_unused_resources(route): url route.request.url if route.request.resource_type in [image, font, media]: await route.abort() elif re.search(r\.(png|jpg|jpeg|gif|svg|woff|woff2|ttf)$, url): await route.abort() else: await route.continue_() await page.route(**/*, block_unused_resources)如果你希望圖片不加載但頁面不報(bào)錯(cuò)可以不用abort()而是返回一個(gè)空圖片的 base64 響應(yīng)await route.fulfill( status200, content_typeimage/png, bodybase64.b64decode(EMPTY_IMAGE_BASE64) )這樣對頁面邏輯的影響最小。尤其是某些前端組件會用圖片的onload事件做后續(xù)渲染這時(shí)候直接 abort 可能導(dǎo)致按鈕一直處于 loading 狀態(tài)而 fulfill 一個(gè) 1x1 像素圖就不會觸發(fā)這類問題。對于第三方統(tǒng)計(jì)腳本、廣告 SDK 這類你根本不需要的資源類型直接按域名攔截更干凈import re async def block_third_party(route): url route.request.url if any(domain in url for domain in [google-analytics.com, googletagmanager.com, doubleclick.net]): await route.abort() else: await route.continue_()攔截后有兩個(gè)細(xì)節(jié)值得注意。第一個(gè)是某些站點(diǎn)的接口會校驗(yàn)資源完整性圖片缺失可能導(dǎo)致前端接口調(diào)用被閾值限制第二個(gè)是 Electron 或內(nèi)嵌瀏覽器環(huán)境下字體缺失時(shí)中文會直接變成方塊。所以建議在本地開發(fā)模式下不要啟用全局?jǐn)r截只在 CI 或者測試環(huán)境里開。3.2 請求監(jiān)聽與超時(shí)治理除了攔截你還可以通過監(jiān)聽請求來判斷頁面是否真的加載完成。很多前端框架在首屏渲染時(shí)會同時(shí)發(fā)起多個(gè)接口請求但頁面的load事件觸發(fā)得比接口返回更早導(dǎo)致你一進(jìn)頁面去點(diǎn)擊按鈕結(jié)果接口還沒回來數(shù)據(jù)是空的按鈕點(diǎn)了沒反應(yīng)——這是測試不穩(wěn)定的最大來源之一。我的做法是把“關(guān)鍵接口請求完成”當(dāng)成一個(gè)更可靠的頁面就緒信號。先用page.on(request)記錄下接口請求再用page.wait_for_response等待對應(yīng)接口返回async with page.expect_response(lambda response: /api/v1/order/list in response.url and response.status 200) as resp_info: await page.goto(https://example.com/orders) response await resp_info.value配合超時(shí)治理我會給每個(gè)這種等待都設(shè)置一個(gè)明確的時(shí)間上限。默認(rèn)的 30 秒全局超時(shí)對慢用例太寬容了很多無效等待就是這么浪費(fèi)掉的。在 Playwright 的 config 里可以這樣收斂# playwright.config.py config { timeout: 15_000, expect: {timeout: 5_000}, }expect里的 5 秒是每個(gè)expect輪詢的默認(rèn)超時(shí)。這樣某個(gè)按鈕 5 秒內(nèi)不出現(xiàn)就直接失敗而不是傻傻地等滿 30 秒。我在實(shí)際項(xiàng)目里還見過不少接口 10 秒才返回的場景這類“真慢”要單獨(dú)在測試數(shù)據(jù)層處理而不是把全局超時(shí)拉高否則所有用例都會為它買單。3.3 攔截策略的邊界與注意事項(xiàng)資源攔截雖然收益大但也不是攔得越多越好。我踩過最深的坑是攔截某個(gè)品牌官網(wǎng)的字體文件之后頁面文字全部變成系統(tǒng)默認(rèn)字體結(jié)果某個(gè)按鈕的寬度變化導(dǎo)致后續(xù)點(diǎn)擊偏移用例反復(fù)失敗。排查了一個(gè)多小時(shí)才意識到是字體文件被攔掉了。所以做資源攔截要有一個(gè)基本判斷原則只攔截那些“不影響行為邏輯、只影響觀感”的資源。圖片、視頻、字體、埋點(diǎn)腳本通常是安全的但接口請求千萬不能隨便攔截因?yàn)槟鞘菢I(yè)務(wù)邏輯的命脈。還要注意route的匹配規(guī)則是按注冊順序執(zhí)行的。如果你先注冊了某個(gè) API 路徑的route.continue_()又注冊了全局資源的攔截那 API 路徑的 rule 會先匹配到就不會被誤傷。建議把精確路徑的攔截放在前面把資源類型的攔截放在最后這樣規(guī)則更可控。另外如果你同時(shí)用page.route(**/*, handler)監(jiān)聽所有請求并在 handler 里做了大量邏輯那也會帶來輕微的性能損耗。實(shí)測下來一個(gè) handler 里有字符串正則匹配還好但如果每次請求都做異步 IO比如查數(shù)據(jù)庫判斷是否攔截請求并發(fā)高時(shí)會產(chǎn)生明顯排隊(duì)。所以我建議 handler 保持純函數(shù)風(fēng)格不要在里面做耗時(shí)操作。4. 等待與選擇器策略把隱性等待變成精準(zhǔn)等待4.1 自動等待機(jī)制與過期固定等待Playwright 和 Selenium 最大的不同就是它內(nèi)置了自動等待。每次執(zhí)行click、fill、press這些操作之前Playwright 會先去檢查元素是否“可操作”比如是否可見、是否穩(wěn)定、是否接收入口事件。這個(gè)機(jī)制本身不慢慢的是大家拿到 Playwright 后仍然習(xí)慣性加上time.sleep()。這里要重點(diǎn)說清楚一個(gè)反直覺的點(diǎn)在 Playwright 里無腦加time.sleep(2)不僅不會讓用例更穩(wěn)定反而會掩蓋真實(shí)前端狀態(tài)變化導(dǎo)致測試和開發(fā)之間反饋?zhàn)兟?。更好的方式是依?Playwright 的 actionability 檢查再用expect去做狀態(tài)輪詢。比如等待某個(gè) loading 狀態(tài)消失await page.goto(https://example.com/order) await expect(page.locator(.loading)).to_be_hidden(timeout10_000) await page.get_by_role(button, name提交訂單).click()它會在 10 秒內(nèi)持續(xù)輪詢元素隱藏的瞬間就繼續(xù)往下執(zhí)行平均等待時(shí)間可能只需要幾百毫秒而不是固定的 2 秒。相比sleep這種方式的耗時(shí)是動態(tài)的、真實(shí)的。我見過一個(gè)有意思的極端案例某個(gè)用例里寫了四處sleep(3)優(yōu)化之后改成自動等待單用例從 16 秒直接降到 7 秒。原因很簡單前端在本地環(huán)境渲染只需要 500ms但測試腳本固定睡了 3 秒白白浪費(fèi)了 2.5 秒。4.2 用 getBy 系列選擇器替代脆弱選擇器選擇器本身不直接決定測試快慢但它決定了用例的一次通過率。一次通過率低就意味著要反復(fù)重試跑整體耗時(shí)自然就上去了。Playwright 官方推薦的getByRole、getByText、getByLabel這些基于可訪問性語義的選擇器比 CSS 類名選擇器穩(wěn)定得多也更貼近真實(shí)用戶操作。舉個(gè)例子。老的 CSS 寫法await page.locator(.btn-primary.btn-large).click()只要前端把類名從btn-primary改成btn-main用例就掛了。換成await page.get_by_role(button, name立即支付).click()前端怎么改樣式類名都不影響這個(gè)按鈕的定位。再比如輸入框用await page.get_by_label(用戶名).fill(tester)它會自動匹配 label 關(guān)聯(lián)的 input比硬寫 CSS 路徑健壯很多。如果項(xiàng)目對可訪問性支持不好很多元素沒有role或者 label那至少也要避免使用多層嵌套的長鏈 CSS。我的原則是“能不用 XPath 就不用 XPath”XPath 里一旦包含下標(biāo)比如//div[3]/div[2]/buttonDOM 結(jié)構(gòu)一變就直接失效。順手提一下playwright codegen。你可以在瀏覽器里像普通用戶一樣操作一遍它會自動生成對應(yīng)的選擇器代碼省去手工寫選擇器的時(shí)間。生成的代碼不一定最優(yōu)但可以作為起點(diǎn)對快速搭用例很有幫助。4.3 網(wǎng)絡(luò)空閑與元素可見性等待的取舍Playwright 還提供了page.wait_for_load_state(networkidle)意思是一直等到 500ms 內(nèi)沒有網(wǎng)絡(luò)連接才繼續(xù)。這個(gè)概念聽著很理想實(shí)際操作里要慎用因?yàn)楹芏囗撁鏁休喸兘涌凇ebsocket 長連接或者第三方統(tǒng)計(jì)腳本每幾秒發(fā)一次請求導(dǎo)致networkidle永遠(yuǎn)等不到。我的經(jīng)驗(yàn)是只有在你明確知道頁面沒有后臺輪詢且所有關(guān)鍵接口都在首屏觸發(fā)完后才使用networkidle。否則優(yōu)先用expect(response)等待關(guān)鍵接口再用expect(locator).to_be_visible()等待關(guān)鍵元素。還有一種“邊操作邊輪詢”的思路。比如打開一個(gè)列表頁你需要等列表數(shù)據(jù)渲染出來以后再搜索?？梢赃@樣await page.goto(https://example.com/list) await expect(page.get_by_text(共 1000 條記錄)).to_be_visible()等待具體內(nèi)容出現(xiàn)遠(yuǎn)比等待“網(wǎng)絡(luò)空閑”要更貼近業(yè)務(wù)語義。換成白話就是你不要等整個(gè)廚房都安靜下來才知道飯做好了你只需要看到菜端上桌就可以了。5. 前置數(shù)據(jù)與診斷開銷減少 UI 操作和日志成本5.1 用 API 預(yù)置數(shù)據(jù)替代 UI 前置流程很多用例其實(shí)存在大量重復(fù)的前置操作。比如測一個(gè)“訂單列表搜索”功能正好需要先創(chuàng)建一個(gè)訂單測“訂單詳情”時(shí)又需要一個(gè)已支付訂單作為前置條件。傳統(tǒng)做法是讓腳本從登錄開始一路點(diǎn)按鈕、填表單、提交訂單整個(gè)流程下來光數(shù)據(jù)準(zhǔn)備就 10 秒。我推薦把數(shù)據(jù)準(zhǔn)備這層操作從 UI 剝離開來直接用 Playwright 的request上下文在后臺調(diào)用接口創(chuàng)建數(shù)據(jù)。它的原理是模擬一個(gè)登錄態(tài)復(fù)用同一個(gè)storage_state直接向接口發(fā)送創(chuàng)建請求比 UI 操作快很多而且穩(wěn)定。具體步驟是先用 UI 登錄一次把登錄態(tài)保存下來context await browser.new_context() page await context.new_page() await page.goto(https://example.com/login) await page.get_by_label(用戶名).fill(tester) await page.get_by_label(密碼).fill(123456) await page.get_by_role(button, name登錄).click() await context.storage_state(pathstate.json)后續(xù)用例里直接用這個(gè) state 創(chuàng)建 API 請求request_context await playwright.request.new_context( base_urlhttps://example.com, storage_statestate.json, ) resp await request_context.post(/api/v1/order, data{ amount: 1000, pay_type: alipay, }) order_id (await resp.json())[id]拿到order_id之后再去跑 UI 層面真正要驗(yàn)證的操作。你會發(fā)現(xiàn)用例的執(zhí)行時(shí)間從原來的 15 秒降到了 5 秒以內(nèi)并且不再受前端表單控件變化的影響。如果后端還沒有提供完整的數(shù)據(jù)制造接口也可以直接操作數(shù)據(jù)庫預(yù)置數(shù)據(jù)。但這條路要小心Browser 會話和數(shù)據(jù)庫之間可能有時(shí)序問題比如緩存、統(tǒng)計(jì)字段、狀態(tài)機(jī)最好封裝成一個(gè)獨(dú)立的數(shù)據(jù)工廠模塊方便統(tǒng)一維護(hù)和清理。5.2 關(guān)閉或分級配置 trace 和視頻錄制Playwright 默認(rèn)在失敗時(shí)會保存 trace、截圖甚至視頻這些診斷信息對定位問題非常有用但打開它們會讓每個(gè)用例都慢上不少。原理不復(fù)雜trace 會把所有頁面操作、DOM 快照、網(wǎng)絡(luò)請求、控制臺日志全部記錄進(jìn)一個(gè) zip 文件視頻錄制則需要每一幀畫面編碼。這些 IO 操作都在用例執(zhí)行的主路徑上。playwright.config.ts里最省事的方式是分環(huán)境配置// 本地調(diào)試 use: { trace: on, video: retain-on-failure, screenshot: only-on-failure, }, // CI 回歸 use: { trace: retain-on-failure, video: false, screenshot: only-on-failure, },如果某個(gè)用例特別難定位你還可以只針對它臨時(shí)開 tracecontext await browser.new_context( record_video_dirvideos/, traceon, )等定位完再把trace關(guān)掉。這個(gè)方案的最大收益是保持平時(shí)執(zhí)行的輕量同時(shí)保留了排查問題的途徑。這里有個(gè)容易被忽略的點(diǎn)retain-on-failure并不是零成本即使最終沒有失敗它也要在內(nèi)存里暫存這些數(shù)據(jù)直到用例結(jié)束才能決定是保留還是丟棄。如果你明確不需要視頻我建議直接把 video 設(shè)為false而不是retain-on-failure。5.3 pytest fixture 緩存與 AI 語義結(jié)合的架構(gòu)思路在 Python pytest Playwright AI 語義的自動化框架里性能優(yōu)化和數(shù)據(jù)準(zhǔn)備可以結(jié)合得很緊密。一個(gè)是利用 fixture 的作用域來控制數(shù)據(jù)生命周期一個(gè)是利用 AI 語義生成更精準(zhǔn)的用例、定位和斷言減少人工維護(hù)成本。先說 fixture 緩存。比如你希望“登錄狀態(tài)”只創(chuàng)建一次多個(gè)用例共用pytest.fixture(scopesession) def login_state(): context browser.new_context() page context.new_page() page.goto(https://example.com/login) page.get_by_label(用戶名).fill(tester) page.get_by_label(密碼).fill(123456) page.get_by_role(button, name登錄).click() page.context.storage_state(pathstate.json) context.close() return state.jsonscopesession表示整個(gè)測試會話只執(zhí)行一次后續(xù)所有使用該 fixture 的測試都復(fù)用這個(gè)登錄態(tài)能省下大量登錄耗時(shí)。再往下走一步你可以把某個(gè)業(yè)務(wù)對象比如一個(gè)“已支付訂單”作為 session 級 fixture用一次 API 創(chuàng)建把它緩存到變量或 conftest 的模塊變量里其他用例拿過來直接用。那“AI 語義”在性能優(yōu)化里能做什么我目前的使用場景是輔助生成用例描述和選擇器。比如用 AI 把自然語言操作步驟翻譯成 Playwright 語義代碼或者用語義模型判斷某個(gè)按鈕用get_by_role還是get_by_text更穩(wěn)定。這個(gè)不會直接讓單條用例變快但它減少了用例調(diào)試和重寫的次數(shù)從總產(chǎn)出看大幅節(jié)省了時(shí)間。scrapy-playwright那套做動態(tài)頁面抓取的思路也值得參考。因?yàn)榕老x場景同樣被頁面等待和資源加載拖慢很多人會在 Playwright 里攔截?zé)o用資源、動態(tài)等待 iframe 內(nèi)容出現(xiàn)。這些技巧和純測試場景的優(yōu)化是相通的。如果你對 Playwright 監(jiān)聽頁面請求已經(jīng)很熟那這部分基本可以無縫遷移。6. 性能測量與 CI 落地優(yōu)化要可量化、可回歸6.1 建立基線測試時(shí)間與預(yù)算沒有測量就沒有優(yōu)化。我的習(xí)慣是在優(yōu)化前先記錄一個(gè)基線總用例數(shù)、總耗時(shí)、單用例平均耗時(shí)、失敗重試次數(shù)、CI 執(zhí)行耗時(shí)。然后每改動一項(xiàng)優(yōu)化再跑一輪全量測試對比基線看收益。這里推薦一個(gè)輕量做法在 CI 的產(chǎn)物里每月留存一份測試報(bào)告包含 Playwright 自帶的耗時(shí)瀑布圖。瀑布圖能直接看出每個(gè)階段loading、click、expect、type各占了多少毫秒定位到具體瓶頸會非常直觀。還需要給項(xiàng)目設(shè)置“時(shí)間預(yù)算”。比如線上核心用戶路徑的端到端用例單條預(yù)算 5 秒涉及多接口的復(fù)雜業(yè)務(wù)單條預(yù)算 12 秒。一旦新增用例超過預(yù)算就說明需要從設(shè)計(jì)上拆分或者用 API 預(yù)置數(shù)據(jù)來降低 UI 操作成本。時(shí)間預(yù)算的本質(zhì)不是限制測試行為而是倒逼團(tuán)隊(duì)思考哪些步驟可以通過后端預(yù)置數(shù)據(jù)解決哪些步驟可以通過攔截資源減少加載哪些步驟壓根不需要端到端覆蓋用接口測試取代就好。6.2 在 CI 中落地并行分片與資源限制CI 里的并行分片有一個(gè)很現(xiàn)實(shí)的坑多臺 runner 同時(shí)跑測試如果測試環(huán)境后端只有一套性能瓶頸就從腳本端轉(zhuǎn)移到了服務(wù)端。你有 4 臺機(jī)器并行跑后端接口如果被壓垮失敗率反而飆升。針對這個(gè)問題我建議在 CI 腳本里設(shè)置并發(fā)度上限并且給測試環(huán)境做容量評估。日?；貧w中我會控制總并發(fā)瀏覽器實(shí)例數(shù)不超過后端服務(wù)能承受的峰值比如整個(gè) CI 同時(shí)最多跑 16 個(gè)瀏覽器進(jìn)程可以用workers和分片數(shù)量相乘估算出來。另一個(gè)容易被忽視的資源是測試環(huán)境的數(shù)據(jù)庫。并行跑測試時(shí)多個(gè)用例可能同時(shí)去創(chuàng)建訂單、創(chuàng)建用戶如果數(shù)據(jù)庫有唯一性約束就會出現(xiàn)偶發(fā)失敗。解決辦法是給每條用例都打上唯一標(biāo)識比如在創(chuàng)建訂單時(shí)把order_no拼上uuid4().hex[:8]從根源上避免數(shù)據(jù)沖突。最后CI 上建議把失敗重試策略也收斂一下。個(gè)別用例偶爾失敗并不是每次都需要立即重跑把重試次數(shù)從默認(rèn)的 2 次降到 1 次并配合失敗截圖、trace 做異步分析能顯著縮短反饋循環(huán)。6.3 常見問題速查表問題排查思路解決方案頁面加載特別慢單用例 15 秒看瀑布圖里哪個(gè)階段耗時(shí)最高攔截圖片、字體、媒體資源并行后內(nèi)存不足瀏覽器閃退Worker 開太多或 container shm 太小減少 worker 數(shù)加--disable-dev-shm-usage固定 sleep 導(dǎo)致用例又慢又不穩(wěn)搜索代碼里的sleep、waitForTimeout改為自動等待和expect輪詢用例間存在數(shù)據(jù)依賴并行后失敗共享了數(shù)據(jù)庫或文件狀態(tài)用 API 預(yù)置數(shù)據(jù)給數(shù)據(jù)加唯一標(biāo)識networkidle永遠(yuǎn)等不到頁面有輪詢或 websocket改用等待關(guān)鍵接口返回或關(guān)鍵元素可見攔截圖片后按鈕點(diǎn)不動圖片 onload 影響組件渲染返回空圖片 base64而不是直接 aborttrace 開著導(dǎo)致執(zhí)行很慢trace 錄制 IO 開銷大改retain-on-failure平時(shí)關(guān)閉復(fù)用存儲狀態(tài)后接口 401Cookie 過期或包含跨域限制重新登錄并導(dǎo)出新的 storage_state排查問題有一個(gè)總原則先看瀑布圖再查網(wǎng)絡(luò)請求最后再懷疑等待邏輯。90% 的“慢”都能落到這三類原因之一。最后再分享一個(gè)小經(jīng)驗(yàn)性能優(yōu)化不是一次性工作而是持續(xù)維護(hù)的動作。每次新增測試用例之前先問自己一句——這一步能不能在 API 層完成這個(gè)等待能不能用事件觸發(fā)替代這個(gè)頁面資源是不是必須加載。多問幾次你的測試套件就能一直保持輕快。 Playwright端到端測試性能優(yōu)化：10個(gè)實(shí)用技巧助你縮短測試耗時(shí)
團(tuán)隊(duì)最近把前端端到端測試套件從 45 分鐘壓到了 12 分鐘核心就是用 Playwright 性能優(yōu)化那一套方法論重新梳理了一遍用例。說實(shí)話做自動化測試的人都有同感用例寫出來不難難得是跑得又快又穩(wěn)。尤其是當(dāng)用例數(shù)量上了三位數(shù)之后每次跑完看一眼耗時(shí)表心里那叫一個(gè)復(fù)雜。這篇文章整理的就是這些實(shí)測下來真正有用的干貨一共 10 個(gè)實(shí)用技巧從并行執(zhí)行、資源攔截、等待策略到數(shù)據(jù)預(yù)置基本覆蓋了 Playwright 縮短測試時(shí)間的主要方向。適合正在被測試耗時(shí)折磨的測試開發(fā)、前端工程化同學(xué)也適合剛上手 Playwright 但不想一上來就踩坑的新手。新手最需要知道的一點(diǎn)是Playwright 并不是一個(gè)慢工具它慢在“默認(rèn)配置”。瀏覽器啟動、圖片加載、動畫等待、trace 錄制、串行執(zhí)行這些默認(rèn)行為疊加在一起測一個(gè)頁面動輒十幾秒。優(yōu)化思路其實(shí)就一句話——不加載的資源不加載不必要的時(shí)間不等待能并行的用例不串行。1. 先弄清瓶頸測試慢在哪優(yōu)化才有方向1.1 我踩過的性能坑與常見瓶頸分布在做優(yōu)化之前我先花了一個(gè)下午給整個(gè)測試套件做了耗時(shí)畫像。這一步非常重要因?yàn)椤案杏X慢”和“真正慢在哪”往往是兩回事。我當(dāng)時(shí)的測試套件里單用例耗時(shí)有高有低高的能到 40 秒低的也要 6 秒平均下來跑一輪要 45 分鐘。耗時(shí)畫像統(tǒng)計(jì)下來瓶頸主要是這幾個(gè)啟動和關(guān)閉瀏覽器實(shí)例的時(shí)間占了大約 15%。這個(gè)問題在測試文件數(shù)量多的時(shí)候尤其明顯因?yàn)槊總€(gè)測試文件默認(rèn)都會啟動自己的瀏覽器實(shí)例。頁面加載時(shí)圖片、字體、視頻、第三方統(tǒng)計(jì)腳本全部加載多了不少等待時(shí)間這部分占了大概 20%。用例里大量使用sleep(3)或者固定等待以及一些 Web 應(yīng)用交互動畫要等 400ms 或 1s這類硬編碼等待疊加起來占到了 25%。數(shù)據(jù)準(zhǔn)備全靠 UI 操作一個(gè)創(chuàng)建流程跑一遍要 8 到 12 秒三個(gè)用例就快半分鐘了這占了 10%。CI 上還是單機(jī)串行執(zhí)行CPU 和內(nèi)存資源實(shí)際只用了四分之一。這個(gè)分布其實(shí)很典型。網(wǎng)絡(luò)帶寬越差、測試環(huán)境響應(yīng)越慢的環(huán)境里瀏覽器啟動和資源加載的占比還會更高。所以優(yōu)化后我立刻就能看到測試套件單跑執(zhí)行速度提升了大概 2 倍再疊加并行執(zhí)行才達(dá)到最終 12 分鐘的效果。1.2 十個(gè)技巧總覽與優(yōu)先級劃分我建議不要一開始就把十個(gè)技巧全部鋪開而是先把收益最大的幾個(gè)落地。下面這張表是我自己整理的一個(gè)優(yōu)先級參考后文會逐個(gè)展開。技巧核心動作預(yù)估收益實(shí)施成本1. 并行執(zhí)行Pytest 多 Worker 并發(fā)跑測試文件接近線性提升低2. CI 分片按 CI 機(jī)器分片并行接近線性提升低3. 資源攔截?cái)r截圖片、字體、媒體請求減少 20% ~ 40% 加載等待低4. 請求監(jiān)聽與超時(shí)監(jiān)聽請求合理硬超時(shí)快速失敗減少單用例無效等待低5. 去掉固定 sleep改為自動等待和輪詢斷言減少 20% ~ 30% 等待中6. 選擇器策略用 getByRole、getByText 替代脆弱選擇器提高定位穩(wěn)定性間接提速低7. 瀏覽器啟動參數(shù)headless、禁用 GPU、禁用沙箱、合屏渲染單用例節(jié)省 1~3 秒低8. 復(fù)用上下文與 API 預(yù)置數(shù)據(jù)用 request 上下文預(yù)置測試數(shù)據(jù)減少 30% 以上的 UI 前置操作中9. 診斷功能按需開啟關(guān)閉 trace、video只在失敗時(shí)錄制節(jié)省數(shù)秒到數(shù)十秒極低10. 緩存與語義化用例fixture 級緩存AI 語義自動生成用例長期維護(hù)收益高較高這十個(gè)技巧不是孤立使用的很多是配合關(guān)系。比如第 3 個(gè)資源攔截和第 4 個(gè)請求監(jiān)聽通常一起用第 8 個(gè) API 預(yù)置數(shù)據(jù)可以為第 1 個(gè)并行執(zhí)行減少很多不穩(wěn)定因素。下面我按章節(jié)把每個(gè)技巧的“為什么”和“怎么做”講透。2. 并行執(zhí)行與瀏覽器實(shí)例策略第一筆大收益2.1 Pytest 插件與多 Worker 配置如果你的測試框架用的是 Pytest那一定不要錯(cuò)過pytest-xdist。它在不改變用例代碼的前提下讓多個(gè) Worker 進(jìn)程并行跑不同的測試文件這是 Playwright 縮短測試時(shí)間最立竿見影的一招。配置起來很簡單。先在項(xiàng)目里安裝依賴pip install pytest-xdist然后在 pytest.ini 里加一行或者命令行直接指定-n auto[pytest] addopts -n autoauto會根據(jù)機(jī)器的 CPU 邏輯核數(shù)自動決定 Worker 數(shù)量。我的開發(fā)機(jī)是 8 核 16 線程實(shí)測 4 個(gè) Worker 時(shí)性價(jià)比最高因?yàn)闉g覽器進(jìn)程本身也要吃內(nèi)存開 8 個(gè) Worker 會導(dǎo)致內(nèi)存吃緊。在 CI 上我反而推薦先定一個(gè)保守?cái)?shù)值比如-n 4再根據(jù)內(nèi)存余量往上調(diào)。一個(gè)重要前提是并行意味著每個(gè) Worker 進(jìn)程都有自己的瀏覽器實(shí)例如果你的用例之間共享了本地?cái)?shù)據(jù)庫文件、共享了同一份靜態(tài)臨時(shí)文件或者依賴執(zhí)行順序那要先處理好這些隔離問題。pytest-xdist 的設(shè)計(jì)原則是“測試文件級并行”所以同一個(gè)文件里的用例默認(rèn)還是串行執(zhí)行的這就很安全。2.2 分片策略與 CI 資源利用如果你的 CI 機(jī)器不止一臺那還可以用 Playwright 官方的分片能力。分片比多 Worker 更徹底它是把整個(gè)測試集合按指定數(shù)量切成多個(gè)片每臺機(jī)器跑其中一部分。常見的做法是 GitHub Actions 里用matrix配一個(gè)并發(fā)矩陣strategy: fail-fast: false matrix: shardIndex: [1, 2, 3, 4]然后在執(zhí)行腳本里加npx playwright test --shard${{ matrix.shardIndex }}/4這樣 4 臺機(jī)器并行跑每一臺跑的用例不會重復(fù)。要注意的是分片并不保證每片用時(shí)完全均勻因?yàn)槊科锏挠美写笥行?。如果你有特別重的用例可以手動給它們標(biāo)上test.describe.configure({ mode: serial })或者放到獨(dú)立文件里避免一個(gè)重用例拖垮整片。我個(gè)人在 CI 上的組合拳是先把用例按業(yè)務(wù)模塊分成幾個(gè)測試目錄再把每個(gè)目錄拆成獨(dú)立 CI JobJob 內(nèi)再用-n 4做二級并行。兩層并行下來整個(gè)流水線從原來的 45 分鐘降到 15 分鐘以內(nèi)而且單個(gè) Job 的資源使用率非常平穩(wěn)。2.3 瀏覽器啟動參數(shù)與復(fù)用上下文默認(rèn)配置下 Playwright 在無頭模式會做很多防御性工作比如啟用 GPU 進(jìn)程、沙箱、硬件加速判斷。對于測試來說這些大部分可以關(guān)掉。下面是運(yùn)行速度影響最大的幾個(gè)啟動參數(shù)browser await playwright.chromium.launch( headlessTrue, args[ --disable-gpu, --disable-dev-shm-usage, --no-sandbox, --disable-extensions, --disable-background-timer-throttling, --disable-backgrounding-occluded-windows, --disable-renderer-backgrounding, --disable-ipc-flooding-protection, ] )這里解釋一下關(guān)鍵參數(shù)的作用--disable-gpu無頭模式本來就不需要 GPU 渲染加速關(guān)掉可避免 GPU 進(jìn)程崩潰導(dǎo)致的重試。--disable-dev-shm-usage在 Docker 容器里非常關(guān)鍵否則/dev/shm太小可能直接讓瀏覽器閃退。--disable-background-timer-throttling頁面切到后臺時(shí)瀏覽器會降低定時(shí)器頻率關(guān)掉后能保證前端輪詢邏輯在并發(fā)下正常工作。--no-sandbox僅在信任的測試環(huán)境里用核心原因是容器環(huán)境默認(rèn)沒有權(quán)限創(chuàng)建 sandbox。再想進(jìn)一步降開銷可以復(fù)用browser_context。多組用例共用同一個(gè)瀏覽器實(shí)例但是每個(gè)用例獨(dú)立context這樣能省掉每次啟動瀏覽器的幾秒鐘。簡單理解就是瀏覽器進(jìn)程只啟動一次頁面之間互不干擾的隔離由 context 保證。3. 網(wǎng)絡(luò)層攔截與資源瘦身少加載就是快3.1 用 route 攔截非關(guān)鍵資源網(wǎng)頁里總有那么一類資源對 UI 測試沒有任何影響但下載起來特別浪費(fèi)時(shí)間大圖、背景圖、字體文件、視頻、埋點(diǎn)統(tǒng)計(jì)腳本。Playwright 提供的route攔截能力可以讓你在請求發(fā)出前就把它直接中止或改寫為空響應(yīng)。最常見做法是攔截掉圖片和字體。以一個(gè)后臺管理系統(tǒng)為例頁面加載 80% 的流量都來自圖片和圖標(biāo)字體攔截之后單頁面加載時(shí)間從 6 秒降到 2.8 秒。代碼如下import re async def block_unused_resources(route): url route.request.url if route.request.resource_type in [image, font, media]: await route.abort() elif re.search(r\.(png|jpg|jpeg|gif|svg|woff|woff2|ttf)$, url): await route.abort() else: await route.continue_() await page.route(**/*, block_unused_resources)如果你希望圖片不加載但頁面不報(bào)錯(cuò)可以不用abort()而是返回一個(gè)空圖片的 base64 響應(yīng)await route.fulfill( status200, content_typeimage/png, bodybase64.b64decode(EMPTY_IMAGE_BASE64) )這樣對頁面邏輯的影響最小。尤其是某些前端組件會用圖片的onload事件做后續(xù)渲染這時(shí)候直接 abort 可能導(dǎo)致按鈕一直處于 loading 狀態(tài)而 fulfill 一個(gè) 1x1 像素圖就不會觸發(fā)這類問題。對于第三方統(tǒng)計(jì)腳本、廣告 SDK 這類你根本不需要的資源類型直接按域名攔截更干凈import re async def block_third_party(route): url route.request.url if any(domain in url for domain in [google-analytics.com, googletagmanager.com, doubleclick.net]): await route.abort() else: await route.continue_()攔截后有兩個(gè)細(xì)節(jié)值得注意。第一個(gè)是某些站點(diǎn)的接口會校驗(yàn)資源完整性圖片缺失可能導(dǎo)致前端接口調(diào)用被閾值限制第二個(gè)是 Electron 或內(nèi)嵌瀏覽器環(huán)境下字體缺失時(shí)中文會直接變成方塊。所以建議在本地開發(fā)模式下不要啟用全局?jǐn)r截只在 CI 或者測試環(huán)境里開。3.2 請求監(jiān)聽與超時(shí)治理除了攔截你還可以通過監(jiān)聽請求來判斷頁面是否真的加載完成。很多前端框架在首屏渲染時(shí)會同時(shí)發(fā)起多個(gè)接口請求但頁面的load事件觸發(fā)得比接口返回更早導(dǎo)致你一進(jìn)頁面去點(diǎn)擊按鈕結(jié)果接口還沒回來數(shù)據(jù)是空的按鈕點(diǎn)了沒反應(yīng)——這是測試不穩(wěn)定的最大來源之一。我的做法是把“關(guān)鍵接口請求完成”當(dāng)成一個(gè)更可靠的頁面就緒信號。先用page.on(request)記錄下接口請求再用page.wait_for_response等待對應(yīng)接口返回async with page.expect_response(lambda response: /api/v1/order/list in response.url and response.status 200) as resp_info: await page.goto(https://example.com/orders) response await resp_info.value配合超時(shí)治理我會給每個(gè)這種等待都設(shè)置一個(gè)明確的時(shí)間上限。默認(rèn)的 30 秒全局超時(shí)對慢用例太寬容了很多無效等待就是這么浪費(fèi)掉的。在 Playwright 的 config 里可以這樣收斂# playwright.config.py config { timeout: 15_000, expect: {timeout: 5_000}, }expect里的 5 秒是每個(gè)expect輪詢的默認(rèn)超時(shí)。這樣某個(gè)按鈕 5 秒內(nèi)不出現(xiàn)就直接失敗而不是傻傻地等滿 30 秒。我在實(shí)際項(xiàng)目里還見過不少接口 10 秒才返回的場景這類“真慢”要單獨(dú)在測試數(shù)據(jù)層處理而不是把全局超時(shí)拉高否則所有用例都會為它買單。3.3 攔截策略的邊界與注意事項(xiàng)資源攔截雖然收益大但也不是攔得越多越好。我踩過最深的坑是攔截某個(gè)品牌官網(wǎng)的字體文件之后頁面文字全部變成系統(tǒng)默認(rèn)字體結(jié)果某個(gè)按鈕的寬度變化導(dǎo)致后續(xù)點(diǎn)擊偏移用例反復(fù)失敗。排查了一個(gè)多小時(shí)才意識到是字體文件被攔掉了。所以做資源攔截要有一個(gè)基本判斷原則只攔截那些“不影響行為邏輯、只影響觀感”的資源。圖片、視頻、字體、埋點(diǎn)腳本通常是安全的但接口請求千萬不能隨便攔截因?yàn)槟鞘菢I(yè)務(wù)邏輯的命脈。還要注意route的匹配規(guī)則是按注冊順序執(zhí)行的。如果你先注冊了某個(gè) API 路徑的route.continue_()又注冊了全局資源的攔截那 API 路徑的 rule 會先匹配到就不會被誤傷。建議把精確路徑的攔截放在前面把資源類型的攔截放在最后這樣規(guī)則更可控。另外如果你同時(shí)用page.route(**/*, handler)監(jiān)聽所有請求并在 handler 里做了大量邏輯那也會帶來輕微的性能損耗。實(shí)測下來一個(gè) handler 里有字符串正則匹配還好但如果每次請求都做異步 IO比如查數(shù)據(jù)庫判斷是否攔截請求并發(fā)高時(shí)會產(chǎn)生明顯排隊(duì)。所以我建議 handler 保持純函數(shù)風(fēng)格不要在里面做耗時(shí)操作。4. 等待與選擇器策略把隱性等待變成精準(zhǔn)等待4.1 自動等待機(jī)制與過期固定等待Playwright 和 Selenium 最大的不同就是它內(nèi)置了自動等待。每次執(zhí)行click、fill、press這些操作之前Playwright 會先去檢查元素是否“可操作”比如是否可見、是否穩(wěn)定、是否接收入口事件。這個(gè)機(jī)制本身不慢慢的是大家拿到 Playwright 后仍然習(xí)慣性加上time.sleep()。這里要重點(diǎn)說清楚一個(gè)反直覺的點(diǎn)在 Playwright 里無腦加time.sleep(2)不僅不會讓用例更穩(wěn)定反而會掩蓋真實(shí)前端狀態(tài)變化導(dǎo)致測試和開發(fā)之間反饋?zhàn)兟?。更好的方式是依?Playwright 的 actionability 檢查再用expect去做狀態(tài)輪詢。比如等待某個(gè) loading 狀態(tài)消失await page.goto(https://example.com/order) await expect(page.locator(.loading)).to_be_hidden(timeout10_000) await page.get_by_role(button, name提交訂單).click()它會在 10 秒內(nèi)持續(xù)輪詢元素隱藏的瞬間就繼續(xù)往下執(zhí)行平均等待時(shí)間可能只需要幾百毫秒而不是固定的 2 秒。相比sleep這種方式的耗時(shí)是動態(tài)的、真實(shí)的。我見過一個(gè)有意思的極端案例某個(gè)用例里寫了四處sleep(3)優(yōu)化之后改成自動等待單用例從 16 秒直接降到 7 秒。原因很簡單前端在本地環(huán)境渲染只需要 500ms但測試腳本固定睡了 3 秒白白浪費(fèi)了 2.5 秒。4.2 用 getBy 系列選擇器替代脆弱選擇器選擇器本身不直接決定測試快慢但它決定了用例的一次通過率。一次通過率低就意味著要反復(fù)重試跑整體耗時(shí)自然就上去了。Playwright 官方推薦的getByRole、getByText、getByLabel這些基于可訪問性語義的選擇器比 CSS 類名選擇器穩(wěn)定得多也更貼近真實(shí)用戶操作。舉個(gè)例子。老的 CSS 寫法await page.locator(.btn-primary.btn-large).click()只要前端把類名從btn-primary改成btn-main用例就掛了。換成await page.get_by_role(button, name立即支付).click()前端怎么改樣式類名都不影響這個(gè)按鈕的定位。再比如輸入框用await page.get_by_label(用戶名).fill(tester)它會自動匹配 label 關(guān)聯(lián)的 input比硬寫 CSS 路徑健壯很多。如果項(xiàng)目對可訪問性支持不好很多元素沒有role或者 label那至少也要避免使用多層嵌套的長鏈 CSS。我的原則是“能不用 XPath 就不用 XPath”XPath 里一旦包含下標(biāo)比如//div[3]/div[2]/buttonDOM 結(jié)構(gòu)一變就直接失效。順手提一下playwright codegen。你可以在瀏覽器里像普通用戶一樣操作一遍它會自動生成對應(yīng)的選擇器代碼省去手工寫選擇器的時(shí)間。生成的代碼不一定最優(yōu)但可以作為起點(diǎn)對快速搭用例很有幫助。4.3 網(wǎng)絡(luò)空閑與元素可見性等待的取舍Playwright 還提供了page.wait_for_load_state(networkidle)意思是一直等到 500ms 內(nèi)沒有網(wǎng)絡(luò)連接才繼續(xù)。這個(gè)概念聽著很理想實(shí)際操作里要慎用因?yàn)楹芏囗撁鏁休喸兘涌凇ebsocket 長連接或者第三方統(tǒng)計(jì)腳本每幾秒發(fā)一次請求導(dǎo)致networkidle永遠(yuǎn)等不到。我的經(jīng)驗(yàn)是只有在你明確知道頁面沒有后臺輪詢且所有關(guān)鍵接口都在首屏觸發(fā)完后才使用networkidle。否則優(yōu)先用expect(response)等待關(guān)鍵接口再用expect(locator).to_be_visible()等待關(guān)鍵元素。還有一種“邊操作邊輪詢”的思路。比如打開一個(gè)列表頁你需要等列表數(shù)據(jù)渲染出來以后再搜索?？梢赃@樣await page.goto(https://example.com/list) await expect(page.get_by_text(共 1000 條記錄)).to_be_visible()等待具體內(nèi)容出現(xiàn)遠(yuǎn)比等待“網(wǎng)絡(luò)空閑”要更貼近業(yè)務(wù)語義。換成白話就是你不要等整個(gè)廚房都安靜下來才知道飯做好了你只需要看到菜端上桌就可以了。5. 前置數(shù)據(jù)與診斷開銷減少 UI 操作和日志成本5.1 用 API 預(yù)置數(shù)據(jù)替代 UI 前置流程很多用例其實(shí)存在大量重復(fù)的前置操作。比如測一個(gè)“訂單列表搜索”功能正好需要先創(chuàng)建一個(gè)訂單測“訂單詳情”時(shí)又需要一個(gè)已支付訂單作為前置條件。傳統(tǒng)做法是讓腳本從登錄開始一路點(diǎn)按鈕、填表單、提交訂單整個(gè)流程下來光數(shù)據(jù)準(zhǔn)備就 10 秒。我推薦把數(shù)據(jù)準(zhǔn)備這層操作從 UI 剝離開來直接用 Playwright 的request上下文在后臺調(diào)用接口創(chuàng)建數(shù)據(jù)。它的原理是模擬一個(gè)登錄態(tài)復(fù)用同一個(gè)storage_state直接向接口發(fā)送創(chuàng)建請求比 UI 操作快很多而且穩(wěn)定。具體步驟是先用 UI 登錄一次把登錄態(tài)保存下來context await browser.new_context() page await context.new_page() await page.goto(https://example.com/login) await page.get_by_label(用戶名).fill(tester) await page.get_by_label(密碼).fill(123456) await page.get_by_role(button, name登錄).click() await context.storage_state(pathstate.json)后續(xù)用例里直接用這個(gè) state 創(chuàng)建 API 請求request_context await playwright.request.new_context( base_urlhttps://example.com, storage_statestate.json, ) resp await request_context.post(/api/v1/order, data{ amount: 1000, pay_type: alipay, }) order_id (await resp.json())[id]拿到order_id之后再去跑 UI 層面真正要驗(yàn)證的操作。你會發(fā)現(xiàn)用例的執(zhí)行時(shí)間從原來的 15 秒降到了 5 秒以內(nèi)并且不再受前端表單控件變化的影響。如果后端還沒有提供完整的數(shù)據(jù)制造接口也可以直接操作數(shù)據(jù)庫預(yù)置數(shù)據(jù)。但這條路要小心Browser 會話和數(shù)據(jù)庫之間可能有時(shí)序問題比如緩存、統(tǒng)計(jì)字段、狀態(tài)機(jī)最好封裝成一個(gè)獨(dú)立的數(shù)據(jù)工廠模塊方便統(tǒng)一維護(hù)和清理。5.2 關(guān)閉或分級配置 trace 和視頻錄制Playwright 默認(rèn)在失敗時(shí)會保存 trace、截圖甚至視頻這些診斷信息對定位問題非常有用但打開它們會讓每個(gè)用例都慢上不少。原理不復(fù)雜trace 會把所有頁面操作、DOM 快照、網(wǎng)絡(luò)請求、控制臺日志全部記錄進(jìn)一個(gè) zip 文件視頻錄制則需要每一幀畫面編碼。這些 IO 操作都在用例執(zhí)行的主路徑上。playwright.config.ts里最省事的方式是分環(huán)境配置// 本地調(diào)試 use: { trace: on, video: retain-on-failure, screenshot: only-on-failure, }, // CI 回歸 use: { trace: retain-on-failure, video: false, screenshot: only-on-failure, },如果某個(gè)用例特別難定位你還可以只針對它臨時(shí)開 tracecontext await browser.new_context( record_video_dirvideos/, traceon, )等定位完再把trace關(guān)掉。這個(gè)方案的最大收益是保持平時(shí)執(zhí)行的輕量同時(shí)保留了排查問題的途徑。這里有個(gè)容易被忽略的點(diǎn)retain-on-failure并不是零成本即使最終沒有失敗它也要在內(nèi)存里暫存這些數(shù)據(jù)直到用例結(jié)束才能決定是保留還是丟棄。如果你明確不需要視頻我建議直接把 video 設(shè)為false而不是retain-on-failure。5.3 pytest fixture 緩存與 AI 語義結(jié)合的架構(gòu)思路在 Python pytest Playwright AI 語義的自動化框架里性能優(yōu)化和數(shù)據(jù)準(zhǔn)備可以結(jié)合得很緊密。一個(gè)是利用 fixture 的作用域來控制數(shù)據(jù)生命周期一個(gè)是利用 AI 語義生成更精準(zhǔn)的用例、定位和斷言減少人工維護(hù)成本。先說 fixture 緩存。比如你希望“登錄狀態(tài)”只創(chuàng)建一次多個(gè)用例共用pytest.fixture(scopesession) def login_state(): context browser.new_context() page context.new_page() page.goto(https://example.com/login) page.get_by_label(用戶名).fill(tester) page.get_by_label(密碼).fill(123456) page.get_by_role(button, name登錄).click() page.context.storage_state(pathstate.json) context.close() return state.jsonscopesession表示整個(gè)測試會話只執(zhí)行一次后續(xù)所有使用該 fixture 的測試都復(fù)用這個(gè)登錄態(tài)能省下大量登錄耗時(shí)。再往下走一步你可以把某個(gè)業(yè)務(wù)對象比如一個(gè)“已支付訂單”作為 session 級 fixture用一次 API 創(chuàng)建把它緩存到變量或 conftest 的模塊變量里其他用例拿過來直接用。那“AI 語義”在性能優(yōu)化里能做什么我目前的使用場景是輔助生成用例描述和選擇器。比如用 AI 把自然語言操作步驟翻譯成 Playwright 語義代碼或者用語義模型判斷某個(gè)按鈕用get_by_role還是get_by_text更穩(wěn)定。這個(gè)不會直接讓單條用例變快但它減少了用例調(diào)試和重寫的次數(shù)從總產(chǎn)出看大幅節(jié)省了時(shí)間。scrapy-playwright那套做動態(tài)頁面抓取的思路也值得參考。因?yàn)榕老x場景同樣被頁面等待和資源加載拖慢很多人會在 Playwright 里攔截?zé)o用資源、動態(tài)等待 iframe 內(nèi)容出現(xiàn)。這些技巧和純測試場景的優(yōu)化是相通的。如果你對 Playwright 監(jiān)聽頁面請求已經(jīng)很熟那這部分基本可以無縫遷移。6. 性能測量與 CI 落地優(yōu)化要可量化、可回歸6.1 建立基線測試時(shí)間與預(yù)算沒有測量就沒有優(yōu)化。我的習(xí)慣是在優(yōu)化前先記錄一個(gè)基線總用例數(shù)、總耗時(shí)、單用例平均耗時(shí)、失敗重試次數(shù)、CI 執(zhí)行耗時(shí)。然后每改動一項(xiàng)優(yōu)化再跑一輪全量測試對比基線看收益。這里推薦一個(gè)輕量做法在 CI 的產(chǎn)物里每月留存一份測試報(bào)告包含 Playwright 自帶的耗時(shí)瀑布圖。瀑布圖能直接看出每個(gè)階段loading、click、expect、type各占了多少毫秒定位到具體瓶頸會非常直觀。還需要給項(xiàng)目設(shè)置“時(shí)間預(yù)算”。比如線上核心用戶路徑的端到端用例單條預(yù)算 5 秒涉及多接口的復(fù)雜業(yè)務(wù)單條預(yù)算 12 秒。一旦新增用例超過預(yù)算就說明需要從設(shè)計(jì)上拆分或者用 API 預(yù)置數(shù)據(jù)來降低 UI 操作成本。時(shí)間預(yù)算的本質(zhì)不是限制測試行為而是倒逼團(tuán)隊(duì)思考哪些步驟可以通過后端預(yù)置數(shù)據(jù)解決哪些步驟可以通過攔截資源減少加載哪些步驟壓根不需要端到端覆蓋用接口測試取代就好。6.2 在 CI 中落地并行分片與資源限制CI 里的并行分片有一個(gè)很現(xiàn)實(shí)的坑多臺 runner 同時(shí)跑測試如果測試環(huán)境后端只有一套性能瓶頸就從腳本端轉(zhuǎn)移到了服務(wù)端。你有 4 臺機(jī)器并行跑后端接口如果被壓垮失敗率反而飆升。針對這個(gè)問題我建議在 CI 腳本里設(shè)置并發(fā)度上限并且給測試環(huán)境做容量評估。日?；貧w中我會控制總并發(fā)瀏覽器實(shí)例數(shù)不超過后端服務(wù)能承受的峰值比如整個(gè) CI 同時(shí)最多跑 16 個(gè)瀏覽器進(jìn)程可以用workers和分片數(shù)量相乘估算出來。另一個(gè)容易被忽視的資源是測試環(huán)境的數(shù)據(jù)庫。并行跑測試時(shí)多個(gè)用例可能同時(shí)去創(chuàng)建訂單、創(chuàng)建用戶如果數(shù)據(jù)庫有唯一性約束就會出現(xiàn)偶發(fā)失敗。解決辦法是給每條用例都打上唯一標(biāo)識比如在創(chuàng)建訂單時(shí)把order_no拼上uuid4().hex[:8]從根源上避免數(shù)據(jù)沖突。最后CI 上建議把失敗重試策略也收斂一下。個(gè)別用例偶爾失敗并不是每次都需要立即重跑把重試次數(shù)從默認(rèn)的 2 次降到 1 次并配合失敗截圖、trace 做異步分析能顯著縮短反饋循環(huán)。6.3 常見問題速查表問題排查思路解決方案頁面加載特別慢單用例 15 秒看瀑布圖里哪個(gè)階段耗時(shí)最高攔截圖片、字體、媒體資源并行后內(nèi)存不足瀏覽器閃退Worker 開太多或 container shm 太小減少 worker 數(shù)加--disable-dev-shm-usage固定 sleep 導(dǎo)致用例又慢又不穩(wěn)搜索代碼里的sleep、waitForTimeout改為自動等待和expect輪詢用例間存在數(shù)據(jù)依賴并行后失敗共享了數(shù)據(jù)庫或文件狀態(tài)用 API 預(yù)置數(shù)據(jù)給數(shù)據(jù)加唯一標(biāo)識networkidle永遠(yuǎn)等不到頁面有輪詢或 websocket改用等待關(guān)鍵接口返回或關(guān)鍵元素可見攔截圖片后按鈕點(diǎn)不動圖片 onload 影響組件渲染返回空圖片 base64而不是直接 aborttrace 開著導(dǎo)致執(zhí)行很慢trace 錄制 IO 開銷大改retain-on-failure平時(shí)關(guān)閉復(fù)用存儲狀態(tài)后接口 401Cookie 過期或包含跨域限制重新登錄并導(dǎo)出新的 storage_state排查問題有一個(gè)總原則先看瀑布圖再查網(wǎng)絡(luò)請求最后再懷疑等待邏輯。90% 的“慢”都能落到這三類原因之一。最后再分享一個(gè)小經(jīng)驗(yàn)性能優(yōu)化不是一次性工作而是持續(xù)維護(hù)的動作。每次新增測試用例之前先問自己一句——這一步能不能在 API 層完成這個(gè)等待能不能用事件觸發(fā)替代這個(gè)頁面資源是不是必須加載。多問幾次你的測試套件就能一直保持輕快。