谷歌工程師吐槽：視覺測試做了8年，為什么還是這么難搞

去年一個前端團隊為排查按鈕偏移2像素的問題，花了47小時。最后發現是Chrome更新導致的渲染差異——這種故事在視覺差分測試（VDT）領域每天都在上演。

VDT也叫視覺回歸測試（VRT），核心邏輯簡單粗暴：給UI截圖，存下來，下次跑測試再截一張，兩張圖疊在一起找不同。聽起來像找茬游戲，實際玩起來卻像在開盲盒。

像素級對比：理想豐滿，現實骨感

最常見的做法是逐像素比對。兩張圖疊在一起，透明度調低，差異區域會顯出鬼影。或者直接用算法掃描每個像素點，記錄RGB值偏差超過閾值的位置。

但CSS的渲染從來都不是確定性的。同一臺機器，同一個瀏覽器版本，兩次截圖可能有0.3%的像素噪聲。抗鋸齒算法、子像素渲染、GPU加速的細微差異，都會讓"完全一致"變成不可能任務。

于是工具廠商開始卷AI。用機器學習判斷"這算不算真正的差異"，試圖區分"按鈕確實移位了"和"陰影渲染抖了一下"。但訓練數據從哪里來？每個團隊的UI風格不同，誤報率依然居高不下。

一位從業8年的工程師直言：我們不是在測試視覺，是在和瀏覽器的渲染引擎賭博。

應用場景分裂：App團隊vs網站團隊

VDT的痛點還體現在需求分化上。

做應用（Application）的團隊，對2像素偏移基本無感。他們更想要"冒煙測試"——確認頁面沒崩、核心流程能走通。比如防止某個全局樣式意外把透明度設為0.6，導致整個界面變成幽靈模式。

做網站（Site）的團隊則相反。營銷頁面對像素級還原有執念，品牌色偏了5%都可能觸發返工。他們的測試覆蓋整頁截圖，但這也意味著任何動態內容——日期、推薦算法、A/B測試桶——都會制造假陽性警報。

兩種需求，同一套技術棧，工具廠商被迫做選擇題。

維護成本：截圖即債務

每個存下來的截圖都是技術債務。設計系統迭代一次，幾百張基準圖集體作廢。團隊規模上去后，VDT的維護工時經常超過寫新功能的工時。

有團隊嘗試過"智能忽略"策略：用DOM選擇器標記動態區域，比對時跳過。但標記本身需要人工維護，新成員經常漏標，導致漏檢真實bug。

更激進的方案是放棄像素比對，轉向"結構比對"——提取元素的尺寸、位置、顏色值做對比。但這又繞回了CSS的復雜性：一個flex布局的微小調整，可能引發連鎖位置變化，結構比對會報出一堆無關緊要的偏移。

工程師的終極困惑是：我們到底在防什么？是防視覺回歸，還是防"我沒意識到改了這里"？

工具生態：百花齊放，各懷鬼胎

開源工具從BackstopJS到Percy再到Playwright的內置方案，商業服務從Chromatic到Applitools，每家都在解決不同層面的問題。

BackstopJS免費但配置繁瑣，Percy被BrowserStack收購后定價模糊，Chromatic綁定Storybook生態，Applitools的AI視覺網格貴到中小企業望而卻步。沒有銀彈，只有權衡。

Playwright 1.40版本加入了實驗性的"toHaveScreenshot"斷言，試圖用瀏覽器原生能力降低門檻。但社區反饋兩極：有人稱贊"終于不用配Docker了"，有人抱怨"截圖穩定性還是不如Puppeteer時代"。

技術選型變成了一場宗教戰爭。選A的人嘲笑選B的人"還在用2018年的方案"，選B的人反擊選A的人"被廠商鎖死"。

如果視覺測試的終極形態不是截圖比對，那應該是什么？組件級的設計令牌（Design Token）校驗？渲染管道的確定性保證？還是干脆承認UI的視覺層本就不可測試，把資源投到人工走查流程的優化上？