译者 | 陈峻
审校 | 孙淑娟
过去，在软件开发的后期，团队往往不得不以全局重构、甚至延迟发布的方式，来处置他们发现的严重错误。而随着时间的推移，业界学会了通过DevOps和敏捷等方法，来加速开发的周期。不知您是否注意到，DevOps并不是一个人的战斗，而是开发人员、运维人员、测试人员、以及业务部门之间的一组复杂的流程、技能、沟通和工具。它专注于弥合开发和运营孤岛之间的沟通障碍，并通过各种自动化或虚拟化工具，实现持续开发、集成、测试、监控与反馈、以及交付和部署，来缩短新功能的面市时间。
不过，和其他新生的技术概念类似，DevOps也在持续完善中。在融入了安全性、基础设施、以及测试之后，我们相继看到了DevSecOps、NetOps、以及TestOps的出现。本文将重点和您讨论TestOps的相关概念、工作流，以及生命周期中每个阶段所涉及到的团队、目标、指标、挑战和工具等方面。
什么是TestOps?
通常，在分解大型发布的过程中，我们需要针对不同的框架和编程语言的代码，进行各种类型的测试（如：Web、API、Canary等）。对此，我们需要通过持续测试的方法，来满足各个微服务代码的单元级与集成级测试的全覆盖。
总地说来，TestOps是DevOps的一个子集。它通过一组技术和方法，在整个DevOps管道中进行自动的、透明的、可访问与管理的测试。而且，这些测试不仅在于QA上的透明与可控。
DevOps的原生测试是怎样的？
一个应用程序通常由前端、后端、以及移动版本等部分组成。每个部分都可以由一个专门的团队来负责开发。而一个典型的10人团队往往包含如下角色：
- 开发人员，负责编写代码、重构和拉取请求的管理
- 项目经理，负责开发的整体进度和敏捷流程
- QA工程师，负责发布测试和最终产品质量
- 自动化测试（AQA）工程师，其工作是将测试自动化发展至极限
- 运维人员/管理员，负责质量把关和管道维护
那么，测试将如何在这样的团队中开展？以下是在典型DevOps中，自动化测试人员的主要任务：
- 首先，自动化测试工程师的工作往往涵盖了后端、前端和与原生自动化测试的各种集成。此处的“原生”意味着测试应使用与被测试代码相同的技术栈，也允许将测试存储在与代码相同的存储库中。使用单一存储库的好处是，开发人员可以协助AQA工程师进行代码的审查、以及复杂的测试开发。
- QA经理在拉取请求的阶段，针对已开发出的案例审查客户场景的合理性、以及极端案例的覆盖率。
- 同时，AQA工程师也会从QA的角度，检查单元和集成测试。
- 虽然诸如：Docker或Kubernetes的配置、构建脚本、以及测试环境设置等底层维护，都是由Ops人员负责的；但是包括：配置Selenium网格、浏览器、以及数据库的数据管理等有关测试的基础设施，仍然是由AQA工程师负责的。
可见，AQA工程师主要从事的是底层测试和质量检查等工作；而QA人员则负责监督发布的整个管理过程。
TestOps的工作流
上图展示了TestOps的管道，其具体工作流为：
- 开发人员创建一个新的功能分支，并在完成时产生一个包含了一些全新代码、以及一堆自动化测试的拉取请求（PR）。
- AQA工程师审查PR，并在必要时添加更多的测试。例如，他们会增加包含了数十个参数与变体的全面测试。
- 之后，QA经理从业务角度开始最终的测试审查。测试主要着眼功能和用户故事的覆盖范围。
- 如果测试能够顺利完成，那么分支就会被合并。如果测试出现问题，那么团队着手予以修复，并跳转至上述第2步。注意，每个错误都应当与待添加到下一次回归运行的问题相关联。
可见，管道上的大多数测试只有在实现了自动化后，其测试的持续时间才能够更容易被预估。
TestOps的生命周期
如上图所示，我将在下文向您介绍QA团队在开展TestOps过程中，可能涉及到的每个阶段的团队、目标、指标、挑战和工具等方面。
M1：单个手动测试人员
该阶段通常是每个QA部门的起点。大多数团队甚至不会意识到该阶段的存在。不过，它确实会对QA的未来发展产生影响。
1. 团队：有时候，该阶段甚至没有专门的QA人员，仅由某个产品负责人或经理去开展测试工作。
2. 目标：
- 创建错误报告的流程与模板，且报告越清晰越易于开发团队的修复。
- 此阶段创建的测试用例，可能很短且缺乏细节，不过主要目的是为了获悉对测试持续时间的粗略估计，以便为下一阶段做好准备。
3. 指标：通过密切地关注流程，在指定的流程中正确地记录Bug的数量。
4. 工具：可使用Excel、电子邮件、Slack、以及任何其他能够共享和跟踪错误报告的工具。
5. 挑战：当团队较小时，将错误直接传递给开发人员，并在Slack DM（即时通讯工具）中获得修复通知是较为容易的。但是该方法也可能会给下个阶段带来潜在的混乱。
6. 达标：团队已经建立了一个基本的错误检测和修复流程。
M2：手动测试团队
这是DevOps的预备测试阶段，测试团队会在此阶段逗留较长的时间，尤其是那些不以快节奏的开发流程为目标的团队。通常，此类手动测试会在规定的发布周期的节奏下正常开展。
1. 团队：多名初、中级QA人员，由一名高级QA人员/负责人指导。
2. 目标：
- 我们需要为每个测试设置一个所有者，并记录运行的结果，以便团队知道谁应该对测试的疏漏负责。这不是为了惩罚，而是为了实现建设性的回顾。
- 测试的透明度。文档、无法通过（pass-failed）的比率、以及将Bug与问题跟踪器联系起来，都可以协助整个团队去掌控测试的过程。
- 详细的测试用例。作为文档要求的一个环节，团队里的不同成员工作在同一套测试用例上时，应为测试用例从一个所有者转移到另一个所有者做好准备。也就是说，测试用例应该包含所有的步骤、注释、元数据、以及环境描述等方面。
3. 指标：
- 测试用例的执行频率。测试的运行当然是越频繁越好。
- 测试通过率。请记住，测试的通过，可能并不表明代码无懈可击，而是跳过或忽略了某些深层次的错误。
- 测试报告的生成和使用情况。测试的结果报告不仅仅是给经理或测试团队的负责人查阅的，也需要开发人员经常查看其中的问题和测试用例。同时，运维人员还需要据此判定手动测试套件，是否比冒烟套件和金丝雀版本更有价值。
4. 工具：团队需要通过如下工具，来存储和管理测试用例，生成控制报告，以及跟踪所有手动测试的活动。
- TestRail，一种基于Web的测试用例管理工具。测试人员、开发人员、以及团队负责人可以使用它来管理、跟踪和组织手动测试等工作。
- PractiTest，一种为手动测试提供了多团队管理、以及报告功能的端到端工具。
- Qase.io，一种新的且迭代迅速的工具。
5. 挑战：通常，测试的速度，以及回归类测试的复杂程度，都会对测试团队的人员数量有所要求。因此，对于那些缺乏人手和经验丰富的团队，可能在此面临严峻的挑战。
6. 达标：团队精心设计好了测试用例、存储、以及管理流程。
M3：高级手工测试团队
这是高级QA工程师团队的一个可选的进化阶段，旨在整个公司的测试中，建立牢固的信任关系。
1. 团队：与前一阶段几乎相同。主要的区别在于团队成员更加资深。
2. 目标：优化监控的效率。鉴于手动测试很难被优化，我们往往需要借助各种半自动化的工具，来加快高级测试团队的工作效率。
3. 工具：在这个阶段，工具的主要任务是通过诸如：屏幕截图、测试场景的自动点击等功能，发挥团队的作用，并尽量减少人工操作。典型工具包括：
- Postman：一种专注于测试、而非执行过程的API测试工具。
- FakeData：一种通过生成测试数据，来节省时间，并避免手动测试表单的工具。
- LambdaTest和Responsively：一种能够将自动化快速测试，在不同分辨率的浏览器上显示结果的工具。
4. 指标：
- 需要衡量通过半自动化工具和自动化日常任务，以优化测试时间与人力成本的水平。
- 通过获得每个测试套件运行的透明度、以及可预测性，来估计出产品的最终发布时间。
5. 挑战：
- 开发团队的自动化测试（如：单元测试、集成测试）和QA团队仍处于脱钩的状态。
- 测试过程中的优化和扩展水平，仍然会受到团队人数的限制。
6. 达标：团队能够根据业务要求，以更快的速度发布新的版本。
A1：有了一位自动化工程师
这是公司走向自动化的第一步。通常，此阶段会包含：选择测试框架、测试的执行环境、以及覆盖率指标等基本步骤。这些都为进一步的自动化开发奠定了基础。
1. 团队：在手动测试的团队中添加了一名中、高级自动化QA工程师。
2. 目标：
- 通过自动化的端到端（E2E）测试，不但涵盖了各种基本API，而且提高了整体测试的效率。虽然对于一组UI测试，可能需要更多的时间，且效率可能低于手动设置；但是一组带有数据生成和模拟API的自动化端到端测试，肯定会在覆盖率和效率上胜过手动操作。
- 创建一个可被用于快速实现手动测试用例的自动化流程，并尽可能地自动生成已调优过的模板代码。
3. 工具：该阶段需要QA和开发团队之间的通力协作，以自动化各种测试实例和可执行的CI管道。
- 自动化工程师可以选择Selenium和Playwright之类端到端的测试工具作为测试环境。这两种工具都是不错的无头浏览器（Headless Browser）测试框架，可以启动手动测试用例的自动化。
- 可以选择JetBrains或微软的IDE产品。
4. 指标：
- 鉴于网站布局或API响应的微小变化，都可能导致自动化测试的失败，测试团队应事先设定有关测试稳定性和可维护性的API测试指标。
- 尽可能频繁地在各种环境和条件下，去测试每个拉取请求的合并和发布。
- 衡量从自动化测试迁移回手动测试的比率。此类迁移往往意味着自动化的成熟度和精准度，尚有待提高与改进。
5. 挑战：尽管我们在这个阶段首次获得了准确意义上的自动化测试套件，但是我们反而无法精准地预测产品从测试到发布的持续时间。
6. 达标：自动化测试用例的生成、工具的建立、以及流程的确立，都为快速发布与交付提供了保障。
A2：测试自动化团队
随着时间的推移，团队虽然获得了更多的自动化工程师，但是有高达60%的自动化项目会出现停滞不前的现象。此外，前面阶段的原有流程也可能会给全栈测试的自动化带来影响。
1. 团队：几位中、高级AQA工程师与更多初级队友一起工作。
2. 目标：从如下方面保持软件质量体系的稳定性：
- 原子化的自动测试既能够彼此独立，又可以提供本地化的结果，更容易修复Bug。也就是说，每次测试失败都能够提供更精确的结果，以便得到快速的修复。
- 提供一个带有统一接口的测试套件，以便开发人员通过质量门在其分支上运行测试。
- 基于良好的文档记录，该阶段应实现100%的回归和验证测试的覆盖率，以体现自动化测试的价值。
3. 工具：该阶段，我们需要能够通过从测试中获取洞见，以提供报告和可观察性工具：
- 报告类工具，如Allure Report和ReportPortal等开源方案，都能够共享结果，并控制自动化套件的执行。
- 全栈测试框架，如Katalon和Cypress。选择全栈测试框架对于计划保持A1-A3测试级别的团队来说，可以在专有的供应商基础设施中，构建出广泛的新功能。
- 监控：虽然设置Grafana之类的实例有些繁琐，但是它作为一个通用的开源分析和交互式可视化工具，能够以图表、图形或警报的形式，为团队提供即时的测试结果。
4. 指标：
- 运行与重新运行次数。就像论文在反复被引用的过程中，可以体现其自身价值那样，同一个测试被不同的团队运行，其结果是否能够给其他团队带来分支合并或发布，都能够体现测试套件的价值。
- 测试本身的用时并不重要，重要的是它能否预测代码正式发布的时间点。
- 有时候，测试可能会在没有明显原因的情况下，持续通过了失败的结果（passed-failed result），对此我们应当予以隔离、调查和修复，以认清是否由于基础设施的问题所致。
- 无论是业务逻辑的变化，还是测试本身的原因，都可能导致失败。因此，我们需要通过Time-to-fix，来估算能够多快去修复此类失败的测试。
5. 挑战：
- 与测试相关的基础设施往往与QA团队“相距甚远”，且不具有通用性。因此，这会影响到上面提到的测试的“运行与重新运行的次数”。
- 随着测试变得更加原子化，您会发现将大型手动测试用例映射到一组原子自动化测试，会变得越来越困难。为此，团队需要有更改手动测试的工作流程，按需使用清单进行手动测试。
6. 达标：
- 一旦回归和验证测试完全转为自动化，团队就有足够的时间进一步考虑基础设施的开发。
- 测试结果的收集和报告自动化，是另一种需要花费大量时间和精力的工作。
A3：高级测试自动化团队
当测试的目标被设定为获得对DevOps管道、以及测试基础设施的完全访问权限后，我们就需要配备一支非常熟悉测试的高级团队。
1. 团队：10人以上的高级AQA工程师
2. 目标：QA团队需要与Ops团队保持联系，不但要完成测试的编写，而且能够对测试的基础设施实施控制。也就是说，由Ops团队负责硬件和脚本级别的维护，其中包括：缓存、构建脚本、以及数据库可访问性等低级别的部分。而QA团队则努力控制测试环境的基本配置与微调、性能分析、依赖关系、数据和环境更新等方面。这些都是团队集成到主要DevOps管道中所必需的。据此，独立的自动化测试团队可以实现对每个分支、以及版本进行快速且精确的测试。
3. 工具：
- 作为全栈测试的自动化解决方案，Allure TestOps为测试团队提供了如下开箱即用的基本功能：
- 可以与JS、Python或Java框架，以及与Playwright或Selenium等全栈工具相集成。
- 能够控制带有各种自定义套件，重运行的选定测试，以及存储运行历史记录的CI/CD系统。
- 能够开展自动化的故障调查和详细的分析。
- qTest是另一个用于敏捷测试的大型测试管理工具。它遵循了集中式的测试管理概念，有助于QA团队与其他利益相关者轻松地进行沟通，并协助开展快速的开发任务。
4. 指标：与A2阶段的指标类似，该阶段的测试执行频率指标需要开发人员、运维人员、测试人员，有时甚至是管理人员等整个团队，最大化测试的使用率。
5. 挑战：缺乏基础设施的管理专业知识。如果QA团队不去深入研究基础架构，那么他们可能会将与Ops相关的任务（如更新Selenium或框架）推迟到最后。
T1：TestOps的第一步
该阶段意味着QA团队已经走出了测试的“泡沫”，代码库被整洁的原子自动化测试所覆盖。测试已经以半自动运行的方式，融入了主要的开发管道流程。如今的重点是为与Ops的全面集成做好准备。
1. 团队：团队中需要有两、三个熟悉服务器管理、以及CI/CD工具和流程等运维专业知识的测试人员。
2. 目标：
- 掌控所有测试基础设施，包括与管理员团队一起维护所有的模拟器、Selenium实例、以及其他测试内容。由经验丰富的管理员着手更新测试服务器上的浏览器或Docker。
- 通过将测试服务器集成到主要的开发管道中，以自行解决“计划”测试、数据库擦除、以及Selenium配置更新等棘手且不稳定的测试。
- 以自动化的方式设置测试通知，并要求Ops团队监控测试的执行。
3. 工具：在这个阶段，我们需要如下工具来构建可扩展、且灵活的自动化测试基础架构。
- Docker，可以轻松地创建、管理多个预设且能够按需运行的环境。
- Jenkins，虽然不是最容易设置的系统，但它一直被庞大的开源社区、以及丰富的生态系统所推崇。
4. 指标：
- 执行测试套件的持续时间与成本。为了避免测试管道被卡在测试的质量门处，我们可以根据时间和成本两项指标，来优化Ops团队的工作，以确保测试预算的可控的范围内。
5. 挑战：与A2阶段类似，我们虽然可以更好地管控测试基础设施，但是上述指标不一定能够被调优。这往往需要我们与Ops团队保持密切协作关系。
6. 达标：一旦我们习惯了掌控管道，并让各种测试都像上了发条一样去自动通知、生成相应的报告，那么我们就达标了！
T2：成立TestOps团队
这个阶段对于弥合测试和开发人员之间鸿沟是必要的。测试人员和开发人员开始在统一的技术栈上编写测试代码。测试人员和运维人员通过对测试基础设施的管理，提供了快速将新功能推向市场的管道。
1. 团队：由原来以资深测试人员为主的团队，转变为具有运维和基础设施维护经验的SDET（Software Development Engineer Test，测试开发工程师）团队。
2. 工具：
- GitHub/GitLab，一套基于代码的协作工具与平台。
- Allure TestOps，一种可以将实时文档、自动跟踪测试内容、以及通过率等所有测试要素，对非开发人员开放的工具。同时，其高级仪表板可供将开发人员、运维人员、以及QA团队，开展聚合式的全栈测试分析。
3. 目标：
- 迁移到各种原生的测试工具上，即：测试与被测代码使用相同的技术栈。例如：JEST for JS、XCtest for iOS、Kaspresso for Android、Pytest for Python、JUnit5 for Java、以及SpringTest for Spring。
- 测试人员在审查开发人员所编写的低级别（单元）和中级别（集成）测试的过程中，使用QA的各种最佳实践，来提高测试的质量，并从开发人员处学习更好的编程模式。
4. 指标：原生测试的覆盖率和迁移的速度。
5. 挑战：原生测试往往需要测试团队比以前更多的编程技能。学习此方面技能的最佳方式，便是通过建立跨职能部门的流程与沟通渠道，与开发人员更紧密地合作。
6. 达标：将传统的测试方式转变为原生的测试模式。
译者介绍
陈峻 （Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验；持续以博文、专题和译文等形式，分享前沿技术与新知；经常以线上、线下等方式，开展信息安全类培训与授课。
原文标题：Complete Guide to TestOps，作者：Ruslan Akhmetzianov