缺陷分類與責任歸屬
軟件缺陷大致三類：
- 做的不是客戶要的（需求/溝通問題）
- 做了不該做的（代碼 Bug）
- 做錯了事（代碼 Bug）
本文聚焦第 2、3 類——純代碼層面的 Bug，這是開發者能直接控制的戰場。
為什麼一定要自己測？
- 黑盒測試（測試人員）能發現症狀，難定位根因
- 白盒測試（開發者）能直達邏輯分支、邊界條件、中間變量
- 外部發現 → 往復修改驗證 → 成本指數級上升
- 客戶現場發現 → 信任崩塌、損失不可估量
自測兩種模式
- 獨立自測：寫完即測，上下文最鮮活
- 交叉測試/結對編程：XP 模式，雙眼審代碼，但需磨合成本
最強實戰法：單步跟蹤測試（Step-by-Step Debugging）
操作流程
- 在所有需測試的方法、分支（if/else、循環、switch case）打斷點
- 啟動除錯器，單步執行（Step Over / Step Into）
- 檢查中間變量值、邏輯分支走向、異常拋出、資源釋放
- 執行到的斷點移除（變綠），直到紅點全清
- 輔助手段：測試介面、單元測試（JUnit）、數據記錄對比
修改代碼同理
變動行必須單步跟蹤一遍，哪怕你對原代碼有「101% 信心」。
為什麼這麼有效？
- 你最清楚代碼「該做什麼、不該做什麼」
- 單步執行 = 強制覆蓋每一行，無死角
- 運行時錯誤（空指針、越界、死鎖）當場暴露
- 邏輯錯誤（條件判斷反、循環次數錯）即時發現
成本核算
看似耗時，實則總成本最低：
- 開發階段發現：成本 = 1x
- 測試階段發現：成本 ≈ 10x（往復溝通、環境切換）
- 生產環境發現：成本 ≥ 100x（停機、熱修復、信任損失）
核心信條：開發人員單步跟蹤測試自己的代碼，朝著零缺陷的方向，朝著勝利的方向。
落地建議
- 將「單步跟蹤全覆蓋」納入代碼提交前檢查清單
- 配合
Git pre-commit hook 或 CI 門禁強制執行
- 新人導師制：資深帶新人做前 3 次全流程跟蹤
- 工具鏈：IDE 除錯器 + JUnit + 覆蓋率工具 形成閉環
