閱讀退出之後，「那兩個同時發生怎麼辦」這句話沒有人會順口問了——它原本由讀程式碼的人隨手補上，現在要由條件的設計自己回答。

等價類可以被量出來

T.C10 把這件事實際量了一次。產品是 Hunt the Wumpus，一個主控台文字冒險遊戲：玩家在洞穴間移動、房間裡可能有怪物、陷阱或蝙蝠。同一份需求從空目錄寫八次，八個程式全部通過同一組 25 案例的驗收，八棵原始碼樹沒有任何兩棵相同，行數從 331 到 603。

被放行的差異裡，大部分屬於實作自由度——檔案怎麼切、函式怎麼命名、內部用什麼資料結構，這些本來就該留給實作。但有三類不是：

判定順序。 原規則是先檢查怪物、再陷阱、再蝙蝠。八個版本裡四個照做、三個反過來先檢查蝙蝠、一個的紀錄沒寫順序——兩種順序都通過，因為沒有任何一條驗收案例把兩個危險放進同一個房間。

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

亂數來源。 三種不同的產生器，意味著同一個 seed 參數在不同版本產出不同結果——--seed 沒有成為可攜的契約。

這三類都是需求的一部分，只是沒有被寫進條件裡。它們與實作自由度的差別在於：改變它們會改變使用者觀察得到的行為。

密度與涵蓋面是兩件事

同一維度上多加一條斷言，縮小等價類的幅度隨密度遞減；而對一個沒有任何條件碰過的維度，增量是零。 這條判準的操作含義是補到第十個邊界值的收益遠低於補第一條「兩件事同時發生」。

同一個實驗提供了它的外顯形態：八份程式的單元測試規模從零到 206 個範例，驗收結果卻完全一致——那 25 條驗收條件把每個危險單獨出現時的反應驗了很多遍，兩個危險同時出現一次都沒有，所以判定順序這個維度的增量始終是零。

它同時解釋了一種常見的挫折感——測試一直加、線上還是出事，而出的事「測試裡明明有類似的案例」。類似不等於交叉：同一個維度上的第十個案例，對另一個維度的貢獻仍然是零。

本章引用的量測數字全部來自同一份實驗，它撐得起與撐不起什麼寫在模組入口。

量射程的操作方式

把條件攤成維度表，看哪些維度組合沒有被任何一條條件同時碰到。維度自己要先推出來，推法是逐一問「這個系統的行為會隨著什麼而不同」——答案裡每一個獨立的自變數就是一個維度。

下面用一個具名流程走一次，讓推導的結果看得見：帳號權限異動（管理者調整某位使用者的角色，而該使用者可能正在使用系統）。

換一個流程，六個維度的內容全部要重填——這張表的欄位是問題，不是答案。前四個維度在任何有狀態的系統裡都推得出來；併發與失敗兩個維度值得單獨說一句：它們在驗收條件層能寫到的程度比其他四個低，因為驗收多半跑在單執行緒的腳本裡。可行的寫法是把它們降級成「這個交叉發生時使用者該觀察到什麼」的陳述（輸的那筆要收到明確拒絕、而不是靜默覆蓋），把實際的競態驗證留給整合層。

這張表自己有一個盲區，而且是本章方法論的遞歸：空格只存在於已經被列出的維度上，漏掉的維度連格子都沒有。 找空格證明不了維度列得夠，所以維度清單要有第二個來源——最便宜的是既有的事故與客訴紀錄：逐則問它落在哪個維度，落不進表上任何一格的就是漏掉的那一個。沒有事故史時退而求其次，把表拿給另一個熟悉這個領域、但沒有參與寫條件的人補一輪。

做法是逐條驗收條件標出它涵蓋哪個維度，再看維度兩兩相乘的格子裡哪些是空的——兩兩相乘是第一輪，更高維的交叉怎麼處理見下一節。空格不必全補——判斷依據是那個交叉發生時消費者觀察得到的行為會不會不同，會不同就是需求缺口。答「觀察不到」的人要指出那個差異落在可觀察面清單（API 契約、時序、資源使用、錯誤形態、分佈不變量）之外的哪一側；指不出來、或說不出從哪個介面觀察，就當成需求缺口補條件——誤補的代價是多一條條件，漏補的代價是那個維度永遠不會再被問起。

消費者不是人的時候這一問要換個問法。下游是程式（函式庫、SDK、資料管線、內部服務）時，可觀察面是 API 契約加上時序、資源使用與錯誤形態——「換一種資料結構」在延遲或記憶體屬於契約的一部分時就不是自由度。下游是統計性流程（模型訓練、報表聚合）時，單筆記錄的差異可能觀察不到而分佈的差異觀察得到，判準要換成分佈層的不變量（筆數、空值率、值域、欄位相關性），而不是逐筆的觀察。這一節的判準與上一段的預設是同一條：指不出可觀察的介面就補條件。處置的形態沿用等價突變的時間盒紀律——給判定一個時限，到了就落在有成本的那一側。

攤到幾維才停

兩兩相乘是起點不是終點。真實系統裡最貴的缺陷常常住在三維以上——年約 × 期末 × 付款失敗、登入中 × 降權 × 快取尚未失效，這類組合在二維表上一格都不會出現。而三維的組合數是二維的好幾倍，全補是不可能的。

停止的判準不是維數，是代價：

1. 把每一個空著的交叉標一個「它發生時消費者損失多少」——金額、資料正確性、無法回復的操作、對外承諾的違反，取那個系統自己的單位。
2. 由大到小排序，從頂端往下補。
3. 補到「再補一條的成本超過那個交叉的代價」為止，然後停。停下來的位置要寫下來——那是這組條件的射程宣告，不是遺漏。

這條判準對維數是中立的：某個三維交叉的代價比所有二維交叉都高時它排在最前面，而多數四維組合會自動落到門檻以下。實務上代價的估算不需要精確，只需要能排序——「這個會讓使用者被多收一期的錢」與「這個會讓錯誤訊息的措辭不一致」之間的差距，不必量化就分得出來。

代價估不出來的交叉另外處理：那通常代表這個情境的業務後果從來沒有人想過，而那件事本身比補一條條件更值得先解決。

這個盤點的副產物往往比測試本身有價值：空格代表需求文件對那個情境沒有交代，而沒有交代的地方通常是產品決策從來沒有被做過的地方。權限異動這個例子裡，「降權時那張 session 怎麼算」多半不在任何文件裡，而它決定了使用者會不會在操作到一半突然被踢掉。

補條件的順序

先補改變外部行為的交叉。 判定順序、狀態轉換的合法性、失敗發生在流程中段時的補償，這些交叉一旦錯了使用者會看見。

再補契約性的承諾。 這一類是「文件上寫了、而沒有任何一條條件在守」的承諾。付款端點宣稱重試安全，就要有一條條件用同一個冪等鍵送兩次並斷言只扣一次款；分頁 API 宣稱排序穩定，就要有一條條件在兩次查詢之間插入一筆資料並斷言既有頁次的內容不位移。T.C10 裡的 --seed 是同一類的最小形態——宣稱同樣輸入得到同樣輸出，而八個版本用了三種不同的亂數產生器，沒有一條條件發現。

終止與資源釋放要有自己的條件。 「跑得完」與「跑對」是兩件事，而多數驗收腳本只斷言後者。長時間執行的流程要斷言它會結束、結束時釋放了什麼。

最後才是同一維度上的密度。 邊界值列表有它的價值，但它排在交叉之後。

把通過的產出當成樣本

同一組條件會被重跑時（重寫、重構、換一個 agent 實作），要能說出這次的產出跟上次是不是同一類。做法是記下行為指紋而不只是「通過了」——原始碼的 checksum 是最粗的一種，更有用的是針對那幾個關鍵維度各跑一次探測（同房間兩個危險時觸發哪一個、同一個 seed 兩次執行結果是否相同、流程中斷後資料停在哪個狀態）。

指紋改變而條件仍然通過，就是等價類裡的移動；此時要問移動落在哪個維度、那個維度該不該被規定。這比「重跑一次看有沒有過」多帶回一個資訊：產出在條件的射程之外變了什麼。

邊界：等價類大是正常的

需求本來就只該約束外部行為，內部實作留給實作是設計上的正確選擇。等價類大本身不是缺陷，甚至是好的——條件把每一行程式碼都釘死的話，重構會變成不可能。

要區分的是集合裡的差異落在哪一側：換一個變數名、把三個函式併成一個是自由度；換一個判定順序、換一種終止方式、換一個亂數來源，是需求沒寫。「換一種資料結構」要看情況——延遲或記憶體用量屬於契約時它就不是自由度。判別的問題是這個差異消費者觀察不觀察得到，而消費者是誰、可觀察面包含哪些維度，要先照前面那一節的方式定下來。

判讀訊號

下一步路由

• 條件由誰寫、為什麼不能與實作同源 → 判準的推導來源
• 條件寫好之後怎麼量測試的偵測能力 → 品質閘門的更替
• 這個判準抽出的可重用原則 → #277 通過關卡不等於通過的是同一個程式
• 實際量出等價類的案例 → T.C10
• 條件下沉到協議層之後怎麼寫成契約 → HTTP contract test 設計

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

模組一到五處理的是驗證發生在哪一層、斷言怎麼寫、盲區在哪裡。那些判準本身與作者身分無關，但它們被使用的方式建立在兩個假設上：寫測試的人懂需求，而且有人會讀完程式碼。程式碼由 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 遮蔽