16 個失敗只有 2 個是缺口 — 大規模測試失敗先分診、再按 ROI 修
觸發場景：Flutter 書籍管理 App 的穩定化時期，兩批大規模測試失敗前後出現：一批 16 個（UI 統一化與 Book 模型簡化之後）、一批 25 個（error dialog 與整合測試）。直覺的做法是從第一個紅燈開始逐個修 疑問來源：逐個修哪裡錯了？失敗清單本身不就是工作清單嗎？ 整理目的：記下「先分診、再修復」的操作方式與兩批實戰的分類結果——失敗數是被分類稀釋過才有意義的訊號 本文邊界：素材是該專案 v0.25 與 v0.28 兩份根因分析記錄；分類軸是這兩批的結果、不是通用分類法——可遷移的是「先分診」跟「按 ROI 排序」兩個動作
第一批：16 個失敗、一半不是 bug
第一批分診的結果直接推翻「失敗數 = 待修 bug 數」的直覺：
| 類別 | 數量 | 佔比 | 實際意義 |
|---|---|---|---|
| 測試過時 | 8 | 50% | UI 統一化改了圖標 / 顏色 / 文字、斷言沒跟上 |
| 設計變更未同步 | 6 | 37.5% | 實作的行為契約變了、測試還在驗舊契約 |
| 功能真未實作 | 2 | 12.5% | 真正的缺口 |
一半的失敗是表現層變動讓斷言過時——功能沒壞、測試在驗一個已經被設計決策淘汰的外觀。這類的修法是更新期望值、成本極低；但混在清單裡逐個修的時候，它們跟真缺口消耗同樣的診斷注意力。分類後 16 個失敗的真實工作量現形：2 個要寫功能、其餘是同步斷言。
分診還有一個副產物：它逼出被失敗掩蓋的設計決策。同一批分析揪出兩個「測試失敗其實是設計問題」的案例——掃描服務在同一個 class 裡混用三種錯誤語意（拋異常、內部 catch 成 Result、直接回 void），測試不知道該期待哪種；Book 模型簡化時把「空值拋 ValidationException」改成「給預設值正常返回」、驗證策略變了卻沒同步到任何測試。這兩個都不是「修測試」能解的，要先做設計裁定（統一 Result 模式；確認建構驗證的邊界規則）、測試才有對齊的對象。
第二批：25 個失敗、修一個 helper 救九個
第二批的分類多了一個維度——修復順序不按失敗數量、按單位工時救回的測試數：
| 類別 | 數量 | 修法 | 排序理由 |
|---|---|---|---|
| AppLocalizations 未配置 | 9 | 改一個 test helper（補 delegates） | 1-2 小時救 9 個、先修 |
| RenderFlex 溢位 | 10 | SearchDialog 版面重構（三個選項） | 影響真實可用性、次修 |
| 功能真未實作 | 4 | 補元件實作 | 要寫新功能、排後 |
| 文字期望過時 | 2 | 更新斷言 | 快速掃尾 |
九個失敗共用同一個根因（測試 wrapper 沒配 LocalizationsDelegate、AppLocalizations.of(context) 回 null），修法是一處——helper 補上 delegates 跟 supportedLocales。失敗數最大的類別（溢位 10 個）反而排第二，因為它的修法是逐個版面調整、單位工時救回數低。ROI 排序的價值在士氣之外很實際：最早的修復讓紅燈數雪崩式下降，後續分診的雜訊立刻變少。
溢位那類還留下一筆值得引用的數據：SearchDialog 的溢位量隨狀態增長（idle 81px、loading 132px、error 167px）——Column 沒有高度約束時，每多一個條件渲染的區塊就多一段溢位。這是「Widget 測試要跑多版型」的實證來源。
症狀特徵字串：讓下一批失敗直接對號
兩批分析都替每個類別記了 signature——第一眼就能分類的錯誤特徵：
Null check operator used on a null value+AppLocalizations.of→ 測試環境配置RenderFlex overflowed by N pixels→ 版面約束means none were found but one was expected→ 元素不存在（未實作或文字過時、看查詢目標分流）
特徵字串的價值在複利：第一批花的分類工時、以索引的形式折舊給之後每一批。下次紅燈爆量時 grep 錯誤輸出對表，多數失敗在動手前就完成分類——這也是分診值得留檔（而不是修完就丟）的原因。
操作收束
失敗數超過十個時的順序：全數分類 → 按 ROI 排序 → 逐類修。分類的產物是一張「類別 / 根因 / 修法 / 數量 / 工時」表，它同時回答三件事：真實工作量多大（過時斷言不算 bug）、先修哪個（單位工時救回數）、有沒有被掩蓋的設計決策要先裁（錯誤語意混用這類）。跳過分診直接修的隱性代價是把四種性質的工作（同步斷言、改 helper、調版面、寫功能）混進同一個工作流，每切換一個失敗就切換一次心智模式。
相關閱讀
- 前置條件：紅燈在量什麼——那篇處理「失敗數可不可信」（斷言 / 量測 / 環境），本文處理「可信之後怎麼消化」；順序是先確認訊號、再分診
- 分診逼出的設計債案例：VO 封裝擺盪與 Book 建構驗證策略變更同屬「設計決策變了、下游沒同步」家族
- 原則層：#92 視覺手段對齊錯誤層次——修法要對準層次的測試版：斷言過時修斷言、配置缺失修 helper、設計混亂先裁設計