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

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

本文先介绍第二篇：AI技术在基于风险测试模式转型中的应用。

在测试内部有一个比较有趣的“Q3”现象， 每年Q3是业务线上问题频发的时间节点， 究其根本原因：除Q3是每年需求交付量较多多，倒排期多等原因， 另一个重要原因是：校招新人开始大量参与项目研发和测试，可能会出现线下和线上质量问题较多。

另外还有一个常见现象与之类似，即公司架构调整， 业务交接， 人员调整之后，线上问题也会高频发生。

这两个导致问题频发的现象，表面是人员流动带来研发测试同学对业务不熟悉，流程规范落地在团队中衰减等原因造成，但问题的本质是什么呢？我们试着从测试过程角度分析软件项目整个交付过程，列举新人/业务交接后需要面对的问题。

通过分析，不难看出研发测试过程受人的主观因素影响太大，即研发测试人员的个人能力、经验，对项目的交付质量和效率有很大影响，人判断不准确和执行偏差导致上面2种现象不断重复。

为了减少或避免此类问题，我们试着引入基于风险的全流程智能决策，提高机器决策占比，从而用较小代价完成测试任务，减少对人能力、经验主观依赖，整体提升决策水平和召回能力。思路如下：

基于这个思路， 我们做了如下方案设计：

首先，构建类似大脑的智能决策系统，这个系统可以支持知识、工具的结构化注册，触发引擎，任务执行调度，交互反馈。但只凭该系统整个生态是无法运转起来的。我们需要从历史项目中，采集并结构化我们的经验、业务知识、方案、工具能力等相关数据。以下是几个较为经典的决策场景：

对于刷库， 数据迁移， 报表， 小流量， 联调等特定场景相关的需求，其对应的子系统一般都有对应的处理逻辑（经验），如若存在小流量，是否只影响web层，还是会影响api和第三方，经验少的产品（经验多的也会）经常会漏相关需求评审。特别地，1.0大项目会有特殊的上线流程，要求更完备的测试方案。对于新人，即使文档组织得再好，这些碎片化的知识、经验，也很难被看到并在需要用到时能识别出来，丢失或衰减是大概率事件。

此外，大量开发好但散落在各处的数据构造脚本，无法被大规模复用，其价值也就不能被最大化发掘来，可能出现重复造轮子。若这些脚本支持的场景或接口可以结构化注册，当相关场景(接口)升级时，就可自动推荐相关脚本工具给用户复用。

同理，环境或测试平台的自检自愈， 问题定位， 项目风险识别等能力都可以沉淀为这个智能交付生态能力项。

有了这些基础能力储备，当增量项目进入研发阶段时，可以通过工具链实时数据采集能力，对项目进行精准刻画，抽取需求，开发，测试，上线各个阶段项目特征进行建模，智能决策系统对项目建模进行实时评估决策，将计算结果按不同的场景进行决策，分发，同时将决策结果通过反馈系统实时通知到项目人员。

当然，智能交付系统建设不是一蹴而就的，需要在系统在线化的基础上，实现项目交付的数字化（具备实时数据采集能力，尤其白盒），有简单、易用的闭环系统可以将碎片化的业务，工具脚本等结构化入库，环境和自动化等能力具备高可能性，这些都是引入智能决策的系统基础。

在需求评审阶段，首先需要面对的是谁来跟进项目测试问题。在项目交付过程中，业务接口人需要花费大量的精力来review需求，与产品、研发沟通，通过对需求大小、复杂度、风险判断，结合已有的项目排期人力分配情况，确定将新增项目分配给哪个同学，费时耗力。

为解决这个问题，我们首先基于历史数据，构建测试的人员画像，如该同学角色划分（是外包，正式，业务测试还是专项测试同学），经常对系统某A功能进行测试，或经常与某RD搭配进行项目交付，测试同学大项目的交付经验，测试任务分配类型（如手工， 自动化，性能测试等），测试质量和效率等等。当新需求提出评审时，可以实时提取项目特征，如需求特征标签，卡片关键字段信息，项目类型特征，研发同学画像，代码，配置或词表变更等信息，对项目进行实时项目建模，再结合人员画像，空闲系数等信息决策，实现测试项目的分发，即项目是否可以完全自动化，是否需要引入众测， 是否可独立分发给外包，或外包正式搭配， 是否引入专项测试等决策，大幅减少业务线接口同学在高频的项目review，沟通中的成本，也能提升机器决策水平。

到测试阶段，通常要先与研发同学共同确认测试方案和测试范围。测试方案，如前面提到对于刷库， 数据迁移， 报表， 小流量， 联调等特定场景相关的需求，其对应的子系统一般都有对应的处理逻辑（经验），而经验很碎片化，丢失或衰减是大概率事件。

对于测试范围评估但面临的问题是——评估不准确，要么少评估，导致漏测，影响质量；要么多评估，做不必要的回归，影响研发效率。

针对测试方案设计，我们可以通过离线挖掘针对不同业务、场景项目信息，把需求关键字信息标签化，从需求卡片抽取关键信息，同时获取人为标注补充信息。结合针对当前场景、特征采取的有效措施和经验、风险预案、工具脚本等，形成一套完整的知识库。当新增项目分配时，基于项目特征，关键字信息推荐适合的测试方案，风险点处理预案，工具脚本，从而实现知识，经验的传承。而非靠人的能力和经验去消除潜在的项目风险。

针对测试范围分析，非常重要的是根据改动代码评估出复杂的测试范围。对于后端来说， 可以离线获取方法间、模块间、系统间的调用关系链路；对于前端组件化开发，可以通过离线获取组件间、组件页面间的调用关系，获取完整的组件调用关系，有完备的方法调用链或组件调用链关系，当底层代码发生变更时，我们便可以通过这个链路关系反查到，底层方法会对哪个接口或第三方或页面有影响，便可以建议测试同学精确回归相关接口和页面，防止漏评估或多评估回归。

在测试执行阶段，持续集成是项目高质量交付的回归场景下提效的重要手段，减少大量的无效任务或无效用例，筛选能发现问题的任务，是我们的核心目标。比如RD只增加了日志打印逻辑方便问题定位，便无差别的执行流水线上所有的安全扫描，静态代码扫描，压测，前后端自动化等任务；亦或只修改了1个方法做bugfix，流水线无差别执行全量的后端自动化用例。无论从任务还是用例层级，这种无差别的执行，一是会导致执行效率大幅下降，二是会带来非常庞大的排查维护成本，持续集成带来的ROI可能是负向的，这也是持续集成在很多公司无法成功被质疑的重要原因。针对这个问题，我们分别在任务和用例层级进行改进。

在任务层级，通过进行流水线模块，脚手架配置，测试能力插件化，执行容器池化等基础能力建设，当RD有代码提交，基于白盒分析，动态创建流水线，只创建需要执行的任务，并智能调度容器资源池，提高测试任务并发度，动态执行创建测试任务。

在测试用例层级，也是基于代码，配置变更以及离线收集用例代码映射信息库等输入，对前后端，手工用例进行筛选，去重，并做组合排列，将要执行用例集合在有效的前提下，降到最小。这样便将任务和用例2个层级无差别执行转换为按需执行，提升执行效率的同时，大幅提升持续集成的稳定性，减少大量的排查维护成本。

通过任务和用例2个层面优化，在任务无漏触发，用例无漏筛选的情况下，业务级将任务执行次数减少2/3， 用例执行量级缩减为原来10-50%，全量自动化用例4000+的情况下，任务稳定性达到85%以上，同时任务执行效率也有大幅提升，从原来90分钟缩减到30分钟以内。

在测试执行过程中，测试同学尤其新人或外包会遇到各种各样的问题，这些问题基本上是围绕测试环境的问题来展开的，如环境不通， 或某接口依赖的第三方服务不稳定， 依赖redis，mysql等中间件连接失败，甚至要确认该问题是否是bug, 都需要做各问题定位，对外包或新人来说有较高的门槛，因为问题排查造成阻塞、测试低效的主要原因。

同样地，问题排查的经验尤其是常见高频的问题，也是可以沉积积累下来，可以将这些排查的过程，思路， 问题现场做一层规则抽取，抽象成不同维度的问题定位规则库，拆分为业务层规则，中间件层规则，pass层规则，实例层规则等，以完成经验或知识沉淀。当出现新问题， 用这些规则为基准、知识， 检测当前环境中可能存在的问题，结合对被测环境实时采集的代码变更，配置词表变更，部署信息，日志，trace等各种信息的实时采集，然后将不同维度多个问题做优先级排序，merge, 形成0/1化结论，反馈给用户。若系统中对于这个结论存在对应的恢复策略，触发对应的恢复策略，以减少各种排查，沟通成本，最大程度减少人的介入。

最后到项目准出和上线阶段，围绕不同规模项目的测试执行效果和风险评估，一般会遇到下列场景：

互联网金融有可以借鉴的场景：贷前审核环节借助大数据风控模型，对贷款人基础信息，网购，支付等信息进行更全面细致评估，来替代原银行漫长的表单提交+人工审核模式，在大幅降低违约风险的同时，提升审核效率。类似地，针对不同项目(贷款人)想到快速达到准出（无违约风险）标准并上线，也可通过获取项目各个维度信息（贷款人信息），选取合适模型（风控模型）对其进行更加精准客观的评估，以达到快速交付的目的。

基于以上思路，我们在测试准出阶段引入项目质量度。将历史交付数据，以项目维度聚合项目涉及的模块，代码，分支，测试覆盖，bug，项目状态等基本信息，这些数据一部分通过公司通用研发工具链进行采集，测试覆盖相关数据通过被测环境采集，有了这些基础数据，再通过特征工程，对基础数据做缺失异常值处理，数据分箱，归一化，用历史数据训练质量度模型，达到可用标准后部署应用。这样当增量项目进入研发阶段后，在线化一站式平台可实时收集当前项目特征数据，在收集到模型需要项目特征后请求策略中台，获取打分结果和报告，在人工确认并标注后，同时也可将增量项目样本推送到数据中台，用标注数据分迭代优化模型。

目前项目质量度已在百度内部大范围落地，

质量：2022Q3共识别1123个不可准出项目，共拦截318个bug；

效能：2022Q3共转化4345个自主测试项目，约节省2172人天；可自测项目评估等待时间得到大幅降低：从50H降到2H。

推荐阅读：
Go语言躲坑经验总结
PaddleBox：百度基于GPU的超大规模离散DNN模型训练解决方案
聊聊机器如何"写"好广告文案?
百度工程师教你玩转设计模式（适配器模式）
百度搜索业务交付无人值守实践与探索
分布式ID生成服务的技术原理和项目实战