原文：https://dl.acm.org/doi/10.1145/3715755

这篇也很有意思，但是把工作丢给LLM的思路有点暴力

不管怎么说，有用就行吧

把bug单挂在Activity转移图下面挺有意思的

基于Bug报告知识库RAG的GUI测试框架

主要关注崩溃类bug

动机

image.png

人类从历史中学到的唯一教训，就是人类无法从历史中学到任何教训。

  • 现有的方法主要关注在分析App本身的结构上，未能聚焦于聚焦触发Bug本身的路径，导致bug检测效率低下，性能提升空间大。
  • 一些方法利用KG在相同的APP上通过分析历史测试报告来生成新的测试用例。但KG的构建effort过大，且只能用在一个APP上。
  • 开源平台上有大量Bug报告，之前没有工作有效利用过。
  • 相似APP/业务流程更有可能包含相似的Bug，可以利用历史Bug报告检测流程相似的APP上是否存在相同的类型的bug。

挑战

  1. 如何利用历史bug报告构建高质量的、结构化的知识库？
  2. 如何从知识库中检索相关bug报告？
  3. 如何利用其他APP的bug报告在AUT上生成探索路径？

方法

主要由三个部分组成

  1. Bug知识库构建
  2. 相似Bug检索
  3. Bug信息增强的探索路径生成

image.png

Bug知识库构建

基于开源软件的知识库构建

image.png

信息获取

APP文本描述信息获取：扫Readme，提取APP名字和介绍

ATG获取：rule-based方法和静态分析提取Activity之间的转移

Bug描述与复现步骤获取

知识库构建

APP描述生成：基于APP描述信息和ATG，通过LLM生成格式统一的APP描述

image.png

Bug报告结构化：利用BERT对bug的第一步和Activity名字做embedding，计算余弦相似度，实现bug与Activity的映射，把bug挂在ATG的节点上。

这个把RAG信息挂在Activity下的方法很有意思，可以借鉴。

相似Bug检索

相似APP检索

基于APP文本描述信息和结构化信息的两阶段检索方法

image.png

  1. 基于Embedding的检索：通过LLM生成APP描述后，利用Embedding模型向量化，与知识库中的APP进行余弦相似度比对
  2. 基于Cross-Encoder的重排

向量化的APP描述丢失了ATG信息，后续的ATG相似性可能没有保证

基于LLM的AUT Cognitive Map构建

通过LLM将KB中APP的ATG上的Bug与AUT的ATG节点匹配起来

image.png

输入：

  1. KB APP的名字、ATG和挂在每个Activity下面的Bug
  2. AUT的名字和ATG

要求输出：

KB APP中的Bug与AUT中Activity的对应关系

image.png

Bug信息增强的测试路径生成

GUI页面标注

对于当前页面，提取UI树，在GUI上用红框标出所有可交互控件，并使用数字ID标记。

局部路径规划

2个挑战：

  1. bug复现步骤来自开源社区，质量可能不高

    这里能不能做结构化？有可能是太困难？

  2. AUT和KB App的操作序列差异可能很大

还是丢给LLM来做，给MLLM提供测试上下文信息的同时，要求MLLM生成等价的操作来复现bug

全局路径规划

通过记忆机制减少重复的探索

  • 记录已经探索过的Activity
  • 完成一个bug的探索后，检查当前Activity是否还有剩余的没有测试过的bug。如果有，则继续按照bug报告探索，否则遍历ATG

image.png

其他App的bug复现流程如果在AUT根本找不到等价操作怎么办？

实验

RQ

RQ1：Bug检测性能和覆盖率

RQ2：消融实验

RQ3：实用性评估

数据集

  1. Themis，从Github上获取的20个开源App，包含34个bug

    最后一次更新基本上都在2020年左右，有些已经不能正常运行，数量也比较少

  2. 从F-Droid的每个category上爬取20个最流行的App，保留在2024年5月以后有更新的App，保留不持续崩溃，能够在所有baseline上运行，能够正常提取UI树，包含崩溃bug且能手动复现，没有在知识库中的App，最终获得51个App，包含87个bug。

结果

Bug检测性能和覆盖率

image.png

image.png

BugHunter前10分钟是在检索相似Bug

相似Bug的例子

image.png

分析：为什么BugHunter有用？

  1. BugHunter能够利用上常见的bug模式，比如输入验证错误
  2. BugHunter能够有效检测app设置中存在的bug

消融实验

image.png

分析：

  1. w/o 相似bug检索的情况下，直接从KB中随机选择bug报告，效果不佳，说明无关bug报告没有意义
  2. w/o bug报告增强的路径生成相当于没有做RAG，可以视为一个基线

image.png

分析：

  1. w/o 重排的性能下降最多。是否重排对检索到的bug列表没有影响，重拍后更相关的bug排在前面，在有限时间内更容易发现bug。
  2. w/o 全局路径规划同理
  3. w/o app描述生成变体中，直接使用爬取的非结构化信息来做检索，性能有下降，说明统一结构的APP描述用于检索有重要意义。

实用性评估

在237个app的数据集上，BugHunter从88个app中检测到了93个崩溃bug，其中45个app上的49个bug此前从未被发现。

最佳Baseline（GPTDroid）仅检测到了其中7个，且均为BugHunter的子集。

49个新Bug均已提交，其中42个已经被修复或确认，没有bug被拒绝。

思考&启发

  • 应该是首个将bug报告利用RAG的思路引入到自动化测试中的，并且提供了一个方法论
  • 方法中把bug在ATG上与Activity关联起来的方法很有意思，实现了bug与应用内状态的精确匹配，值得借鉴
  • 图已经出来了，能不能在检索的时候直接基于图结构做检索，而不是转成文字描述之后再检索？
    • 转成文字模态以后结构信息丢失了
  • 同样也在GUI上添加了组件标记，应该是一个比较常用且有效的手段。
  • 组会上分享这篇文章的时候，也有个学姐提到说这个工作里面的一些部分使用LLM似乎不是很必要