冒煙測試（smoke test）是部署、重建或重開機之後立刻執行的一組最小檢查：服務有沒有在聽、首頁或健康檢查端點有沒有回正確的狀態碼、最主要的一兩條路徑走不走得通。它判斷的是「這次部署有沒有整個壞掉」，通過了才值得往下跑完整的測試或把流量切過來，沒通過就不必往下測。名稱來自硬體：新裝好的電路板第一次通電，先看會不會冒煙。其他中文資料也寫作「煙霧測試」。它是一組 Testing vs Checking（探究與檢查） 裡的檢查：判斷標準事先寫死、由腳本執行，不負責發現新的錯誤類型。

概念位置

冒煙測試在測試的分層裡是範圍最窄、執行最快的那一層：它不驗證每一條路徑的行為，只驗證系統起得來、接得上。這個範圍決定了它的盲區：只在某些輸入下才出現的錯誤，冒煙測試照樣通過。一個典型的例子是重建主機之後漏了一項手動調過的設定：nginx 的 body 上限沒有收進 repo，從 repo 重建之後冒煙測試全部通過，上傳大檔案的請求卻回 413，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停時保留的範圍：只停服務、停止主機、終止主機、全部刪除〉。判斷一組檢查有沒有資格判定通過的依據，見 Test Oracle。

可觀察訊號

  • 部署腳本的最後一步是幾條 curl 或 systemctl is-active，失敗時腳本以非零的 exit 結束。
  • 存取紀錄裡有部署時間點送出的幾筆請求，來源是主機自己（Host: 127.0.0.1 或 loopback 位址）；分析 access log 時要把這幾筆排除，否則會被算成異常的來源。
  • 冒煙測試全部通過，使用者仍回報某個功能壞掉：那個功能不在冒煙測試的範圍內。

設計責任

冒煙測試的設計是在範圍與速度之間取捨：

  • 檢查的對象：服務在聽（連接埠）、回應正確（狀態碼加上回應內容裡的一個固定字串，只看狀態碼的話，回錯誤頁面的 200 也會通過）、依賴的元件接得上（資料庫、快取）。每多一項檢查，部署就多花一點時間，換到的是多擋下一類錯誤。
  • 從哪裡送：在主機上對 loopback 送，驗證的是服務本身；從主機外面經過 CDN 送，另外驗證防火牆、DNS 與 CDN 設定。恢復上線時先在主機上對 loopback 測、確認服務正確，再開放外部入口，原因是對外開放之前的錯誤只有自己看得到。
  • 失敗時的處置要寫在腳本裡：檢查失敗時以非零 exit 結束，讓部署流程停下來或回退；只印出結果而 exit 是 0 的冒煙測試，失敗了也沒有人會知道。
  • 它不取代完整的測試：冒煙測試通過只代表沒有整個壞掉。重建之後要確認行為跟原本一致，要另外比對設定（重建出來的主機與原本的主機逐項比）或跑涵蓋更多路徑的測試。

鄰卡