简单说说 缺陷检测(代码智能之缺陷检测)

阿里巴巴 前端委员会智能化小组 @ 阿里巴巴

文/ 阿里云 - 秦奇

本文章为系列文章,主要介绍代码智能(Code Intelligence)领域涉及的众多有趣的任务(Task),具体会从这些任务的简介、历史和现状等维度展开介绍,希望让大家对于代码智能有一个深切的认识(前篇:和你说说智能代码推荐)。 ​

本文的主角是 代码缺陷检测,即判断一段代码中是否有Bug。这听起来有点玄乎,实际上呢,就是根据已有经验和历史数据进行归纳总结,从而得出结论,那么有没有觉得和 “算命”有点像呢?注意:本篇的缺陷检测仅指 检验是否有Bug,而不涉及到 缺陷的定位 和 缺陷修复的部分。


缺陷检测(Defect Detection)

想象中的缺陷检测应该是这样的,



或者是 这样的:


然而实际上并不是,缺陷检测仅仅预测一段代码是否存在Bug,而并不关心Bug在哪里,是什么。所以缺陷检测在实际的开发或测试中并没有特别大的效用。可以想像一下,我告诉你一段代码有Bug,但是并不告诉你Bug是什么,是不是很抓狂?并且在我并不能保证一定有Bug的情况下,能找出来问题还好,找不出来会岂不是更抓 狂。就变成了“你觉得有到底没有Bug呢”? 只能来一句:我不要你觉得,我要我觉得。。。 ​

回到正题,缺陷检测 并不针对开发的场景,唯一可能有用的是在Code Review的时候,比如告诉你当前这个文件大概率存在问题,这个时候做CR的人就需要格外注意了。 虽然实际效果一般,但是并不妨碍它作为代码智能领域的一个有趣的小任务并一直存在着。 ​

缺陷检测的历史

缺陷检测的历史可以说和缺陷被定义的历史是一样的,在缺陷被定义的时候,就有人在思考如何通过工具能够检测出这些缺陷或者避免一些缺陷。比如编译语言在编译过程中能够发现一些静态错误从而导致编译不成功;还有代码分析工具,或者说 静态扫描工具,也能够提前发现一部分缺陷,这些都属于缺陷识别和定位的部分了,我们后续再聊。 ​

缺陷检测的思路

常用的缺陷检测思路是:从历史代码中提取出有用的特征,然后根据这些特征进行训练得到预测模型,从而对之后的代码进行预测。 这里的训练单元可以是代码片段和文件,也可以是 一次提交(Commit),相比于文件,代码片段和提交的预测相对更有效一些,很容易定位到缺陷的位置。而文件由于篇幅过大,从而定位缺陷的难度也随之上升。 ​

常用的特征包含以下这些:

  • 基于变更元数据的特征,比如开发者、提交时间、变更日志、修改文件行数等
  • 基于变更代码内容的变更,比如代码复杂度特征,变更代码、日志和文件名的词频率、或者基于变更前后代码文件的抽象语法树(AST)相同类型节点数量的差值。
  • 基于软件演进过程的变更,即基于项目代码修改历史量化变更,比如变更相关文件被修改的次数、修改文件的开发者人数等信息
  • 与软件项目管理系统相结合,可以提取更多纬度特征,比如CR信息、缺陷信息等。
  • 有缺陷的代码信息特征,一般是源代码或者对应的抽象语法树

前3项更偏一些量化指标特征,与缺陷的相关性较差,但是比较容易获得和统计;而后面两项跟缺陷更加相关一些,但是获取难度更大一些。 ​

缺陷检测的未来

之前说到,单独的缺陷检测技术并不能为我们带来什么,更多的需要缺陷定位和缺陷修复等技术的配合使用。近几年,由于深度神经网络的快速发展,有了很多基于深度模型的缺陷检测&修复相关的论文和研究,也有一些推出的产品,比如微软的DeepDebug,号称可以自动修复Python的缺陷。具体并没有试用过,因此效果也未可知。不过可以猜测一下,类似于代码推荐,更多仍在PR阶段,离实际应用还有一段路要走。不过要始终坚信,技术始终是在发展的,说不上哪一天,我们就可以拥有一个自动改Bug的机器人了呢。


不说了,改Bug去了。。。 ​



淘系前端-F-x-Team 开通微博 啦!(微博登录后可见)
除文章外还有更多的团队内容等你解锁🔓