持续交付会如何影响测试

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

InfoQ：这会如何影响测试人员的工作？

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

搭建并运行单元测试

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

运行负载和性能测试。

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

部署到生产环境。

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

查看英文原文：How Continuous Delivery Impacts Testing