小编有话说

相信在日常的测试活动中，大家多少会遇到以下几种场景：

研发的某些“很简单”的代码变更，测还是不测，不测的话风险怎么控制；
某些版本交付，都经过大量的测试，但谁能保证线上有多大风险或还有多少潜在的风险；
随着自动化测试程度的不断提升，越来越多的质量保障无人介入，但自动化测试的有效性谁去保证（当前更多考虑的覆盖率或者用例是否通过）；
某些类型的自动化或测试执行，长期召回不了问题，逐渐成为“鸡肋”，但是又不敢轻易“下线”；等等。

带着这些问题，百度智能测试团队于2019年底开始致力于研究质量度模型，希望通过质量度模型可以实现：

通过获取研发过程数据+自测+自动化数据，用质量度模型决策是否需要跟进后续测试，以减少不必要的投入和降低测试周期；
通过质量度模型，获取所有测试行为后的数据+研发数据，预估风险度，以进一步提升交付团队对风险把控的信心和召回可能漏出的问题；
通过质量度模型+自动化测试任务特点，智能决策任务是否需要执行、执行哪些用例或多长时间，以实现性价比高的测试，从而提升效能。

经过一年多的研究、开发和实验，百度智能测试团队借助强大的质效中台提供标准化、规模化的数据+风险模型研究，在百度系的众多业务线得到试点和落地，现总结成系列文章（主要解决1和2两个问题，质量度模型与自动化测试任务的解决将在智能构建系列文章呈现），推送给同行，希望能够一起交流和探讨。

具体系列文章如下：

*系列文章可能因为具体项目推进情况会发生调整或合并

质量度模型系列一---测试智能分级与风险评估在商业平台的应用探索

质量度模型系列二---质效中台助力实现质量度模型规模化落地

质量度模型系列三---风险预估算法调研与应用实践

质量度模型系列四---质量度模型特征挖掘方案

质量度模型系列五---基于质量度模型的风险决策实现交付过程无人值守

导读：本文主要介绍在测试分级和风险准出两个场景，引入质量度模型，通过客观数据和模型策略对风险进行精准评估，从而解决完全靠人工评估带来的误判和因担心风险而进行重复测试的问题，实现质效合一，即在保证质量的情况下提升交付效率。

一、背景介绍

保证质量的前提下快速价值交付一直是测试改进不断追求的目标，高效能的价值交付是敏捷开发，持续交付等不断改进追求的方向。

从上图所示一个传统的研发流程说起，不管是敏捷开发还是其余开发模式，在需求评审完成进入代码开发之前，PM，RD/FE，QA要坐在一起确定项目排期和跟进方式（QA是否介入和介入程度），即为了快速向用户提供服务，有大量项目（如小优化升级）是通过RD自测并自动化测试通过后后直接上线的，这也是当前RD/QA高人力配比下，项目能快速交付主要原因之一。

对上面场景进行总结，随着百度自动化测试和自动化测试技术产品化，越来越多测试靠机器完成，越来越多的测试行为由RD进行，所以2019年起提出自主测试概念：

自主测试即RD在研发过程中自行利用测试服务和完备有效的自动化进行质量保障，再由QA或质量度风险评估直接给出可交付结论的研发行为。

但随着自主测试的普及，存在两个方面问题：

1）判断自主测试完全依赖人，会导致误判的风险漏出或可自主测试判断为非自主测试

人工经验评估测试范围和项目风险是非常主观的，再有经验的QA也不能保证每次评估都准确（尤其是新人不断增多的业务）。在微服务、中台化的大趋势下，若RD改了一个核心方法某行代码，改动影响很多最外层接口甚至第三方服务，会带来很大质量风险。

另一个重要影响是，很多小型升级的项目可以转化为自主测试直接上线，但RD担心带来质量问题，要求QA介入进行测试，这会很大程度降低团队的交付效率。

2）判断测试准出报告依赖人，容易造成风险误判，进而漏出风险

如RD自主测试不等同于不测试，RD测试情况到底怎样，有没有人能说清楚？还有QA跟进测试常规项目，目前是完全是靠人的判断是否可以准出，有报告输助也需要人进行分析判断，容易造成误判，还是会有漏出出风险。反之，如果已经测试充分，能否提前准出，避免后期低效重复测试？

二、解决思路

上述问题本质是，RD/QA对不同风险项目进行人工评估分级，因为人的经验、素养和知识面有一定差别，会使得自主测试的风险程度不一，导致漏出。互联网金融有个类似场景：贷前审核环节借助大数据风控模型，对贷款人基础信息，网购，支付等信息进行更全面细致评估，来替代原银行漫长的表单提交+人工审核模式，在大幅降低违约风险的同时，提升审核效率。可类比，针对不同项目(贷款人)想到快速达到准出（无违约风险）标准并上线，也可通过获取项目各个维度信息（贷款人信息），选取合适模型（风控模型）对其进行更加精准客观的评估，以达到快速交付的目的。

具体来说：

1）项目升级较小；

2）pm、rd很靠谱，代码变更少；

3）自测已经把需要回归的场景全部覆盖；

等相关因素作用下，是否可以判断为在RD提测后不需要QA跟进测试，直接上线。

相反：

1）一个项目评估时变更小；

2） PM, RD都为新人，代码虽然变更少，但可能影响了其它接口，甚至第三方服务，就需要QA跟进测试来降低项目质量风险。

当前企业向数字化转型认识已经被提到一个前所未有的高度，把数字化转型作为企业的战略核心，这个过程中有大量基础数据可以积累下来为研发效能改进提供数据支撑，同时这些基础数据也可以结构化为研发过程自身所用，通过结构化的数据为项目做立体，精准画像，通过机器学习训练项目质量度模型，从而为研发测试过程项目分级和准出提供客观的更加置信的决策。

本文开始研究项目质量度在解决这两个问题方面的可行性和实践，从理解角度给项目质量度模型下一个定义：以项目维度为出发点，收集项目从需求准备、研发、提测、测试等环节项目研发、质量行为的数据，建立项目质量度模型，为项目分级和准出提供客观决策，让项目质量风险可见。

三、技术方案

1. 研发流程规范

引入项目质量度模型，一个前提是高度统一且规范化的研发流程，主要有两个原因：

1）高度统一且适合业务线特点的研发流程，将研发过程中的基础数据可以按项目聚合的前提条件，如需求管理，任务拆分，代码提交，环境，持续集成，测试覆盖数据分布在不同的工具链，统一的研发流程可以通过父子关系，需求id，提交id等将任意工具链、研发环节的数据聚合到需求维度串联起来，如对被测环境上任意实例的测试，无论手工还是自动化测试覆盖都可以快速直接与需求id关联，形成对本次项目代码变更测试覆盖的精准刻画。举一个反例，若需求id里包含多个pm提出需求，或者模块分支代码中包含多个项目需求代码，在基础收集过程中很难从项目维度将数据串联起来，同时若准出时没有达到要求，也很难找到对应负责人做相应测试覆盖提升。

2）模型评分后需要和交付过程结合起来落地，经过人工确认作为最后一道防线防止模型误判，模型准确率和召回率提升本身是一个不断迭代优化训练过程，需要将正确的数据做新样本沉淀到训练数据集，不断迭代优化评分模型，如下图所示的各阶段关联数据：

2. 项目特征选取与获取

用结构化数据对项目风险质量进行全方位，客观的精准刻画是对项目评分基础。按项目的研发阶段将项目质量风险按需求，开发，测试3个维度进行划分。

2.1 项目特征选取

项目需求画像

含需求大小、关联方数、需求变更数、PM画像等数据，如一个项目关联方越多，评审过程中变更次数越多，PM为新人，则项目需求维度风险越高。

项目开发画像

含代码变更行数、变更方法圈复杂度、方法调用链、影响接口、第三方数据、开发周期、代码review数据、静态代码扫描、RD画像等数据，如代码变更量越大，影响自身多个核心接口，影响多个第三方服务，RD为新人，项目质量风险就越高。

项目测试画像

用例准入执行数量、持续集成结果、增量覆盖率、bug收敛曲线、项目千行代码bug率等，如自测或QA测试用例覆盖场景越多，持续集成通过，增量覆盖率越高，bug曲线收敛比较好，则项目质量风险越低。

2.2 极致全面的测试中台能力，助力基础特征数据获取

下面介绍获取确定下的项目特征。当项目启动时PM、RD、QA按研发流程规范将需求评审、代码提交、评论、测试活动等行为数据都存储在公司统一研发工具链，便可通过api或订阅等方式获取各个维度基础数据，但这些基础数据有些符合人工判断项目风险特征，如需求大小，需求变更次数，时间节点，或研发阶段代码变更行数，开发周期等，可以直接用来刻画项目，但有些基础数据需要和其它数据组合起来进行二次加工或离线数据挖掘，才能生成符合人工判断项目风险特征，如代码复杂度需获取变更代码，并使用工具对代码进行特征分析，千行代码bug率需对RD历史提交代码行和bug记录进行分析，bug收敛曲线需对天粒度bug数进行数据分析等，如下图所示，工具链基本采集了非常多的基础数据。

获取基础数据并可对其进行二次加工是质量度落地的另一基础，即极致的数据采集测试中台能力。基础数据获取需要在无感知或极少人力介入情况下才能在真实场景中落地，若一线QA在大量测试工作同时，增加手工输入和人工触发各种数据收集成本，很难在业务线推行。同理，测试中台能力稳定性如自动化误报较高，这些数据对于模型来说是脏数据，可能成为干扰因素。如代码调用链，复杂度，静态代码扫描，JS增量覆盖率等基础数据的获取因篇幅原因本文不再一一展开，只以java增量覆盖率自动获取为例展开介绍。

首先，环境在自动部署默认启动覆盖率收集插件（jacoco on-the-fly模式收集覆盖率的agent配置），推送实例的部署信息如模块名，分支名， commitid等信息到质量度模型系统DB。当QA在被测试环境进行手工或自动化测试时，桩数据保存在内存当中。

其次，质量度模型系统客户端定时通过环境推送过来的实例列表，从各实例内存中导出桩数据中间文件exec文件，同时环境插件做兜底，任意实例重启或暂停前都会触发覆盖率收集任务，防止覆盖信息丢失。

最后，客户端收集生成增量覆盖率报告所需的桩数据文件，源代码，jar包，变成方法列表（对jacoco框架做二次封装改造，单次生成增量覆盖率报告本文不再展开）生成可解析的增量覆盖率报告，解析并入质量度模型系统。

3. 模型选取

3.1 规则建模

先从一条简单规则开始：

缺点是大量的if else，阈值的选取需要对业务有很深的理解，并且频繁变动需要开发支持，规则模型主要用于早期的数据积累。

根据智能化程度将智能测试层次分为3层：人机协作、自动化、智能化。人机协作，指人在测试数据的支撑下，还是人来进行判断。自动化，是工具在做判断，人工不再干预，但是工具需要人事先编好了规则，工具依照既定的规则作出判断，也就是这里的规则模型。第三层是智能化，规则不再定死，也不是人给定，而是通过数据不停地学习，当规则模型积累了足够的数据量时，引入模型算法，进行智能化判断。

3.2 基于数据的建模方法

项目能否自测问题本质是项目分级的一个0/1化决策问题即分类问题。

3.2.1 常见分类算法

常见的分类算法有KNN、朴素贝叶斯、决策树、逻辑回归、SVM，以及集成分类器。KNN算法属于最简单的机器学习算法之一，核心思想是从训练集中找到和新数据最接近的K条记录，然后根据他们的主要分类来决定新数据的类别。朴素贝叶斯对于给出的待分类项，求解在此项出现的条件下各个类别出现的概率，认为此待分类项属于概率最大的类别。决策树按照一定特征选择的准则，从根节点开始，递归的生成决策树，3种决策树算法ID3 、C4.5、cart分别使用信息增益最大、信息增益比最大、Gini 指数最小作为特征选择的准则。线性回归的任务是找到一个从特征空间X到输出空间Y的最优的线性映射函数，逻辑回归将线性回归的( −∞ , + ∞ )结果，通过sigmoid函数映射到( 0 , 1 )之间，以实现分类决策。SVM原理是找到空间中的一个能够将所有数据样本划开的超平面，并且使得样本集中所有数据到这个超平面的距离最短，线性不可分问题可通过核函数转化为高维度线性可分问题。

除了上述介绍的分类算法，通过构建并组合多个学习器来完成学习任务，通常可以获得比单一学习器优越的泛化性能，也就是集成分类器。集成分类器分为两类，个体学习器之间存在强依赖关系、必须串行生成的序列化方法，Boosting算法（AdaBoost、GBDT、XGBoost）；个体学习器之间不存在强依赖关系、可同时生成的并行化方法，Bagging 和随机森林。

考虑到数据量、可解释性、样本分布不均等因素，团队主要研究lr算法和评分卡，其中lr算法是当前落地过程中使用最多的算法。

3.2.2 逻辑回归模型

另外一种是逻辑回归模型，名为“回归”的线性分类器，线性回归演化来的。线性回归的任务是找到一个从特征空间X到输出空间Y的最优的线性映射函数。但线性回归可以预测连续值，但是不能解决分类问题。而逻辑回归是在空间中找到一个决策边界来完成分类的决策，我们需要根据预测的结果判定其属于正类还是负类，即将线性回归的( − ∞ , + ∞ )结果，通过sigmoid函数映射到( 0 , 1 )之间，以实现分类决策。

Sigmoid 函数图像如上图所示，函数形式为：

线性边界形式如下：

其中，训练数据为向量

，最佳参数

。

构造预测函数可以表示为：

的值表示预测结果取1的概率，若概率大于阈值则预测为1。一般选择0.5作为阈值，实际应用时特定的情况可以选择不同阈值，如果对正例的判别准确性要求高，可以选择阈值大一些，对正例的召回要求高，则可以选择阈值小一些。

在测试准出场景过程中，100%测试覆盖在常规的软件测试过程中一般是不可达的（即使100%的代码覆盖也不能保证没有bug），其时间成本也不允许，根据项目的变更风险，完成哪些测试类型，达到怎样的增量覆盖是一个相对安全测试质量呢，而逻辑回归模型刚可以动态调整测试类型，用例覆盖场景，增量覆盖率等正向特征预测一个最小的值，使模型对样本的决策结果从0变成1，从而动态给出测试准出的提升建议。比如在质量风险较低的项目，可以在一个较低的增量覆盖就可以准出，而质量风险较高的项目，需要较高的增量覆盖率，更多联调场景，第三方回归才可以准出。

3.2.3 评分卡模型

最后介绍文章开始提到的在软件交付过程中引入质量度模型出发点，“跨界”参考了金融风控领域信贷申请过程最常用的模型，申请评分卡模型(A卡)。它是指根据客户的各种属性和行为数据，利用一定的信用评分模型，对客户进行信用评分，据此决定是否给予授信以及授信的额度和利率，从而识别和减少在金融交易中存在的交易风险。

参考贷前申请评分卡，给出项目质量评价卡模型示意图如下：

项目质量评分=基准分+需求变更评分+代码变更评分+增量覆盖率评分，若某个项目质量评分大于项目质量高的阈值得分，则认为项目无风险可以准出。反之，刚认为项目有风险，需要根据提示继续提升手工测试覆盖或与第三方联调，或回归自动化等等。

评分卡模型的开发流程如下图所示：

数据获取：如第二章节提到从公司工具链获取基础数据，并以项目维度聚合生成项目质量画像样本，包含2种来源，一是冷启动时历史数据挖掘，二是在模型在业务线落地时经过人工打分标准的数据。

EDA(探索性数据分析)：这个环节主要是指每个维度数据的缺失、异常情况、平均值、中位数、最大值、最小值、分布情况等，以便制定合理的数据预处理方案。主要有直方图、箱形图等指标描述样本总体情况。

数据预处理：在对样本数据整体情况有整体了解后，需要对缺失值，异常值进行处理。比如新人的千行代码bug率，未按流程规范提交代码导致增量覆盖率数据未自动获取，这里可以根据样本之间的相似性填补缺失值，若样本近正态分布则采用平均值，若样本偏态分布可以中位数填充。也可以根据变量之间的相关关系填补缺失值，可以采用随机森林法对缺失值进行补充。异常值进行处理，比如开发周期超过45天，或单项目代码变更量超过2万行（1.0项目除外）的样本，常规迭代升级可以从已有样本中结合人工经验确定一些明显与实际值不符的样本，可以直接进行删除处理。

LR模型开发：评分卡模型通过对变量进行分箱来实现变量的分段，分箱主要是对连续变量进行分段离散化；同时将多状态的离散变量进行合并，减少离散变量的状态数。常见的分箱方法有：

等频分箱：把自变量按从小到大的顺序排列，根据自变量的个数等分为k部分，每部分作为一个分箱。
等距分箱：把自变量按从小到大的顺序排列，将自变量的取值范围分为k个等距的区间，每个区间作为一个分箱。
聚类分箱：用k-means聚类法将自变量聚为k类，但在聚类过程中需要保证分箱的有序性。分箱之后我们便得到了一系列的离散变量，接着我们需要对变量进行编码，将离散变量转化为连续变量。

WOE编码是评分卡模型常用的编码方式。WOE 称为证据权重(weight of evidence)，是一种有监督的编码方式，将预测类别的集中度的属性作为编码的数值。对于自变量第箱的WOE值为：

其中是第i箱中坏样本占所有坏样本，是第i箱中好样本占所有好样本比例，是第i箱中坏样本的数量，是所有坏样本数量，是第i箱中好样本的数量，是所有好样本数量。

特征分箱有效处理特征中的缺失值和异常值，数据和模型会更稳定，同时简化逻辑回归模型，降低模型过拟合的风险，提高模型的泛化能力。WOE编码操作可以提升模型的预测效果，将自变量规范到同一尺度上，便于分析变量与变量之间的相关性。

生成评分卡： 我们将某个项目有质量风险的概率设为p, 则无风险的概率为1-p, 可以计算无风险和有风险项目比率为：

则评分卡设定的分值刻度可以通过将分值表示为比率对数的线性表达式，即

A和B是常数，公式中的负号可以使得逾期概率越低，得分越高。通常情况下，这是分值的理想变动方向，即高分值代表低风险，低分值代表高风险。A和B的值可以通过将两个已知或假设的分值带入计算得到。通常情况下，需要设定两个假设：

某个特定的违约概率下的预期评分，即比率odds为时的分数为
该违约概率翻倍的评分（PDO）

则根据以上假设odds为2时的分数为，解议程组可得：

在实际的应用中，我们会计算出每个变量的各分箱对应的分值。新样本产生时，对应到每个分箱的值，将这些值相加，最后加上初始基础分，得到最终的结果。

上面的公式中的变量是出现在最终模型的入模变量。由于所有的入模变量都进行了WOE编码，可以将这些自变量中的每一个都写成的形式：

3.2.4 评价指标与模型训练分析

使用分类器进行预测结果可以分为四类，得到一个二分类的混淆矩阵：

	预测不存在风险	预测存在风险
实际不存在风险	True Positive(TP)	False Positive‍‍‍‍ (FP)
实际存在风险	False Negative (FN)	True Negative (TN)

基于以上分类，度量预测准确度的指标有：准确率（Precision）、召回率（Recall）、正确率（Accuracy）。

为了做实验对比，我们对KNN、朴素贝叶斯、SVM、LR、CART决策树做了些实验对比，以便更好的选择合理的模型。

模型训练数据基于从业务线收集到的结构化历史数据，需要通过自动化和人工标注相结合的方式剔除异常数据后，再进行训练组和测试组数据划分。使用sklearn作为训练工具，不同分类器在数据集上的分类效果如下：

方法名	准确率	召回率	正确率	AUC值
KNN	90.00%	82.89%	79.27%	0.7686
朴素贝叶斯	82.16%	100.00%	82.90%	0.9278
SVM	97.52%	77.63%	80.83%	0.9020
LR	91.46%	98.68%	91.71%	0.9437
CART决策树	94.12%	94.74%	91.19%	0.9090

得到不同分类器在数据集的ROC曲线如下：

可以看出，在相同数据集上虽然准确率逻辑回归模型在召回效果上会更好，也更加符合QA基本价值导向，即在保证质量的前提下去提升效率，且单从模型性能评价指标AUC来看，在数据集上的性能逻辑回归也相对更好。

另外逻辑回归模型还有另外落地场景，项目的需求变更，代码复杂度，bug收敛曲线等类型的特征认为是负向特征，即这些特征值越大，项目风险越高，能准出的概率越低。为了达成准出需要尽可能的提升增量覆盖，用例签章，自动化结果等正向特征值“中和”负向特征，使模型判断可以准出概率达到阈值，从而实现准出动态预估的功能。即项目风险低，预估的测试活动要求低，项目风险高，预估测试活动要求就高。也符合人对项目风险的识别后的基本行动导向。

评分卡模型的实验数据因进行了分箱和WOE编码转换，在对一些特征缺失的样本预测鲁棒性更好，整体召回率有所提升，整体f1测度提升较好。但自动分箱不满足单调性诉求，分箱成本很高，而模型的效果受分箱的合理性影响较大，目前仍在优化中。

4. 实现落地--基于质量度模型的交付架构

1）可视化平台

作为交互层主有3个作用，一是以项目维度聚合项目涉及的模块，代码，分支，cimmitid，bug，项目状态等基本信息，统一研发过程，二是聚合所有测试能力，根据项目特点推荐不同的测试工具，三是构建增量项目的画像样本，与模型侧交互，并将模型打分结果呈现给最终用户。

2）工具链层

项目研发过程是托管在公司工具链平台，除了基本的需求，代码，流水线管理，还有环境，用例，自动化平台，精准系统等测试能力都属于这一层。

3）基础数据获取

从工具链中获取项目基础数据信息，根据需要做简单的二次加工。

4）特征工程

对基础数据做缺失异常值处理，数据分箱，编码等操作。

5）模型训练评估及部署应用

模型在测试集上经常评估后发布到策略中台，可视化平台在收集模型需要项目特征后请求策略中台，获取打分结果和报告，在人工确认并标注后，将增量项目样本推送到数据中台，分迭代优化模型。

5. 业务效果

1）自主测试转化

商业平台是引入项目质量度模型的业务线，自主测试的占比已经从最初完全依赖人工评估25%，通过模型客观判断提升至60%，而这一比例随着数据特征不断的补充，对项目质量风险刻画更加精准，以及模型和落地流程不断优化，仍有10%~20%的提升空间，在降低项目平均交付周期同时可以大幅提升项目交付吞吐量，从而提升交付效能。

2）召回能力提升

通过质量度在准出环节的风险拦截，在有针对性的测试补充过程中召回40+问题，在高效交付同时保证了测试质量。

四、总结

在交付效能提升的过程中，针对传统研发过程中测试分级和准出两个场景完全靠人工评估无法保证质量，经常导致漏测，漏评的痛点问题，通过收集需求，研发，测试，上线各个研发阶段数据对项目进行精准刻画，并引入项目质量度模型，为项目分级和准出提供客观的风险决策支撑，让项目质量风险可见。这里需要指出是质量度落地需要研发流程、环境搭建、测试中台能力高度统一并具备高稳定性，才能为模型提供精准的聚合数据支撑。

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

招聘信息

百度MEG质量效能平台致力于打造业界领先的智能化测试技术体系，长期招聘测试开发及JAVA、C++、移动软件开发、机器学习／数据挖掘／自然语言处理工程师，坐标北京、上海、深圳。

欢迎感兴趣的同学发送简历至：

QA-talent@baidu.com

end

点个“在看”少个 bug 👇