Docker引領測試革新

1.傳統軟件開發流程的痛點

在傳統軟件開發流程中，開發團隊在完成功能代碼編寫後，會首先進行自測，以後將代碼提交到Git倉庫中。在每一次迭代轉測試時，開發團隊會首先構建轉測試的二進制文件，以後由測試團隊對版本進行驗證，驗證經過後會將版本提交給運維團隊。以後再由運維團隊將產品發佈件部署到運維服務器中以提供給客戶使用。

在這個流程中會有以下痛點：

(1)開發、測試和運維環境不統一。

這致使了有些本該在開發階段發現的軟件缺陷可能會遺漏到測試或運維階段才能發現。有時發佈件在開發環境中運行的很穩定，而在運維環境中剛剛運行就掛掉了。這時運維團隊不得不找開發團隊來救火，致使了整個團隊工做效率降低。

(2)沒法準確獲取客戶的軟件環境。

咱們每每不能直接復現客戶報的軟件缺陷，不得不去客戶現場進行調試，滯後瞭解決問題的時間。

(3)開發者在提交代碼前每每未作充分的測試。

開發自驗工做取決於開發者的責任心，而沒有一種機制來保證自驗工做的進行。致使了不少低級的軟件缺陷遺漏到測試和運維團隊。

(4)開發團隊沒法復現測試團隊報出的軟件缺陷，致使兩個團隊出現相互推諉的現象。

(5)配置測試環境的時間較長，測試自動化成本高。

傳統環境每每使用虛擬機，而其消耗資源高、部署速度慢，致使自動化的效率不高。

2.當前測試技術面臨的挑戰

主要的挑戰以下所示：

(1)配置一致的測試環境。

(2)快速部署軟件。

(3)並行執行測試，在並行的同時還需確保測試任務各自的環境不被污染。

(4)成功的復現軟件缺陷。

(5)建立清潔的測試環境。

(6)正確配置測試工具。同一個工具須要適配到不一樣的linux發行版中。

(7)快速部署多個測試主機。

(8)快速導入測試數據。

(9)快速清理測試環境。

(10)快速保留、複製、恢復測試環境。

3.Docker對測試技術的革命性影響

(1)更早的發現單元測試中的軟件缺陷。

測試驅動開發是軟件工程中一個具備里程碑意義的創新，即開發者在提交開發代碼的同時也要提供對應的測試代碼，在代碼提交後系統會自動進行一輪自動化測試。經過Docker能夠快速部署測試環境，能夠有力的支撐自動化測試，從而確保在第一時間發現單元測試中的軟件缺陷。

(2)爲功能測試和集成測試提供清潔的測試環境。

不少公司因爲成本問題，不得不在一個虛擬機中運行不一樣類型的測試任務。而這些任務在運行時每每會致使環境污染。經過Docker技術的隔離性，能夠有效地解決測試環境的污染問題。

(3)讓測試團隊和客戶丟掉冗長的配置文檔。

開發轉測試時每每帶有較長的環境部署文檔，而在這些文檔中每每存在部署過程跳步的問題，測試團隊很難一次準確的將環境部署成功。而如今能夠經過Docker鏡像將配置環境的過程簡化，測試團隊省去了查閱文檔的過程，只須要基於開發團隊提供的Docker鏡像就能夠輕鬆的配置測試環境。

(4)便於復現客戶報告的軟件缺陷。

當客戶使用軟件發現缺陷時，能夠將其所使用的環境打包成鏡像提供給開發團隊。開發團隊經過鏡像便可獲取與客戶一致的軟件環境。

(5)經過Dockerfile能夠梳理好測試鏡像製做的流程。

若是流程步驟須要微調時(如將安裝gcc3.4改成安裝gcc4.3)，能夠將Dockerfile中對應的信息進行修改並從新建立新的鏡像，沒必要手動從新配置運行環境。

(6)能夠將成熟的測試套或測試工具經過鏡像共享。

這樣能夠支持軟件在不一樣linux發行版中成功的運行，軟件提供商能夠將主要精力放在完善功能上，沒必要投入過多時間將軟件適配到不一樣的linux發行版中。

(7)利用Docker生態中的工具能夠快速建立可伸縮的測試環境，大大減小了測試所消耗的時間。

能夠在短期內快速集中資源來完成一項測試任務，在任務完成後又能夠快速的對資源 進行回收，有利於提高資源使用效率。

(8)優越的性能指標。

經過優於虛擬機的性能，Docker能夠提高測試效率。經過「-v」選項能夠將主機的目錄快速映射到容器中，能夠實現測試文件的快速共享。經過「--rm」選項能夠在測試完成後第一時間刪除容器，以便釋放系統資源。

(9)輕鬆的恢復測試環境（包括內存）-CRIU技術 Checkpoint Restore In Userspace

結合CRIU技術，能夠實現容器運行狀態的保存，這項技術也是容器熱遷移的基礎。

4.DevOps與Docker

DevOps一詞的來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合做，經過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。

在DevOps出現以前，軟件通過開發、測試後由運維團隊將發佈件部署到公司的基礎設施上，並將服務提供給客戶使用。然而，開發、測試、運維三個團隊缺乏有效協同工做的機制，致使部門牆嚴重。開發團隊每每關注新功能開發和快速迭代，而運維團隊關注的是發佈件的穩定性，他們不但願版本頻繁的更替。每每在這兩個團隊間會爆發激烈的鬥爭。

在DevOps出現以後，團隊經過協做和自動化的方式打通了開發、測試、運維團隊之間的壁壘。當有新的代碼提交時，系統在第一時間會觸發自動化測試，依次在開發自驗環境、測試環境、運維環境中驗證軟件，確保能夠第一時間發現軟件缺陷。然而，當出現業務峯值時，傳統的基礎設施中的虛擬機就沒法有效的應對了。

在後Devops時代，隨着雲計算的普及，不少雲平臺提供了應用引擎，若是你的應用符合引擎的規範，雲平臺就能夠自動檢測業務負載量。當業務出現峯值時，平臺能夠利用底層容器技術的快速部署、資源快速擴展伸縮等特性來應對，從而有效的支撐了業務的正常運行。

5.Docker與自動化測試

對於重複枯燥的手動測試任務，能夠考慮將其進行自動化改造。自動化的成本在於自動化程序的編寫和維護，而收益在於節省了手動執行用例的時間。簡而言之，若是收益大於成本，測試任務就有價值自動化，不然受益的只是測試人員的自動化技能獲得了提高。利用Docker的快速部署、環境共享等特性，能夠大大減小自動化的成本，使不少本來沒有價值自動化的測試任務變爲了有價值自動化的任務，大大提高了項目效率。

那麼若是自動化測試已經運行在了虛擬機中，是否有必要使用Docker技術將其進行改造？這個就要具體問題具體分析了。筆者並不贊同將全部測試任務一刀切的進行容器化改造。若是當前虛擬機已經知足測試需求，你就須要評估一下引入Docker進行改造所需的成本，其中包含學習Docker技術所須要的時間成本。反之，若是虛擬機沒法知足當前的測試需求，能夠考慮儘快引入Docker進行改造。

6.Docker的約束

Build, Ship, and Run Any App, Anywhere.這是Docker公司高調宣稱的口號，即在任何平臺均可以構建、部署、運行任何應用。然而，因爲Docker自身的特色，其使用場景有一些約束：

(1)由於容器與主機共享內核，若是容器中應用須要不一樣的內核版本，就不得不更換主機內核。但若是主機內核變動後又會影響到其它容器的運行。變通的方法是將應用源碼的編寫與內核特性解耦。

(2)Docker使用時須要3.10或以上版本的內核，這是最低的限制。若是你須要使用更高級的Docker特性，如user namespace，那麼還須要更高版本的內核。

(3)使用「--privileged」選項後能夠在容器內加載或卸載內核模塊，但這個操做會影響到主機和其它容器。

(4)沒法模擬不一樣平臺的運行環境，例如不能在x86系統中啓動arm64的容器。

(5)由於Docker採用了namespace的方案來實現隔離，而這種隔離屬於軟件隔離，安全性不高。不適合安全性高的測試任務。

(6)由於目前沒有time namespace技術，修改某個容器時間時就不得不影響到主機和其它容器。

7.適用於Docker的測試場景

因爲容器與主機共享內核使用，凡是和內核無強相關的測試任務是適合引入Docker進行改造的，例如源碼編譯測試、軟件安裝測試、互聯網應用測試、數據庫測試等。而與內核強相關的測試任務是不適合使用Docker進行改造的，如內核網絡模塊測試、內核namespace特性測試等。

8.Docker測試實踐

8.1.容器化編譯系統測試

早期咱們將linux發行版安裝到物理機中進行測試。當須要從新進行全量測試時不得不手動還原測試環境。以後改用了虛擬機，雖然可以經過自動化的方式實現環境還原，但虛擬機的損耗較大，效率不高。

以後咱們嘗試將環境製做成Docker鏡像，同時進行了以下的改進：

(1)經過Docker的「-v」選項，將主機目錄映射到容器中，實現多個容器共享測試代碼。測試代碼部署時間從2分鐘減小到10秒。

(2)將大粒度的執行時間較長的用例拆分紅爲若干個小用例。

(3)利用容器併發執行測試。

(4)使用Dockerfile梳理產品依賴包和編譯軟件的安裝。

編譯系統測試是用戶態的測試，很是適合使用Docker進行加速。若是須要針對某一個linux發行版進行測試，能夠經過Docker快速部署的特色，將全部的資源快速利用起來，從而達到加速測試執行的目的。

8.2.linux外圍包測試

外圍包包含動態連接庫文件和經常使用的命令行工具，屬於linux操做系統的中間層，其上運行着應用程序，其下由linux內核支撐。起初的外圍包測試採用串行執行，效率不高。同時受到環境污染的影響，容易產生軟件缺陷的誤報。在改進方面，咱們首先經過Dockerfile基於rootfs製做一個Docker鏡像，而後經過Docker-compose工具實現測試用例的併發執行。

如下是改進先後的對比。

改進前	改進後
每套環境獨佔一臺主機，主機利用率不高。	多套環境能夠在同一主機上部署，能夠更有效利用主機資源。特別是在主機資源昂貴的狀況下，能夠節省不少成本。
測試串行執行，由於環境污染問題測試任務不易併發。	經過Docker進行測試任務隔離，能夠並行執行測試，提升了cpu利用率。
環境釋放時清理工做依賴於程序員的技能。在每一個測試用例中有一個cleanup函數，負責資源回收和環境恢復。若是程序員編程技巧不高的話，可能會形成資源回收不完全，測試環境會受到污染。	環境釋放時清理工做由Docker接管，當執行完任務後，能夠刪除容器。即便不寫cleanup函數，也能夠實現資源的回收。
沒法解決多個外圍包的環境污染問題。當連續執行多個測試時，有部分測試沒法經過，而單獨執行這些測試時又可以經過。這一般是因爲測試環境污染形成的。	容器可快速啓動與關閉，每次都是清潔的環境。
外圍包編譯環境不易統一，致使測試結果不一致。	經過鏡像保存編譯環境，確保環境統一。
測試網絡包時須要至少兩臺主機，分別部署服務端和客戶端。	測試網絡包時只須要在同一臺主機中啓動兩個容器來部署服務端和客戶端。

9.經過Docker進行測試加速的原理

Docker自己並不會直接加速測試執行。在串行執行測試時，在容器中執行測試反而會帶來約5%左右的性能衰減。但咱們能夠充分利用Docker快速部署、環境共享等特性，同時配合容器雲來快速提供所需的測試資源，以應對測試任務的峯值。若是忽略環境部署時間，當每一個測試用例粒度無限小而且提供的測試資源無限多時，測試執行所需的時間也就無限小。

10.總結

不少測試任務能夠利用Docker進行改造，讀者能夠根據項目自身的特色，因地制宜的使用Docker進行測試能力的改造。若是想進一步瞭解容器雲，能夠參考《網易雲的實踐之路：談談容器雲的機會與挑戰》這篇文章。

本文地址：http://www.linuxprobe.com/docker-change-test.html