本文共 2961 字，大约阅读时间需要 9 分钟。
在2020年的夏天，我不止一次经历了项目发布前开发团队和测试团队连续加班工作到后半夜的场景。
开发和测试团队工作到很晚，他们集中精力，赶在最后期限之前需要完成一些非常重要的工作项：
- 开发团队快速修复缺陷
- 测试团队进行Retest
- 开发团队和测试团队进行缺陷Review，然后按照优先级和严重等级对缺陷进行重新排序，确定缺陷修复顺序
- 对于存在争议的和不能确认的缺陷进行再次Review，争论到耳红脖子粗，最后由PO进行调停
- 关闭缺陷列表
- 将即将发布的软件版本部署到Stage Server，测试团队最后运行回归测试
- 测试通过后，开发团队和Infra团队进行最后一次部署（至运营服务器），做发布之前的最后一次准备
- 为第二天一大早的发布，检查一切工作内容
之后发生了什么？没人知道。对于大多数开发和测试团队成员来说，Ops是一个黑盒子。更多的时候，他们忘记了行动中发生的事情，角色，责任和时间表。
在开发人员和测试团队经过延迟、问题和更改后的最后期限过后的几个小时，产品上线了。
这个时候，大家都因为连续加班和焦虑的工作状态已经非常疲惫了，除了想立刻回家洗个澡，补个觉之外，似乎没有什么值得让他们更感兴趣的事情了~
这个场景听起来熟悉吗？
DevOps应该是游戏规则的改变者。
DevOps对很多人来说意味着很多事情。但是对于测试团队来说，持续测试（Continuous Testing）是DevOps的首要任务。
而且，随着产品的交付和部署，Continuous Testing 不仅仅是一次又一次地重新运行同一组“完全回归测试”。
最近，测试团队被要求通过转向敏捷和scrum来提高他们的实践。DevOps将推动团队现在将他们的实践提升到更高的自动化程度、更多的技术测试和更多可利用的工具。
如果您的测试团队已经有了成熟的敏捷实践，通过持续的测试，他们可以进一步成熟，最终加速产品发布。
从CI开始，测试团队加入了自动化的冒烟测试（Smoking Tests）的过程。对CI的严格看法是关于自动化构建过程。然而，对于今天从事CI的人来说，这仅仅是一个开始。
使用Jenkins等工具的CI的实际情况是，在自动化构建过程之后，单元测试将重新运行，自动冒烟测试（在用户界面、API级别或任何地方）将运行，许多公司将在此基础上构建，以包括在测试环境中自动重新运行完全回归，然后对一些虚拟机自动运行一些测试集。这种在词的层次上不断增长的“威严”正在成为一种普遍的做法。你可能会问，“这不是连续测试还是接近连续测试？“CI是基础”。它从那里生长。
连续测试是一个精益过程的质量在每一个步骤。它包括User Story、测试环境、单元测试和性能测试。它是“每一步都在测试”，而不是最后的“质量保证”。
它还将测试任务从最后的操作转移到更早的测试和持续。CT也增加了更多的任务。
持续测试（CT）的成功在于它能够让每个人都参与进来，而不仅仅是测试团队。
在正确的环境中，在正确的时间运行正确的测试从来都不是一件容易的事。
在敏捷开发中，单元测试、性能测试、安全测试、功能测试和工作流测试是每个人的责任。它是连续测试的基础。
连续测试的测试策略与敏捷测试策略有很大的不同。在敏捷环境中，测试通常依赖于在部署之前的回归或Sprint来进行更大、更长的测试，然后由运营团队在一个临时环境中进行他们自己的性能和安全测试。
在DevOps和“Shift—Left”方法中，所有这些测试都需要作为测试团队TestSuite的一部分更早、更频繁地运行。
到目前为止，我们已经使用持续集成环境运行了开发人员单元测试和自动化Smoking tests，这是一种经常运行的自动化的完全回归测试。
除了手动测试之外，这些测试是sprint期间新的User Story开发的正常部分，继续是持续测试的一部分。
连续测试从这里开始变得更大。
Ops/IT通过虚拟化、虚拟机、容器、云环境等为测试团队构建环境和数据。测试团队将在更早的时候，针对与生产中相同的虚拟化环境，实现更多自动化并运行不同类型的测试。
这个想法是将过去的开发后期和最终测试转移到测试周期的早期。因此，消除回归或Release Sprint，为产品持续交付做好准备。
更长的工作流和集成测试现在必须自动化，并针对构建运行，以便持续交付，以及在开发过程中的不同点运行负载、性能和安全测试。这给测试和操作带来了许多需要解决的问题。
这就提出了一个问题，测试团队什么时候做可用性测试、运营测试、端到端测试（End to End Testing）、工作流测试和基于任务的测试？
这些测试专注于完成一个完整的用户任务，而不是测试一个单独的功能。这些是自动的吗？
长时间的测试往往中断得更多，自动化也更复杂。许多团队自动化他们的回归测试，但是从复杂、困难或长场景测试中排除。这些都需要更高水平的自动化技能。
今天太多的自动化测试都是验证单个功能的小型、孤立的测试。我们都知道这不是用户使用产品的方式。他们在不同的序列、组合和数据种类中使用函数。自动化和维护所有这些更复杂的测试当然不是一件容易的事情。
而且，许多测试团队并不负责运行性能、负载和安全测试。
在DevOps世界中，传统的测试团队可能仍然不是编写它们的团队。他们可以管理或执行这些新的测试任务作为他们的regu的一部分
利用微服务构建应用程序的趋势正在迅速增长。从API到面向服务（SOA）的体系结构，再到WEB Service，再到微服务，测试正在演变为对由服务组成的产品进行集成。
容器（Container）的使用加快了服务的使用。测试团队必须具备足够的知识、技能和工具来充分测试和自动化这些服务的测试。
如果你的测试团队没有适当的技能和工具，就需要将测试进行外包，寻找适合的外包测试团队，将测试服务外包。
等待通过UI测试这些总是可能的，但是一旦发生缺陷，通过UI隔离缺陷要比在服务级别困难得多。通过UI运行测试并不简单快捷。
我们在连续测试中自动化如此之多的最重要的原因是为了获得关于系统健康状况的快速而简单的反馈。跳过测试API或该服务级别上的任何服务都不再正常。
测试不再是QA团队或者独立的测试团队的责任。这是每个人的工作！
Scrum和XP实践上的大动作，比如TDD，或者简单地做一堆更多的单元测试，为整个团队更加负责的工作铺平了道路。团队中的每个人都必须进行测试。如果你不能，那么DevOps不适合你。
测试团队将需要成熟的自动化工程师和Ops/IT人员来支持环境、数据、VM、容器和测试团队的所有虚拟化需求。
如果你的开发和测试团队已经拥有成熟高效的敏捷实践、低维护成本的自动化测试和良好的持续集成过程，那么持续测试和DevOps是实现超效率的下一步。
通过更早地将Ops/IT及其过程引入开发过程、向左移动以及利用虚拟化和基础设施自动化的进步，企业中的每个人都从中受益。
（完）
转载地址：http://ktvdi.baihongyu.com/