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