Docker在自动化测试中的实践应用-轻识

2020-10

今天距2021年62天

这是ITester软件测试小栈第171次推文

点击上方蓝字“ITester软件测试小栈“关注我，每周一、三、五早上 08:30准时推送，每月不定期赠送技术书籍。

微信公众号后台回复“资源”、“测试工具包”领取测试资源，回复“微信群”一起进群打怪。

本文3759字，阅读约需9分钟

没有接触Docker，但大伙也可能在论坛上、招聘技能点、交流群里等等听过Docker这项技术。不了解Docker，都不好意思在网上冲浪的时候吹牛逼，本文主要介绍Docker在自动化测试中的实践应用。

一

Docker背景故事

有一个笑话叫作《千万不要跟程序员说，你的代码有Bug》：

他的第一反应是：你的环境有问题，第二反应是：你是傻x不会用吧。
你要是委婉的这么跟他说：“这个程序运行的怎么跟预期不一样，是我操作有问题吗？”。他会说：Obviously，在我本地是好的。
经过上述两次打脸，这货才会豁然反思“擦，这是不是出bug了？”

我们写的程序，一般能接触到好几个环境：

自己写代码的环境叫做开发环境；
给测试去跑的环境叫做测试环境；
测试完可以对外使用的叫做生产环境。

现实中，我们在项目中很多时间都浪费在“环境”上：

如果现在重装了系统，我想要跑war/jar包，得去安装一下JDK、Tomcat、MySQL等配置各种的环境变量才能跑起来。
开开心心地跟着博主给出的步骤去写Demo，但总是有Bug，缘于版本/配置依赖于环境。
好不容易在测试环境下跑起来了，在生产环境就各种出错！
跟着教学视频做分布式/集群的项目，跑一堆的虚拟机，每个虚拟机都要安装对应的环境。

Docker作为一个开源的应用容器引擎，设计思想来自于集装箱，集装箱解决了什么问题？在一艘大船上，可以把货物规整的摆放起来。并且各种各样的货物被集装箱标准化了，集装箱和集装箱之间不会互相影响。那么我就不需要专门运送水果的船和专门运送辣条的船。只要这些货物在集装箱里封装得好好的，我可以用一艘大船把他们都运走。将一整套环境打包封装成镜像，无需重复配置环境，解决环境带来的种种问题。Docker容器间是进程隔离的，谁也不会影响谁。

开发人员利用 Docker 可以消除协作编码时“在我的机器上可以正常工作”的问题。运维人员利用 Docker 可以在隔离容器中并行运行和管理应用，获得更好的计算密度。企业利用 Docker 可以构建敏捷的软件交付管道，以更快的速度、更高的安全性和可靠的信誉为 Linux 和 Windows Server 应用发布新功能。

二

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发行版安装到物理机中进行测试。当需要重新进行全量测试时不得不手动还原测试环境。之后改用了虚拟机，虽然能够通过自动化的方式实现环境还原，但虚拟机的损耗较大，效率不高。

之后尝试将环境制作成Docker镜像，同时进行了如下的改进：

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

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

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

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

编译系统测试是用户态的测试，非常适合使用Docker进行加速。如果需要针对某一个Linux发行版进行测试，可以通过Docker快速部署的特点，将所有的资源快速利用起来，从而达到加速测试执行的目的。

Linux外围包测试

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

改进前后对比

如下所示：

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