摘要

无论是在平板电脑、智能手机还是桌面平台上运行，图形用户界面（GUI）都是当今应用程序的重要组成部分。由于 GUI 通常是人类交互的唯一组件，因此它要求进行彻底的测试，以确保高效和令人满意的用户体验。作为几乎所有应用程序组件之间的粘合剂，GUI 还可以用于系统级测试。但是，GUI 测试本质上是困难的，并且即使使用保证自动化的现代工具，也通常需要大量的体力劳动。本文介绍了一个名为 GUITest 的 Java 库，它允许为复杂的应用程序生成完全自动化的 GUI 健壮性测试，而无需手动生成模型或输入序列。我们将解释它的运行方式，并在对 Microsoft Word 进行测试的过程中首先展示其适用性和有效性。

关键词

GUI 测试、自动化测试、健壮性测试

一 导言

图形用户界面（GUI）代表了软件组件与其最终用户之间的主要连接点，几乎可以在所有现代应用程序中找到。供应商努力构建更直观和高效的界面，以保证更好的用户体验，使其功能更强大，但同时也更复杂。尤其是自从智能手机和平板电脑的兴起，这种复杂性已经达到了一个新的级别，并威胁到了应用程序在 GUI 级别的有效可测试性。为了应对这一挑战，使测试过程自动化是很有必要的。

捕获和重放（CR）工具有望在图形用户界面级别实现自动化测试。然而，它们一直都是有争议的，因为它们需要测试人员进行大量的手动操作，他们仍然需要记录和维护输入序列。尤其是在频繁更改 GUI 的情况下，CR 工具会产生很高的维护成本。尽管 CR 方法有缺点，但它是有价值的，因为测试用例是由具有领域知识的人生成的。但是，当今的 GUI 的复杂性，与测试它们相关的体力劳动以及随之而来的维护成本，要求一种具有真正自动测试环境的补充方法。在这种环境下，测试用例的生成、执行和评估应该在没有人为干预的情况下进行。这是相当困难的，因为 GUI 是为人类而不是为程序设计的。程序需要以编程方式访问 GUI 的状态，以便能够以点击、击键和手势的形式模拟人类的行为。因此，我们开发了 GUITest，这是一个 Java 库，它允许为复杂的图形应用程序编写自动化的健壮性测试。在下面，我们将解释 GUITest 是如何工作的，它与现有的工具和库有何区别，以及它在涉及复杂的非 Java 桌面应用程序的第一次测试中是如何执行的。

二 方法

图 1 可视化了一个人在使用图形用户界面时所经历的基本过程。在图（a）中，我们可以看到一个带有相应图标的手机应用程序面板。仅仅通过观察屏幕，大多数人就直观地知道哪些动作可以在这种特定的状态下执行。例如，可以轻触五个应用程序项中的一个，或向左或向右滑动以显示其他项。如果用户单击左下角的项目（b），浏览器应用程序将启动（c），提供多种操作可供选择（d）。例如，在点击搜索字段之后，会出现一个虚拟键盘（e），然后他必须再次决定执行哪个操作。通过重复这个过程，可以生成任意的输入序列，从而驱动 GUI。

为了让程序以类似的方式驱动 GUI，有必要收集关于 GUI 状态的足够信息，GUI 状态构成了其小部件的状态（即控制元件）。为了能够执行合理的操作，它需要确定在特定状态下可见的所有小部件的类型、位置、大小和其他属性。GUITest 可以以小部件树的形式确定被测系统（SUT）的当前 GUI 状态。窗口小部件树是当前在屏幕上可见的窗口小部件的分层组合，以及相关窗口小部件属性的值。图 2 显示了这样一个图片树（a）的示例。有了这些信息，一个自动测试程序可以计算出合理的默认操作：可以点击启用的按钮、图标和超链接，可以点击文本字段并填充文本，可以拖动屏幕、滚动条和滑块等。GUITest 允许模拟简单的操作（点击，按键）以及复杂的操作（拖放操作、手写和其他手势等），因此甚至可以驱动复杂的 GUI。表 1 列出了 GUITest 的一些特性。

三 第一次测验

为了评估 GUITest 的功能，我们为 microsoft word for mac 实现了一个健壮性测试。其目标是开发一个程序，生成随机输入序列并自动检测 SUT 的崩溃。如果 a）SUT 意外终止或者 b）GUI 在超过 60 秒的时间内没有响应输入，我们认为 SUT 已经崩溃。我们利用 GUITest 的功能编写了一个完全自动化的测试，无需监督。因此我们不得不

提供 Word 可执行文件的名称及其配置文件的位置：在每次执行 Word 之前，需要还原配置文件，以确保序列生成和回放期间的相同启动条件。如果这些条件不同（例如，由于上次运行更改了“选项”对话框中的值），则可能无法重播崩溃序列。定义要执行的操作集：如前所述，GUITest 已经为大多数小部件派生了默认操作。但是，可能需要包括其他操作，比如将剪贴画符号拖到文档中（参见图 3）。可能还需要禁止某些操作，例如：在初始测试期间，程序执行系统菜单中的“关机”和“重新启动”菜单项，从而终止整个机器。在文件对话框的上下文中出现的其他问题：在这些对话框中，程序可以创建、删除或移动文件，这可能会导致严重损坏，具体取决于它在文件系统中浏览的位置。打印对话框等也应小心处理。图 3 显示了可以执行的典型操作以及我们故意不允许的某些小部件（注意打印、保存和打开工具项以及 Apple 和“Word”菜单项）。最后，我们在一个具有更严格访问权限的专用用户帐户中运行该程序，以防止潜在的损害。

为了能够重播崩溃运行，我们将生成的序列的长度限制为 200 个操作。每次运行之后，测试程序都会停止 SUT，保存序列（如果它导致崩溃），恢复配置文件，重新启动 SUT 并继续生成下一个测试用例。我们总共编写了四个 Java 类文件，总共 314 个 LOC。自动测试运行了 18 小时，产生了 672 个序列。其中 9 个序列导致 Microsoft Word 崩溃并显示错误消息。我们能够重放其中的六个。然而，有三个很难重放，因为重放期间的计时起了重要作用：在一些运行期间，一个序列使 SUT 崩溃，而在另一些运行期间，SUT 通过时没有任何问题。我们认为这与难以控制的外部因素（内存消耗、处理器利用率、线程调度…）有关。我们目前正在努力改进序列回放，并正在考虑使用一个虚拟机更好地控制这些条件。另一个选择是视频记录整个测试过程，这将使序列回放不再必要。

四 其他工具和技术

有各种工具可用于 GUI 测试，包括商业、开源和科学产品。其中很大一部分属于捕获和重播（CR）或脚本类别。流行的商业工具是 eggPlant，TestComplete，QF-test。开源工具包括 Abbot、Selenium 和 SWTBot。如前所述，这些工具通常会导致大量的手工劳动，特别是当一个 GUI 经常发生变化，从而导致记录的测试用例中断并需要修复时。然而，由于测试用例是由人工记录的（可能对 SUT 有很好的了解），因此它们非常有效。

在 GUI 测试方面，有一些比 CR 方法更自动化的科学方法：在 Atif Memon 领导下开发的 GUITest 框架中实现了一个有趣的方法。他们的想法是遍历 GUI（通过系统地单击 widgets）并自动生成一个模型（以事件流图的形式），通过应用几个覆盖率标准从中派生测试用例。[4] 概述他们的工作。不幸的是，在他们的实验中，他们只测试小型 Java 应用程序（其中一些是合成的，一些是学生开发的小型办公套件的一部分），这些应用程序只通过执行单击来执行。它们在执行序列时有问题，因为它们来自的 GUI 模型是一个近似值。因此，它们生成短序列（3 到 20 个动作），然后应用遗传算法自动修复。

Artzi 等人为 JavaScript web 应用程序执行反馈导向的随机测试用例生成。他们的目标是找到具有高代码覆盖率的测试套件，以及显示编程错误（如无效的 html 或运行时异常）的序列。他们开发了一个名为 Artemis 的框架，该框架通过调用适当的处理程序方法并为它们提供必要的参数来触发事件。为了指导他们的搜索，他们使用优先级函数：他们随机选择事件处理程序，但更喜欢那些在过去的序列中只实现了低分支覆盖率的事件处理程序。

Marchetto 和 Tonella 使用元启发式算法为 AJAX 应用程序生成测试套件。它们执行应用程序以获得有限状态机。此计算机中的状态是应用程序的 DOM 树（文档对象模型）的实例，转换是事件（来自服务器/用户输入的消息）。从这个 FSM 中，他们计算出语义交互事件的集合。目标是生成具有最大多样事件交互序列的测试套件，即每对连续事件在语义上相互作用的序列。

我们的方法的优点是，它可以与大型的本机应用程序一起工作，它可以使用复杂的操作驱动这些应用程序。上述方法要么调用事件处理程序（不适用于许多 GUI 技术），要么只执行简单的操作（单击）。此外，我们的技术既不需要人工劳动（生成输入序列或模型），也不需要对 SUT 的源代码进行检测。虽然对于[4]中提出的方法也是如此，但它们只生成短序列，其中许多序列是无效的。因此，这些序列需要修复，根据作者的说法，可能需要几天甚至几周的时间。最后，所提出的技术具有非常低的维护成本，因为即使 GUI 发生更改，测试也将继续工作。然而，我们知道，目前我们的方法非常简单（随机操作选择），只适合于查找导致崩溃的严重故障。它可能受益于上述方法的想法，反之亦然。

五 结论和今后的工作

在本文中，我们介绍了 Microsoft Word 的健壮性测试，该测试是在 GUI 测试库 GUITest 的帮助下实现的。 尽管此测试非常简单，但结果还是很有希望的，并且表明了该方法的适用性，甚至适用于具有复杂接口的大规模 GUI 应用程序。 将来，我们将重点关注以下几个方面：

更复杂的操作选择：我们计划应用机器学习技术和元启发式方法来查找更可能导致 SUT 崩溃的序列（例如，消耗大量内存或执行时间较长的序列）。在早期的工作中我们提出了一些关于这如何工作的想法。细粒度的预言：我们将努力发现除崩溃以外的故障。重点是学习如何区分正确和错误行为的自动化技术。其他 GUI 技术：目前，GUITest 只支持在 MacOSX 下运行的应用程序。我们已经对其他平台进行了可行性研究，并在未来计划中支持 Windows。我们还考虑在平板电脑或智能手机平台上实施这种方法。致谢

本文由南京大学软件学院 2020 级硕士生李彤宇翻译转述。 感谢国家重点研发计划（2018YFB1003900）和国家自然科学基金（61832009，61932012）支持！