Swing UI测试库比较：FEST，WindowTester Pro等

我对Abbot和FEST有一些相当好的经验，这两个库都是用于Swing UI测试的开源库。

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

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

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

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

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

对于组件标识，我强烈建议在 UI 中命名所有 Swing 组件（使用 ），并为此使用命名策略，这可以确保永远不会有 2 个具有相同名称的组件同时可见。在 guts-gui 库中，我甚至开发了一种策略，可以自动命名存储在面板中的字段的 Swing 组件，这有助于在对应用程序进行编码后添加组件名称。Component.setName()

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

希望这有帮助。

Jemmy为UI测试提供了相当不错的功能。虽然，对于 JUnit 测试来说，它不是一个开箱即用的解决方案，但它可以很容易地扩展以适合您的目的。

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

它是一个开源项目（在CDDL下授权），并且正在积极开发中。

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