出處是這條軸最常見的代理，不是這條軸本身。 同一次生成的測試與實作幾乎一定共用推導，所以出處同源通常意味著判準被污染；但兩者不是同一件事，而它們分岔的位置恰好是本模組推薦的做法之一——同一個 agent 同時產出實作與一條往返性質時，出處同源而判準來自需求，驗證力仍在。反過來也成立：兩個獨立會話，而寫測試那一側被餵了既有的 API schema，出處獨立而判準有一部分從實作推導。判定要問的是這條斷言的預期值從哪裡長出來，出處只是最好查的那個線索。這條性質在測試由人手寫的年代很少被單獨討論，因為寫測試的人與寫實作的人即使是同一位，中間也隔著一段時間與一次重新理解需求的動作；產出速度提高之後那段間隔消失了，獨立性變成需要主動維持的性質。

判準被污染的三種形態

判準被實作污染的形態由兩件事決定：寫實作與寫斷言的推理是不是同一段，以及寫斷言時手上有沒有實作可以照抄。兩者組合成四格，而第四格「不同推理、無可抄對象」是後面要談的做法（另一個來源先寫測試）、不是問題形態，所以不在這一節。以下三種按判準被污染的程度由重到輕排列。

同一次產出（同推理、無可抄對象）。 一個請求同時要求實作與測試，兩者由同一段推理產生。獨立性最低，因為需求的每一次誤讀都會被一致地寫進兩邊——這裡沒有可抄的實作，但也不需要抄，誤解在源頭就共用了。

實作完成後補測試（不同推理、有可抄對象）。 實作先存在，之後要求為它補一套測試。測試會照著實作的分支結構長出來，覆蓋率數字通常很高，而斷言的預期值多半是從實作推導的。推理雖然分了兩段，可抄的對象讓第二段推理沒有動力回到需求。

人讀完實作後補測試（不同推理、有可抄對象、但推理者換了）。 人讀過產出再寫測試，獨立性取決於讀的過程有沒有回到需求。讀完一份不熟悉的實作之後，腦中的「它該做什麼」已經被它實際做了什麼佔滿，寫出來的斷言常常是實作行為的複述。這一種比多數人以為的低，而它仍是三者中最高的——換了推理者本身就製造了一部分差異。

三種形態共通的訊號是斷言的寫法：斷言重述實作的計算式（實作寫 total * 0.8、斷言也算 total * 0.8）。預期值只要能從實作推導出來，這條斷言就沒有在驗證任何東西。

判準被污染時還抓得到什麼

同源不等於這組測試沒有價值，它的射程被限縮到特定幾類錯誤：

最後兩類正是 agent 產出最容易出錯的地方，也是同源測試的系統性盲區。單據合併後明細 id 全部重建（下游持有舊 id 的取消與追加操作從此無聲失效，而畫面看起來一切正常）、危險判定的先後順序、幣別換算的方向、狀態機少一條轉換——這些都是需求語意層的問題，在實作與測試共用同一個誤解時全部通過。

這個盲區不會因為測試變多而縮小。T.C10 裡八份程式的單元測試規模從零到 206 個範例，而 25 條驗收條件對危險判定順序一律沉默——規模成長沒有把任何一份帶進那個維度，因為斷言全部從同一份對需求的理解長出來。

本節的三種形態與四個變數出自機制推導；用來對照的實驗數字只有一份來源，模組入口交代了它支持與不支持哪些宣稱。

把判準移出實作的四個變數

獨立性可以被設計，能動的有四件事。前三件是本節展開的重點，第四件在開場已經出現過——時間間隔：寫實作與寫測試之間隔一段時間，中間發生一次重新理解需求的動作。它在人手寫的年代是免費附贈的，產出速度提高之後要刻意安排，而它也是四者裡最不可靠的一個（間隔不保證有人真的回去讀需求）。

需求的來源。 把驗收條件寫成一份人審過的文件，測試的預期值從那份文件逐條取得。這是四者裡效果最強的一個，因為它直接把 oracle 的來源移到實作之外。這份文件自己會漂移，而漂移的方向剛好抵銷它的作用——實作改了之後有人回來把它「對齊現況」，判準就在維護環節被實作污染了。所以它要跟程式碼同 repo、同一個 PR 送審，而且變更要由不是實作者的人核可；做不到這一點時，依同步期待要嘛有機制承接、要嘛明示降級把它降級成標記消費時點的記錄，不要繼續當它是最新的。成本落在那份文件必須寫到可以逐條對應成斷言的程度——寫成「訂單要正確處理」沒有用，要寫到「同一個房間裡同時有蝙蝠與陷阱時，先觸發哪一個」這種顆粒度。條件顆粒度的設計在驗收條件的等價類那章展開。

產出的順序。 測試先寫、實作後補，讓實作沒有可照抄的對象。這正是 Test-First 在 agent 產出情境下的新理由——它原本的理由是「小步好想、介面問題早暴露」，服務的是人的認知負荷；現在它多了一個結構性的理由，就是製造出處差異。順序帶來的獨立性有上限：先寫的測試如果也由同一個 agent 從同一段需求描述生成，誤讀仍然會一致地進入兩邊，順序只擋住了「照著實作寫斷言」這一種退化。

產出的主體。 測試與實作由不同的 agent、不同的會話、或不同的人產出，且寫測試的一方看不到實作。判準是寫測試那一側看不到實作；「開兩個獨立的會話、只餵需求不餵程式碼」是寫作當下達成它的方式，而不是判準本身——跨會話記憶或共用專案 context 會讓兩個會話不再等於隔離，用之前先確認手上的工具是哪一種，成本是需求描述必須自足——寫測試那一側沒有實作可以參照，需求裡漏掉的部分就會直接變成測試的缺口。這個成本本身是有用的訊號，但它有一個判不開的地方：寫不出測試也可能是那一方缺領域上下文或經驗不足，同一個觀察對應得到兩個原因。要分開只有一種做法——同一份需求給兩個獨立的測試方，兩方卡在同一處才是需求的問題。

主體這條線往上還有兩層，而本模組其餘部分預設它們不存在。 「產出的主體」講的是 agent 與會話，那是最裡面那一層；外面還有組織層與契約層：

三層的判準相同（判準是不是由實作推導），可動的手段不同。本模組後面三章的修法都寫在產出層——決定權、滿足義務、後果承擔屬於同一方是它們共同的前提。這個前提不成立時，先確認是哪一層的主體不同，再看那一層有沒有可動的變數；契約層通常沒有可動的變數，此時要動的是合約或控制程序本身，那超出本模組的射程——但不代表沒有事情可做：外部門檻照舊守著、內部指標另外疊加上去，那條原則在品質閘門的更替的導入順序段。

四者可以疊加，也可以只動一件——但只動一件時要知道拿回了多少：動「需求的來源」把判準整個移出實作，語意層的盲區關得起來；只動順序或時間間隔只擋掉「照著實作寫斷言」這一種退化，共用誤讀那一種仍在，此時定位仍然是回歸網。都動不了的情況下，這組測試的定位要誠實降級成回歸網——它守得住「後來改壞了」，守不住「一開始就寫錯了」——並且在別處補上獨立的判準。

人審的位置要跟著移動

逐行讀 agent 寫的實作，讀的人已經被實作的敘事引導：變數命名、註解、結構都在說服讀者這段程式做的就是它該做的事，而讀者手上沒有一份獨立的對照。這種閱讀能發現的多半是風格與局部缺陷，發現不了「整段做的是另一件事」。

同樣的注意力放在驗收條件上，審的是需求本身，而在需求、驗收條件、實作、測試這條鏈上，驗收條件是少數還沒有被實作污染的環節之一。這也是判斷「不再逐行讀產出」這個決定是否成立的方式：說得出哪一個環節接手了原本由閱讀承擔的那件事，這個決定就成立；說不出來時，交換掉的是驗證的可見性而不是閱讀的時間。

邊界：判準取自實作也合理的場合

一次性的探索腳本、用完就丟的資料轉換（「用完就丟」是對未來的預測，要說得出丟棄的時點或條件，說不出來的多半不會被丟）、以及characterization test 這種本來就以現狀為判準的測試，同源不構成問題——前兩者的錯誤代價低到不值得建立獨立判準，後者的設計意圖就是複製現狀。

重構是另一種邊界，而且它的正確配置不在本節四個變數裡：重構的 oracle 是改動前的行為而不是需求文件，所以「把驗收條件寫成人審過的文件」在這裡等於重建二十年的規格。可行的配置是拿舊實作當參照 oracle（新舊並行跑、比對輸出），配上行為快照守住尚未被正確性測試覆蓋的部分。

另一個邊界是需求本身沒有語意深度的功能：CRUD 端點的欄位對映、單純的格式轉換，誤讀的空間小，同源測試的盲區也隨之縮小。判斷方式是問這個功能有沒有「兩件事同時發生時該怎麼辦」這類問題，沒有的話同源的風險確實低。

判讀訊號

下一步路由

• 驗收條件要寫到什麼顆粒度才擋得住語意層錯誤 → 驗收條件的等價類
• 有了獨立判準之後怎麼量測試的偵測能力 → 品質閘門的更替
• 這條性質的術語卡 → Test Provenance
• 由測試自己餵資料造成的同型盲區 → Stub 與 T.C5
• 站內在測試耦合對象上的立場 → 行為優先的 TDD

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

等價類可以被量出來

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 設計

這個假設從來沒有完全成立。站內的 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 產出的情境下比過去更常用到，原因有兩個：產出的規模讓逐例斷言的撰寫速度成為瓶頸，而逐例的預期值又是最容易被實作污染的一種——跑一次實作就能把答案抄進斷言。不變量與變形關係比較不容易被抄：它們沒有現成的形態可以複製，要從實作反推得先看出一條性質，那是一個刻意的動作而非順手的動作。這是機率的差別不是構造上的不可能——從實作觀察出一條對應再寫成斷言仍然辦得到，而那正是本章末段要處理的失效模式。

三層退階的選用

選幾層看兩件事——答案算不算得出來決定上界（算得出來就從逐例開始），錯了的代價決定下界（代價高、或這段邏輯會被重試與併發碰到，就一路補到變形關係）。選用不是三選一，同一個功能常常三層都有：折扣計算的幾個關鍵金額用逐例斷言釘死，「折扣後金額不超過原價且不小於零」是不變量，「數量加倍時折扣後總額不會少於原本」是變形關係。三者各自抓不同的錯，而後兩者在需求被誤讀時仍然會變紅。

不變量怎麼寫得有鑑別力

性質太弱是這類測試主要的失效方式。「結果不會是 null」對所有實作都成立，包含錯的那些。判斷方式與突變測試一致——問這條性質擋不擋得住某個具體的錯誤寫法。「想出一個具體的錯誤寫法」這一步交不出去，可執行的只有「想不出來就代表性質太弱」那半句。

下面六類在業務系統裡最常成立，前四類是骨幹、後兩類補上骨幹漏掉的形態。用法是逐類問「這個功能上它成不成立」、不成立寫一句理由——挑兩三類寫完就收工是最省力的走法，而模組的核心論證（涵蓋面不等於密度）在這裡同樣適用：六類裡沒被問過的那幾類，增量是零。

往返。 編碼後解碼得回原值。適用於序列化、加解密、格式轉換、匯出匯入。這一類的鑑別力來自它同時約束兩個方向，單邊寫錯就會被抓到。

守恆。 操作前後某個量不變或單調變化。轉帳前後總額相同、合併訂單後品項總數不變、分頁遍歷完的元素數等於總筆數。這一類特別適合抓「資料在某條路徑上被吃掉」的缺陷，而那類缺陷逐例斷言很難覆蓋到。

對照。 與一份簡單但慢的參照實作結果相同。最佳化過的演算法是最直接的用法，而業務系統裡更常見的是另外兩種：費率或稅務試算拿還在跑的舊系統當參照（遷移期間免費附贈一份參照實作），報表聚合拿一句直白的 SQL 對照程式裡那套分批累加的邏輯。划不划算看一件事——寫那份參照實作要花多久：邏輯本身十行內寫得完就值得，要重建一套領域模型才寫得出來就不值得，那時改用守恆性質。

冪等。 執行兩次與執行一次結果相同。適用於正規化、去重、部署腳本、以及所有會被重試的操作。這一類在有重試機制的系統裡是必須的，而它幾乎不會出現在逐例測試裡。

上下界。 輸出永遠落在某個範圍內——折扣後的金額不超過原價也不小於零、庫存不會是負數、百分比不超過一百。最容易寫、鑑別力也最低，但它抓的那一類缺陷（溢位、正負號、單位換算）逐例測試常常整批漏掉。

順序無關。 打亂輸入的順序，結果應該相同。分散式與批次處理裡最要緊的一類——訊息亂序抵達、分區處理順序不固定、平行聚合的合併次序，這些在單執行緒的逐例測試裡永遠不會出現。

生成器要跟著資料的真實形狀走，而「真實形狀」要靠量測取得。可執行的取法是從正式環境的資料抽一份樣本（拿不到正式資料時——新系統、或沒有存取權——退而求其次去量既有的錯誤日誌與客訴紀錄，那裡的輸入形狀最接近真實的極端），對每個欄位量四件事——長度分佈的極值與中位數、字元集（有沒有多位元組、控制字元、前後空白）、空值與缺欄的實際比例、以及重複值的集中度——再把這四項餵回生成器的參數。預設生成器產出的字串多半是短的隨機 ASCII，量過就會知道它離真實有多遠。生成器沒有涵蓋的形狀，性質再強也驗不到，這與Test data 代表性是同一個問題。

失敗時框架回報的最短反例是產出本身——它通常直接就是缺陷的最小重現案例，可以原樣固定成一個逐例測試，讓這次的具體失敗有穩定的回歸點。

變形關係適用的位置

適用訊號是「跑出來的結果對不對沒有人說得準，但如果它變成這樣就一定錯了」。推薦排序、搜尋相關度、路徑規劃、費率與稅務試算、以及任何輸出帶有不確定性的元件，都落在這一類。

關係的方向要從業務語意選，不同的關係抓不同的缺陷：

• 搜尋條件收緊時結果集應該是原本的子集——抓過濾邏輯
• 輸入清單順序打亂時結果集應該完全相同——抓對輸入順序的隱性依賴
• 所有價格同乘一個係數時總價同比例變化——抓計算裡漏掉的加項

關係要從需求推導而不是從實作觀察。跑兩次看到某個對應成立就把它寫成斷言，等於把實作現在的行為當成規格，那是出處污染的另一種形態。

歸因需要額外一步：逐例斷言變紅指向一個具體的輸出值，變形關係變紅只說明兩次執行的關係不對，缺陷可能在任一次執行裡。縮小範圍的做法是把複合關係拆成單步關係，讓每次只改變一個輸入維度。

退階的三層判準由機制推導，不依賴實驗；引用到的數字與其他三章同源，射程見模組入口。

判準寫不下來的那一區

三層退階之後仍然有寫不下來的部分。錯誤訊息會不會讓使用者以為是自己打錯、這個流程走到一半被打斷時使用者知不知道發生什麼事、這份報表的數字對不對得起業務直覺——這些的判準在觀察到當下才成形。

這一區與可自動化的部分之間有一條明確的分界：判準在執行之前寫得下來的屬於檢查，可以交給機器重複執行；判準要在觀察當下才成形的屬於探究，交不出去。同一個功能通常兩側都有——登入失敗三次鎖定帳號是檢查，鎖定之後的求助路徑通不通要有人真的走一次。

資源分配要跟著改的第一件事，是不再拿套件規模當思考量的代理指標——兩者為什麼脫鉤，testing vs checking 那張卡有完整的推導。

實際的分配方式是把省下來的人力移到檢查產生不了的地方：判準本身的設計、驗收條件的維度盤點、以及那些沒有被任何斷言涵蓋的問題。把省下來的時間拿去逐行讀機器寫的斷言，等於把人放回機器已經做得比較好的那一側。

邊界

不變量與變形關係不取代逐例斷言。關鍵的具體數值仍然需要被釘死——稅率、額度上限、狀態碼的對應，這些用性質表達會失去精度，而它們正是最常被改壞的那些值。

另一個邊界是成本：性質式測試的每次執行都跑數十到數百個案例，放進每次提交的回饋迴圈會拖慢節奏。常見的配置是提交時跑固定的少量案例、夜間排程跑完整的隨機探索，並把探索找到的反例固定成逐例測試回到快速迴圈裡。

判讀訊號

下一步路由

• 判準為什麼要獨立於實作 → 判準的推導來源
• 判準的顆粒度怎麼定 → 驗收條件的等價類
• 判準品質怎麼量 → 品質閘門的更替
• 術語卡 → Test Oracle、Property-Based Testing、Metamorphic Testing、Testing vs Checking
• 被測對象本身是模型、輸出不確定時的評估 → LLM Benchmarking 與評估