摘自PM圈子網—專案經理牛人聚集地

測試是DevOps轉換的核心，如果DevOps是關於團隊文化之間的差距，那麼測試就是一個分界點，這是Dev和Ops團隊的共同特徵。

隨著新技術和特性進入到應用程式的體系結構，在應用堆疊的各個級別都需要進行變革，比如程式碼重構、確保功能向後相容、重新訪問過去的核心設計決策，以及更改服務和資料模型。

DevOps是關於文化的，它需要一個健壯的測試實踐和文化的改變，下面，我們就來看看可以追求的文化改變，以便更好地進行測試實踐。

平衡速度和質量

每個DevOps轉換的承購是以實現當前設定的工作方式開始，釋出是高壓力的事件，充滿不可預測的失敗，結果是創新慢下來，一旦你決定要解決問題的根源，DevOps就變成了一個明確的解決方案，更快的釋出是組織採用DevOps的關鍵原因。

然而，通過關注開發管道，需要考慮整個產品生命週期的每一步，以實現更快的釋出——只有這樣才能有質量和可靠性，當在應用程式中限制新特性的數量和特性的複雜性時，這些特定需要在真實環境下持續使用，在如今支離破碎的移動生態系統中，實現這一目標更加困難。

致力於自動化

自動化是實現跨管道速度的關鍵，每個團隊開發人員，測試和Ops都需要致力於儘可能地自動化，這意味著每個人的實際情況會有所不同，但這一承諾對於真正的工作來說是必要的，對於Dev來說，使用Jenkins構建自動化是自動化的第一步，同樣，對於測試來說，自動化單元測試也是起點，對於Ops來說，能夠根據模板建立和配置不同的環境是它開始的地方，自動化減少了手工錯誤，並將質量引入到流程的每一步中。

從觸發-響應模型的角度考慮自動化是很重要的，在SDLC中，可以使用各種事件作為觸發器來啟動一個或多個響應，比如，每當開發人員提交程式碼時，該事件就充當Jenkins的觸發器，以自動編譯和構建程式碼，作為下一步，Jenkins可以整合測試工具來發起自動化單元測試，此外，在真實裝置上的功能測試可以使用裝置雲實現自動化。

這樣，團隊就可以毫不費力地得到流程的各個步驟的反饋，並且可以在更高價值的任務上花費更多的時間，但最重要的是，自動化帶來了一種速度，如果人類手動執行相同的任務，是不可能的，想象一下，每週購買一臺新的Android裝置，或者在每次測試執行前手動配置每一個裝置又或確保所有裝置都執行最新版本的作業系統和支援應用程式，自動化或將這些管道任務解除安裝到供應商可以在任何規模上帶來速度和質量。

自動化的另一個機會是使用模板來簡化環境的建立，如果您使用AWS進行基礎設施，這意味著使用如何CloudFormation這樣的工具，可以基於以前的配置或自行建立的模板來建立生產就緒的環境，將生產環境模擬為測試的目的是一項挑戰，但通過對流程進行模板化，它就變得可管理，併為您提供更可靠的測試結果。

利用監控告警

在微服務應用程式中事情會進展的很快，而且經常中斷，如果在一個穩定的未過濾的流中檢視警報的數量會變得勢不可擋，解決方案是使用一個路由邏輯，確保每個人和團隊看到與他們工作相關的告警，當它們被用作自動化的觸發器時，警報變得更有價值，例如，對於一個失敗的服務的告警可以被用來自動在Jira中建立，通知相關的團隊讓每個人進行相應的處理。

關注全域性

當自動化整個SDLC時，優化流程的每個部分會帶來更大的速度，但是要將這個過程變得更高，應該考慮全域性，隨著自動化的成熟，需要考慮如何做出影響整個管道的更改，如Spinnaker這樣的工具，由Netflix建立，AWS程式碼管道可以讓使用者以檢視的方式進行。

從整體上看，這條管道可以幫助致力於實現自動化的所有人員，這不僅僅丟擲了一些新工具，更深入地考慮這些工具支援的過程，更深層的是，它著眼於團隊如何一起工作，以及他們使用的工具和過程是否受到限制或授權。跨開發、測試和運維的自動化文化對於實現DevOps轉換承諾的速度至關重要。

總結

“質量”在SDLC中構建的每一步驟都是非常重要的，它需要來自每個團隊的努力，並要求實現對自動化的承諾，需要知道的是，當自動化是一件不僅要減少投入而且要加快速度、提高質量的時候，那麼你就在正確的軌道上，當接受自動化的文化時，它必然會改變測試的工作，並導致高質量的應用程式被傳送的更快。