出處是這條軸最常見的代理，不是這條軸本身。 同一次生成的測試與實作幾乎一定共用推導，所以出處同源通常意味著判準被污染；但兩者不是同一件事，而它們分岔的位置恰好是本模組推薦的做法之一——同一個 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

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

三層退階的選用

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

不變量怎麼寫得有鑑別力

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

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

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

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

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

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

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

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

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

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

變形關係適用的位置

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

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

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

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

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

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

判準寫不下來的那一區

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

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

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

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

邊界

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

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

判讀訊號

下一步路由

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

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

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

概念位置

測試三層（unit / protocol integration / screen state）回答的是驗證發生在哪一層，oracle 回答的是憑什麼判定，兩者正交：同一層的兩個測試可以有完全不同的判準來源，而判準來源決定了紅燈的意義。

判準來源分兩層。第一層問預期值從哪裡取得，有四種取法；取不到答案時進第二層，改問預期值必須滿足什麼（不變量）或輸入變了輸出該怎麼變（變形關係）——那兩種是判準的替代形態而不是取得預期值的來源，退階的完整判準在判準寫不下來的時候。

第一層四種來源各自的覆蓋範圍：

可觀察訊號與例子

Oracle problem 指的是被測對象沒有可直接取得的預期輸出這個處境。典型場合是最佳化演算法（知道解合不合法、算不出最佳解該長什麼樣）、編譯器與轉譯器（輸出是另一份程式）、繪圖與版面計算（正確與否是視覺判斷），以及規格只存在於人腦裡而從未被寫下的功能。這些場合逐例斷言寫不出來，判準要換成不變量或變形關係。

另一種訊號來自紅燈的歧義：一個測試變紅時如果分不出「這代表行為改了」還是「這代表行為不對」，通常是同一個檔案裡混用了規格 oracle 與現狀 oracle。

設計責任

每個測試的作者要能指出預期值是從哪裡取得的。指不出來時最常見的實情是預期值取自實作的執行結果——先跑一次、把印出來的值貼進斷言，那是用實作驗證實作，不是驗證。這個退化在測試與實作由同一次生成產出時是預設會發生的事，判定方式見 test provenance。

Oracle 的可信度是測試套件的上限：斷言寫得再細密，也不會超過判準來源本身的正確性。這條上限也劃出了自動化的邊界——判準無法事先寫下的驗證工作屬於探究而非檢查。

代理會在兩個位置失準，記住它們就知道什麼時候不能只看出處：同源產出而判準是一條從需求來的不變量時，驗證力仍在；獨立產出而寫測試那一方被餵了 API schema 時，判準仍有一部分是推導來的。這跟 stub 那張卡描述的失效是同一個機制在不同層級的形態——stub 是餵資料的人同時寫斷言，出處問題是寫實作的人同時寫斷言。

概念位置

出處是 oracle 來源之外的第二個維度。同一個 oracle 類型可以有不同的出處：規格 oracle 由人寫規格、機器寫實作時獨立，由機器同時產出規格與實作時不獨立。測試三層（unit / protocol integration / screen state）對這個維度不作區分——分層決定驗證發生在哪，出處決定驗證是不是在照鏡子。

判準被污染的程度是連續的，不是有無：判準完全從實作推導時抓不到任何需求誤讀，判準有一部分從實作推導（例如生成器的參數、性質的前置條件抄自實作的守衛條件）時抓得到一部分。形態的分類、各自的射程、以及可動的四個變數在判準的推導來源那一章，卡片這裡不重複一套鍵不同的分類。

可觀察訊號與例子

最直接的訊號是順序：測試在實作之後由同一個來源補上時，它多半是照著實作的分支寫出來的，覆蓋率數字會很高而斷言貼著實作結構。另一個訊號是斷言的寫法——斷言重述實作的計算式（實作寫 a * 0.8、斷言也算 a * 0.8）：預期值是從實作推導來的，需求文件裡的那個數字從頭到尾沒被引用。

規格層的錯誤是這類測試的系統性盲區。危險處理順序寫反、狀態機少一個轉換、幣別換算方向顛倒——這些在實作與測試共用同一個誤解時全部通過，因為兩邊錯得一致。mutation testing 也發現不了它們，理由與突變的產生方式有關、在那張卡上。

設計責任

出處是可以被設計的，不是給定的：需求的來源、產出的順序、產出的主體、以及兩者之間的時間間隔，四者各自可動。四個變數的取捨、成本與操作方式在判準的推導來源那一章展開。

卡片層要記住的判準只有一條：四者都動不了時，這組測試的定位要降級成回歸網，並且在別處補上獨立的判準。

概念位置

不變量是比例子更難被實作污染的一種判準。逐例的預期值可以從實作跑一次抄回來，不變量抄不了——它必須從需求推導。這讓性質式測試在測試與實作出處不獨立的情況下保有較多驗證力，而生成器的存在也讓它涵蓋到人不會主動想到的輸入組合。

四類骨幹性質（另有上下界與順序無關兩類，連同適用條件與划算判準在判準寫不下來的時候）：

可觀察訊號與例子

同一個測試被複製貼上多次、只有輸入的數值不同：那組例子背後藏著一條沒被寫出來的性質，把它寫出來就是這類測試的起點。另一個訊號是邊界值列表越補越長：0、1、-1、最大值、空字串、單一元素，每次線上出問題就補一個，代表判準是靠回憶累積的。

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

設計責任

寫得出來的性質決定了這個測試的射程，所以性質太弱是主要的失效方式。「結果不會是 null」對所有實作都成立，包含錯的那些；把它收緊成「結果的長度等於輸入的長度且每個元素都來自輸入」才開始有鑑別力。判斷方式跟突變測試一致——問這條性質擋不擋得住某個具體的錯誤寫法。

生成器要跟著資料的真實形狀走。預設生成器產出的字串多半是短的隨機字元，而實際輸入可能有多位元組字元、前後空白與極長的內容；生成器沒有涵蓋的形狀，性質再強也驗不到，這與 test data 代表性是同一個問題。連性質都難以陳述時，判準要再退一層到變形關係。

概念位置

三種判準的要求由強到弱排成一條線：逐例斷言要知道每個輸入的正確輸出，不變量只要知道輸出必須滿足什麼，變形關係連這個都不需要、只要知道輸入變了輸出該怎麼變。變形關係因此是三者裡門檻最低、也是最後一道還寫得下來的判準。完整的退階表與選用程序在判準寫不下來的時候，來源分類見 test oracle。

它跟參照實作 oracle 的差別在於不需要第二份實作：變形關係比較的是同一份實作的兩次執行，因此在只有一個實作可用的場景（多數自研系統）仍然適用。

可觀察訊號與例子

「跑出來的結果對不對，沒有人說得準；但如果它變成那樣，就一定是錯的」——講得出這句話的時候就到了變形關係的位置。推薦排序、搜尋相關度、路徑規劃、稅務與費率試算、以及模型輸出的穩定性，都落在這一類——最終答案的正確性難以逐例判定，而輸入輕微改動後輸出翻轉是可以斷定的異常。

關係的方向要跟著業務語意選。搜尋條件收緊時結果集該縮小是子集關係；商品清單順序打亂時結果集該完全相同是置換不變關係；兩者同時成立，而各自抓的是不同的缺陷——前者抓過濾邏輯，後者抓對輸入順序的隱性依賴。

設計責任

變形關係要從需求推導，不是從實作觀察。從實作跑兩次看到某個對應成立就把它寫成斷言，等於把實作現在的行為當成規格，這與出處不獨立的失效是同一件事；正確的來源是業務語意上「本來就該如此」的那些對應。

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