1. 為什么我最終選了 LangChain Playwright 這套組合網(wǎng)頁自動化測試這件事我做了快六年。早期用 Selenium 寫腳本后來換到 Playwright再后來發(fā)現(xiàn)光有 Playwright 還不夠——因?yàn)闇y試用例的維護(hù)成本實(shí)在太高了。一個(gè)電商后臺光是登錄、下單、退款這三條鏈路就能寫出兩百多個(gè)斷言每次前端改個(gè)按鈕的 class 名我就得跟著改一堆選擇器。這種活干久了人會麻木。真正讓我下決心引入 LangChain 的是一次很典型的場景產(chǎn)品經(jīng)理臨時(shí)要求驗(yàn)證用戶下單后如果優(yōu)惠券過期頁面提示文案是否正確。這種需求用傳統(tǒng)腳本寫得先定位優(yōu)惠券元素、判斷狀態(tài)、再定位提示文案前后至少半小時(shí)。但如果讓大模型來理解頁面結(jié)構(gòu)我只需要告訴它檢查過期優(yōu)惠券的提示它就能自己找到對應(yīng)的 DOM 節(jié)點(diǎn)。這就是 LangChain 在這套組合里的核心價(jià)值——它不替代 Playwright 的執(zhí)行能力而是補(bǔ)上了語義理解這一環(huán)。這套方案適合誰如果你已經(jīng)會寫基本的 Playwright 腳本但被頻繁變動的選擇器和斷言邏輯折磨那這套組合能幫你省下大量維護(hù)時(shí)間。如果你是完全的新手也沒關(guān)系我會把每一步拆開講包括環(huán)境配置、代碼結(jié)構(gòu)、以及我踩過的那些坑。提示LangChain 和 LangGraph 不是替代關(guān)系。LangGraph 更適合有狀態(tài)、多輪循環(huán)的 Agent 場景而網(wǎng)頁自動化測試這種一次性任務(wù)鏈用 LangChain 的 LCEL 表達(dá)式就夠了沒必要上 LangGraph 增加復(fù)雜度。2. 環(huán)境搭建與核心依賴選型2.1 Python 版本與虛擬環(huán)境我實(shí)測下來Python 3.10 到 3.12 都能跑通這套組合但 3.9 會在 LangChain 的某些依賴上出問題。建議直接用 3.11兼容性最穩(wěn)。虛擬環(huán)境用 venv 就行沒必要上 conda除非你本地已經(jīng)有 conda 環(huán)境不想折騰。python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate創(chuàng)建完環(huán)境后先升級 pip這一步很多人會跳過但老版本 pip 在裝 Playwright 的瀏覽器依賴時(shí)容易卡住。pip install --upgrade pip2.2 核心依賴安裝這套組合需要三個(gè)核心包playwright、langchain、langchain-openai。注意 langchain-openai 是獨(dú)立包不要只裝 langchain 就以為萬事大吉。pip install playwright langchain langchain-openai python-dotenv playwright install chromium這里有個(gè)細(xì)節(jié)playwright install chromium只裝 Chromium 內(nèi)核如果你需要測試 Firefox 或 WebKit得單獨(dú)執(zhí)行playwright install firefox和playwright install webkit。我一般只裝 Chromium因?yàn)?90% 的網(wǎng)頁測試場景用它就夠了而且能省下幾百 MB 磁盤空間。注意如果你在公司內(nèi)網(wǎng)環(huán)境Playwright 下載瀏覽器二進(jìn)制文件可能會超時(shí)。這時(shí)候可以設(shè)置環(huán)境變量PLAYWRIGHT_DOWNLOAD_HOST指向內(nèi)部鏡像源或者手動下載后放到緩存目錄。具體路徑在 Windows 下是%USERPROFILE%\AppData\Local\ms-playwrightmacOS 和 Linux 在~/.cache/ms-playwright。2.3 大模型接入配置LangChain 本身不綁定任何模型你需要自己接一個(gè)。我用的是 OpenAI 的接口但國內(nèi)也有不少兼容 OpenAI 協(xié)議的服務(wù)配置方式基本一致。在項(xiàng)目根目錄建一個(gè).env文件OPENAI_API_KEY你的密鑰 OPENAI_BASE_URLhttps://api.openai.com/v1然后在代碼里用python-dotenv加載。這里我要強(qiáng)調(diào)一點(diǎn)不要把密鑰硬編碼在代碼里哪怕只是本地測試。我見過太多人把帶密鑰的代碼直接傳到公開倉庫結(jié)果被人掃到盜刷。用.env文件加上.gitignore是最基本的操作。from dotenv import load_dotenv load_dotenv()2.4 目錄結(jié)構(gòu)設(shè)計(jì)我習(xí)慣把項(xiàng)目分成四個(gè)目錄pages放頁面對象、chains放 LangChain 鏈、tests放測試用例、utils放工具函數(shù)。這種結(jié)構(gòu)在項(xiàng)目變大后優(yōu)勢很明顯——當(dāng)你要改某個(gè)頁面的定位邏輯時(shí)只需要動pages目錄下的文件不會影響到測試用例本身。project/ ├── pages/ │ └── login_page.py ├── chains/ │ └── element_finder.py ├── tests/ │ └── test_login.py ├── utils/ │ └── browser.py └── .env3. 核心原理LangChain 到底在自動化測試?yán)镒鍪裁?.1 傳統(tǒng) Playwright 腳本的痛點(diǎn)先看一段典型的 Playwright 代碼await page.click(button.submit-btn) await page.fill(#username, testuser) await page.fill(#password, testpass)這段代碼能跑但問題在于button.submit-btn和#username這些選擇器是硬編碼的。一旦前端重構(gòu)把submit-btn改成submit-button腳本立刻報(bào)錯(cuò)。更麻煩的是有些頁面的按鈕文案會變——今天叫登錄明天叫立即登錄后天叫登 錄中間多個(gè)空格你根本沒法用固定的選擇器覆蓋所有情況。3.2 LangChain 的語義補(bǔ)位LangChain 在這里的作用是把找元素這件事從精確匹配變成語義匹配。具體做法是先把頁面的 DOM 結(jié)構(gòu)簡化成一段文本去掉樣式、腳本等無關(guān)內(nèi)容然后讓大模型根據(jù)你的自然語言描述返回最可能匹配的元素選擇器。舉個(gè)例子你告訴模型找到登錄按鈕它會在簡化后的 DOM 里搜索包含登錄、登陸、sign in等語義相關(guān)的元素然后返回對應(yīng)的 CSS 選擇器或 XPath。這樣即使按鈕文案變了只要語義沒變腳本依然能跑。3.3 為什么不用純大模型操作瀏覽器有人會問既然大模型這么聰明為什么不直接讓它控制瀏覽器答案是成本和穩(wěn)定性。大模型每次調(diào)用都有延遲和費(fèi)用如果每個(gè)點(diǎn)擊、每個(gè)輸入都走一遍模型一個(gè)測試用例跑下來可能要幾十秒甚至幾分鐘。而且大模型的輸出有不確定性同樣的輸入可能返回不同的選擇器這在測試場景里是致命的。所以我的方案是用 LangChain 做元素定位這一件事其余操作全部交給 Playwright 原生 API。這樣既享受了語義理解的好處又保持了執(zhí)行層的穩(wěn)定和高效。3.4 頁面 DOM 簡化的具體做法直接把整個(gè) HTML 丟給大模型是不現(xiàn)實(shí)的一個(gè)現(xiàn)代網(wǎng)頁的 DOM 動輒幾千個(gè)節(jié)點(diǎn)token 消耗巨大且容易超出上下文限制。我的做法是用 Playwright 的evaluate方法在瀏覽器里先做一輪篩選simplified_dom await page.evaluate(() { const interactiveTags [button, a, input, select, textarea]; const elements document.querySelectorAll(interactiveTags.join(,)); return Array.from(elements).map(el ({ tag: el.tagName.toLowerCase(), text: el.innerText?.trim().slice(0, 50) || , id: el.id || , className: el.className || , type: el.type || , placeholder: el.placeholder || })); })這段代碼只提取可交互元素并且把每個(gè)元素的文本截?cái)嗟?50 個(gè)字符避免 token 浪費(fèi)。實(shí)測下來一個(gè)普通頁面的簡化 DOM 大概在 500 到 1500 token 之間完全在可控范圍內(nèi)。4. 完整代碼實(shí)現(xiàn)從零到跑通4.1 瀏覽器管理工具類先寫一個(gè)瀏覽器管理的工具類負(fù)責(zé)啟動、關(guān)閉和頁面創(chuàng)建。這里我用的是異步 API因?yàn)?Playwright 的同步 API 在某些場景下會和 LangChain 的異步調(diào)用沖突。from playwright.async_api import async_playwright class BrowserManager: def __init__(self, headlessTrue): self.headless headless self.playwright None self.browser None async def start(self): self.playwright await async_playwright().start() self.browser await self.playwright.chromium.launch( headlessself.headless, args[--disable-blink-featuresAutomationControlled] ) async def new_page(self): context await self.browser.new_context( viewport{width: 1280, height: 720}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ) return await context.new_page() async def close(self): if self.browser: await self.browser.close() if self.playwright: await self.playwright.stop()--disable-blink-featuresAutomationControlled這個(gè)參數(shù)很關(guān)鍵它能去掉 navigator.webdriver 標(biāo)志避免被一些網(wǎng)站的反自動化機(jī)制識別。當(dāng)然這不是萬能的有些站點(diǎn)還有更復(fù)雜的檢測手段但對于大多數(shù)內(nèi)部測試場景已經(jīng)夠用。4.2 LangChain 元素定位鏈這是整套方案的核心。我用 LCEL 表達(dá)式構(gòu)建了一條鏈輸入是簡化 DOM 和自然語言描述輸出是選擇器。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser llm ChatOpenAI(modelgpt-4o-mini, temperature0) prompt ChatPromptTemplate.from_messages([ (system, 你是一個(gè)網(wǎng)頁元素定位專家。根據(jù)用戶描述和頁面元素列表 返回最匹配的元素選擇器。優(yōu)先使用 id其次使用穩(wěn)定的 class 最后才用文本內(nèi)容。返回 JSON 格式{{selector: ..., reason: ...}}), (human, 頁面元素\n{elements}\n\n用戶描述{description}) ]) parser JsonOutputParser() element_chain prompt | llm | parsertemperature0是為了讓輸出盡可能確定減少隨機(jī)性。模型我選的是 gpt-4o-mini因?yàn)樵囟ㄎ贿@個(gè)任務(wù)不需要太強(qiáng)的推理能力mini 版本足夠且便宜。如果你對成本不敏感換成 gpt-4o 效果會更好尤其是在處理復(fù)雜表單時(shí)。4.3 頁面對象封裝把定位邏輯封裝成頁面對象這樣測試用例里就不用關(guān)心具體選擇器是怎么來的。class SmartPage: def __init__(self, page, chain): self.page page self.chain chain async def get_elements(self): return await self.page.evaluate(() { const tags [button, a, input, select, textarea]; return Array.from(document.querySelectorAll(tags.join(,))) .map(el ({ tag: el.tagName.toLowerCase(), text: (el.innerText || ).trim().slice(0, 50), id: el.id || , className: typeof el.className string ? el.className : , type: el.type || , placeholder: el.placeholder || })); }) async def smart_click(self, description): elements await self.get_elements() result await self.chain.ainvoke({ elements: str(elements), description: description }) selector result[selector] await self.page.click(selector) return selector async def smart_fill(self, description, value): elements await self.get_elements() result await self.chain.ainvoke({ elements: str(elements), description: description }) selector result[selector] await self.page.fill(selector, value) return selector4.4 完整測試用例把上面的組件串起來寫一個(gè)完整的登錄測試import asyncio from utils.browser import BrowserManager from chains.element_finder import element_chain from pages.smart_page import SmartPage async def test_login(): manager BrowserManager(headlessFalse) await manager.start() page await manager.new_page() smart SmartPage(page, element_chain) await page.goto(https://example.com/login) await page.wait_for_load_state(networkidle) await smart.smart_fill(用戶名輸入框, testuser) await smart.smart_fill(密碼輸入框, testpass) await smart.smart_click(登錄按鈕) await page.wait_for_timeout(2000) assert dashboard in page.url print(登錄測試通過) await manager.close() if __name__ __main__: asyncio.run(test_login())跑通這段代碼你就有了一個(gè)能自動理解頁面語義的測試腳本。實(shí)測下來從零開始到跑通第一個(gè)用例熟練的話 5 分鐘確實(shí)夠新手大概 15 到 20 分鐘。5. 實(shí)操中踩過的坑與排查技巧5.1 模型返回的選擇器不唯一這是最常見的問題。比如頁面上有兩個(gè)提交按鈕模型可能返回了一個(gè)通用的button選擇器導(dǎo)致點(diǎn)錯(cuò)。我的解決辦法是在 prompt 里明確要求返回唯一選擇器并且在代碼里加一層校驗(yàn)count await page.locator(selector).count() if count 1: # 回退到更精確的定位 selector f{selector}:has-text({description})5.2 動態(tài)加載頁面元素抓取不全有些頁面是懶加載的初始 DOM 里沒有目標(biāo)元素。這時(shí)候需要先滾動頁面觸發(fā)加載await page.evaluate(window.scrollTo(0, document.body.scrollHeight)) await page.wait_for_timeout(1000)5.3 iframe 內(nèi)的元素定位如果目標(biāo)元素在 iframe 里page.evaluate是抓不到的。需要先切換到對應(yīng)的 frameframe page.frame_locator(iframe#content) elements await frame.locator(button).all()5.4 常見問題速查表問題現(xiàn)象可能原因解決方法模型返回空選擇器DOM 簡化后元素太少擴(kuò)大提取范圍加入 div 等容器標(biāo)簽點(diǎn)擊后無反應(yīng)元素被遮擋用page.click(selector, forceTrue)超時(shí)錯(cuò)誤頁面加載慢增加wait_for_load_state等待時(shí)間token 超限D(zhuǎn)OM 太大只提取可見元素過濾display:none選擇器失效前端改版重新跑一次定位鏈讓模型重新生成提示不要完全信任模型的輸出。我一般會在關(guān)鍵操作前加一個(gè)截圖方便出問題時(shí)回溯。await page.screenshot(pathdebug.png)這行代碼救過我很多次。6. 性能優(yōu)化與成本控制6.1 緩存選擇器同一個(gè)頁面反復(fù)定位同一個(gè)元素是浪費(fèi)。我加了一個(gè)簡單的內(nèi)存緩存self.selector_cache {} async def smart_click(self, description): if description in self.selector_cache: selector self.selector_cache[description] if await self.page.locator(selector).count() 1: await self.page.click(selector) return selector # 緩存失效重新定位 ...這樣在同一個(gè)測試會話里第二次點(diǎn)擊同一個(gè)按鈕就不會再調(diào)用模型了。6.2 批量定位如果一個(gè)頁面要操作多個(gè)元素可以一次性把所有描述傳給模型讓它返回一個(gè)映射表而不是逐個(gè)調(diào)用。這樣能把 N 次模型調(diào)用壓縮成 1 次成本直接降一個(gè)數(shù)量級。6.3 模型選型建議模型定位準(zhǔn)確率單次成本適用場景gpt-4o-mini85%極低常規(guī)頁面元素特征明顯gpt-4o95%中等復(fù)雜表單動態(tài)內(nèi)容本地小模型60-70%免費(fèi)內(nèi)網(wǎng)環(huán)境對準(zhǔn)確率要求不高我個(gè)人的建議是日?；貧w測試用 mini關(guān)鍵鏈路用 4o本地模型只在完全離線場景下考慮。7. 后續(xù)擴(kuò)展方向這套框架跑通后可以往幾個(gè)方向擴(kuò)展。一是接入 pytest把每個(gè)測試用例寫成獨(dú)立的 test 函數(shù)用 pytest-asyncio 管理異步執(zhí)行。二是加入視覺比對用 Playwright 的截圖功能配合圖像差異算法檢測頁面渲染是否異常。三是把定位鏈換成 LangGraph支持多輪交互——比如模型第一次沒找到元素時(shí)自動觸發(fā)滾動頁面再找一次的循環(huán)邏輯。我在實(shí)際項(xiàng)目里還加了一個(gè)自愈機(jī)制當(dāng)某個(gè)選擇器連續(xù)三次定位失敗時(shí)自動觸發(fā)模型重新生成并把新選擇器寫回緩存。這個(gè)機(jī)制讓腳本的維護(hù)頻率從每周一次降到了每月一次省下來的時(shí)間相當(dāng)可觀。最后分享一個(gè)小技巧如果你在調(diào)試階段把headless設(shè)為False能看到瀏覽器實(shí)際操作過程定位問題時(shí)非常直觀。等腳本穩(wěn)定后再切回True跑回歸測試時(shí)速度會快很多。