分类: 软件测试

容器化时代对测试的机遇

对于工作在复杂系统上的测试工程师,我们眼前浮现的都是这些人的屏幕上开着N个远程桌面,N个虚拟机,他们在每个交付迭代周期内都疲于奔命,顾此失彼地应付着各种不同的环境、浏览器和操作系统。在我曾经工作过的A公司和D公司,测试和开发人员的比例几乎是1:1甚至更高。

过去的几年里,测试的工作似乎变得完善和高效,成熟的敏捷实践使很多测试工作得以自动化,这无疑降低了企业成本,也使得测试本身变得更有趣,人们有时间去做一些创造性的工作,而把重复的、了无生趣的工作交给了机器和脚本。

但是,虽然我们做了很多改变,但就目前的情况而言,依然不是很乐观,我们还是会碰到诸如此类的问题:“我的环境没发现这个defect,你来帮我重现一下”,当我们信心满满去尝试重现的时候,却可能再也无法发现这个defect,然后不得不花费几个人几个小时甚至几天的时间去定位和解决它。

再有,很多敏捷团队都会做每日构建,构建成功的前提是所有的测试都要通过,我们为了减少构建时间、测试反馈时间,花了大力气去优化和重构,使用了mock技术等等,但对测试时间的影响依然是杯水车薪。

上述问题仅仅是我们平时工作里遇见的一小部分,对于这几个问题,我们归结了两点:

  1. 测试环境不够干净
  2. 测试执行效率需要大幅提升

我们带着这两个问题,来看近年来火爆的轻量级虚拟化——容器技术,它提供了能够独立运行的轻量级虚拟化解决方案,并且也提供了一种在安全、可重复的环境中自动部署软件的方式。

传统的硬件化虚拟占用的资源比一个容器要多不止10倍。我们不敢想象在一个物理机上开上百个虚拟机是什么效果,但是要实现同样数量的容器是很正常的。容器为我们提供了隔离的运行空间,每个容器又包含了完整的用户环境。不但如此,我们还可以通过诸如ansiblepuppet、chef这样的自动化运维工具对不同的容器空间进行批量化操作等等。

从一个测试人员的角度来讲,这恰恰为我们运行测试脚本提供了丰富的土壤,我们不必担心一些依赖包悄悄地破坏我们的环境,也不再担心多人在相同的虚拟机或者硬件环境中的操作污染了环境,使defect无法重现,同时,多操作系统版本、多尺寸的移动端自动化测试也将从容器化技术中受益更多。

那么另一个问题解决起来也不算难,主流的开源自动化测试工具Selenium多年前就提供了Selenium Grid,hub/remote的机制可以很好地帮助我们设计分布式测试环境:

grid

我们可以把这样分布式的环境与自定义的容器化空间结合在一起,利用提供各种语言支持的并发工具包,让我们在安全、可重复、可移植的环境基础下,指数级提升测试运行效率,减少反馈时间:

grid2

 

大部分测试人员对日新月异的技术并不是很敏感,很多时候,我们可能会认为,这些技术的发展,并不会也并不想知道这些技术能对日常的测试工作带来多少影响,但其实很多时候看似孤立的领域,碰撞在一起会有意想不到的火花。

乔布斯曾经说,创新就是把各种事物整合在一起。当你问有创意的人是如何创新的,他们可能会感到些许愧疚,因为他们根本没有创造什么。他们只是看到了一些东西。我们对于日常工作了解得更深更广,我们就会做得越出色。

发表评论

评论

Webmentions

  • 复杂业务场景下如何进行iOS端自动化测试-IT文库

    […] 去年写了一篇关于《容器化时代对测试的机遇》的文章,提到了一些分布式自动化测试和容器化技术结合的架构设想。但是目前来说,分布式运行并不是难点,亟需解决的问题是针对特殊平台和复杂场景下的测试,例如复杂业务场景下iOS平台的自动化测试。 […]