E2E 测试容器化实践

齐磊，ThoughtWorks 高级质量咨询师

今天给大家带来的话题是E2E容器化实践，可能QA更关注些。

在互联网最初之时，没有任何容器化的概念，那么刚开始的时候是怎样开发软件或者是网站的吗？那时就是计算机便是服务器，就是一个简单的静态网页，没有复杂的业务逻辑。

第二个时代是虚拟化时代，这个时代网络迅猛发展，软件开发工程化各种实践，这个时代崛起的虚拟化技术尤其是虚拟机对于QA来说非常重要，因为我们可能在虚拟机上去运行测试环境，这样不会对本地的开发环境造成影响。

虚拟机对开发来说更加友好，因为你不可能一辈子只工作在一个技术栈上，频繁的切换环境可能造成本地环境的崩溃。

第三个阶段是容器化时代，大家知道这个阶段代表作是什么？Docker。

无容器化虚拟蛮荒时代，测试环境即生产环境，DEV旧是QA又是OPS,在最早没有任何测试，造成很多问题。

虚拟化时代，分为虚拟机、私有虚拟集群和云计算，私有虚拟集群尤其是之前在华为工作过的，其实就是虚拟机群，IT运维部门会给你一个IP、用户名密码，你远程连接之后登到虚拟机，它其实就是在你公司的一个私有服务器上去创建一堆的虚拟机，让员工去用。

云计算，不管你是阿里云还是什么别的云，它全是基于OpenStack 技术去创建的，会将不同的服务器资源利用起来帮助你启动你需要的虚拟资源。

容器化时代，为什么要讲容器，先看它和虚拟机的区别，最重要的区别是虚拟机是硬件层面虚拟化，Docker是操作系统级别的虚拟化。

更有效的利用系统资源，刚才的PPT大家可以看到，虚拟机是硬件化的虚拟，它的启动需要时间，而且需要占用一定的磁盘空间，需要占一定的CPU和资源。

但Docker的占用内盘空间和占用的虚拟空间是根据系统来设置的，根据你运行的文件去自动调整，占用的硬件空间几乎可以忽略，只有几M, 因为它是系统节级的。

更快速的启动时间，Docker不像虚拟机那样需要去启动系统，你要把它运行，运行之后还要像自己的电脑一样去加载系统，进入到系统，光启动就三四分钟，还要去运行你的服务。

但Docker不一样，Docker直接就运行了，所以能够减少启动加载和服务加载所消耗的时间。

一致的运行环境，当你刚来到一个公司或者是刚进一个项目时，这时你的开发或者是QA小伙伴说要做开发了，或者说我们要去测一下项目，这时候我们配置了半天开发环境，结果还是错误一堆。

Docker不一样，Docker只需要你下载所对应的服务镜像，之后去启动容器镜像访问所需服务就可以, 规避了很多环境所带来的问题。

持续交付和部署，前非容器化时代项目要和CI去做集成时非常麻烦，要考虑很多因素，比如刚才说的变量还有系统项目路径等都需要去单独配置，但有了Docker之后就不用，因为它在容器里，你只需要把运行容器的服务的代码具体路径映射到你的容器就行。

更轻松的迁移，我不知道大家都写过Docker file，它非常简单，便于我们更加方便的组装所需服务。

更轻松的维护和扩展，Docker有一个版本管理功能，当你持续改进Docker镜像时，也是便于你。

总结一下对比传统虚拟机容器化有哪些特点或者说优点。

• 第一个就是时间，之前从你运行界面到你运行服务，需要耗费4——5分钟，容器基本是秒级；
• 第二个是硬盘使用，刚才提到Docker的容器是几M兆，但是需要占用磁盘空间；
• 第三个是性能，容器化是操作系统层面的虚拟化，所以更接近于原生，基本没有什么消耗，但是虚拟的你要在你初始阶段去分配内存和CPU，如果你用过AWS云或者是阿里云等你在创建的时候都是会让你选你要多大的CPU和内存；
• 第四个是系统支持量，在一个服务器上，Docker可以单击支持上万个容器，但是虚拟机是几十个就撑死了。

进入今天的正题，欢迎来到测试容器化时代。容器化能给QA带来哪些方面的测试，第一个是单元测试，第二个是集成测试，第三个是E2E测试。之前在虚拟化时代这三个也能做，但是容器化时代已经来临，我们要进入到容器化时代。

测试容器化解决了什么？

测试容器化可以解决的问题，一是准备测试环境。

二是运行环境一致性，一个组不止你一个QA, 一个QA大组里面有几个或者几十个QA,我们可以通过虚拟机让QA们拥有相同的环境，但那个镜像面可能就十几个G, 有可能造成你的机器性能和硬盘耗尽，但容器就没有这个问题。

三是测试运行的稳定性，你再怎么在容器里去测试运行，它都不会受外界干扰。

四是方便与CI结合，不会受其它的因素干扰。

测试容器化不能解决什么？

不能解决问题？浏览器兼容性测试，我们知道Docker没有办法去运行到WINDOWS系统，第二个是性能测试，就算容器已经无限接近于原生的操作系统，但对于性能测试来说，比如说双十一或者是京东6•18时，不能对容器的性能做测试，可能在前一段时间去对它自己的备用服务器去做测试，在怎么强大的容器化，都不能和真实的机器媲美。所以性能测试还是用真实的服务器去测试。

怎么实现测试容器化？

先聊一下E2E测试，我们是先编写测试脚本，然后去上传，这里有两种触发CI的方式，一种是开发环境部署后触发，一种是定时触发，当触发之后，会把代码放到运行测试的服务器上去运行，这时当你运行完之后就会把结果告诉你，就是三步骤，编写测试，CI去触发测试，最后是结果。

具体的实践，一是构建合理的测试image

刚才我谈到Docker最重要的是镜像，编写合理的镜像对于你的工作来说能减少很多的不必要的浪费提高工作效率。

实践一，动静分离。把经常变化的和基本不会变化的内容要分开，Test scripts可以用现在任何的主流编程语言编写，所以在base image这部分，你需要选择合适的景象，如果你是JAVA，你要先下载JAVA的安装包等，配完之后才能测，因为Webdriver是随着浏览器版本的变化而变化的，它一直在动，所以要动静分离，讲的是这两部分要分开。

实践二，只安装必须的东西。很多人写镜像的时候喜欢把一堆无关紧要的东西都放在里面，在创建景象时会造成资源的浪费和时间的浪费，所以需要检测你测试框架中的依赖库文件，剔除无用的库。

从这里可以看到，这些可能是去做一些信息的筛选，这是我们整个依赖的范围，尽量减少这些，把无关紧要的东西抽出。这个小一些，这是前端测试，当时用的是谷歌自己出的，也是专门抽出了一部分去做，只是安装最核心的，对于测试来说，我们尽量减少依赖。

实践三，每个镜像只有一个功能。测试最终都是需要去测单独的一个服务的，不能把服务和测试打成一个，这也可以做，但后期的维护成本非常高，你要不停的去Build你的测试页面，不停的拉服务端，当你把服务和你的测试分开之后，就可以更好的去构建你的运行版本。

刚才我提到Docker image，把你的产品服务都all in one, 这个是分布化，有为产品做服务的，产品也有云数据库，数据库是Docker for sever。

实践四，使用更少的层，减少每层的内容。把不同的命令分开来，写在多个命令中容易阅读的位置。我先进入到一个目录，去连接接下来的全部操作，这样在你的Docker页面里只打了一层，通过这些手段可以帮助你更好的Build一个性能更好更优的层。

这里有一些建议，比如安装完软件包，清理你的缓存，这样就可以减少占用，下面也一样，删除中间文件和历史文件，都是为了让你的image更小，效率就会提升。

实践五这一块是用Docker去管理不同的服务，这里有两个服务，一个服务是刚才提到的产品服务，它用了2个Docker，3000和9999，让测试者能访问到产品服务。这个也分三个阶段，有了Dockfile就可以在任何地方去复制，当你把这个下载到电脑上你只需要一行命令 就可以帮你自动启动所需服务。

运行E2E测试

最早的时候容器化尝试是这样，怎么在没有界面的情况下去运行，我们知道端到端测试需要页面做一些操作，在容器里怎么做操作？最早的时候是尝试了一种方法是phantomJS, 确实可以做，但坑比较多。

第二个阶段是现在很多公司仍然在用的xvfb, 这是一个过渡时期的产品，vfb也就是linux 虚拟图像化环境，这个东西是给Docker容器化起一个虚拟的环境，Xvfb虚拟容器化界面有一个重要的问题是非常占内存，最新的阶段是今年谷歌在他的大会上发布了一个东西，叫做chrome headless, 这套框架替换前面这些选择，在现阶段是最完美的东西。

未来的趋势是谷歌不会满足于这套框架，因为它还是要有具体的驱动脚本，在浏览器上运行，要是通过这个就非常麻烦，要通过中间件来发，中间件在告诉浏览器要干啥，比较慢。

所以谷歌在年初发布了puppeteer之后又对这一块深入，现在各大浏览器厂商也在开发headless的模式，未来web兼容性测试会有质的飞跃，可能会紧密的与devops结合。

持续集成

什么时候用trigger E2E testing,我们知道端到端的测试，项目比较小可能运行时间需要2-3分钟，项目大的话可能一两个小时。

当开发把代码部署到生产环境之后，这时再去trigger端到端的测试，因为部署到这个环境半个小时就可以一次，还是可以覆盖的。

第二种是按小时，按小时trigger，工作时间从9点到下午6点，这样按每个小时去一次，既能节省资源又能即时反馈。

端到端测试也应该有自己的Pipeline，我们要开发部署到之后它会trigger流水线去构建自己的测试，可以看到这一块是用Jenkins2.0，用node 、stage、step。

来看看这个，第一个阶段是准备镜像阶段，先把路径放到变量里，用Dockfile，

第二个阶段是注册信息，注册账户，需要在Dockfile里拉一些产品服务的镜像，

最后是测试的东西要和服务的东西相结合。Run test, 要初始化变量，为什么要先down, 因为有可能一些其它因素或者容器没有被关掉，所以要先down掉，然后是Build，要把之前服务的容器和测试容器相连接，接下来是run我的端到端测试。

后面是把容器和服务全部停掉，对于QA来说最终是要看测试结果，我们要查看详细的运行结果，所以要把测试报告上传到远端服务器，这个服务器可以是AWSS3 存储服务或者本地服务器，只要能够保存测试结果就可以。

Clean up, 要删掉当前机器上的这些镜像，它的内存空间是有限的，所以我们要尽量减少。

Q&A

提问：我的问题是Docker我们之前试过，我刚才看你讲的那些应该是最佳实践的建议，但我们后面没有分析的原因，是我们一个产品是生产环境在内网，发布环节我们想做成镜像，简化部署过程，镜像怎么打都很大，轻轻松松的七八百兆，我们还有一个拷贝，我刚才看到你的策略是类似于功能唯一性，不知道你有没有类似的场景问题，你是怎么解决的？

齐磊：有私有化，你可以去搭一个私有化的。

提问：我感觉没打多少，有一个形态就是这样，有JDK, 我打进去之后就是一个G, 直接发布软件的话可能就是几十兆或者是一两百兆。

齐磊：你给了一个完整的运行环境，能运行，但你发布一个单独的包还是需要一个单独的环境去运行这个服务，它是两个概念。

提问：但如果我采用老的策略，每一次发布都给包的话，就不用每次给？

齐磊：是，但如果你采用Docker的话，就可以直接把Docker镜像做下来，不用再做工作，但如果不是这样的话你就需要再去下载，如果用Docker容器化镜像化的东西就只需要做镜像包就行。

提问：你们生产环境是不一定镜像？

齐磊：刚才我一直在强调，我讲的是作为容器化，对于QA来说更多的是关注本地，这种测试环境和镜像环境是有区别的，没有把完整的整套环境去布置，可能就是一个单独的，一个单独的对于一个市场的定制化的东西，这时把所有的镜像打出来确实非常占内存。

提问：我明白，我们的应用场景可能有一定的区别。谢谢。

齐磊：其他人还有什么问题吗？

提问：我想问一下，Docker在镜像环境的时候都是在setting里面，我们是在所有的环境，专门有一个兆，你们有没有做过这样的尝试，Docker在把所有的环境统一，无时无刻不在监控着容器里有没有变化，把它统一部署到所有的里去，而不是在每个个setting来进行限产。我觉得这样会比较浪费时间，执行效率会有所降低，我是这样认为的，因为我实际操作过。

齐磊：具体的实践不一样，Docker只是镜像去帮你进行，不存在效率的问题。可能你之前就是把很多都揉在一块，如果用微服务的概念，把它都拆开，这时可能就更利于测试，而且远端服务可以采取一些增量式的，我发现我的测试，

从我的下载，产品到环境变化，总共耗时最长8分钟，第二个测试是设计，分不同模块测试，和功能界定没有太大关系，要从测试层面去拆分你现有的模块。运行测试要从各个层面去考虑，不光是Docker层面，另一个层面是设备，怎么从现行变成并行，这样你的测试效果更好时间才能减少。

提问：我想了解一下Docker镜像，管理的优势方案，因为每一次操作，如果是一些环境的东西，这样你的Docker就会无限增大。

齐磊：有专门的可以去帮你管理Docker镜像，我更关注的是怎么帮助我运行各种各样的测试，容器化怎么去管理运维大神有发言权。

主持人：现在有多少人用Docker，刚才说的容量大的问题，不知道听说过BICYBOX没，拉镜像的时候有两个，一个是BICYBOX, 还有一个只有8兆，BICYBOX是32兆，现在官方的都是小镜像，我用在生产环境大于0.5G的不会用，还有拆分的方式。

Docker是文件一层一层的，你可以做一个定时任务，经常去Build它的基础镜像，拉到内网，因为它本身是缓存的，每一个Agent去本地构建，因为前面大的部分都已经构建过了，所以不需要构建，只需要构建新的东西进来就行，这是第二种。

第三种是针对你要做的JAVA应用，把Docker容器里的文件系统挂出来，你有Docker的运行环境，把它挂进去，不需要构建整个镜像，直接用就可以。这样更新快，也方便，更新下一步版本的时候就重新启一下，不用重新打包和重新传输。

提问：我不知道你们测试环境里的数据库，它本身的体量，还有版本。

齐磊：从QA的角度来说，可能更关注的是脚本，第二次可能就会创建失败，第一次使用的是mook数据库，第二个是还是要坚持使用原来的数据库，你需要去准备一套和现在的数据库一模一样的东西，每一次去把这个搬到那，但最好的建议还是用mook。

注：本文根据 DevOps 时代社区和 ThoughtWorks Community 联合举办的Jenkins Area Meetup 齐磊老师的分享整理而成。