我不会尝试类似这样的重复问题:
Unit testing framework for a Swing UI
我想知道的是,是否有人对各种 Swing 单元测试库进行了很好的比较,例如:
- WindowTester Pro
- FEST
- 等等……
我们从未进行过任何 GUI 测试,因此我们不熟悉可能存在的问题。
提前致谢。
最佳答案
我在 Abbot 和 FEST 这两个用于 Swing UI 测试的开源库方面有相当不错的经验。
似乎不再支持 Abbot;这有点难以进入,因为记录器没有生成“足够好”的脚本。实际上,我已经使用记录器“学习”了脚本语言(XML 标签),最后我还是直接用一个简单的文本编辑器自己编写了脚本。这工作得很好。
FEST 采用另一种方法,您必须(在 Java 中)编写 UI 测试代码。这使它成为 Java 开发人员保留的工具,而 Abbot 可以供其他人使用(例如 QA 团队测试人员)。
这两种工具以及任何 UI 测试工具的主要问题是:
- 找到一种方法来唯一地标识组件,而不使用它们的位置或文本内容(这可能会从一个版本更改为另一个版本,或者难以在不同的
语言环境中测试相同的应用程序
) - 在脚本中使用正确的时间:这些测试工具可以比人类用户更快地运行您的 UI,因此您的 UI 可能对他们来说不够快(例如,可能需要几十毫秒打开一个对话框,甚至可以从数据库中填充一个表)
不过,对于这两个问题,都有解决方案。
对于组件识别,我强烈建议在 UI 中命名所有 Swing 组件(使用 Component.setName()
)并使用命名策略 ,这样可以确保永远不会有 2 个同名的组件同时可见。在 guts-gui图书馆,我什至开发了a strategy that automatically names Swing components以字段形式存储在面板中,这有助于在应用程序编码后添加组件名称。
对于脚本计时,两个框架在等待对话框出现时都接受超时值;考虑到您的测试可能在具有或多或少可用功率的不同类型的机器上运行的事实,您可以选择最佳值。您应该使用足够大的超时来确保脚本不会报告误报(例如,1 秒后出现的对话框,而脚本仅等待 500 毫秒),但也不能太长,以便当有一个真实的错误(例如,预期的对话框永远不会出现)。我建议使用 2 到 5 秒的超时,这应该适合大多数测试平台和大多数应用程序。
希望这会有所帮助。
关于java - Swing UI 测试库比较 : FEST, WindowTester Pro 等,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5939749/