Docker引领测试革新

1.传统软件开发流程的痛点

在传统软件开发流程中，开发团队在完成功能代码编写后，会首先进行自测，以后将代码提交到Git仓库中。在每一次迭代转测试时，开发团队会首先构建转测试的二进制文件，以后由测试团队对版本进行验证，验证经过后会将版本提交给运维团队。以后再由运维团队将产品发布件部署到运维服务器中以提供给客户使用。

在这个流程中会有以下痛点：

(1)开发、测试和运维环境不统一。

这致使了有些本该在开发阶段发现的软件缺陷可能会遗漏到测试或运维阶段才能发现。有时发布件在开发环境中运行的很稳定，而在运维环境中刚刚运行就挂掉了。这时运维团队不得不找开发团队来救火，致使了整个团队工做效率降低。

(2)没法准确获取客户的软件环境。

咱们每每不能直接复现客户报的软件缺陷，不得不去客户现场进行调试，滞后了解决问题的时间。

(3)开发者在提交代码前每每未作充分的测试。

开发自验工做取决于开发者的责任心，而没有一种机制来保证自验工做的进行。致使了不少低级的软件缺陷遗漏到测试和运维团队。

(4)开发团队没法复现测试团队报出的软件缺陷，致使两个团队出现相互推诿的现象。

(5)配置测试环境的时间较长，测试自动化成本高。

传统环境每每使用虚拟机，而其消耗资源高、部署速度慢，致使自动化的效率不高。

2.当前测试技术面临的挑战

主要的挑战以下所示：

(1)配置一致的测试环境。

(2)快速部署软件。

(3)并行执行测试，在并行的同时还需确保测试任务各自的环境不被污染。

(4)成功的复现软件缺陷。

(5)建立清洁的测试环境。

(6)正确配置测试工具。同一个工具须要适配到不一样的linux发行版中。

(7)快速部署多个测试主机。

(8)快速导入测试数据。

(9)快速清理测试环境。

(10)快速保留、复制、恢复测试环境。

3.Docker对测试技术的革命性影响

(1)更早的发现单元测试中的软件缺陷。

测试驱动开发是软件工程中一个具备里程碑意义的创新，即开发者在提交开发代码的同时也要提供对应的测试代码，在代码提交后系统会自动进行一轮自动化测试。经过Docker能够快速部署测试环境，能够有力的支撑自动化测试，从而确保在第一时间发现单元测试中的软件缺陷。

(2)为功能测试和集成测试提供清洁的测试环境。

不少公司因为成本问题，不得不在一个虚拟机中运行不一样类型的测试任务。而这些任务在运行时每每会致使环境污染。经过Docker技术的隔离性，能够有效地解决测试环境的污染问题。

(3)让测试团队和客户丢掉冗长的配置文档。

开发转测试时每每带有较长的环境部署文档，而在这些文档中每每存在部署过程跳步的问题，测试团队很难一次准确的将环境部署成功。而如今能够经过Docker镜像将配置环境的过程简化，测试团队省去了查阅文档的过程，只须要基于开发团队提供的Docker镜像就能够轻松的配置测试环境。

(4)便于复现客户报告的软件缺陷。

当客户使用软件发现缺陷时，能够将其所使用的环境打包成镜像提供给开发团队。开发团队经过镜像便可获取与客户一致的软件环境。

(5)经过Dockerfile能够梳理好测试镜像制做的流程。

若是流程步骤须要微调时(如将安装gcc3.4改成安装gcc4.3)，能够将Dockerfile中对应的信息进行修改并从新建立新的镜像，没必要手动从新配置运行环境。

(6)能够将成熟的测试套或测试工具经过镜像共享。

这样能够支持软件在不一样linux发行版中成功的运行，软件提供商能够将主要精力放在完善功能上，没必要投入过多时间将软件适配到不一样的linux发行版中。

(7)利用Docker生态中的工具能够快速建立可伸缩的测试环境，大大减小了测试所消耗的时间。

能够在短期内快速集中资源来完成一项测试任务，在任务完成后又能够快速的对资源 进行回收，有利于提高资源使用效率。

(8)优越的性能指标。

经过优于虚拟机的性能，Docker能够提高测试效率。经过“-v”选项能够将主机的目录快速映射到容器中，能够实现测试文件的快速共享。经过“--rm”选项能够在测试完成后第一时间删除容器，以便释放系统资源。

(9)轻松的恢复测试环境（包括内存）-CRIU技术 Checkpoint Restore In Userspace

结合CRIU技术，能够实现容器运行状态的保存，这项技术也是容器热迁移的基础。

4.DevOps与Docker

DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合做，经过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

在DevOps出现以前，软件通过开发、测试后由运维团队将发布件部署到公司的基础设施上，并将服务提供给客户使用。然而，开发、测试、运维三个团队缺乏有效协同工做的机制，致使部门墙严重。开发团队每每关注新功能开发和快速迭代，而运维团队关注的是发布件的稳定性，他们不但愿版本频繁的更替。每每在这两个团队间会爆发激烈的斗争。

在DevOps出现以后，团队经过协做和自动化的方式打通了开发、测试、运维团队之间的壁垒。当有新的代码提交时，系统在第一时间会触发自动化测试，依次在开发自验环境、测试环境、运维环境中验证软件，确保能够第一时间发现软件缺陷。然而，当出现业务峰值时，传统的基础设施中的虚拟机就没法有效的应对了。

在后Devops时代，随着云计算的普及，不少云平台提供了应用引擎，若是你的应用符合引擎的规范，云平台就能够自动检测业务负载量。当业务出现峰值时，平台能够利用底层容器技术的快速部署、资源快速扩展伸缩等特性来应对，从而有效的支撑了业务的正常运行。

5.Docker与自动化测试

对于重复枯燥的手动测试任务，能够考虑将其进行自动化改造。自动化的成本在于自动化程序的编写和维护，而收益在于节省了手动执行用例的时间。简而言之，若是收益大于成本，测试任务就有价值自动化，不然受益的只是测试人员的自动化技能获得了提高。利用Docker的快速部署、环境共享等特性，能够大大减小自动化的成本，使不少本来没有价值自动化的测试任务变为了有价值自动化的任务，大大提高了项目效率。

那么若是自动化测试已经运行在了虚拟机中，是否有必要使用Docker技术将其进行改造？这个就要具体问题具体分析了。笔者并不赞同将全部测试任务一刀切的进行容器化改造。若是当前虚拟机已经知足测试需求，你就须要评估一下引入Docker进行改造所需的成本，其中包含学习Docker技术所须要的时间成本。反之，若是虚拟机没法知足当前的测试需求，能够考虑尽快引入Docker进行改造。

6.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技术，修改某个容器时间时就不得不影响到主机和其它容器。

7.适用于Docker的测试场景

因为容器与主机共享内核使用，凡是和内核无强相关的测试任务是适合引入Docker进行改造的，例如源码编译测试、软件安装测试、互联网应用测试、数据库测试等。而与内核强相关的测试任务是不适合使用Docker进行改造的，如内核网络模块测试、内核namespace特性测试等。

8.Docker测试实践

8.1.容器化编译系统测试

早期咱们将linux发行版安装到物理机中进行测试。当须要从新进行全量测试时不得不手动还原测试环境。以后改用了虚拟机，虽然可以经过自动化的方式实现环境还原，但虚拟机的损耗较大，效率不高。

以后咱们尝试将环境制做成Docker镜像，同时进行了以下的改进：

(1)经过Docker的“-v”选项，将主机目录映射到容器中，实现多个容器共享测试代码。测试代码部署时间从2分钟减小到10秒。

(2)将大粒度的执行时间较长的用例拆分红为若干个小用例。

(3)利用容器并发执行测试。

(4)使用Dockerfile梳理产品依赖包和编译软件的安装。

编译系统测试是用户态的测试，很是适合使用Docker进行加速。若是须要针对某一个linux发行版进行测试，能够经过Docker快速部署的特色，将全部的资源快速利用起来，从而达到加速测试执行的目的。

8.2.linux外围包测试

外围包包含动态连接库文件和经常使用的命令行工具，属于linux操做系统的中间层，其上运行着应用程序，其下由linux内核支撑。起初的外围包测试采用串行执行，效率不高。同时受到环境污染的影响，容易产生软件缺陷的误报。在改进方面，咱们首先经过Dockerfile基于rootfs制做一个Docker镜像，而后经过Docker-compose工具实现测试用例的并发执行。

如下是改进先后的对比。

改进前	改进后
每套环境独占一台主机，主机利用率不高。	多套环境能够在同一主机上部署，能够更有效利用主机资源。特别是在主机资源昂贵的状况下，能够节省不少成本。
测试串行执行，由于环境污染问题测试任务不易并发。	经过Docker进行测试任务隔离，能够并行执行测试，提升了cpu利用率。
环境释放时清理工做依赖于程序员的技能。在每一个测试用例中有一个cleanup函数，负责资源回收和环境恢复。若是程序员编程技巧不高的话，可能会形成资源回收不完全，测试环境会受到污染。	环境释放时清理工做由Docker接管，当执行完任务后，能够删除容器。即便不写cleanup函数，也能够实现资源的回收。
没法解决多个外围包的环境污染问题。当连续执行多个测试时，有部分测试没法经过，而单独执行这些测试时又可以经过。这一般是因为测试环境污染形成的。	容器可快速启动与关闭，每次都是清洁的环境。
外围包编译环境不易统一，致使测试结果不一致。	经过镜像保存编译环境，确保环境统一。
测试网络包时须要至少两台主机，分别部署服务端和客户端。	测试网络包时只须要在同一台主机中启动两个容器来部署服务端和客户端。

9.经过Docker进行测试加速的原理

Docker自己并不会直接加速测试执行。在串行执行测试时，在容器中执行测试反而会带来约5%左右的性能衰减。但咱们能够充分利用Docker快速部署、环境共享等特性，同时配合容器云来快速提供所需的测试资源，以应对测试任务的峰值。若是忽略环境部署时间，当每一个测试用例粒度无限小而且提供的测试资源无限多时，测试执行所需的时间也就无限小。

10.总结

不少测试任务能够利用Docker进行改造，读者能够根据项目自身的特色，因地制宜的使用Docker进行测试能力的改造。若是想进一步了解容器云，能够参考《网易云的实践之路：谈谈容器云的机会与挑战》这篇文章。

本文地址：http://www.linuxprobe.com/docker-change-test.html