# 测试人员需要成为devops工程师吗 这确实是个非常值得讨论的话题。 测试人员究竟是不是需要成为 devops 工程师，我的答案是不需要，但又需要。 测试有时候在开发团队会不被开发同事所重视，甚至有时候会背上效率低下的骂名，我认为其中一个很重要的原因是：测试的工程化程度不高。 想想开发的一些核心行为 - 写设计文档和方案：这个工程化程度不算太高，但是如果是写接口文档，那么很多工具都支持从代码生成文档，这个是可以工程化的； - 搭建本地开发环境和测试环境：可以工程化。 - 写代码：本身代码就是工程化的一环。 - 构建发布产物：可以工程化。 - 发布：可以工程化。 - 监控和告警：可以工程化。 再看测试的核心行为 - 用例编写：很难工程化； - 用例执行：手工执行用例很难工程化； - 测试数据准备和清理：可以工程化； - 提出 bug 并进行跟踪：很难工程化； 我们再看看 devops 的概念，DevOps 将软件开发（Dev）和 IT 运维（Ops）的工作进行整合和自动化，旨在提升并缩短系统开发生命周期。 自动化是 DevOps 中的重要部分。软件程序员和架构师应使用“适应性函数”（fitness functions）来确保他们的软件保持在预期状态。 简单来说 devops 就是运维工程化，而工程化最好的体现就是运维的自动化。 ## 测试需要工程化 测试同学其实可以不用成为专职的 devops 工程师，毕竟这是另一个研发角色，负责的内容和范围也不太一样。 但是测试同学确实是可以借鉴 devops 文化中的工程化思想，让测试变得更具工程化一些。 然而我们看到，核心的一些测试行为确实很难进行工程化，这样一来，我们就需要扩大我们的工作半径，将**一切可以提升质量的行为**都纳入到我们的工作职责中来，而这一系列的行为里，有一部分是可以进行工程化的。 最典型的可以进行工程化质量实践就是构建 ci/cd 流水线。 测试同学可以通过构建 ci/cd 流水线进行自动化的准出测试，如果对代码库的 precommit hook 进行工程化定制的话，还可以对准入进行控制。 流水线的输入是代码，输出也是代码，其中执行的各种任务也都是代码实现的，所以如果测试同学想要构建一条对质量有所裨益的流水线，那么下面的一些技能还是需要具备的。 - 一定的代码能力 - 一定的工具整合能力，ci/cd 的工具很多，有时候我们不需要开发，只需要接入和定制就好 - 一定的质量规划能力，加什么准入和准出？如何保证各种检查不会拖慢流水线的执行？ ## 小结 简单来说，会代码，有工程化思想，有构建高质量产出物的工具和思路，这类的测试同学应该还是会受欢迎的。 但不要忘了，测试同学的核心任务还是质量保障，ci/cd 只是质量保障的一种实践，而不是质量管理的全部。 ## 其他人的观点 最近看到了一篇文章对测试人员要不要成为 devops 人员进行了讨论，这里顺便放上来，供大家参考。 原文地址: https://visible-quality.blogspot.com/2024/09/do-testers-need-to-be-devops-engineers.html 在我职业生涯的某个阶段，我逐渐专注于理解测试环境。这一切始于观察子系统之间的关联，以及识别哪些数据可以兼容。在保险行业，进行有效测试没有其他选择，尤其是当时一个新的 IBM 大型机测试环境的搭建就耗费了 100 万和一年的时间（我也经历过）。我已经不太记得那时用的货币是芬兰马克还是欧元了，只记得那种对项目的巨大责任感，因为我需要确保这个耗资百万的项目能够顺利进行。那段经历让我从此更加重视测试环境，不仅对工作站、服务器和版本有了更清晰的分类，处理这些事情也变成了日常工作的一部分。 当云计算后来进入我的工作领域时，这种对测试环境的分类和基础知识变得更加重要。了解存储、计算和专业服务的位置，设置这些分布式服务之间的连接和依赖关系，再结合我们已有的控制手段，以及那些我们意识到但无法控制的部分，极大地帮助我搞清楚自己在测试什么。 当时，我很容易判断出新项目的测试环境在每周的早期会比较顺畅，但随着时间推进，问题会逐渐显现。我能分辨出哪些症状是由于测试环境规模过小，哪些是由于数据和内存问题引起的，进而根据每周、每天的节奏调整测试方式。 今天我在思考这些问题时，看到有人问测试人员是否需要理解 CI/CD，以及在这方面需要具备哪些具体技能。 我的很多同事在测试自动化领域深耕后，逐渐走上了 CI/CD 流水线的道路。他们意识到，手动在自己电脑上运行的程序化测试并不能真正实现自动化。只有在变更之后立即运行测试，才能最大化其价值，而这需要将测试设计融入 CI/CD 流水线中。许多同事每周只有不到一天的时间进行实际测试，而随着测试每晚自动化运行，测试环境逐渐演变为通过 Docker 进行编排的架构平台，基础设施的任何变更都需要通过修改代码来完成（即基础设施即代码）。 我依然会与一些对测试环境理解停留在我当年水平的测试人员合作。他们能区分出两个相同但地址不同的测试环境，并根据经验法则判断应该关注哪些问题。像我当初一样，他们依靠特定的时间模式来控制测试时遇到的版本。这类测试人员可能会设计出不允许变更的环境，因为安装环境常常不可用或超出他们的控制范围。他们需要了解 CI/CD 作为发布和调度的机制，但无需深入理解其内部运作。 如今，我越来越多地与那些设计并优化流水线的测试人员合作。他们不一定亲自完成所有更改，但需要能够读懂流水线，了解其中的运作。流水线中的错误往往决定了他们一天的工作内容，他们需要找到错误的根源。大多数人只是在已有范例的基础上配置新的作业，而少有人会去创新引入新工具。然而，很多人似乎非常喜欢这一部分工作。 此外，还有一些人专注于流水线本身。测试对于他们来说只是一种占位符，他们很少有时间考虑测试的覆盖范围。他们的工作就是围绕流水线展开，让流水线在更好的基础设施上运行，添加新工具，升级现有工具，构建支持团队的各种设备。这些人即使有测试背景，也往往会称自己为 DevOps 工程师，以突出他们对基础设施和流水线的关注。 在招聘测试人员时，你可能会遇到不同层次的技能水平。许多人追求中间地带的平衡，我们也越来越希望招聘到那些既掌握流水线赋予测试环境的控制手段，又能有效进行测试的人。 与此同时，我们也在寻找一种平衡，既要求人们具备足够的知识，又能专注于测试工作，而不仅仅是维护流水线。