不要再偷懒,请测试你的软件(借力 Docker)

  • Daniel Bryant
  • 谢丽

2015 年 11 月 27 日

话题:测试DevOps持续交付语言 & 开发

DockerCon EU 2015 大会上,Laura Frank作了题为“不要再偷懒,请测试你的软件”的演讲。Frank 指出,不管公司规模大小,也不管公司处于什么阶段,软件测试都至关重要,而将Docker引入开发流程有助于提高编写和运行测试框架的效率,使组织能够始终如一地向客户提供高质量的软件产品。

Frank 是一名来自Codeship的资深软件工程师。他在演讲开始时说,软件测试自首台用于计算的机器出现时就已经开始了。有位女士为第一台通用电子计算机ENIAC编写了程序,用于帮助美国陆军弹道研究实验室计算炮兵射击轨迹。她会定期拿一份已知正确的、手工计算的表格检查计算结果。Frank 指出,与其他技术(如结对编程、版本控制、代码审查和高可用架构)一样,测试对交付“可用于生产环境的软件”而言至关重要。

测试的目的包括升级应用程序并避免引入回归缺陷,验证更新的功能,证明重构没有破坏现有的功能。编写测试和测试套件本地运行耗时过长,正常开发流程受到干扰,测试环境难以正确配置,这些往往会让人沮丧。Frank 提出,将Linux 容器Docker 工具箱引入测试创建和执行过程可以部分地缓解这种沮丧。

Docker Compose使用户很容易就可以创建一致的、可重现的容器化环境。Frank 表示,许多软件开发人员都使用 Docker Compose 创建本地开发环境,但却没有将其用于软件测试。在测试中使用 Docker 同在开发中使用 Docker 有同样的好处,如创建可预测、可重现的环境,这对质量保证过程非常有益。

Docker 可以提供可预测且可重现的测试环境。就是这样。

Frank 提醒说,在将 Docker Compose 用于测试时,可能需要对其工作流做一些修改,甚至需要使用一个不同的 Dockerfile 指定不同的环境变量和运行目标,Docker Compose 通过“docerfile”属性提供这种支持。当容器、应用程序和存储配置复杂时,要注意避免初始化和执行竞态条件。

Docker Compose 的 docker-compose up 命令可以用于执行一个编入 Compose YAML 配置文件的自动化测试套件,也可以使用 Compose 的run命令一次运行一个服务,比如:

$ docker-compose up
$ docker-compose run -e “RAILS_ENV=test” app rake db:setup
$ docker-compose run -e “RAILS_ENV=test” app test-command path/to/spec.rb

Frank 提到,持续集成与测试相辅相成,依赖 CI/CD 而测试覆盖率不足通常会出问题——与在生产环境中发现缺陷相比,开发人员更愿意看到持续交付管道运行失败。

需要注意的是,运行测试的环境与生产环境差别越小越好。Frank 认为, 如果应用程序将来会运行在容器中(并且在容器中开发),那么构建管道中的测试也就必须在容器中进行。为此,开发人员可能会倾向于运行“Docker-in-Docker”。Frank 指出,任何考虑这样做的人都应该读下Jérôme Petazzoni的著作,比如文章“将 Docker-in-Docker 用于 CI 或测试环境?请三思而行”。

Frank 认为,在开发过程中使用容器时,很容易错误地将容器看作一个运行特定负载的“小型虚拟机”。然而,如果能更准确地将容器视为简单 OS 进程,那么测试过程就可以获得额外的好处。例如,需要在容器化应用程序上运行的多个测试可以并发执行。在 DockerCon 欧洲大会质量改进主题的基础上,Frank 提出,可以增加一个并发构建管道,当质量下降时(比如测试代码覆盖率降到一定水平之下,linting错误增加,或者违反ratchets中的规则),使构建失败,以此保证软件的质量。

Frank 引用Edsger Dijkstra的话对演讲进行了总结。他表示,虽然测试至关重要,但它并不能保证开发出的软件没有缺陷,应该恰当设定测试预期。

测试是一种显示 Bug 存在的有效方法,但却不足以显示它们不存在。

读者可以从 SlideShare 上下载 Frank 演讲用的幻灯片,演讲视频稍后将在Docker YouTube上提供。

查看英文原文:Stop Being Lazy, and Test Your Software (with the Help of Docker)

测试DevOps持续交付语言 & 开发