Page 145 - 《软件学报》2026年第6期
P. 145

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


                    ● 新状态和组件奖励. 若某动作成功探索到一个新的状态, 则会获得正向奖励, 以激励探索新状态的行为. 每
                 个  GUI 页面所属的组件代表着崩溃探索的方向. 当新状态属于可达路径中的组件时, CReDroid                      会赋予该动作正向
                 奖励. 若新状态属于崩溃组件, 则获得更高奖励, 鼓励更深入的探索.
                    ● 标题操作奖励. 若动作操作的         GUI 控件与崩溃报告标题中的关键操作相关联, 则获得正向奖励, 表明该动作
                 可能是触发崩溃的关键操作, 有助于缩小探索范围.
                    ● 重复或失败的状态处罚. 当触发一个动作使得应用转换到一个已经探索过的状态, 该动作会受到惩罚, 因为
                 它触发崩溃的可能性较低. 另外, 如果某动作使得被测应用跳转到无关页面                        (如打开浏览器) 或触发非目标崩溃,
                 则会受到大的惩罚. 这些惩罚旨在避免            CReDroid  在不可能触发目标崩溃的动作上浪费探索资源.
                    每个状态-动作对的       Q  值存储在  Q-Table 中, 记录与崩溃相关的探索信息并帮助记忆有价值的动作. 当被测应
                 用第  1  次探索新状态时, 该状态中的所有动作值会初始化为                0. 随着探索的进行, 根据奖励或惩罚通过           Bellman  函
                 数更新   Q  值:

                                                                ∗
                                          Q(s t ,a t ) ← Q(s t ,a t )+α(r t +γQ (s t+1 ,a t+1 )− Q(s t ,a t ))  (1)
                 其中, α  为学习率, 控制每次更新的幅度, 设为         0.1;  r t  为当前动作的奖励; γ 为折扣因子, 权衡当前奖励与未来奖励,
                 设为  0.9;   Q s t+1 a t+1 ) 指的是转换后状态  s t+1  中所有动作的最大  Q  值, 反映后续探索的潜在收益.
                          (
                             ,
                         ∗
                  2.3.3    序列约简
                    在崩溃复现过程中, 所有与         GUI 控件的交互操作都会被记录在探索历史中, 该历史在被测应用重新启动后会
                 被清空. 在成功触发目标崩溃时, 探索历史中保存了从被测应用启动到崩溃发生的所有                           GUI 操作. 然而, 这些记录
                 往往包含重复或者循环的冗余交互            [29,30] , 无法直接反映复现崩溃的最直接步骤.
                    为了便于快速定位和触发崩溃, CReDroid          对探索历史中的交互序列进行自动化约简, 去除多余的重复和循环
                 操作, 仅保留必要的关键步骤. 最终, 约简后的交互序列被转换为自动重放的脚本和人类可读的复现步骤. 如图                                 2
                 所示, 复现步骤以“图像+文本”的形式呈现. 具体而言, 每个复现步骤均通过在页面截图上用矩形框标注触发的目
                 标  GUI 控件, 并以“事件类型+控件名称”的文本描述对应的操作.
                  3   实验设置

                    为了评估    CReDroid  在复现崩溃方面的整体性能, 本文设计了如下            4  个研究问题.
                    RQ1: CReDroid  在崩溃复现有效性与效率上分别表现如何?
                    RQ2: 这些最先进的技术在复现崩溃时是否互补?
                    RQ3: 自适应控件评分模块是否能够提高            CReDroid  崩溃复现的效果?
                    RQ4: CReDroid  生成的复现步骤是否能够正确触发崩溃?
                  3.1   实验数据

                    本文构建了一个包含        74  个崩溃报告的数据集, 用于评估所提出的            CReDroid. 该数据集的崩溃报告来源于以
                                         [9]
                 下  3  个相关工作: (1) ReCDroid 的评估数据集, 包含     33  个崩溃报告; (2) CrashTranslator [14] 的评估数据集, 包含  20
                 个崩溃报告; (3) 从   AndroR2 [31] 数据集中筛选出  21  个崩溃报告, 这些报告与前两者不重复. 本研究仅关注崩溃报
                 告, 不包含其他类型的非崩溃报告          (如界面显示问题的缺陷报告).
                    为确保数据集的完整性和准确性, 我们对每个崩溃报告对应版本的应用进行了实际交互, 以验证所选报告的
                 可复现性, 并排除了重复的报告. 需要说明的是, 这              74  个崩溃报告  (33+20+21) 中并非全部包含堆栈跟踪信息. 对
                 于缺乏堆栈跟踪的报告, 我们通过          GitHub  提供的复现步骤手动触发崩溃, 并从运行日志中提取相应的堆栈跟踪信
                 息. 这些堆栈跟踪随后被用于在运行过程中验证崩溃是否能够成功复现. 在实验过程中, 本文仅使用崩溃报告中的
                 标题和堆栈跟踪信息进行崩溃复现, 未参考报告中可能包含的复现步骤或截图. 此外, 崩溃报告在开发者确认和修
                 复过程中可能会被修改, 以更准确地描述崩溃场景. 为避免被修改的标题无法真实反映用户的实际行为, 本文直接
                 采用崩溃报告的初始标题构建标题数据集. 对于缺乏标题的崩溃报告, 则使用摘要作为替代.
   140   141   142   143   144   145   146   147   148   149   150