自动化是DevOps成功的前提。特别是在向测试人员和开发人员提供快速，准确的反馈，从而能够对错误，错误和不断变化的需求做出快速反应时，测试自动化是关键要素。
开发运维是一种将软件开发与软件操作结合起来的实践，是将高质量软件发布到生产中的一种手段。
开发运维人员促进软件生产中涉及的不同角色之间的协作和透明性：开发，测试和运营。这包括定义发布管道，为团队构建或采用正确的工具，以及（最重要的是）尽可能多地自动化发布管道。
开发运维发布管道
开发运维的骨干是发布管道的定义。发布管道包括各个阶段和检查（门），一段代码或软件在从单个开发人员的计算机进入生产过程中必须经过这些步骤。管道通常由“协调器”控制，以确保事情以正确的顺序进行，并且在阶段之间进行正确的检查。
管道协调器的示例包括Jenkins，Atlassian Bamboo，TFS / VSTO和TeamCity。
如下图所示，发布管道通常包括：
- 生成代码的个人开发人员环境
- 在构建阶段，准备使用持续集成（CI）发行代码
- 专门用于各种类型测试的测试阶段，包括功能UI测试
- 生产环境
为了满足持续交付管道的要求，自动化的功能UI测试至关重要。
但是，如何将自动功能UI测试集成到发布管道中？
实施自动化时，常见的错误是选择一种不适合发布管道的工具。管道应该决定工具，而不是相反。
如何在整个发布流程中自动化测试
通过正确的设置，可以在多个阶段将测试自动化平台与发布管道集成在一起，以实现多种目的。
以下是发布管道中您可以并且应该使用测试自动化的三个阶段示例。
1.从回归测试开始
这是自动化的主要且最常见的目标。在相对稳定的测试环境中进行“经典”回归测试。
可以从管道协调器触发自动回归测试，也可以根据需要按计划运行。
2.验证您的构建
测试自动化可以支持DevOps的第二个领域是针对CI服务器运行一组小的测试用例集。这将有助于回答以下问题：“ CI服务器的最新版本是否可以测试？”换句话说，此构建是否已准备好移至“测试”环境并值得花费实际的测试人员资源？
除了运行单元和集成测试外，此验证练习还为开发人员提供了快速的反馈。
3.实施非侵入式验证
测试自动化在发布管道中的第三个也是最后一个应用是验证生产环境中软件的单个元素或部分。
针对Production运行的测试用例应是非侵入性的，这意味着它们不应留下任何痕迹或干扰软件的主要用途。取而代之的是，这种验证旨在在软件用户遇到问题之前捕获诸如意外中断，故障等问题。
下图显示了这三个如何在DevOps设置中利用自动化功能UI测试的示例。
开发运维应该设置什么作为测试自动化平台的标准？
从DevOps的角度来看，下一步是查看功能UI测试自动化的平台要求。
在这方面，您应该特别注意三件事：
- 积分： 确保平台易于与您的管道集成。持续集成自动化工具应随附最常见的管道协调器和/或文档齐全的API的相关插件，以允许协调器控制测试自动化平台。
- 执行时间处理时间： 在全自动管道中，运行测试所需的时间至关重要。如果运行所有测试用例需要48个小时，则该管道将无法正常运行，并且在实践中将无法正常工作。确保测试自动化平台可以扩展测试用例的执行，以将运行时间保持在最低限度。
- 控制和灵活性： 成功的自动化需要高度的灵活性，而又不影响对管道的控制感。测试自动化平台应该使在各种环境中，出于各种目的以及在各种时间轻松地定义和执行不同的测试用例集合变得容易。例如，某些环境比其他环境更稳定，可以进行更频繁的测试，而其他环境仅用于快速验证和反馈。
LEAPWORK：为DevOps构建的测试自动化平台
的基本愿景 LEAPWORK自动化平台 基于DevOps管道的思想。
LEAPWORK自动化平台 带有全面的公共REST API，允许第三方系统触发测试用例的集合并检索格式正确的响应。 LEAPWORK也可以使用最常见的管道协调器（Jenkins，Atlassian Bamboo，TFS / VSTO，TeamCity等）的本机插件。
所有这些使将测试自动化作为发布管道的一部分变得非常容易。
下载白皮书：DevOps和测试自动化
您想要了解更多有关如何是否通过共享的自动化所有权跨CI / CD管道快速反馈？然后下载白皮书：
