T.C7 症狀相同、成因兩種 — 用測試切開前後端責任

2026-07-17

同一個症狀、兩種可能成因，光看畫面無法歸因：可能是後端沒釋放資源，也可能是後端釋放了但前端沒刷新。這個案例示範「前後端責任切分」如何用測試完成，取代猜測與互相指責。關鍵認知：同一個症狀往往有多種成因，而其中一種在自己身上。

觀察

前端與後端的契約是：刪除一張單據時，後端一併釋放該單據佔用的資源狀態（例如場地、座位這類由後端控管的佔用旗標）。使用者回報：刪除後，資源在畫面上仍顯示為佔用中。

初步懷疑指向後端違約。但讀前端程式時發現：刪除編排在成功後沒有任何一次資源狀態的刷新——也就是說，即使後端照契約釋放了，畫面也會殘留舊的「佔用中」，症狀與後端沒釋放完全無法區分。

階段	做法	結果
切分責任	假後端（行為可控的模擬後端）加開關：模擬「會釋放」與「不會釋放」兩種行為，前端刪除編排在兩種行為下各寫一條流程測試	「會釋放」那條紅燈——逼出前端缺刷新的問題，先修
定案成因	真實後端驗證測試：刪除後直接讀後端的資源狀態（即刻＋延遲各一次，容許非同步）	綠燈——後端有同步釋放
結論	是前端 bug（漏刷新），不是後端違約	撤銷回報、修復已被既有測試鎖住

「畫面顯示的」不等於「後端狀態」。前端畫面是「上次同步的後端狀態」的快取；任何會改變後端狀態的操作，若後續沒有同步，畫面就殘留舊值。這類 bug 的歸因第一步是：繞過畫面，直接讀後端。
兩種行為都寫測試，而不是先賭一邊。假後端的開關讓「後端會釋放」與「不會釋放」兩個世界都存在；前端編排在兩個世界裡的正確行為不同（前者要畫面還原、後者要誠實顯示佔用）。分開鎖定後，無論真實後端是哪種，前端這半的責任都已被測試涵蓋。
真實後端測試把「歸因」變成一次執行。紅＝後端違約（測試本身成為修復的驗收標準）、綠＝前端問題。不需要會議、不需要來回猜測——而且這次的結果與最初的懷疑相反，正說明沒有證據的歸因有多不可靠。
延遲重讀是必要的容錯。後端可能非同步釋放（即刻讀還是佔用、幾秒後才釋放）；驗證測試即刻與延遲各讀一次，把「同步釋放／非同步釋放／未釋放」三種結果區分開，各自對應不同的前端處置。

歸因順序：直接讀後端狀態 → 確認後端行為 → 再回頭檢查前端的同步時機。跳過第一步的歸因都是猜測。
「改變後端狀態的操作」在前端編排的收尾必須有對應的同步。這條規則可以巡檢：列出所有會改變資源狀態的操作，逐一檢查操作後有沒有刷新。
定案後收斂測試：真實行為確定後，把假後端的開關定死、移除錯誤行為那條測試分支——錯誤行為分支違反假後端「只固化已證實行為」的定位，後端未來變壞由配對的真實後端驗證測試接手。雙行為測試是歸因期的工具，不是永久資產。