客服测试流水线编排设计思路和准入准出应用｜得物技术

一、前言

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

二、测试流水线的概念

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

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

三、测试流水线的必要性

流程守护-降低发布风险

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

测试协同-降低团队损耗

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

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

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

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

编排设计思路

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

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

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

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