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