共计 5574 个字符，预计需要花费 14 分钟才能阅读完成。
作者 | 韩照光
导读
基于危险驱动的交付是百度实际智能测试 – 感知智能阶段十分重要的钻研方向，基于危险驱动的交付，源于三个现状：
一、不是所有的我的项目都有危险，80% 以上的我的项目无任何的关联 bug 和线上问题；
二、不是所有的测试工作都可能揭错，有效的品质行为（有 bug 发现的品质行为 / 所有品质行为）占比十分高；
三、测试人员也有误判的可能，漏测始终存在。
通过上诉三个现状，可见如果可能有办法迫近：测该测的我的项目、评危险评得准，那么对测试效力和召回都有极大的帮忙。
1、百度搜寻业务交付无人值守实际与摸索：从具体业务实际的角度介绍危险评估在交付无人值守畛域的关键作用。
2、AI 技术在基于危险测试模式转型中的利用：从测试全过程的角度介绍各环节以危险思维 +AI 技术加持的各种利用场景。
3、品质评估模型助力危险决策程度晋升：从思路、计划和模型的角度介绍品质度模型的实现和挑战。
本文先介绍第二篇：AI 技术在基于危险测试模式转型中的利用。
01 背景
在测试外部有一个比拟乏味的“Q3”景象，每年 Q3 是业务线上问题频发的工夫节点，究其根本原因：除 Q3 是每年需要交付量较多多，倒排期多等起因，另一个重要起因是：校招新人开始大量参加我的项目研发和测试，可能会呈现线下和线上品质问题较多。
另外还有一个常见景象与之相似，即公司架构调整，业务交接，人员调整之后，线上问题也会高频产生。
这两个导致问题频发的景象，外表是人员流动带来研发测试同学对业务不相熟，流程标准落地在团队中衰减等起因造成，但问题的实质是什么呢？咱们试着从测试过程角度剖析软件我的项目整个交付过程，列举新人 / 业务交接后须要面对的问题。
1、是需要评审阶段，谁来测的问题：
- 自动化测试还是人工染指?
- 若人工染指，外包能够独立实现还是须要正式帮忙，以及具体调配给谁？
- 须要引入众测吗？
2、是测试阶段，怎么测的问题：
- 本次测试范畴是哪里？
- 要执行哪些测试用例？
- 遇到问题，该怎么解决？
3、是准出上线阶段，测得怎么的问题：
- 执行完测试流动后，被测系统是否还存在问题？
- RD 自测我的项目，如何判断 RD 是否进行无效的测试？
通过剖析，不难看出研发测试过程受人的主观因素影响太大，即研发测试人员的集体能力、教训，对我的项目的交付品质和效率有很大影响，人判断不精确和执行偏差导致下面 2 种景象一直反复。
02 解决思路和技术计划
为了缩小或防止此类问题，咱们试着引入基于危险的全流程智能决策，进步机器决策占比，从而用较小代价实现测试工作，缩小对人能力、教训主观依赖，整体晋升决策程度和召回能力。思路如下：
（1）基于项目风险特色做任务分配、散发，最大水平晋升人效，解决谁来测的问题。
（2）通过把我的项目教训结构化、代码剖析，机器决策代替人工剖析，就能够准确分析测试范畴，晋升测试效率同时缩小漏测。
（3）通过代码白盒剖析，用例精简，能够较小代价，高质量高效实现测试工作。当遇到问题时，引入问题智能定位 / 辅助，拟人化决策，缩小人工染指频率，降门槛，危险预警。
（4）在准出阶段引入我的项目品质度模型，让品质可见，从危险维度依据测试流动和变动预估我的项目品质危险，用主观数据撑持准出决策。
基于这个思路，咱们做了如下方案设计：
首先，构建相似大脑的智能决策零碎，这个零碎能够反对常识、工具的结构化注册，触发引擎，工作执行调度，交互反馈。但只凭该零碎整个生态是无奈运行起来的。咱们须要从历史我的项目中，采集并结构化咱们的教训、业务知识、计划、工具能力等相干数据。以下是几个较为经典的决策场景：
对于刷库，数据迁徙，报表，小流量，联调等特定场景相干的需要，其对应的子系统个别都有对应的解决逻辑（教训），如若存在小流量，是否只影响 web 层，还是会影响 api 和第三方，教训少的产品（教训多的也会）常常会漏相干需要评审。特地地，1.0 大我的项目会有非凡的上线流程，要求更齐备的测试计划。对于新人，即便文档组织得再好，这些碎片化的常识、教训，也很难被看到并在须要用到时能辨认进去，失落或衰减是大概率事件。
此外，大量开发好但散落在各处的数据结构脚本，无奈被大规模复用，其价值也就不能被最大化挖掘来，可能呈现反复造轮子。若这些脚本反对的场景或接口能够结构化注册，当相干场景 (接口) 降级时，就可主动举荐相干脚本工具给用户复用。
同理，环境或测试平台的自检自愈，问题定位，项目风险辨认等能力都能够积淀为这个智能交付生态能力项。
有了这些根底能力储备，当增量我的项目进入研发阶段时，能够通过工具链实时数据采集能力，对我的项目进行精准刻画，抽取需要，开发，测试，上线各个阶段我的项目特色进行建模，智能决策系统对我的项目建模进行实时评估决策，将计算结果按不同的场景进行决策，散发，同时将决策后果通过反馈系统实时告诉到我的项目人员。
当然，智能交付零碎建设不是欲速不达的，须要在零碎在线化的根底上，实现我的项目交付的数字化（具备实时数据采集能力，尤其白盒），有简略、易用的闭环零碎能够将碎片化的业务，工具脚本等结构化入库，环境和自动化等能力具备高可能性，这些都是引入智能决策的零碎根底。
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。
04 总结
本文的问题背景：如何升高我的项目交付过程中效率品质对人的主观依赖，用较小代价实现高质量高效率交付。
解决问题思路 ：在我的项目交付过程引入全流程的智能(AI) 决策零碎，缩小对人的主观依赖，最大水平的缩小人工染指，晋升决策程度，从而晋升交付效率和品质。
计划实现根底：对立研发流程并在线化，在晋升效率的同时让研发数据实时静默采集成为可能；另外须要有极致的根底能力建设，环境和自动化须要具备高可用性和高实效性。
冲破：以智能化测试为引领，在线化根底上实现全研发过程数字化为引入智能策略提供数据底座，基于不同场景建设白盒剖析 + 模型相结合的智能决策零碎，晋升机器决策在交付全过程占比。
————END————
举荐浏览：
Go 语言躲坑经验总结
PaddleBox：百度基于 GPU 的超大规模离散 DNN 模型训练解决方案
聊聊机器如何 ” 写 ” 好广告文案?
百度工程师教你玩转设计模式（适配器模式）
百度搜寻业务交付无人值守实际与摸索
分布式 ID 生成服务的技术原理和我的项目实战