將測試工作作為前鋒

要成功實施持續交付，我們必須要相信能夠在不影響現有功能的情況下快速有序的交付新功能。這裡，我們討論一下如何通過pipeline確保高質量的持續交付。

通常的做法是先開發功能，然後進行測試。這樣就導致測試成了應用上線路上的乙個路障。畢竟，**都已經在那兒了---還等什麼呢？無法避免的延遲導致測試被壓縮或者中斷，於是也就導致交付了低質量的功能。

在持續交付環境中，我們採用了更具有生產力的方式。有了自動化的可測試規範，測試變成了首要的事情，可以先於開發工作啟動。自動化的測試可以是開發過程的一部分持續的執行。這種方式給我們提供了pipeline所有階段的功能和質量層次的實時反映。

傳統的規範會隨著需求和功能的變化過時而被束之高閣。冗長的文件首先被轉換為測試用例，然後手工執行。這樣費時費力的過程還可能會導致測試無法驗證最初設想的功能。

採用持續交付，我們切換到了可執行規範。這些規範是採用了結構化的自然語言形成的，可以被業務和測試工具所理解。再也沒有迷失在轉換為測試用例的問題了：規範本身就是功能驗收測試。

寫乙個小的程式執行在便攜本等相對友好的環境中並不是難事，可是，在真實的業務環境中交付可靠的經過驗收的高質量軟體是比較有挑戰性的。

持續交付的成功實施需要我們在不影響已有功能的情況下，非常有信心能夠快速且有節奏的交付新的功能。否則，就是出現了回歸問題。

避免回歸問題的乙個有效的測試型別是白盒測試。

軟體開發領域中，對一段**行為所做的測試被稱為單元測試。在tdd，開發者通常在寫真正的**之前先寫單元測試**。一旦模組的單元測試建立了，變會經常執行以保證該模組的功能正確。

從管理者的角度，好的回歸測試有兩個度量指標：覆蓋度和執行時間。覆蓋度是表示有多少系統行為被測試用例驗證的百分比。測試覆蓋度達到100%可能會花費大量的時間，導致業務上無法接受。所以，需要在覆蓋度和花費時間之間達到某種平衡。比如，關鍵的每個變更需要全覆蓋，優化配置和工具、並行測試減少執行時間等。