在軟體測試的領域中，我們經常面臨一個靈魂拷問：「你今天到底測了什麼？」

對於探索性測試（Exploratory Testing）的實踐者來說，這個問題尤為棘手。我們不像傳統測試那樣死守著 Excel 表格裡的幾千條測試案例（Test Cases），我們更靈活、更依賴直覺與技術深度。

但靈活不代表混亂。為了讓探索性測試具備可追溯性與管理價值，「基於會話的測試管理（Session-Based Test Management, SBTM）」應運而生。

而 SBTM 的靈魂，就在於一份強大的「測試會話匯報檢查清單（Test Session Debrief Checklist）」。

這篇文章將深入剖析這份清單的每一個環節，教您如何將模糊的測試過程，轉化為數據清晰、故事完整的專業報告。這份清單將測試報告拆解為六個關鍵維度。我們將逐一解析，並告訴您如何在實務中應用。

1. 章程 (Charter)

「章程必須總結本次測試會話的實際任務。」

很多測試人員會犯一個錯誤：測試開始前寫好了章程（例如：「測試登入功能」），但在測試過程中發現了資料庫崩潰的問題，於是花了兩小時在修復資料庫，最後報告裡的章程還是寫著「測試登入功能」。

這份清單告訴我們：誠實修正你的章程。

(1) 實務檢核點

• 文字與行動是否一致？ 您報告上的章程描述，是否真的符合您剛剛那段時間所做的「大部分」工作？如果不符，請修改章程文字。
• 任務完成了嗎？如果原本預定的任務沒做完，您有兩個選擇：記錄下哪些沒做，或者修改章程以反映實際完成的工作。
• 關聯性：如果這是一個被重複使用的章程（例如回歸測試），您能否說明這次的測試與上次有何不同？

(2) 舉例說明：

假設原本的任務是「驗證購物車結帳流程」。但在測試第一步時，您發現商品無法加入購物車，導致您花了 90分鐘在分析 API 的錯誤回應。

錯誤的做法：提交報告說「驗證購物車結帳流程」，然後結果是 Failed。

正確的做法：將章程修改為「調查購物車 API 回應錯誤」，因為這才是您實際做的事情。這樣管理者才能知道時間花去哪了。

2. 基本資料 (Basic Data)

別小看這些行政標籤，它們是日後 debug 的救命稻草。清單強調報告模板必須被妥善填寫。

實務檢核點：

• 誰參與了？除了您自己，是否有開發人員或 PM 花了大量時間協助您？把他們的名字加上去。
• 環境與版本：這是最基本的。三個月後當有人問起「這個 Bug 是在哪個環境測出來的？」您會感謝自己當時記錄了測試環境與產品版本。
• 策略與區域標籤：為了避免重複計算，如果您標記了某個產品區域（例如：「會員中心」），請確保您至少有一半的時間是真的在測那個區域。

3. 時間運用 (Use of Time)

這部分是 SBTM 最具爭議但也最有價值的地方。我們需要知道時間都去哪了，但不是為了監視，而是為了優化流程。

清單建議將時間拆分為三類，並且要求排除干擾時間（例如中斷去喝咖啡或開會的時間不計入）。

A. 測試執行 (Test Execution)：
這部分的時間，只能算在那些「合理預期能發現錯誤（Bug）」的工作上。這是您真正與軟體互動、尋找漏洞的時間。

B. 錯誤調查 (Bug Investigation)：
這僅包含因為調查 Bug 或撰寫 Bug 報告而打斷了測試執行的時間。

如果您一邊測一邊隨手記個小 Bug，那不算調查。這裡指的是您必須停下來，去查 Log、去重現步驟的那種深度調查。

C. 設置與管理 (Setup/Admin)：
這是指為了測試會話而做，但打斷了執行或調查的時間。例如架設測試伺服器、閱讀規格書、填寫報告本身。

舉例說明，一個 120 分鐘的會話：

花了 30 分鐘架設環境（Setup: 25%）
測了 10 分鐘就發現一個大 Bug，然後花了 40 分鐘定位問題並寫報告（Bug Investigation: 33%）
剩下 40 分鐘繼續測試其他功能（Test Execution: 33%）

這樣的數據能讓管理者一眼看出：「喔，我們的環境架設太花時間了，是否該自動化？」

4. 測試數據與產出 (Test Data and Output)

測試不僅僅是「點一點」而已，過程中產生的資產必須被保存。

實務檢核點：

• 您是否產生了特定的測試數據（例如一批特定的使用者帳號），未來可能還會用到？
• 是否有更新測試文件或程式碼？
• 螢幕截圖：是否擷取了關鍵畫面，並將其與測試筆記放在一起？

5. 測試筆記 (Test Notes)

這是報告的核心靈魂。一份好的測試筆記，不僅要記錄結果，還要講述「過程」。

(1) 三個月法則：
問自己一個問題：「三個月後的我，還看得懂這些筆記嗎？」 如果答案是否定的，請重寫。

(2) 三大要素 (Coverage, Oracles, Activity)：
為了講好這個故事，您的筆記必須回答「在這個會話中發生了什麼事？」，並包含：

• 覆蓋範圍 (Coverage)：我測了哪些部分？
• 預言/判斷準則 (Oracles)：我憑什麼判斷這是對的或是錯的？（是依據規格書？還是依據舊版行為？）
• 活動 (Activity)：我具體做了什麼動作？（例如：輸入了 SQL 注入字串、斷開了網路連線等）。

(3) 知識轉移：
筆記中有沒有什麼發現，是應該被更新到更長期的文檔（如產品覆蓋率大綱）中的？不要讓知識停留在一次性的報告裡。

(4) 寫作技巧：

• 差勁的筆記： 「測試了搜尋功能，沒問題。」
• 優秀的筆記： 「針對搜尋列進行邊界測試（Activity）。輸入了 256 個字元與特殊符號。依據 UI 規範（Oracle），系統應顯示錯誤訊息，但實際上卻崩潰了。覆蓋了英文與中文搜尋（Coverage）。」

6. 錯誤與議題 (Bugs and Issues)：區分「產品」與「流程」

這是這份清單最獨特的洞察之一。它要求我們區分Bugs 和Issues。

• Bugs (缺陷)：產品本身的問題。記得加上標題和正式報告連結。
• Issues (議題)：影響您測試能力的事物。

這非常重要！如果 API 文件過期了、測試環境一直斷線、或者規格書寫得不清不楚，這些都是「議題」。

「如果沒有列出Issues (議題)，這是否意味著測試過程中沒有困惑、沒有遺留問題，且測試路徑上沒有任何障礙？」

通常情況下，完全沒有議題的測試是非常罕見的。如果您總是寫「無議題」，可能代表您對環境的容忍度太高，或者沒有意識到阻礙的存在。

7. 整體評估 (Overall)：測試經理的視角

在報告的最後，請跳出細節，用宏觀的角度審視這次會話。

• 忠實呈現：這份報告是否誠實地反映了剛剛發生的事情？不需要完美，但必須真實。
• 下一步行動：
   需要追加會話嗎？這次的發現是否引發了更多疑問，需要另開一個 Session 來深入？
   需要延長或修訂嗎？還是目前的會話應該被標記為未完成，需要補時？
• 「這是否是太多的文書工作？有沒有更簡單的方式來講述測試故事？」 這提醒我們，SBTM 的目的是管理，而不是製造官僚主義。如果報告本身成了負擔，就該簡化它。

許多測試工程師的痛苦在於「做得多，但說不出價值」。透過這份清單，可以得到以下反思：

• 時間分析證明了您不僅在測試，還在處理環境與調查問題。
• 章程修正證明了您具備動態調整策略的能力。
• 議題報告證明了您關注的不僅是 Code，還有整個開發流程的健康度。

下次進行測試匯報時，試著拿出這份清單，檢查您的報告是否具備了這些要素。您會發現，原本枯燥的 Bug 列表，將變成一份充滿洞察力的產品健康診斷書。

根據上面檢查清單的格式，以台灣高鐵訂票系統為背景，撰寫 3 個測試會話匯報（Session Reports）範例給大家看看。

範例一：新功能探索與邊界測試
這個範例展示了當測試過程順利，且重點放在「覆蓋範圍」與「判斷準則」時的報告樣子。

測試會話匯報 #001

章程 (Charter)： 探索「一般對號座」行動裝置購票流程，特別針對「信用卡優惠連動」與「取票方式選擇」的邏輯驗證。

基本資料：
* 測試人員： 老查 (Instructor)
* 環境/版本： iOS App v5.4.0 / Staging 環境
* 區域標籤： 訂票流程 / 支付模組

時間運用：
* 測試執行 (Execution)： 80% (全程專注於不同卡號與優惠方案切換)
* 錯誤調查 (Bug Investigation)： 10% (確認一筆優惠折抵金額計算錯誤)
* 設置與管理 (Setup/Admin)： 10% (準備 5 組不同銀行信用卡號)

測試筆記：
* 覆蓋範圍 (Coverage)： 單程票、去回票；全票、孩童優待票；商務車廂與標準車廂。
* 活動 (Activity)： 輸入符合升等資格的信用卡號，並在最後支付頁面反覆切換「立即支付」與「稍後支付」。
* 預言/判斷準則 (Oracles)： 依據《2026 銀行信用卡合作規範》。當輸入特定卡號時，應自動彈出「商務車廂升等」選項，且總金額應正確扣除點數折抵。

錯誤與議題：
* Bugs： [Bug #102] 當選擇「去回票」且僅去程符合升等時，支付頁面未正確拆分金額。
* Issues： 無。測試環境銀行 API 回應速度極快，過程流暢。

整體評估： 任務已完成。建議下次 Session 針對「外籍旅客護照訂票」進行專門測試。

範例二：遇到嚴重阻礙時的動態調整
這個範例展示了當「章程」與實際行動不符時，如何誠實修正報告。

測試會話匯報 #002

章程 (Charter)： (原訂) 驗證高鐵早鳥票自動配位邏輯。 -> (實際修正) 調查訂票系統與資料庫連線逾時問題。

基本資料：
* 測試人員： 小敏、開發者 阿良
* 環境/版本： Web 2.0 / 開發測試環境 (Dev-DB-02)
* 區域標籤： 系統基礎架構 / 資料庫

時間運用：
* 測試執行 (Execution)： 20% (僅點擊三筆購票即遇到連線中斷)
* 錯誤調查 (Bug Investigation)： 70% (與開發者協同查看 ELK Log，確認 SQL 死結問題)
* 設置與管理 (Setup/Admin)： 10% (重啟服務與恢復測試資料)

測試筆記：
* 活動 (Activity)： 執行多人在線同時搶購「週五熱門時段」車票的模擬腳本。
* 覆蓋範圍 (Coverage)： 資料庫連線池 (Connection Pool) 壓力。
* 預言/判斷準則 (Oracles)： 依據效能規格書，系統應可承受每秒 500 筆訂單而不噴出 504 Gateway Timeout。

錯誤與議題：
* Bugs： [Critical] 資料庫在處理「剩餘位元組更新」時發生 Row Lock 競爭。
* Issues： 測試環境的資料庫配置與 Production 不一致（CPU 僅 2 核心），導致效能瓶頸被放大。

整體評估： 由於基礎環境問題，原訂的「早鳥票邏輯測試」無法進行。已將此 Session 轉向問題定位，明天需重新補一個 Session。

範例三：針對「流程議題」的深度觀察
這個範例強調了測試筆記的「三個月法則」以及對開發流程中「議題 (Issues)」的捕捉。

測試會話匯報 #003

章程 (Charter)： 評估「T-EX 行動購票」APP 與「實體自動販賣機」取票條碼的跨平台一致性。

基本資料：
* 測試人員： 老查
* 環境/版本： App v5.4.0 / 實體測試機台 (Kiosk #09)
* 區域標籤： 跨通路整合 / O2O 流程

時間運用：
* 測試執行 (Execution)： 60%
* 錯誤調查 (Bug Investigation)： 15% (測試不同螢幕亮度下條碼掃描成功率)
* 設置與管理 (Setup/Admin)： 25% (移動至實體機台實驗室)

測試筆記：
* 覆蓋範圍 (Coverage)： QR Code 掃描、身分證字號取票、訂位代號取票。
* 活動 (Activity)： 在 App 訂票後，故意將手機螢幕亮度調至最低，測試實體販賣機的掃描頭感應能力。
* 預言/判斷準則 (Oracles)： 使用者經驗指南 (UX Guideline) 提到掃描時間應在 1.5 秒內完成。

錯誤與議題：
* Bugs： 無。
* Issues： [流程/文件] 發現自動販賣機的錯誤提示語音（台語版）與螢幕顯示的繁體中文語意不完全對等，容易造成長輩困惑。此外，目前的 API 文件未定義當 App 已取票後，應顯示什麼具體錯誤代碼。

整體評估： 功能正常，但存在 UX 風險。這份筆記詳細記錄了掃描頭在不同光線下的表現，方便未來 UI 團隊評估是否增加「掃描時自動提亮螢幕」的功能。

參考資料: SBTM Session Report Checklist
https://www.satisfice.com/download/sbtm-session-report-checklist