投递人 itwriter 发布于 2018-10-11 13:26 原文链接 [收藏] « »

  作者:Ben Linders ,译者:刘嘉洋

  英文原文:How Continuous Delivery Impacts Testing

  如果要做持续交付,那我们必须关注我们写的代码的质量。不是所有团队都配备专门的测试人员,但如果有测试人员的话,他们会和开发人员紧密合作,编写在单元测试中无法覆盖的少数测试的自动化代码,并帮助开发人员搭建单元测试。

  Industrial Logic Canada 公司的首席执行官 Jeff Morgan 在 2018 年 eXperience Agile 大会上介绍了持续交付会如何影响测试人员的工作。InfoQ 会以问答、总结和文章的形式报道 eXperience Agile 大会。

  Morgan 说,持续交付的优势在于可以迅速在生产环境下进行实验。它可以帮助我们尽快测试用户对产品的想法,并收集数据结果。

  我们大多数的应用程序都会进行单元测试。Morgan 表示他们没有人工测试,一切测试都是自动化进行的。并不存在强化阶段,我们必须从一开始就保证产品的质量。

  Morgan 建议如果你需要专门的测试知识,那让测试方面的专家和团队一起工作,不要让专家闷头写测试。是整个团队需要测试,不仅仅是这个专家需要测试。

  Morgan 说,由于测试人员越来越技术化,开发人员也越来越注重测试的重要性,随着时间的推移,开发人员也会承担测试的工作,测试人员也会做一些开发的工作。

  InfoQ 采访了 Morgan,咨询了他持续交付会如何影响测试工作。

  InfoQ:当组织采用持续交付的方法时,软件搭建和交付的方式会有什么重大改变?

  Jeff Morgan:最主要的变化是我们不会再用传统的软件开发方式了,构建完软件之后就直接进入测试阶段。选择进行持续交付,一旦代码进行了源代码管理并遍历了部署管道,代码就部署到了生产环境下。

  这个重大的变更也表明,测试需要在开发的同时进行。实际上,我们通常不会把开发和测试认为是两个分开的工作。相反,测试是整个开发流程的一部分。这个变更还表明,我们会更多地依赖自动化:自动化测试、自动化部署和环境自动化。

  InfoQ:持续交付会如何影响我们对于质量的看法?

  Morgan:通常,我们会在软件开发周期的最后,在发布前才验证并完善软件的质量。这通常被称为强化阶段。但是我们如果采用持续交付,就没有必要设立专门的强化阶段,因为只要检查了代码就会立刻进入生产环境。 相反,在我们写代码的时候,我们要全程关注软件的质量。对于我工作的团队来说,这代表着我们写代码的方式发生了彻底的改变。我们会采用结对编程、测试驱动开发、减少分支、以及功能开关等实践。开发人员会更加注意测试和质量问题。如果团队中有测试人员,他们会主要关注少量端到端的自动化,并和开发人员结对进行探索性测试。与传统的仅由测试人员来测试不同,团队中的“每个人”都会进行非功能性需求的测试。很优秀的团队中,开发人员和测试人员之间并没有很多区别。

  我们也会使用大家所说的 DevOps 来帮助我们完善系统。通过搭建管道,用不同的方法运行我们所有的测试来降低风险,并通过测试来消除安全性、能力以及合规性的问题。通过容器和基础设施来避免环境方面的风险。通过对于小的变更的发布控制来避免对于用户和产品产生的风险。

  InfoQ:这会如何影响测试人员的工作?

  Morgan:首先我要指出在现代社会,不是所有团队都会配备专门的测试人员的。如果有测试人员的话,他们不会手动执行测试脚本。相反,他们要编写少量单元测试无法覆盖的自动化代码,帮助开发人员从金字塔最上面转移到最底端的单元测试。他们和开发人员合作非常紧密,并帮助搭建管道。他们会在整个开发过程中和开发人员结对,来进行探索性测试。一旦发现了缺陷,他们会和开发人员结对,立刻修复并部署修订后的版本。所有的工作都是和开发人员合作完成的。

  InfoQ:如果没有“测试阶段”的时间的话,开发人员应该做什么?

  Morgan:根据我的经验,和传统的“敏捷”相比,持续交付中会进行更多的测试。同时,在开发周期的不同时间都会进行测试,而不仅仅在最后才进行测试。我们非常依赖于自动化(主要是单元测试)和管道,来保证系统的质量。

  测试人员应该和开发人员紧密合作,保证软件的质量,保证缺陷几乎不会发生。测试人员通常要关注金字塔最上面的“用户测试”。他们还可以和开发人员结对,帮助他们获得并提升自己的测试能力。测试人员还需要帮助定义构建管道。

  有时候会需要专门的测试专家,比如安全或负载/性能测试专家。这种情况下,他们需要和团队讨论、创建并维护测试脚本在管道阶段的运作。

  在很多方面,管道是最接近“测试阶段”的存在。每次检入代码时,我们在这里运行所有测试,并最终将我们的代码部署到生产环境。尽管所有的管道都是不同的,但我发现各个团队之间总有些核心的通用模式。这里举例说明了团队可能会有的管道阶段:

  1. 搭建并运行单元测试
  2. 运行动态代码分析,如果质量没有达到的话就会失败
  3. 在功能开关开启的时候进行部署,只运行关注于未发布功能的测试。任何不在控制之内的后端系统都应该模拟。
  4. 在功能开关关闭的时候进行部署,运行其他的测试,实现回归。这个测试要很快运行,因此它们可以并行运作。同时,任何控制之外的后端系统都应该模拟。
  5. 在功能开关关闭的时候进行部署,在不同的浏览器和设备上进行小部分测试。后端需要模拟。
  6. 在功能开关关闭的情况下部署,运行一小部分测试,不需要模拟。这能保证完整集成工作的正常运作。
  7. 运行静态和动态安全测试。
  8. 运行负载和性能测试。
  9. 运行合规性测试,解决任何生产前的合规性工作。
  10. 部署到生产环境。

  如果任何阶段失败了,管道都需要停止。

  InfoQ:你对于想要采用持续交付的组织有什么建议?

  Morgan:有很多公司跟我说正在接受持续交付。当我问他们为什么的时候,他们大多数会聊到更快的交付或是质量提升。虽然这都是很好的目标,但我认为持续交付有更重要的优势。在我认为,采用持续交付的最重要原因是改变我们计划和交付产品的方式。持续交付可以帮助我们抛弃辛苦的、推测性的长期产品路线图,而改为采用“精益创新”方式来进行产品设计。它可以帮助我们根据真实用户的体验来修改代码,以交付完善的产品。这是我认为使用持续交付的关注点。

  对于正在使用持续交付的公司,他们需要了解 DevOps 并不是解决所有问题的方法。它当然是个重要的组成部分,但必须要和高质量的开发相结合。实际上,我建议首先提高质量,这需要一些时间。一旦实现之后,你可以考虑添加持续集成,这样开发人员可以尽快在搭建过程中获得反馈。随着时间的推移,你可以把它扩展为成熟的部署管道。

  一旦你的组织中有了质量保证的文化之后,你就可以为每天交付多次添加 DevOps 自动化了。

 
来自: InfoQ
找优秀程序员,就在博客园 收藏 新浪微博 分享至微信
标签: 持续交付

24小时阅读排行

    最新新闻

      相关新闻