香港大学 | 通过突变分析暴露库的API误用（ICSE 2019）

原文标题：Exposing Library API Misuses via Mutation Analysis
原文作者：Ming Wen; Yepang Liu; Rongxin Wu; Xuan Xie; Shing-Chi Cheung; Zhendong Su
原文链接：https://ieeexplore.ieee.org/document/8812114
发表会议：ICSE’19
笔记作者：NING@SecQuan
笔记小编：黄诚@SecQuan

1 研究介绍

API 误用可能造成软件崩溃或者是漏洞问题，然而当下随着各种开源项目库的开发，API 的数目也急剧增加，因此针对 API 误用的研究也是逐渐深入。传统的模式挖掘算法的假设过于理想化，因此急需一些新的思路和想法来帮助解决该问题。

本文的核心思想在于，将 API 误用看作相应 API 正常使用的一个变体( mutants ) ，进而通过这些学习变体模式来发现和挖掘 API 误用。

本文的主要工作如下：

• 第一个将突变分析应用到 API 误用检测的研究

• 开发了 MUTAPI 工具，用以检测 Java 库的 API 误用，并且应用了一套新的突变符

• 该工具能够高精度的发现当下 Java API 的误用，并且在 MUBENCH 上表现优于现有方法

2 一些背景知识

在上一篇文章中关于 API 误用的 benchmark 数据集进行了简单的介绍，这里将对该领域核心处理方法进行简单介绍。

解决思路——模式挖掘

API-Misuse 即 API 误用，也就是在代码开发中对一些 API 进行了不合理、不安全、不规范的使用，而这种不规范的使用与规范的代码使用相比，它的出现是相对罕见的，因此最早的一种 API 误用的检测思路便出现了，也就是通过算法去进行模式挖掘，将代码中常见的 API 上下文模式定义为合理、罕见的定义为误用。进而在检测时，获取每个 API 的上下文，观察其是否违反了这些模式，违反则被认为是可疑的，最后进行排序，并作为可能的 bug 报告给程序员。

这种思路看上去是合理的，但是会存在这样一种情况，就是有些 API 本身就是很少使用的，这样的话就使得这个方法很大程度上会导致假阳性偏大，而且如果无法获得大量的代码进行支持，则这种方法便很难取得效果。于是关于外部文档知识的方法出现了，而它的主要假设在于 API 文档本身就是支持 API 使用的手册，因此它应该包含了正确的 API 使用方法，只需要使用自然语言处理技术将其提取，便可以获得有关 API 的编程模式，进一步进行违规检测。初次之外还有很多的一些研究在技术细节的上的变化，但核心还是大致相同。

3 主要方法

本文的核心思路与之前的 整体流程主要有三个阶段：构建变体测试、优先处理 Killing Relations、发现 API 误用模式。

A. Conducting Mutation Testing

这一步主要是构建变体进行测试。首先对每个 API 进行序列化建模，建模中包括 API 涉及的变量、条件等，如表 1 所示。接着在此基础上通过使用一些突变运算符来进行正常 API 的突变，而这些突变运算符也很好想象，例如如果编程时存在 try 却没有 except 则会发生错误，因此删除部分序列便是突变运算符之一，而更多的运算符如表 2 所示。在这种突变的变化上，便可以生成突变体进行后续的测试。

B. Prioritizing Killing Relations

所谓 killing relation 也就是杀戮关系，可以认定为一个使得程序异常、并终止的一个行为关系，这个关系可以定义为一个 k，同时它会包含一些特定信息，主要是它产生时的一些变量信息，包括 m，a，p，t。其中 p 代表 project，也就是被测试的项目，m 代表 mutant 触发 k 时的变体，a 代表 API 也就是触发 k 的 API 位置，t 则是 test suite 也是触发 k 的测试用例。同时需要获取对应的堆栈路径 s。

但这里有个难题就是，如何准确判断这个杀戮关系是突变体满足 API 误用条件造成的，而不是其他原因。

C. Discovering API Misuse Patterns

在上一步的基础上，对于每个不同的堆栈路径 s， MUTAPI 将会计算其目标分数，并检索所有具有相同 s 的杀戮关系 k。进而在这个集合上面拓展到 s 和 突变体 m 的关系。而为了更好的抽取其中的 API 误用关系，MUTAPI 与先前的工作相同，选择使用<violation type， API usage element>的误用对。于是便获得了 API 误用的模式。

4 实验效果

实验主要评估的是 MUTAPI 的有效性，共选取了 16 个满足条件的项目。从以下三个方面进行了实验评估：

RQ1：MUTAPI 能否发现误用模式，对于那些模式具有更好的效果？

MUTAPI 在项目中生成了大量突变体，并在此基础上获取了大量的 killing relation，而在处理堆栈路径跟踪后，每个客户端获得了 65 个唯一的堆栈跟踪。于是在此基础上提炼了近 300 种 API 误用模式。而在此基础上，人工手动检查了前 50 种模式，并且前 10 种实现了 0.90 的精度，前 50 降低到了 0.78，而排名最高的几种主要是：缺少检测程序、缺少调用、缺少异常、错误条件和冗余调用。

RQ2：MUTAPI 能否检测最新 MUBENCH 数据集上的 API 误用？

MUTAPI能够检测出53种实际API滥用中的26种。它实现了0.49的最高召回率。在实际设置中，MUTAPI的性能明显优于所有基线方法。此外研究人员进一步调查了MUTAPI无法检测到某些模式的API滥用实例的原因，并发现了三种主要类型的原因：没有正确使用API，没有突变体覆盖和测试套件不足。

图中涉及到了两种实验设置，一个是不包含任何手工制作的 API 用法，另一种是涉及到手工制作的 API 正确用法。之所以有两种设置，在论文 A systematic evaluation of static api-misuse detectors 中有解释。

RQ3：与传统变异算子相比，本文的变异算子在检测 API 误用模式的效果表现如何？

该实验主要是对比本文方法和传统变异算子的区别，传统 PIT 方法产生的突变体数目是 MUTAPI 的 2.39 倍，而突变分析计算是较为花时间的，MUTAPI 平均需要 9.87 分钟，而 PIT 则需要 20.93 分钟。此外，PIT 按照 RQ1 中的思路，前 50 位中仅能检测到 5 中条件不正确且调用遗漏的真阳性错误。这主要是因为变异符大多为条件和算数运算符，于是无法判断断言错误等，这样证明了本文变异算子的有效性。

5 个人思考

• 本文方法反其道而行之，不是归纳 API 正确用法在进行检测，而是通过突变 API 去产生误用，并归纳其模式进而进行判断，是一个极具想法的思路，能够一定程度上克服频繁项挖掘的算法不足性

• 本文的变异依赖于源代码的全面性，需要其有着正确的 API 用法，如果代码中不存在该代码正确的使用，自然无法获得误用情况，也就无法获取任何误用模式，从而无法检测

• 突变覆盖率问题，如果在算子的变异当中没有产生错误，那该种错误模式也无法被学习，本文也举了例子，说到其变异算子会从源代码中寻找元素进行变异，如果未出现对应可能触发误用的元素，自然也就不会被覆盖到。

• 测试套件问题，变异位置在测试套件中需要触发 killing relation，如果没有触发也就不会进入后期的分析环节，但这个并不代表其不存在误用的情况