一、前言

测试流水线经过多个迭代准入准出的实践应用，基本完成了线上化、标准化以及流程自动化提升，目前客服域已实现 100%的应用通过测试流水线准出完成测试。当前在商家和 ERP 推广，大家一起来了解下测试准出流水线是什么，解决什么问题，又需要如何接入和线上化应用。

二、测试流水线的概念

在 DevOps 转型中，更多的会提到 CI/CD（Continuous Integration / Continuous Delivery，即持续集成和持续交付），但 DevOps 概念下，与之适配的软件测试能力也是必不可少。随着对测试“左移”和“右移”能力的要求，那 Continuous Testing（持续测试）这个概念也就涌现了。持续测试是在整个软件开发生命周期中，都需要进行测试的做法，作为持续交付流程中的一环，旨在尽早发现缺陷和问题，减少以后修复它们的成本和时间。

在得物 DevOps 下实践持续测试，考虑到研发和测试的分工差异化、测试自动化成熟度以及多角色协同复杂性。将软件交付过程中归属于测试角色的各类质量活动都组件化，并有序集成在单独的流水线，通过测试角色来触发执行和管理，这类流水线定义为测试流水线，来实施持续测试。通过和研发 Push 流水线、发布流水线的多级联动协同，更好的支撑测试完成流程守护、迭代测试、门禁卡点等职责。

三、测试流水线的必要性

流程守护-降低发布风险

解决当前流程节点无法评估版本风险的问题。具备测试流水线后，研发测试全生命周期均可由对应着不同阶段的流水线串联，这些流水线之间将存在多级联动约束，从而确保整体流程走下来是一个逐步收敛版本质量，从高风险到低风险、从不稳定到稳定的过程。

测试协同-降低团队损耗

通过流水线提高协同效率。具备测试流水线后，不管跨角色之间研发还是测试，亦或是跨团队、跨异地之间的协同，都将统一在一个载体上活动。制品、环境、质量动作和门禁都托管在流水线引擎调度和执行，测试步调是否一致，测试对象是否一致，彼此可视化、可追溯、可度量。

测试准出-降低对个人依赖

解决当前流水线执行结果不具备质量结论价值的问题。具备测试流水线后，伴随线下的质量活动更多的集成到测试流水线，结合质量门禁的应用，测试准出结论将直接简化为测试流水线最终执行结果。不用再依赖交付前的线下人工多方采集信息评估风险。

四、客服测试流水线的编排设计

编排设计思路

1. 以需求特性为核心驱动，以应用为唯一载体，通过强卡点守住质量底线。

特性是用户能体验到的产品能力的最小单元，故以需求特性为核心驱动触发测试流水线执行；应用是提供一种业务能力的最小单元，也是软件交付和运维的最小单元，故以应用为唯一载体通过应用串联代码、流水线、环境、测试以及数据库、中间件等；最后通过强卡点保障研发测试步调统一，守住交付质量底线。实现达到当增量代码集成到应用程序中时，流程化、可视化、集成化和自动化的完成测试动作。具体如下：

2. 测试万物皆可 pipeline，流程自动化解放生产力。

测试层面识别测试核心活动，核心活动组件化后集成到测试流水线。通过在测试流水线向右向左扩展节点，每个节点向下扩展测试组件，覆盖完整测试过程，实现测试过程流程化、自动化。整体研发测试流程层面，测试流水线需要承前启后，和其他流程通过一定的输入输出契约，实现流程的自然融合。

行业实践参考

在需求、应用和流水线关联解决方案上，根据各团队不同的协作方式、交付方式等，当前主流的实践有变更交付和自由交付两种模式。变更交付更偏重研发测试流程的应用，有严格控制多阶段逐级晋级的要求，一般通过需求管理应用及流水线，主要由需求驱动流水线执行。而自由交付则没有这些限制，在需求、应用的关联处理和流水线的执行上更灵活自由。

在测试活动集成方案上，大部分都是采用的插件化方案，将某类完整的测试活动抽象后集成在流水线中，具备灵活插拔和自由适配组装的好处。具体抽象内容上一般做法是只将可自动化的测试动作集成，偏重执行的高频高效。也有部分团队实践将手工的测试动作尽量集成，更关注流程的连贯性和完整度。

在质量门禁解决方案上，几乎都是采用的差异化管控方案。主流做法是每个质量组件具备独立的门禁，质量组件在不同阶段执行实时反馈门禁结果。门禁设置上不仅支持多类指标守护代码质量，如代码规范、自动化测试、代码覆盖率、安全漏洞等，也支持灵活的阈值配置和人工判断介入。

客服适配演化

统一客服分支模型

基于以需求特性为核心驱动，以应用为唯一载体，其中分支模型是穿针引线的关键。通过协同客服研发、流水线平台实施客服新分支模型，新分支模型下减少研发在多个分支重复合并等操作频率，降低了高频人为操作放大风险的可能；解决了特性分支即合测试分支又合版本分支导致的分支血缘丢失，非所测即所发的质量风险；也提供了流水线在代码问题回溯、分支一致性校验以及基于分支可视化展示需求交付过程等能力上的拓展空间。

老分支模型

新分支模型

奥姆卡剃刀原则，测试准入准出线上化极简模型

基于测试万物皆可 pipeline，流程自动化解放生产力，通过和客服研发、流水线平台和协同平台等多次沟通讨论，化繁为简。测试流水线内部最大程度复用现有组件能力搭建测试流水线，整体的研发测试流程上通过协同面板、流水线平台共同完成流程融合。通过持续的 2 个小项目，完成了客服测试流水线基于特性的多级联动模型搭建和验证。

第一版

合并需求测试流水线

分支自动合并复用 MR 流水线

组件和协同面板融合

奥姆卡剃刀下测试准入准出极简模型

客服基于模型的准入准出场景演绎

质量门禁，引入更多专家经验冷启动

基于强卡点守住质量底线，研发测试过程中各环节各组件遍布各类质量门禁，包括静态代码扫描、单测、自动化和覆盖率等，其中覆盖率作为最核心的准出质量门禁。代码覆盖率通过采集前序的各项活动过程并转化为代码覆盖率进行卡点，是目前业内最为成熟和有效的测试充分度量化工具，在应用上有各式玩法和拓展。

我们在各质量门禁阈值设置上缺乏存量数据进行差异化指导，故采用了一刀切的方式。而达到一刀切的标准可能需要持续反复测试，甚至可能确实达不到，从而在质量门禁强卡点上支持了组件重试执行和组件带分析的跳过门禁能力，引入人工分析，通过专家经验冷启动质量门禁。

平台能力标准化

五、基于测试流水线的准入准出线上化应用

快速开启准入准出

1. 开启提测准入卡点

• 需求关联 feature 分支

• feature 分支流水线设置 sonar 卡点

• 协同面板开启 feature 流水线准入卡点选项

2. 批量创建测试准出流水线

• 新建应用维度自动化计划

• 应用接入覆盖率平台

• 调整测试准出流水线模版和门禁配置，批量应用

3. 开启测试流水线

• 协同面板开启测试准出流水线

4. 开启发布卡点

• 进入应用生产发布流水线编辑状态

• 在发布流水线添加测试准出卡点

测试准入准出应用

1. 提测准入

• 研发提测 feature 分支，校验 feature 分支最新流水线结果

2. 触发测试流水线

• 手工测试完成，需求变更为可准出。选择应用分支即可触发测试准出流水线

3. 测试流水线托管执行和失败介入

• 测试流水线自动按编排运行，流水线执行成功则自动准出

4. 流转校验

• 研发基于准出分支发布应用，校验测试准出流水线最新结果

配套协同运营机制

1. 研发测试协同机制

2. 测试适配以应用为核心的分工协作机制

3. 运营机制和指标

• 运营频率和方式

• 双周迭代维度运营

• 通过研发效能双周会、测试周会、技术周会等场合通晒数据、汇报关键进展和跟进 TODO 项落地

• 运营平台

• 协同面板：从协同平台的准出面板进入数据报表，可运营准入准出流程流转数据

• 流水线平台：在流水线平台报表 Tab 页，可运营流水线维度准入准出相关数据

• 发布平台：在发布平台可运营测试准出发布拦截数据

• 核心运营指标

客服应用数据概览

六、总结 &规划

得物客服域从测试角色视角出发，结合测试承担的流程守护、门禁卡点、提供自动化工具等责任，设计了特性变更驱动的测试流水线，并基于流水线多级联动完成线上化准入准出模式的验证。通过多个迭代版本的应用和实践沉淀，拿到了非常正向的质量和效能结果，客服质量团队也对测试流水线价值有进一步认知和理解。未来客服域质量团队将通过规模化应用、一键化托管和体系化运营，持续走向 CI/CD 最佳实践。

1. 多域推广

推进在非客服业务域开展准入准出落地。通过多域的大规模应用，进一步完善测试流水线标准化，适配兼容更多业务域。

2. 阶梯化提升成熟度

适时推进提测单、分支自动合并等相关能力，完成研发到测试流转部分的自动化托管能力。

3. 更好的评估量化

跟进现有流程下相关数据报表和指标的产出，进一步完善基于指标的运营机制，优化研发效能和流程。

*文 / 三十本书

本文属得物技术原创，更多精彩文章请看：得物技术

未经得物技术许可严禁转载，否则依法追究法律责任！