您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

TestOps完全手册:工作流、生命周期、团队和流程

发表于:2022-08-11 作者:陈峻 来源:51cto

译者 | 陈峻

审校 | 孙淑娟

过去,在软件开发的后期,团队往往不得不以全局重构、甚至延迟发布的方式,来处置他们发现的严重错误。而随着时间的推移,业界学会了通过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为测试团队提供了如下开箱即用的基本功能:
  1. 可以与JS、Python或Java框架,以及与Playwright或Selenium等全栈工具相集成。
  2. 能够控制带有各种自定义套件,重运行的选定测试,以及存储运行历史记录的CI/CD系统。
  3. 能够开展自动化的故障调查和详细的分析。
  • 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