測試工程能力容器化改造方案

隨著容器時代的到來，開源社區中誕生了以Docker、Rocket為代表的優秀的容器引擎方案。本文旨在介紹通過容器技術對不同測試類型（應用層測試、中間層測試、內核測試、硬件驅動測試、編譯測試）進行容器化改造的方案和收益，并通過具體實例的方式來展示容器化時代為軟件測試帶來的機遇。

1.測試工程能力容器化技術沙盤

容器時代為云產業帶來了前所未有的機遇，容器云平臺如雨后春筍般的出現在大家的視野中。大部分容器云都提供了代碼托管、鏡像存儲、編譯、測試、打包、運維等功能。容器云中的容器通常配置有一致的內核，相近的硬件資源。

很多的軟件測試任務可以通過容器云進行改進或加速。然而，還有一些類型的測試任務不適用容器云。需要說明的是容器云和容器是兩個概念。不適用容器云的業務并不代表不能使用容器對軟件測試業務進行改造。

以下沙盤覆蓋服務器操作系統、虛擬化、實時操作系統、Web終端、Linux內核、互聯網服務、安全測試業務，同時對各業務以測試工具、源碼編譯、應用層、中間層、內核、硬件為基準進行分層。綠色表示該業務適用容器云；黃色表示需要根據具體場景來確定是否適用于容器云；紅色表示該業務不適用容器云。我們將在接下來的章節中討論各業務的容器化改造方案。

2.各測試類型容器化方案

以下列舉了分層中的典型業務的容器化改造方案，某些方案可以在不同的業務中拉通。讀者可以根據自己的實際場景有針對性的規劃適合自身業務的容器化改造方案。

2.1.測試工具容器化

容器云作為一個輕量級的容器虛擬化平臺，可以集成各類工具，如持續集成、大數據等方面的工具，方便用戶進行各類服務的部署。使用容器化來改造測試工具，主要有兩點好處：

• Docker能將測試工具放在一個干凈的容器環境中，并且不會影響到Guest文件系統；

• Docker鏡像可以賦予系統管理員跨Windows、Mac和Linux服務器的簡化管理能力，當服務端為Linux服務器時，客戶端可以是Windows、Mac或Linux架構，這樣會實現更快速的部署和管理。不過需要注意的是，除非使用虛擬機，Windows的Docker鏡像是無法在Linux系統中啟動成功的。

現在許多主流的測試工具已經推出官方的Docker鏡像，比如滲透測試領域的Kali，持續集成的工具Jenkins等，同樣還有很多未被容器化的測試工具，讀者可根據需要自行進行容器化改造嘗試，相信隨著Saas和Caas的普及，會涌現出更多的容器云化測試工具。

2.2.源碼編譯測試容器化

源碼編譯測試是運行在用戶態中的程序，屬于CPU密集型的測試任務。其執行測試所需時間與系統資源成反比。容器云是以時間和資源使用量為基準收費的。可以通過Docker快速部署、快速伸縮的特點，在短時間內獲取容器云中大量系統資源支撐測試執行以達到測試加速的目的。在測試執行完之后，可快速釋放所占資源，減少測試成本。同時可以在Dockerfile中梳理編譯依賴包（如gcc）和編譯軟件的安裝，使得環境準備的步驟更加清晰。

2.3.應用層軟件測試容器化

應用程序屬于最上層的軟件，非常適合容器化改造。可參考以下幾個方面進行改造。

(1)將Docker和Devops結合起來使用，統一開發、測試、運維環境，打通全流程自動化任務。

(2)利用容器云中Docker可擴展可伸縮的特性加速測試執行或者模擬多個終端用戶來進行測試。

Selenium是針對Web應用的自動化測試工具，其支持多種瀏覽器。通過Selenium可以模擬用戶在瀏覽器中的操作。

Selenium Grid是一個分布式Web測試工具，可以將測試任務分發到多個主機上并行執行測試。Selenium Grid架構中包含兩個主要角色：Hub是中心點控制節點，而Node是Selenium的工作節點，它們注冊到Hub上，并會操作瀏覽器執行由Hub下發的自動化測試用例。在傳統的部署方式中，一個瀏覽器在操作系統上只能安裝一個版本且只能有一個運行實例。為了針對不同版本的Chrome進行測試，需要將指定版本的Chrome瀏覽器安裝到不同物理機或虛擬機上。這種部署方法耗費資源多，部署時間長。

通過容器云快速伸縮、環境隔離等特性能夠快速啟動多個容器并行進行不同瀏覽器版本的測試，可以有效的減少物料消耗和節約測試時間。

(3)利用容器隔離性和快速環境清理的特性，并行執行軟件兼容性測試(如安裝不同版本的數據庫)。

(4)通過容器模擬測試執行需要的外部環境。可將一些典型的測試場景進行容器化處理，將鏡像存儲到鏡像倉庫中。可以通過docker-compose以微服務的方式部署這些測試場景，便于其他團隊復用已有的測試場景。

(5)如想在容器云中運行與內核相關的應用，可將應用程序進行內核特性解耦，將內核模塊對應的部分代碼移植到應用程序中。

2.4.中間層軟件測試容器化

Linux外圍包（通常是rpm或deb包）是操作系統的中間層，絕大部分外圍包與內核無強依賴，是適合使用容器云進行加速的。因為在容器云中無法自定義內核，所以與內核相關性強的外圍包的測試是不適合使用容器云加速的。對于這類測試，讀者可以搭建可定制內核的私有云來實現測試加速。

除此之外，還有兩個特例需要說明一下。

(1)grub包:grub是多系統啟動規范的實現，它允許用戶可以在計算機內同時擁有多個操作系統，并在計算機啟動時選擇希望運行的操作系統。因為與主機啟動強相關，所以不適用容器加速。

(2)ntp包:ntp是網絡時間協議(Network Time Protocol)，它是用來同步網絡中各個計算機的時間的協議。因為當前內核不支持time namespace，即容器與主機間、容器與容器間不能使用不同的時間（注意是時間不是時區）。而更改容器時間就不得不更改主機時間，這樣就無法構建具有不同時間的測試環境。如果使用不同主機中的容器來規避該問題，雖然可以構建對應的測試環境，但又無法有效利用容器快速部署、執行帶來的收益，相當于為了使用容器而使用容器，沒有實際意義。

2.5.內核測試容器化

Ltp測試套中包含了最全面的內核功能測試用例集。該測試套的調度程序是串行執行測試用例的。可以通過如下幾個方面對內核測試進行容器化改造。

(1)啟動多個容器并發執行內核功能測試來提高cpu負載，以便減少測試執行時間。然而，內核測試的容器化會有一定的局限性。這主要體現在：

A.在容器內執行內核測試時會有部分用例執行失敗。例如， pidns32測試用例 是用來測試namespace的最大嵌套深度，因為啟動容器時已經默認嵌套了一層namespace，當在容器中執行用例時其還會嘗試最大嵌套，這就導致了測試用例執行不通過。對于此類用例，我們需要對其進行容器化適配，設定在容器內可嵌套的層數要比主機上少一層。

B.某些內核測試項是排他的，需要單獨運行，這部分測試需要進行額外的操作處理，比如一些中斷操作、寄存器操作。

C.內核性能測試的執行不適用容器化，否則會有失真。

(2)可以在容器內搭建內核測試環境。Ltp測試套中的測試用例源碼默認是被動態編譯的，其運行需要一些動態鏈接庫。而很多系統特別是嵌入式系統往往缺少這些動態鏈接庫，導致部分內核測試用例無法執行。可將必要的動態庫集成到Docker鏡像中，這樣既保證了測試用例可以順利執行，又可以避免在主機中直接安裝庫文件造成的環境污染。

(3)使用Docker構建內核集成測試場景。因為內核是底層技術，很難找到一個能夠包含多個內核特性的集成測試場景。通過以下Docker命令可以輕松搭建namespace、cgroup、capability、seccomp等內核特性的集成測試場景。

$ docker run --memory 20m --cap-add sys_admin --security-opt seccomp=unconfined --userns-remap default ubuntu:14.04 bash

2.6.硬件驅動測試容器化

Docker的設計初衷是來屏蔽各硬件平臺差異的。因此利用Docker來改進硬件驅動測試的難度較大。慶幸的是Docker利用內核的device cgroup特性可以實現設備直通的功能，可將主機中的設備映射到容器中進行測試。

收益：測試環境不會污染主機環境；便于設備驅動并行測試；即使主機文件系統缺少測試所需的庫文件，仍然可以使用容器的文件系統中的工具來輔助測試。

例子：串口測試

$ docker run -device /dev/console:/dev/console ${your_image} ${your_test_script}

2.7.壓力穩定性測試容器化

有一句行話叫做“無壓力不測試”，意思是說很多軟件在無壓力環境中是運行正常的，但當系統持續加壓時，軟件可能會暴露出很多穩定性和容錯性方面的問題。因此在多個領域的測試中，都會在集成測試或者系統測試階段開展長時間壓力穩定性測試。服務器操作系統、虛擬化與linux內核等業務中傳統的長穩測試框架均存在以下痛點：

(1)部署工作復雜。

加壓測試套編譯與運行有很強的平臺依賴性，當測試涉及多平臺復雜組網時，會出現很多兼容性問題。系統巡檢工具的安裝依賴包多，需要人工進行各個版本依賴包的適配工作。一套完整的長穩測試框架的部署（包括背景加壓、系統巡檢與用例執行）會耗費大量人力，影響了測試效率。

(2)加壓模型單一。

(3)容錯能力差。

當系統中因為誤操作或者資源競爭導致加壓或巡檢進程異常退出時，系統不具備任何應急處理能力。

基于以上痛點，我們對該項測試進行了容器化改造的實踐。首先是背景加壓容器化，將cpu、內存、io的測試套打包成Docker鏡像，以cpu加壓為例，可以運行下面的命令來對系統進行cpu加壓：

$ docker run -tid -m 3g --restart=always back_stress bash -c "bash cpu_stress/test_20.sh

這樣完全可以解決編譯安裝時間長與平臺化差異所帶來的影響，-m 3g --restart=always增強了加壓框架的容錯性，限制了加壓容器最大使用的內存量，可以避免因加壓程序導致系統垮掉的問題（如加壓程序有內存泄露時，當容器試圖使用超過限定內存時會觸發oom，在restart規則下容器所占資源會被清理同時容器會快速重啟并持續進行加壓）。test_20.sh明確了加壓程度為20%，可以通過增加容器的數量來實現加壓強度的疊加，常見的加壓模型如上圖所示。

(點擊放大圖像)

其次，我們實現了系統巡檢的容器化。將Zabbix巡檢工具的server端與agent端均打包為鏡像，在多平臺組網復雜的環境中，可以完全屏蔽平臺化差異，通過對應鏡像可以一鍵拉起巡檢容器，只需要在web端進行配置即可實現長穩環境的系統巡檢。

3.總結

本文針對不同的測試場景，列舉了容器化改造方案。讀者在針對實際的測試場景進行容器化改造時，不必拘泥于本文的理論和方法，可因地制宜的制定有效的容器化改造策略。

 

來自：http://www.infoq.com/cn/articles/test-engineering-capacity-container-transformation-scheme