AI技术在基于风险测试模式转型中的应用
基于风险驱动的交付是百度实践智能测试--感知智能阶段非常重要的研究方向，基于风险驱动的交付，源于三个现状：
一、不是所有的项目都有风险，80%以上的项目无任何的关联bug和线上问题；
二、不是所有的测试任务都能够揭错，无效的质量行为（有bug发现的质量行为/所有质量行为）占比非常高；
三、测试人员也有误判的可能，漏测一直存在。
通过上诉三个现状，可见如果能够有方法逼近：测该测的项目、评风险评得准，那么对测试效能和召回都有极大的帮助。
1、百度搜索业务交付无人值守实践与探索：从具体业务实践的角度介绍风险评估在交付无人值守领域的关键作用。
2、AI技术在基于风险测试模式转型中的应用：从测试全过程的角度介绍各环节以风险思维+AI技术加持的各种应用场景。
3、质量评估模型助力风险决策水平提升：从思路、方案和模型的角度介绍质量度模型的实现和挑战。
本文先介绍第二篇：AI技术在基于风险测试模式转型中的应用。
01
在测试内部有一个比较有趣的“Q3”现象， 每年Q3是业务线上问题频发的时间节点， 究其根本原因：除Q3是每年需求交付量较多多，倒排期多等原因， 另一个重要原因是：校招新人开始大量参与项目研发和测试，可能会出现线下和线上质量问题较多。
另外还有一个常见现象与之类似，即公司架构调整， 业务交接， 人员调整之后，线上问题也会高频发生。
这两个导致问题频发的现象，表面是人员流动带来研发测试同学对业务不熟悉，流程规范落地在团队中衰减等原因造成，但问题的本质是什么呢？我们试着从测试过程角度分析软件项目整个交付过程，列举新人/业务交接后需要面对的问题。
1、是需求评审阶段，谁来测的问题：
自动化测试还是人工介入?
若人工介入，外包可以独立完成还是需要正式帮助，以及具体分配给谁？
需要引入众测吗？
2、是测试阶段，怎么测的问题：
本次测试范围是哪里？
要执行哪些测试用例？
遇到问题，该怎么解决？
3、是准出上线阶段，测得怎样的问题：
执行完测试活动后，被测系统是否还存在问题？
RD自测项目，如何判断RD是否进行有效的测试？
通过分析，不难看出研发测试过程受人的主观因素影响太大，即研发测试人员的个人能力、经验，对项目的交付质量和效率有很大影响，人判断不准确和执行偏差导致上面2种现象不断重复。
GEEK TALK
02
解决思路和技术方案
为了减少或避免此类问题，我们试着引入基于风险的全流程智能决策，提高机器决策占比，从而用较小代价完成测试任务，减少对人能力、经验主观依赖，整体提升决策水平和召回能力。思路如下：
（1）基于项目风险特征做任务分配、分发，最大程度提升人效，解决谁来测的问题。
（2）通过把项目经验结构化、代码分析，机器决策代替人工分析，就可以精确分析测试范围，提升测试效率同时减少漏测。
（3）通过代码白盒分析，用例精简，可以较小代价，高质量高效完成测试工作。当遇到问题时，引入问题智能定位/辅助，拟人化决策，减少人工介入频率，降门槛，风险预警。
（4）在准出阶段引入项目质量度模型，让质量可见，从风险维度根据测试活动和变化预估项目质量风险，用客观数据支撑准出决策。
基于这个思路， 我们做了如下方案设计：
首先，构建类似大脑的智能决策系统，这个系统可以支持知识、工具的结构化注册，触发引擎，任务执行调度，交互反馈。但只凭该系统整个生态是无法运转起来的。我们需要从历史项目中，采集并结构化我们的经验、业务知识、方案、工具能力等相关数据。以下是几个较为经典的决策场景：
对于刷库， 数据迁移， 报表， 小流量， 联调等特定场景相关的需求，其对应的子系统一般都有对应的处理逻辑（经验），如若存在小流量，是否只影响web层，还是会影响api和第三方，经验少的产品（经验多的也会）经常会漏相关需求评审。特别地，1.0大项目会有特殊的上线流程，要求更完备的测试方案。对于新人，即使文档组织得再好，这些碎片化的知识、经验，也很难被看到并在需要用到时能识别出来，丢失或衰减是大概率事件。
此外，大量开发好但散落在各处的数据构造脚本，无法被大规模复用，其价值也就不能被最大化发掘来，可能出现重复造轮子。若这些脚本支持的场景或接口可以结构化注册，当相关场景(接口)升级时，就可自动推荐相关脚本工具给用户复用。
同理，环境或测试平台的自检自愈， 问题定位， 项目风险识别等能力都可以沉淀为这个智能交付生态能力项。
有了这些基础能力储备，当增量项目进入研发阶段时，可以通过工具链实时数据采集能力，对项目进行精准刻画，抽取需求，开发，测试，上线各个阶段项目特征进行建模，智能决策系统对项目建模进行实时评估决策，将计算结果按不同的场景进行决策，分发，同时将决策结果通过反馈系统实时通知到项目人员。
当然，智能交付系统建设不是一蹴而就的，需要在系统在线化的基础上，实现项目交付的数字化（具备实时数据采集能力，尤其白盒），有简单、易用的闭环系统可以将碎片化的业务，工具脚本等结构化入库，环境和自动化等能力具备高可能性，这些都是引入智能决策的系统基础。
GEEK TALK
03
方案实现
3.1 任务自动分发系统
在需求评审阶段，首先需要面对的是谁来跟进项目测试问题。在项目交付过程中，业务接口人需要花费大量的精力来review需求，与产品、研发沟通，通过对需求大小、复杂度、风险判断，结合已有的项目排期人力分配情况，确定将新增项目分配给哪个同学，费时耗力。
为解决这个问题，我们首先基于历史数据，构建测试的人员画像，如该同学角色划分（是外包，正式，业务测试还是专项测试同学），经常对系统某A功能进行测试，或经常与某RD搭配进行项目交付，测试同学大项目的交付经验，测试任务分配类型（如手工， 自动化，性能测试等），测试质量和效率等等。当新需求提出评审时，可以实时提取项目特征，如需求特征标签，卡片关键字段信息，项目类型特征，研发同学画像，代码，配置或词表变更等信息，对项目进行实时项目建模，再结合人员画像，空闲系数等信息决策，实现测试项目的分发，即项目是否可以完全自动化，是否需要引入众测， 是否可独立分发给外包，或外包正式搭配， 是否引入专项测试等决策，大幅减少业务线接口同学在高频的项目review，沟通中的成本，也能提升机器决策水平。
3.2 测试范围精准分析
到测试阶段，通常要先与研发同学共同确认测试方案和测试范围。测试方案，如前面提到对于刷库， 数据迁移， 报表， 小流量， 联调等特定场景相关的需求，其对应的子系统一般都有对应的处理逻辑（经验），而经验很碎片化，丢失或衰减是大概率事件。
对于测试范围评估但面临的问题是——评估不准确，要么少评估，导致漏测，影响质量；要么多评估，做不必要的回归，影响研发效率。
针对测试方案设计，我们可以通过离线挖掘针对不同业务、场景项目信息，把需求关键字信息标签化，从需求卡片抽取关键信息，同时获取人为标注补充信息。结合针对当前场景、特征采取的有效措施和经验、风险预案、工具脚本等，形成一套完整的知识库。当新增项目分配时，基于项目特征，关键字信息推荐适合的测试方案，风险点处理预案，工具脚本，从而实现知识，经验的传承。而非靠人的能力和经验去消除潜在的项目风险。
针对测试范围分析，非常重要的是根据改动代码评估出复杂的测试范围。对于后端来说， 可以离线获取方法间、模块间、系统间的调用关系链路；对于前端组件化开发，可以通过离线获取组件间、组件页面间的调用关系，获取完整的组件调用关系，有完备的方法调用链或组件调用链关系，当底层代码发生变更时，我们便可以通过这个链路关系反查到，底层方法会对哪个接口或第三方或页面有影响，便可以建议测试同学精确回归相关接口和页面，防止漏评估或多评估回归。
3.3 智能化测试，用最小代价完成测试执行
在测试执行阶段，持续集成是项目高质量交付的回归场景下提效的重要手段，减少大量的无效任务或无效用例，筛选能发现问题的任务，是我们的核心目标。比如RD只增加了日志打印逻辑方便问题定位，便无差别的执行流水线上所有的安全扫描，静态代码扫描，压测，前后端自动化等任务；亦或只修改了1个方法做bugfix，流水线无差别执行全量的后端自动化用例。无论从任务还是用例层级，这种无差别的执行，一是会导致执行效率大幅下降，二是会带来非常庞大的排查维护成本，持续集成带来的ROI可能是负向的，这也是持续集成在很多公司无法成功被质疑的重要原因。针对这个问题，我们分别在任务和用例层级进行改进。
在任务层级，通过进行流水线模块，脚手架配置，测试能力插件化，执行容器池化等基础能力建设，当RD有代码提交，基于白盒分析，动态创建流水线，只创建需要执行的任务，并智能调度容器资源池，提高测试任务并发度，动态执行创建测试任务。
在测试用例层级，也是基于代码，配置变更以及离线收集用例代码映射信息库等输入，对前后端，手工用例进行筛选，去重，并做组合排列，将要执行用例集合在有效的前提下，降到最小。这样便将任务和用例2个层级无差别执行转换为按需执行，提升执行效率的同时，大幅提升持续集成的稳定性，减少大量的排查维护成本。
通过任务和用例2个层面优化，在任务无漏触发，用例无漏筛选的情况下，业务级将任务执行次数减少2/3， 用例执行量级缩减为原来10-50%，全量自动化用例4000+的情况下，任务稳定性达到85%以上，同时任务执行效率也有大幅提升，从原来90分钟缩减到30分钟以内。
3.4 问题排查智能定位
在测试执行过程中，测试同学尤其新人或外包会遇到各种各样的问题，这些问题基本上是围绕测试环境的问题来展开的，如环境不通， 或某接口依赖的第三方服务不稳定， 依赖redis，mysql等中间件连接失败，甚至要确认该问题是否是bug, 都需要做各问题定位，对外包或新人来说有较高的门槛，因为问题排查造成阻塞、测试低效的主要原因。
同样地，问题排查的经验尤其是常见高频的问题，也是可以沉积积累下来，可以将这些排查的过程，思路， 问题现场做一层规则抽取，抽象成不同维度的问题定位规则库，拆分为业务层规则，中间件层规则，pass层规则，实例层规则等，以完成经验或知识沉淀。当出现新问题， 用这些规则为基准、知识， 检测当前环境中可能存在的问题，结合对被测环境实时采集的代码变更，配置词表变更，部署信息，日志，trace等各种信息的实时采集，然后将不同维度多个问题做优先级排序，merge, 形成0/1化结论，反馈给用户。若系统中对于这个结论存在对应的恢复策略，触发对应的恢复策略，以减少各种排查，沟通成本，最大程度减少人的介入。
3.5 基于风险评估的准出
最后到项目准出和上线阶段，围绕不同规模项目的测试执行效果和风险评估，一般会遇到下列场景：
（1）测试范围评估时，若只有需求变更，RD并未介入开发，评估是否靠谱？
（2）项目较小，变更相对较小并由研发自测的项目，自测覆盖怎样，如何度量？
（3）非自测的小项目，若RD自测充分，能否裁剪QA测试，减少重复测试？
（4）非自测项目覆盖提前达标，能否提前准出；若测试同学觉得测试比较充分了，但到底覆盖怎样，有没有风险，如何消除？
互联网金融有可以借鉴的场景：贷前审核环节借助大数据风控模型，对贷款人基础信息，网购，支付等信息进行更全面细致评估，来替代原银行漫长的表单提交+人工审核模式，在大幅降低违约风险的同时，提升审核效率。类似地，针对不同项目(贷款人)想到快速达到准出（无违约风险）标准并上线，也可通过获取项目各个维度信息（贷款人信息），选取合适模型（风控模型）对其进行更加精准客观的评估，以达到快速交付的目的。
基于以上思路，我们在测试准出阶段引入项目质量度。将历史交付数据，以项目维度聚合项目涉及的模块，代码，分支，测试覆盖，bug，项目状态等基本信息，这些数据一部分通过公司通用研发工具链进行采集，测试覆盖相关数据通过被测环境采集，有了这些基础数据，再通过特征工程，对基础数据做缺失异常值处理，数据分箱，归一化，用历史数据训练质量度模型，达到可用标准后部署应用。这样当增量项目进入研发阶段后，在线化一站式平台可实时收集当前项目特征数据，在收集到模型需要项目特征后请求策略中台，获取打分结果和报告，在人工确认并标注后，同时也可将增量项目样本推送到数据中台，用标注数据分迭代优化模型。
目前项目质量度已在百度内部大范围落地，
质量：2022Q3共识别1123个不可准出项目，共拦截318个bug；
效能：2022Q3共转化4345个自主测试项目，约节省2172人天；可自测项目评估等待时间得到大幅降低：从50H降到2H。
GEEK TALK
04
总结
END