BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

持续交付会如何影响测试

| 作者 Ben Linders 关注 28 他的粉丝 ,译者 刘嘉洋 关注 0 他的粉丝 发布于 2018年10月11日. 估计阅读时间: 8 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

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

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

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

搭建并运行单元测试

运行动态代码分析,如果质量没有达到的话就会失败

在功能开关开启的时候进行部署,只运行关注于未发布功能的测试。任何不在控制之内的后端系统都应该模拟。

在功能开关关闭的时候进行部署,运行其他的测试,实现回归。这个测试要很快运行,因此它们可以并行运作。同时,任何控制之外的后端系统都应该模拟。

在功能开关关闭的时候进行部署,在不同的浏览器和设备上进行小部分测试。后端需要模拟。

在功能开关关闭的情况下部署,运行一小部分测试,不需要模拟。这能保证完整集成工作的正常运作。

运行静态和动态安全测试。

运行负载和性能测试。

运行合规性测试,解决任何生产前的合规性工作。

部署到生产环境。

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

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

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

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

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

查看英文原文How Continuous Delivery Impacts Testing

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT