Page 137 - 《软件学报》2026年第6期

2456 软件学报 2026 年第 37 卷第 6 期

component interaction data from the CTG to accurately locate the target crash component. Second, based on the critical operations in the
crash report title and the reachable paths in the CTG, CReDroid designs an adaptive strategy that uses the contextual relationship between
the current page’s component and the crash component to assign priority scores to GUI widgets. The dynamic exploration process is
globally optimized through reinforcement learning to effectively reduce inaccuracies in the prediction process. This study evaluates
CReDroid using 74 crash reports and compares its performance with state-of-the-art crash reproduction tools, including CrashTranslator,
ReCDroid, and ReproBot, as well as widely used automated testing tools, Monkey and APE. The experimental results show that CReDroid
successfully reproduces 57 crash reports, which is 13, 25, 27, 30, and 17 more than CrashTranslator, ReCDroid, ReproBot, Monkey, and
APE, respectively. Moreover, for the successfully reproduced crashes, CReDroid reduces the average reproduction time by 26.71%,
94.96%, 71.65%, 84.72%, and 88.56%, compared to CrashTranslator, ReCDroid, ReproBot, Monkey, and APE.
Key words: crash reproduction; component awareness; stack trace; report title
截至 2024 年 10 月, 安卓用户可以在 230 万个应用中进行选择 [1] , 其中 Google Play 的应用下载量已超过
[2]
[4]
256 亿次 [3] , 市场份额超过 70% , 成为全球应用数量最多的应用商店. 然而, 随着安卓应用 (Android application) 功
能的不断丰富和交互环境的日益复杂, 应用崩溃问题也出现更加频繁, 这对用户体验和隐私安全带来极大影响 [5] .
[7]
[6]
当用户遇到崩溃问题时, 他们通常会通过例如 GitHub 、Bugzilla 等问题跟踪系统提交一份错误报告, 描述应用
故障情况, 并提供相应的复现步骤以协助开发人员解决问题. 为保障用户的高质量体验, 开发者需要根据报告中提
供的信息尽快复现崩溃, 定位崩溃原因并快速修复崩溃问题.
用户通常通过文本描述、截图、录制视频等形式提供崩溃复现的步骤, 或直接提供堆栈跟踪信息来描述应用
崩溃的情况. 现有研究主要利用崩溃报告的两类信息进行崩溃复现. 第 1 类方法侧重于基于复现步骤的崩溃复现,
通常依赖用户提供的文本描述或视觉记录等包含逐步指导信息的复现步骤 [8−13] . 对于文本描述提供的复现步骤,
一些研究 [8−12] 通常设计用于解析复现步骤的预定义语法模式, 利用自然语言处理技术, 从中提取有用信息, 并采用
动态探索策略, 在当前页面中匹配可能触发崩溃的相关图形用户界面 (graphical user interface, GUI/UI) 事件. 此外,
针对例如视频以视觉记录形式提供的复现步骤, GIFDroid [13] 通过图像处理技术将视频的关键帧映射到 GUI 状态,
并基于 UI 转换图静态搜索视频中可能缺失的步骤. 第 2 类方法主要依赖堆栈跟踪信息实现崩溃复现. 例如, Crash-
Translator [14] 通过分析堆栈跟踪中的崩溃相关信息, 结合大型语言模型 (large language model, LLM) 预测可能的探
索步骤. Mole [15] 则对被测应用进行静态分析, 跟踪到崩溃点的可达路径中的相关控件 (widget), 从而实现从堆栈跟
踪信息中自动复现崩溃.
尽管这些崩溃复现方法取得了一定的进展, 但在实际应用中仍存在以下局限性, 影响着崩溃复现的成功率和
效率. 第一, 基于复现步骤的方法高度依赖用户提供完整的操作信息. 实际上, 用户提交的崩溃报告往往不完整, 缺
乏详细的操作步骤, 甚至可能仅包含崩溃的堆栈跟踪信息, 导致复现困难. 报告标题中可能包含相关操作信息, 但
这些信息通常较为有限, 难以提供完整的行为指导. 第二, 仅依赖堆栈跟踪难以准确定位崩溃组件 (component), 缺
乏明确的方向指导动态探索过程. 例如, 在图 1 中 AnkiDroid 的问题 ID 为 4586 [16] 崩溃案例中, 由于堆栈跟踪中崩
溃语句未包含显式的应用组件信息, CrashTranslator 无法定位到崩溃发生的具体活动 (activity), 从而无法有效引导
探索. Mole 尝试通过分析 GUI 控件的属性状态来寻找通往崩溃点的可行路径, 在崩溃复现中关注可达路径中的相
关控件. 然而, 由于底层调用图构造的复杂性, Mole 在依赖调用图定位崩溃点时可能会出现偏差. 此外, 现有研究
忽略了触发事件对被测应用组件交互上下文的影响. 虽然 CrashTranslator 基于应用所有活动, 利用 LLM 预测下一
个可达活动, 但其预测的活动转换可能并不真实存在, 进而影响崩溃复现的效率. 第三, 现有研究未能充分利用崩
溃报告中的多维信息. 当缺乏复现步骤并且堆栈跟踪中的指导性信息不足时, 未能结合其他关键信息 (如标题中的
自然语言描述), 导致搜索空间过大. 应用的 GUI 页面通常包含大量可交互控件, 缺乏关于崩溃场景信息的指导会
使动态探索过程更具不确定性, 增加了触发崩溃事件序列的难度.
针对以上问题, 本文提出一种组件感知的安卓应用崩溃自动复现方法 CReDroid, 能够结合崩溃报告的标题信
息和堆栈跟踪来有效地复现崩溃. 该方法融合了基于复现步骤与基于堆栈跟踪的两类方法优势, 不仅借助堆栈跟
踪辅助崩溃组件定位, 还结合标题中的关键操作和堆栈信息引导崩溃路径的探索. 首先, 借助 LLM 从崩溃报告的
标题中提取关键操作, 以此代表崩溃场景的核心信息. 其次, 使用自动应用探索工具对被测应用进行分析, 构建组