階段 7 · 確保品質（測試與檢查）
Bug
程式行為和預期不同，造成錯誤或不正常結果。
先用一句話理解
程式行為和預期不同，造成錯誤或不正常結果。
打個比方
像機器某個零件卡住，表面看起來還在跑但結果不對。
什麼時候會遇到
測試、客戶回報、監控警報或上線後異常時。
再往深一點看
Bug 是程式的實際行為和預期行為之間的落差——可能是邏輯錯誤（計算結果不對）、邊界條件沒處理（使用者輸入空字串就當機）、競爭條件（兩個請求同時寫入同一筆資料導致資料毀損），或是環境差異（本機沒事但正式環境報錯）。找 bug（debugging）的起點是重現：如果你無法穩定讓 bug 出現，就無法確認修好了。Sentry 這類監控工具可以在正式環境自動捕捉錯誤發生的當下，記錄 stack trace、使用者操作路徑、瀏覽器版本，讓你不用等使用者「描述一下發生了什麼」。Bug 和 issue 的關係是：通常 bug 回報後會開一張 issue（任務單）來追蹤「這個 bug 目前是什麼狀態、誰在修、修完了沒」。
舉個例子
使用者回報「結帳時金額顯示 0 元」，你在 Sentry 找到對應的錯誤紀錄，看到 stack trace 指向 calculateTotal() 函式裡有一行把字串相加而不是數字相加（'100' + '200' === '100200'）。重現步驟確認後，修正型別轉換、補一個 unit test 確保這個案例以後不會再壞，然後開 PR 修復。
常見誤解
- - 只描述「壞掉了」或「不能用」，沒有提供重現步驟、預期結果與實際結果，工程師收到回報後光是重現問題就要來回問好幾次，浪費雙方時間。
- - 發現 bug 後直接在正式環境的程式碼上改，沒有先在本機重現和修復再部署，匆忙修改反而引入新 bug，且沒有任何 git 紀錄可以追溯。
- - 修完 bug 後沒有補測試，下次改到相關程式碼又讓同一個問題復活（regression），因為沒有任何自動化的防護。
相關名詞
相關服務
SentryGitHub