最近在搭建測試環境，因平臺的項目較多，而且每次war都會不定時的更新，在次搭建使用，硬件環境也不是很充足，采用較為笨重的方法：安裝虛擬機->操作系統-->中間件服務器->db->最後在服務器部署war。。。開發團隊在完成功能代碼編寫後，會首先進行自測，之後將代碼提交到Git倉庫中。在每一次叠代轉測試時，開發團隊會首先構建轉測試的二進制文件，之後由測試團隊對版本進行驗證，驗證通過後會將版本提交給運維團隊。之後再由運維團隊將產品發布件部署到運維服務器中以提供給客戶使用。。。。每次都很繁瑣。切有些問題重復性易難復現，最重要是測試環境與預生產環境有時候偏差太多。導致很多隱藏性問題沒有挖掘出來。果斷采用了Docker測試技術

這裏標記一些較好的學習網址，用作參考：

Docker中文操作手冊：http://www.docker.org.cn/book/docker/what-is-docker-16.html

InfoQ上面有系列的文章：

深入淺出Docker在InfoQ上的內容: http://www.infoq.com/cn/dockerdeep/

深入淺出Docker（一）：Docker核心技術預覽：http://www.infoq.com/cn/dockerdeep/
深入淺出Docker（二）：Docker命令行探秘：http://www.infoq.com/cn/articles/docker-command-line-quest
深入淺出Docker（三）：Docker開源之路：http://www.infoq.com/cn/articles/docker-open-source-road
深入淺出Docker（四）：Docker的集成測試部署之道：http://www.infoq.com/cn/articles/docker-integrated-test-and-deployment
深入淺出Docker（五）：基於Fig搭建開發環境：http://www.infoq.com/cn/articles/docker-build-development-environment-based-on-fig
深入淺出Docker（六）：像谷歌一樣部署你的應用：http://www.infoq.com/cn/articles/deploy-your-application-like-google

Docker源碼分析（一）：Docker架構：http://www.infoq.com/cn/articles/docker-source-code-analysis-part1
Docker源碼分析（二）：Docker Client創建與命令執行：http://www.infoq.com/cn/articles/docker-source-code-analysis-part2
Docker源碼分析（四）：Docker Daemon之NewDaemon實現：http://www.infoq.com/cn/articles/docker-source-code-analysis-part4
Docker源碼分析（五）：Docker Server的創建：http://www.infoq.com/cn/articles/docker-source-code-analysis-part5
Docker源碼分析（六）：Docker Daemon網絡：http://www.infoq.com/cn/articles/docker-source-code-analysis-part6

《Docker從入門到實踐》– 標準化開發測試和生產環境

http://wiki.jikexueyuan.com/project/docker-technology-and-combat/environment.html

構建基於 Docker + Jenkins + Sahi 的 Web UI 自動化測試環境

http://www.ibm.com/developerworks/cn/opensource/os-cn-JenkinsDockerSahi/index.html

利用 Docker 構建高度集成化的 Chef 開發測試環境

http://www.ibm.com/developerworks/cn/cloud/library/1410_zhangyq_dockerwithchef/

深入淺出Docker（四）：Docker的集成測試部署之道

http://www.infoq.com/cn/articles/docker-integrated-test-and-deployment/

Move fast and don’t break things! Testingwith Jenkins, Ansible and Docker

https://developer.rackspace.com/blog/move-fast-and-dont-break-things-testing-with-jenkins-ansible-and-docker/

Testing Made Awesome with Docker

http://blogs.plos.org/tech/testing-made-awesome-with-docker/

Container Technology: Integration Testingwith Docker

http://clypd.com/container-technology-integration-testing-with-docker/

ECS Docker實踐文檔

http://help.aliyun.com/knowledge_detail/5974866.html

docker安裝測試和使用：http://blog.csdn.net/san1156/article/details/76038287

<!---------------Docker：-------------------------------------------------------------------------->

1、什麽是Docker

百度百科：https://baike.baidu.com/item/Docker/13344470?fr=aladdin 是這樣解釋的：

Docker是一個開源的引擎，可以輕松的為任何應用創建一個輕量級的、可移植的、自給自足的容器。開發者在筆記本上編譯測試通過的容器可以批量地在生產環境中部署，包括VMs（虛擬機）、bare metal、OpenStack 集群和其他的基礎應用平臺

docker有很多的優勢，要詳細說明要很多時間，我就列一下我們主要關註的幾點：

• 節省資源：我們知道容器技術節省資源就在於它並不是一個完整的操作系統，所有的容器都是共享主機內核的。你可以理解為它直接將主機的rootfs掛載到容器內。這是為什麽我們能支持那麽多套測試環境的原因之一。
• 用完既刪：容器的啟動和刪除都是極其簡單快速的，秒級啟動和秒級刪除。這樣我們可以使用一種模式，就是那些並不需要持續提供服務的容器可以在使用完就刪除掉，等到再使用的時候現場啟動就好。 舉個例子，我們可以並發N個編譯容器完成任務立即就可以銷毀。而虛擬機的方案需要一直存在若幹臺編譯機提供服務。這也是docker節省資源的一個原因
• 遷移方便：java圈有一句話叫一次編譯到處執行。那docker圈裏也有類似的一句話。鏡像一次制作，到處執行。所以你可以隨意的刪除和擴展我們的測試環境。而且這些環境絕對是標準化的。他們沒有任何不同。 我們可以很簡單的把環境從一臺機器遷移到另一臺上。也可以很快速的從10個環境擴展到100個。
• swarm，kubernetes，Mesos多個成熟的開源分布式管理框架任君選擇。
• 簡化運維成本。 舉個例子：我們的產品使用mariadb，而我這個不知道幾手的運維在當時根本不知道怎麽搭一個mariadb出來。所以幹脆從docker hub上下載一個官方鏡像直接啟動，整個過程不超過5分鐘。 搭建testlink的時候也一樣，下載mysql和testlink鏡像以後，配置一下就可以用了。可以說docker生態圈的出現讓普通的QA也能own整個的測試環境管理成為了可能。

我們可以用Docker做什麽?

• 日常測試環境： 這是最主要的容器。我們把測試環境都放在容器裏。
• 基礎服務：testlink,jira,wiki,jenkins等基礎設施
• 測試執行環境：就拿我剛才說的UI自動化的例子，我們想分布式執行用例來提高運行速度。但我們以往並沒有足夠的機器來做這件事。那現在我分別下載了grid-hub和chrome-node的鏡像。啟動多個測試節點還是很容易的。像我剛才說的，docker比虛擬機要節省很多的資源。所以我們能夠比以前啟動更多的測試節點

就如上面的圖一樣，我們把所有我們想要的服務都放到容器裏。 也一如一開始我們說的那個logo。 docker這條鯨魚承載著很多的集裝箱，集裝箱裏就是我們的服務。 那麽我們的問題來了，我們如何跟這些集裝箱中的服務通信呢？ 我們知道容器並不是虛擬機，我們不能像以前一樣做了。所以我們先介紹一下網絡的玩法。

網絡的玩法、測試環境玩法、測試機器玩法、存儲玩法、集群 https://testerhome.com/topics/8229

<!---------------Docker應用的測試領域：-------------------------------------------------------------------------->

1、Docker目前有以下應用場景：

測試：Docker很適合用於測試發布，將 Docker 封裝後可以直接提供給測試人員進行運行，不再需要測試人員與運維、開發進行配合，進行環境搭建與部署。

測試數據分離：在測試中，經常由於測試場景變換，需要修改依賴的數據庫數據或者清空變動 memcache、Redis 中的緩存數據。Docker 相較於傳統的虛擬機，更輕量與方便。可以很容易的將這些數據分離到不同的鏡像中，根據不同需要隨時進行切換。

開發：開發人員共同使用同一個 Docker 鏡像，同時修改的源代碼都被掛載到本地磁盤。不再因為環境的不同而造成的不同程序行為而傷透腦筋，同時新人到崗時也能迅速建立開發、編譯環境。

PaaS雲服務：Docker 可以支持命令行封裝與編程，通過自動加載與服務自發現，可以很方便的將封裝於 Docker 鏡像中的服務擴展成雲服務。類似像 Doc 轉換預覽這樣的服務封裝於鏡像中，根據業務請求的情況隨時增加和減少容器的運行數量，隨需應變。

使用 Docker 來做分布式集群模擬

2、Docker在測試領域的應用：

1）快速搭建兼容性測試環境（各類Web服務器、中間件、數據庫的組合環境）

2）快速搭建復雜分布式測試環境

3）持續集成（快速創建和撤銷容器）

3、Docker對測試方式的影響：

1）、容器級測試

2）、測試前移（功能模塊-容器）

3）、集成測試

4）、自動化測試、並行測試

5）、可擴展性測試

6）、兼容性測試（例如驗證兼容MySQL和Postgres）

標準化容器開發和測試環境

Docker就像工廠中的流水線，將一個個集裝箱（模塊化的功能）傳輸到發貨區（上線發布）。

傳統模式和Docker模式在測試方式上的區別：

基於Docker的測試場景：

在開始測試之前，測試工程師需要確保自己的測試機上已經安裝了Docker並處於運行狀態，必要時需保證Docker的版本與最終生產環境一致。

測試環境搭建好之後，根據測試請求說明的鏡像地址拉取鏡像，並按要求運行，根據鏡像的目的測試所實現的業務。

如果在測試過程中發現bug或不符合需求，應盡快反饋給開發人員，開發人員修正後，重新將鏡像推送到註冊服務器，測試人員從鏡像庫拉取最新修改的鏡像繼續測試。反復幾輪直到達到可發布的版本。最後，測試人員發布測試合格報告，並註明最終的鏡像版本。

如果多個測試工程師同時測試，各自使用自己的測試容器，還能保證測試之間不被幹擾。

Docker模式下，開發-測試-運維的協作模式：

以一個簡單的應用開發、測試和發布來說明 Dock er 在阿裏雲 E CS 上的運用：
1) 運維人員在 ECS 上搭建私有 Docker Registry。
2) 開發人員在開發 ECS 上從阿裏雲或私有 Docker Registry 獲取應用需要的基礎鏡像。
3) 開發人員開發 ECS 上構造應用容器，自測後?交容器為新的鏡像並推送到私有 Docker Registry，通知 QA 測試。
4) QA 在自己的測試 ECS 上啟動容器，測試後，有問題則 a)，沒問題則 b)。
a) 通知開發修復，回到步驟 3)。
b) 交到私有 Docker Registry，準備發布。
5) 發布人員下載最新版本鏡像並在生產ECS 上啟動容器。

Docker時代，對測試的技能要求：

1、基於Docker的測試環境搭建能力

2、微服務架構的測試能力

3、基於容器與開發、運維的協作能力

最後，關於Docker在測試領域的應用，我們還缺乏比較多的嘗試和實踐，例如：

基於容器的應用，對其實施自動化測試與傳統應用有哪些差異？

基於容器的應用，在性能上與傳統方式的部署，差異有多大？

基於容器的應用，在安全測試方面，跟傳統應用有哪些差異？

Docker在測試領域的應用