Android state_pressed代码设置

安卓设置蜕变测试setDroid

• Setting-wise Metamorphic Fuzzing

• High-level Idea
• Approach
• Oracle checking rule 1
• Oracle checking rule 2

• Design and Implementation of SetDroid

论文：Understanding and Finding System Setting-Related Defects in Android Apps

Setting-wise Metamorphic Fuzzing

High-level Idea

主体思想：在大多数情况下，如果给定设置发生更改并随后正确恢复，应用程序行为应保持一致，或者如果未恢复则显示预期差异。 否则，可能会发现设置缺陷（setting defect）。 例如，如果网络关闭但立即打开，应用程序的功能不应受到影响； 或者，如果更改默认语言，应用程序应该以不同的语言显示文本。 因此，基于前面的观察，作者受到启发，利用蜕变测试来解决 oracle 问题。

Approach

作者的方法是 Setting-wise Metamorphic Fuzzing，将一对事件 ⟨$e_c$ ，$e_u$ ⟩ 随机注入给定的种子 GUI 测试 𝐸 以获得突变测试 𝐸 ′ ，其中 $e_c$ 更改给定的设置，而 $e_u$

Formally，让 𝐸 是一个种子 GUI 测试，它是一系列事件，i.e., 𝐸 = [$e_1$ , . . . ,$e_i$ , . . . ,$e_n$], 其中 $e_i$ 是用户事件（例如，单击、编辑、滑动、屏幕旋转。 𝐸 可以在应用程序 𝑃 上执行以获得一系列 GUI 布局（页面）𝐿 = [$l_1$ , . . . , $l_i$, . . . , $l_{n+1}$ ]，其中 $l_i$ 是一个 GUI 布局（由多个 GUI 小部件组成）。具体来说，如果我们将 $e_i$ 的执行视为一个函数，那么 $l_{i+1}$ = $e_i$($l_i$),𝑖 ≥ 1。我们可以得到一个突变的 GUI 测试 𝐸 ′ = [$e_1$, . . . ,$e_c$ , . . . ,$e_u$ , . . . ,$e_n$ ] 可以在 𝑃 上执行以获得一系列 GUI 布局 ’ ’ (页面) 𝐿 ’ = [$l_1$ , . . . , $l_c$ , . . . , $l_u$ , . . . , $l_{n+1}$]。我们分别比较𝐸（即𝐿）和𝐸′（即𝐿′）的GUI 布局之间的GUI 一致性，以发现缺陷。在实践中，我们通过比较 𝐿 和 𝐿 ′ 之间可执行 GUI 小部件的差异来检查 GUI 一致性。让 𝑒.𝑤 成为 𝑒 目标的 GUI 小部件 𝑤。

Oracle checking rule 1

规则 I 与以下两种策略相结合，将 ⟨$e_c$ ，$e_u$

• Immediate setting mutation. 我们注入$e_c$ 紧接着是 $e_u$ 。 例如，$e_c$开启省电模式，$e_u$
• Lazy setting mutation. 我们先注入 $e_c$ 并仅在必要时注入 $e_u$（例如，应用程序提示警报对话框或请求消息）。 例如，$e_c$ 撤销应用权限，而$e_u$仅在应用请求该权限时授予该权限。 请注意，我们的研究证明了惰性突变策略的合理性，因为 Android 设计指南要求向用户提示适当的警报以改善用户体验.

上图说明了规则一：在这两种注入策略下，如果存在一个GUI事件$e_i$∈𝐸′及其目标widget $e_i$.𝑤不能位于对应的布局ℓ𝑖′∈𝐿′（ℓ𝑖′对应 到 ℓ 𝑖 ∈ 𝐿)，然后发现一个可能的设置缺陷。 因为它可能表明应用程序的行为受到了影响。Formally,

Oracle checking rule 2

在规则 II 下，我们只将 $e_c$注入 𝐸（$e_u$被忽略）。 此规则旨在确认更改给定设置，例如语言、小时格式（12 小时或 24 小时格式）确实会导致一些 GUI 更改。例如，当默认语言改变时，我们检查 ℓ 𝑖 和 ℓ 𝑖 ′ 中的文本是否确实是预期的不同语言，而没有出现其他不一致的情况。 在实践中，我们使用名为 langid 的语言识别工具来确定每个文本的语言。

因此，规则 I 对 GUI 一致性进行同等检查，并适用于设置缺陷的三种常见后果，即崩溃（GUI 不一致的一种特殊情况）、功能故障和有问题的 UI 显示。 规则 II 对 GUI 一致性进行不等式检查，并适用于对设置更改无效的检查。

Design and Implementation of SetDroid

作者实现了一个名为 SetDroid 的自动化 GUI 测试工具。图 6 描述了工作流程。它有四个主要模块：(a) 测试执行器，(b) 设置更改注入器，© oracle 检查器，和 (d) 错误报告减少器。我们将详细介绍四个模块如下。

Test executor.。 测试执行器在两个相同的设备 A 和 B 上并行运行同一个被测应用程序 (AUT)。在测试期间，执行器在设备 A 上即时生成种子测试，并同时在设备 B 上重放注入了设置更改（即突变测试）的相同种子测试。执行器循环工作：(1) 在设备 A 上获取 AUT 当前的 GUI 布局，(2) 从布局中随机选择一个可执行小部件并生成一个事件，(3) 在设备 A 和 B 上执行事件. 这种即时策略为在运行时注入设置更改提供了灵活性。我们使用随机种子测试，因为它们是多样的、实用的、可扩展的。在实践中，我们使用 UI Automator 测试框架来执行事件并获取 GUI 布局。

Setting change injector。根据我们的研究，我们在设计此模块时采用了两个关键见解。首先，我们发现我们研究中的许多设置缺陷 (211/486≈43.4%) 是由在运行时更改设置而不是在启动应用程序之前触发的。在第一个见解的指导下，SetDroid 在种子测试的任何位置而不是仅在开始时随机注入事件对 ⟨𝑒 𝑐 ,𝑒 𝑢 ⟩。此外，如果一对 ⟨𝑒 𝑐 ,𝑒 𝑢 ⟩ 被注入并且没有发现设置缺陷，那么下一个相同的 ⟨𝑒 𝑐 , 𝑒 𝑢 ⟩ 稍后再次注入。这个过程一直持续到种子测试结束。其次，我们发现只有少数设置缺陷（10/486≈2%）是由显式更改两个设置（即两个设置同时更改为非默认值）引起的，没有任何缺陷是由更改引起的两个以上的设置。在第二个见解的指导下，设置更改注入器一次随机注入一对事件 ⟨𝑒 𝑐 ,𝑒 𝑢 ⟩，不与其他事件交错。只有屏幕方向（被视为普通用户事件）可以与其他设置更改交错。具体来说，注入器通过投币决定是否在种子测试中的每个 GUI 事件之后注入 𝑒 𝑐，然后根据变异策略注入 𝑒 𝑢。表 4 列出了支持设置更改的事件对和相应的注入策略。 这些事件是根据我们的实证研究设计的，可以体现大多数设置缺陷并涵盖其他可能形式的相关设置更改。 测试前，将𝐴和𝐵这两款设备初始化为相同的默认设置环境：飞行模式关闭、Wi-Fi开启、移动数据开启、定位（高精度）开启、省电模式关闭、多窗口关闭、屏幕方向 在横向，免打扰模式关闭，语言为英语，12 小时制。

Oracle checker. 在测试执行器生成每个事件后，oracle 检查器会检查设备 B 的布局是否与设备 A 的布局一致（即规则 I），或者显示预期的差异 w.r.t. 设备 A（即规则 II），同时还监控应用程序崩溃。 如果发现缺陷，检查器会生成错误报告，其中包括执行的事件、GUI 布局和屏幕截图。

Bug report reducer. 错误报告减少器会删除任何重复或无法忠实再现的错误报告。 具体来说，它会重放记录的 GUI 测试，这些测试触发多次运行的设置缺陷，以确定可重复性。 它使用两个布局之间的 GUI 不一致作为哈希键来删除任何重复的错误报告。 此步骤不会导致任何漏报。