容器化时代对测试的机遇

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

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

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

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

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

　　测试环境不够干净

　　测试执行效率需要大幅提升

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

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

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

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

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

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

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

原文转自：http://www.testwo.com/article/583