Swing UI 测试库比较：FEST、WindowTester Pro 等答案

【问题标题】：Swing UI Testing Library Comparisons: FEST, WindowTester Pro, etcSwing UI 测试库比较：FEST、WindowTester Pro 等
【发布时间】：2011-08-21 20:05:28
【问题描述】：

我不会尝试类似这样的重复问题：

Unit testing framework for a Swing UI

我想知道的是，是否有人对各种 Swing 单元测试库进行了很好的比较，例如：

WindowTester Pro
FEST
等等……

我们从未进行过任何 GUI 测试，因此我们不熟悉可能存在的问题。

提前致谢。

【问题讨论】：

我从未使用过 FEST，这就是为什么这不是答案，但我使用了多个 GUI 测试工具，目前正在使用 WindowTester Pro。第一个问题是您的组件需要命名。除非您的 GUI 是自动为您“编写”的，否则情况可能并非如此。这不是世界末日，但在大型代码库上可能会很麻烦。我们发现的另一个问题是有一些边缘情况并不像您希望的那样优雅，例如在组件上模拟某些键/鼠标事件。
@pickypg：谢谢。这很有帮助！
FEST 对我来说效果很好，我没有使用过其他的。唯一的复杂性可能是正确查询控件（从组件读取但在 EDT 之外读取是错误的）。
我不久前对 UI 测试工具进行了比较，其中大部分归结为能够访问 Swing 应用程序并访问各个组件。因此，如果您的应用程序编写得很好，那么在比较中屡获殊荣的好工具就是您要使用的工具。如果应用程序写得不好，开源对于编写良好的应用程序来说已经足够了，一些商业工具可能能够应付它。
你知道 ReTest (retest.de/en) 吗？这是一种相对较新的 Swing 测试工具，结合了基于 AI 的猴子测试的新颖方法。

标签： java unit-testing swing user-interface

【解决方案1】：

我在 Abbot 和 FEST 这两个用于 Swing UI 测试的开源库方面有相当不错的经验。

似乎不再支持 Abbot；这有点难以进入，因为记录器没有生成“足够好”的脚本。实际上，我已经使用记录器“学习”了脚本语言（XML 标签），最后我自己用一个简单的文本编辑器直接编写了脚本。这工作得很好。

FEST 采用另一种方法，您必须（在 Java 中）编写 UI 测试代码。这使它成为为 Java 开发人员保留的工具，而 Abbot 可供其他人（例如 QA 团队测试人员）使用。

这两种工具以及任何 UI 测试工具的主要问题是：

找到一种方法来唯一地标识组件，而不使用它们的位置或文本内容（这可能会从一个版本更改为另一个版本，或者难以在不同的Locale 中测试相同的应用程序）
在脚本中使用正确的时间：这些测试工具可以比人类用户更快地运行您的 UI，因此您的 UI 可能对他们来说不够快（例如，可能需要几十毫秒打开一个对话框，甚至可以从数据库中填充一个表）

不过，对于这两个问题，都有解决方案。

对于组件识别，我强烈建议在 UI 中命名所有 Swing 组件（使用Component.setName()）并为此使用命名策略，这样可以确保永远不会有 2 个同名的组件同时可见。在guts-gui 库中，我什至开发了a strategy that automatically names Swing components，它作为字段存储在面板中，这有助于在应用程序编码后添加组件名称。

对于脚本计时，两个框架在等待对话框出现时都接受超时值；考虑到您的测试可能在具有或多或少可用功率的不同类型的机器上运行的事实，您可以选择最佳值。您应该使用足够大的超时时间以确保脚本不会报告误报（例如 1 秒后出现的对话框，而脚本仅等待 500 毫秒），但也不能太长，以便当有一个真实的错误（例如，预期的对话框永远不会出现）。我建议使用 2 到 5 秒的超时，这应该适合大多数测试平台和大多数应用程序。

希望这会有所帮助。

【讨论】：

这些都是好点。听上去，Abbot 不再活跃有点糟糕，因为它听起来像是首选工具。
当然，但好在 FEST 在很大程度上受到了 Abbot 的启发，我认为在 FEST 中使用了 Abbot 源代码的某些部分（至少在初始版本中）。此外，我知道 Alex Ruiz（FEST 负责人）有一个开发录音机的计划，但我不确定这方面是否取得了任何进展。
到目前为止，最烦人的问题是与超时相关的竞争条件，尤其是当您尝试快速运行测试时。只有一个缺失的解释：通常，您的测试代码中有一系列超时，因此，当您增加一个超时时，您也必须在链中增加其他超时。这是非常难以管理的。理论上是错误的！如果可能的话，您应该将 GUI 工作封装在 SwingWorker(s) 中，这将在工作完成时传播通知。但这需要一种从一开始就考虑 GUI 测试的编码风格......而没有人这样做。

【解决方案2】：

Jemmy 为 UI 测试提供了相当不错的功能。虽然它不是 JUnit 测试的开箱即用解决方案，但它可以轻松扩展以满足您的目的。

我不确定其他 UI 测试工具，但与 RFT 相比，它为您提供了实际 UI 对象的句柄（RFT 返回一个代理对象）。根据我的经验，这可能很方便。

这是一个开源项目（在 CDDL 下获得许可）并且正在积极开发中。

我认为其他流行的（或曾经是？？）是 jfcUnit。虽然我不认为这是在积极开发中。

【讨论】：

【解决方案3】：

有很多因素需要考虑。录制/重放、单元测试支持、代码更改的性质、许可、成本、多平台支持、具有多种外观和感觉的测试、支持 i18n 测试……您的列表是什么样的？

关于我们使用的工具的一些 cmets。

IBM Rational Functional Tester：

这具有录制脚本和回放的能力。它支持验证点。最大的优点之一是不需要更改代码。 RFT 修改 JVM 并使用 java 可访问性扩展来记录和测试。我们主要将它用于 Java（带有大量 2D 和对话框操作的 Swing/awt）。它也适用于浏览器。

RFT 公开了两种识别 GUI 元素的机制。一种使用对象图。这非常弱，并且在长期可维护性方面存在问题。使用“查找”API 对程序员更友好，尽管它需要更改代码。拥有正确名称的所有对象也有帮助。

根本不适合单元测试。

适用于 Windows 和 Linux。

非常昂贵的浮动许可证在 12000 美元范围内，固定许可证将花费一半。所有节点（记录测试和运行测试）都需要许可证。定价是近似的和旧的，但它会给出一个想法。

需要真正的 GUI 会话，在 Windows 上。（在带有 VNC 的 linux 上可能没问题）

杰米：我们转移到 jemmy 进行新的测试。支持windows、linux。它曾经是免费的，不知道甲骨文对此有何打算。我们在 jemmy 之上添加了我们的测试层——用于断言和其他验证机制。这个关于“jemmy testing toolkit”的演讲有更多关于jemmy的细节。

【讨论】：

“固定将大约一半”？

【解决方案4】：

2012 年@AlexRuiz，FEST 背后的主要开发者决定stop development of FEST

FEST 代码库后来被分叉成AssertJ-Swing。

跳过 FEST 并从 AssertJ-Swing 开始。

【讨论】：

【解决方案5】：

您可能想试试Swing Testing Toolkit。它使用不同的方法：它不记录所有事件。测试说明减少到最低限度。

【讨论】：