缺陷意味著返工，返工意味著浪費
有效的質量控制措施：
n 準確完整描述使用者需求
n 關注非功能性需求
n 質量內建在開發過程之中
n 小迴圈快速獲取驗證反饋
n 自動化、自動化、自動化
n 資訊公開透明，授權決策
n 適度架構，組織和架構匹配
n 從失敗中吸取教訓
測試金子塔和測試受創面
**-->單元測試-->整合測試-->介面測試-->ui/功能測試-->生產環境部署
單元測試
n 自動/手工
n ide/流水線內執行
n 單個**檔案即可執行
n 無需部署
n 速度快
n 職責：開發人員
n 工具:junit等測試框架
整合測試：
n 自動/手工
n ide/流水線內執行
n 單個/多個**檔案即可執行
n 可能需要部署
n 速度比較快
n 職責：開發人員
n 工具：基於測試框架或者手工完成
介面測試：
n 自動/手工
n 特定環境中執行
n 單個服務部署完成(微服務)
n 需要部署
n 速度較慢
n 職責：開發/測試人員
n 工具：
ui/功能測試：
n 自動/手工
n 特定環境中執行
n 系統完整部署完成
n 需要部署
n 速度慢
n 職責：開發/測試人員
n 工具，selenium
自動化測試是某種型別測試的一種狀態
單元測試：不需要在部署環境中就能測試
測試金字塔和軟體生命週期：
微軟測試管理策略的演進
l0:每次嵌入，只需要執行時檔案就可以執行，在ci中執行，必須迅速可靠
l1:每次嵌入，但需要依賴環境資源
l2:必須針對特定的「環境執行，逐步清理」
l3:直接在生產環境執行
原則：
n 測試應用在最低**層級編寫
n 編寫一次，可在所有環境執行(包括生產環境)
n 可測試性事設計的重要目標
n 將測試**看作生產**的一部分，僅保留可以穩定執行的測試**
n 微測試提供可自動獲取的共享資源
研發效能提公升的核心秘籍
管理粒度：devops從管理角度優化永遠實在通過控制「管理單元」的粒度來完成的。所謂的「管理單元」可能是團隊、需求，任務，測試，交付物等任何研發中的被管理物件
研發效能提公升：無論是敏捷，精益或者持續交付，其最終目的都是為了提公升效能。所謂「效能」，就是單位投入的產出量(效率)和組織實現目標的能力
工程解耦：devops從技術角度的優化永遠實在通過解除「工程物件」之間的耦合實現的。所謂「工程物件」可能是系統，工具，**，模組，服務，平添，雲或者任何在研發過程中存在或者交付的技術物件。
《持續交付》筆記 第4章 測試策略的實現
測試是跨職能部門的活動，是整個團隊的責任，應該從專案一開始就一直做測試。摘自本書 支援開發過程的 評判專案的 業務導向的 測試驗收測試 自動的 演示易用性測試 探索性測試 手工的 技術導向的 單元測試 整合測試 系統測試 自動的 非功能驗收測試 包括容量測試 安全性測試等 手工的 自動的 自動化驗收...
測試管理 出色測試管理者的思考 持續更新ing
如何合理安排並按質按量按時完成每乙個測試任務，做好專案管理？如何把控到每乙個測試任務的質量？如何快速構建和構建好測試環境？如何獲取或快速製作測試資料？如何確保每乙個測試人員的工作都飽滿？如何快速提公升團隊整體的業務和技術技能水平？如何根據每個測試人員的特點和優勢來分配好其工作職能？如何因人定製績效考...
研發管理中的測試管理
專案在分析 設計 實現 組裝後，就進入測試環節，測試作為檢測我們設計的軟體是否滿足設計的功能需求，及其效能需求及其隱性需求起著重大的作用，作為最後成形的產品，可能在一些功能或是設計上存在缺陷，或是對於使用者的需求歪曲的設計，都可以在測試環節找出來，予以修正。因此從這個角度上看，我們應該是重視軟體測試...