功能測試實戰：用狀態、契約與風險把關

功能測試實戰：用狀態、契約與風險把關
別測畫面，測行為。有效的功能測試，把資料、狀態、契約放在一線。
一個可以避免的靜默事故
我輔導的金融團隊，使用者在結帳改幣別後，部分退款偶爾消失。UI 測試全過，日誌正常。根因是狀態機少了一條轉移。用 State transition testing 畫出允許的變化與禁止跳躍，一天內就定位缺陷。
關鍵模式：契約、狀態、神諭
– 契約優先：先在服務邊界鎖定輸入/輸出，再談 UI；提早攔截介面漂移。
– 建立狀態模型：列舉有效狀態與轉移；用 State transition testing 覆蓋非法與邊界跳轉。
– 咬人的神諭：以商業規則當判定（費率、進位、權限），而非截圖像素。
– 真實資料集：帶入時區、在地化、大金額、冪等鍵等邊界資料。
– 風險熱區：把力氣放在資金流、資料變更、配額節流處。
本週可落地清單
1) 為最高風險流程（登入、結帳）畫狀態圖。
2) 為兩個關鍵 API 寫契約測試。
3) 對用戶在意的規則加神諭（例：退款精確到分）。
4) 跑三個負向轉移與一條長用戶路徑。
5) 以「狀態」而非「頁面」分類缺陷。
把 [内链：登录流程设计]、[内链：测试用例管理]、[内链：回归测试策略] 佈在對應內容節點。當你的系統模型比 UI 更清晰，功能測試就會更銳利。