Part 4 的倒數第二天。今天講一個結構性的問題，而且那個案子把它列為唯一沒有解決的問題。它叫「安全網的不對稱」，一句話是：
十次升級全部通過，但每一次的安全感只來自一個專案。其餘六個是靠「編譯過就算」撐過去的。
那個工作區有七個專案，共用同一套建置設定。升級的時候一起升，測試的保障卻天差地遠：
| 專案 | 測試條數 | 端到端 | 升級時的實際保障 |
|---|---|---|---|
| A（主戰場） | 114 ✅ | 4 條全流程 | 單元 + 流程 + UI + 對話框實拍 |
| B（共用元件庫） | 454（5 條紅） | 無 | 單元（有既有紅燈） |
| C | 測試檔編譯失敗 | 無 | 只有「編譯過」 |
| D | 測試檔編譯失敗 | 無 | 只有「編譯過」 |
| E | 1 條 | 無 | 幾乎沒有 |
| F | 2 條（紅） | 無 | 幾乎沒有 |
| G | 0 條 | 無 | 無 |
C 和 D 那兩個「測試檔編譯失敗」的原因很有意思：是壞掉的 CLI 樣板。引用了不存在的東西。產品程式本身是好的。
換句話說：那兩個專案連「測試能不能編譯」都沒有人管。
一、Day 29 那個對話框破圖，就是這樣存活的。
三次升級的 UI 比對都報「4/4 一致」，因為截圖拍不到對話框。而唯一有能力補上對話框截圖的專案，就是 A。其餘三個專案共 52 處對話框呼叫，至今沒有任何實拍。
二、每份報告都必須寫「未涵蓋」。
十次升級的報告裡，「連帶升級（僅驗證編譯）」這句話出現了 60 次以上。這是誠實的。但它同時意味著：如果那六個專案在某一版壞了，我們不會知道。
三、修正只能做「機制驗證」，不能做「畫面驗證」。
某兩個專案的對話框圓角修正，最後的證據是：
三項裡缺了最直接的那一項。
上面講的都是缺口。但同一份資料也證明了反面。
最後一版有 4 筆人工修正。包括六處語法改寫、測試基礎建設調整。這些不是自動遷移做的，是人動手改的。
而它們全部能在當天驗證完並確認沒有回歸。
為什麼？因為那 114 條測試和 4 條全流程端到端測試在。如果沒有那套安全網，那 4 筆修正只能靠「編譯過」交差。然後你就不敢改了。
所以這件事的真正意義不是「測試覆蓋率高比較好」這種老生常談，而是：
安全網決定了「你敢改的範圍」。
沒有網的地方，你只能做最保守的改動。能不動就不動、能繞過就繞過、能延後就延後。
而那些「不敢改」會累積成技術債，最後變成下一次升級的阻力。
我想講清楚一件事：這不是誰偷懶。
那個案子的資源分配是完全理性的：
在有限的時間裡，把資源集中在主戰場，是對的決定。
問題不在決定本身，在於那個不對稱有沒有被看見、有沒有被寫下來。
而這個案子做對的地方就在這裡：它寫下來了。
那份分布表就是證據。每個專案有幾條測試、有沒有端到端、實際保障是什麼，一目了然。
而且它被列為「唯一沒解決的結構性風險」。
不是「要把測試補齊」——那是廢話，而且通常做不到。
是這個：
把你的安全網分布畫出來，然後誠實標註哪些區域沒有網。
因為一旦畫出來，三件事會自動發生。
一、你會知道自己在哪裡是瞎的。 那六十次「僅驗證編譯」不是失敗，是已知的盲區。
二、你會知道改動的風險不是均勻的。 同樣一行改動，在 A 專案是安全的，在 G 專案是賭博。
三、它會變成補網的優先序。 下次有時間補測試，你知道該補哪個。
而如果沒有畫出來，那六個專案的風險會看起來跟 A 專案一樣。因為報告上都寫著「升級成功」。
我把它推廣成一個問句，我覺得任何專案都可以問：
你的驗證覆蓋，是均勻的嗎？
大部分專案的答案都是「不均勻」，而且不均勻的分布通常長這樣：
第三項最危險。共用元件被所有地方依賴，但它通常沒有自己的測試。因為「用它的地方都有測試」。
而那個案子的資料剛好印證了這一點：共用元件庫有 454 條測試，但其中 5 條是紅的，而且是既有的紅燈。沒有人管，因為它「一直都是紅的」。一個一直是紅的測試，等於沒有測試。 而且比沒有更糟。它佔了一個位置，讓人以為那裡有防護。
如果你想試試看，這個練習大概二十分鐘：列出你專案的所有模組／子專案，每一個填三欄：
| 模組 | 測試條數 | 有沒有端到端 | 出事會怎麼被發現 |
最後一欄最重要。填不出來的，就是盲區。
我第一次做這個練習的時候，最後一欄有一半填的是「使用者反映」。
明天是 Part 4 最後一天，講一個我在別的案子看到、而且沒在任何方法論裡看過的做法：寫下你會忍不住相信的錯誤。
iThome鐵人賽
看影片追技術