Microsoft自动化框架是否处理Java、C++、Delphi或我应该使用OCR？
我在AutoIT和windows自动化方面已经工作了03年多了，但主要是在WinForms上。AutoIT不适用于WPF或Java。我使用过一些白色框架。我想编写一个用于测试和第03方UI自动化的通用应用程序，向该应用程序传递一个xml，其中包含窗口标题、窗口文本、UI控件-文本和操作(右击或左击)--完全类似于AutoIT控件--单击函数，并由它执行操作。
我的要求是，它应该适用于所有的windows桌面应用程序(无论它们是用C、C++、.Net Winforms、.Net WPF、Silver、Java、Delphi、Qt等语言编写的)。最终用户将是我们的操作或测试团队(谁将无法编码)。我应该采取什么方法？
- Microsoft自动化框架是否支持所有类型的windows UI自动化？
- White框架是否比Microsoft UI自动化更好(我在内部检查过- White也使用了Rhino)？
- 我是否应该编写自己的库，使用OCR来检测控件(就像人类用户所做的那样)？使用OCR姿势会有什么缺点？
问候Akshay Mishra
回答 3
Stack Overflow用户
发布于 2013-04-30 12:19:54
UI自动化框架处理任何使用(或映射到)本机windows控件的操作，这是Java的SWT、C++的大部分小部件工具包和Delphi的VCL表单的情况，它还与其他工具箱一起工作，这些工具箱提供自己的控件，但为了可访问性而公开它们的接口(我认为Java的swing就是这种情况)。
White在内部使用UI自动化框架，因此理论上它可以处理自动化框架所能处理的任何事情。
使用OCR将是很多工作，而且结果可能不会很好，所以如果您正在.NET或UI自动化框架的COM对象中编码，则应该使用White，因为没有任何东西可以轻松使用，或者与自动化框架这样的大量接口类型一起工作(至少我还没有找到任何其他东西)。
Stack Overflow用户
发布于 2012-04-23 18:52:20
如果它们是您正在使用的专业应用程序，那么它们很可能会公开某种形式的可访问性框架。这些对于自动化是非常有用的，我肯定会进行调查。
如果您想要一个完全可靠的系统，很可能您必须为每个框架编写类似的自动化代码，然后有一个正在使用的检测机制。这是很多代码，但大多数代码都已经存在了。
正如你提到的，OCR是另一种选择。这几乎是一个廉价的黑客，而不是一个好的解决方案，所以我建议记住它作为一个后备选择。AutoIt很好地涵盖了OCR，在公共库中有几个包装器。我可以想象一个有趣的例子是莫迪，您必须看看它是否允许您获得文本的坐标以及文本本身。
或者，如果字体将是默认的系统字体，或者您知道它将是什么字体，您不一定需要使用OCR，而是可以搜索字体的图像。如果你有很多看上去都一样的按钮，也许值得一看。
Stack Overflow用户
发布于 2016-06-29 12:35:30
VS 2016中的编码UI测试不支持Java
只有本地窗口元素可以被Automation看到(窗口，标题栏.)而窗口的内部内容不被识别(JEdit，JCombobox.)
因此，MTM使用来自本机元素的坐标(检查SQA.stackexchange上的问题)记录测试。
https://stackoverflow.com/questions/10279569
复制相似问题
腾讯云开发者
