代码审查缺陷密度量化模型研究

鸦 文，杨沁梅

（中国电子科技集团公司第二十八研究所，江苏 南京 210007）

0 引言

测试是“使用为发现错误所选择的输入和状态的组合而执行代码的过程”[1-4]，代码审查是软件测试的手段之一，是在不执行软件的条件下有条理地仔细审查软件代码，从而找出软件缺陷的过程。代码审查必须依靠具有软件系统开发经验、编程经验、测试经验的技术人员集体审查[5]。进行代码审查的主要目的是提高软件质量，及早发现软件缺陷，避免因这些缺陷造成更大的灾难[6]。在开发过程初期进行软件代码审查非常有价值，不仅可以找出后期软件测试阶段难以发现或隔离的软件缺陷，降低研发成本；同时还可以促进开发团队内部沟通和知识共享，提升团队开发能力。

量化管理是CMMI的主要内容之一，量化管理使得软件管理者拥有决策的客观基础，能在量化的范围内预测性能，可以有效地监控项目过程，处理过程偏差的特殊原因[7-12]。

为此，可以将代码审查过程识别为影响项目目标达成的关键过程之一，通过建立过程性能模型和使用适当的量化分析方法[13-14]，来指导代码审查活动的策划和实施，达到提升产品最终质量的目标。统计过程控制中主要利用控制图来记录过程质量[15]。

1 代码审查平台

软件项目管理过程中，组织往往缺少量化的数据支撑，从而导致对于有关量化的改进目标制定或者项目的量化目标制定无从下手[16]。为此，可以通过集成开源的配置管理、代码检测、权限控制工具，建立代码审查平台来进行在线审查和数据采集，为后续的模型建立和量化分析过程提供平台支撑。

一种可行的代码审查平台设计架构如图1 所示。

图1 代码审查平台架构

其中：

（1）Crowd 是atlassian 公司推出的集成化组件，其实现和配置简单，功能齐全，用于用户管理和授权登录。利用此平台可录入代码审查活动相关人员信息并赋予不同的使用和管理权限。

（2）Crucible工具是一个代码检测工具，能检查、注释、编辑代码，并记录结果，帮助开发人员发现和纠正缺陷，提高代码开发效率。代码审查活动主要依托共用平台Atlassian Crucible 模块实施。

（3）Gitlab 是一个用于仓库管理系统的开源项目，使用Git 作为代码管理工具，并在此基础上搭建起来的Web服务。该模块用于浏览源代码和代码缺陷管理。开发团队可使用该模块浏览历史版本，也可以利用其代码片段收集功能实现代码复用、查找。该模块非强制使用，由项目组/业务室选择使用。

2 代码审查触发时机

代码审查由项目软件负责人或专业/业务负责人在完成以下代码研发和自测后组织执行。可重点针对以下对象进行审查：

（1）被定义为关重件配置项的代码；

（2）核心算法、主要业务逻辑、关键数据处理、提供对外接口的代码；

（3）新员工产生的代码；

（4）前期测试过程中问题较多的软件代码。

3 代码审查

3.1 审查准备

3.1.1 建立专家库

项目研发组织首先应建立代码审查专家库，主要成员可以是组织内各领域的资深程序员和各专业/业务的技术骨干。

每次代码审查前，由各项目/专业/业务负责人依据被审查代码的专业/业务类型从部门代码审查专家库中选取除被审代码编写者之外的代码审查人员，成立代码审查组，并指定代码审查组长。

3.1.2 设置用户权限

依托代码审查平台可以实现用户的添加和权限设定，主要步骤如下：

（1）由配置管理员在Crowd 模块中录入人员信息（支持分组），并设定各模块管理员和使用者角色；

（2）配置管理员将Crucible、Gitlab 模块的权限信息与Crowd 相连，确保Crowd 模块中的用户信息在各个模块中可见；

（3）各项目/专业/业务负责人在需使用的模块中设定人员权限。

3.1.3 选取和提交审查代码

代码审查前，各项目/专业/业务依据第2 节选取需审查代码（但不限于）。

3.2 执行代码审查

代码审查专家在Crucible 上开展代码审查活动，审查重点为代码整体架构、风格、逻辑质量等，审查项及主要要求参考表1。

表1 首轮采集

具体方法：

（1）代码审查专家登录“lzb.cru.com:8060/cru”，打开代码开展审核；

（2）点击有问题的代码，并输入审查意见，点击“Comment”提交。

3.3 审查问题整改归零

（1）代码审查后，开发人员根据代码审查专家提出的问题对代码进行修改；（2）完成修改后，重新提交代码审查；（3）代码审查人员进行回归确认。

3.4 审查结果处置

项目代码审查活动结束后，由代码审查组长汇总、分析代码审查数据，并及时将代码审查过程中遇到的典型编码缺陷在开发团队或全部门集中宣贯，减少典型缺陷重复发生。

4 代码审查过程性能模型建立

4.1 模型定义

代码审查缺陷清除模型预测值为代码审查发现缺陷的密度，分析确定影响部级代码审查质量的因子是：审查专家能力、开发人员能力和代码审查速率。即：代码审查发现缺陷的密度＝f（审查专家能力，开发人员能力，代码审查速率）。

模型因子取值如下：

（1）审查专家能力取值：5 表示能力高，从事软件编码工作5 年及5 年以上；3 表示能力中，从事软件编码工作大于等于3 年且少于5 年；1 表示能力低，从事软件编码工作少于3 年。

（2）开发人员能力取值：5 表示能力高，从事软件编码工作5 年及5 年以上；3 表示能力中，从事软件编码工作大于等于3 年且少于5 年；1 表示能力低，从事软件编码工作少于3 年。

（3）代码审查速率＝代码审查代码规模÷代码审查总工时。

4.2 数据采集

首轮采集了21 组有效数据，见表1。

4.3 模型试算

4.3.1 正态性检验

经使用Mintab工具计算得到的审查专家能力、开发人员能力和代码审查速率这3 个参数的正态性检验结果如图2 所示。

图2 正态性检验结果

4.3.2 相关性分析

经使用Mintab工具计算得到的审查专家能力（x1）、开发人员能力（x2）、审查速率（x3）和代码审查缺陷密度（Y）这4 个参数的相关性结果如图3 所示。

图3 相关性分析结果

4.3.3 回归分析结果

进一步使用Mintab工具计算，得到初步建立的模型算法，如图4 所示。即：

图4 回归分析结果

代码审查缺陷密度（个/千行）=3.583+0.076×审查专家能力-0.159×开发人员能力-1.977×代码审查速率

4.4 基线建立

经Mintab工具计算得到代码审查缺陷密度概率图如图5 所示，计算得到的P 值大于0.05，显示样本数据服从正态分布。

图5 代码审查缺陷密度概率图

进一步使用控制图检查数据的稳定性，如图6 所示，数据点随机地分布在中心线（即基线均值）上下，且在基线上下限之间，表明数据基本稳定。

图6 数据稳定性检查

最终获得的基线值如图7 所示，即代码审查缺陷密度平均为1.921 9 个/千行代码。

图7 代码审查基线值

5 结论

研发团队所属组织可以根据组织对产品质量的要求和团队实际情况，参考以上得到的代码审查缺陷密度平均值来设定组织级代码缺陷目标，并使用建立的模型，依据代码审查的代码规模、选定的审查专家能力，计算得到代码审查工时的估计值，并据此估计值进行代码审查活动的策划。通过所属项目后续的测试、检验活动，可以再逐步分析代码审查遗留问题的影响，并重新修正模型和目标，进而逐步达到通过有效代码审查提升代码质量的目的。