Skip to content
所有文章 ‹ Part 03 of 09 · 一次 Golang 版本升級的連鎖反應
工程 · 2 min read

逐層下降隔離回歸問題

把層一層層剝掉來定位回歸,但如果輸入本身有問題,每一層都會以同樣的方式說謊。逐層下降只走程式碼軸,搭配輸入變異才完整。

圖片處理服務的 GIF 影格數測試紅了。我們從應用層一路往下剝:應用 → 封裝層 → raw CLI → 版本 bisect(用二分法逐版本找出壞掉的那個)。每一層都紅。四層一致指向「libvips 8.18 回歸了」。regression:之前正常、更新後壞掉。感覺像四份獨立的證據,但其實是同一份。

要定位回歸發生在哪一層,把層一層層剝掉,直到用最少的元件還能重現:

你的應用程式碼 ← 最多元件 還是壞的? 封裝層(SDK / wrapper) ← 排除你的用法 還是壞的? raw upstream CLI/lib ← 如果這層還壞,就是上游 還是壞的? 版本 bisect ← 找到翻紅的那個 release
每下降一層就清除一個嫌疑人。raw 工具重現了問題,這就洗清了你的程式碼。

每下降一層就清除一個嫌疑人。當 raw 工具在最簡輸入上重現了問題。這就洗清了你的程式碼和封裝層。

盲點:你也要變動輸入。 逐層下降固定了輸入、移動了程式碼。如果輸入本身有問題,「raw 工具也壞了 → 上游有 bug」就是一個假洗清。工具對一個壞輸入做了正確的事。

輸入(你從未移動的軸) 被污染的 生產形態的 應用層 紅 綠 封裝層 紅 綠 raw CLI 紅 —「上游!」 綠 bisect 3.20 ok / 3.21 壞 全部 ok ↑ 你搜索了這裡 ↑ 答案在這裡 逐層下降只走這一直行
四個一致的結果不是四份證據。是你把一份證據數了四次。

你每下降一層都在收窄程式碼軸,感覺像進展。但整個左欄只是同一個污染的格子重複了四次。四個一致的結果不是四份證據。是你把一份證據數了四次。

逐層下降很好用,但它只走程式碼這條軸。搭配輸入變異。換一個生產形態的輸入重新跑。才能避免在錯誤的維度上越走越深。


參考來源:

延伸閱讀: 回到連鎖反應總覽。或繼續看被污染的測試基準會反轉你的診斷。也看 GIF 編碼器合併相同影格是合法行為。

↑↓ 移動 ↵ 開啟 esc 關閉