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

ygfb 4年前
 

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 油Tube 上提供。

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