你在過度測試你的軟件嗎？

發布候選測試需要花費很長時間，這是許多敏捷團隊都面臨的一個最大的挑戰。但據JavaWorld 報道 ，許多公司都通過持續交付模型消除或極大地減少了發布候選測試，而且它們有一些共性：

• 使用測試工具 ：有許多測試工具可以執行軟件，貫穿軟件的基本流程。因此，選擇恰當的自動化檢查工具非常關鍵，而其目標是降低風險，快速執行，減少手工維護的工作量。
• 將工具鉤連到構建系統 ：等待構建完成再手工執行檢查會浪費大量的時間，而在每次構建時自動檢查可以消除這種浪費，最好是有一個自動化的檢出/構建/部署/測試/推廣管道。
• 從根本上消除回歸錯誤 ：利用減少發布候選測試節省出的時間改進開發實踐。
• 開發可單獨部署的組件 ：借助組件，每個變更都是相互隔離的。變更影響范圍小，降低了部署風險，使得部署或回滾過程更可控。
• 根據風險劃分測試/部署策略 ：不同的功能可能需要不同的測試策略或過程，高風險、發布頻率低的變更可能需要更嚴格的測試過程。 Zappos（Amazon的一個部門）很久之前就采用了這種方式 。
• 持續監控生產環境 ：缺陷代碼在生產環境中存在的時間越長造成的損害越大。如果團隊可以快速發現并修復缺陷，那么風險將大大降低。
• 自動部署和回滾 ：通過幾次點擊就可以實現部署或回顧。
• 配置標識 ：程序員在編碼時將新特性封裝在一個 if() 語句中，然后就可以通過將配置標識設置為“On”或“Off”來啟用或關閉特性。感興趣的讀者可以閱讀下 這篇文章 。
• 增量滾動發布 ：將配置標識與不同的用戶關聯，就可以實現為不同的客戶提供不同的功能。感興趣的讀者可以看下 微軟的做法 。

當然，并不是在任何情況下都可以消除發布候選測試。在某些情況下，需要在測試時間和發布風險之間進行權衡。也就是說，要根據風險制定靈活的發布候選測試策略。

對于JavaWorld的報道，有網友提出了不同的意見。Steve Naidamast認為：

而網友Chris Riley則認為該報道具有誤導性：