同一份程式、同一個測試,這次綠、下次紅、再跑一次又綠。這就是 flaky。

技術上它只是不穩定,真正的傷害發生在心理層面:它教會團隊忽略紅燈。而一支學會忽略紅燈的團隊,等於沒有自動化測試。

一、為什麼 flaky 比沒有測試更傷

圖 1:從時紅時綠到信任崩壞的循環

循環是這樣走的。測試無關對錯地時紅時綠,大家開始說「喔,那個本來就會紅」。紅燈被習慣性重跑、忽略。然後某天,真正的 bug 造成的紅燈混在裡面,一起被忽略,流進正式環境。

注意最後一步:flaky 除了自己沒用,還廢掉了其他好測試的警報功能。所以治理 flaky 的優先級,應該高於寫新測試。警報器要嘛可信,要嘛拆掉,不能又響又沒人理。

二、業界的做法:五個步驟

成熟團隊處理 flaky 的流程大同小異,拆開來就是五步。測試人員的日常工作,主要落在中間三步。

圖 2:flaky 的標準處理流程

第一步:偵測 — 讓 flaky 現形

Playwright 的 retry 機制就是偵測器。設定失敗自動重試以後,報告會特別標出「重試後才通過」的測試,那就是你的 flaky 名單。
你可以這樣對 Claude Code 說:

幫專案開啟測試重試(失敗後重試 2 次),並說明:報告上哪裡看得到「重試後才通過」的測試?我想每週整理一份 flaky 清單,有沒有辦法把這類測試列出來?

紀律講清楚:重試是偵測手段,不是解決方案。重試讓當下過關,但 flaky 還在。每一個「重試後才過」都要進清單、被診斷。把重試當止痛藥吃到忘記病因,清單只會越來越長。

第二步:記錄 — 開票,給它一個主人

這一步最容易被跳過,卻是整套流程能不能運作的關鍵。業界的做法是把 flaky 當成 bug 處理:一支測試一張票,進追蹤系統,不是留在某個人的記事本裡。

一張票至少要有五個欄位:測試名稱、出現頻率、首次發現日期、疑似根因分類、負責人。
頻率怎麼量?把同一支測試連續跑固定次數(業界常用 10 次或 20 次),記錄紅了幾次。這個數字之後有三個用途:決定要不要隔離、判斷修完了沒、跟團隊溝通時當證據。

你可以這樣對 Claude Code 說:

請幫我寫一個指令,把指定的測試連續執行 20 次,統計失敗了幾次,最後輸出一行摘要(測試名稱、失敗次數、失敗率)。

第三步:分類 — 三類根因,三種修法

圖 3:flaky 的常見根因分類

● 時序問題:最大宗。寫死的等待、搶在資料載入前就驗證。修法回第 8 篇,用明確訊號等待。
● 資料干擾:第二名。測試共用資料,執行順序影響結果。解藥就是上一篇的資料隔離。
● 環境不穩:測試環境資源不足、依賴的第三方服務抖動。這類改測試解不了,要帶著證據跟團隊談基礎設施。

診斷的利器還是 trace(第 10 篇)。flaky 難就難在要重現才能查,而 trace 把失敗那一次的現場整包留下來了。

丟給 Claude Code 時,記得附上頻率資訊,例如:「這個測試十次約紅兩次,紅的時候都卡在同一步」。出現機率的描述,本來就是回報間歇性 bug 的基本功,在這裡直接變現。

第四步:隔離 — 對付一時修不好的

有些 flaky 一時查不出、修不動,又不能讓它繼續污染紅燈的公信力。業界通行的做法是設隔離區:標記後移出主要測試集,另外排程執行、持續觀察。

圖 4:隔離區的進出規則

三個配套缺一不可。隔離要有名單和負責人,不能丟進去就失憶;每張隔離票要有到期日,常見是兩週或一個 Sprint,到期沒修就進退場審查,要嘛修、要嘛刪;隔離區還要設數量上限,超過就停下新測試先清帳。

你可以這樣對 Claude Code 說:

幫我在專案裡加一組 flaky 標記機制:被標記的測試不進主要測試集,另外有一個指令可以單獨執行它們,方便我每天排程觀察。

隔離的本質是誠實記帳:承認這個警報器暫時壞了,好過假裝它還能用。

第五步:回主線 — 修好之後還要觀察

改完不等於好了。業界的判準是「連續穩定通過」才放回主線,常見的門檻是連續 20 次或觀察一週。用第二步量頻率的同一個指令驗收,前後數字擺在一起,修得好不好一目了然。

團隊層級追蹤兩個數字就夠:隔離區的測試數量(趨勢往下才健康),以及紅燈的可信度。

三、今天的練習

● 幫你的專案開 retry,連續跑全部測試五次,看有沒有「重試後才過」的浮出來。有,恭喜提前抓到;沒有,也建立了基準。
● 建一個 flaky 清單文件,欄位就五個:測試名稱、出現頻率、發現日期、疑似根因分類、負責人。之後每週維護。
● 挑清單上頻率最高的那一支,用連續執行 20 次的指令量一次,把數字寫進票裡。
● 跟團隊聊一個問題:「我們現在看到紅燈的第一反應是什麼?」答案是「重跑看看」的話,把圖 1 的信任崩壞循環拿給大家看。