现在PRECFIX技术已经在阿里巴巴团体内部落地并获得好评，关于“PRECFIX”技术的论文被国际软件工程大会（ICSE）收录。张昕东(别象) 阿里巴巴 云研发事业部 算法工程师阿里巴巴在缺陷检测技术方面遇到的三个挑战编码是DevOps的重要一环，我所在的部门主要卖力阿里巴巴团体的代码托管。在平台业务的背后，我们建设了一系列智能化能力用来赋能前线业务。

依赖底层的代码图谱和离线数仓（离线数据堆栈）的数据能力，代码智能衍生出了缺陷检测、代码生成、代码克隆、代码宁静等能力。今天主要先容一下我们在缺陷检测领域的开端探索和实践。

缺陷检测和补丁推荐几十年来一直是软件工程领域的难题，又是研究者和一线开发者最为体贴的问题之一。这里讲的缺陷不是网络毛病、系统缺陷，而是隐藏在代码中的缺陷，也就是法式员们戏称的“八阿哥”（即BUG）。每位开发者都希望有一种智能的缺陷检测技术来提升代码质量，制止踩坑。

所谓“最迷人的最危险”，如此令人着迷的技术自然有着重重阻碍。在研究了现有的一些解决方法以及阿里巴巴内部数据集的特征后，我们将缺陷检测技术在阿里巴巴产物落地上的挑战归纳为三个方面：庞大的业务情况首先阿里巴巴经济体业务种类繁多，有底层系统中间件的代码，有物流的代码，也有宁静、人工智能等各个领域的代码，业务在变，代码缺陷类型也在变。代码数据只增不减，代码缺陷类型捉摸不透，缺陷检测的难题不言自明。

以Java语言为例，学术界的Java缺陷公然数据集常用的是Defect4J。Defect4J包罗6个代码库，有快要400小我私家工确认的缺陷和补丁。这些代码库是比力基础通例的代码库，缺陷种类容易划分，一部门研究者也做了特定缺陷种类的研究，对症下药效果尚可，然而换了一种缺陷类型，那么检测的效果就很难令人满足了。

在阿里巴巴数据集中，有众多的缺陷类型难以界说，希望能有一种对缺陷类型泛化能力强的缺陷检测与补丁推荐的方法，不说“包治百病药到病除”，但希望能够适应差别的“病症”，提高代码“免疫力”。有限的辅助资源第二大挑战泉源于有限的辅助资源，这也是导致许多学术界相关结果无法直接复现使用的原因。

何谓辅助资源，常用者有三：测试用例，缺陷陈诉，缺陷标签。虽然大多数线上代码都已经到达了很高的测试笼罩率，可是由于代码质量参差，有一大部门代码库是缺乏测试用例的，我们也缺少足够的缺陷陈诉去直接定位缺陷。

我们也想实验过通过缺陷标签来学习缺陷模式，然而自动打标签的方法准确率不高，而人工给如此庞大的数据集打标签是不太现实的。产物落地的要求而最难现实的是第三大挑战，来自产物的落地要求。

作为一项技术，需要在产物中寻找落地的时机。而真实的落地又对技术有极高的要求：我们构想的主要落地场景是代码评审中的缺陷静态扫描及补丁推荐。

产物司理说：“检测历程要高效，只管不要给误报，定位缺陷还不够，补丁方案还得让用户知道。”业界和学术界较为盛行的缺陷检测手段和其局限性搞研究做创新自然不能固步自封，闭门造车。我先来给大家简朴地先容一些相关领域的一些现有结果。

主要从缺陷检测，补丁推荐，以及其他相关的技术应用三个方面做先容。缺陷定位技术关于缺陷定位技术的这些归纳总结主要来自于熊英飞老师（北京大学新体制副教授）的论文。主要方法大类有：基于光谱的缺陷定位，基于突变的缺陷定位，客栈分析等等。好比基于光谱的缺陷定位是基于测试用例，通过的测试用例经由的代码行给予正向分数，失败的测试用例经由的代码路径给予负面分数，类似于光谱的形式将分数较低的一些代码行归类为潜在缺陷行。

这些缺陷定位手段大多关注特定缺陷，在定位某些特定缺陷时准确率显着高于其它缺陷，好比Predicate Switching主要用于检测条件语句中的bug。第二个局限在于误报率较高，以Defect4J数据集测试效果为例，以上方法中准确率最高的是基于光谱的定位，可是TOP1的掷中率也只有37%左右。有研究事情将这些各有所长的缺陷定位手段整合起来一起判断，但误报率仍然高于50%。最重要的一点是，上述的缺陷定位手段不提供补丁信息，这一点在实际应用历程中是很致命的，好比基于光谱的定位会返回多个潜在缺陷行，可是没有明确的修复方案，用户会比力渺茫。

补丁推荐技术关于补丁推荐技术，比力具有代表性的研究是Generate-and-validate approach，这种类型下的研究结果大要思路是基于失败的测试用例，定位到代码上下文，然后通过随机替换代码元素，或基于语义不停实验改变抽象语法树上的结点，并使用测试用例或其它可验证信息去验证修改的效果，直到测试用例或其他验证手段跑通。这些补丁生成的方法主要有三大局限，首先是准确率低，主要体现在Overfitting（过分拟合）问题上，意思是生成的修复片段和现实中工程师实际的修复方式差别，有些修复甚至是面向测试用例的修复而不是面向真实缺陷的修复。左图是某论文中一个Overfitting的例子，“Generate-and-validate”方法将if条件修改为了一个无意义的恒即是true的条件，使得该方法每次宁静地return，这样的修改确实能跑通测试用例，可是对真实的bug是无济于事的。

第二个显着的局限是耗时长，消耗的盘算资源较多，这种修复方法往往是小时级的，而且他是基于编译的，需要不停地测试运行，效率较低。此外，这种方法对测试用例完备性的要求很是高，它既磨练测试的笼罩率，又磨练了测试用例设计的合理性。其它应用技术另有一些缺陷检测或补丁推荐技术，可能大家有所耳闻，特别是Facebook和Google的，我也简朴地先容下。

Simfix和CBCD主要是基于缺陷陈诉的补丁生成，使用代码克隆把缺陷陈诉和补丁迁移到新代码上。Ubisoft的CLEVER首先基于特征做了commit级此外缺陷预测，对风险较大的一些commit做二次检测，二次检测的方法是将缺陷陈诉凭据代码的dependency聚类起来，然后做抽象语法树的节点相似度比力，游戏代码往往有一些相似的缺陷。

Bugram是将代码剖析成token序列，使用Ngram算法来预测泛起某一个token的概率，概率低的token可能是个缺陷点，这种方法今世码庞大度变高或代码词汇数量过大后，效果就急剧下降。Infer，Getafix，Sapfix都是Facebook提出的，做的都很不错。

Sapfix主要是针对移动手机的UI做类似Fuzzing的缺陷检测，Infer主要针对代码的NPE问题做了偏规则的检查，所以准确率较高，Getafix是在Infer的检测效果的基础之上，对工程师修复的补丁做了模式聚类，将常用的NPE修复模式统计生成出来。Tricorder和Findbugs等工具都是比力成熟的代码检测器，开发者可以基于这之上定制自己的检测机制，但比力依赖规则的人工制定。我们为什么提出PRECFIX方法经由调研后，我们发现外部的已有技术方法不能完全解决阿里巴巴面临的挑战和问题，于是我们提出了PRECFIX方法。

我们首先在阿里巴巴数据集中复现了一个基于特征工程的commit级别缺陷风险检测，这个在之前讲Ubisoft的Clever的时候有提过，详细方法是从代码数据集中凭据托管系统Git建设commit父子关系图，使用革新的SZZ方法对commit举行自动打标签，然后抽取出一部门特征如下所示，然后使用Xgboost 或者随机森林对特征和标签举行训练，将模型用于commit风险的检测。特征主要分为规模、代码漫衍、目的、开发者履历以及文件修改五大维度，共14个子特征。以SZZ算法作为标签数据的模型在准确率上有瓶颈。SZZ算法虽然逻辑合理，在公然数据集上有比力好的体现，然而在我们的代码数据集上，准确率不高，人工视察了数百条SZZ算法标注的缺陷commit，其中仅有53%是真实的修复行为。

“噪声点”主要来自以下几种场景：业务型的修复与代码无关，注解日志的改动，测试类的调整，代码气势派头的优化，代码改动自己是用于“debug”的所以message中带有“debug”信息等等。而更进一步，仅有37%的修复型代码改动可以迁移到新的代码上，这也就意味着有些代码改动虽然是真实的修复，可是由于改动量过于庞大，或者只与特定情况，特定上下文相关，没有可借鉴的价值。

通过对标签数据的细致分析，我们认为自动化的标签不满足我们的需求，而且打缺陷标签对打标者的技术要求较高，对海量的代码改动历史打标签也是不现实的。我们开始不盲目寻找和复现方法，而是用心去感受和发现开发者在日常开发历程中的修复行为，我们总结了以下几点：首先，借鉴于SZZ算法，commit message中往往包罗了用户的修复意图，可以依据commit message来过滤出一部门数据。另外我们在调研SZZ算法数据时，发现75%的修复提交都有这样的模式：删除一些缺陷代码,然后新增一些代码，好比修改了一个参数，在diff中即是删除了一行，新增了一行。

还视察到一个细节就是一个修复的操作往往涉及的文件数不凌驾两个，而一些不太规范的commit内里含有大量的文件，纵然内里包罗了修复行为，也会被稀释掉，引入不被接待的噪音。同时我们也调研了在代码评审阶段用户比力体贴的缺陷，如故障点、重构点、代码气势派头、性能问题等等，许多问题都有重复泛起、重复修改的记载。我们萌生了从海量的提交历史中挖掘出重复常见的缺陷，防止开发者再次犯错的想法。

于是我们提出了：这次ICSE收录的论文中形貌的方法,后期会在云效产物中使用，其实思路方法比力直接简练，主要分为三步，首先从代码提交数据中提取“缺陷修复对”，然后将相似的“缺陷修复对”聚类，最后对聚类效果举行模板提取，这个缺陷检测和补丁推荐技术可以用于代码评审，全库离线扫描等等。用户的反馈以及我们人工的审查可以进一步提高模型推荐质量。实现PRECFIX方法的技术细节接下来我们聊一下实现PRECFIX方法的技术细节。首先是“缺陷修复对提取”。

有朋侪可能会有疑问，作甚“缺陷修复对”？“缺陷修复对”如何提取？缺陷修复对提取这得先从几个数字讲起。SZZ算法使用Blame信息去追溯引入缺陷的commit以及缺陷行，我们视察发现，有25%的文件的缺陷行源自多个文件，这就意味着使用blame信息去溯源可能会将一个缺陷追溯到两个源头，而将一个缺陷的代码行一分为二很有可能是没有意义的。通过blame信息去追溯缺陷代码行不够准确，而我们想要的缺陷相关的代码上下文实际上就是这次修复型commit提交前该文件最后一次提交的内容，我们可以直接通过本次提交的文件和对应的diff还原出本次提交前的文件内容。我们发现，大多数的修复行为是以方法为单元的，所以我们提出了以方法为单元的“缺陷修复对”提取方法，即将方法体内的diff chunks（差异文件区块）合并，生成一个缺陷修复对。

固然也可以不以方法体为规模，直接以diff chunk为单元去提取缺陷修复对，这些都各有利弊，如果以diff chunk为单元去提取，那就不需要源代码信息了，直接剖析diff即可。在提取历程中有个小tips就是将缺陷片段和修复片段归一化，好比将空格和换行符去掉，然后比力两者，将相同的缺陷修复对过滤掉，这样能过滤掉一部门代码花样修改。我们发现60%的commit仅包罗了1-2个文件，但也存在小部门的不规范commit包罗了数十个甚至上百个文件。如之前所说，我们认为一次修复行为关联的文件往往在三个以下，为了减小噪声的引入，在提取缺陷修复对的历程中建设过滤机制。

其实这个commit文件数量的限制是准确率和召回率的权衡，在真实实践中我们为了召回率略微放宽了限制，将阈值设为了5。通过SZZ算法标注的代码缺陷47%不够准确。我们沿用了SZZ的使用commit message的数据收罗步骤，所以这个缺陷修复对的提取历程还是会存在大量的噪声难以去除。

我们想到了聚类，将常见的缺陷与补丁聚类起来，总结成模板，一些噪声或没有借鉴意义的缺陷修复会被自然地过滤。缺陷修复对聚类提取完缺陷修复对后，为了只管淘汰噪音，而且我们的目的是提取共性缺陷修复记载，于是接纳了聚类的方法，将相似的缺陷修复对聚类在一起，获得一些共性的缺陷。由于事前无法预测类簇数量，我们没有使用Kmeans聚类算法，接纳了现在比力成熟的基于密度的DBSCAN算法，固然也可以使用pairwise的比力和合并，也就是所有情况都比一遍。

聚类方式上，我们实验过许多种，有单独聚类缺陷片段的，效果不错，可是修复片段的分析成为了难点，因为同样一段缺陷片段有差别的修复方案，很难自动化地分析。我们最后实验了同时聚类缺陷和修复片段，这样聚类的方式可以在匹配上缺陷片段时直接给出修复片段，不用再另外思量如何做修复推荐。直接使用DBSCAN效率较低，以我们的实验数据量来讲，或许需要70个小时。于是，我们在DBSCAN的基础上做了一定的优化，主要有图表上的几种方式。

我们基于MapReduce实现聚类，Mapper阶段做缺陷修复对的预处置惩罚，Reducer阶段跑DBSCAN。第一种优化方式是在Mapper阶段接纳KDTree或者SimHash算法将比力相近的缺陷修复对分发到一个Reducer中做并行聚类，时间性能或许提升了4倍。类簇损失率主要是和基础版的DBSCAN算法相比，或许损失了6%。

大多数的缺陷修复对相互之间是没有任何关联的，而我们使用代码克隆技术比力两个片段又是最耗时的部门，图上的APISEQ即是我们优化“不须要比力”的方法。我们洞察了这批缺陷修复对数据集，发现险些所有的片段都或多或少包罗了方法挪用，没有方法挪用的片段或许率是一些无意义的噪声，所以我们可以在聚类比力的历程中先比力两个片段是否含有相同的API，如果有的话再举行比力，通过这个方法时间性能又提高了四倍。我们也实验了比力新颖的并行DBSCAN算法，速度很是快，可是类簇损失相对较大。

这个数据处置惩罚的历程是定期的离线盘算，频率较低。最终权衡之下，我们选择了耗时相对较短，损失率较小的KDTree或APISEQ+KDTREE的聚类方法。

至于聚类历程中的两个片段的代码克隆比力方式，我们发现两种互补的盘算方式的效果显着优于单个盘算方式，我们的最佳实践是“编辑距离”和“Jaccard”的加权平均，因为“编辑距离”能够捕捉到token（代码元素）的顺序关系，而Jaccard能盘算token重合比例。模版提取与匹配最后是“模版提取”：为了提升用户体验，我们希望将同一类簇的片段聚合起来提取出模板，降低用户的明白成本。如上图所示，同一类簇的两个片段很是相似，我们先递归地使用最宗子序列算法，黄色部门为匹配的内容。

一些不匹配的内容除了左边的片段多了一句以外，其他部门实际上是变量名差别，我们将差别的变量名分析提取出来，存储为“@Para”的花样利便后期匹配。当扫描到新的缺陷片段时，我们基于模板识别出它的变量名，并直接用新的变量名替换补丁模板中的“@Para”参数，然后自动推荐出带有新参数的修复建议。下面来看几个PRECFIX聚类获得的模板。

第一大类是“合理性检查”，修复片段做了长度的判断，合理性检查也包罗了空值检查。第二个类是“API变换”， API的参数发生了改变，增加了Gpu id，第一个参数的泉源也做了修改。

API变换还包罗了方法名的改动，参数的增删改，这是很是常见的类型。另有一个大类是做检察聚类效果之前没想到的，就是“API封装”，工程师往往会把功效独立，经常复用的代码段封装起来，淘汰代码重复度和维护成本，而且工具类会将方法写的比力完善，淘汰开发者在编写时发生的不须要的失误。固然Precfix也不是代码缺陷的特效药，只是提供了一种从代码库中挖掘缺陷的思路。

模板数量和误报率需要连续地跟进和维护。PRECFIX方法已经在阿里巴巴团体内部落地，在内部公然库中扫描出了800多种缺陷类型，3万多个缺陷，并将效果对用户举行了访谈，获得了普遍的好评。后续，该方法也会在“云效”产物中应用，供更多开发者使用。西安创成有限公司，新型信息化技术的提供者和信息化系统支撑业务系统的方案/开发技术提供者。

公司下设：农业信息化与农业物联网部：主要从事农业信息化技术开发、应用、推广及服务，致力于城乡融合、乡村工业振兴、农业信息化技术研究和应用，在智慧农业偏向上，研究新型信息化技术在农业、农村中的应用和推广。信息系统集成部：主要从事新型信息化技术、智能信息化应用、移动互联网技术（APP、小法式、云平台等）等深度信息化的方案、智慧都会、数字城管等信息化的集成、方案咨询等业务。软件技术研究中心：主要从事软件开发技术、公司自研型软件平台、软件工程应用新技术、物联网平台、大数据与AI应用技术、公司未来计划新业务偏向预研、新型ICT人才造就与输出等业务。

接待大家洽谈业务、交流互助！联系方式：联系人：张先生电话：13892807048邮箱：cs_zhanght@163.com网址：www.chuangcheng-software.com关注我司，请扫以下二维码：西安创成有限公司，一个创新并缔造价值的公司，期待您的互助与加盟！。

本文来源：www(Kaiyun)com-www.gzcfjy.com