Page 118 - 《软件学报》2025年第5期

2018 软件学报 2025 年第 36 卷第 5 期

e 47 由于未造成 GUI 界面的跳转变化被其忽略, 导致其约减后路径无法触发崩溃. SimplyDroid 算法约减后的结
件
果中有 22 个测试序列无法触发崩溃, 达到了总序列数的 33%, 通过对其无法正确约减的序列进行分析, 我们发现
其在 Activity 层次进行抽象, 导致约减策略过于粗略, 很多事件被合并到一起进行验证, 程序无法崩溃时则直接忽
略这些事件, 导致其中一些原本对触发程序崩溃有作用的关键事件被去除, 例如序列 5 来自 ATimeTracker 应用,
在此序列中, 其触发崩溃的操作为创建活动并打开设置, 将其 sound 属性从 disabled 切换为 enabled, 然后返回活动
列表并点击创建的活动, 其中切换 sound 属性的步骤仅改变了 sound 控件的状态, 而由于 SimplyDroid 在 Activity
层次进行建模, 忽略了此关键步骤, 导致其约减结果无法触发崩溃. 我们的方法 TREC 则对所有的测试序列均可返
回正确触发程序崩溃的结果.

4.4.2 研究问题 2: 约减序列长度分析
表 2 中右侧第 3、6、9 列给出了每个算法对各个测试序列约减后的序列长度. 由表格可以看出, 在 ECHO 给
出的测试序列能够触发崩溃的情况下, 仍无法保证其给出的是最短测试序列. 例如对于序列 44, ECHO 约减后序
列长度为 35, 而 TREC 和 SimplyDroid 则分别给出了长度为 14 和 17 的测试序列. 这是因为 ECHO 仅仅在控件层
次进行约减, 抽象粒度较低, 当测试序列一直在同一 Activity 中进行细微探索时, 导致测试状态跳转图中最短路径
也很长, ECHO 生成的测试序列也会很长. 而 SimplyDroid 本身在 Activity 层面进行抽象、TREC 采用控件与页面
布局结合的方式进行抽象, 均可规避这个问题.
对比 SimplyDroid 与 TREC 的约减结果, 在 57 个测试序列上, TREC 约减后的序列长度比 SimplyDroid 得到
的结果更短或相等, 占到总序列的 86%, 而在这其中二者给出的序列长度相差大于 3 的达到了 30 个. 此外, 对于标
号 57–60 的 4 个序列, SimpyDroid 给出的序列仍包括几十甚至上百个事件, 与 TREC 给出序列长度相差 10 倍以
上, 通过进一步分析发现, 此缺陷来源于 Transistor 应用, 其是一款广播电台收听与管理应用, 其崩溃触发操作序列
包括了应用切换、输入等复杂操作, 且包括了对创建的电台的图标切换操作, 此操作无法在 Activity 层次上进行
体现, 导致 SimplyDroid 无法有效约减, 约减后序列仍旧包括很多冗余, 我们认为在这种情况下 SimplyDroid 给出
的测试序列对开发者进行后续的测试理解或复现没有任何帮助.
TREC 仅在 10 个 (15%) 上生成了更长的测试序列, 而在这其中二者给出的序列长度相差大于 3 的仅有 3 个 (序
列 34、40、43), 经过对这些序列进行分析, 我们发现这 3 个案例均来自 OpenSudoKu 游戏软件, 包括了简单、中
等、复杂这 3 个难度的数独游戏界面, 它们均采用了相同的布局结构, 导致 TREC 在布局粒度上约减时无法区分.
此外, TREC 在这 3 个测试序列的约减结果长度分别为 14、15、19, 约减掉了原序列的 82%、83%、82%, 我们认
为此约减结果已经足够精简, 可以辅助开发者进行后续测试理解或复现.

4.4.3 研究问题 3: 约减效率分析
表 2 中右侧第 4、7、10–12 行分别给出了 ECHO、SimplyDroid、TREC 的约减时间, 其中标记时间为 TREC
对每个事件进行标记花费的时间, 约减时间代表了具体约减算法执行时间. 由表格可以看出, 在 ECHO 能够成功
约减的情况下, 其与 TREC 花费的时间相差不大, 我们进行了二者运行时间的配对 t 检验, 其显著性 p 值为 0.072 39,
代表二者之间没有显著差别, 这也与二者均是先发现平凡最短路径的设计策略相匹配.
对于 SimplyDroid, 其在 58 个测试序列上的约减时间均高于 TREC, 占到了总序列的 87.88%, 而对于其能成功
约减的序列, TREC 则在 36 个案例上能在更短时间内约减, 占到了总成功序列的 81.82%. 此外我们计算了二者在
成功案例上的配对 t 检验, 其结果为 0.007 9, 说明 TREC 约减效率明显优于 SimplyDroid 方法.
为了更直观地展示二者的区别, 我们计算出二者在每个测试序列上的总执行时间相差数值, 并绘制了柱状图,
其结果展示在图 3 中, 其横坐标为测试序列标号, 纵坐标为运行时间差, 数值为正表示 TREC 约减效率更高, 此外,
黄色柱形代表 SimplyDroid 在此测试序列上的约减结果无法触发测试崩溃. 从图 3 可以看出在绝大多数测试序列
上, TREC 的约减时间均明显小于 SimplyDroid, 其中很多测试序列二者相差时间超过 1 h, 二者最高时间相差
1 308.52 min, 超过 21 h. 此外, 二者时间相差超过 1 h 的序列中, SimplyDroid 在绝大多数案例上均无法成功约减,
这严重限制了其在实际使用的价值, 开发者可能等待 1 h 仍无法得到可成功触发崩溃的约减结果. 例如序列 37 源
于 OpenSudoKu 应用, 包括了编辑单个数独游戏名称然后取消、删除单个数组游戏等操作, 这些操作由于均在弹