趙輝

DBAplus社群（dbaplus)

讀完需要

20

分鐘

速讀僅需 5 分鐘

作者介紹

趙輝，前HSBC商業銀行DevOps團隊主管，DevOps專家，現任一線公有云企業DevOps平臺解決方案架構師。

當下的IT領域，持續測試是成功采用DevOps交付模式的關鍵因素。持續交付的目標，是能夠快速和持續地反饋符合客戶需求的高質量產品。

然而，理想很豐滿，現實很骨感。自從2012年，第一份DevOps報告由Alana Brown發布之后，DevOps開始逐漸獲得業界的認知。越來越多來自各領域和產業的IT團隊開始談論DevOps和數字化轉型，其中不少團隊已經根據自身對DevOps的理解采取了行動。根據哈佛商業評論的數據，在2019年大約有70%的轉型項目失敗，而失敗的原因與其DevOps落地的情況有著很強的相關性。

本文我們具體來看看，現階段持續測試是如何幫助團隊成功落地并實現DevOps轉型的。

一、避免中心化的測試團隊

傳統上來說，QA、開發和產品Owner隸屬于不同的團隊，即煙囪式的中心化團隊。當開發完成一個功能需求的開發之后，QA團隊才開始測試用例的設計，并且執行對應的測試用例，無論是手工測試還是自動化測試。當所有的測試工作結束后，產品負責人會驗收這個新開發的功能是否符合預期。通常在這種開發模式下，QA團隊或者產品Onwer的反饋已經晚了，因為代碼已經被合并到了主干，導致任何代碼的變化將造成的成本已經高出了大多數人的預期。下圖是一個傳統的中心化的團隊結構：

DevOps的核心觀念就是提供反饋，為開發團隊盡早地提供反饋機制對于實現持續集成至關重要。因此，團隊的結構應該被調整為如下圖所示：

在新的開發測試運維一體化的團隊中，QA將作為核心團隊的一部分，和開發、產品一起來創建用戶需求用例和測試用例，甚至測試用例開始的時間點，會比開發開始寫下第一行代碼的時間點更早。

二、定義測試類別

下圖是一個描述測試類別的分類圖。在現實中，很多團隊并不清楚自己對于不同的測試類型扮演什么不同的角色、承擔哪些不同的責任。

手工探索性測試（Owner Product Owners）

手工探索性測試通常是由來自業務團隊、或產品團隊的代表最終用戶的領域專家來承擔，這些專家對于產品如何在真實的生產環境中使用非常清楚和自信。手工探索性測試通常是對一些常見的場景進行具有創造性的驗證，模擬在現實中有可能會發生的場景。

UI回歸測試（Owner QA engineers）

UI測試一般會被定義為回歸測試，由QA工程師進行維護。UI自動化測試腳本的維護成本是非常高的，而且對于QA工程師的技能有比較高的要求。因為在執行UI自動化測試的成本通常高于接口測試，因此，UI自動化測試不應該被用來當做一個檢查點來確定代碼是否應該被合入。

這是因為，如果UI自動化回歸測試失敗之后，QA工程師、開發，甚至產品人員應該坐在一起，來檢查自動化回歸測試是否應該被更新。在這一點上，開發可以去做性能重構或者安全重構而不用擔心自己新的代碼會影響現有功能。

UI測試通常被設定為每天執行，用來執行UI自動化測試的編譯包通常被稱為snapshot版本或者黑夜版本。

服務接口測試（Owner Developers, QA engineers）

服務接口測試通常由開發人員，少數情況由測試人員來進行維護。開發人員需要確保自己合入主干分支的代碼能夠符合需求。通常情況下，服務接口測試的開發會早于業務代碼的開發。開發人員在開發業務代碼的時候，需要保證業務代碼的功能能夠通過服務接口測試的測試用例。

這個流程在業界被稱為測試驅動開發（TDD，Test Driven Development）。如果被合并入主干的代碼導致了服務接口測試用例的失敗，這個問題必須立刻解決。開發人員應該首先關注如何將業務代碼通過服務接口測試用例，在通過用例之后，開發人員就會對接下來代碼性能或者安全的重構不會影響業務邏輯而很有信心。

單元測試作為代碼質量的門限（Owner Developers）

單元測試應該關注單個類或者方法。需要注意的是，代碼會腐敗。開發人員應該對自己代碼的code smell（即代碼風格）承擔責任，并且遵守團隊的代碼規約。從DevOps的角度來看，代碼的單元覆蓋率應該在代碼被合并到主干分支之前被保證。

通常，一個Pull Request（PR）被創建之后，單元測試覆蓋率應該被自動化的工具檢查，并且在正式的代碼人工審查之前，保證單元覆蓋率和代碼規約質量符合團隊的規范。這么做有兩個優點，其一是強迫開發人員在代碼人工審查開始之前就注意代碼質量，其二是團隊在做人工審查的時候能夠關心真正的邏輯問題和代碼設計問題，而不是一些基本的代碼錯誤，節省整個團隊的時間。?

三、自動化測試數據管理

自動化測試數據管理是一個很大的話題，而且是實現自動化測試的重要因素。通常，測試數據管理會被與測試環境管理混為一談，但是，我個人更愿意將測試數據管理分開來談，主要有以下幾個考量。

環境管理關注部署

環境管理的目標是保證環境的一致性。這意味著我們必須保證基礎設施和配置在測試的所有環節保持一致。部署完成后，在運行測試用例時，環境不能有變化。這一點和測試數據是不同的。

在數據中心或者公有云環境下，環境的創建本身也類似于代碼的管理，自動化構建的腳本和流水線，將會獲取環境的定義，通常環境定義本身也會使用git倉庫來保存，進而觸發環境構建的流程。實例的初始化流程腳本也會從一個共享的配置管理數據庫（CMDB）中獲取配置信息來創建環境的實例。流程如下圖所示：

測試數據管理和測試用例的關聯關系

不同于環境管理，測試數據的設置和初始化需要和測試用例關聯。我們需要找出基礎數據和測試用例數據。

基礎數據，有些團隊稱之為參考數據，是一個標準的參考數據模版，用于所有的測試環境，并且獨立于測試用例。所有的測試用例都需要建立在基礎數據之上。每一次測試數據需要恢復到初始狀態時，測試人員就可以使用基礎數據覆蓋當前環境中的數據集來“恢復出廠設置”。

測試用例數據是在每一次執行測試用例之前，自動化引擎將會從測試數據管理平臺（Testing Data Management）獲取用于初始化測試數據的增量數據。執行測試用例之后，清理工作將會把產生的中間數據清理掉，并且恢復到測試用例之前的測試數據集。因此，測試數據的準備和清理都必須做到冪等。

具體流程如下圖所示：

結論

測試部分通常因為更重原因，例如成本考慮、團隊結構考慮，或者政治因素，在落地DevOps實踐中被有意或者無意地忽略。但是，實際上測試才是實現真正的持續集成和持續交付的關鍵點。請注意，持續測試不僅僅是工具和技術，更是一個流程、組織結構和思維方式。

---

?

新炬首架梁銘圖：從70萬字SRE神作提煉出7千字精華與君共勉

?

技術團隊的工程師文化：效率與價值

?

中臺是個筐，啥都往里裝？

?

微信支付軟件架構重構之旅

中生代技術社區提供內推服務，對應BAT，網易，頭條等大廠對接到用人部門，

有需求請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #接力技術，鏈接價值#

總結

以上是生活随笔為你收集整理的DevOps落地成不成，关键不在持续集成？的全部內容，希望文章能夠幫你解決所遇到的問題。

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