為何 SRE 與測試密不可分#

測試是 SDLC 不可或缺的一環，目的是在軟體上線前找出 bug、錯誤與缺陷。

測試愈詳盡、愈嚴謹，系統愈穩定。SRE 才能把心力放在 production 的其他面向，而非疲於繞過錯誤。

各種測試類型#

單元測試（Unit testing）#

• 開發者在自己模組上做的低階測試
• 通過後才把程式碼合進中央倉庫
• 多數開發工具內建單元測試框架，可直接客製
• 屬於功能性測試，但範圍小

功能測試（Functional testing）#

聚焦業務需求，驗證動作的輸出是否正確（而非中間狀態）：

• 回歸測試（Regression testing）：每次合併新程式碼後執行，確認沒破壞既有功能
• 遞增測試（Progression testing）：針對新程式碼測試是否有新缺陷

例如服務 A 應傳資料給服務 B，若資料順利送達，功能測試就通過；但服務 A 花了 1 小時才送達這種「中間狀態」，不在功能測試範疇，要靠效能測試補捉。

使用者測試（User testing）#

• 模擬使用者在完整應用環境的行為
• 多從 UI 切入，但失敗會反映後端問題
• 與單元、功能測試相互關聯

效能測試（Performance testing）#

• 在特定工作負載下評估系統表現
• 確保高峰流量下的效能與可靠性
• 自動化工具可注入大量請求，用來找瓶頸與穩定度

混沌測試（Chaos testing）#

• 在受控環境中蓄意注入故障，驗證系統的反應與韌性
• 是降低未發生即下線的重要實踐

冒煙測試（Smoke testing）#

• 又稱 shakedown 測試
• 端對端驗證系統基本功能
• 多在 pre-production 上線前最後執行
• 確認應用「能否走完最基本流程」

測試的價值#

• 產品品質：每種測試各補不同層面的缺陷，反覆迭代直到系統穩定
• 安全：及早抓出程式中的安全漏洞與敏感資料外洩風險，並驗證基礎設施安全（OS 版本、防火牆等）
• 節省成本：愈早發現問題愈便宜；上線後再修要付出更高代價
• 系統效能：理解高負載與故障下的行為，協助 SRE 為 production 做好準備
• 客戶滿意：少 bug、多穩定，是客戶滿意度的根本

案例：2017 AWS S3 災難#

2017 年 AWS S3 大規模當機，影響全球數千家業務。根因是一道 S3 擴充指令的錯字，意外移除大批伺服器。本可在較低層環境先測試指令而避免——這個案例說明基礎設施程式碼也必須測試，不是只有業務邏輯需要驗證。

多階段測試的真實流程#

• 開發完成後，CI/CD 把程式碼部署到測試環境
• QA 進行多種功能測試，包括遞增與回歸測試
• 通過後部署到 pre-production 環境
• SRE 在此進行混沌測試與效能測試
• 全部通過後才能進入 production

測試應該嵌入 SDLC 的每個階段，不是某一階段的單獨任務。挑選內建測試能力的工具，並讓 QA 用自動化測試案例擴大覆蓋範圍，是維持系統穩定與提升客戶滿意的捷徑。