Docker在测试领域的应用

标签：预览   实践   比较   开始   扩展性   中间件   操作系统   反馈   google   

最近在搭建测试环境，因平台的项目较多，而且每次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在测试领域的应用

标签：预览   实践   比较   开始   扩展性   中间件   操作系统   反馈   google   

原文地址：http://www.cnblogs.com/what-/p/7821200.html