百度搜索业务交付无人值守实践与探索

作者：百度Geek说

2022-10-25
上海
本文字数：3855 字
阅读完需：约 13 分钟

作者 | 刘道伟

导读

基于风险驱动的交付是百度实践智能测试——感知智能阶段非常重要的研究方向，基于风险驱动的交付，源于三个现状：

一、不是所有的项目都有风险，80%以上的项目无任何的关联 bug 和线上问题。

二、不是所有的测试任务都能够揭错，无效的质量行为（有 bug 发现的质量行为/所有质量行为）占比非常高。

三、测试人员也有误判的可能，漏测一直存在。

通过以上三个现状，可见如果能够有方法逼近：测该测的项目、做该做的质量行为、评风险评得准，那么对测试效能和召回都有极大的帮助。

接下来我们将持续刊登三篇文章，来揭秘百度实践基于风险驱动的交付的冰山一角：

1、百度搜索业务交付无人值守实践与探索：从具体业务实践的角度介绍风险评估在交付无人值守领域的关键作用。

2、AI 技术在基于风险测试模式转型中的应用：从测试全过程的角度介绍各环节以风险思维+AI 技术加持的各种应用场景。

3、质量评估模型助力风险决策水平提升：从思路、方案和模型的角度介绍质量度模型的实现和挑战。

本文先介绍第一篇：百度搜索业务交付无人值守实践与探索。

01 引子

提起交付无人值守概念，大部分人应该都比较陌生，出现下面这些疑问：

什么是交付无人值守？
怎么做到交付无人值守？
交付无人值守能带来哪些好处？

本文就从以上几方面入手，详细介绍一下百度搜索业务在交付无人值守上一些探索及实践。

02 无人值守的源起

在介绍无人值守之前，可以先了解下交付模式的发展历程，如下图所示，随着工程能力的不断发展，交付过程中的测试逐步从纯手工测试变为半自动化测试或自动化测试。同时在互联网行业敏捷开发模式持续发展，持续集成也随之开展起来，通过将自动化测试工具集成到流水线中，质效工作逐步左移，大部分的需求研发人员可以通过流水线完成测试、上线工作。我们把这类研发人员不再需要通过测试人员手工测试，使用流水线即可完成全部测试过程的模式称为研发自主测试，在搜索业务中，DevOps 已成为最主要的交付模式，部分业务需求自主测试比例达到了 90%以上。

理想状态下，既然大部分需求已实现自主测试，整个交付过程中应该是不需要耗费测试人员人力，但是理想很丰满，现实却很骨感。下图是在自主测试模式下，测试人员的工作日常，可以看到在整体过程中测试人员工作量依然比较大：

1）研发人员流水线执行测试失败，需要测试人员进行问题排查、修复任务稳定性问题、定位是否与代码有关、与研发反复沟通；

2）研发流水线执行完成后，测试人员还需要确认研发的自主测试报告，分析需求风险，判断是否可准入；

3）交付过程中，存在很多环节需要研发人员和测试人员的沟通及手工操作，如需求的报备、拉分支、发布版本等工作。

能否有技术手段，把交付过程中这些耗费测试人员大量人力的工作由机器替代呢？这就是我们今天要介绍的无人值守出发点。

03 无人值守的方案

在当前交付过程中，主要有以下几个环节对测试人员的依赖程度较大：

决策依赖人：CI 代码后需要执行哪些测试任务是静态配置的或完全人工决策决定的。
流程依赖人：交付各环节流程流转依赖研发或测试人员，沟通交互成本高。
结论依赖人：流水线无风险分析能力，测试任务无 0/1 化结论，准入准出的风险判断依赖个人经验。

因此要实现无人值守必须要通过技术手段解决这三个依赖问题，一句话概括就是 “通过智能执行和风险评估能力，实现失败智能运维，过程自动流转，风险智能揭露，整个交付过程无需测试人员人工干预 ”。要真正实现这个目标，首先要满足三个必要的条件：完备的测试能力、稳定的构建能力以及精准的评估能力，在这些能力的基础上，建设数据采集、风险识别、风险控制、风险决策等智能化机制，最终实现全环节的无人化。

由于篇幅所限，本文下面先重点介绍三个依赖的基础能力。

3.1 完备的测试能力

完备的测试能力是无人值守的基础，完备即要求流水线的测试任务是全面且有效的。

怎么理解全面？不同类型业务对于测试任务的需求是不同的，全面就是具备对应的业务类型需要的各种测试任务，以百度的工程能力地图服务端要求为例，全面的测试能力即要求下图所示的服务端的各环节的测试任务都具备，可以根据业务的实际需求进行一些变化。

全面测试能力的基础上进一步是有效的，有很多情况下流水线虽然具备了某类型的测试任务，但是这个测试任务是不是能够拦截问题还依赖测试任务的风险揭露能力，或者依赖测试人员对于测试报告的分析解读能力。

以搜索业务的 DIFF 测试类型为例，DIFF 测试就是针对基线版本和测试版本，发送同样的数据，对比返回的数据的字段的不同，判断测试版本是否符合预期，已经是当前接口测试和大数据测试中比较常见的方式。但是 DIFF 测试任务存在有效性问题，测试任务产出了 diff 的结果，可能是『噪音』导致的不稳定，可能是代码变化的预期内的，也可能是 bug 导致的非预期结果，这个风险的判断完全依赖研发和测试的人工分析。因此要提升 DIFF 测试有效性要解决噪音干扰的随机 diff 问题和 diff 结果 0/1 分析问题，随机 diff 的消除通过后端 mock、环境数据一致性、随机 diff 智能识别与过滤策略等机制解决，本文不详细展开论述，重点介绍下 diff 测试的拟人化分析能力。

拟人化分析就是把人工分析测试结果的能力转化的自动化过程，因此要实现拟人化分析首先要清楚人在看到 diff 测试结果的时候是如何判断的，经过实际调研发现，研发和测试人员在分析 diff 测试结果的时候，首先会看修改的代码是否与产出的 diff 结果字段相关联，如果是关联比较大就认为是代码导致的，接着会分析这些字段的业务影响面是否是需求内预期的以及影响面大小，如果是预期内的影响且风险可控即可认为通过，因此拟人化分析也从下面两个方面进行判断：

1）根据白盒数据+模型+业务逻辑分析字段是否符合预期；

2）根据结合业务的数据分析，评估字段影响面风险。

这其中最重要的一点是如何将白盒数据与结果相关联，目前主要采用了两个手段，一个是比较常规的业务知识库沉淀，通过对业务的知识的梳理及沉淀，将研发和测试的个人经验转化为可自动判断的规则，如某些函数的变化可能引起某类的 diff，优点是与业务关联比较紧密，准确度更高，缺点是仍然过于依赖各个业务的人员的梳理，沉淀的效率较低，因此我们探索了第二个手段，通过任务执行的历史数据，分析代码变化与字段变化之间的关联关系，离线的建设代码及字段的关联模型，在线阶段通过模型判断字段变化是否是代码导致，再结合字段的业务风险判断最终给出 diff 测试结论。

通过上述一些手段，能够大大的提升 DIFF 测试的有效性，也减少了 DIFF 测试的人工分析成本，类似的工作也在性能测试等其它场景开展，即通过技术手段提升测试任务的风险揭露能力和结果的分析能力，从而提升测试任务有效性。

3.2 稳定的构建能力

如果说完备的测试能力是实现无人值守的基础，稳定的构建能力就是实现无人值守的保障。如果流水线构建频繁失败，就会导致在自主测试过程中，测试人员需要不停的进行失败问题的定位，修复，以及与研发人员的反复的沟通，因此稳定的构建至关重要。如何建设的稳定的构建能力呢？其实可以用线上服务的稳定性建设作为参考，线上服务通常有研发、运维的各种稳定性及监控建设，稳定性能够达到几个 9 以上，但是线下服务的稳定性通常只有百分之八九十，那为什么不使用线上稳定性建设的标准来进行线下测试能力的建设呢，因此我们以线上运维的标准，全面提升了线下构建的稳定性，主要包含以下主要工作：

基础依赖治理：流水线稳定性离不开基础依赖的稳定性，这些依赖包含机器、实例、测试代码、测试数据、第三方服务等各个方面，因此要提升稳定性首先要治理这些依赖，如机器的统一管理，测试代码和数据用线上代码的标准管理，第三方服务的 SLA 保障及容灾等措施。
全环节的稳定性保障：全环节即预防、发现、定位、恢复、闭环各个环节均建设对应的稳定性能力，如在预防环节，针对构建需要的环境、数据等进行监控，如出现不可用或缺失等问题提前报警，避免测试任务构建时才发现导致失败；定位环节规范错误码，针对错误码建设自动定位机制，如果定位问题能够自动恢复即触发自愈的策略自动触发恢复手段，减少失败的人为干预。
构建数字化：通过对构建数据的数字化，实现构建的稳定性度量、刻画、建议等工作。

3.1 精准的评估能力

有完备的测试能力和稳定的构建能力，交付的无人值守还有最后的环节需要解决：准入准出的风险如何判断？传统的流程上通常都是由人工评审测试报告的方式对风险进行把控，不仅耗费人力成本，而且判断准确程度完全依赖个人的经验，新人研发和测试同学经常会出现判断错误导致漏测。如何实现自动的风险评估能力呢，我们采用了基于质量度模型及规则结合的方法建设评估能力，质量度模型就是将可能影响风险的数据都抽象为特征，通过人工标记的历史数据训练为模型，在准入准出阶段通过调用质量度模型的结果给出风险得分，再结合基于业务的规则判断进行综合判断风险，如果风险低则可以自动准入不再需要人工分析，如果风险为高，再引入人工。