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

刘姝琪 等: 组件感知的安卓应用崩溃自动复现方法 2465

3.2 实现细节及环境配置
本文使用 Python 3.9.21 实现了所提出的方法, 并基于多种现有工具进行了扩展, 以支持崩溃复现任务. 代码已
发布于: https://github.com/liushuqi-2022/CReDroid. 在交互与数据预处理方面, 利用 Appium [32] 与安卓应用进行交
互, 提取当前页面的视图层次结构; 使用 Apktool [33] 从 APK 文件中提取 AndroidManifest.xml 文件、资源文件和源
代码; 结合数据流框架 Soot [34] 和动态探索工具 ICCBot [22] 构建 CTG, 支持页面间路径的分析. 在路径处理与语义分
析方面, 采用 networkx [35] 对获取的 CTG 进行操作, 检索页面间的可达路径; 通过 NLTK [36] 对提取的文本数据进行
预处理, 通过 Sentence-Transformers [37] 模型生成控件描述的语义嵌入, 并结合 sklearn [38] 计算嵌入之间的余弦相似
度, 以衡量 GUI 控件的语义分数. 在崩溃日志记录与结果展示方面, 借助 LOGCAT [39] 记录运行时异常日志, 提取触
发崩溃的关键信息; 通过 OpenCV [40] 在页面截图上标记交互的目标控件, 并以图文结合的方式直观展示复现步骤.
实验运行在 Windows 10 操作系统上, 设备配备 32 GB 内存和 Intel Core i7-12700 处理器. 测试环境使用 Android
4.4 至 8.1 版本的安卓模拟器, 用于验证 CReDroid 的性能.
此外, 随着训练数据规模的不断扩展, 基于大型语言模型的生成式 AI 在面对特定任务或提示时给出准确的回
答, 并在多个领域展现卓越的性能. 本文使用在 OpenAI 官网发布的 ChatGPT 模型 [41] , 其基础模型是 GPT-3.5-turbo,
并通过自定义数据集结合官方 API 说明对模型进行微调. 微调后的模型被用于从崩溃报告的标题或者摘要中提取
关键词, 为崩溃复现任务提供有效的辅助支持.
3.3 评估指标与评估设置
本文从有效性和效率两个维度对所提方法 CReDroid 的性能进行评估. 有效性通过计算在限定时间内成功复
现崩溃报告的百分比 (即成功率) 进行验证, 效率则通过统计完成一次成功复现所需的时间 (即复现时间) 进行
衡量.
针对 RQ1, 沿用 Huang 等人 [14] 的实验设置, 将崩溃复现的最长测试时间限定为 1 h. 为了减轻实验中因随机性
导致的偏差, 每个崩溃报告在对应目标应用上分别运行 3 次, 并取平均值作为成功复现时间. 据我们所知, CReDroid
是第 1 个利用崩溃报告的标题和堆栈跟踪进行崩溃复现的方法. 为了全面评估 CReDroid 的性能, 我们选择了 5 种
代表性工具作为基准方法进行对比, 即 CrashTranslator [14] 、ReCDroid 、ReproBot 、Monkey [17] 和 APE [18] .
[8]
[9]
● CrashTranslator [14] . 该工具代表基于堆栈跟踪的崩溃复现, 与 CReDroid 最为接近. CrashTranslator 仅依赖堆
栈跟踪信息, 通过 LLM 预测触发崩溃的探索步骤, 并结合强化学习缓解预测误差从而全面引导搜索. 在实验中, 我
们仅提供崩溃堆栈跟踪作为其输入.
[8]
[9]
● ReCDroid 和 ReproBot . 这两种工具依赖逐步指导的文本描述的复现步骤来实现崩溃复现. ReCDroid 采
用预定义的语法模式解析报告中描述的事件, 并使用动态 GUI 探索合成事件序列以重现崩溃. ReproBot 通过时间
归一化和重排序提取独立步骤, 并利用强化学习探索应用来匹配步骤和 UI 事件. 由于本研究未涉及详细复现步
骤, 这些方法无法直接应用于我们的任务. 然而, 考虑到崩溃报告标题也是一种文本描述, 即使缺失详细步骤, 我们
仍将其作为输入. 如果标题不可用, 则提供堆栈跟踪中的包含应用包的 API 信息, 不管方法是否能理解.
● Monkey [17] 和 APE [18] . 这两种工具是典型的自动化 GUI 测试工具, 具备检测崩溃的能力. Monkey 通过随机
事件 (如点击、滑动、输入等) 对应用进行无目标探索. APE 采用基于模型的测试方法, 利用运行时信息动态优化
GUI 抽象模型, 提高测试覆盖率. 这两种工具被广泛用于许多研究工作的基准对比方法.
针对 RQ2, 我们在 RQ1 的实验结果基础上, 进一步分析不同工具在崩溃复现任务中的互补性. 由于各工具在
复现过程中依赖的崩溃报告信息不同, 我们将 74 个崩溃报告划分为两类: (1) 仅包含堆栈跟踪信息的崩溃报告
(9 个), 这些报告仅提供崩溃发生时的堆栈跟踪信息, 标题中通常仅包含关键的堆栈跟踪语句, 缺乏显式的用户操
作描述; (2) 同时包含标题和堆栈跟踪信息的崩溃报告 (65 个), 这些报告除了提供完整的堆栈跟踪, 标题中还包含
一定程度的操作描述. 基于此分类, 我们统计不同工具在这两类崩溃报告上的复现成功率, 并探讨其适用场景. 具
体而言, 我们关注以下两个方面: 不同工具在两类崩溃报告上的复现能力, 分析是否存在方法在某类崩溃报告上的
复现成功率更高; 每类崩溃复现工具的适用场景, 探讨是否存在某些崩溃仅能被特定工具复现, 并分析相同类别工