Docker在测试领域的应用

作者：陈能技，资深质量优化专家，12年软件测试与质量管理经验，《软件性能测试诊断分析与优化》等多本IT畅销书作者。

Docker是PaaS供应商dotCloud开源的一个基于LXC 的高级容器引擎，Docker项目始于2013年3月，尽管Docker项目很年轻，然而它的发展势头如此之猛已经让很多人感叹不已了。

Docker的容器技术本身不是什么新鲜玩意儿，但是它所具有的一些特性，例如轻量级虚拟化、秒级启动、镜像分层等，促使这样一个技术可以应用在研发和运维的诸多场景中，并有效地推动DevOps、持续集成等敏捷开发的发展与实施落地。

目前来看，Docker至少有以下应用场景：

1）测试：Docker 很适合用于测试发布，将 Docker 封装后可以直接提供给测试人员进行运行，不再需要测试人员与运维、开发进行配合，进行环境搭建与部署。

2）测试数据分离：在测试中，经常由于测试场景变换，需要修改依赖的数据库数据或者清空变动 memcache、Redis 中的缓存数据。Docker 相较于传统的虚拟机，更轻量与方便。可以很容易的将这些数据分离到不同的镜像中，根据不同需要随时进行切换。

3）开发：开发人员共同使用同一个 Docker 镜像，同时修改的源代码都被挂载到本地磁盘。不再因为环境的不同而造成的不同程序行为而伤透脑筋，同时新人到岗时也能迅速建立开发、编译环境。

4）PaaS 云服务：Docker 可以支持命令行封装与编程，通过自动加载与服务自发现，可以很方便的将封装于 Docker 镜像中的服务扩展成云服务。类似像 Doc 转换预览这样的服务封装于镜像中，根据业务请求的情况随时增加和减少容器的运行数量，随需应变。

具体到Docker技术在测试领域的应用，可以体现在：

1）快速搭建兼容性测试环境

从Docker的镜像与容器技术特点可以预见，当被测应用要求在各类Web服务器、中间件、数据库的组合环境中得到充分验证时，可以快速地利用基础Docker镜像创建各类容器，装载相应的技术组件并快速启动运行，测试人员省去了大量花在测试环境搭建上的时间。

2）快速搭建复杂分布式测试环境

Docker的轻量虚拟化特点决定了它可以在一台机器上（甚至是测试人员的一台笔记本电脑上）轻松搭建出成百上千个分布式节点的容器环境，从而模拟以前需要耗费大量时间和机器资源才能搭建出来的分布式复杂测试环境。

3）持续集成

Docker可以快速创建和撤销容器，在持续集成的环境中，可以频繁和快速地进行部署和验证工作。

既然Docker可以给测试工作带来诸多便利，那么，引入了Docker之后，测试的方式与传统模式会有哪些差异呢？

基于Docker的测试场景：

在开始测试之前，测试工程师需要确保自己的测试机上已经安装了Docker并处于运行状态，必要时需保证Docker的版本与最终生产环境一致。

测试环境搭建好之后，根据测试请求说明的镜像地址拉取镜像，并按要求运行，根据镜像的目的测试所实现的业务。

如果在测试过程中发现bug或不符合需求，应尽快反馈给开发人员，开发人员修正后，重新将镜像推送到注册服务器，测试人员从镜像库拉取最新修改的镜像继续测试。反复几轮直到达到可发布的版本。最后，测试人员发布测试合格报告，并注明最终的镜像版本。

如果多个测试工程师同时测试，各自使用自己的测试容器，还能保证测试之间不被干扰。

另外，我们再看看，引入Docker之后，开发 - 测试 - 运维的协作模式也随之发生改变：

以一个简单的应用开发、测试和发布来说明 Docker 在阿里云ECS上的运用：

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的引入，对传统的开发-测试-运维的模式都会带来一些改变，Docker对测试方式和测试工程师的技能也会带来一些影响，例如：

1）、容器级测试

以后我们的测试人员做的更多的测试都将基于容器进行，因此对容器的一些技术特性必须了解和掌握，例如容器的创建、使用、监控等。

2）、测试前移

传统开发测试模式下，开发通常将整体系统版本提交给测试进行验证，通常会到比较末端后期才能开展，现在基于Docker采用微服务设计、功能模块的容器化实现，可以开发一个容器（功能），测试一个容器（功能），所以测试得以前移，跟上开发的节奏，更符合敏捷开发的思想。

3）、集成测试

基于容器开发后，系统功能隔离到一个个容器，那么容器间的联系和功能交互就会变得复杂，测试工程师需要重点关注容器间集成的验证。由此带来的必然是容器级的打桩、模拟等技术的引入，目前还没有看到太多这方面的实践。

4）、自动化测试

给自动化测试带来的挑战则是：容器层面的自动化控制（启停）、数据的验证方式、非界面层的自动化测试方式。

当然，由于容器的天然隔离性和环境搭建的快速高效、资源优势，使得自动化测试的并行执行得以更方便地实施。

5）、可扩展性测试

基于容器的部署发布带来的问题是：从运维角度，希望在测试环境充分验证系统的可扩展性，尤其是系统性能-容器资源的扩展曲线，以便后续实施容量规划。

关于Docker在测试领域的应用，随着越来越多的企业尝试和实践，相信会有更多细节上的困难出现并被有效解决！建议测试工程们尽早了解Docker这类很有可能改变 开发-测试-运维 模式的容器技术。