记录和重放工具对于移动应用程序的质量保证是必不可少的。由于其重要性，正在开发越来越多的工具来记录和重放 Android 用户交互。但是，通过对工业环境中各种现有工具进行实证研究，研究人员发现行业要求的特性与公开可用的记录和重放工具的性能之间存在差距。该研究得出的结论是，评估中的现有工具不足以用于工业应用。在本文中，我们提出了一种称为 SARA 的记录和重播工具，旨在弥合差距并广泛采用。具体而言，动态仪表技术用于在应用层中容纳丰富的输入源，以满足行业要求的各种约束。提出了一种自我重播机制来记录更多用户输入信息，以进行准确的重播而不会降低用户体验。此外，还设计了一种自适应重播方法，可以在具有不同屏幕尺寸和 OS 版本的不同设备上重播事件。通过评估 53 种高度流行的工业 Android 应用程序和 265 种常见使用场景，我们证明了 SARA 在记录或重放相同或不同设备上的丰富输入源方面的有效性。

2、介绍

移动设备已经迅速成为世界上最易访问和最受欢迎的计算设备。记录及回放工具在质量保证的过程中起着重要的作用对于移动应用程序，由于其功能在记录用户与应用程序交互和重现各种设备在稍后的时间，允许开发者测试应用程序在不同的设备上。例如，回归测试的过程可以在高级测试选择技术的协作下实现自动化。为此，开发人员和测试人员的负担大大减轻，来自学术界和工业界的许多努力都致力于构建记录和回放工具。

然而，最近对大多数现有工具的研究表明，目前可用工具的能力与业界对 Android 应用程序的记录和回放需求之间存在显著差距。微信是最受欢迎的社交媒体应用之一，拥有超过 10 亿的月活跃用户，其开发者要求一个理想的记录和回放工具应该提供四个功能，并满足四个限制。这四个特征包括F1)记录的运动事件应该基于屏幕坐标(测试者在屏幕上的触点)；(F2)记录的运动事件应该基于部件(如，按钮，文本字段)；(F3)记录的事件应该对 app 的状态不敏感；和(F4)事件之间的时间应该被记录。这四个约束是(C1)不需要自定义 OS；(C2)不需要在 app 上使用仪器；(C3)不需要根访问；(C4)不需要 app 的源代码。同时，还有其他一些常见的需求，即工具的源代码是可用的；记录的数据应该是人类可读的；记录的数据应该能够在不同屏幕大小和操作系统版本的不同设备上重放。

根据研究，没有公开可用的工具满足所有期望的特性，在行业要求的约束下提供所有特性有三个挑战：（1）记录和回放输入来源丰富；（2）有效地记录基于小部件的运动事件；（3）在不同的设备上重放事件。

在本工作中，我们设计并实现了一个名为 SARA 的记录和重放工 具(Android 的自复写增强记录和重放)，以解决所有上述挑战，并以广泛采用为目标。为了实现这一目标，SARA 集成了三大技术：

(1) 动态仪表被应用于记录和回放移动设备上的各种输入，包括来自传感器的输入。它甚至在上述各种约束下工作，例如没有自定义操作系统和源代码。

(2) 针对基于小部件的运动事件有效记录问题，提出了一种自重复机制。具体来说，SARA 首先记录仅基于屏幕坐标的运动事件，在用户交互过程中。然后，它自动地在同一设备上重放记录的事件，以识别交互下的小部件。自播放前的录音是一种低成本的操作。因此 SARA 可以记录运动。基于屏幕坐标和小部件的事件，同时提供良好的用户体验。

(3) 设计了一种自适应重放方法，用于在不同设备上重放事件。SARA 能够通过启发式搜索小部件和转换坐标来重播事件，以适应不同的屏幕大小和操作系统版本。

我们在三种不同的 Android 设备上评估了 SARA，其中有 53 个非常流行的工业 Android 应用程序和 265 个常见的使用场景。评价结果表明：

(1) 在同一设备上的 265 种常见使用场景中，SARA 成功地记录和回放了 228 种，分别超过了 appetizer 和 RERAN 的 161 次和 29 次成功回放。因为 SARA 对事件之间的时间不敏感，我们不将它与 monkeyrunner 进行比较。在答复中，事件之间的时间安排至关重要。

(2) 在 42 种常见的使用场景中，SARA 成功地在两个具有相同显示纵横比但不同屏幕大小的设备上重播了 41 种，这是 31 种以上的 appetizer 成功重播。SARA 在 42 个设备中回放了 34 个，这两个设备在显示纵横比和屏幕大小上都有不同。请注意，开胃菜未能在具有不同显示纵横比的设备上重播任何事件。我们不比较 SARA 和 RERAN，因为它不支持在不同的 设备上重放事件。

(3) 虽然 SARA 应用了仪器技术并基于小部件记录运动事件，但与原始运行时相比，记录和重放的开销仅为 4.29%和 7.07%。空间开销只有 1.78KB 每秒。

3、相关知识

学术界和工业界在开发桌面应用程序和 Android 应用程序的记录和回放工具方面取得了很大进展。Android 应用程序的工具可以根据记录输入的层分为以下三类。

Linux 内核层。RERAN 是研究者提出的第一个记录和回放工具之一。它在内核层中工作。 具体来说，它通过读取 /dev/input/event*文件中的日志，用 ADB 命令 getevent 捕获低级事件，并利用命令 sendevent 来重播事件。低级别事件与硬件紧密耦合，使得很难重新构造成高级别的手势并在其他设备上重播。Mosiac 和 appetizer 通过同一途径捕捉事件。这些工具在记录和回放一些传感器输入方面有局限性，因为像 GPS 这样的输入没有写入日志。

Android 框架层。VALERA 修改了 Android 框架，以捕获传感器和网络输入，事件时间表以及应用程序间通信，从而实现了精确的记录和重播。但是，VALERA 需要自定义 OS 进行记录和重放，这违反了行业的限制。

应用层。在应用层中有很多记录输入数据的工具。特别是 Mobiplay 采用客户机-服务器体系结构,包括客户端应用程序运行在移动设备和目标应用程序在服务器上运行拦截输入应用。然而,不能重放传感器输入像 GPS 在没有源代码的应用。Espresso 记录运动事件基于部件和关键事件记录下将调试器附加到应用程序,但它不能记录传感器输入和复杂的手势像缩放,必要时,它也需要源代码的应用程序。Robotium 是派生自 Selenium web 浏览器自动化工具。它只能拦截那些被应用程序的主进程控制的小部件。在评估过程中，我们发现大多数流行的工业应用程序实际上启动了多个进程。Culebra 在桌面上提供图形用户界面，用户可以与 record 下的应用程序进行交互。在将用户动作发送到应用程序之前，Culebra 试图识别将在视图层次结构中交互的小部件，这在精神上非常类似于 MobiPlay。但是它引入了大量的时间开销，并且不能记录传感器输入。Ranorex 是一个跨平台的商业测试自动化工具。它支持通过仪器记录基于坐标和小部件的事件，但它不能记录传感器输入，也不能记录大型应用程序。SARA 也属于这一类。它被设计用来记录和重放不同类型的输入，在行业要求的约束下。

4、研究方法

在本节中，我们将详细介绍 SARA 背后的设计决策，以及 SARA 如何应对在行业要求的各种约束下提供特性的挑战。

4.1 通过动态仪器记录和重放丰富的输入源

现有的工具通常需要定制的操作系统或应用程序的源代码来记录和回放移动设备上丰富的输入源。然而，行业开发人员不喜欢定制操作系统的工具。由于自定义操作系统可能与设备不兼容，在实际操作过程中安装自定义操作系统非常耗时且容易出错。另一个主要的担忧是，在自定义操作系统中记录的事件可能不能转移到官方的 Android 操作系统。开发人员也不喜欢要求应用程序源代码记录在案的工具，因为他们有时会把测试外包给其他公司。然而，在没有定制操作系统和源代码的情况下记录和回放丰富的输入源并不是一件简单的事情，特别是对于那些输入来自 GPS 等传感器的数据。

为了应对这一挑战，SARA 在应用层中应用了动态仪器来记录丰富的输入数据源。首先，将丰富的输入源交付给应用层，允许开发人员处理它们。与 Linux 内核层和 Android 框架层相比，该层的输入数据是高级的。因此，在应用层中记录输入数据最显著的优点之一是，记录的数据是人类可读的，并且很容易被重构成高级手势(如缩放)，这使得测试人员很容易分析、修改和重新组装这些数据，以达到进一步测试的目的。其次，动态检测在应用程序运行时工作，不需要自定义操作系统或源代码。它也几乎不受在 Android 平台上越来越流行的隐藏代码的打包技术的影响。这是因为隐藏的索引代码将被解压缩以便在运行时执行。动态仪器技术在回放传感器输入(如 GPS，在第 4 节讨论)中也发挥着重要作用。

注意，开发人员从微信也不赞成仪器，他们关心的是仪表工具和应用程序之间的兼容性，但当我们将显示在第五节，SARA 兼容微信等高度流行的工业应用，这样可以缓解他们的担忧一些扩展。

4.2 通过自重播基于小部件有效记录运动事件

行业开发人员请求一个记录和重放工具，它根据坐标和小部件记事件。直观地说，基于小部件记录的事件比仅基于坐标记录的事件更健壮。在交互作用下，有各种方法来记录小部件，但它们通常会带来很大的开销，因为有关小部件的信息比坐标要复杂得多。例如，Espresso 能够通过在记录期间将调试器附加到应用程序来拦截小部件。但它不可避免地导致应用程序响应缓慢，从而导致用户体验差。

为了有效地记录基于坐标和小部件的事件，同时提供坚实的可用性，SARA 引入了一种新的自我回放机制，将典型的记录阶段分解为两个子阶段。第一阶段的目标是基于坐标记录事件，这不会带来太多的开销，因此提供了良好的用户体验。第二阶段的目标是用相关的小部件信息来增加上一阶段记录的事件。具体来说，SARA 在记录设备上自动回放事件，并有效地识别交互下的小部件。第二阶段引入的额外开销对于测试人员来说是透明的。为此， SARA 能够基于坐标和小部件记录事件，同时保持良好的用户体验。

值得注意的是，自重放机制可以很容易地结合到现有的记录和重放工具中。例如，它可以在 Mobiplay 的录制阶段结束时添加这样 MobiPlay 录制的事件就会变得既协调又敏感。

4.3 自适应回放

尽管所有事件都被记录下来，动作事件甚至还添加了小部件信息，但在不同设备上重放动作事件仍然是一项具有挑战性的任务。主要原因如下。首先，一个应用程序的同一上下文中的视图层次结构通常在不同的设备上是不同的，特别是当层次结构中有可滚动的小部件时。可滚动小部件中的项目数量与屏幕大小密切相关。例如，在记录设备上的可滚动小部件中可能有 7 个可见项，但在屏幕较小的设备上只有前 5 个可见。其次，对于一些高级动作手势(如滑动)来说，窗口小部件信息仍然不足以实现准确的重放，因为滑动的轨迹也很重要，尤其是在绘图场景中。最后，UI 布局的破坏性改变偶尔会出现在不同的设备上。

针对这些问题，提出了一种自适应重放方法。特别地，SARA 通过启发式搜索小部件来回放事件，例如，自动滑动可滚动小部件，以及根据回放设备的屏幕参数转换坐标以适应不同设备上的布局。

5、实现

5.1 SARA 概述

为了记录和回放，SARA 采用了三段式操作。图 1 描述了 SARA 的工作流程。在记录阶段，SARA 记录所有输入数据，包括运动、按键和传感器输入，并将它们解析为事件。然后在自重放阶段，SARA 通过自重放用相关小部件数据来增强记录的事件。也就是说，SARA 自动回放记录设备上的事件，并标识交互下的小部件。最后，在重放阶段，SARA 会启发式地搜索 widget，并根据重放设备在重放期间的屏幕参数进行坐标转换。

图 1. SARA 的工作流

5.2 记录阶段

这个阶段的目标是精确地记录输入和两个连续输入之间的时间。SARA 通过由记录器和解析器组成的记录模块实现了这一目标。

记录器。记录器关注于捕获丰富的输入源。正如第 3.1 节所讨论的，SARA 通过应用动态仪器技术在应用层中记录输入数据。通常，Android 应用程序的输入可以分为三类，即动作、按键和传感器。下面，我们将描述 Recorder 如何在应用层中捕获三种类型的输入。

5.2.1 运动输入。Android 框架提供的服务向活动的应用程序交付运动输入。然后运动输入被分派从应用程序的视图层次结构的顶部开始，然后向下，直到它到达目标小部件。因此，为了拦截所有的运动输入，记录器动态仪器 dispatchTouchEvent 方法的活动，对话框，和视图在弹出窗口，记录输入的数据(例如，坐标，动作代码)和时间从这个阶段开始。注意记录仪在这个阶段记录基于坐标的运动输入。SARA 原则上能够识别各种动作手势，因为开发人员也可以在 dispatchTouchEvent 方法中识别它们。

5.2.2 关键输入。按键输入可以进一步分为物理按键输入(例如，返回，音量上升)和软键盘输入。与运动输入类似，记录仪通过动态测量活动和对话框的 dispatchKeyEvent 方法来截取物理按键输入，记录输入数据(如按键代码)和这个阶段开始的时间。相反，软键盘输入通常被传送到主动输入法。输入法然后通过进程间通信将输入传递给活动应用程序。具体来说，InputConnection 接口提供了一个从输入法到接收输入的应用程序的通信通道。因此，记录仪器开始批量编辑，并按照 InputConnection 的 formEditorAction 来记录软键盘输入数据(例如，输入内容，接收输入的文本视图)。注意，对于 WebView，记录器通过在网页中注册一个输入监听器来捕获关键的输入数据。

5.2.3 传感器输入。智能手机提供了比桌面/服务器机器更丰富的传感器集。可分为低级别传感器和高级别传感器。低级传感器包括加速度计、重力计、陀螺仪等。开发者可以通过覆盖 SensorEventListener 的 onSensorChanged 方法来检索实时的低级别传感器输入。因此，记录器截取方法 onSensorChanged 来记录低级传感器数据。对于像 GPS 这样的高级传感器，Android 提供了丰富的 api 来处理各种输入。例如，当 GPS/位置发生变化时，Android 框架会发送一个消息给 LocationListener 来通知应用程序。开发者能够通过覆盖 LocationListener 的 onLocationChanged 方法来处理位置的变化。因此，记录器也拦截 onLocationChanged 来记录位置数据。

解析器。应用程序层中的输入数据是高级的，这使得它很容易被解析为人类可读的事件。例如，两个连续的运动输入共享相同的坐标和用户按下时(或简称为停机时间)的时间，可以组合在一起。根据自停机时间以来所经过的时间，分组的输入可以被解析为一个 tap 或一个长 tap。特别是，Parser 遵循 Android 官方开发指南来解析运动输入、按键输入和传感器输入。我们将解析器的解析结果定义为事件，包括运动事件、输入事件和传感器事件。此外，当记录器记录从捕获输入时开始记录阶段的时间时，事件之间的时间可以由解析器精确计算。

5.3 自我修复阶段

这一阶段的目标是通过自我回放来增加相关小部件数据的运动事件。SARA 通过一个由候选识别器和复制器组成的自我复制模块来实现这个目标。算法 1 概述了这个阶段的过程。它将记录阶段的记录事件作为输入，并输出增强事件。

候选识别器。候选识别器负责识别交互下的小部件，并为每个小部件生成唯一标识符，以便在下面的重放阶段唯一地识别它们。在重放运动事件之前，候选识别器在应用程序的视图层次结构中识别候选小部件（第 5 行）。如果事件的坐标位于小部件的区域（由小部件的位置和大小决定），则将此小部件视为候选部件。候选的数量通常大于一个，因为小部件之间通常会发生重叠，并且视图层次结构缺乏重叠小部件的顺序。因此，为了确定性地识别交互下的小部件，候选识别器对每个候选执行一个仪器，以记录它是否接收到输入。接收运动输入的最后一个小部件被视为目标小部件（第 7 行）。一旦目标小部件被识别，候选识别器将为其生成唯一标识符（第 8 行）。特别是，候选识别器在视图层次结构中搜索最短的 xpath，以自下而上的方式唯一地标识目标小部件（第 16-29 行）。这个 xpath 最终作为小部件的标识符。

解析器。应用程序层中的输入数据是高级的，这使得它很容易被解析为人类可读的事件。例如，两个连续的运动输入共享相同的坐标和用户按下时(或简称为停机时间)的时间，可以组合在一起。根据自停机时间以来所经过的时间，分组的输入可以被解析为一个 tap 或一个长 tap。特别是，Parser 遵循官方的 Android 开发指南来解析运动输入、按键输入和传感器输入。我们将解析器的解析结果定义为事件，包括运动事件、输入事件和传感器事件。此外，事件之间的时间可以通过解析器精确计算，因为记录器记录了从捕获输入时开始记录阶段的时间。基于此假设，Replayer 动态检测 onSensorChanged 方法，并实时将读取的传感器数据替换为记录的数据。对于 GPS 等高级传感器输入，同样，Replayer 动态仪器 LocationListener 的 onLocationChanged，用记录的数据替换位置数据。因此，动态仪器技术使 SARA 能够在不需要自定义操作系统和源代码的情况下回放传感器输入，而这在现有的记录和回放工具中通常是必需的。

5.4 回放阶段

这一阶段的目标是在不同屏幕大小和操作系统版本的不同设备上重放事件。SARA 通过一个重放模块实现了这一目标，该模块由小部件识别器、坐标转换器和重放器组成。此模块中的 replay 与自重放模块中的 replay 相同。使重播模块与众不同的是，在这个重播阶段，运动事件是基于小部件和转换后的坐标重播的。算法 2 概述了这个阶段一个动作事件的重放过程。小部件识别器首先识别目标小部件(第 1 行)。如果小部件被成功识别，坐标转换器将根据屏幕大小和回放设备的像素密度转换相对于小部件的坐标。否则，坐标转换器将简单地转换相对于屏幕的坐标(第 2-5 行)。最后，Replayer 根据转换后的坐标执行事件(第 6 行)。

小部件识别器。小部件识别器负责识别小部件。具体来说，小部件识别器首先通过自重放阶段生成的唯一标识符识别视图层次结构中的目标小部件。当小部件识别器无法识别目标小部件时，它尝试通过在视图层次结构中自动滑动可滚动小部件来搜索小部件。

协调变压器。坐标转换器背后的基本思想是，它尽最大努力保持回放设备上的轨迹和运动距离(第 7-13 行)。具体来说，dpi(每英寸点)指的是屏幕上像素的物理密度。px2dp 将像素(px)转换为密度无关像素(dp)，这是 Android 中常用的距离单位，它保留了不同像素密度设备上的可见大小或距离。而过程 dp2px 则执行反向转换。

5.5 工具实现

SARA 是作为一个桌面应用程序实现的，它可以在 Windows 和 Linux 操作系统上运行。具体来说，SARA 的 Record 模块中的记录器主要是用一个跨平台的动态仪表工具包 Frida 来实现的，Frida 可以在不需要 root 访问的情况下对应用程序进行仪表化。自重播模块中的 Replayer 和重播模块主要是用 Android uiautomator2 和 Frida 的 python 包装器实现的。候选识别器和小部件识别器都严重依赖于视图层次结构，它是由 uiatuomator2 和 ADB 命令 ADB shell dump activity top 提取的。

6、实验结果讨论

RQ1. SARA 在同一台设备上记录和回放事件的效果如何?

SARA 用于在同一台设备上记录和回放每个常见的使用场景。为了建立基线，我们还评估了 appetizer 和 RERAN，这是研究报告中提到的最先进的 Android 记录和回放工具。我们不会评估其他最近提出的和公开可用的工具，如 Espresso 和 Culebra，因为它们要么需要应用程序的源代码，要么会带来大量的时间开销，这阻碍了我们对工业应用进行大规模的有效评估。开胃菜和重新运行记录输入都是通过读取/dev/input/event*文件中的日志。开胃菜的不同之处在于它不需要根访问，并且它支持在不同设备上重放事件。当且仅当外部可见状态相同时，我们认为重放是正确的，其中外部可见状态是用户所查看的 app 状态的子集。我们在重放阶段手动检查外部可见状态，以评估重放的正确性。对 Galaxy A8 设备进行了评估。需要根访问，它支持在不同的设备上重放事件。当且仅当外部可见状态相同时，我们认为重放是正确的，其中外部可见状态是用户所查看的 app 状态的子集。我们在重放阶段手动检查外部可见状态，以评估重放的正确性。对 Galaxy A8 设备进行了评估。

RQ2. SARA 在不同屏幕尺寸和操作系统版本的设备上回放事件的效果如何?

SARA 用于在同一台设备上记录和回放每个常见的使用场景。为了建立基线，我们还评估了 appetizer 和 RERAN，这是研究报告中提到的最先进的 Android 记录和回放工具。我们不会评估其他最近提出的和公开可用的工具，如 Espresso 和 Culebra，因为它们要么需要应用程序的源代码，要么会带来大量的时间开销，这阻碍了我们对工业应用进行大规模的有效评估。开胃菜和重新运行记录输入都是通过读取/dev/input/event*文件中的日志。开胃菜的不同之处在于它不需要根访问，并且它支持在不同设备上重放事件。当且仅当外部可见状态相同时，我们认为重放是正确的，其中外部可见状态是用户所查看的 app 状态的子集。我们在重放阶段手动检查外部可见状态，以评估重放的正确性。对 Galaxy A8 设备进行了评估。需要根访问，它支持在不同的设备上重放事件。当且仅当外部可见状态相同时，我们认为重放是正确的，其中外部可见状态是用户所查看的 app 状态的子集。我们在重放阶段手动检查外部可见状态，以评估重放的正确性。对 Galaxy A8 设备进行了评估。和三星 Galaxy A8，并在其余两款设备上回放事件。在不同屏幕尺寸的设备上，外部可见状态通常是不同的。因此，在本研究中，我们认为回放是正确的，当且仅当所有记录的事件在相应的小部件上按顺序触发。

RQ3. SARA 头顶上的时间和空间是多少？

我们通过在 36 个随机采样的场景中运行 SARA 来衡量 SARA 的时间和空间开销。具体来说，为了度量时间开销，我们首先记录一个场景的原始运行时。然后，我们分别在 SARA 的录制阶段和重放阶段比较该场景的运行时间。至于空间开销，我们测量在记录阶段生成的事件日志的大小和日志速率。对三星 Galaxy A8 设备进行了评估。

同一设备上记录和回放事件的有效性

表 1. 在同一设备上记录和回放事件的选定应用程序和评估结果的概述

表 1 为 SARA (SA.)的评价结果，开胃菜(ap.)和重播(RE.)在三星 Galaxy A8 上记录和重播场景。最后三列的表格单元格中的数字表示工具管理记录和回放的应用程序场景的数量。灰色背景的表格单元格表示与其他工具相比的最高值。SARA、appetizer 和 RERAN 在同一台设备上分别记录和回放了 265 个常用场景中的 86.0%、60.7%和 10.9%。很明显 SARA 获得了最好的表现。与其他工具相比，RERAN 的性能要低得多，因为它通常会在重播期间暂停，并产生错误消息，如无法打开/dev/input/event0，打开的文件太多。这是 RERAN 的一个众所周知的问题，但它的存储库中还没有补丁解决这个问题。至于 appetizer，它不能记录物理按键输入，例如，点击后退按钮，它通常会在回放过程中省略一些事件。

开发人员从微信不赞成仪器，他们关心的是仪表工具和应用程序之间的兼容性。但当我们显示在表中，SARA 和微信是兼容的，所有其他采样工业应用除了 Facebook，这在一定程度上缓解他们的担忧。

不同屏幕大小和操作系统版本的设备上回放事件的有效性

表 2 显示了采样后的 42 个场景，这些场景可以使用 SARA 和 appetizer 服务进行重玩。当在红米的 1s 上记录场景时，SARA 设法分别在 A8 星系和 A9 星系上重放了 41 和 34 个场景。appetizer 在 A8 星系上再现了 31 个场景。然而，appetizer 不支持在 Galaxy A9 上重放场景，因为 A9 与红米 1s 有不同的显示长宽比。当在 A8 星系上录制场景时，SARA 设法在红米 1 和 A9 星系上分别回放了 38 个和 32 个场景，而开胃菜设法在红米 1 上回放了 30 个场景。SARA 比开胃菜更有效地在两种评估设置的不同设备上重播场景。

表 2. 在不同屏幕尺寸和操作系统版本的设备上回放事件的评估结果

在评估过程中，我们发现在红米 1s 和 A8 星系上重演场景比在 A9 星系上要简单得多。尽管红米 1s 和 Galaxy A8 在 dpi 和屏幕尺寸上有所不同，但它们上的应用程序布局大致相同。因此，根据屏幕分辨率对记录坐标进行缩放在这两种设备上都能很好地工作。事实上，appetizer 非常依赖这种缩放技术来支持在多个设备上重放事件。与开胃菜不同的是，SARA 首先尝试搜索小部件，然后在执行运动事件之前转换相对于目标小部件的坐标，这使得它在处理重放阶段应用程序的状态差异时更加健壮。图 2 通过一个示例演示了 SARA 的健壮性。

当我们在 Galaxy A9 上回放事件时，我们发现 app 的布局通常与红米 1s 和 Galaxy A8 的布局不同，这说明在回放时，单纯的缩放记录坐标是容易出错的。识别交互下的小部件并基于它们进行坐标转换，可以在一定程度上解决这一问题。因此，SARA 设法重现了 A9 星系的大部分场景。

我们分析了在 A8 星系上记录的 10 个场景，SARA 在 A9 星系上没有回放。失败的主要原因是 SARA 未能在重放阶段的交互中识别正确的小部件。其中 7 个是因为 uiautomator2[6]提取的视图层次结构不准确。由于 SARA 严重依赖于视图层次结构来在自回放阶段找到候选窗口小部件，所以如果没有一个候选窗口小部件是正确的，它很难识别正确的窗口小部件。导致失败的其他因素包括布局的中断改变(如图 3 所示)，应用程序的不确定性状态(目标小部件并不总是在应用程序中显示)，以及在设备上执行滑动手势的 uiautomator2 问题。

7、总结

威胁：与大多数经验评价一样，与我们提出的结果相关的有效性既存在外部威胁，也存在建设性威胁。在外部有效性方面，我们的结果可能不会推广到其他工业应用程序和其他 Android 设备。我们只考虑 3 部真正的手机，53 部工业应用程序和 265，42 和 36 种常见的使用场景分别在 RQ1，RQ2 和 RQ3。这个限制是一个复杂的工件，涉及到计算场景、设置环境和记录不同设备上的场景。为了减轻这种威胁，我们对 GooglePlay 中每个类别下载量最高的顶级推荐应用程序进行了采样，并从 GooglePlay 中的描述和我们的动手体验中找出了场景。我们选择的三款真正的手机涵盖了在编写时使用最广泛的 Android 操作系统版本和屏幕大小。我们相信，考虑到广泛类别的高度流行的工业应用程序和我们选择的具有代表性的手机，SARA 也应该适用于其他工业应用程序和 Android 设备。在建设性的有效性方面，在实施 SARA 方面可能存在错误。为了减轻这种威胁，我们广泛地检查了评估结果。

限制：SARA 仍然有一些局限性。首先，混合应用(混合了本地和 web 技术的应用)在记录和回放基于小部件的事件时带来了转向挑战，因为一些小部件是由 WebView 渲染为 HTMLElements，在视图层次结构中无法找到。其次，游戏应用通常是用游戏引擎开发的(如 Unity)。游戏应用程序中的大多数小部件都是由游戏引擎渲染的，而且也不能在视图层次结构中找到，这使得 SARA 无法使用这些小部件。

扩展：微信是一款非常受欢迎的工业实力 Android 应用，每月活跃用户超过 10 亿。对可靠的记录和回放工具的要求与期望的功能，从微信开发人员是有价值的研究社区和行业，这促使我们设计和实现 SARA。虽然 SARA 的动机来自微信，但对 SARA 的收养并不局限于微信。我们期待着与工业伙伴合作，改善 SARA，并将 SARA 纳入他们的测试和维护过程。