分支劇情怎麼測試：狀態矩陣、路徑覆蓋與迴歸測試完整範本

分支劇情不能靠「把每條路線玩一遍」完成測試。路徑會迅速增長，許多缺陷來自狀態組合。更可靠的方法是先驗證狀態轉移，再用風險優先的路徑覆蓋關鍵組合，最後把每次缺陷轉成迴歸測試案例。

刪除沒有讀取點的變數，補齊沒有來源的讀取條件。

每條測試案例記錄起始節點、前置狀態、操作、預期下一節點、狀態變化和截圖或日誌。限時選擇還要測逾時、邊界輸入與重複點擊；媒體節點要測載入失敗和復原。

優先覆蓋兩個變數的關鍵組合，例如關係高低與是否持有鑰匙、QTE 成敗與是否掌握線索。它不能取代高風險全組合，但能以較低成本發現常見條件錯誤。

預設主線、每個結局的最短路線、最低資源路線、全 QTE 失敗路線、存檔／章節復原路線，以及歷史嚴重缺陷的迴歸路線。

版本／平台：
起始節點與前置狀態：
重現步驟：
實際／預期結果：
發生頻率：
截圖或日誌：

發布前至少確保所有嚴重缺陷結案、每個結局可重現兩次、存檔升級和章節跳轉已驗證，並明確說明尚未覆蓋的組合風險。

只拿故事圖測試，會知道玩家從 A 到了 B，卻不知道哪些變數被寫入。狀態字典為變數定義型別、預設值、合法範圍、寫入與讀取節點。任何變數改名或範圍變化，都要同步更新測試案例。

關係值尤其容易失控。不要只寫「信任增加」，應寫從多少到多少、是否有上限、哪些場景讀取，以及介面如何回饋。若結局條件是 trust > 3，邊界值 3 和 4 都必須測試。

正常選擇之外，還要測試重複點擊、倒數計時邊界輸入、斷網、切到背景、媒體載入失敗、快速跳過、切換語言與還原存檔。常見缺陷不是故事寫錯，而是狀態在異常操作後被重複寫入或完全漏寫。

每條測試案例從可重現的存檔開始。只寫「進入第三章點擊左邊」不足以重現，因為第三章可能繼承不同關係和道具。

P0 覆蓋主線、全部結局、存檔損壞和內容安全；P1 覆蓋重要關係、道具、QTE 與章節跳轉；P2 覆蓋局部對白和低風險視覺差異。每次提交執行節點測試與 P0 冒煙測試，候選版本再執行 P1/P2。

覆蓋率不要只報走過多少節點。同時報告狀態轉移、結局條件、異常復原和未測組合。一個節點被造訪過，不代表它的全部條件正確。

每修復一個問題，就把原始前置狀態和操作加入迴歸測試集合。若問題來自章節跳轉預設值，今後的所有版本都要驗證這個場景，否則同類錯誤會在重構後重新出現。

例如玩家在 N05 獲得鑰匙，跳到 N08 後系統卻使用預設值 has_key=false。記錄應包含完整流程與跳轉流程對照、存檔版本和日誌；修復後分別驗證新存檔、舊存檔與章節重開。

報告列出通過的結局、關鍵路徑、阻斷缺陷、剩餘風險和版本。不要用「全流程已測」這種不可稽核的表述。目標不是宣稱沒有 bug，而是讓決策者知道哪些因果已驗證、哪些組合仍未知。

主線首次通關、付費入口、不可逆選擇和最終結局列為最高風險，每次建置都執行；常見支線和主要匯流點按日迴歸；罕見組合可按版本輪替。優先順序由使用者影響、發生機率、修復成本和歷史缺陷共同決定，不能只測試最容易自動化的路線。

每條測試案例寫清初始存檔、操作步驟、預期狀態、可見結果和清理方式。失敗時保存建置編號、節點、狀態快照、截圖或錄影及最短重現路徑。若只能描述「偶爾跳錯結局」，開發者很難定位是條件計算、存檔遷移還是媒體載入問題。

新增狀態、重新命名節點或調整預設值時，用發布版舊存檔進入新建置，檢查缺失欄位如何補齊、已解鎖內容是否保留、回復舊存檔是否跳過關鍵遷移。全新存檔通過並不代表升級安全。無法相容時應提前說明影響並提供可理解的處理方案。

驗收會議只處理有證據的結果：哪些路徑已執行、覆蓋了哪些狀態邊界、剩餘缺口為何可以接受。把未覆蓋區域明確列出，比用一個籠統通過率製造安全感更有價值。