当前位置 : 主页 > 编程语言 > java >

揭秘百度智能测试在测试定位领域实践

来源:互联网 收集:自由互联 发布时间:2022-12-23
作者 | intelligents 前几篇,分别介绍了测试活动测试输入、测试执行、测试分析、测试定位和测试评估五个步骤中测试输入、执行、分析、评估的智能化研究和实践,本章节重点介绍测试

揭秘百度智能测试在测试定位领域实践_智能测试

作者 | intelligents

前几篇,分别介绍了测试活动测试输入、测试执行、测试分析、测试定位和测试评估五个步骤中测试输入、执行、分析、评估的智能化研究和实践,本章节重点介绍测试定位环节的智能化实践。

测试定位的主要作用是在构建失败或问题发生后,快速给出产生该现象的原因,以帮助现象处理者给出合理的处置措施,降低问题处理时长,降低人力定位成本和问题时长,根据原因进行分类一般也分为两种:

一、根因定位:即给出造成失败的真正原因(如代码问题);

二、行为定位:即给出造成失败的可能操作或变化,以快速进行处置,降低影响面。

测试定位智能化通过将数据、算法、工程等相关技术有机结合,从问题现象、问题关联数据、系统关联数据,利用策略或算法给出问题发生的操作项或根本原因,以最终给予问题处理者决策对应的处置行为。在该领域的实践相对较少,百度QA也一直在探索研究和实践。本章节将从多个实践的角度,本章节将从多个实践的角度,介绍相关领域的目标、思路、涉及到的技术点,希望能给到大家一定参考。

一、 基于频谱的问题根因定位

基于频谱的问题根因定位期望能通过定位分析技术手段,揭露出疑似代码问题范围,协助研发和测试人员在定位问题中快速修复,降低人效。基于频谱的问题根因定位在学术界研究已久,其思路是利用测试用例执行过程中的程序元素信息(如测试结果、代码覆盖率),对内部代码做逻辑差异分析,对代码行或代码块进行可疑度排序,从而去定位错误根源。其主要过程为使用插桩编译后的程序执行被测用例集合,对每一个测试用例的标记代码块/语句是否覆盖、是否通过进行分析,以语句/代码块为统计单位,采集<ef,ep,nf,np>四元组特征(ef:失败用例中,该代码块执行的次数;ep:成功用例中,该代码块执行的次数;nf:失败用例中,该代码块未执行的次数;np:成功用例中,该代码块未执行的次数),通过多种可疑度公式(如Tarantula,Ochiai,Overlab等),将每个标记代码块/语句计算出一个可疑度值,并根据可疑度分数排序得到最终高风险代码片段集合。该分析定位能力较为通用,可广泛应用到如单元测试、功能测试、diff测试等测试活动,大大降低人工排查定位成本,后续也将持续探索,结合更多代码白盒元素,尝试更多问题根因定位手段不断提升定位能力,目前百度正在将该定位能力集成到自动化测试流水线中。

二、基于错误码的构建系统定位方案

在测试人员的日常工作中,各种自动化任务量大,其中的异常构建数多,流水线执行完后,业务线同学需要花很多人力在问题定位&标注和红灯修复上;同时,很多问题没有彻底闭环,人工处理止于问题标注和手动恢复,导致同类问题反复出现。为了解决此类问题,我们希望对自动化异常构建进行自动标注、修复、问题闭环。错误码,是当前系统问题的一种较为直观反映。业务能结合代码注释、经验等,将错误码翻译为具体的错误原因;针对这原因一般有两种解决方案,一是可以依靠自动化恢复,二是需要人工介入处理。我们将以上过程概括为自动标注策略、自愈策略、问题闭环策略。自动标注策略指由错误码得出错误原因后,自动化标注错误分类,节省人工定位标注耗时。这要求业务线将任务日志接入统一的日志系统或使用我们规定的插件,并梳理一份错误码和错误分类的映射表,在插件中心进行注册。如此在问题发生时,工具便可以捕获错误日志,并提取其中的错误码,和错误分类做映射,并标注。自愈策略基础是自动标注策略。自愈策略接入需要先圈定自动重启的场景,即满足什么条件需要触发自愈,依赖工具产出的错误码,每一种条件为一种自愈子策略。判断当前满足自愈条件时,便触发自愈策略,如出现红灯时重启环境等。可根据业务线需要,配置超时时间、模块、内存等多个触发条件和自愈子策略,支持业务线自行定制,较为灵活。问题闭环策略同样基于自动标注策略,和自愈策略可以结合使用。在大概率需要人工介入的场景,自动创建问题的icafe卡片,卡片内容中描述问题、错误码和自动定位结果,由人工来确认问题的解决方式和处理结果。从问题出现到卡片创建再到卡片状态被修改为处理完成,才算完成闭环。在项目业务线试点中,异常任务问题上报率达到100%,问题闭环率达到94%。

三、商业收入变化大盘止损决策定位介绍

商业收入变化大盘止损决策定位过程由报警接收, 报警定位诊断、故障特征提取、止损决策、止损方案推荐组成,其核心是覆盖和诊断策略的有效性;其中覆盖又包含报警覆盖、指标覆盖两部分;报警覆盖首先需要覆盖产品线的各个子方向,指标覆盖是指对当前已覆盖报警的业务的监控指标完备性的覆盖,包含系统稳定性指标覆盖、用商指标覆盖、宏观指标&业务过程指标结合完备性指标的整体覆盖,通过完备的报警指标覆盖能第一时间感知商业大盘收入变化风险,基于报警信息制定一套故障特征标准数据结构来解析不同报警获得通用的故障特征;诊断策略对故障特征进行策略分析并最终给出有效的止损推荐方案,诊断策略的有效性对最终止损推荐的质量至关重要。当前诊断策略主要包含风险程度识别策略用于判断报警风险程度;风险指标&报警识别策略用于判断系统关联的风险指标/模块信息;异常点识别策略用于确认业务真实异常时间点;日志trace定位策略结合效果监控拓扑,对报警链路模块日志trace定位,实现精确定位到故障模块,进而对模块程序/词典变更暂停或回滚止损;根据监控影响pv计算当前报警预估损失pv指数,预估线上问题级别, 给出止损建议;通过止损库策略梳理给出完备的止损预案操作指导快速发起止损决策;为了更便于不同业务定制诊断策略,当前提供故障诊断、止损决策策略支持业务低成本自定义编写,其中故障特征可在继承通用策略的基础上自行编排、通知样式可在基本标准格式下进行子编排处理。目前商业收入变化大盘止损决策定位已完成报警触发、诊断、止损推荐的全流程机制打通,并可直接给出止损决策方案。

四、搜索UI展现case级定位方法

为了提升系统质量,质量保障同学一般会针对系统建设全方位的质量监控,虽然能召回的问题变多,但是随之而来的针对case级的定位,就会是一项耗时耗力的工作,ui展现case定位就是基于这个背景而来的。定位主要分为两个部分,一个是基础建设,二就是具体逻辑实现。基础建设是定位重要的一环,系统的复杂度会给我们定位带来极大的挑战,越是复杂的系统就越难定位。针对这个问题我们解决方案是建设完整的日志trace方案。首先为了节省资源,不单独存储日志,只存种子信息,所有日志保存一份;然后建设模块topo,将日志从上到下的进行递归检索,根据日志的内容生成请求链路。最后为了保证安全,建设流量管控,超时等机制。最终完成了秒级延迟和检索耗时的日志trace能力。二就是具体定位逻辑实现,主要是通过定位topo、结合case报警信息去触发整体的召回定位能力,然后通过日志里的进行进行正则化的匹配和提取,来判断在具体case的原因在哪些地方有体现,比如具体的资源为什么没有召回,在哪个地方被删除和修改,最终实现分钟级别的报警接收和自动定位。

---------- END ----------

推荐阅读【技术加油站】系列:

​​揭秘百度智能测试在测试评估领域实践​​

​​揭秘百度智能测试在测试分析领域实践‍​​

​​揭秘百度智能测试在测试自动执行领域实践​​

​​揭秘百度智能测试在测试自动生成领域的探索​​

​​【技术加油站】浅谈百度智能测试的三个阶段​​

​​【技术加油站】揭秘百度智能测试规模化落地​​

揭秘百度智能测试在测试定位领域实践_测试定位_02

上一篇:【源码透视】SpringBoot的SPI机制
下一篇:没有了
网友评论