Docker 與自動化測試
對於重複枯燥的手動測試任務，可以考慮將其進行自動化改造。自動化的成本在於自動化程序的編寫和維護，而收益在於節省了手動執行用例的時間。簡而言之，如果收益大於成本，測試任務就有價值自動化，否則受益的只是測試人員的自動化技能得到了提升。利用 Docker 的快速部署、環境共享等特性，可以大大減少自動化的成本，使很多原本沒有價值自動化的測試任務變爲了有價值自動化的任務，大大提升了項目效率。
那麼如果自動化測試已經運行在了虛擬機中，是否有必要使用 Docker 技術將其進行改造？這個就要具體問題具體分析了。筆者並不贊同將所有測試任務一刀切的進行容器化改造。如果當前虛擬機已經滿足測試需求，你就需要評估一下引入 Docker 進行改造所需的成本，其中包含學習 Docker 技術所需要的時間成本。反之，如果虛擬機無法滿足當前的測試需求，可以考慮儘快引入 Docker 進行改造。
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 技術，修改某個容器時間時就不得不影響到主機和其它容器。
適用於 Docker 的測試場景
由於容器與主機共享內核使用，凡是和內核無強相關的測試任務是適合引入 Docker 進行改造的，例如源碼編譯測試、軟件安裝測試、互聯網應用測試、數據庫測試等。而與內核強相關的測試任務是不適合使用 Docker 進行改造的，如內核網絡模塊測試、內核 namespace 特性測試等。
Docker 測試實踐
容器化編譯系統測試
早期我們將 linux 發行版安裝到物理機中進行測試。當需要重新進行全量測試時不得不手動還原測試環境。之後改用了虛擬機，雖然能夠通過自動化的方式實現環境還原，但虛擬機的損耗較大，效率不高。
如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
之後我們嘗試將環境製作成 Docker 鏡像，同時進行了如下的改進：
(1) 通過 Docker 的“-v”選項，將主機目錄映射到容器中，實現多個容器共享測試代碼。測試代碼部署時間從 2 分鐘減少到 10 秒。
(2) 將大粒度的執行時間較長的用例拆分成爲若干個小用例。
(3) 利用容器併發執行測試。
(4) 使用 Dockerfile 梳理產品依賴包和編譯軟件的安裝。
編譯系統測試是用戶態的測試，非常適合使用 Docker 進行加速。如果需要針對某一個 linux 發行版進行測試，可以通過 Docker 快速部署的特點，將所有的資源快速利用起來，從而達到加速測試執行的目的。
linux 外圍包測試
外圍包包含動態鏈接庫文件和常用的命令行工具，屬於 linux 操作系統的中間層，其上運行着應用程序，其下由 linux 內核支撐。起初的外圍包測試採用串行執行，效率不高。同時受到環境污染的影響，容易產生軟件缺陷的誤報。在改進方面，我們首先通過 Dockerfile 基於 rootfs 製作一個 Docker 鏡像，然後通過 Docker-compose 工具實現測試用例的併發執行。
以下是改進前後的對比。
通過 Docker 進行測試加速的原理
Docker 本身並不會直接加速測試執行。在串行執行測試時，在容器中執行測試反而會帶來約 5% 左右的性能衰減。但我們可以充分利用 Docker 快速部署、環境共享等特性，同時配合容器雲來快速提供所需的測試資源，以應對測試任務的峯值。如果忽略環境部署時間，當每個測試用例粒度無限小並且提供的測試資源無限多時，測試執行所需的時間也就無限小。