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

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

使用測試工具：有許多測試工具能夠執行軟件，貫穿軟件的基本流程。所以，選擇恰當的自動化檢查工具很是關鍵，而其目標是下降風險，快速執行，減小手工維護的工做量。

將工具鉤連到構建系統：等待構建完成再手工執行檢查會浪費大量的時間，而在每次構建時自動檢查能夠消除這種浪費，最好是有一個自動化的檢出/構建/部署/測試/推廣管道。

從根本上消除迴歸錯誤：利用減小發布候選測試節省出的時間改進開發實踐。

開發可單獨部署的組件：藉助組件，每一個變動都是相互隔離的。變動影響範圍小，下降了部署風險，使得部署或回滾過程更可控。

根據風險劃分測試/部署策略：不一樣的功能可能須要不一樣的測試策略或過程，高風險、發佈頻率低的變動可能須要更嚴格的測試過程。Zappos（Amazon的一個部門）好久以前就採用了這種方式。

持續監控生產環境：缺陷代碼在生產環境中存在的時間越長形成的損害越大。若是團隊能夠快速發現並修復缺陷，那麼風險將大大下降。

自動部署和回滾：經過幾回點擊就能夠實現部署或回顧。

配置標識：程序員在編碼時將新特性封裝在一個if()語句中，而後就能夠經過將配置標識設置爲「On」或「Off」來啓用或關閉特性。感興趣的讀者能夠閱讀下這篇文章。

增量滾動發佈：將配置標識與不一樣的用戶關聯，就能夠實現爲不一樣的客戶提供不一樣的功能。感興趣的讀者能夠看下微軟的作法。

固然，並非在任何狀況下均可以消除發佈候選測試。在某些狀況下，須要在測試時間和發佈風險之間進行權衡。也就是說，要根據風險制定靈活的發佈候選測試策略。

對於JavaWorld的報道，有網友提出了不一樣的意見。Steve Naidamast認爲：

這個消除或減小應用程序的建議跟實際的測試過程同樣複雜，甚至更復雜……此外，因爲能力的不足或工具的缺陷……，會引入新的問題……

而網友Chris Riley則認爲該報道具備誤導性：

第一，它沒有建議咱們減小測試，而只是將測試移到了管道中的不一樣位置。第二，持續交付並不適合全部人……這看上去是個不錯的理想，但可能會誤導R&D主管在沒有備用計劃的狀況下錯誤地削減了QA職位。

本文轉自：http://www.spasvo.com/news/html/201591103204.html