重現是科學方法：控制變數與最小重現

重現是科學方法：控制變數與最小重現 「我這邊會壞，你那邊試試看？」這句話是 bug report 裡最昂貴的一句話。工程師照著這句話去試，試不出來，於是回一句「無法重現」，整張 ticket 就卡住了。工程師多半有認真試，問題在你給的線索不夠讓他走到同一個地點。 重現不是隨便戳戳看，是做受控實驗：控制環境、縮小變數、剔除雜訊，直到能用最短的路徑，讓同一件事必然再次發生。 控制變數法 重現的第一個陷阱，是同時改太多東西。你用 Chrome 在 Mac 上試，工程師用 Edge 在 Windows 上試，網路環境也不同。三個變數同時變，就算他試出來了，也不知道是哪個變數造成的；試不出來，也不知道從哪裡開始縮。 正確做法是每次只改一個條件。假設你發現上傳頭像在某個情況下會失敗，接下來的調查過程應該長這樣： 固定瀏覽器（Chrome 最新版），只換檔案格式——PNG 成功、WebP 失敗？那問題可能在格式解析。 回到 PNG，只換檔案大小——4MB 成功、6MB 失敗？那問題可能在大小限制的邊界。 固定格式與大小，只換網路環境——公司 WiFi 成功、手機熱點失敗？那問題可能跟頻寬或超時設定有關。 每次只改一個，就算最後找到的根因是「WebP 超過 5MB 在行動網路下會觸發 timeout」，這個結論也驗證得了，不是靠猜的。 邊界值分析 欄位有限制，bug 最常藏在限制的邊緣，也就是「剛好符合」和「剛好超過」的那條界線。 以暱稱欄位「上限 10 個字」為例，測試矩陣應該是： | 輸入長度 | 輸入內容 | 預期結果 | | | | | | 0 字（空白） | （不填） | 提示必填 | | 9 字 | 測試帳號名稱一二三 | 儲存成功 | | 10 字 | 測試帳號名稱一二三四 | 儲存成功 | | 11 字 | 測試帳號名稱一二三四X | 阻擋送出或截斷 | | 20 字 | AAAAAAAAAABBBBBBBBBB | 阻擋送出或截斷 | 10 和 11 是最關鍵的兩筆。Off by one 是 bug 的聚集地——開發者在寫條件判斷時， 我在用日期選擇器的時候，選了一個日期之後畫面就跑掉了，然後我重新整理又好了，但再試一次又壞了，大概是下午兩點左右，我有截圖可是截到的是空白畫面…… 一份工程師能立刻上手的最小重現： ① 進入「新增預約」頁面（需登入狀態）。 ② 在日期欄位選擇任意月份的 31 日（例如：1月31日）。 ③ 按「確認」送出。 必現結果 ：頁面跳回列表頁，但新預約未出現；Console 有 Invalid date` 錯誤。 環境 ：Chrome 124 / macOS 14.4 / 測試站 staging.example.com。 第二份讓工程師不用重建任何上下文，照著走三步，就能看到你看到的同一件事。