开云手机app(中国)官方网站IOS/安卓通用版/手机APP下载

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

本文来源：开云官方网站-www.xiankelailai.com