自從2006年Unruly公司成立以來，其團隊就開始采用極限敏捷（XP）實踐并沿用至今。Unruly的軟件開發項目是由多個小型團隊完成的，沒有設立專職的測試人員。這些團隊在開發代碼時遵從測試優先原則，并且投入了大量的精力以實現能夠在真實環境運行的自動化檢測，而不依賴于在預發布環境中進行手工測試。

\\

Rachel Davies是Unruly的敏捷教練，她在敏捷測試日2015年荷蘭大會上進行了關于持續測試的主題演講。InfoQ有幸對Davies進行了采訪，內容涉及以持續化方式進行測試的重要性、這種方式是如何演變的，以及它為Unruly所帶來的商業優勢。

\\

InfoQ：能否請你解釋一下，為什么自動化測試對你的團隊如此重要？

\\\

Davies：它的重要性是因為自動化測試比起手工檢測軟件速度更快、也更加可靠。手工測試是一件很煩人的工作。我們希望做到，在銷售人員提出某些產品變更需求的當天就能夠立即部署。為了實現這一點，我們對部署腳本進行了自動化，并且通過腳本運行自動測試。機器比人類運行重復性步驟要快得多，因此自動化能夠幫助我們更快地交付有價值的解決方案。

\\\

InfoQ：你能否為我們舉一些例子，讓我們了解自動化測試是如何幫助Unruly的團隊交付商業價值的？

\\\

Davies：銷售人員可以對運行中的系統提出某種變更的需求，而我們能夠在幾個小時、而不是幾天內讓這個變更生效。我們有一個與眾不同的地方，就是我們沒有搭建任何臨時的預發布環境，強制代碼必須在這些環境上進行檢驗。我們的做法是直接將變更發布到生產環境中，因為這樣可以更快地交付價值。雖然新的代碼直接部署了到新的生產環境中，但我們可以通過某些手段讓在線系統的用戶不會直接看到這些變更。我們的做法是使用多個可部署的小步驟，通過自動化測試檢測行為是否符合我們的需求。如果在測試中出現了速度緩慢或是經常出錯的情況，那么在團隊的回顧會議中會進行討論。

\\\

InfoQ：經過這么多年對持續測試的投入，你覺得為什么值得這樣做，持續測試能夠為你帶來什么益處？

\\\

Davies：通過采取測試優先的開發方式，我們實現了良好的代碼覆蓋率，以幫助我們檢測產品的特性是否按期望的方式工作。如果有任何變更破壞了現有的自動化測試，我們能夠迅速地發現問題。通過對在線服務進行自動化監控，也能夠幫助我們指出是否出現了哪種我們沒有預料到的情況。以測試驅動我們的產品開發，這種方式也幫助我們團隊專注于所需交付的價值，并不斷發展前進。

\\\

InfoQ：在敏捷測試日荷蘭大會上，你談到了在生產環境中運行某些持續性的檢測以進行持續測試。你能否描述一下這種方式是如何實現的？

\\\

Davies：我們配置了Nagios警報系統，它會根據在線服務的不同情況對團隊發出通知。如果出現問題，我們將通過短信方式獲得通知。我們也在開發團隊的區域擺放了幾臺大屏幕，以顯示我們的在線系統的軟件負載及性能。也許你會有興趣讀一下我們的開發者所寫的一個博客，其中提到了監控檢測中的壞味道。

\\\

InfoQ：你能否詳細闡述一下自動化測試這幾年間在Unruly是如何演變的嗎？

\\\

Davies：公司是于2006年成立的，我們當時就采用了XP實踐當中的TDD，因此從一開始測試就是自動化的。經過幾年的發展，我們必須將這些測試擴展到瀏覽器與設備測試上（因為瀏覽器和移動平臺的新功能也在不斷涌現）。產品的功能也擴展了，并且在技術上產生了很大的轉變，轉為能夠適應桌面電腦、平板和移動設備的“響應式”網站。而在2006時平板電腦并非我們所考慮支持的設備。

\\

我們并沒有采用讓非技術人員也能夠閱讀的BDD風格的測試，這是因為我們早先在使用FiTnesse進行自動化驗收測試時的體驗很糟糕。我們的開發者直接與項目干系人進行對話，而不是業務分析師。所有的測試都是由開發者使用與應用代碼相同的編程語言進行編寫和維護的，因此使用示例型BDD的風格對于我們來說沒有多少益處。

\\\

InfoQ：你在演講中提到在測試中使用了chaos monkeys技術，你是否詳細說明一下？

\\\

Davies：這一點是受到Netflix的基礎設施chaos monkeys的啟發，因此我們也開發了特定于我們領域的“monkeys”，在生產環境中的應用級別注入一些潛在的錯誤，例如在對于延遲非常敏感的應用中產生服務無響應的錯誤。這種方式能夠幫助我們找到并修復那些在測試環境中不會出現的問題。我們的一位開發者Alex Wilson在一篇博客帖子中就提到了如何在生產環境中注入應用級的錯誤。

\\\

InfoQ：有沒有什么新的測試技術是看起來很有前途的，并且你們團隊也打算嘗試的？

\\\

Davies：我們或許能夠在手工探索性測試方面投入更多時間。對于這種測試，經典的定義是“同時進行測試設計與測試執行，同時進一步學習系統”，這一定義來自于由Cem Kaner、James Bach與Bret Pettichord在2002年共同出版的名作《軟件測試經驗與教訓》（Lessons Learned in Software Testing）。這種方式與自動化檢測不同，而是積極地探索系統的各種行為，在不使用腳本的情況下學習系統會表現出哪些未預料的行為。

\\\

InfoQ：如果有其它組織打算實施持續測試，你能否為他們提供些建議？

\\\

Davies：首先將所有的回歸測試都實現自動化，并且不要將注意力分散到BDD上。從基礎的健康狀況檢測開始自動化，例如冒煙測試，并逐漸改善測試覆蓋率。從最重要的業務邏輯，或是最容易出錯的地方開始。

\\\

查看英文原文：Benefits of Continuous Testing

總結

以上是生活随笔為你收集整理的持续测试的益处的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。