• 菜雞行為：只設計正常路徑，把例外留給現實
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何把失敗矩陣轉成狀態、測試與恢復證據。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 11｜功能真正的任務，是失敗時仍能被理解和處理，把任務定成失敗可判斷、可處理、可恢復。本篇交代我做了什麼、改變了什麼。

我先把矩陣填完，才動第一行程式

粉鳥工單服務這個虛構案例接著做。我沒有先寫程式，而是把《失敗情境矩陣》填完：錯誤輸入、外部失敗、逾時、重複命令、背景失敗、取消與部分成功，逐格寫上觸發與期望行為。順序是刻意的：會留下爛資料的先做，純顯示問題最後。接著把 Day 11 的生命週期落進實作：工單多了可查詢的狀態欄位，失敗記下分類與原因，重試綁在狀態上，不藏在迴圈裡。

測試從一條綠燈變成一排失敗情境

再來才是測試。過去我只測成功建立；這次每格矩陣都對應至少一個測試：模擬通知逾時、同一命令重送兩次、背景中途失敗、執行中取消。每個測試驗證的不是「不會出錯」，而是「出錯後查得到狀態、允許的操作真的可用」。

這張表同時是測試與驗收清單，每列都連回一個風險。

結果是失敗變得可見，不是系統不再失敗

改完後，粉鳥工單服務照樣會失敗，差別在失敗不再靠考古：使用者看得到狀態與能做的事，值班查得到失敗分類。留下的證據是三份可重用檔案：填完的矩陣、生命週期表與這排測試。限制也要老實說：矩陣只涵蓋想得到的失敗，沒想到的仍會漏接；部分成功的補償有幾種仍靠人工；這整套對單步驟小功能是過度設計，明確的錯誤訊息就夠。

粉鳥工程筆記：讓每一種失敗都連回一個測試

矩陣先填完再決定順序；會留下爛資料的失敗優先；測試驗證狀態與操作，不是驗證不會出錯；證據要能交接，不能只在我腦裡。

今天可以帶走的練習

從失敗情境矩陣挑四項高風險情境，花半小時，用《測試案例表》寫成可重現的測試案例，含前置條件、輸入、預期結果與證據。產出四列表格，驗收方式是讀者能照表重現其中一項。風險低的小功能挑一兩項即可。

對應工具：《測試案例表》。

# 測試案例表

用途：把失敗情境連到需求、風險與可重現的證據。
使用時機：功能含背景工作、外部系統或部分成功風險時。
不必使用：失敗影響小、重做一次即可的功能。

| 類型 | 需求或風險 | 輸入 | 預期結果 | 證據 |
| --- | --- | --- | --- | --- |
| 失敗 | 通知逾時留下卡單 | 模擬逾時 | 狀態為失敗可重試 | 測試紀錄 |
| 邊界 | 命令重送造成重複 | 同命令送兩次 | 僅一張工單 | 工單編號 |

提醒：每列連回一個風險；不放機密、個資與可辨識人物。

下一篇

例外有了位置，測試也像真的了；下一種學生味換個戰場。Day 13｜我看不順眼的程式碼，就想整套重構。