為可靠度測試:測試不是證明沒 bug,是讓你敢快

這篇講一個常被當成「開發的事」、其實是可靠度基石的東西:測試。關鍵觀念先講:可靠度不是靠「不改」得來的——你一定得改(修 bug、加功能、換設定),而每次改動都是一場賭。測試的意義,就是把這場賭變成有信心的推進,讓你敢頻繁小步發布(這正是 error budget 想要的:改得起、也退得回)。

測試金字塔:底層多、上層少

測試分幾層,而它們的數量該呈金字塔——底層(便宜、快、穩)要多,上層(貴、慢、脆)要少:

綠燈不等於 Production 健康:用 Canary 收尾

但這裡有個 SRE 特別在意的真相:測試全綠,只代表「你想到要測的情境」過了——真實世界的流量、資料、時序,永遠有你沒測到的。所以光在測試環境過還不夠,最後一道防線是 Canary(金絲雀發布):新版先只放給一小撮真實流量,盯著 SLI,沒問題再逐步全推:

還有兩個常被忽略的:設定(configuration)也要測——很多故障來自改設定而不是改 code,而設定常常沒人測就上;以及主動的災難演練——像 Chaos Monkey 那樣故意注入故障,測「壞了會怎樣」,而不只測「正常會怎樣」。

Flaky test 是測試界的「狼來了」

最後一個一定要治的病:flaky test(不穩定測試)——偶爾紅、re-run 一下又綠了。它比沒有測試更毒,因為它訓練整個團隊養成「看到紅燈先重跑,通常就過了」的習慣,於是真正的紅燈也被無視。這跟 告警疲勞是同一個病:雜訊麻痺了訊號。我的原則很硬:flaky test 要嘛當天修好、要嘛移除,絕不放著——放著它,會慢慢腐蝕整個團隊對「綠燈」的信任。

反思

測試的目的不是「證明沒 bug」,是「讓你敢快」

我年輕時把測試當成「證明我的 code 沒問題」的檢查關卡,壓力很大、也很挫折(因為根本證不完)。後來心態轉了:測試證明不了沒 bug(不可能窮舉),但它能大幅降低改動的風險——而風險一低,你就敢頻繁、小步地推進。 可靠度從來不是靠「少改、別動」換來的,是靠「敢頻繁驗證」。這跟 error budget、跟我在 K8s 滾動更新講的「讓改變可逆,人就敢頻繁前進」完全一致。把測試當加速器、不是路障,你跟測試的關係就順了。

綠燈只代表「你測到的那些」過了

測試全綠很爽,但它保證的範圍,只到「你當初想得到要測的情境」為止。真實世界的流量分佈、髒資料、奇怪時序,永遠在你的測試之外。所以我學會不把「測試過了」當成「一定沒事」,而是當成「風險已經降到,可以放一小撮真實流量去驗證」——然後用 canary 收尾。測試環境給你信心去賭,canary 讓你只賭一小口。 這個「分批下注、邊放邊看」的心態,比追求「上線前測到滴水不漏」務實太多——因為後者根本做不到。

Flaky test 會腐蝕整個團隊的判斷力

一個偶爾紅的測試,傷害的不只是它自己,是整套測試的公信力。當「紅燈 = 重跑一下」變成團隊的肌肉記憶,你就等於把警報系統關靜音了——真的出事時,那個紅燈也只會換來一次無意識的 re-run。這跟 告警、跟我一貫講的「訊號要精準」是同一件事:寧可少一個測試,也不要一個會說謊的測試。 維護測試的「可信度」,和維護測試的「覆蓋率」一樣重要——一套沒人信的綠燈,跟沒有燈沒兩樣。