4

我从事 AutoIT 和 windows 自动化工作超过 03 年，但主要是在 WinForms 上。AutoIT 不适用于 WPF 或 Java SWT UI。我已经使用了一点白色框架。我想编写一个用于测试和 03rd 方 UI 自动化的通用应用程序，我将一个带有窗口标题、窗口文本、UI 控件文本和操作（右键或左键）列表的 xml 传递给它——就像 AutoIT 控件一样-click 函数并执行该操作。

我的要求是它应该适用于所有 Windows 桌面应用程序（无论它们是用 C、C++、.Net Winforms、.Net WPF、Silver-light、Java、Delphi、Qt 还是任何东西编写的）。最终用户将是我们的运营或测试团队（他们将无法编码）。我应该采取什么方法？

  1. Microsoft UI 自动化框架是否支持所有类型的 Windows UI 自动化？
  2. White 框架是否比 Microsoft UI 自动化更好（我检查过 - White 在内部也使用 Rhino）？
  3. 我是否应该编写自己的库来使用 OCR 来检测控件（与人类用户一样）？使用 OCR 会带来什么缺点？

问候 Akshay Mishra

4

3 回答 3

4

UI 自动化框架处理任何使用（或映射到）本机 Windows 控件的东西，Java 的 SWT、大多数 C++ 的小部件工具包和 Delphi 的 VCL 表单就是这种情况，它也可以与呈现自己的控件但公开其界面的其他工具包一起使用出于可访问性目的（我认为 Java 的摇摆就是这种情况）。

White 在内部使用 UI 自动化框架，因此理论上它可以处理自动化框架可以处理的任何事情。

使用 OCR 会做很多工作，而且结果可能不会很好，所以如果你在 .NET 或 UI 自动化框架的 COM 对象中编码，你应该使用 White，因为没有什么比它更容易使用或有效的了具有如此多的接口类型，例如自动化框架（至少我还没有找到其他任何东西）。

于 2013-04-30T12:19:54.710 回答
1

如果它们是您正在使用的专业应用程序，那么它们很可能会公开某种形式的可访问性框架。这些对于自动化非常有用，我肯定会进行调查。

如果您想要一个完全可靠的系统，您可能必须为每个框架编写类似的自动化代码，然后拥有一个正在使用的检测机制。这是很多代码，但其中大部分已经存在。

正如您所提到的，OCR 是另一种选择。这几乎感觉像是一种廉价的黑客攻击，而不是一个好的解决方案，所以我建议将其作为后备选项牢记在心。AutoIt 很好地涵盖了 OCR，并带有几个围绕公共库的包装器。我想感兴趣的是MODI，你必须看看它是否允许你获取文本的坐标以及文本本身。

或者，如果字体将成为默认系统字体，或者您知道它将是什么字体，则不一定需要使用 OCR，而是可以搜索字体的图像。如果您有很多看起来都一样的按钮，可能值得一看。

于 2012-04-23T18:52:20.830 回答
1

VS 2016 中的 Coded UI 测试不支持 Java GUI

Automation FW（窗口，标题栏...）只能看到本机窗口元素，并且无法识别窗口的内部内容（JEdit，JCombobox ...）

因此，MTM 使用来自本机元素的坐标记录测试（检查 SQA.stackexchange 上的问题）

于 2016-06-29T12:35:30.623 回答