测试评估是通过收集质量保障活动过程产生的各类系统表现数据，利用策略进行分析，以进一观测经过全部质量活动后的质量风险，此次分析区别于测试报告，如性能测试报告、功能测试报告，测试报告是针对某项质量活动揭露有无问题的报告，测试评估是从风险程度去判断是否要增加质量活动。测试评估往往是质量保障人员最容易忽视的环节，但随着测试自动化程度水平的提升，测试人员往往只通过自动化报告去判断质量风险，而缺少必要的分析，极容易造成漏测。

测试评估智能化通过将数据、算法、工程等相关技术有机结合，从质量活动系统表现数据、变更风险程度等方面，利用策略或算法预估项目准出的风险，以最终决定项目是否可以上线。测试评估的研究主要从风险引入、质量活动数据挖掘、风险度评估等多个领域进行研究，在该领域的实践相对较少，百度QA一直在探索研究和实践。本章节将从对应实践角度，介绍相关领域的目标、思路，涉及到的技术点、效果，希望能给到大家一定参考。

一、基于研发行为的质量风险维度挖掘

质量风险引入主要是研发阶段，即研发写出有风险代码。研究该过程，实际上是在探寻何种人在何种背景下写出何种代码容易引入风险，挖掘出因素并进行结构化，进而通过模型进行识别风险，为下一步风险控制和决策提供依据。

挖掘质量风险引入的维度有项目风险、人员风险、代码风险等，

项目风险包括开发时长、模块数、变更数等维度，可以衡量出项目规模；

人员风险包括千行代码bug率、项目熟悉度、提测打回数等，可以衡量出研发人员的靠谱程度。

代码风险包括两类，一类是变更行、函数、复杂度等代码变更信息，可以衡量出复杂程度；另一类是影响接口、UI、场景对应的用户密度、问题密度等，可以衡量出变更代码可能影响面。

基于这些数据，建立模型和规则，可以得到风险发生概率和风险发生造成危害大小，帮助判断项目qa需要介入程度，如是否可以自测、无人值守。

数据维度选择、采集是识别的基础。

1、 项目风险、人员风险依赖项目过程中留存数据，在整个交付过程会得到采集、清洗和落盘；

2、 代码风险可由历史提交情况，结合代码语法树分析AST和深度算法识别等技术计算得到，用来判断风险概率，如稳定性风险、性能风险等。

依赖风险可以通过rpc+mesh等系统架构进行获取，获取服务相互间依赖，再结合代码理解，判断项目变更是否会带来服务间影响，进而判断依赖风险概率。

二、准入风险评估及应用

准入风险评估主要由风险维度数据、风险决策、任务类型三部分组成，以判断项目预计需要用何种质量活动进行覆盖，如完全自动化、RD自测即可、QA介入或介入程度。

准入风险评估本质是测试前识别风险，根据风险推荐/预警质量活动和测试用例。建设通用数据挖掘工程能力打通数据血缘关系，获取项目风险画像、人员风险画像、代码动静态风险画像等，基于画像信息建立风险识别能力量化风险；风险控制本质是针对已识别风险给出执行建议和充分度评估；深入风险跟踪&控制，智能决策生成或执行能充分暴露风险的测试活动(如功能测试、策略测试、性能测试、灰度等)，使得系统风险和产品质量风险最低；驱动测试活动从传统的经验执行触发模式向充分度评估指导的风险驱动执行模型转变，在测试活动无法覆盖所有已识别风险即测试充分度不满足需求时给出优化建议补充测试指导。风险决策本质是综合考虑风险发生概率和风险发生时的影响程度进行综合决策，借鉴偏专家经验的规则化决策以及风控模型，产出基于规则、模型、影响的整体量化决策方案。整个风险决策闭环流程包含风险追踪数据获取、风险数据特征筛选、特征清洗、特征处理、模型开发、校验评估、模型上线、监测标注，并且将标注结果反哺风险追踪数据，完成整个风险决策流程良性循环。

准入风险评估结论主要用于测试任务分发、流程流转、测试人员分发等，通过准入风险评估结论指导后续质量方式选择自动化任务跳过、无人值守、自主测试、何种类型的QA介入，总之风险准入评估，可以用来做质量活动的最优分发，提升质量活动的合理性。

三、多维活动过程数据挖掘

项目通过准入风险评估后，会进入到质量活动进行对应的测试，需要记录每个质量活动的痕迹，用来判断通过质量活动后，前期风险准入评估风险是否得到覆盖，本环节就是要研究获取何种维度质量活动数据和抓取。下面主要讲得是比较核心的白盒覆盖率，日志覆盖率，业务请求覆盖，仿真性等数据挖掘。

白盒覆盖率：主要是测试过程中，测试用例对项目的覆盖程度，用于评判测试的完备性，细分项目有语句、判定、分支、函数等等。主流的实现思路是通过对源码文件在编译过程中产生的预处理文件进行插桩处理，及对预处理文件埋点记录函数，而后正常去编译。当正在运行的程序走到相关的代码行便会进行记录，再去对记录的数据进行挖掘和采集，得到白盒覆盖率数据

日志覆盖率：一般指的是异常日志的覆盖情况，主要用于检测异常测试的充分度。和白盒覆盖率相比，不需要单独插桩编译，会省时许多。主流的实现逻辑是使用单独的日志打印的逻辑函数。当正在运行的程序走到相关的函数便会进行记录，最后统计测试用例可以覆盖的日志情况，最终得到日志覆盖率的数据

业务请求覆盖：主要指的是通过业务场景建设业务请求知识图谱，根据经验，本身场景风险大小去细化请求路径，最终分风险级别给出所有业务场景集合，在执行测试用例的时候，来判断测试用例中业务请求在业务场景中的覆盖情况，得到业务请求覆盖的数据。

仿真性：主要分两类，一是环境仿真性，主要是和线上环境的仿真程度，包括机器，网络，程序版本，上下游情况等等，得到环境仿真性数据；二是流量仿真性，包括流量大小，潮汐，覆盖范围等等，通过数据的统计得到流量仿真性，最终给出仿真性数据。

四、基于模型的风险评估

以往当项目提测时，评估项目质量风险更多的是根据测试人员的以往测试经验来决定的。但这种评估项目风险的手段存在着人工判断存在盲区，测试人员经验不足等问题，因此基于模型的质量风险度评估系统应运而生。

本环节就是应用前几个阶段的风险维度数据+质量活动数据，用模型或规则预估项目最终风险大小，来判断项目是否应该上线或补充测试。

在风险评估中，需要考虑风险的发生的概率和风险发生的影响进行决策，因此在决策方案上，采用基于规则+模型+影响来进行量化决策。首先，建设风险概率模型，通过历史数据自动学习“经验”，用以评估项目风险发生的概率。在模型选型上，模型需要有一定的可解释性，且质量数据量较少，速度要求高等特性。

并且针对业务测试数据对各种分类算法进行效果验证。综合以上考量，选取逻辑回归（LR）作为分类模型。在模型特征选取上，选取风险引入（代码风险指标，人员风险指标等）和风险移除（测试充分度，监控完备度等）两个维度的多类特征数据作为模型输入。然后，在风险决策结论给出方面，采用风险矩阵法的思路，综合考虑风险的遗留概率(风险发生的可能性)和风险的影响程度(风险的严重程度)，得出风险的评估结论。最后，通过风险报告可视化等路径完善反馈闭环，持续优化模型迭代。

通过上述质量风险维度设计、风险准入评估、质量活动数据挖掘、风险准出评估，四个环节系统实现，把所有环节连接起来，落地业务线，在提质增效上取得很好的效果：

风险评估单Q22-Q3共识别1000+不可自主测试项目，共拦截300+bug；风险评估托管4000+自主测试项目，约节省2000+人天 。

基于风险决策进行质量保障领域，才刚起步，后续百度QA将持续从上述四个维度进行技术和算法研究，以进一步提升准召。

作者：百度Geek说

链接：https://juejin.cn/post/7156043909544542239