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

　　釋出候選測試需要花費很長時間，這是許多敏捷團隊都面臨的一個最大的挑戰。但據JavaWorld報導，許多公司都透過持續交付模型消除或極大地減少了釋出候選測試，而且它們有一些共性：
　　使用測試工具：有許多測試工具可以執行軟體，貫穿軟體的基本流程。因此，選擇恰當的自動化檢查工具非常關鍵，而其目標是降低風險，快速執行，減少手工維護的工作量。
　　將工具鉤連到構建系統：等待構建完成再手工執行檢查會浪費大量的時間，而在每次構建時自動檢查可以消除這種浪費，最好是有一個自動化的檢出/構建/部署/測試/推廣管道。
　　從根本上消除迴歸錯誤：利用減少釋出候選測試節省出的時間改進開發實踐。
　　開發可單獨部署的元件：藉助元件，每個變更都是相互隔離的。變更影響範圍小，降低了部署風險，使得部署或回滾過程更可控。
　　根據風險劃分測試/部署策略：不同的功能可能需要不同的測試策略或過程，高風險、釋出頻率低的變更可能需要更嚴格的測試過程。Zappos（Amazon的一個部門）很久之前就採用了這種方式。
　　持續監控生產環境：缺陷程式碼在生產環境中存在的時間越長造成的損害越大。如果團隊可以快速發現並修復缺陷，那麼風險將大大降低。
　　自動部署和回滾：透過幾次點選就可以實現部署或回顧。
　　配置標識：程式設計師在編碼時將新特性封裝在一個if()語句中，然後就可以透過將配置標識設定為“On”或“Off”來啟用或關閉特性。感興趣的讀者可以閱讀下這篇文章。
　　增量滾動釋出：將配置標識與不同的使用者關聯，就可以實現為不同的客戶提供不同的功能。感興趣的讀者可以看下微軟的做法。
　　當然，並不是在任何情況下都可以消除釋出候選測試。在某些情況下，需要在測試時間和釋出風險之間進行權衡。也就是說，要根據風險制定靈活的釋出候選測試策略。
　　對於JavaWorld的報導，有網友提出了不同的意見。Steve Naidamast認為：
　　這個消除或減少應用程式的建議跟實際的測試過程一樣複雜，甚至更復雜……此外，由於能力的不足或工具的缺陷……，會引入新的問題……
　　而網友Chris Riley則認為該報導具有誤導性：
第一，它沒有建議我們減少測試，而只是將測試移到了管道中的不同位置。第二，持續交付並不適合所有人……這看上去是個不錯的理想，但可能會誤導R&D主管在沒有備用計劃的情況下錯誤地削減了QA職位。
　　本文轉自：