測試是跨職能部門的活動，是整個團隊的責任，應該從專案一開始就一直做測試。——摘自本書
支援開發過程的
評判專案的
業務導向的
測試驗收測試
（自動的）
演示易用性測試
探索性測試
（手工的）
技術導向的
單元測試
整合測試
系統測試
（自動的）
非功能驗收測試
包括容量測試
安全性測試等
（手工的/自動的）
自動化驗收測試的價值
1、加快了反饋速度；
2、減少了測試人員的工作負荷；
3、可讓測試人員集中精力做探索性測試和**值的活動；
4、也是一組回歸測試套件；
往往驗收測試會通過直接操作使用者介面的方式來執行。一旦介面改變了（哪怕是一點兒），測試也會被破壞，偶合緊。書中提到有二種方法來解決這個問題：一種是測試與使用者介面之間增加乙個抽象，以減少因使用者介面變更而導致的工作量。另一種是通過api來隔離，而使用者介面也會使用這些api來執行真正的操作。（我們原來某專案就是採用第二種方法）。當然並不是說不需要使用者介面測試了，這樣分離的好處就是驗收測試可以直接驗證業務邏輯，把使用者介面測試成本減少到更低。
這種自動化測試單獨由開發人員建立和維護。這一節講得比較少，簡單地概括包含單元測試、整合測試（元件測試）和部署測試（系統測試）。
這類手工測試可以驗證我們實際交付給使用者的應用軟體是否符合期望。這節也是簡單介紹了演示、易用性測試和探索性測試。一種非常重要的面向評介專案的測試就是演示。每次迭代結束時敏捷團隊會向使用者演示所完成的功能，以確保盡早發現與需求一致。最後文中也提了一下beta測試。
驗收測試分為兩類：功能測試和非功能測試。主要提到非功能測試（包括容量測試、安全性測試等）是屬於支援導向且評介專案的測試。
最重要的是一開始就要寫自動化驗收測試。
建立自動化構建；
制定遵守invest原則；
客戶、分析師和測試人員定義驗收條件；
測試人員和開發人員一起基於驗收條件實現驗收測試的自動化；
只要有自動化測試失敗，無論是單元測試、元件測試還是驗收測試，開發人員都應該把修復測試失敗定為最高優先順序；
引入自動化測試最好的方式是選擇那些最常見、最重要且**值的用例為起點。
在這種情況下，如果沒有自動化構建流程，最高優先還是建立乙個，然後再慢慢豐富。
該章總體來說還是提倡盡可能多的自動化測試，並結合相應的手工測試，比如探索性測試和演示。文中提到測試主要是建立一種反饋迴圈，而這種反饋環會驅動開發，設計等活動。若將測試推遲到後期最終將會導致專案成本增加甚至失敗。
第4章 持續交付2 0的組織文化
持續交付2.0 強調 持續學習 和 快速驗證 而探索必然會伴隨著失敗，失敗會令人產生挫敗感和不安全感。而學習與成長也通常法神在失敗之後。這就要求組織必須建立 安全 信任與持續改善 的組織文化 第一步 定義想要做的事情 第二步 定義期望的做事方法 第三步 提供相應的培訓 第四步 做些必要的事情來強化那...
08 持續交付中測試管理策略筆記
缺陷意味著返工，返工意味著浪費 有效的質量控制措施 n 準確完整描述使用者需求 n 關注非功能性需求 n 質量內建在開發過程之中 n 小迴圈快速獲取驗證反饋 n 自動化 自動化 自動化 n 資訊公開透明，授權決策 n 適度架構，組織和架構匹配 n 從失敗中吸取教訓 測試金子塔和測試受創面 單元測試 ...
讀書筆記 軟體測試的藝術第4章
黑盒測試 等價類劃分 邊界值分析 因果圖分析 錯誤猜測 白盒測試 語句覆蓋 判定覆蓋 條件覆蓋 判定 條件覆蓋 多重條件覆蓋 白盒測試 關注的是測試用例執行的程度或覆蓋程式邏輯結構 源 的程度。語句覆蓋是白盒測試中較弱的準則，通常沒有什麼用處。判定覆蓋或分支覆蓋式較強的一些邏輯覆蓋準則。該準則要求必...