TestOps 完全指南

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。
众所周知，DevOps 不是一个人ーー它是开发人员、操作、测试和业务单元之间的一组复杂的流程、技能、通信和工具。DevOps 几年前凭借《凤凰计划》(The Phoenix Project，2013)和《 DevOps 手册》(The DevOps Handbook，2016)进入科技大舞台，以解决可伸缩性问题，并为科技公司提供更快发布软件的机会。它关注于关闭开发和操作之间的循环，并通过持续开发、集成、测试、监控和反馈、交付和部署来驱动生产。

技术领先者现在已经转向它，打破了开发人员和运营人员之间的沟通障碍，减少了新功能的上市时间。DevOps 负责这样一个事实，即我们都使用 CI/CD 系统、虚拟化工具和各种自动化来每天发布两次更新。

一如既往，通往当前状况的道路并不容易。软件开发的整个领域都在努力跟上新的步伐: 安全、基础设施，当然还有测试。这就是 DevSecOps、 NetOps 以及最终的 TestOps 的发展过程。

TestOps 是专注于测试的 DevOps 的一个子集，它基本上是一组技术和方法，允许项目中所有测试(不仅仅是 QA)的完全透明性和可控性。这就是为什么我们需要一个新的“ something Ops”。

十年前，发行量很大，也很少。首先，编写代码; 然后构建和测试代码。在后期阶段发现错误可能导致全局重构，甚至延迟发布。随着时间的推移，市场被那些学会了如何更快发布的公司所领导。

加速开发周期的答案是 DevOps 和敏捷。两种方法都侧重于分解大型发布: 管道变得更加复杂; 出现了质量门; 单元测试和集成测试完全覆盖了每个微服务的代码; 发布开始在金丝雀版本上进行测试。每组测试都变成了一个决策点: 测试通过了; 测试失败了，但是我们可以在生产环境中发布; 测试失败了，我们必须回滚。

问题是，在不同的框架和编程语言上进行的几种类型的测试(web、 API、 canary)的结果(这些测试在几个 CI 系统上重现)将完全脱节。它们需要在一个地方进行解释、聚合和收集，以便做出决策。下一步是在一个地方统一对运行、重新启动、监视和管理整个测试动物园的访问。

这就是 TestOps 的作用: 在整个 DevOps 流水线上进行自动化的、透明的、可访问的和可管理的测试。我们有合适的工具吗？

让我们想象一个团队，建立一个应用程序。该应用程序有前端、后端和移动版本ーー每个部分都由专门的团队开发。那么每个梦之队是如何工作的呢？通常，一个团队中有10个以上的人; 让我们看看在这样的团队中发现的典型角色。每个角色可以由几个团队成员代表。

• 开发人员，负责编写代码，重构和拉请求管理
• 开发人员，负责编写代码、重构和请求管理
• 项目经理，负责开发进度和敏捷流程
• 质量保证工程师，负责发布测试和最终产品质量
• 自动化测试工程师(AQA 工程师) ，其工作是将测试自动化推向极限
• 操作人员/管理员，负责质量检验和管道维护

那么，在这样的团队中测试是如何工作的呢？在这样的流程中打开了许多协作机会。下面是 DevOps 中自动化测试人员的主要任务:

• 首先，我们的自动化测试工程师涵盖了后端、前端以及与本地自动化测试的集成协议。在此上下文中，本机意味着测试使用与被测代码相同的技术堆栈。它还允许将测试存储在与代码相同的存储库中。至于它是一个单一的回购，开发人员通常渴望帮助 AQA 工程师与代码审查和复杂的测试的开发
• QA 经理有机会在拉请求阶段检查所有的测试: 检查客户场景和角落案例覆盖率，开发了多少个测试，等等
• 作为回报，AQA 工程师从 QA 的角度检查开发人员的测试(单元测试和集成测试)
• 自动化测试工程师还负责测试基础设施。当然，底层维护(如 Docker 或 Kubernetes 配置、构建脚本或测试环境设置)仍然由操作人员负责。但是，配置 Selenium 网格、浏览器或数据库数据管理仍由自动化测试人员负责

好吧，但如果 AQA 已经是个测试员了我们为什么还需要专门的 QA 人员呢？自动化测试人员负责低级别的测试和质量，而 QA 人员则负责监督发布管理过程。

• 第一个区域手动测试经验专业知识在 TestOps 中，实际上是和项目经理一起做决策:什么正在测试，什么没有? 覆盖分析和安全的释放与 AQA 工程师我们发现了什么漏洞，它们有多重要？我们能否将当前的测试结果发布出去？
• 另一件事是大规模特性的跨团队沟通。QA 经理建议工程团队用测试覆盖特定的用例和跨团队 API
• 探索性测试将长期手工操作，而回归测试和验证套件将100% 自动化。许多未编写脚本的测试必须在发行版上执行。通常，这些是新的复杂特性测试，将在下一个 sprint 中自动化

听起来不错，但是怎么用呢？让我们来看一个整个流程的例子及其优缺点:

• 开发人员创建了一个新的特性分支，当工作完成时，他们会有一个带有一些全新代码和一堆自动化测试的请求
• AQA 工程师审查公关，并增加一些更多的测试，如果必要的。开发人员经常测试快乐之路，并且不太关心编写包含几十个参数和变量的全面测试
• 之后，QA 经理从业务角度开始最终的测试评审: 测试覆盖哪些产品需求。QA 经理不关心运行哪些精确的测试; 他考虑的是特性和用户描述的覆盖范围。当然，他们有一些清单。为了确保万无一失，所有东西都经过测试了，对吧？
• 如果测试运行为绿色，则合并分支。如果没有，团队就会修复问题并进入第2步。此时，每个 bug 都会链接到下次要添加到回归运行中的问题
• 流水线上的所有测试都允许我们自动生成测试文档和分析。此外，大多数测试是自动化的，因此预期的测试持续时间很容易预测

看起来像个梦之队，对吧? 但我们怎么才能到那儿呢？

在本文中，我们将经历 QA 团队发展到 TestOps 的所有阶段，从初创企业到企业。我们将努力覆盖每个阶段的目标、阻碍因素和工具。

这是每个质量保证部门通常的起点。大多数团队甚至没有意识到这个舞台的存在，而它往往是 QA 未来的基石。

1. 团队。有时，在这个阶段甚至没有一个专门的 QA 人员ーー产品所有者或经理自己检查所有东西
2. 目标.此时的主要目标是创建 bug 报告过程。Bug 报告模板将会存在很长一段时间，所以深吸一口气，让它尽可能明确，尽可能容易为开发团队修复。 另一件需要记住的事情是将测试用例放在某个地方。它们可能很短而且缺乏细节; 主要思想是获得验证测试持续时间的粗略近似值，并为进一步的步骤设定目标度量。记录的错误数量。密切关注过程，保持每一个错误正确的记录和固定在特定的流程
3. 工具. 电子邮件、 Slack 或任何其他允许共享和跟踪错误报告的工具。除了在测试人员的记事本中，测试用例通常不会被记录在任何地方
4. 挑战. 当团队规模较小时，直接将 bug 传递给开发人员并在 Slack DM 中获得修复通知总是比较容易，但是这种方法将在下一阶段带来混乱
5. 过渡点。 该团队已经建立了一个基本的 bug 检测和修复流程

这是一个完全预 DevOps 测试阶段，一些团队会在这个阶段停留很长时间，特别是那些不以快节奏的开发过程或基于项目的开发过程为目标的团队。在这个阶段，整个想法就是手工测试可以按照一定的发布周期进行。

1. 团队. 在一名高级人员/质素保证主管的指导下，数名初级至中级质素保证人员
2. 目标. 放弃“我已经测试过了，让我们部署吧!”接近。此时，您需要为每个测试设置一个所有者，并记录运行的结果，以便您知道谁应该对错误绿色的运行负责。不是为了惩罚，而是为了进行建设性的回顾测试透明度。文档、通过失败率以及将 bug 与问题跟踪器联系起来将使整个团队都能够访问测试过程。没有人会深入研究在 Excel 中存储和运行的方案可靠和详细的测试用例。这是文档要求的一部分。由于您有几个人在处理一个套装，所以要为测试用例从一个所有者转移到另一个所有者时的情况做好准备。在这种情况下，测试用例应该包含所有步骤、注释、元数据、环境描述等
3. Metrics 度量.测试用例执行的频率。测试运行的频率越高越好合格率。指示测试质量的度量。请记住，“全部绿色”可能意味着测试跳过错误，而不是完美的代码首先报告生成和使用情况。尽量确保测试结果被所有人使用，而不仅仅是经理或者测试团队领导。开发人员多久查看一次问题和测试用例？操作人员认为手动测试套件比烟雾测试套件和金丝雀释放更有价值吗？
4. 工具. 此时，团队需要一个工具来跟踪所有的手动测试活动，基本上就是一个 TMS。通常的功能是存储和管理测试用例、团队合作控制和报告TestRail,跟踪和组织手工测试工作 PractiTest 是另一个令人惊叹的端到端 TMS，它提供了很多用于手动测试的团队管理和报告功能Qase.io, 一个现代的和迅速发展的 TMS 值得注意
5. 挑战. 测试速度仅与劳动力有关。您的回归套件增长得越大，需要按时运行所有测试的人员就越多。目前缺乏人力资源和经验丰富的工程师使这一挑战更加严峻
6. 过渡点 我们有设计良好的测试用例存储和团队管理过程

一个可选的演进阶段，作为开发高级 QA 工程师团队的一种合乎逻辑的方法。其主要思想是在整个公司的测试中建立牢固的信任。

1. 团队. 几乎与前一阶段相同。主要区别是团队进入高级
2. 目标. 效率监测和优化。手工测试很难优化，但是有很多半自动化的工具可以加快高级测试团队的速度。记住，他们对日常任务感到厌烦，所以要想办法使其自动化
3. 工具. 在这个阶段，工具解决了一个也是唯一的任务: 就我们已经构建了一个紧密的团队而言，我们的任务是减少人为因素，并在测试中获得尽可能多的可预测性。因此，团队应该开始寻找自动化原子测试人员活动的工具，比如屏幕截图、点击测试场景等等Postman: 一个很棒的 API 测试工具，它允许专注于测试，而不是执行过程 FakeData: 手工测试表单很无聊。使用测试数据生成可以节省时间并消除表单测试中的人为因素。LambdaTest 和 Response: 不要浪费时间在测试不同分辨率的多个浏览器上。机器人在这方面做得更好(而且它们从不感到疲劳!)
4. 度量.释放测试持续时间. 此时需要衡量的最重要的事情是通过半自动工具和日常任务自动化可以达到的时间和精力优化水平。为了能够估计最终的发布时间，为每个运行的测试套件获得透明度和可预测性是很重要的
5. 挑战.开发团队(单元测试、集成测试)和 QA 团队的自动化测试通常仍然是不连接的. 测试过程优化和规模仍然受到员工数量的限制
6. 过渡点 业务需要团队以比看起来可能的更快的速度发布版本

这是公司迈向自动化的第一步。通常，此阶段包含基本步骤，如选择测试框架、测试执行环境和覆盖度量。但是，就像 M1步骤一样，有一个看不见的巨大目标ーー为进一步的自动化发展奠定基础。

1. Team 团队. 一个手动测试人员团队得到一个中高级自动化 QA 工程师
2. Goals 目标. 这里的目标可能看起来很复杂，但它们为进一步发展提供了坚实的基础:通过自动化 e2e 测试覆盖基本 API。展示测试自动化是如何提高整个测试过程的速度的一个容易获得的成果。一组 UI 测试需要花费更多的时间和精力，但是效率低于手动测试。但是，一组包含数据生成和模拟的 API e2e 测试将涵盖手工团队的日常工作，这是在长期自动化运行开始时获得赞赏和支持的一个很好的方式。创建一个快速手动测试用例自动化的过程。如果可能的话，这里的最佳方法是通过进一步调优的自动样板代码生成
3. Tools 工具. 这个阶段将需要 QA 和开发团队之间的一些协作，因为自动化 QA 人员将需要一个测试实例和 CI 管道来执行。提前考虑一下. 测试环境: 通常，一个单一的 E2E 测试工具是由自动化工程师选择的。这里最常见的解决方案是 Selenium 和 Playwright。这两个工具都是伟大的无头浏览器测试框架，可以启动手动测试用例自动化IDE的排序: 选择通常在 JetBrains 或 MS 产品之间，这取决于所选择的工具
4. Metrics 度量.在这个阶段，我们需要对自动化结果抱有信心，因此度量标准将集中在这个目标上:API 测试的稳定性 自动化测试是愚蠢的ーー这是所有团队都会感到烦恼的第一件事。即使是网站布局或 API 响应的细微变化也会导致失败。因此，准备好关注测试的稳定性和可维护性自动化测试使用。尽可能频繁地执行测试！在不同的环境和条件下，每个请求、合并和发布。如果测试处于闲置状态，它们就不会带来任何价值。没有价值，没有进步。开始考虑通过自动化测试来度量节省的时间。虽然测试很愚蠢，但它们快如闪电！自动方案执行比手动方案执行所需的时间少得多。这可能是显而易见的，但一个明确的时间节省措施与几十个自动运行是最好的方式来显示数量级测试加速的角度。测量自动化到手动测试迁移率。从长远来看，较高的比率表明自动化的进步。卡住的数字通常伴随着对自动化测试缺乏信任。 测量自动化到手动测试迁移率。从长远来看，较高的比率表明自动化的进步。卡住的数字通常伴随着对自动化测试缺乏信任
5. Challenges 挑战.尽管我们在这个阶段得到了第一个自动化套件，但是仍然几乎不可能预测到发布测试持续时间
6. Transition point. 过渡点 随着自动化测试用例生成过程和工具的建立，开始相信快速发布交付

在前一阶段的自然演变中，团队获得了更多的自动化工程师。这就是高达60% 的自动化项目陷入困境的时候，因为没有明显的方法可以进一步推进。此外，过去阶段的流程可能会给全栈测试自动化的发展带来混乱和冲突。

1. Team 团队. 几个中高级 AQA 工程师由许多初级队友陪同
2. Goals 目标. 使您的软件质量系统稳定:原子自动化测试。虽然从 A1阶段开始的一步一步的长期测试看起来很自然，但是它们带来了很多不利因素，从长远来看阻碍了您的团队的进步。原子测试更容易修复，彼此独立，并提供本地化的结果。这意味着每个失败的测试都能提供更精确的结果，并且能够很快得到修正ーー这是获得团队对自动化测试信任的强制性要求获得一个自己运行测试的接口。是的，您需要一个运行测试套件的“按钮”，并且您希望每个人都可以使用它。开发人员是否希望在其分支上运行测试？他们拿到了！操作人员是否希望在质量检查门处明确地重新运行测试套件？没问题。全程掩护。此时，团队应该实现100% 的回归和验证测试覆盖率。这些块非常适合于突出显示完全非手动测试的价值，因为它们通常有良好的文档记录，并且由易于自动化的测试组成
3. Tools 工具.此时，我们的目标是从测试中获得洞察力。这意味着我们需要报告和可观察性工具像 AllureReport 和 ReportPortal 这样的报告工具。正如在 M2阶段一样，一定要找到合适的工具来共享结果，并对自动化套件的执行进行一些控制。这两个工具都是很好的开源解决方案，可以很好地应用。全栈测试框架: Katalon，Cypress。选择一个全栈测试框架对于那些计划保持在 A1-A3测试级别的团队来说是有好处的，因为在专有的供应商基础设施中构建了广泛的功能监控: 设置 Grafana 实例可能有点麻烦，但它作为一个通用的开源分析和交互式可视化工具是有回报的。将即时结果视为用于测试的图表、图表或警报
4. Metrics 度量.重播。测试必须一直运行、通过和失败。你们是唯一进行测试的团队吗？这是危险信号！这意味着其他团队在您的测试中看不到任何价值。再次检查操作团队是否查看了您的测试结果，并在分支合并或发布时自己运行套件。 测试运行持续时间。时间本身并不重要。可预测性至关重要ーー获得测试套件运行的大致预期，以显示发布测试的新机会。 古怪。有时候测试开始变得有趣，并且通过了——在没有明显原因的情况下，连续几次测试都失败了。这样的测试应该是隔离的、调查的和固定的，这取决于它们不稳定的原因，也可能是基础设施问题。修复测试失败的时间。团队最终会得到破碎的测试。不管原因是业务逻辑的改变还是测试本身。重要的是我们能以多快的速度修复坏掉的测试。如果需要很长时间，没有人会等我们，所以我们会失去团队的信任
5. Challenges 挑战.测试基础设施通常是 QA 团队无法触及的。这个约束导致无法影响测试套件的执行时间和运行/重新运行的数量。这是保持 QA 基础设施开发的触发器. 更改手动测试人员的工作流程。随着测试越来越原子化，您将看到将大型手动测试用例映射到一组原子自动化测试是一个阻碍因素。将检查表用于手动测试是一个更好的解决方案
6. Transition point. 过渡点. 完全回归和验证测试自动化。一旦自动化完全覆盖了这些类型的测试，团队就有足够的时间考虑进一步的基础设施开发。 测试结果收集和报告自动化。这是另一种需要大量时间和精力进行自动化测试的工作类型

高级测试自动化团队是在测试团队的目标是获得对 DevOps 管道和测试基础设施的完全访问权，同时在测试本身方面变得非常熟练的时候诞生的。

1. Team 团队. 10 高级 AQA 工程师团队
2. Goals 目标. 获取您亲手操作的测试基础设施。测试不仅仅是编写测试ーー为了获得对测试基础设施的控制; QA 团队需要与 Ops 团队保持联系。在努力获得对基本测试环境配置的控制的同时，将硬件和脚本级别的维护留给操作团队。为什么我们需要这个控制？因为不同的团队关心其他事情: Ops 团队通常关心低层次的东西，比如缓存、构建脚本或者数据库可访问性，而测试工作在小的调整和性能分析、依赖、数据和环境更新上。这是团队集成到主要 DevOps 管道中的必备条件。较低的时间安排允许对每个分支和版本进行快速和精确的测试ーー这是 A3的主要目标，A3是独立测试自动化团队的最终目标
3. Tools 工具.Allure TestOps 作为一个全栈测试自动化解决方案，为测试团队提供了几个开箱即用的必备特性:测试工具集成，可以是 JS、 Python 或 Java 测试框架，也可以是一些全栈工具，如 Playwright 或 SeleniumControl 控制 CI/CD 系统，该系统允许运行自定义套件、重新运行选定的测试或存储运行历史。 详细的分析和自动的故障调查. QTest 是敏捷测试的另一个大型测试管理工具，遵循集中测试管理的概念，有助于轻松沟通，并有助于跨 QA 团队和其他涉众的任务快速开发
4. Metrics 度量. 测试执行频率指标可能看起来类似于 A2阶段的执行指标，但是差异仍然存在于姿态中。在 A2中，团队只能观察测试的频率和使用情况，而在 A3阶段，团队需要把精力放在最大化整个团队的测试使用情况上: 开发人员、运营人员、测试人员，有时甚至是管理人员
5. Challenges 挑战.这里的主要挑战是缺乏基础设施管理专业知识。进入这个阶段肯定需要你的 QA 和 Ops 团队是一致的: 学习 DevOps 的基础知识和基础设施管理将需要大量的协作。请记住，不同的团队关心不同的事情: 如果您不深入研究基础设施，您与 Ops 相关的任务(例如更新 Selenium 或框架)可能会推迟到最后

1. Team. 团队的主要区别在于获得 Ops ——测试人员之间的专业知识。我们需要两三个熟悉服务器管理和 CI/CD 工具和流程的人
2. Goals.负责所有的测试基础设施。与您的管理员团队一起习惯于维护所有的模拟器、 Selenium 实例和其他测试工具: 开始更新测试服务器上的浏览器或 Docker。有经验丰富的管理人员支持是很重要的。还记得我们在 A2的“运行测试”按钮吗？是时候动手了。我们必须将我们的测试服务器集成到主要的开发管道中，同时对它们负责。只要您负责基础设施，就不会因为“预定”测试、数据库擦除或 Selenium 配置更新而导致那些棘手的失败和片状测试。此外，您将能够迅速解决所有的问题自己。 更自动化! 开始设置测试通知，并要求操作团队监视测试执行
3. Tools. 在这个阶段，我们需要工具来构建一个可伸缩和灵活的自动化测试基础设施Docker, 容易管理和运行多个环境。创建几个预置，并保持它们按需运行Jenkins, ，虽然老了点，但还不错。Jenkins 并不是最容易建立的系统，但它一直被推荐给庞大的开源社区和丰富的生态系统
4. Metrics.测试套件执行持续时间与成本。一旦我们的声音变得响亮，我们就可以优化涉及行动小组工作的指标。如果你的管道卡在检测质量门上，要求更多的电源！但是记住不要超出预算。
5. Challenges. 正如在 A2阶段一样，我们对测试基础设施有了更多的控制，但是度量标准不受我们的直接影响。请记住与行动小组保持密切联系，因为他们的经验将让我们到达 T1-T2的过渡点。
6. Transition point. 一旦我们习惯了这样一个事实，即我们负责管道，并且所有适合的工具都像钟表一样运行，有通知、自动生成的报告等等，我们就准备好了！

测试人员和开发人员应该开始在相同的技术栈上一起编写测试。这个阶段对于打破测试和开发人员之间的竖井心态是必要的。测试人员和操作人员的测试基础设施管理提供了管道，可以快速简化面向市场的新特性。

1. Team. 一个高级测试人员团队变成了一个具有操作和基础设施维护经验的 SDET 团队
2. Tools. 我们需要一个基于代码的协作工具，我不确定我们可以通过 GitHub 提供任何建议Allure TestOps，作为一个工具，将保持所有的测试对非开发人员开放。像实时文档这样的特性将自动跟踪测试内容和测试失败/通过率。高级仪表板将让团队聚合全栈测试分析，包括所有级别的测试: 当然是开发人员测试、操作系统测试和 QA 测试
3. Goals.迁移到本机测试工具。本机意味着测试使用与测试代码相同的技术堆栈。简洁的部分ーー它们可以存储在与测试代码相同的回购文件中。这里有一些例子: JEST for JSXCtest for iOSKaspresso for AndroidPytest for Python JUnit5 for Java 或 SpringTest for Spring JUnit5用于 Java 或 SpringTest 用于 SpringDevelopers 编写低(单元)和中(集成)级别的测试。在这个阶段，测试人员应该开始检查这些测试，原因有二: 使用 QA 最佳实践提高测试的质量，并从开发人员那里学习更好的编码模式。虽然现在所有的测试都存在于一个存储库中，但是这个过程很容易实现。
4. Metrics. 本地测试覆盖率和迁移速度。还记得 DevOps-native 测试流程的描述吗？我们在这个阶段已经涵盖了基础设施和流程，因此唯一需要改进的就是本地测试速度。
5. Challenges. 与以前相比，本机测试需要测试团队提供更多的编程技能。学习技能的最好方法是与开发人员更紧密地合作。这里的挑战是建立桥梁和跨职能流程，以实现我们的目标。
6. Transition point. A一旦我们将我们的“遗留”测试迁移到本机测试，我们就都准备迁移到 T3，这实际上是在“ DevOps-native 测试看起来像什么?”部门

当然，您可能会在每个阶段遇到本文没有包含的陷阱。然而，我们试图概述开发的最重要途径和死锁的主要原因。请继续关注其他帖子，详细讨论最困难的阶段。