E2E测试容器化实践

luna
作者:齐磊

今天给大家带来的是QA更关注的话题端到端的容器化实践。

在最早的时候，互联网刚开始的时候没有任何容器化的东西，大家知道，刚开始的时候是怎样开发软件或者是网站的吗？那时就是服务器，就是一个静态网页，没有复杂的东西，第二个时代是虚拟化时代，对于QA来说非常重要，因为我们可能在虚拟机上去运行，要去切一些不同的站时会造成破坏，虚拟机对开发来说更好。第三个阶段是容器化时代，大家知道这个阶段带来了什么？Docker。

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

虚拟化时代，分为虚拟机、私有虚拟集群和云计算，私有虚拟集群尤其是之前在华为工作过的，其实就是虚拟机，它会给你一个IP,给你用户名密码，你远程连接之后登到虚拟机，它其实就是在你公司的一个私有服务器上去创建一堆的虚拟机，让员工去用。云计算，不管你是阿里云还是什么云，它全是基于最新的技术去创建，会将不同的服务器资源利用起来帮助你启动你需要的虚拟资源。

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

更有效的利用系统资源，刚才的PPT大家可以看到，虚拟机是硬件的虚拟，它的启动需要时间，而且需要占的磁盘空间很大，需要占一定的CPU和资源，但Docker的占用内盘空间和占用的虚拟空间是根据系统来设置的，根据你运行的文件去自动调整，占用的硬件空间几乎可以忽略，只有几M, 因为它是系统节级的。

更快速的启动时间，Docker没有虚拟机那样，你需要去启动系统，你要把它运行，运行之后还要像自己的电脑一样去加载系统，进入到系统，光启动就三四分钟，还要去运行你的服务，但Docker不一样，Docker直接就运行了，基本是毫秒级或者是秒级的。

一致的运行环境，刚来到一个公司或者是刚进一个项目时，这时你的开发或者是QA小伙伴说要做开发了，或者说我们要去测一下项目，他那一块做的好不好告诉你具体的配置，你是派专家还是不派？Docker不一样，Docker只需要你下载具体的对象，去访问具体的UI, 规避了变量带来的问题。
持续交付和部署，之前我们和其它的CM去做集成时非常麻烦，要考虑很多因素，比如刚才说的电量还有系统项目路径等都需要去调，但有了Docker之后就不用，因为它在容器里，你只需要把运行容器的主机具体路径映射到你的容器就行。

更轻松的迁移，我不知道大家都写过Docker FATE没，它非常简单，就是视觉化运行的容器。

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

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

• 第一个就是时间，之前从你运行界面到你运行服务，需要耗费4——5分钟，容器基本是秒级；

• 第二个是硬盘使用，刚才提到Docker的容器是几M兆，但是虚拟机能在你的内存上占到5——6G, 有可能你装完还不能应用；

• 第三个是性能，容器化是操作系统层面的虚拟化，所以更接近于原生，基本没有什么消耗，但是虚拟的你要在你初始阶段去分配内存和CPU，如果你用过AWS云或者是阿里云等你在创建的时候都是会让你选你要多大的CPU和内存；

• 第四个是系统支持量，在一个服务器上，Docker可以单击支持上万个容器，但是虚拟机是几十个就撑死了。
  

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

测试容器化解决了什么？

测试容器化可以解决的问题，一是准备测试环境。二是运行环境一致性，一个组不止你一个QA, 一个QA大组里面有几个或者几十个QA,虚拟机可能是把虚拟机的镜像重建，但那个镜像面可能就十几个G, 可能你机器的性能和硬盘就不够，但容器就没有这个问题。三是测试运行的稳定性，你再怎么在容器里去测试运行，它都不会受外界干扰。四是方便与CI结合，不会受其它的因素干扰。

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

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

怎么实现测试容器化？

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

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

刚才我谈到Docker最重要的是镜像，编写合理的镜像对于你的工作来说能减少很多的浪费。
实践一，动静分离。把经常变化的和基本不会变化的内容要分开，Test scripts可以用现在主流的任何一个，但是容器这部分，如果你是JAVA，你要先下载JAVA的安装包等，配完之后才能测，因为Webdriver是随着浏览器版本的变化而变化的，它一直在动，所以要动静分离，讲的是这两部分要分开。

实践二，只安装必须的东西。很多人写镜像的时候喜欢把一堆无关紧要的东西都放在里面，在检测时会造成资源的浪费和时间的浪费，所以需要检测你测试框架中的依赖库文件，剔除无用的库。从这里可以看到，这些可能是去做一些信息，这是我们整个依赖的范围，尽量减少这些，把无关紧要的东西抽出。这个小一些，这是前端测试，当时用的是谷歌自己出的，也是专门抽出了一部分去做，只是安装最核心的，对于测试来说，我们尽量减少依赖。

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

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

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

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

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

运行E2E测试

最早的时候容器化尝试是这样，怎么在没有界面的情况下去运行，我们知道端到端测试需要页面做一些操作，在容器里怎么做操作？最早的时候是尝试了一种方法是phantomJS, 确实可以做，但坑比较多，第二个阶段是现在很多公司仍然在用的xvfb, 还是过渡时期的产品，就是虚拟图形环境，这个东西是给Docker容器化起一个虚拟的环境，Xvfb虚拟容器化界面有一个重要的问题是非常占内存，最新的阶段是今年谷歌在他的大会上发布了一个东西，叫做chrome headless, 这套框架替换前面这些东西，在现阶段是最完美的东西。

未来的趋势是谷歌不会满足于这套东西，因为它还是要有具体的驱动脚本，在浏览器上运行，要是通过这个就非常麻烦，要通过中间件来发，中间件在告诉浏览器要干啥，比较慢，所以谷歌在年初发布了之后又对这一块深入，现在各大浏览器厂商也在开发headless的模式，未来web兼容性测试会有质的飞跃，可能会紧密的与devops结合。

持续集成

什么时候用trigger E2E testing,我们知道端到端的测试，项目比较小可能两三分钟，项目大的话可能一两个小时。当开发把代码部署到生产环境之后，这时再去trigger端到端的测试，现在的端到端测试跑的比较早，最长就8分钟，因为部署到这个环境半个小时就可以一次，还是可以覆盖的。第二种是按小时，我们为什么要跑测试，按小时trigger，工作时间从9点到下午6点，这样按每个小时去一次，既能节省资源又能即时反馈。

端到端测试也应该有自己的Pipeline，我们要开发部署到之后它会trigger流水线去构建自己的测试，可以看到这一块是用Jenkins2.0，用node 、stage、step，我需要把当时远端的这些都删掉，以免影响下一次。

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

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

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

后面是把容器和服务全部停掉，对于QA来说最终是要看测试结果，不光关注这一次失败还是成功，所以要把测试报告上传到远端服务器，这个服务器可以是AWS服务器，只要保证测试到就行。

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。