作者：韩照光 百度资深测试工程师

作者为百度大商业交付效能提升负责人，长期从事研发效能提升工作。在研发流程改进，接口自动动化及持续集成，效能数字化有一定的经验，目前专注于精准测试和智能化测试等专项测试改进工作。

研发效能提升是近两年业界的一个热点方向，但大多数议题和分享聚焦效能度量和数字化层面，和实际研发测试能力改进关联较少。本文试着从笔者所在业务线效能提升实践出发，介绍研发测试能力改进如何与效能度量和数字化相结合打造一套体系化的智能交付系统，从而提升业务线效能，希望可以给大家一些参考。

一、问题背景

当前业务特点和效能提升面临的挑战。

1.业务线特点

• 我们商业平台目前主要技术栈：Java web 系统，微服务架构；
• 开发特点就是活跃模块多，业务线多，多研发团队并行开发。

2.研发效能提升面临的挑战

• 流程不统一，落地难，流程易退化。

虽然是一个大的部门，各个研发团队或各个业务产品线流程可能是不尽统一，我们去做一些流程落地的时候经常会遇到落地比较困难，比如业务的调整或是人员的流动或新人的进来，经常会有一些简单的流程的退化。

• 基础能力易用性，可用性差。

虽然一直在做效能和测试能力的改进，但整体想把它做好或者做到极致化，往智能化测试去应用的时候，易用性和可用性还是会有一些问题。

• 手工黑盒测试占比高、效率低、质量差。

目前我们偏手工黑盒测试整体占比较高，整个测试过程中也会有一些外包同学参与，虽然我们也有很多自动化的积累，但整体的测试效率、质量还会有一些问题出来。

• 无差别交付效率低，推高成本。

在测试过程中，不管大小或者是项目的难易，可能就是一套能力全部用上。比如自动化习惯要全去跑一遍，或者现有的一些测试能力可能全部去铺一遍都去跑，其实是做了很多不必要的加法技能；还有就是无差别交付，一些项目如果不根据它的难易和复杂程度做一些分级，整体的人力成本相对是会比较高的；还有就是如何区分分级，使用外包测试如何保证测试质量，这些都是提升研发效能需要面临的一些问题。

3.思路

• 基于数据或风险驱动，去做一套智能交付系统，减少对个人的依赖，从而提升测试质量；
• 减少重复测试，提升整个测试过程机器决策的占比，提升整个测试过程机器执行的占比，从而提升效率，整体降低人力成本。

二、研发效能提升整体解决方案

相对业界对 T+1 这种效能数据的度量的讨论，那我这次实践分享可能会更侧重于我们实时的数据采集。在体系化、在线化的基础上，去做实时的数据采集以后，这一块我们可以做更多能力改进、智能化交付，或者项目质量度的交付，从而提升我们整个的研发效能。

具体来说，首先在底层把研发流程标准化，简化项目在工具链项目管理中的应用成本，为后面的低成本实施数据采集打一个基础。然后把我们的流程优化统一起来，让我们整个体系化、在线化去做上层的能力改进建设的时候，能够有一个比较好基础，或者说我们去做扩展复用这套能力的时候，能够快速推进。

然后有了流程的标准化以后，就去做流程的落地，比如数据的实时采集、静默采集，去做一些流程的在线化保证我们的流程规范，能力能够快速扩展复用。

那在基于这套底层的流程统一和精简之后，就是一些能力的左移，比如 API 一些自动发布、远程测试环境的 debug、智能 UT 等。

然后继续去往后边走的话，环境的稳定性和应用性，环境的快速搭建能力，是测试或者交付展开的一个最基本的基础。

然后就是我们 CI 的自动化，特别是对前端的自动化这块，我们可能会更精简一些，会关注一些核心的自动化，因为现在至少就是前端这一块整体的稳定性和执行的效率，从我们的实践过来看其实还是有一些问题的，那我们可能会侧重一些 P0，然后会做一些浅交互的自动生成用例的探索。

然后再往后边的话，就是我们的白盒能力，比如说覆盖率，就是我们的 Java/JS 的覆盖率，也就是我们业务代码语言所用的覆盖率。那现在可能比较多的可能就是 Go 或其他的语言技术栈的能力，现在应该在业界推的也比较多了。

然后还有 SA，基于我们的这种 SA 去做的我们的一些静态代码的风险识别，基于调用链，然后再基于这套白盒的能力去加上我们流程、极致化环境的能力，去做项目的实时刻画，基于这个打造我们的项目质量度，用项目质量度去做比如项目的测试分级，去做整体的风险评估，去做项目的准出。

然后再往上的话就是会稍微介绍一下我们整体的一个解决方案，就是说那我做了这种项目的分级以后，那我可以基于这个项项目质量度去做研发的自主测试的交付，甚至说我们整体能力达到一定程度，其实就可以做项目整体的一个无人值守（QA 的无人值守），然后是非自主测试精细化分层，大概是这个思路。

总的来说，不管是度量或者在线化还是整个交付系统，我们有一个原则，那就是：简单易用，高实效性；多做减法，避免为度量而度量。

1.流程精简统一，数据实时采集、能力优化的基础

这里列出两个问题，来讲一下我们是怎么做的。

首先第一个问题，由于团队比较多，流程繁杂且不统一，影响研发效率。

比如：需求卡片层级不同，拆分粒度不同，管理和度量代价大；代码提交规则和分支管理不同，项目间经常互相影响；RB 机制也不同，代码经常被覆盖，或误带上线等一些常见的问题。

针对这些情况，我们做了一些简化和规范。比如我们用了两种卡片，在百度内部有一个 icafe 的需求管理系统，然后我们去用了两种卡片的类型，用需求 story 去管理需求，然后用 task 去管理我们这些代码，story 是对应一个真实世界的需求，无论这个需求是比较大的 1.0 的项目还是一个 bugfix，这样的话不会因为每个人的理解产生不同的影响，避免为了度量而度量。

第二个问题，就是我们整体的如何低成本用工具链上的数据刻画项目。

这块主要是列了 3 个点：

• 研发模式：采用分支开发测试，测试完后经主干，开 RB 上线。
• 代码提交：只能关联 task 卡片，hook 主干和 RB 保证代码稳定。
• RB 机制：单周 2RB 窗口，不限容量，整点发车。

这样带来的 “收益”：

• 理解简单：标准易对齐，PM 原子需求，无论 bugfix 还是大项目，避免多级关联或拆分粒度不同带来的管理成本。

• 聚合串联：通过规范用 storyid 或 icafe（需求），icafe（代码），agile（测试能力），xstp（环境 + 覆盖率收集）等基础设施串联起来。

• 能力优化：一系列能力优化和建设的基础，如环境一键搭建，api 自动化部署，js/java 覆盖率采集，质量度等。

2.研发流程线上化——一站式交付，质量风险可视化

为了保证流程的不退化，让流程能够规范化实施下去，我们去做了研发流程的线上化，去做一站式交付。

这样的一个好处就是可以从项目的整体维度统一研发流程，使它标准化、在线化，可以把项目生命周期的进展和质量做到可视化，用风险去驱动整体的交付。

然后还有一个好处，就是我们在测试能力或研发效率提升过程中会做各种各样的测试改进和底层的一些研发工具链，这样的好处就是可以屏蔽后台公司的基础设施，然后提供一站式的平台，有一种拎包入住的体验。基于这些工具链去做开发和能力建设，就可以做到主动推荐，降低使用成本。

3.环境智能搭建

环境这一块我个人理解，我们业务拓展过程中，我们所有能力不管你的业务成熟度高低或者测试能力建设成熟度高低，环境一直是基础，环境的快速搭建和稳定性是我们研发交付过程非常基础的一个环节。

那环境智能搭建这块我们也有核心的基础，首先会先搭建一套 base 环境，也就是说我会维护一套和线上版本相同的一个 Base 环境，这样的话一个是版本比较相同，还有一个就是整体的环境比较稳定，还有整体的环境资源或性能可能会稍微更好一些。基于这个多路复用环境，我们会订阅线上的拓扑更新，拓步更新完成以后把这些信息会解耦，保存到各子系统里边，有了子系统的拓扑信息以后，我会把这些信息实时更新到一套和线上相同的线下环境，比如子系统环境模块、服务链路的信息会实时更新下来，那有了这个链路信息以后，我基于这套信息会在定时的去更新我线下的这套 Base 环境。

有了这个 Base 环境，可以对项目实时画像，实时采集项目变更信息，基于项目变更一键环境搭建，易用性以及研发效率都有提升。

4.持续集成 - 最小代价完成测试执行

前面讲到过，我们整体的 CI 或持续集成这一块，有一个问题，就是无差别交付效率低，推高成本。

为了降低整体的维护排查成本，我们做了一个项目的整体的画像，我不会 by 模块的去做整体的流水线触发，我可能会 by 项目。比如我一个项目升级了 3 个模块，那这 3 个模块都升级完成以后，我才会去做整体流水线的一个触发，去降低执行和后面维护排查的成本。

那具体这块的思路，针对这些问题我们基于前端在线化或实时代码变更，去采集分支的变更，或者是文词表数据库的变更，然后去拿到代码变更的信息、配置变更的信息，然后再加上比如离线采集用例的代码的验收库。那这样的话，在宏观流水线层面，我们就可以根据这种代码模块的变更去动态创建些流水线出来。比如说我 a 模块有变更了，那我就去把 a 模块相关联的一些任务创建出来。或者比如只有后端升级，那前端的相关的配置、任务是不需要拉进来的，那我只需要把其他的一些单侧或者后段的用例拉出来，相关的任务去拉出来创建一个动态流水线，进行执行就行。

然后根据任务的多少大小去做动态的容器调度，基于这些模板去动态的创建我的测试任务。

执行集合这一块，就可能有前端后端，然后加上手工用例，那我可能会根据它的一些关联关系，代码的一些验证关系，去把相关的用例筛选出来去做去重，淘汰一些不稳定用例，整体做一个组合，去做一些排序，提升精准性，这是整体的这块的一个思路。

5.常规项目交付过程中存在的问题

刚才把我们的研发过程、环境、CI 这些基础能力去做到一些介绍，但整体在交付过程中其实是有一些问题的。

比如从上面的图大家可以看一下，如果需求变更，但交付过程变更的代码还没有开发，我们就要基于这个去评估，去做项目分级；还有就是如果有一些小的项目，我们可能会让 RD 去做一些自测，那这个自测哪里有没有测，测试的怎么样，这个怎么去度量，这块其实是我们完全其实基本上就是靠天吃饭，或者靠 RD 的人品吃饭；还有一个就是这种非自测小项目，如果 RD 比较靠谱，自测比较充分，那这种其实我们是可以做一些裁剪，减少这种重复测试，直接让它准出，但是这块我们没有任何的标准去做这层把关；然后还有比如如果是一些常规的一些项目的话，我们 QA 跟进，那大家去准出的一个标准，基本就是我们测试用例去测试完了，然后大家可能觉得我觉得测的差不多了，然后就准出了。但这个东西到底覆盖了多少，有没有风险，然后怎么去做消除，这块其实是有问题。

所以这块我们解决问题的思路就是引入项目质量度的这个概念，也就是说，在做整个决策的过程中用机器去模拟人。举个例子，比如金融机构根据个人征信判断是否发放贷款，受此启发，我们在项目交付过程中，如果以往这个 RD 比较靠谱或者这个 PM 比较靠谱，那项目如果在人力不足的情况下其实我可以完全由 RD 去做自测，用机器模拟度量决策，去提升自测的占比，减少我们不同角色、环节间的重复测试。这个也可以减少我们对人的依赖，用数据对项目质量风险做精准刻画。

6.项目质量度

具体来说，我们常规的项目交付过程中，一般会有需求评审、开发、提测、测试、测试准出、上线几个阶段。在提测阶段，项目能不能让 RD 去做自测，适不适合自测，或者说项目能不能转自测，我们是需要有一定的评估。

然后就是在准出的时候，这个项目能不能准出，有没有风险，其实也需要有一定的数据支撑去代替人的一些感性的认识。在这个基础上，我们通过在线化一站式工作台把整体的项目做一个精准刻画，通过把这些项目在工具链或者被测环境的数据实时采集，去做我们整个项目的风险特征的刻画。

还有我们在被测环境上这种测试活动信息，或者一些实时采集，然后把这些数据集合起来去精准刻画这个项目，通过这种数据模型离线的一些历史数据的一些训练，去训练一个质量度模型出来，这样的话当我们的新的项目过来的时候，就可以利用这个经验在新的增量项目上去用这个模型对这个增量项目做一些项目分级，那在准出的时候也可以用这个模型对这个项目的测试覆盖、风险特征去做整体的打分，然后做一个风险的决策，相对来说可能比人的决策会更加客观靠谱一些，这样去做风险的决策，去提升自主测试的占比，提升整体的效率。

在这个过程中，我们也可以基于策略分析给报告 01 化结论替代人工分析。

7.基于质量度的自主测试和无人值守

接着前面讲的，有了项目质量度以后，有了这些能力以后，那在 RD 的研发过程中，它在自测环境中其实就可以做一些环境的搭建，那对于 Java web 去做手工测试，去写一些增量的自动化接口，这个过程中我的一些能力的支持比如 API 的自动部署、本地包快速部署、问题的自动定位、远程的 debug 能力、数据构造能力、泛化的接口支持，其实都是偏左移支持研发去更快更高效地去提测的能力左移的一些点。

然后用这个去保证手工测试，去保证增量功能，当然还有增量的新接口的优化去保证增量的功能是测试 OK，然后用我们建设的 CI 的一些用例去保证回归的一些场景是 OK，这样的话最后准出，通过质量度去做一个评测、打分，然后没有问题可以直接预上线，这样就可以做到这种偏小的项目（1-3 天）可以做一些自主测试，那甚至就是说如果我们的一些环境、精准的系统、CI 的能力的稳定性比较 ok 的话，那这个项目的整个交付过程其实是可以做到一个 QA 的无人值守，也就是说把 QA 的人力其实是可以节省出来，做一些更大的测试改进或者一些大的项目投入。

8.精细化分层测试

上面说的这种是一些比较小的项目，对一些常规的项目或者有 QA 需要跟进的这种项目，我们也是面临一些问题，比如手工测试占比还是比较高，自动化工具 CI 环境的排查有一定的门槛，对于新人和外包同学上手其实是有一定的困难，如果让他们去排查环境或者写一个比较规范的自动化用例，其实是有一定的沟通成本，效率会降低。然后还有一个问题就是自主测试占比提升以后，单人的串行测试周期相对来说还是比较长。

基于这些，我们提出了精细化分层测试这样一个概念，就是把我们常见的测试能力或者测试分工去做分层，比如自动化相关的一些同学去做专项的一些东西，一些专项性能测试或者是 diff 同学然后专项去做监控，然后还有一些执行的 QA 在业务上比较熟去带些外包去做业务的整体测试，这样的话就把比如有些公司单人做的事情，我们用不同的角色的人去分工协同，去替代单人串行，把复杂的问题向专业能力更强的同学迁移，将简单重复的手工测试往新人和外包的人员转移，这样的话通过技术手段或我们的流程，把工作内容、流程的衔接和质量度的产出能够衔接起来，去整体保证测试质量。同时，多人的串行并行的协同肯定是和单人的串行执行测试来说，整体测试周期肯定是有很明显降低。

三、总结

1.基础：研发流程标准化、在线化，这些是一切改进的基础

• 梳通流程，提升研发效率，为交付减负

• 数据底座：能力极致化、智能化、数字化，是模式变革的支撑

2.关键：基础能力的极致化、智能化，通过实时数据赋能

• 环境、数据构造、CI 极致化，一是提效，二是智能化关键

• 能力左移，赋能研发环节

• 智能化，基于风险交付，避免或减少重复工作

3.方案：交付模式变革

无人值守自主测试和精细化分层测试从交付模式做变革优化

4.闭环：效能数字化支持迭代闭环改进

• 最大程度控制度量成本，减少对一线同学负担。
• 体系化在线化基础上，实时数字化是智能化交付的煤电油。