Hi，大家好。DevOps、CI/CD、Docker、Kubernetes……好像全世界都在谈论这些技术，以至于你觉得即将到达NoOps阶段。别担心，在工具和各种最佳实践的浩瀚海洋中感到迷失是正常的，是时候让我们来分析一下DevOps到底是什么了。

一、DevOps介绍

1、简介

DevOps是一系列软件开发实践，强调开发人员（Dev）和运维人员（Ops）之间的沟通合作，通过自动化流程和工具，使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps强调一种打破固有的开发和运维人员之间壁垒的文化，强调开发、测试、运维等环节之间的沟通合作。DevOps 是讲敏捷开发实践扩展到运维阶段的一种实践方法，强调软件构建、部署、交付等的流程化。DevOps也是一系列的工具链，从编码、构建、测试、打包、发布到配置、监控等，基于一系列的基本原则和实践的方法论，形成一套工具化、自动化的工具链。它使他们能够构建，测试和部署应用程序，同时大大缩短产品上市时间。DevOps让软件过程既“快”又“稳”。快和稳体现在部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。

质量保证是瀑布开发过程中不可或缺的一部分，但在DevOps中仍然占有重要地位。DevOps的过程永远不会花费大量时间在编码和发布之间进行全面的测试创建。这也意味着团队将不断努力，以有效，快速地指定，构建，测试和部署软件。

测试量的增加也增加了对测试自动化的要求。DevOps需要测试自动化的备份，以保持敏捷和高效。测试自动化对于保持完整的质量控制并保持发布速度至关重要。无论如何，CI / CD管道中无法避免对自动化测试的依赖。

2、好处

测试自动化具有许多优势，企业可以利用这些优势来简化其DevOps实践：

• 消除人为错误的可能性；
• 在测试运行期间不需要人工干预；
• 获得更快的反馈；
• 更多设备覆盖；
• 自动化确保质量的一致性；
• 自动重新配置；

尽管具有多个优点，但是自动化测试可以完全取代手动测试吗？好吧，答案不是肯定的。但是，最好的方法应该是尽可能自动化，同时仅对不太关键的应用程序功能进行手动测试。这包括更新测试脚本，审阅，完成一次性测试以及测试可用性等。

持续实施测试自动化可以更轻松地根据历史数据量化自动化程度。但是，对测试领域不熟悉的人可以使用此标准公式来计算测试自动化的估计ROI。

测试自动化成本=工具成本+创建脚本的人工成本+自动化测试维护的成本

如果您多次使用自动测试，则每次使用后ROI都会相加。因此，如果自动化评估低于手动测试，则继续执行该策略，并找到尽可能多的自动化领域。

二、各测试阶段分析

1、单元测试

单元测试的重点是没有调用数据库，也没有Web服务的代码。由于关注范围较窄，而且对外部服务或系统没有依赖性，因此这些测试非常快。

单元测试仅专注于确保所有路径都通过代码并得到正确验证。考虑一种工资核算算法，该算法设计用于计算每小时工作的工人的工资。该算法将通过考虑工时数和小时费率来计算工资。但是，这种算法将需要多种类型的情况，包括：

• 标准工作时间（0–40小时）
• 加班时间（小时数大于40到公司每个时期的最大小时数）
• 纠正错误（负小时，负工资，超过最大小时数）

使用广泛接受的工具（包括NUnit，RSpec和JUnit等）来验证这种情况。通过使用公认的工具（包括NUnit，JUnit和RSpec等）进行单元测试，可以有效地验证这种情况。

2、集成测试

集成测试可以验证组件之间的行为。它包括检查数据库调用，Web服务或其他API交互之间的行为。

与单元测试相比，由于要处理大量的“仪式”以建立连接，进行身份验证以及处理网络和服务延迟，因此集成测试的速度较慢。集成测试应包含在更重要的验证中，而不是粒度验证中。

3、功能测试

功能测试旨在从功能上验证系统的一部分。与集成测试不同，功能测试要慢得多，因为它们贯穿用户界面的长度和广度。可以理解，它们比单元测试要慢得多。

由于性质脆弱而缓慢；让功能测试处理高价值案例是可行的。让功能测试处理过多的低级操作会大大缩短产品上市时间。

只有在交付团队之间密切配合的情况下，才能有效覆盖测试范围。确保有效的测试还可以确保在测试覆盖范围内避免任何形式的重复。防止重复测试对业务至关重要，以便可以使用昂贵的工具来解决特定问题。

那么，在什么情况下测试自动化最可行？

• 在要求测试关键的功能期间，用户可以清楚地看到其故障；
• 劳动密集型和重复性零件；
• 具有导致问题历史的功能测试；
• 测试需要大量数据的组件；
• 压力/负载测试；
• 针对不同的版本，数据集和浏览器进行测试；

4、自动化测试

企业需要尽可能地使测试阶段自动化，以确保所需的集成交付阶段能够有效地满足时间表。为了有效实施DevOps实践，团队需要在开发的早期阶段开始测试阶段，并在其整个生命周期中保持连续。通过从开始阶段检测问题就可以轻松实现所需的发布频率，当这些问题更容易解决且不花大钱时。

但是，您需要在开发周期的各个阶段使用不同的测试方法。您在不同项目上需要的不同类型的自动化测试包括回归，单元，性能，集成，负载，可访问性，安全性和生产监控以及功能测试等。

三、自动化与DevOps

1、有什么意义？

为了适应频繁交付的速度，测试工作需要更加高效，这就使得自动化测试成为必须。说到自动化测试，就不得不说一说测试金字塔。金字塔由下至上大致分为单元测试、接口测试、界面测试，在金字塔越底层发现问题解决成本越低，而越向上一层，解决成本越高，效率也会越低。所以，按照金字塔原理，在最底层单元测试方面，我们要做得足够充分，这里的充分并不仅仅是用例数量多、覆盖率高，更是要求测试质量要高。如果在界面测试发现了问题，我们需要从界面到接口、模块等等，需要多方配合进行问题定位。如果在单元测试发现问题，就是模块本身的问题，问题定位与解决速度就快的多。而自动化测试，可以使测试效率与质量都得到提升。不过自动化测试对测试人员的自动化测试能力、测试工具等都有一定的要求，是需要一定投入的，不过后期收益也是显而易见的。

2、如何推进？

在敏捷开发的生命周期中，我们通过每一次迭代来丰富和更新产品，以使其最大限度地符合客户对系统的需求。而测试的关注点在开发阶段，保证产品达到上线标准。引入 DevOps 之后，我们不仅关注产品的质量，同时也关注产品价值的及时验证。因此，我们不仅要测试左移，在开发、甚至设计阶段就发现问题并及时验证，还要测试右移，通过监控产品在生产环境的运行数据，来验证产品价值及时获得反馈，从而不断改进产品。

我们在推进 DevOps 工程的同时，也在不断探索应该如何在DevOps下更好的完成测试工作。在 DevOps 中，测试不仅仅用来及早发现产品问题，验证产品质量，更成为验证产品价值并获得反馈，以达到持续改进产品的目的。而测试也不再是测试人员的专属工作，整个团队都应该对质量负责，DevOps 更是对自动化测试提出来更高的要求，作为团队成员，每个人都应该提高测试技能，而测试人员应该更加关注自动化测试技能的提升，团队成员共同努力，才能更好的发挥测试的价值。

3、所需资源？

DevOps 工具都是开放源代码，并支持从容器构建和编排到微服务网络，配置管理，CI / CD 自动化，全栈监视等更多功能。以下列举一些当今最受欢迎的 DevOps 工具：

• Kubernetes：无需手动发布微服务，Kubernetes可以自动化生产中的容器组的部署，维护和扩展
• Docker：Docker 是一个免费的开放源代码平台，用于以轻量级容器的形式构建，发布和运行应用程序。容器打包了程序运行所需的二进制文件，库，配置文件和依赖项。
• Jenkins：DevOps 理念的很大一部分是寻找更有效地自动化和部署新迭代的方法。此目标的一部分是创建简化的持续集成和持续交付（CI / CD）管道。Jenkins 是一个开放源代码自动化服务器，带有数百个插件，可自动完成软件项目的构建，部署和测试。
• ELK Stack：ELK Stack 是由 Elastic 维护的Elasticsearch，Logstash和Kibana三个开源项目的结合。使用这三个组件，开发人员可以从任何来源获取和记录数据，并创建有用的可视化文件。
• Prometheus：Prometheus 服务器通过抓取 HTTP 端点来收集时间序列指标，并生成与该数据进行交互的系统，从而提供深度查询，可视化，存储和其他功能。
• Istio：Istio 是一种开源服务网格，基于 Envoy 构建，将其开放给插件和可扩展性选项。

4、总结

DevOps的过程依赖于自动设置，配置和部署，以确保更快地交付更新所有这些使自动化测试成为CI / CD的关键部分，因为在部署之前需要对每个代码提交进行正确的测试。测试自动化有助于在错误仍然很小的情况下以更快的速度查找和修复错误。它可以在几天甚至几小时内响应客户需求的同时降低风险。

自动化测试的优势在DevOps中提供了令人难以置信的高效率。但是，测试的一般实践仍未赶上现代技术的步伐。凯捷（Capgemini）的一项研究表明，大中型企业没有完全使用自动化。这项研究是通过采访500位高级IT主管进行的。该研究还显示，只有24％的测试用例是通过自动测试执行的。

测试自动化对于DevOps确保及时交付高质量交付物至关重要。但是，它永远无法完全消除对手动测试方法的依赖。正确的策略应该是在自动和手动测试之间取得最佳平衡，以得出最佳结果。