這個假設從來沒有完全成立。站內的 Assertion 品質三問把 isNotNull、isA 列為人手寫測試裡常見的無效斷言，T.C3 就是一個實例。變的是規模：套件小到可以逐條抽查時，這類斷言會在 review 裡被指出來；斷言可以整批產生之後抽查追不上，塌掉的是這個假設的可稽查性——它本身的正確性一直都只是近似。於是需要一個不靠抽查、而且用空斷言達不到的指標——突變測試是目前唯一一種空斷言達不到的成熟指標——這個性質來自它的構造，不隨工具生態變動。

覆蓋率失效的形狀

覆蓋率不是變得不準，是執行足跡與偵測能力之間的相關性斷了。一個測試呼叫函式、檢查它沒有拋出例外，覆蓋率把那幾行算進去；同一個測試對回傳值不做任何檢查，偵測能力是零。這種測試被稱為永遠綠的測試，它在覆蓋率報表上與一個嚴謹的測試無法區分。

T.C10 的數據顯示了這個斷裂的程度：事後補測試、逐函式測試、以及 TDD 三法則（沒有失敗的測試就不寫 production code、只寫剛好會失敗的測試、只寫剛好讓它通過的實作）加上複雜度上限，這三種做法產出的程式與套件組成完全不同，行覆蓋率全部停在 97% 到 99%。被覆蓋率區分出來的只有兩端——零測試又不開複雜度上限那一版停在 14% 與 24%（前者是分支形式的覆蓋、後者是行覆蓋；同一組紀律開啟複雜度上限的那一列被迫生出 40 個範例、覆蓋率跟著跳上來），數字全部來自載入而非斷言；三法則不開複雜度上限的那一版停在 85.81% 行覆蓋，作者標為 outlier，成因是主控台迴圈只被輕度驅動。也就是說它分得出「有沒有測試」與「有沒有一整塊沒被驅動」，分不出「測試好不好」。分得出有無、分不出好壞。

這給覆蓋率一個誠實的定位：它是下限指標。低覆蓋率確實代表有問題，高覆蓋率不代表沒問題，而把它當成通過條件會讓「達成它」變成最便宜路徑的目標。

突變分數量的是什麼

突變測試對程式注入單點的行為改變——把 > 換成 >=、把回傳值換成常數、刪掉一次呼叫——再看測試會不會因此變紅。變紅稱為殺死，全綠稱為存活。存活的突變指出一件具體的事：程式在那個位置改掉行為，這套測試不會發現。

突變分數（殺死數除以有效突變數）用字面上的空斷言達不到：要殺死突變，斷言必須真的檢查到那個行為。這是它取代覆蓋率當閘門的理由——不是它更精確，是覆蓋率最便宜的那條達成路徑對它無效。

但「低思考量」的路徑沒有被完全堵死，下一段的四條就是它們，其中兩條的思考量與空斷言同級。所以突變分數擋掉的是一種特定的作弊，不是所有作弊。

它並沒有因此免疫於機械約束的通病。這件事在分數只是本機參考值時不會發生，一旦它變成 CI 的通過門檻或團隊報表上的一個數字，讓它上升就有了立即收益——而有立即收益的最便宜動作一定會發生。便宜的達成路徑至少有四條。前三條改在設定檔裡——縮小掃描範圍（只掃已經寫好測試的模組）、放寬等價突變的排除清單、削弱算子集（拿掉最會存活的那幾種突變）；它們不留痕跡於測試碼，所以設定檔要進版控，變更要跟分數變化一起看。

第四條在測試碼裡，而且它是這裡最需要提防的一條：錄製式斷言。把整個回傳值序列化後跟一份存下來的快照比對，思考量跟空斷言同級（不必想清楚哪個欄位重要），卻能一次殺死大量突變。它的判準是現狀而不是需求，也就是把整套測試變成行為快照——分數很高而「這個行為對不對」一個字都沒回答。防它的方式不是禁用快照，是問這份快照的預期值是誰決定的：由人審過的規格產生的合法，由實作跑一次產生的不合法。

還有一個不算作弊、但會讓分數失真的來源：例外導向的殺死。造成崩潰的突變連零斷言的 smoke test 都會紅，所以一套幾乎不做檢查的測試在多數專案也拿得到兩三成分數。看絕對分數之前先看這個基線。

導入的成本結構跟其他測試層不同：每個突變都要重跑一次相關測試，總時間是突變數乘上測試時間。壓下來靠三件事：

只跑這次改動的檔案。 完整跑一次的代價通常只在夜間排程或發版前接受得了，日常回饋要用差異模式。

用覆蓋率資料跳過沒被執行到的突變。 沒有任何測試執行到的程式碼，突變一定存活，跑它只是浪費——這是覆蓋率在新配置下仍然有用的地方：它變成突變測試的輸入而不是閘門本身。

平行執行並設定逾時。 有些突變會造成無窮迴圈，逾時要設得夠短，否則單一突變就吃掉整輪時間。

覆蓋率與偵測能力脫鉤這件事另有站內既有內容佐證（本章開頭引的 Assertion 品質三問與 T.C3），不單靠那份實驗；實驗本身的射程見模組入口。

存活的突變分兩類

處理方式相反，判錯了會傷到測試套件。

真的漏洞。 那個位置的行為改變確實沒有被任何斷言檢查到，補一條斷言。這是多數情形。

等價突變。 改寫之後行為完全相同。典型形態有兩種：一是等價的邊界寫法（i < n 換成 i <= n - 1），二是對結果沒有影響的短路順序（兩個都是純函式的條件互換前後）。這是工具的限制，要標記排除。為等價突變硬補斷言的代價是那條斷言必然綁在實作的寫法上，反過來傷害重構安全性，與行為優先的 TDD 要守的性質直接衝突。

判斷方式是問這個突變如果留在正式版本，有沒有任何一種輸入會讓使用者觀察到不同的結果。答案是沒有，它就是等價突變。

這個問題形式上可執行、實務上判不出來（等價性一般而言不可判定），所以要配一套不靠判準的處置紀律：單一突變的判定給一個時間盒（十五分鐘是個起始值，依領域邏輯的密度自行調整——密集的規則引擎值得久一點，膠水層更短），時間盒到了預設歸類為真漏洞而非等價突變（誤判成漏洞的代價是多寫一條斷言，誤判成等價的代價是永久失去一個偵測點）、排除清單的每一條要寫下「想不出區分輸入」的理由並具名，且由第二個人覆核。單人維護的專案沒有第二個人，這一項退化成定期回看自己的排除清單——此時清單的成長速度是唯一還在運作的訊號——它比程式碼成長得快時，判定已經放水了。

突變分數守不住什麼

這是導入時最需要先講清楚的一件事：突變是對照著程式現在的樣子產生的，所以它守得住「斷言不夠密」，守不住「這段程式一開始就實作錯了需求」。

把危險判定順序寫反的那份程式跑突變測試，長出來的斷言會把那個順序釘得更牢（機制推論，非實驗觀察）。那份實驗實際記載的是：突變長出來的第二套測試補的全是運算子層的翻轉，作者的結論是它「沒有發現一個不同的遊戲」。

這個限制在測試與實作出處不獨立時特別要緊，因為那正是規格層錯誤最容易產生的情境。突變分數 100% 的套件仍然可以整套建立在一個錯誤的需求理解上。

閘門要成對設計

每個機械閘門都有一個它量不到的維度，而達成該閘門最便宜的路徑通常就走在那個維度上。配對的檢查點要一起設，否則閘門會被最便宜的方式滿足。

複雜度上限那一列有實測的代價可以參考：同一份實驗在程式寫完後強制把圈複雜度壓到 3 以下，四個版本的函式數大致翻倍、覆蓋率上升到 97% 以上，而原作者給的可讀性評分全部落在最低的兩級，設計評分一次都沒有上升。他的描述是這個約束「不做簡化，只是繁殖名字」。這條的完整推導在 #278。

兩個前置條件

這一章的作法有兩個硬前提，任一個不成立時整套跑不起來，而它們不會在文件裡自己現身。

測試套件要是確定性的。 突變測試對 flaky test 極度敏感：一個隨機紅燈會被記成「殺死突變」，分數因此變成噪音、而且是往上飄的噪音。導入之前要先把已知的不穩定測試隔離出去，並確認隔離清單不在掃描範圍內。

該語言要有一個跑得動的突變工具。 工具的成熟度分語言差距很大（寫作當下 Java、JavaScript 與 Python 各有生產可用的實作，而包含 Dart 在內的不少語言還沒有），而這個生態逐年變動——導入前查一次該語言的現行實作，不要拿本文的舉例當現況。工具不存在時的替代品是性質式測試加上人工的斷言強度抽查，不是降級回覆蓋率。

導入順序

先有可信的判準，再談分數。順序顛倒的話，得到的是一套把錯誤需求釘得很牢的高分測試。

1. 驗收條件出處獨立、且做過維度交叉盤點
2. 覆蓋率降級成輸入而非閘門（餵給突變測試用來跳過未執行的位置）
3. 突變測試先在核心領域邏輯上跑，不要一開始就全庫
4. 門檻從現況起跳、只要求不倒退，不要一開始就訂絕對值
5. 等價突變的排除清單納入版控，並定期回顧——排除清單長得太快是判斷太寬鬆的訊號

這五步自己也是機械約束——#278 要求每個機械約束配一個它量不到的維度，而模組入口的「判定問題的答案要留下痕跡」那一節給的是本模組共用的配對形式。這裡只補一件它特有的：門檻採「只要求不倒退」時，最省力的達成是讓新程式落在掃描範圍的 glob 之外，所以納入率要跟分數並列著看，兩個數字缺一個就讀不出真相。

這五步預設閘門由團隊自己決定。門檻是外部義務時——寫進合約的覆蓋率下限、監理或內稽要求的指標——作法是疊加而不是替換：外部門檻照舊守著，突變分數當內部指標另外跑。有一件事值得寫進驗收流程或合約附件：覆蓋率達標可以用空斷言達成，所以它不構成驗收通過的充分條件；而要讓這句話有效力，它得寫在有約束力的地方，那已經超出這一章能處理的層。同樣的分辨也適用於逐行閱讀——code review 在受監理環境常是變更管理控制項，存在理由是留下具名的責任證據與四眼原則，跟偵測效率無關，那種 review 不能因為「效率低」而移除。

第三點的範圍選擇有實際差別：領域邏輯的突變幾乎都有意義，而 I/O 膠水層、序列化樣板、設定讀取的突變多半是等價的或無關緊要的，先跑那些會讓排除清單暴增而收益很低。

判讀訊號

下一步路由

• 判準本身怎麼取得獨立性 → 判準的推導來源
• 驗收條件的射程怎麼量 → 驗收條件的等價類
• 預期值連寫都寫不出來時怎麼辦 → 判準寫不下來的時候
• 術語卡 → Mutation Testing
• 機械約束的代價 → #278 機械約束買到被量測的那個數字
• 斷言本身怎麼寫才有鑑別力 → Assertion 品質三問

這個模組跟前五個模組的分工

模組一到五處理的是驗證發生在哪一層、斷言怎麼寫、盲區在哪裡。那些判準本身與作者身分無關，但它們被使用的方式建立在兩個假設上：寫測試的人懂需求，而且有人會讀完程式碼。程式碼由 agent 產出時這兩個假設各失效一半——判準可能與實作出自同一次推導，而讀完整份產出的成本高到多數人不會做。

失效的不是分層，是判準的來源與可信度。三層測試分層在這裡照舊成立——協議差異仍然要用真實服務驗、畫面狀態仍然要覆蓋；改變的是每一層的預期值從哪裡來，以及那個來源有沒有被實作污染。本模組處理的就是這一層。

這個模組的證據基礎

四章共用同一份實證錨：Robert C. Martin 的公開對照實驗 negative-test-experiment，同一份需求從空目錄寫八次、四種測試紀律乘上一個複雜度度量的開關。案例側的完整記錄在 T.C10。

它只有一個產品（一個主控台文字遊戲）、一種語言、每一格執行一次，設計與可讀性評分由原作者本人以主觀量表給出。這決定了它撐得起什麼：

四章的判準本身出自機制推導，實驗提供的是一次外顯的形態。逐項數字要當成示例讀，不要當成基準值。

右欄是量的未知，不是機制的未知——「這份實驗撐不起覆蓋率門檻在多大規模才失效」不等於「覆蓋率門檻在我的規模還有效」。拿右欄當有利推定時，要說得出憑什麼。

判定問題的答案要留下痕跡

本模組的判準大多以問句給出——這個交叉消費者觀察得到嗎、這條性質擋不擋得住某個具體的錯誤寫法、這個名字對得回哪個領域概念、這個功能有沒有「兩件事同時發生時該怎麼辦」。問句本身不產生產物，而認真問過與完全沒問，結論都可以是「不必補」，後者省力得多。

可執行的形式是把答案寫成一列：問了什麼、答案是什麼、依據是哪一條可指認的東西（需求文件的哪一段、可觀察面清單的哪一項、想得到的那個具體錯誤寫法）。判成不適用、判成暫緩時這一列必填——遵循會留下測試碼，豁免什麼都不留，所以舉證責任反過來壓在豁免那一側。

這是本模組把 #278 套用在自己身上的結果：那張卡說機械約束會被最便宜的路徑滿足，而本模組開出的判定問題就是這種約束——最便宜的滿足方式是心裡想一下然後判它不適用。

資源很少時先做哪一件

四章的作法成本差很多。這一節是授權的降級版本，所以進出都要留下痕跡：用它之前寫下哪一項前置不成立（沒有 CI、團隊人數、該語言沒有工具），用它之後訂一個回看的時點或訊號。少了這兩件，「資源很少」會變成不必再檢查的長期狀態。

前置成立時照這個順序取用：

1. 判準與實作分開產出——開兩個會話、寫測試那一次不餵程式碼。工具層的成本接近零，真正的成本落在需求描述必須自足；擋掉的是最大宗的那一類失效。
2. 維度表先攤前四個維度（狀態、事件、順序、邊界），這四個靠產品知識就推得出來。併發與失敗需要系統經驗，但不要整個跳過——需求已經明寫的（例如「付款失敗要回滾」）照補，其餘降級成「這個交叉發生時使用者該觀察到什麼」的陳述，實際的競態驗證留給整合層。
3. 性質式測試挑兩類：往返與冪等。這兩類最好認、也最常在小系統裡成立。
4. 突變測試整章暫緩。它的兩個硬前置（確定性套件、可用的語言工具）加上一個成本條件（CI 時間預算）通常一個都不成立，強行導入會卡在第零步。暫緩要記進模組的 backlog 並寫明是哪一個前置擋住——回補的訊號跟著那一項走（隔離清單清空、CI 時間預算鬆動、該語言出現生產可用的實作），沒有訊號的暫緩會變成永久豁免。

反過來說，人手充足而決定權不在自己手上時，順序完全不同——先看判準的推導來源那一章的三層主體表，確認要動的是哪一層。

本模組回應的案例

跨分類引用

• → LLM 模組四 Benchmarking 與評估：被測對象本身是模型、輸出不確定時的評估方法住在那裡；本模組處理的是 agent 產出的程式碼，兩者的判準形態不同
• → LLM 4.5 人機協作拓樸：那一章決定「人在什麼時機介入、怎麼介入」，本模組的「人審的位置要跟著移動」是同一個決策在驗證側的落點——自動判準的能力決定介入頻率，而判準能力正是本模組四章處理的對象
• → Backend 模組六 可靠性驗證：Release gate 與 fuzz campaign 是伺服器側的閘門設計，本模組的「品質閘門要成對設計」給的是挑選閘門的判準，兩者互補不重疊
• → 行為優先的 TDD：站內在古典派與倫敦學派分歧上的立場，本模組承接它留下的下一個問題——行為由誰決定
• → #277 通過關卡不等於通過的是同一個程式 與 #278 機械約束買到被量測的那個數字：本模組兩條主線抽出的可重用原則

本則是外部案例，來源為 Robert C. Martin 的公開實驗 repo negative-test-experiment。實驗的 policy、plan、八份逐行 notebook 與結論都在 repo 內可回溯；本頁的數字取自 2026 年 8 月的 experiment-conclusion.md（當時的 HEAD 為 faf9df0，2026-08-17）。該 repo 仍在演進——作者若補跑新一輪網格或改寫結論，本頁的列號式指認（列 1、列 4、列 5 這類）就會失聯而讀者無從察覺；repo 出現觸及 experiment-conclusion.md 的新 commit 時，要回頭核對站內所有引用該實驗數字的位置——rg "negative-test-experiment|331 到 603|97% 到 99%|85.81" content/ 是目前掃得到它們的方式。本頁是這些數字的來源，其他位置引用時應指回本頁。

觀察

實驗設計是一個 4 × 2 的網格。產品固定為 Greg Yob 的 Hunt the Wumpus，合規判準固定為一份 25 案例的主控台驗收腳本。變因一是測試紀律四選一：三法則 TDD、test-last（先寫完程式再補測試）、bundling（寫一個函式就測一個函式）、完全不寫測試；變因二是 CRAP 度量是否強制壓到低於 4。八行各自從空目錄寫起，禁止複製其他行的程式碼；每行寫完後封存該行的測試套件，再從空的用突變測試長出第二套。執行者是 AI agent，policy 檔通篇是防止抄近路的條款。

被放行的差異裡有三類不只是實作自由度：

危險判定順序。 原作的規則是先檢查 wumpus、再 pit、再 bats。八行裡有四行照做（列 3、6、7、8）；另外三行（列 1、4、5）的 notebook 逐行記載都是 bats、pit、wumpus；列 2 的 notebook 未記順序。實際存在的是兩種順序，而驗收案例從來沒有把兩個危險放進同一個房間，所以兩種都合法通過。

終止行為。 一行的主迴圈永不結束，一行的外層迴圈永不離開，一行以拋出並吞掉例外的方式結束。驗收腳本沒有斷言離開的方式。

亂數來源。 三種不同的產生器（平台內建、兩種不同係數的線性同餘），意味著 --seed 參數在八行之間不是可攜的契約——同一個種子在不同行產出不同的地圖。

判讀

1. 等價類的大小由條件之間的交叉密度決定，不由條件數量決定。 二十五條驗收案例讀起來像把功能講完了，實際上它們只約束了「每個危險單獨出現時的反應」。判定順序住在「兩個危險同時出現」這個交叉裡，而沒有任何一條條件走進那裡。這與三層測試分層談的盲區不同——那是層與層之間的縫，這是同一層內部維度沒有相乘。

2. 同一維度上加斷言，縮小等價類的幅度隨密度遞減；對沒有任何條件碰過的維度，增量是零。 八行的單元測試規模從零到 206 個範例，而驗收結果完全一致——判定順序住在「兩個危險同時出現」這個交叉裡，25 條驗收條件一條都沒有走進去。密度成長與涵蓋面成長是兩件事，而套件規模只反映前者。

3. 行覆蓋率在這個網格裡鑑別力很低。 test-last、bundling、三法則+CRAP 三者都停在 97% 到 99%，而它們的程式與套件組成完全不同。被覆蓋率區分出來的只有兩端：零測試那一行的 14% / 24%，以及三法則不開 CRAP 的 85.81%（作者標為 outlier，成因是主控台迴圈只被輕度驅動）。也就是說覆蓋率分得出「有沒有測試」與「有沒有一整塊沒被驅動」，分不出「測試好不好」。

4. 突變測試守得住斷言密度，守不住規格錯誤。 實驗記載的是突變長出來的第二套測試全部瞄準運算子層的翻轉、作者的結論是它「沒有發現一個不同的遊戲」。由此可以推出而實驗未直接測量的一件事：突變是對照著程式現在的樣子產生的，所以它不會對判定順序產生任何訊號——把 bats 排在前面的那份程式跑突變測試，長出來的斷言會把那個順序釘得更牢。這個限制在測試與實作出處不獨立時特別要緊，因為那正是規格層錯誤最容易產生的情境。

5. 自由度與未規定的需求要分開。 等價類大本身不是缺陷——命名、模組切法、內部資料結構本來就該留給實作。八行之間的檔案切法差異屬於這一類；判定順序與終止行為不屬於，它們是需求的一部分，只是沒有被寫進條件裡。

策略

從這則案例抽出的可重用修法在 #277（設計驗收條件時問哪些不同的程式會通過、交叉優先於單維度密度、把通過的產出當成樣本、指名誰接手了閱讀原本承擔的工作、區分自由度與未規定的需求），這裡不重述。

案例層特有的只有一條：把品質指標配對到它量不到的維度。覆蓋率門檻配突變測試，突變分數再配一次規格層的人工檢查——本則的八個版本正好示範了為什麼單一指標全綠不構成放寬下一層檢查的理由。

下一步路由

• 這則案例抽出的可重用原則 → #277 通過關卡不等於通過的是同一個程式
• 同一份實驗的另一軸（機械約束的代價）→ #278 機械約束買到被量測的那個數字
• 測試與實作同源時 oracle 為什麼退化 → Test Provenance
• 判準來源本身有哪幾種、各自抓得到什麼 → Test Oracle
• 由測試自己餵資料造成同型盲區的自有案例 → T.C5 凍結參照失效被 stub 遮蔽

概念位置

突變分數（被殺死的突變數除以有效突變數）是覆蓋率的替代指標——字面上的空斷言灌不高它，而錄製式斷言這類低思考量的路徑仍然可以，射程在品質閘門的更替。它跟 test oracle 的分工是：oracle 決定判準從哪來，突變分數量既有判準的密度。覆蓋率之所以長期被當成閘門，前提是「執行到了通常也就斷言了」——這個前提在斷言由人一行一行寫的年代大致成立，在斷言可以整批產生之後不再成立。用突變分數當閘門的理由是它無法用空斷言達成：要殺死突變，斷言必須真的檢查到那個行為。

它的成本結構跟其他測試層不同：每一個突變都要重跑一次相關測試，所以執行時間與突變數乘上測試時間成正比。壓低成本的三種手法，以及分數自己的至少四條便宜達成路徑（兩組互不對應），在品質閘門的更替那一章。

可觀察訊號與例子

覆蓋率維持在 90% 以上，而漏出去的 bug 落在有被覆蓋的程式碼裡——這組數字同時出現時，斷言多半只檢查到「有沒有跑完」，而突變分數會立刻把落差顯示出來。

存活的突變分成兩類，處理方式相反：真的漏洞要補斷言，等價突變（改寫之後行為完全相同）是工具的限制，要標記排除。為等價突變硬補的斷言會綁在實作寫法上，反過來傷害重構安全性。兩者判不開時的處置紀律（時間盒、預設歸類、排除清單覆核）在品質閘門的更替。

設計責任

引入的順序是先有可信的 oracle、再談突變分數。突變是對照著程式現在的樣子產生的，因此它守得住「斷言不夠密」，守不住「這段程式一開始就實作錯了需求」——把危險判定順序寫反的程式碼跑突變測試，長出來的斷言會把那個順序釘得更牢（機制推論，非實驗觀察）。這個限制在測試與實作出處不獨立時特別要緊，因為那正是規格層錯誤最容易發生的情境。

它也不會提出新的問題。突變生出來的斷言全部瞄準運算子與回傳值層級的翻轉，屬於 checking 的補完；產品有哪些情境值得驗證，仍然要由人設計。