摘要

自動化測試有時(shí)通過、有時(shí)失敗，通常被稱為 Flaky Test。這類問題比固定報(bào)錯(cuò)更難排查，因?yàn)樗赡芘c異步操作、時(shí)間、隨機(jī)數(shù)據(jù)、測試順序或外部服務(wù)有關(guān)。本文介紹如何使用 Codex 收集失敗證據(jù)、定位不穩(wěn)定因素，并通過重復(fù)運(yùn)行和 Git Diff 驗(yàn)證修復(fù)結(jié)果。

在項(xiàng)目開發(fā)中，最難處理的測試不一定是“每次都失敗”，而是下面這種情況：

第一次運(yùn)行：通過
第二次運(yùn)行：失敗
第三次運(yùn)行：通過

這類偶發(fā)失敗會影響 CI/CD 穩(wěn)定性，也容易讓團(tuán)隊(duì)誤以為是構(gòu)建平臺出了問題。

不少開發(fā)者會直接讓 Codex：

把這個(gè)測試改到可以通過。

這種要求很危險(xiǎn)。Codex 可能通過增加重試、延長等待時(shí)間或降低斷言標(biāo)準(zhǔn)，讓失敗暫時(shí)消失，卻沒有解決真正原因。

一、先確認(rèn)是否屬于 Flaky Test

建議先重復(fù)運(yùn)行同一個(gè)測試：

npm run test -- user-profile.test.ts

或者連續(xù)執(zhí)行多次：

for i in {1..20}; do
  npm run test -- user-profile.test.ts || break
done

需要記錄：

• 失敗出現(xiàn)的頻率；
• 是否只在 CI 中失?。?/li>
• 單獨(dú)運(yùn)行是否通過；
• 與其他測試一起運(yùn)行是否失敗；
• 失敗日志是否完全一致；
• 是否與執(zhí)行順序有關(guān)。

可以把這些結(jié)果交給 Codex：

當(dāng)前測試連續(xù)運(yùn)行 20 次，其中失敗 4 次。

單獨(dú)運(yùn)行通常通過，
與完整測試集一起運(yùn)行時(shí)更容易失敗。

請先分析，不要修改測試。

輸出：

1. 最可能的不穩(wěn)定因素；
2. 如何驗(yàn)證每個(gè)原因；
3. 需要檢查哪些文件；
4. 最小修復(fù)方案；
5. 如何證明問題已經(jīng)解決。

二、重點(diǎn)排查五類原因

1. 異步操作沒有等待完成

例如頁面仍在請求數(shù)據(jù)，測試已經(jīng)開始斷言：

render(UserProfile);

expect(screen.getByText("張三")).toBeInTheDocument();

更合理的方式是等待元素出現(xiàn)：

expect(
  await screen.findByText("張三")
).toBeInTheDocument();

但不能簡單地把所有等待時(shí)間延長。真正需要確認(rèn)的是：測試是否等待了明確的業(yè)務(wù)結(jié)果。

2. 測試之間共享狀態(tài)

某個(gè)測試修改了全局變量、緩存或 Mock，卻沒有清理，可能影響后續(xù)測試。

重點(diǎn)檢查：

• localStorage；
• 全局狀態(tài)管理；
• 數(shù)據(jù)庫測試數(shù)據(jù)；
• Mock 請求；
• 單例對象；
• 環(huán)境變量；
• Fake Timer。

建議在每個(gè)測試結(jié)束后恢復(fù)狀態(tài)：

afterEach(() => {
  localStorage.clear();
  vi.clearAllMocks();
  vi.useRealTimers();
});

3. 依賴真實(shí)時(shí)間

如果測試與當(dāng)前日期、時(shí)區(qū)或倒計(jì)時(shí)有關(guān)，在不同時(shí)間和環(huán)境中可能得到不同結(jié)果。

例如：

const today = new Date();

可以在測試中固定時(shí)間：

vi.useFakeTimers();
vi.setSystemTime(new Date("2026-07-23T10:00:00Z"));

這樣本地和 CI 執(zhí)行時(shí)會得到一致結(jié)果。

4. 使用隨機(jī)數(shù)據(jù)

測試中直接使用隨機(jī)數(shù)、隨機(jī)用戶名或隨機(jī)訂單狀態(tài)，會導(dǎo)致結(jié)果不可復(fù)現(xiàn)。

不建議：

const quantity = Math.floor(Math.random() * 10);

更推薦固定輸入，或者記錄隨機(jī)種子：

const quantity = 3;

測試的目標(biāo)是驗(yàn)證確定行為，而不是每次制造不同條件。

5. 依賴外部服務(wù)

如果測試直接請求真實(shí) API、數(shù)據(jù)庫或第三方服務(wù)，網(wǎng)絡(luò)延遲和服務(wù)狀態(tài)都會影響結(jié)果。

更穩(wěn)定的方式是：

• 單元測試使用 Mock；
• 集成測試使用獨(dú)立測試環(huán)境；
• 外部服務(wù)設(shè)置明確超時(shí)；
• 測試數(shù)據(jù)可重復(fù)創(chuàng)建和清理；
• 將外部依賴測試與普通單元測試分開。

三、不要用重試掩蓋根因

一些 CI 平臺支持失敗后自動重試。重試可以作為臨時(shí)保護(hù)，但不能代替修復(fù)。

如果一個(gè)測試重試三次后通過，仍然說明它不穩(wěn)定。

需要警惕這些修改：

增加等待時(shí)間；
降低斷言標(biāo)準(zhǔn)；
跳過失敗測試；
設(shè)置多次重試；
捕獲異常后不處理。

可以讓 Codex審查：

請檢查當(dāng)前修復(fù)是否只是隱藏 Flaky Test。

重點(diǎn)確認(rèn)：

1. 是否增加了無依據(jù)的延遲；
2. 是否降低了斷言；
3. 是否加入重試但沒有修復(fù)根因；
4. 是否遺漏狀態(tài)清理；
5. 是否仍依賴真實(shí)時(shí)間或外部服務(wù)。

四、修復(fù)時(shí)堅(jiān)持最小范圍

假設(shè)問題來自用戶狀態(tài)沒有清理，本次修改只需要涉及：

用戶狀態(tài)測試；
測試初始化文件；
相關(guān) Mock。

不應(yīng)該順便重構(gòu)完整用戶模塊。

可以明確限制：

允許修改：

- tests/user
- tests/setup.ts
- 用戶狀態(tài)相關(guān) Mock

禁止修改：

- 生產(chǎn)業(yè)務(wù)邏輯；
- 路由配置；
- 權(quán)限規(guī)則；
- package.json；
- 無關(guān)測試文件。

如果確認(rèn)生產(chǎn)代碼本身存在競態(tài)條件，再單獨(dú)建立業(yè)務(wù)修復(fù)任務(wù)。

五、修復(fù)后如何證明穩(wěn)定？

一次測試通過不能說明 Flaky Test 已經(jīng)解決。

建議完成三層驗(yàn)證。

第一層：重復(fù)運(yùn)行當(dāng)前測試

連續(xù)執(zhí)行 20—50 次，確認(rèn)不再偶發(fā)失敗。

第二層：與完整測試集一起運(yùn)行

npm run test

檢查是否存在測試順序依賴。

第三層：在 CI 環(huán)境驗(yàn)證

確認(rèn) Linux、不同 Node.js 版本或并行執(zhí)行時(shí)仍然穩(wěn)定。

同時(shí)運(yùn)行：

npm run type-check
npm run lint
npm run build

最后檢查：

git status
git diff --stat
git diff

確認(rèn)沒有通過刪除測試、放寬斷言或修改無關(guān)文件獲得“穩(wěn)定”。

六、讓 Codex 輸出測試修復(fù)報(bào)告

任務(wù)完成后可以要求：

請輸出 Flaky Test 修復(fù)報(bào)告：

1. 問題現(xiàn)象；
2. 失敗頻率；
3. 根本原因；
4. 修改文件；
5. 修復(fù)方式；
6. 重復(fù)運(yùn)行結(jié)果；
7. 完整測試結(jié)果；
8. 仍然存在的風(fēng)險(xiǎn)。

例如：

## 根本原因

測試使用 Fake Timer 后沒有恢復(fù)真實(shí)時(shí)間，
導(dǎo)致后續(xù)用戶狀態(tài)測試的超時(shí)邏輯異常。

## 修復(fù)內(nèi)容

- 在 afterEach 中恢復(fù)真實(shí)時(shí)間；
- 清理用戶狀態(tài)和 Mock；
- 補(bǔ)充測試順序驗(yàn)證。

## 驗(yàn)證結(jié)果

- 當(dāng)前測試連續(xù)運(yùn)行 50 次：全部通過
- 完整測試集：通過
- 類型檢查：通過
- 項(xiàng)目構(gòu)建：通過

七、什么時(shí)候適合評估升級 Pro？

偶爾分析一個(gè)失敗測試，現(xiàn)有方案通常能夠滿足需求。

但如果每天都需要 Codex：

• 閱讀大量 CI 日志；
• 重復(fù)運(yùn)行測試；
• 分析異步和競態(tài)問題；
• 修改多個(gè)測試與業(yè)務(wù)文件；
• 連續(xù)處理多輪失敗結(jié)果；
• 同時(shí)維護(hù)多個(gè)倉庫；

任務(wù)會形成較長的調(diào)試鏈路。

這時(shí)應(yīng)先通過限定測試范圍、固定時(shí)間、清理共享狀態(tài)和拆分任務(wù)減少無效消耗。如果工作流已經(jīng)優(yōu)化，但測試分析、修改和重復(fù)驗(yàn)證仍經(jīng)常因使用限制中斷，就可以重新評估當(dāng)前方案。

對于長期把 Codex 用于測試、調(diào)試和項(xiàng)目交付的開發(fā)者，Pro 更適合持續(xù)推進(jìn)多輪工程任務(wù)，減少在問題尚未驗(yàn)證完成時(shí)反復(fù)恢復(fù)上下文的成本。

總結(jié)

Flaky Test 的難點(diǎn)不是讓它“這一次通過”，而是證明它以后能夠穩(wěn)定通過。

更可靠的處理流程是：

記錄失敗頻率 → 定位不確定因素 → 最小范圍修復(fù) → 重復(fù)運(yùn)行驗(yàn)證 → 完整測試與 CI 檢查。

Codex 可以幫助分析異步邏輯、共享狀態(tài)、時(shí)間和外部依賴，但不能通過重試或降低測試標(biāo)準(zhǔn)掩蓋問題。

只有測試結(jié)果可重復(fù)、失敗原因可解釋、修改范圍可審查，才算真正完成修復(fù)。

以上就是Codex遇到測試偶爾失敗的排查與修復(fù)流程的詳細(xì)內(nèi)容，更多關(guān)于Codex遇到測試偶爾失敗的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論