一、背景介绍

本文主要从web类业务线系统特点出发，介绍如何从0到1构造智能交付系统， 从而提升业务线的交付效能。

二、业务线特点及面临的挑战

1. 特点

（1）业务线特点：几十条业务线（团队），子系统间交互复杂，业务间相互依赖，单项目往往涉及多团队协同开发；业务线多项目并行开发，单周几百量级项目上线。高度复杂的子系统在并行开发的情况下，经常导致项目相互影响，比如环境稳定性，api兼容性，代码被覆盖，开发中代码误被带上线等等。

（2）技术架构特点：Java web技术栈，微服务/中台化/组件化。在高频迭代的情况下，能否快速搭建一套可用测试环境？单行代码改动可能会影响多个第三方接口或前端组件，在实际交付过程中要么全量回归效率低下，要么只回归改动的功能点经常造成漏评估漏测。

（3）测试特点：web系统，手工黑盒测试仍是主要测试手段，自动化是提高回归效率主要手段。但手工测试一般无覆盖度量，完全依赖个人经验和能力，自动化用例随着不断的建设积累，执行效率越来越低，维护代价越来越大。

2. 带来的挑战

如何在多项目多团队并行开发情况下，保证各项目有序、有节奏交付同时，保证高质量高效交付（单周2-3次发版，高优项目可随时上线，80%项目可在2周内交付）？

三、建设方案

研发流程规范化、测试能力极致化、测试过程智能化、实现质效合一、交付过程向数字化、智能化转型（篇幅原因，数字化在本文不作展开）。

（1）研发流程规范化/统一化

一是解决多项目多团队协同开发，代码、环境相互影响，代码漏合回等问题；二是统一流程、工具链、技术栈，使一套能力、快速复用，才能使数据结构化、血缘关系构建成为可能，是后两项建设的基础。

（2）数据赋能测试中台能力——从点到面突破

• 环境高效自动化搭建：测试环境可以高效自动化搭建，是一切测试改进的基础。RD自测需要，排查问题需要，手工，自动化测试需要，是项目倒排期，需求变更频繁等特殊情况下最低要求，否则人海战术也无用武之地。

• 手工测试更加精细化：在web和app类的产品交付过程中，可以预见手工测试仍是未来长期一段时间内主要的测试手段，精细化测试可以提升手工测试的效率，降低对人的经验，能力主观依赖，降低复杂系统对测试人员的准入门槛，高效召回。

• 数据赋能让持续集成的自动化测试更加高效有效：自动化仍然是回归提效主要手段，但业务线往往是被淹没在无限重复的维护排查工作里，数据赋能让持续集成的自动化测试更加高效有效。

（3）测试智能化——让质量风险可见

将离散在研发过程，各测试环节数据提取出来，以项目维度聚合构建数据血缘关系，用客观数据（特征）精准刻画项目质量风险，引入模型辅助用户做项目分级，风险度量和测试裁剪决策。可以避免不同角色，不同研发阶段重复测试问题，同时也为准出提供一个度量标准，精准召回。

1. 研发流程规范化

在统一研发流程之前，笔者所在业务线存在三种研发模式，项目间经常相互影响。因为分支管理比较混乱，单周单次上线业务线已经承受了很大压力。同样需求和代码管理也是各自为战，无法获取研发效能数据，都case by case的解决研发过程中的问题，亦或问题发现过晚或甚至被掩盖。笔者认为所有的研发过程的改进，都需要从研发流程规范着手，因为研发流程规范是一个团队的“灵魂”，是团队高效运转无形的手。

它本身就可以提升交付效率，减少因流程带来的线上问题。例如如A项目正在提测，修bug后部署环境，发现部署失败，排查发现B项目RD提交代码导致，A项目所有同学要等B项目修复代码才能继续提测。并行项目开发过程中，同时混乱的流程经常会有代码覆盖或误被带上线导致线上问题。

同时它也为数字化和智能化打下良好的数据基础。若研发流程不规范化，基础研发数据获取的过程会变成适配各业务线定制化要求的陷阱里，需求、研发、测试、上线过程数据结构化根本无从谈起。

下面从三个方面介绍一下研发流程规范化关键点。

1.1 研发模式选取（分支管理）

• 主干开发分支上线：适合小而精的业务团队或产品起步阶段，需要有比较成熟代码开关或比较稳定持续集成测试，以保证主干代码稳定。在不满足上述条件情况下，多项目多团队并行开发，往往项目间会相互影响，代码稳定性差，影响交付效率和质量。
  

• 分支开发分支上线：项目基于从主干开出的分支开发，上线前从主干开出上线分支，将所以开发分支代码合到上线分支发布，上线完成后合回主干。适合多项目多团队并行开发，但有一个致命缺陷，单周多次发版的高频迭代中，若上线分支漏合回主干，将会带来灾难性后果，上次发版功能会全部被覆盖。
  

所以我们基于业务线特点，制定了FcFlow分支管理模式，即由开发分支、主干和上线分支三种分支组成。

有以下三个基本规则：

• 规则一：开发时RD从主干拉开发分支进行开发, 并基于分支或主干测试；

• 规则二：项目到达上线窗口后，合入主干，并从主干开上线分支（RB）上线；

• 规则三：Hotfix在最近一次RB分支上做fix，hotfix在上线完成及时合回主干。

这样即可以保证多项目多团队并行开发不会相会影响，对持续集成稳定性要求低，代码合入主干至少经过手工测试。即使在高频发布的过程中，上线分支代码有漏合回主干情况下，最差情况只有该上线分支hotfix bug被覆盖。

1.2 需求、开发、测试统一管理

借助百度内部高效的需求、代码、流水线管理工具链，将需求、开发（代码）、测试（构建）阶段用极低的成本关联起来，为基础数据获取打下坚实基础。

具体来说：

• 将卡片类型分为2种，需求和任务卡片，需求卡片管理需求，PM管理；

• 任务卡片由RD拆分，必须关联需求为父卡片，且rd提交代码时必须包含任务卡片id， 这样就将代码与需求关联起来。

有上面的基础，代码提交时自动触发构建，就可以根据规范自动获取项目升级涉及模块、分支、commit等信息自动搭建子系统环境为持续集成提供匹配的测试环境。

1.3 双周迭代 有节奏RB

在项目迭代交付过程中，项目需求评审往往是随来随评，从感觉上给人带来感觉是很快，但实际情况并非如此。

RD项目的开发中夹杂着项目的评审、沟通&线上问题处理，精力不集中，效率低。QA同样会导致测试的过程中bug，风险后置发现，效率低下。PM需协调UE、依赖方，需求没完全确认、无前期沟通、人力资源固定性下项目优先级如何处理等问题。每个角色的精力都被打散、碎片化。

所以我们制定双周迭代、单周两RB迭代交付机制，即双周做一次需求排期、单周2RB窗口、项目随测完随发车上线、最大限度减少时间等等。需要注意的是只是双周需求排期的概念，并不是双周内进入迭代需求都要完成上线，小需求快上线、大项目按实际情况上线、流程保证紧急需求可随时高优插入随时上线。

2. 数据赋能使测试中台能力极致化

有了上面流程基础（项目迭代高效有序推进，且可以提供脉络清晰的项目、团队等维度基础数据），下面再来看如何基于这些基础建设极致的测试中台能力。

2.1 环境高效的自动化搭建是一切测试改进的基础

当前Web类系统的技术架构是高度的微服务化、中台化、容器化，RDQA想搭建一套可用的子系统环境出来，往往涉及到几十个模块实例，这些实例容器资源申请、基础依赖服务、版本匹配、配置管理、系统拓扑等若都是人工维护，可想而知会大大降低项目的交付效率。对于任何项目测试来说，高效稳定的测试环境永远是测试改进的起点，否则自动化测试无从谈起，连基本的手工测试、研发都会受影响。Web业务类业务系统当然也不例外。在微服务化、中台化、容器化的大趋势下，都给环境部署带来了更大的挑战，所以环境部署效率、稳定性、易用性都是影响交付提效的关键因素。

• Base环境

  
  

业界常见的环境解决方案，是在容器化基础搭建沙盒环境，但这种方案需要部署子系统所有模块，消耗大量资源，当子系统模块越多时也越影响部署效率和成功率。

为解决这个问题，我们设计base环境，每个业务线子系统只维护一套与线上一致的base环境，当项目需要搭建环境时只部署与项目代码升级的模块，然后通过路由配置与base环境未升级的模块相连通，这样环境搭建时只需要搭建2到3个升级模块，不仅大大提升环境部署效率，将部署成功率从原来85%提升到95%，同时也将机器资源节省50+%以上。

• 环境一键搭建
  

虽然base环境缓解部署效率和资源问题，但部署往往涉及多个模块配置更新，无论是环境工具命令行还是提供web操作页面，需要在平台做复杂的配置拓扑才能保证连通性，误操作导致排查和学习成本很大，对RD和新人来说上手成本更大。

于是我们在流程规范和base环境基础上，通过流水线实时获取项目升级涉及模块、分支及代码提交记录，将拓扑信息和升级数据在DB中缓存起来，将环境的配置、拓扑维护这些复杂操作对最终用户透明。当RD、QA甚至PM需要搭建该项目子系统环境时，只需要“傻瓜式”一键点击便可以快速完成环境搭建，极大降低环境学习使用门槛，并进一步提升部署效率，单套环境部署降低20分钟。

2.2 手工测试：精细化测试 提升测试效率和精准召回的利器

手工测试在未来很长一段时间内仍是web类系统最主要的测试手段，但长期以来手工测试主要以黑盒测试为主，完全依赖测试人员的个人能力、经验，基本靠“天”吃饭。比如中台/微服务架构下，一个底层接口或前端公共组件改动，对上层业务影响如何确定，是需要“全都回归一遍”还是只测试改动功能就可以？如果再遇到新人呢？这就更难应对了。

针对上面问题，我们思路是通过离线挖掘代码间调用关系，引入精准测试，在全流程提供数据报告辅助一线同学进行针对性的测试，从而大幅提升测试效率和召回。

• 范围评估报告

为了解决中台化和组件化代码变更带来影响面难以准确评估的问题，我们通过动态获取模块间接口和离线方式获取模块内方法调用关系，生成任意方法和接口及第三方的映射关系。当RD提代码时，实时获取变更方法查知识库生成范围评估报告，可以精准缩小测试范围、提升交付效率，同时也可以防止漏评漏测、提升交付质量。

具体影响面评估报告如下图所示：

• 增量覆盖率报告

为了解决测试覆盖无法度量以及测试过程中无客观数据报告让QA可以针对性提升测试覆盖的问题，我们对jacoco覆盖框架进行改造，可以单次快速生成只显示变更代码增量覆盖率报告。同时与环境打通，更是可以做到无感知自动收集覆盖率，并提供实时代码染色能力，指导RDQA针对性做测试覆盖提升，降低漏测风险。

增量覆盖率报告如下图：

2.3 持续集成：自化用例筛选+智能流水线 只做有效构建

随着自动化用例积累，单业务线用例量级突破万级，若每次都触发或每次都执行全部用例，任务成功的概率几乎为零，会带来很高的维护和排查成本，同时也会带来资源浪费。

• 宏观触发层面

引入智能流水线和项目级CI，以项目维度代替模块级触发，跳过不必要或无diff触发。比如变更代码只是加了注释或日志调试信息，在识别变更代码便可以引入策略来决定是否要触发流水线构建。甚至，可以基于对变更代码解析，针对性对流水线做智能编排，静态代码分析、单测、接口自动化、UI自动化这些分层测试手段不需要每次都全量执行，做到持续集成的“千人千面”。

• 微观用例执行层面

自动化框架有大量的用例执行数据也可以用来为测试提效，比如根据用例历史执行时间和用例执行数量动态分组和分配并发任务数，解决用例最长执行路径问题，效率提升50%以上。

微观用例执行层面还可以从离线收集用例与代码，用例稳定性数据入手，引入用例生命周期，用例覆盖相似度精简不稳定和重复用例，通过用例和代码映射关系，将代码变更无关的用例剔除，形成筛选漏斗，将执行时有效用例集合降低到最小，构建稳定性从70%提升87%，执行时间降为原来的50%。

3. 测试智能化：减少重复测试 让质量风险可见

项目质量度：精准刻画项目质量 避免重复测试让风险可见

在高速的项目迭代过程，会有70%左右的项目是小优化升级或bugfix，为了项目快速交付会有一大部分项目通过RD自测流程上线。

但这个流程存在一个很大bug，就是项目交付都是按计划排期，项目是否要走自测试流程上线的时间点，往往是需求排期或紧急插入需求。此时RD并发开发一行代码，完全靠人的经验评估，但人工经验是否靠谱呢？若一行代码改动影响了很多第三方呢？另外RD自测得怎么样、QA跟进测试的质量风险怎样，能否有量化评估？

• 项目质量度
  

研发规范统一和极致测试中台能力，使高效稳定获取各阶段各维度数据成为可能。质量度就是以项目维度为出发点，收集从需求、研发、测试等环节研发质量和风险数据，刻画质量风险，建立质量度模型模拟人的决策，为增量项目测试分级和裁剪提供决策支撑。

比如RDPM靠谱，变更小且没有影响第三方，自测覆盖很高，质量风险很小，就可以走自测流程。反之，则需较高的覆盖才能准出。或者，基于项目数据画像分析，风险较小，基于增量覆盖率报告做部分场景补充后，很快达到准出标准，可以裁剪不必要测试，避免重复、提前交付，从而避免不同角度、不同阶段间重复测试，提升交付吞吐量并大幅降低交付周期。

四、总结

（1）制定适合产品线特点的研发流程规范， 是一切效能提升的基础；

（2）高效稳定环境自动化搭建能力是所有测试改进的基础；

（3）将质效数据+策略有机计划，形成智能化解决方案，是提升交付系统效能的关键手段；

（4）制定适合产品线和其发展阶段的测试分层拦截体系，做高效的有效构建。

整体效果

• 从原来的单周1次发版，RB周期2天提升到单周2次发版，RB周期1天；

• 通过质量度大幅提升自主测试项目占比，从原来25提升到60%，80分位交付周期下降30%。
  

不过，智能化和数字化是交付提效大趋势，但还在起步阶段，还有很多场景需要去探索。

点个“在看”少个 bug 👇