Make LLM a Testing Expert: Bringing Human-like Interaction to Mobile GUI Testing via Functionality-aware Decisions

Zhe Liu1,2 ,Chunyang Chen3 , Junjie Wang1,2,∗ , Mengzhuo Chen1,2 , Boyu Wu2,4 , Xing Che1,2 , Dandan Wang1,2 , Qing Wang1,2,5,∗

1State Key Laboratory of Intelligent Game, Beijing, China Institute of Software Chinese Academy of Sciences, Beijing, China;

2University of Chinese Academy of Sciences, Beijing, China; ∗Corresponding author;

3Technical University of Munich, Munich, Germany; 4DiDi Global Inc;

5Science & Technology on Integrated Information System Laboratory

引用

Liu Z, Chen C, Wang J, et al. Make LLM a testing expert: Bringing human-like interaction to mobile GUI testing via functionality-aware decisions[C]//Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 2024: 1-13.

论文：https://dl.acm.org/doi/abs/10.1145/3597503.3639180

仓库： https://github.com/franklinbill/GPTDroid

摘要

自动化图形用户界面（GUI）测试在确保应用质量方面起着至关重要的作用，特别是现在移动应用已成为我们日常生活的一部分。尽管基于深度学习的技术在自动化GUI测试中因其能够生成类似人类的交互而越来越受欢迎，但它们仍存在一些局限性，例如测试覆盖率低、泛化能力不足和过度依赖训练数据。受到大型语言模型（LLMs），如ChatGPT在自然语言理解和问题解答方面的启发，我们将移动GUI测试问题形式化为一个问答任务。我们提出了GPTDroid，通过传递 GUI 页面信息，让LLM与移动应用交互以引出测试脚本，并执行它们以继续传递反馈给 LLM，进行迭代过程。在这个框架中，我们还引入了一个功能感知的记忆提示机制，该机制使 LLM 能够保留整个过程的测试知识，并进行长期的、基于功能的推理来指导测试。我们在 Google Play 的 93 个应用上进行了评估，并证明其在活动（Activity）覆盖率上比最佳基线提高了 32%，在更快的速度下检测多到了31%的漏洞。此外，GPTDroid在Google Play上识别了53个新漏洞，其中35个已被确认并修复。

1引言

近年来，移动应用已成为我们日常生活中不可或缺的一部分，可以从像谷歌商店和苹果应用商店下载数百万应用。随着应用在日常生活中的重要性日益增加，对应用开发者来说，确保其具有高质量并且期望的运行效果变得越来越重要。为避免耗时且劳动密集的手动测试，自动化图形用户界面（GUI）测试被广泛用于移动应用的质量保证，即通过执行滚动、点击等不同动作来动态探索移动应用，以验证应用功能。

不幸的是，现有的GUI测试工具，如基于概率或模型的工具，因测试覆盖率低而受到挑战，这意味着它们可能会错过重要的漏洞和问题。这是由于现代移动应用的复杂和动态性质，这些应用可能有成百上千个不同的屏幕，每个屏幕都有其独特的交互集和可能的用户操作和逻辑。此外，这些方法生成的测试输入与真实用户的交互轨迹显著不同，导致测试覆盖率低。为了解决这些限制，越来越多的人对使用深度学习（DL）和强化学习（RL）技术进行自动化移动GUI测试产生了兴趣。通过学习人类测试者的行为，这些方法旨在生成类似人类的动作和互动，可以用来更彻底、更有效地测试应用的GUI。这些方法的基本思想是，测试算法执行的动作越接近人类用户的动作，测试就会越全面和有效。

然而，这些基于DL或RL的GUI测试方法仍然存在一些局限性。首先，学习算法需要大量数据，这些数据很难从真实世界用户的互动中收集。其次，学习算法旨在从训练数据中学习和预测，因此它们可能无法很好地推广到新的、未见过的情况，因为应用程序在不断发展和更新。最后，移动应用可能是不确定的，这意味着一个动作的结果可能每次执行时都不同（例如，从列表中点击“删除”按钮，如果是最后一个内容，则会生成一个空列表，此时删除按钮不再起作用），这使得RL算法难以学习并做出准确的预测。因此，需要另一种更有效的方法来生成类似人类的动作，以彻底测试移动应用。

大型语言模型（LLMs），如 GPT-3/4，已经成为自然语言理解和问答的有力工具。LLM的最新进展引发了各种研究，探索这些模型在软件开发任务中的应用。来自OpenAI的ChatGPT具有数十亿的参数，经过大量包括测试脚本和漏洞报告在内的数据集训练。其在多个领域和主题上的卓越表现展示了LLM理解人类知识和作为知识渊博的专家与人类互动的能力。受到ChatGPT的启发，我们将GUI测试问题构想为一个问答（Q&A）任务，即让LLM扮演人类测试者的角色来测试目标应用。

我们提出了GPTDroid用于自动化GUI测试，该系统通过将GUI页面信息传递给LLM以引出测试脚本并执行它们，以持续传递应用反馈给LLM，迭代整个过程。为了将应用GUI的视觉信息转化为相应的自然语言描述，我们首先通过反编译目标应用和查看层次结构文件来提取应用和GUI页面的语义信息，并设计语言模式来将信息编码为LLM的提示。然后，我们利用少数示例学习，通过提供输出模板的示例来帮助LLM生成所需的执行命令来执行应用。

然而，在交互式问答GUI测试过程中存在两个主要挑战。第一个是局部困境。与主要针对确定的软件进行程序修复或单元测试生成不同，GPTDroid将GUI测试定义为多轮任务，而LLM面对的是不断变化的GUI页面，即LLM与移动应用之间的互动，以探索应用的各种页面。在互动过程中，LLM很难清晰且准确地记住历史上的探索，尤其是那些很久以前发生的。因此，LLM可能只依赖最近的互动信息来做出决策，而忽略全局视角，这可能使探索陷入局部困境，并阻碍其实现更高的覆盖率。第二个是低层次困境。LLM被输入描述性的GUI信息后，很容易更多地关注低层次的语义，如小部件或活动，而较少关注高层次的语义，即通过小部件/活动的操作序列实现的功能。然而，移动应用的功能方面对测试者和用户来说非常重要，长期以来一直是现有技术的障碍。

为了克服这些挑战，在GPTDroid中，我们开发了一个功能感知的记忆机制。它构建了一个测试序列记忆器，用于记录所有的互动测试信息，包括探索的活动和小部件。它还在迭代过程中查询LLM关于测试的功能级进展，例如，正在测试哪个功能，以使LLM能够进行明确的推理。然后，这些信息被编码进一个功能感知的记忆提示中，并输入到LLM中，使LLM能够决定探索应用功能的有意义的操作序列，并进行全局探索以覆盖未探索的区域。

为了评估GPTDroid的有效性，我们在Google Play上的93个热门Android应用中进行了实验，发现了143个漏洞。与10个常用且最先进的基线相比，GPTDroid在活动覆盖率上可以实现超过32%的提升，在代码覆盖率上可以实现超过20%的提升，达到75%的活动覆盖率和66%的代码覆盖率。由于GPTDroid可以覆盖更多活动，该方法可以以更快的速度检测到比最佳基线多31%的漏洞。除了我们的GPTDroid的准确性外，我们还通过检测Google Play上真实应用中未见的崩溃漏洞来评估我们的GPTDroid的实用性。在223个应用中，我们发现了53个崩溃漏洞，其中35个已被开发者确认并修复，其余的仍在等待中。为了揭示我们方法表现出色的背后原因，我们进一步定性地调查实验结果，并总结了包括通过长有意义的测试轨迹进行功能感知探索、功能感知优先级、有效文本输入和复合动作（function-aware exploration through long meaningful testing trace,function-aware prioritization, valid text input and compound action）等4个发现。

本文的贡献如下：

2 技术介绍

我们将GUI测试建模为一个问答（Q&A）问题，即要求LLM扮演人类测试者的角色，并使LLM与正在测试的应用之间进行交互。为了实现这一点，我们提出了GPTDroid，如图2所示，包含嵌套循环。

在外层循环中，它提取当前GUI页面的上下文信息，将其编码成LLM的提示问题，将LLM的反馈答案解码成可操作的脚本以执行应用，并迭代整个过程。具体来说，在每次测试的迭代中，GPTDroid首先获取移动应用的视图层次文件并提取GUI上下文，包括应用信息、当前GUI页面的信息以及页面中每个小部件的详细信息。然后，我们设计语言模式来生成作为LLM输入的GUI提示。我们利用少数示例学习的思想，通过提供示例作为参考，使LLM的输出符合我们的预期标准，这些标准可以直接在应用中执行。

在内层循环中，它构建一个测试序列记忆器来记录所有详细的交互测试信息，例如，探索的活动和小部件。在此过程中，记忆器还存储测试的功能级进度，例如，正在测试哪个功能，目的是使LLM能够自行进行明确的推理。我们还设计语言模式将信息编码进功能感知的记忆提示中，以赋予LLM保留整个测试知识和进行长期推理的能力。外层循环和内层循环的提示将一起输入LLM以查询下一个操作。

2.1 GUI上下文提取

尽管LLM在各种任务上表现出色，其性能显著受到输入质量的影响，即输入是否能准确描述所询问的内容。在这个交互式移动GUI测试场景中，我们需要准确描述当前正在测试的GUI页面，以及从更微观的角度描述其包含的小部件信息，以及从更宏观的角度描述应用信息。本节将描述将提取哪些信息，而2.2节将描述我们如何组织信息以使LLM更好地理解。GUI上下文涉及应用的信息、当前正在测试的GUI页面以及页面上的所有小部件。应用信息是从AndroidManifest.xml文件中提取的，而其他两种类型的信息是从视图层次文件中提取的，该文件可以通过UIAutomator获取。表1展示了它们的汇总视图。

应用信息提供了正在测试的应用的宏观层面的语义，有助于LLM获得关于应用功能的一般性了解。提取的信息包括应用的名称和其所有活动的名称。

页面GUI信息提供了交互过程中当前页面的语义，有助于LLM捕获当前快照。我们提取页面的活动名称，由“文本”字段或“资源ID”字段表示的所有小部件（按顺序第一个非空的），以及页面的小部件位置。对于位置，受屏幕阅读器的启发，我们首先从上到下、从左到右获取每个小部件的坐标，页面中部以下的小部件标记为下方，其余标记为上方。

小部件信息表示GUI页面的微观层面的语义，即其所有小部件的固有含义，这有助于LLM提供与这些小部件相关的可操作步骤。提取的信息包括“文本”、“提示文本”和“资源ID”字段（按顺序第一个非空的）、“类”字段和“可点击”字段。为了避免小部件的空文本字段，我们还从附近的小部件中提取信息，以提供更全面的视角，这包括父节点小部件和兄弟节点小部件的“文本”。

2.2 GUI提示与执行命令生成

利用提取的信息，我们设计语言模式来生成输入LLM的提示。首先对信息进行预处理，以便进行后续设计。我们根据应用开发中的命名惯例，使用下划线和驼峰命名法对属性进行分词。

2.2.1 GUI提示的语言模式

为了设计这些模式，我们要求五名注释者按照常规提示模板编写提示句，并询问LLM生成操作步骤。然后我们检查推荐操作在整个测试过程中的合理性。有了提示句之后，五名注释者进行卡片排序和讨论，以得出语言模式。如表2所示，这一过程得出了与表1中的三种信息子类型和两种操作与反馈模式相对应的6种语言模式。

与GUI上下文相关的模式（表2-Id 1,2,3）我们设计了三种模式来分别描述当前正在测试的GUI页面的概览，分别对应于表1中的应用信息、页面GUI信息和小部件信息。

与操作和反馈问题相关的模式（表2-Id 4,5,6）我们还设计了模式来描述操作和反馈问题。对于操作问题，我们询问LLM需要什么操作。我们还在提示中提供输出模板，以便LLM生成用于测试应用的期望执行命令，详细信息在2.2.3节中。注意，我们将查询一般动作（例如，点击）和文本输入（例如，输入特定文本）的模式分别用模式ID 4和5来分开，以使生成的命令能更好地与GUI页面中的小部件匹配。对于反馈问题，在决定之前的操作不适用后，我们通知LLM当前页面上没有这样的小部件，并让它重试。

2.2.2 提示生成规则

由于设计的模式从不同的视角描述信息，我们结合不同视角的模式并生成如表2所示的提示规则。我们分别为开始测试、常规询问和发生错误时获取反馈设计了三种提示。注意，由于LLM的鲁棒性，提示句不需要完全遵循语法规则。

测试提示是用于通知LLM当前状态并查询下一步操作的最常用提示。具体来说，我们告诉LLM GUI上下文，即当前GUI页面的信息和详细的小部件信息；然后询问LLM需要哪种操作。

反馈提示用于通知LLM发生错误并重新查询下一步操作。具体来说，我们首先告诉LLM其生成的操作与页面上的小部件不符；重新提供页面的详细小部件信息，并让LLM再次推荐操作。

除了上述两种提示外，我们还额外设计了启动提示来开始测试应用，且只使用一次。与测试提示不同，它为LLM提供包括所有活动的应用信息，以获得全局概览。

2.2.3 执行命令生成

在输入生成的提示后，LLM将输出操作的自然语言句子。考虑到测试操作可以用不同的方式和不同的词语表达，将自然语言测试操作映射到应用程序执行中是一项挑战。因此，我们利用上下文学习的思想，为LLM提供输出模板，包括可用的操作和操作原语，这些可以直接映射到执行应用的指令中。

可用操作。我们确定了移动应用中五种常用的标准操作，包括点击、双击、长按、滚动和输入。尽管还有其他的定制操作，如自定义手势，但它们不常见，我们将它们留作未来的工作。

输出模板。我们为上述操作设计了不同的操作原语，以表示小部件和执行命令。上述五种操作可以分为两大类，即动作（前四种操作）和输入。对于动作类别，我们将其格式化为<Operation>[点击 / 双击 / 长按 / 滚动] + <Widget name>。对于输入类别，GUI页面通常涉及用于输入特定值的文本字段小部件和后续操作（通常用于提交文本输入）。我们将其格式化为<Widget name> + <Input content>，紧跟着<Operation> + <Widget name>。表4提供了LLM对这两类的一个示例答案。

2.3 功能感知记忆提示

通过前两节的上下文提取、GUI提示和执行命令生成，GPTDroid已能够进行自动化GUI测试。本节提出功能感知记忆提示，这进一步提高了方法在迭代测试过程中保留知识的能力，并理解移动应用的功能方面，以生成能够从全局视角指导操作的功能感知操作。

为实现此目标，我们构建了一个测试序列记忆器（第2.3.2节）来记录所有详细的测试信息。我们还会在每个迭代测试步骤中查询LLM关于测试的功能级进展（第2.3.1节），并将其存储到记忆器中。然后，我们设计语言模式将信息编码进功能感知记忆提示（第2.3.3节），并与前一节的提示一起查询LLM。

2.3.1 功能级过程

由于功能对应用用户的重要性，我们希望我们的自动化GUI测试能从功能的视角进行探索。因此，我们需要使LLM了解当前正在测试的功能是什么，这是从已探索的活动和小部件中派生出来的。具体来说，我们设计了一个提示，询问LLM当前正在测试的功能是什么，以及是否已经完成（第2.3.3节）。LLM将向我们提供功能级进展，格式为<Function name> + <Status>，其中“YES”表示已完成对特定功能的测试。

为了促使LLM做出合理的功能级决策，我们还在提示中为LLM提供应用的功能列表。这些信息首先从应用描述文件和活动名称中提取，作为初始种子，并将在迭代测试过程中不断让LLM输出精炼的信息。

2.3.2 测试序列记忆器

我们设计了一个测试序列记忆器来保留测试记录，包括已测试的功能集（第2.3.1节中）、活动的测试路径、带页面访问次数的已测试活动集、当前页面的已测试小部件集及其访问次数。

具体来说，在迭代过程中，当进行某个操作时，我们可以获得功能的状态（<Function name>+<Status>）、小部件的操作（<Operation>+<Widget name>）以及活动的测试路径（<Activity1>+<Operation>+<Activity2>）。然后相应地更新操作记忆器。通过在操作记忆器中查找具有“text”字段和“resource-id”字段的相同小部件，更新小部件的访问次数。通过在记忆器中查找具有“ActivityName”字段的相同活动，更新活动的访问次数。

2.3.3 功能感知记忆提示

基于测试序列记忆器中的信息，我们进一步构建功能感知记忆提示，以帮助LLM在推荐下一步操作时关注功能。这包括三个部分：已探索的功能、已覆盖的活动和最近测试的操作，并且在每次迭代中都会参考测试序列记忆器以获取最新信息。我们遵循第2.2节中的同样程序来推导这些提示模式。提示的详细内容和示例显示在表3中。

与已探索功能相关的模式（表3-Id 1）。这描述了哪些功能已被探索、探索的次数以及是否已完成功能的测试。由于上一节中的GUI提示仅展示当前GUI页面的小部件和活动，它无法提供由小部件/活动的操作序列完成的功能的高层视角。因此，这个提示可以提醒LLM关于应用的功能方面，并帮助LLM决定探索应用功能的有意义的操作序列。具体而言，GPTDroid从测试序列记忆器中提取已测试的功能，包括功能页面的访问次数和功能的测试状态。

与已覆盖活动相关的模式（表3-Id 2）。这描述了测试过程中已覆盖活动的序列。由于移动应用的基本组成部分是活动，这些活动记录在AndroidManifest.xml文件中，此提示旨在提供测试历史的活动视角，使LLM更好地捕获已测试的功能并覆盖更多未探索的区域。具体而言，我们合并相邻的相同活动和活动序列，并相应地更新访问次数。

与最近测试操作相关的模式（表3-Id 3）。这标示了最新测试页面及其包含的所有小部件的详细访问状态，以及离开页面的操作。这些信息是最新的，细粒度的测试记录，可以帮助LLM捕获测试进展的最新状态，并就探索某一功能做出明智的决策。具体而言，GPTDroid从测试序列记忆器中提取每个GUI页面上测试过的小部件及其访问次数。对于当前测试页面，我们将选择最近k步的操作页面及相应的操作。对于每个页面，我们提供LLM当前页面的活动名称和访问页面时每个小部件的访问次数。我们基于经验将k设为5。

与功能询问相关的模式（表3-Id 4）。我们询问LLM当前正在测试的功能，并在提示中提供输出模板，以便LLM生成功能名称及其状态，详见2.3.1节。

提示生成规则。我们结合以上三种模式，为LLM提供不同视角的测试信息的功能方面，并生成如表3所示的提示规则。我们提供了GUI上下文提示和记忆提示如何工作以实现应用测试的示例。

2.4 实现

GPTDroid被实现为一个完全自动化的GUI应用测试工具，使用或扩展了以下工具：VirtualBox [9] 和 Python库pyvbox [7] 用于运行和控制Android-x86操作系统，Android UIAutomator [63] 用于提取视图层次文件，以及Android Debug Bridge (ADB) [1] 用于与测试中的应用进行交互（第2.1节）。对于LLM（第2.2节），我们使用了OpenAI网站上发布的预训练的ChatGPT模型，基本模型是gpt-3.5-turbo模型。

3 实验和结果

为了验证GPTDroid的性能，我们通过考察活动和代码覆盖率（RQ1）以及检测到的漏洞数量（RQ2）来评估它。我们还展示了对GPTDroid中每个模块的消融研究（RQ3）。需要注意的是，本节利用应用仓库中先前检测到的漏洞来展示GPTDroid的有效性，下一节将评估GPTDroid在检测新漏洞方面的实用性。

3.1 实验设置

实验数据集来自两个来源。第一个来源是Themis基准测试中的应用[59]，包含GitHub上的20个开源应用和34个漏洞。考虑到基准测试中应用的数量较少，我们按照相似的程序收集了第二个数据集。

具体来说，我们从Google Play[4]的每个类别中爬取了50个最受欢迎的应用，并保留了至少在2022年5月后更新过一次的应用，共得到12个Google Play类别中的407个应用。然后，我们使用10个常用且最先进的自动化GUI测试工具（详见3.2节）依次运行这些应用，以确保它们能正常工作。接下来，我们根据以下标准过滤掉无法使用的应用：（1）它们会在模拟器上不断崩溃。（2）一个或多个工具无法在其上运行。（3）注册和登录功能无法通过脚本跳过。（4）它们在GitHub上没有问题记录或拉取请求。

共有73个应用（含109个漏洞）留用于此有效性评估。注意，与基准一样，所有漏洞均为崩溃漏洞。具体来说，对于每个应用，我们选择开发者确认的漏洞版本（合并的GitHub拉取请求）作为我们的实验数据。

注意，有101个应用被筛选，但可以成功运行我们提出的方法。我们将它们应用于2.2.1节的手动提示生成。并且这确保了方法设计和评估中的应用没有重叠。

我们采用活动覆盖率、代码覆盖率和检测到的漏洞数量作为指标，这些是评估GUI测试的广泛使用的指标。我们还展示了同样常用的指标中的覆盖活动和小部件的数量，这些指标显示在表6中。我们将Android应用的AndroidManifest.xml文件中定义的活动视为活动的完整集合。

在测试过程中，我们收集与操作交互的GUI页面的唯一活动名称和小部件ID，并将它们视为活动数量和小部件数量。

3.2 基线

为了展示GPTDroid的优势，我们将其与10种常用且最先进的自动化测试技术进行比较。我们将它们大致分为基于随机/规则、基于模型和基于学习的方法，以便于理解。对于基于随机/规则的方法，我们使用Monkey、Droidbot、TimeMachine。对于基于模型的方法，我们使用WCTester、Stoat、Ape、Fastbot、ComboDroid。对于基于学习的方法，我们使用Humanoid和Q-testing。

为了进行更全面的比较，我们还包括了5个其他基线，其中原始提出的技术旨在增强自动化GUI测试，并可以通过与上述自动化测试工具集成来使用。具体来说，QTypist用于生成有效的文本输入，以增强自动化测试工具的覆盖率。Toller是一个包含对Android操作系统的基础设施增强的工具。Vet用于通过识别UI跟踪中的模式来识别探索陷阱，从而优化探索序列。我们使用它们原始论文的实验设置导出以下5个基线，即QTypist与Droidbot和Ape集成（Droidbot+QT, Ape+QT），Toller与Stoat集成（Stoat+TO），Vet与WCTester和Ape集成（WCTester+VE, Ape+VE）。

3.3 结果与分析

3.3.1 覆盖性能（RQ1）

表6显示了GPTDroid及基线的已覆盖小部件数量、已覆盖活动数量以及平均活动覆盖率。我们可以看到，GPTDroid覆盖的小部件和活动远多于基线，平均活动覆盖率达到75%，平均代码覆盖率达到66%，横跨93个应用。即使与最好的基线（Ape与QTypist）相比，活动覆盖率也高出32%（0.75 vs. 0.57）。同时，在Themis基准测试和Google Play数据集上，它比最好的基线高出28%（0.69 vs. 0.54）和33%（0.77 vs. 0.58）。这表明GPTDroid在覆盖更多活动和代码方面的有效性，从而为应用质量带来更高的信心，并可能揭示更多漏洞。

图3还展示了不同时间点的平均活动覆盖率。我们可以看到，在每个时间点，GPTDroid的活动覆盖率都高于基线，且在大约24分钟内实现了高覆盖率。这再次表明GPTDroid在用较少的时间覆盖更多活动方面的有效性和效率，这在考虑测试预算时非常有价值。在基线中，基于模型和基于学习的方法表现相对较高。然而，基于模型的方法无法捕获GUI的语义信息，探索也无法很好地理解应用的内在业务逻辑。基于学习的方法只使用少量上下文信息指导探索，并没有使模型考虑应用的功能的机制。

我们进一步分析了未覆盖案例的潜在原因。首先，一些小部件或输入没有有意义的“文本”或“资源ID”，这阻碍了方法有效理解GUI页面。其次，一些应用需要特定操作，例如，数据库连接、长按并将小部件拖动到固定位置，这些操作自动化实现是困难的。

3.3.2 检测漏洞的性能

图4显示了GPTDroid和基线在不同时间点检测到的漏洞总数。GPTDroid在93个应用中检测到95个漏洞，比最佳基线（Stoat与Toller）高出31%（95 vs. 66）。我们还比较了Stoat与Toller和我们的方法之间检测到的漏洞的相似性和差异性，结果显示Stoat与Toller检测到的所有漏洞也都被GPTDroid检测到。这表明GPTDroid在检测漏洞方面的有效性，有助于确保应用质量。

我们还可以看到，在每个时间点，GPTDroid检测到的漏洞都比基线多，并且在大约27分钟内达到最高值，与最佳基线相比节省了35%的测试时间（17 vs. 26），同时检测到更多的漏洞。这再次证明了GPTDroid的有效性和效率，这对于节省更多时间进行后续的漏洞修复非常有价值。我们将在3.3.3节进一步讨论其优越性能背后的原因。

3.3.3 消融研究（RQ3）

模块的贡献。表7显示了GPTDroid及其两个变体的性能。具体来说，对于没有GUI上下文（第2.1节）的GPTDroid，我们使用原始视图层次文件替换了GUI上下文信息并提取了小部件名称。对于没有功能记忆（第2.3节）的GPTDroid，我们移除了功能感知记忆提示。可以看到，GPTDroid的活动和代码覆盖率远高于所有其他变体，表明设计的模块的必要性和我们方法的优势。与GPTDroid相比，没有GUI上下文的GPTDroid导致最大的性能下降，即活动覆盖率下降了77%（0.17 vs. 0.75）。这进一步表明，GUI上下文提取可以帮助LLM理解GUI页面的结构和语义信息，并做出合理的判断。没有功能记忆的GPTDroid也经历了较大的性能下降，即活动覆盖率下降了55%（0.34 vs. 0.75）。这表明我们提出的功能感知记忆提示可以帮助在测试过程中保留知识，并获得全局视角以达到未覆盖的区域。

子模块的贡献。图5进一步展示了GPTDroid及其8个变体的性能。我们在查询LLM时移除了部分提示，即前四个变体分别移除了表2的模式1、2、3、5、6，后三个变体分别移除了表3的模式1、2、3。实验结果表明，移除任何子模块都会导致明显的性能下降，表明设计的子模块的必要性和有效性。移除已探索功能（GPTDroid w/oExplored Function）对性能的影响最大，活动覆盖率降低了51%（0.37 vs. 0.75）。这表明通过明确查询LLM关于测试进度的功能方面，该方法可以更清楚地了解正在测试的功能，并有效规划探索路径以覆盖更多功能。

最近测试操作数量的影响。图6展示了在不同数量的最新测试操作下的性能。可以看到，随着最近测试操作中测试页面的增加，活动和代码覆盖率都有所提高，即测试了5步的页面和操作。之后，即使增加了测试页面的数量，性能也会逐渐下降。这也进一步验证了我们在试点研究中选择的5步操作是有效和有价值的。

4 实用性评估

4.1 实验设置

本节进一步评估GPTDroid在检测新的崩溃漏洞方面的有用性。我们采用与前一节类似的实验设置。为了简洁起见，我们仅比较最佳基线，即TimeMachine、Stoat with Toller和Humanoid，每种方法中表现最好的一个，根据图4所示的漏洞检测性能选择。需要注意的是，对于覆盖率，前三名是不同的基线组合，但本节关注的是它们在检测漏洞方面的能力，因此我们使用它们的漏洞检测性能作为标准。

我们从前一节中的12个类别中开始，选择最受欢迎且最近更新的317个应用。然后我们重新使用第3.1节中的四个筛选标准来筛选不可用的应用。不同的是，我们放宽了第四个标准，只要求应用具有报告漏洞的方式，因为在本节中，问题记录或拉取请求并非强制要求。这样，共有223个应用用于有用性评估。请注意，本节旨在评估GPTDroid是否能在应用中检测到新漏洞，因此允许本节和前一节应用之间的重叠。

我们使用与前一节评估相同的硬件和软件配置。当检测到崩溃漏洞时，我们通过在线问题报告或电子邮件将它们报告给开发团队。

4.2 结果与分析

在223个应用中，GPTDroid检测到涉及115个应用的135个漏洞，其中53个涉及41个应用的漏洞是新发现的漏洞。此外，这些新漏洞中只有9个被三个基线检测到。我们将这53个漏洞提交给开发者，其中35个已被修复/确认（20个修复和15个确认），其余的仍在等待中（没有一个被拒绝）。这进一步表明我们提出的GPTDroid在漏洞检测方面的有效性。由于篇幅限制，表8展示了这些已修复/确认的漏洞，完整列表可以在我们的网站上找到。

我们进一步分析这些漏洞的细节，发现其中17个涉及多个文本输入或复合操作。此外，我们还观察到有11个漏洞在触发漏洞之前需要执行超过20次操作，从MainActivity页面开始计算，这表明GPTDroid在测试更深层次功能方面的能力。此外，我们发现至少有28个漏洞与应用的主要业务逻辑有关。

转述：李昕