UI 自动化和 WPF 的经验 [关闭]

Question

我们正在开发一个相当大的基于 WPF 的应用程序，并希望在我们的测试套件中包含一些自动化 UI 测试（其中已经包含许多单元测试）。

来自 Microsoft 的 UI Automation Framework 在某种程度上听起来非常适合在测试设置中以编程方式启动应用程序并与之交互。但是，我一直在努力寻找可靠的示例和技术经验参考，MSDN 上提供的文章和小示例不足以让我相信这是一个可靠的选择。

那么，有没有人有在他们的测试套件中使用 UI 自动化框架的实际经验？有哪些注意事项和陷阱？编写测试脚本时的任何最佳实践，您是否可以“记录并重播”为可编写脚本的格式，您应该在多大程度上促进应用程序的测试，您是如何将其合并到自动构建中的？我们是否应该转向 UI 自动化框架以外的其他方向？

随时在这里发布您的经验或链接到我可能错过的一些好的参考资料

Answer 1

在我工作的地方，我们刚刚开始为我们的系统评估一些测试工具。我们遇到了一个名为 white 的工具，它使用 UI 自动化框架。请注意，白色也有记录功能，尽管我认为它看起来有问题并且仍在开发中。

我们尝试将它们设置为看起来像单元测试，即[TestFixture] [Test] 等。 然后我们就可以在单元测试的同时通过 nunit 运行它们。

我们发现访问窗口中的某些组件可能很困难，但没有太多机会调查原因。

如果您不介意为软件付费，那么我会推荐TestComplete。

Answer 2

我正在对工作中的 WPF 应用程序进行 UI 自动化。我正在使用 White 和 IronRuby，效果很好。我在这里写下了我是如何做到的：http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

我们最初选择白色，然后远离它。它试图对 Win32 API、Winforms、Java 应用程序和 MS UI 自动化 API 进行通用和抽象。 MS UI 自动化 API 还试图在 win32 api、winforms 和 WPF 之上实现通用和抽象，因此您最终会陷入“最低公分母的最低公分母”场景。

这样做的结果是，White 元素搜索 API 根本不够灵活，无法找到我们需要查找的各种 UI 元素，并且它没有暴露足够多的底层 UI 自动化框架元素让我们做任何事情对它有用。

我们最终采用了一种本土的框架；我们直接使用 MS UIAutomation 框架，但有扩展方法和辅助类来处理它没有解决的场景。 （主要是键盘和鼠标输入）。

注意：我们的测试脚本和自制框架都使用 IronRuby。 Ruby 向现有类添加方法的能力和灵活的语法（与 method_missing 相结合）非常适合这种事情。