​​

在我测试生涯的某个阶段，我专注于理解测试环境。这一切都从看到子系统之间的连接以及识别兼容数据开始。毕竟在保险行业中进行有效测试没有别的选择，我也经历过一个全新的IBM大型机测试环境，耗费了100万资金和一年的时间。我不记得那时我们还在使用芬兰马克作为货币单位，还是已经进入欧元时代了，我只记得那种对项目负责的强烈责任感，尤其是在涉及数百万资金的情况下。那段职业生涯使我对任何测试环境都保持了高度的敏感性，并使分类工作站、服务器和版本成为日常例行任务。

当云技术后来进入我的世界时，对测试环境的分类和基础设置变得特别有用。识别存储、计算和专用服务的位置，建立这些地理上分散且按需配置的组件之间的连接和依赖关系，以及管理我们已有和未曾拥有的控制措施，极大地帮助了我理解自己在测试什么。

我很容易理解，我刚开始的新项目在一周初期会有更好的测试环境运行，我们可以预期随着一周的进展会出现一些问题。我能够预见到由于配置了较小的测试环境而可能出现的症状，数据和内存的结果会是什么，我也能根据我所识别的测试环境的每周和每日节奏来设计如何测试特定的内容。

今天我想到了这些，因为我看到有人问：“测试人员是否需要了解CI/CD？CI/CD的具体内容是什么？在这方面我们应该具备哪些具体技能？”

我许多专注于测试自动化的同事，在意识到手动在他们机器上运行的程序化测试无法真正实现自动化后，走上了CI/CD流水线的道路。如果在更改完成后立即运行测试，能够避免引发问题的可能性会大大提高，这就需要将测试设计到CI/CD流水线中。许多同事发现，他们每周几乎只能花一天时间实际做测试，因为每晚运行的测试会转化为优化后的流水线集合，环境变成了docker化的协调平台，基础设施中的任何变更都需要通过修改代码来实现（基础设施即代码）。

我仍然与一些测试人员合作，他们对环境的理解与我曾经的相似——能够识别两个不同但相同的测试环境，并能通过一些启发式的方法来决定关注什么。像我在整合这些CI/CD流水线的思维之前一样，他们通过环境的特定时间模式来控制他们在测试中所体验的版本。他们可能会设计出不允许变更的环境，因为安装操作通常是不可用的，或者是在我们理解之外的。这些测试人员需要理解CI/CD作为发布和调度的机制，但不会深入其中。

越来越多的情况下，我与那些设计和改进流水线的测试人员合作。虽然他们不需要自己进行所有的变更，但他们需要能够阅读流水线代码，了解流水线中的动态。红色（错误标识）总有其原因，并且驱动他们的工作日去查找红色来自何处。大多数在这一群体中的人都配置新的工作任务，但通常不会走得更远，只有少数人会引入新工具。而引入新工具这部分，似乎是人们特别喜欢做的事情。

然后还有一些人生活在流水线中。测试对于他们来说只是占位符和框架，他们很少有时间自己去思考测试的覆盖率。为流水线工作就是他们的工作，让它们在更好的基础设施上运行，添加新工具，升级现有工具，构建所有支持团队的机制。这些人，即使有测试背景，也往往称自己为DevOps工程师，以强调他们对基础设施和流水线的关注。

在招聘测试人员时，您可能会遇到不同层次的知识水平。很多人都在寻找中间地带。我们越来越期望人们具备了解流水线对测试环境的控制和测试选项的知识。

越来越多的时候，我们在寻找一种平衡——让人们拥有足够的知识，同时仍能专注于测试，而不仅仅是构建流水线。