質量是團隊的責任，不只是測試的責任。
質量的定義與責任#
質量不是測出來的，而是設計和開發出來的。質量保障是整個團隊的責任，不只是 QA 的責任。
寶玉在《軟體工程之美》中強調：
很多團隊認為「測試保證質量」，這是錯誤的。測試只能發現問題，不能保證質量。質量來自每一個環節的認真對待。
質量的成本#
flowchart TD
subgraph P [💰 預防成本 - 最低]
P1[代碼規範]
P2[設計評審]
P3[培訓]
P4[工具投入]
end
subgraph E [💵 評估成本]
E1[代碼評審]
E2[測試執行]
E3[質量審計]
E4[監控告警]
end
subgraph I [💸 內部失敗成本]
I1[Bug 修復]
I2[返工重做]
I3[延期]
I4[團隊士氣]
end
subgraph O [💔 外部失敗成本 - 最高]
O1[客戶投訴]
O2[賠償損失]
O3[品牌受損]
O4[信任喪失]
end
P -->|投資不足| E
E -->|發現不及時| I
I -->|流入生產| O
style P fill:#c8e6c9
style E fill:#fff9c4
style I fill:#ffe0b2
style O fill:#ffcdd2在早期發現和修復問題的成本最低。投資於預防，而不是事後補救。
測試策略#
測試金字塔#
經典的測試金字塔模型：
/\
/ \
/ UI \ 少量端到端測試
/------\
/ 集成 \ 適量集成測試
/----------\
/ 單元 \ 大量單元測試
/--------------\各層測試的特點：
| 測試類型 | 速度 | 成本 | 覆蓋範圍 | 定位問題 |
|---|---|---|---|---|
| 單元測試 | 快 | 低 | 小（單個函數/類） | 精準 |
| 集成測試 | 中 | 中 | 中（多個組件） | 中等 |
| E2E 測試 | 慢 | 高 | 大（完整流程） | 模糊 |
自動化測試#
寶玉關於自動化測試的建議：
值得自動化的：
├── 核心業務流程
├── 頻繁執行的回歸測試
├── 需要大量數據的測試
└── CI/CD 流水線中的測試
不一定要自動化的：
├── 一次性的測試
├── 經常變化的 UI 測試
├── 探索性測試
└── 用戶體驗測試測試覆蓋率#
追求高覆蓋率，忽略測試質量。100% 覆蓋率不等於沒有 Bug。
合理的覆蓋率目標：
- 核心業務邏輯：80%+
- 工具類/基礎設施：60%+
- UI 組件：根據情況，不強求
- 整體：60-80%
比覆蓋率更重要的：
- 測試是否覆蓋了關鍵路徑
- 測試是否真的能發現問題
- 測試是否容易維護
代碼質量#
代碼審查#
為什麼要做 Code Review：
- 發現 Bug 和設計問題
- 知識共享
- 保持代碼一致性
- 建立質量文化
Code Review 檢查清單：
mindmap
root((Code Review))
✅ 功能正確性
是否實現了需求？
邊界條件處理了嗎？
錯誤處理完善嗎？
有沒有明顯的 Bug？
🏗️ 設計質量
設計是否合理？
是否遵循設計模式？
是否過度設計？
是否有重複代碼？
📖 可讀性
命名是否清晰？
是否需要註釋？
邏輯是否容易理解？
是否符合編碼規範？
🔒 安全性
有沒有安全漏洞？
輸入是否驗證？
是否有敏感資訊洩露？
權限是否正確檢查？靜態分析#
常用的靜態分析工具：
- 語法檢查（ESLint、Pylint）
- 類型檢查（TypeScript、mypy）
- 安全掃描（SonarQube、Snyk）
- 複雜度分析
把靜態分析集成到 CI 流程中，問題代碼不允許合入。這比事後發現問題成本低得多。
上線與發布#
發布策略#
寶玉介紹的發布方式：
滾動發布（Rolling Update）：
- 逐步替換舊版本
- 過程中新舊版本共存
- 可以隨時回滾
藍綠部署（Blue-Green Deployment）：
- 準備兩套環境
- 切換流量到新環境
- 問題時快速切回
金絲雀發布（Canary Release）：
- 先給小部分用戶使用新版本
- 觀察指標正常後逐步擴大
- 發現問題只影響少量用戶
選擇建議：
├── 小更新：滾動發布
├── 大更新：金絲雀發布
├── 關鍵系統：藍綠部署
└── 多種組合使用灰度發布實踐#
灰度的維度：
- 按用戶 ID（內部用戶優先）
- 按地區（某個城市先上）
- 按比例（5% → 20% → 50% → 100%）
- 按設備（iOS 先上，Android 後上）
灰度過程中的監控：
- 錯誤率
- 響應時間
- 業務指標
- 用戶反饋
灰度不是萬能的。如果問題在灰度階段沒發現，全量後可能更難發現。灰度階段要認真監控。
安全實踐#
安全左移#
寶玉提出「安全左移」的概念：
安全問題越早發現成本越低。不要等到上線前才做安全測試。
各階段的安全實踐：
| 階段 | 安全活動 |
|---|---|
| 需求 | 安全需求分析、威脅建模 |
| 設計 | 安全設計評審 |
| 開發 | 安全編碼規範、代碼審查 |
| 測試 | 安全測試、滲透測試 |
| 部署 | 配置審查、漏洞掃描 |
| 運維 | 監控、響應、更新 |
常見安全問題#
OWASP Top 10（簡化版）：
注入攻擊：
├── SQL 注入
├── 命令注入
└── 防護：參數化查詢、輸入驗證
認證問題：
├── 弱密碼
├── Session 管理
└── 防護：多因素認證、安全會話
敏感數據：
├── 數據洩露
├── 傳輸不加密
└── 防護：加密存儲、HTTPS
訪問控制：
├── 越權訪問
├── 權限繞過
└── 防護：嚴格權限檢查永遠不要信任用戶輸入。所有外部輸入都要驗證和過濾。
生產事故處理#
事故響應流程#
喬新亮分享的事故處理原則：
flowchart TD
subgraph D [🔔 發現階段]
D1[監控告警] --> D2[快速確認問題]
D3[用戶反饋] --> D2
D4[內部發現] --> D2
end
subgraph R [⚡ 響應階段]
R1[組織響應團隊] --> R2[判斷影響範圍]
R2 --> R3[決定處理策略]
R3 --> R4[對外溝通]
end
subgraph H [🔧 處理階段]
H1[🚨 止血優先] --> H2[修復問題]
H2 --> H3[驗證恢復]
H1 -.- H1a["恢復服務最優先"]
end
subgraph P [📝 復盤階段]
P1[時間線梳理] --> P2[根因分析 5 Why]
P2 --> P3[改進措施]
P3 --> P4[經驗分享]
end
D --> R --> H --> P
style D fill:#ffebee
style R fill:#fff3e0
style H fill:#e8f5e9
style P fill:#e3f2fd事後復盤#
復盤的目的是學習和改進，不是追責。如果復盤變成追責會議，以後就沒人敢報告問題了。
好的復盤會議：
- 聚焦系統和流程，而非個人
- 鼓勵誠實說出問題
- 產出具體的改進措施
- 跟進改進的執行
復盤報告模板：
mindmap
root((復盤報告))
📋 事故概述
時間
影響範圍
持續時間
⏱️ 時間線
詳細的事件發展過程
🔍 根因分析
直接原因
根本原因（用 5 Why 分析）
📊 影響評估
業務影響
用戶影響
🛠️ 改進措施
短期修復
長期改進
責任人和時間表本章要點#
- 質量是團隊責任：不只是測試的責任
- 測試金字塔：大量單元測試，適量集成測試，少量 E2E
- Code Review：發現問題、共享知識、建立文化
- 灰度發布：逐步上線，邊發布邊監控
- 安全左移：越早發現安全問題成本越低
- 復盤不追責：目的是學習和改進