Microsoft UI 自动化库与编码 UI 测试
我对测试自动化之类的东西非常陌生。最近，我被分配到一个项目，我必须编写一个应用程序（或者，可能是一个脚本，我不确定），该应用程序将自动执行类似 CAD 的 WPF 应用程序的 UI 测试，该应用程序缺少很多 AutomationId。
在 MSDN 和其他资源上进行了一些搜索后，我对是否应该使用 Microsoft UI Automation Library 还是 VS2010 中包含的新的 Coded UI Test 功能有点困惑。我不清楚这两者中的哪一个适用于哪些场景，其中一个相对于另一个有什么优势以及哪一个适合我的目的。
如果您对此事有经验/了解，请遮蔽一些光线。提前致谢。
I'm very much new to Test Automation kind of thing. Recently I've been assigned to a project where I have to write an application (or, a script may be, I'm not sure) that will automate the UI testing of a CAD-like WPF application which misses lots of AutomationIds.
After doing a little searching on MSDN and other sources I'm a bit confused about whether I should use the Microsoft UI Automation Library or the new Coded UI Test feature included in VS2010. I'm not getting the clear picture of which one of these two applies in which scenarios, what advantages one has over the other and which one suits my purpose.
Please shade some light if you have experience/knowledge on the matter. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
基本上，Microsoft UIA 是.Net 4.0 中的新辅助库。 WPF 应用程序和控件通过 AutomationPeer 类内置对 UIA 的支持。
编码 UI 测试是一个记录和测试播放自动化工具，使用底层的 Microsoft UIA 库。与用 C# 编写代码相比，它是一种工具，因此它可以提高 QA 生产力，记录更多测试用例。
对于计划支持自动化的应用程序，Coded-Ui 应该足够了。如果缺少 AutomationID，请确保控件具有一些唯一的属性，例如名称。使用 UIVerify 或 Inspect 来检查这一点。
如果没有可用的唯一属性，则可以将下面提到的其他技术与 Coded-UI 结合使用。
来自一个事件
当您的应用程序收到 UI Automation事件时，传递给事件处理程序的源对象是 AutomationElement。例如，如果您已订阅焦点更改事件，则传递给 AutomationFocusChangedEventHandler 的源是接收焦点的元素。有关详细信息，请参阅订阅 UI 自动化事件。
从一个点：
如果您有屏幕坐标（例如，光标位置），则可以使用静态 FromPoint 方法检索 AutomationElement。
从窗口句柄：
要从 HWND 检索 AutomationElement，请使用静态 FromHandle 方法。
从集中控制：
您可以从静态 FocusedElement 属性中检索代表焦点控件的 AutomationElement。
Basically Microsoft UIA is the new accesibility library in .Net 4.0. WPF applications and controls have built-in support for UIA through the AutomationPeer class.
Coded-UI test is a Record & Play automation tool which uses the Microsoft UIA Library underneath. Since being a tool compared to writing code in C# it improves QA productivity for recording more test cases.
For applications with automation support planned into it, Coded-Ui should be sufficient. If the AutomationIDs are missing make sure the controls have some unique property like Name. Use UIVerify or Inspect to check for this.
If NO unique property is avialble, there are the other below mentioned techniques you can use in combination with Coded-UI.
From an Event
When your application receives a UI Automation event, the source object passed to your event handler is an AutomationElement. For example, if you have subscribed to focus-changed events, the source passed to your AutomationFocusChangedEventHandler is the element that received the focus. For more information, see Subscribe to UI Automation Events.
From a Point:
If you have screen coordinates (for example, a cursor position), you can retrieve an AutomationElement by using the static FromPoint method.
From a Window Handle:
To retrieve an AutomationElement from an HWND, use the static FromHandle method.
From the Focused Control:
You can retrieve an AutomationElement that represents the focused control from the static FocusedElement property.
如果您可以利用和使用编码的 UI 测试然后走那条路。请务必验证您给定的配置是否受支持。
UI 自动化库解决了隐藏代码中的所有问题。然后，这迫使您使用像 UISpy 这样的工具来访问控件内部，以便您可以构建测试。
另一方面，编码的 UI 测试仍然有代码隐藏，但它允许记录您正在测试的给定应用程序的步骤，这将大大增加您可以创建的测试数量。
If you can leverage and use the Coded UI Test then go that route. Make sure to verify that your given configuration is supported.
The UI Automation Library resolves everything in the code behind. This then forces you to use a tool like UISpy to gain access to the controls internals so that you can then build out your test.
A Coded UI Test on the other hand still has code behind however it allows for the recording of steps through the given application which you are testing which will greatly increase the number of tests you can create.
UI自动化库是一个低级库。通常，您不想直接针对它编写测试，因为它需要相当多的工作。
我建议您查看更多高级库。您提到了其中之一 - 编码 UI；另一个不错的选择是来自 TestStack 的 White。它们都适合不同类型的项目。当您不想在测试套件中投入大量精力时，编码 UI 是很好的选择。同时，它的扩展性不大，因此如果您要编写大量测试，最好选择白色。
在这里，我更详细地比较了这两个框架：Coded UI 与 White
UI Automation library is a low-level library. Usually, you don't want to write tests against it directly as it requires a pretty decent amount of work.
I would recommend looking at more high-level libraries. You mentioned one of them - Coded UI; another good choice would be White from TestStack. They both suits different kinds of projects. Coded UI is good when you don't want to invest a lot of efforts into your test suite. At the same time, it doesn't scale much so if you are going to write a lot of tests, you are better of choosing White.
Here I compare the two frameworks in more detail: Coded UI vs White
为了补充上述回复，请查看 CUITE，它会很有帮助，并且可能是适合您的方法。
我开始使用 CodedUITest 库“滚动我自己的”“半框架”，并设计了一个将自动化细节与 (C#) 代码分离的范例。
基本上，我正在创建一个驱动程序，它从电子表格中读取需要完成的操作，其中的每一行都是一个测试步骤（或指向不同工作表中场景的指针）。
目前，虽然不完整，但很有希望，我让它在 WPF 应用程序上工作并取得了部分成功。
主要问题之一是开发人员忽视了唯一且一致地标识控件。
贝伊
To complement the above responses, please look at CUITE that helps quite a bit and may be an appropriate approach for you.
I began 'rolling-my-own' 'semi-framework' using the CodedUITest library and devised a paradigm for separating the details of automation from the (C#) code.
Basically, I am creating a driver that reads what needs to be done from spreadsheet(s) where each line in it is a test step (or a pointer to a scenario in a different worksheet).
At present, incomplete, but promising, I have it working against a WPF application with partial success.
One of the main problems is that the developers neglected to identify controls uniquely and consistently.
Bey