DevOps對測試員意味著什么？
當任一應用程序代碼改變了，只有將依賴于它的每樣事物都重新測試一遍，才能保證是正確的。軟件相關性通常是極其復雜的，功能中看起來毫不相關的bug很常見。即使是極小的改變也要求將所有代碼重新測試一遍，如果每一樣都是手動測試的話，這個過程需要大量資源和時間。因此，在短周期（持續集成的一部分）內，因為軟件中加入了附加組件或功能，軟件的每一部分都需要經常性地重新測試。因為通常每隔幾天要部署一次，所以不太可能每隔幾天手動測試一遍所有的功能。自動化測試提供了一種理想的解決方案，因為這種編碼測試可以在短時間按照要求進行多次。只有擁有更多實質性改變的新故事需要手動測試。一個故事的測試一完成，同樣故事的自動化測試也創建好了并被添加到一個中央儲存庫。于是，盡管測試的數目隨著項目增加而增加，但手動執行的測試數目仍保持相對穩定。
如何將一切都自動化？
DevOps中，理想情況是將測試的每個階段都自動化，可以追蹤方式的每一步并可以一次次地實現可預測的結果。盡管下面的一些做法已經存在很久了，但不少團隊沒能成功利用其優勢，因此還需要大幅度調整改善。
自動化單元測試
自動化測試的基礎應該是整個單元測試覆蓋。單元測試將會測試獨立的單元，通常是在一個不依賴于其他系統的類中。盡管還沒有變成一個主流做法，但自動化單元測試已存在了很久，且往往被視作開發團隊的責任。
自動化集成測試
集成測試連接不同的單元，還經常訪問數據庫和其他系統。這些服務測試進行地比單元測試更久且應該只在構建服務器上啟動，它通常是由測試團隊與開發團隊在一個類灰盒測試里合作執行的。有不少工具如Fitnesse和NUnit，每個都擁有特定技術且能基于需求被采用。
服務測試
服務和組件層包含不同的單元。系統的各個組件被集成，它們的web服務需要通過分析對設置請求的回應來檢查。這在一個應用程序的敏感部分里執行測試時尤其重要，比如保險系統中的保險金確認，一些自動化web服務驗證工具（比如GreenHat Tester，SOAP UI，SOAP UI Pro等）已經存在很久了。
UI測試
UI測試是一種黑盒測試技術，本質上是測試應用程序，中間設備和基礎設施的。這些GUI測試是常見的測試，其編寫和自動化很貴。但是對于有效的交付到生產，自動進行所有系統和回歸測試極其重要。Devops的關鍵之一是要了解每一層的執行者以及上述測試周期每一階段預期的質量水平。舉個例子，仔細考慮一下下列要求：“當點擊提交，數據庫中應該建好一個條目”。事實上，在UI測試中測試這個是不可能的。然而，我們需要確保有一個單元測試能覆蓋這個場景，在這里任何失敗都可以追溯到上述任一測試中，且可以追究相應執行者（如：測試團隊，開發團隊等）的責任。
其他自動化流程
盡管上面展現了不同測試階段的自動化，開發和交付周期的一些其他流程可以自動提供靈活的DevOps團隊。
--基于新簽入代碼的自動化和按需的構建部署。
--從系統到開發者/測試員回送反饋以確定潛在的性能差錯的自動化服務器和性能控制。
--與多個系統相互連接并基于需求和要求按區域幫助分配團隊運行進程的自動化報告和批處理。
--減少對專業運維人員或巨大資金支出需要的自動化基礎設計配置和設置。
結論
DevOps的目標不僅僅是增加變化發生的速度，還要成功將這些變化部署到生產中，同時當錯誤發生時快速發現并改正。要做到這一點，需要一個特定人員或團隊負責Quality Gate將大多數測試自動化。還有，DevOps是一種工作文化，沒有敏捷、高層管理的鼓勵和開發與運維團隊間的理解無法發展壯大。但是如果正確實施的話，能夠提供長期商業利益。
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://m.eqie.com.cn/news/html/2015528142745.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
