虚拟化已经存在很长时间了。早在20世纪60年代,IBM就在大型机上支持虚拟化,以降低其多代系统迁移的成本。像Pascal,Java和C#这样的语言翻译成虚拟机语言,然后解释或进一步编译(即时编译)到实际的机器代码中。
从底层配置的细节中屏蔽应用程序仍然是虚拟化的驱动因素- 尤其是使用虚拟机。这有助于提供更高效的物理硬件使用。对于测试人员来说,虚拟机可以改变游戏规则。游戏的真正变化程度在很大程度上取决于组织如何决定使用虚拟机以及测试人员本身如何主动识别和利用虚拟机的可能性。
虚拟机通常需要从IT部门请求,本质上使测试团队受到IT要求的支配。测试人员将无法编写脚本,从图像动态生成虚拟机,对其执行测试,并在不访问虚拟机的情况下有效地将其退回。而IT部门可能会根据手动使用情况在物理机上标注虚拟机,但自动化测试通常比人类用户要求更高。
另一个问题是,很难预测虚拟机的时间行为。自动化测试通常很大程度上依赖于时间。在操作过程中,虚拟机可能会被换出,然后可能比自动化所需时间更长。我们发现以前在物理机上始终稳定运行的虚拟机上的测试会中断。为了解决这个问题,确保使用“主动计时”,等待可测量的事情,不要使用硬编码的睡眠,并为测试提供最大等待阈值。
管理虚拟机及其映像本身可以成为一项工作- 特别是在大规模使用虚拟机时,例如模拟被测应用程序的许多配置。与计划一起工作,让一个指定的人拥有它。需要回答的一些问题包括:您需要什么样的配置来定义和运行虚拟机,何时运行它们以及运行哪些硬件。
令人兴奋的新一轮虚拟化是“容器”。这些进程具有自己的预定义环境 - 文件系统,库和设置。这些容器已经被开源工具Docker广受欢迎,它允许它们在任何机器上移动并快速实例化并启动。以这种方式组织起来,这些容器形成了小型虚拟机,其大小以兆字节为单位,而不是成千上万的虚拟机所需的千兆字节。
容器的自然使用是在面向服务的体系结构(SOA)中运行服务器。容器为操作提供了一个很好的工具来组织配置并运行系统及其组件的实例。对于测试人员而言,容器可以更轻松地构建和维护功能与生产等效的环境。如果集装箱使用“大使模式”,这些好处会更好。它允许通过实物模型轻松替换主要服务提供商,如数据库或外部REST服务。当您使用基于操作的测试时,您甚至可以考虑通过操作来控制模型的行为。您可以使用它们让模拟捕获请求来自测试过程并生成预定义的答复。
虚拟机和容器可以为测试人员提供很多机会,特别是在他们工作的操作方面。一个深思熟虑的方法,在所有相关人员的支持下,对于实现这些效益都会非常有帮助。