2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，帮助测试从业者了解最前沿行业趋势，及最新的行业实践。

会上，饿了么测试开发专家邱化峰做《人工智能在Bug定位中的应用》主题演讲。邱化峰指出，“企业想获得人工智能带来的便利，首先要制订相对应的标准，如果没有这个标准，按照固定的算法，则很难实现。”

以下为邱化峰演讲实录：

现场视频（上）

今天我讲的是人工智能在Bug应用中的定位，讲这个话题之前，我想先做一下统计，大家用java管理Bug的人员有多少？在修复Bug之后，在代码里面，想关联Bug是什么样的同学请举手。人工智能定位首先需要有一个数据的基础，这个数据的来源是什么样的？测试通过java提交Bug，我们有Bug的描述，Bug的相关信息，以及Bug的重现步骤，会直接提给开发，开发根据这些步骤去执行，看Bug是不是可重现的。如果是可重现的，会要求开发把相关的问题进行关联，关联之后作为Bug分析的一个前提，不需要在人工去标注什么样的样本，因为把Bug描述的相关信息放上之后，我们就可以通过自然语言或者是人工的处理方式，提取含有Bug相关的字段，比如出现的异常是什么，错误是什么，问题是什么样的。有了这个基础之后，不需要人去做标注，就可以拿到一些样本。还有一个是学术界要做的，首先，有些人专门维护了所有关于java的Bug，这些Bug在修复里时会生成一些数据，告诉你哪个方法在第几层，哪个方法哪一行出现了什么错误。如果想使用人工智能带来的便利，首先要制订一些相对应的标准，如果没有这个标准，很难按照固定的算法来得到想要得到的东西。讲完了这些前提，我主要讲三部分，第一是工具介绍，第二是Bug定位的原理和方法，第三，使用这些工具之后应用从哪些方面做具体的落地。

工具分了八种，这个PPT是之前做的，最近一个月又出来一个新的Bug定位的技术，就是基于行为的Bug定位技术。前面这八种定位技术都是以能拿到相关的样本来做对应的处理，而且这些东西是通过提取测试用例，编译测试。这大部分是基于单元测试做的，但是基于行为的已经突破了在单元测试的层面去获取Bug的样本，通过基于链路去分析是什么样的情况。第一个是程序频谱，就是我跑多少测试用例，成功的测试用例覆盖了哪些行，失败的覆盖哪些行。我们计算失败的测试用例占的行，我们做一个排名，就可以拿到这一行代码出现BUG的概率是多少。然后是基于变体，程序频谱的基础上做了一个改良，变体现在应用的，最实用的一个是衡量测试用例的有效性很重要的一个手段，我写了那么多测试用例，这些测试用例是不是真的有效，我可以去变体来做衡量。基于变体会生成两个，有一个变异分数，分数越高的时候，单元的测试用例的质量就比较高。程序切片就是通过程序切片或者场景，生成程序用例的方式，程序切片也可以用于Bug定位，然后是堆栈跟踪，APP端有用监控的，类似于接了监控系统的同学举一下手。安卓系统底下的应用，比较多的只发安卓的，不发iOS的同学有多少？大部分都是既发安卓又发iOS。基于堆栈追踪，堆栈话题要讲到好多，比如日志，log，线上的这些东西怎么去拿。堆栈追踪，不仅仅应用于服务端的Bug的定位，也可以应用于C端的Bug定位，比如界面突然卡掉了，或者突然卡死，我拿到这些对应的堆栈信息，也可以直接来进行Bug的定位，以及做Bug的预测。第五是上下文的切换，这个就不讲了。第六是信息检索，通过一些词频，或者去算出现概率比较多的，大家知道热点覆盖概念的同学请举一下手，你能说一下吗？

听众：有个热点图，看哪边用户点击更多，哪边点击更少。

    

邱化峰：我们是变向的热点覆盖的方法，映射到修改的方法是最多的。最后是机器学习。如果我们需要知道怎么去定位Bug，通过人工智能的方式，首先要定义各种指标，这些指标就决定了在定位Bug中的准确率有多高。基于java这里列了7个，首先看一下，代码的有效行数，圈复杂度，包括是否符合javadoc的规范，为什么要把这个作为参考指标？阿里巴巴推出了java编写规范，不是说凭空无中生有的，是基于扫描了阿里所有的代码仓库包括历史记录总结出来的，比如空格应该空几行。我们有人工智能定位的工具，通过统计含有Bug的类型做了一个统计，Bug产生因素最多的就是随意的命名变量名，这是作为了定位Bug中得出来的最主要的参考指标。Bug的产生大部分是由人的理解或者认知在一定范围之内造成错误的使用的某个变量名，包括函数。代码编写规范，第一代是函数式的，第二代是面向对象的，面向对象的是不是万能的，我们面向对象去写的时候，是不是易于维护的和易于理解的。最主要的有一个是扇入和👕扇出，我去做Bug定位的时候，如果这个方法被多次引用，也会增加Bug出现的概率。然后是包的设计质量，之前是单体的应用，现在讲微服务，又在讲中台，这些是相当于在包的基础上做了一些变革，之前我们是单体的，把它拆成微服务之后应该怎么做，当把微服务单独抽出来做中台，最主要的改变就是Jar包的结构和这些东西也在随之不断的发生变化。第四个，用来分析Jar包的升级质量，变量的个数和参数的个数，这也是在Bug中影响Bug定位的主要指标，大家见过的，能知道测试过程中发现变量数最多的同学，有没有说发现使用了多少参数，或者一个函数能支持多少个函数，有知道的同学吗？参数的个数，语言多多少少有差异，我在函数传参的时候，函数的参数名和变量最多只允许有256个，超过256个，程序就跑不起来了。变量的个数和参数也是作为Bug定位的指标。再看最后一个，运算符的个数，大家也知道功能测试和做中间件测试的，基本上是不一样的，不一样在哪儿？基于业务的可能是业务场景的，逻辑，或者是业务场景相对来说比较固定，逻辑的单一化比较好一点，但是作为一个中间件，会考虑很多的不确定因素。当我们去考虑这些不决定因素的时候，其实是变向增加了运算符的操作。