为什么 Inspect.exe 经常挂起并且不一致地显示 AutomationId？
Why does Inspect.exe hang frequently and inconsistently display AutomationId?
我正在尝试使用 MS UI Automation 来测试 WPF 应用程序，并且正在使用 Windows SDK 中包含的检查对象工具 (inspect.exe) 来查找某些元素上的 AutomationId 属性。
Inspect 对我来说表现得很奇怪：
如果我关闭所有应用程序并启动 WPF 应用程序和检查，检查能够看到各种 UI 元素的 AutomationId 属性。没有 AutomationId 的元素仅显示两个引号，表示空字符串 ("")。
在 WPF 应用程序中执行一些操作后，inspect.exe 挂起，我必须终止它并重新启动它。尽管机器的 CPU 和 RAM 利用率大约为 50% 或更少，但我已经尝试等待几分钟——有几次可能接近 20 或 30 分钟——但无济于事。
- 重新启动后，inspect.exe 无法再找到任何 UI 元素的 AutomationId，即使是那些以前有它们的元素。更重要的是，将鼠标悬停在 WPF 应用程序上时 属性 完全消失了——它根本不再列出，甚至没有空字符串值。
- 如果我将鼠标移动到另一个屏幕（具体来说，移动到另一台计算机，使用 Mouse Without Borders），AutomationId 属性 会重新出现，其值为 "FormDot"
- 如果我在 WPF 应用程序仍然 运行 时仅重新启动 inspect 额外次数，则 inspect 的行为与第一次重启后的行为相同。
- 如果我在检查仍然 运行 时仅重新启动 WPF 应用程序，检查的行为仍然与第一次重新启动后相同。
- 如果我同时关闭 inspect 和 WPF 应用程序，然后启动 inspect，然后启动 WPF 应用程序，一切都会正常工作一段时间，并且 inspect 在 WPF 应用程序的几个元素上找到 AutomationId ...直到检查再次挂起的点。
我已经尝试 运行 按照 中的建议以正常方式和以管理员身份进行检查，两种方式的行为都相同。
如果有的话，我做错了什么？我是不是太不耐烦了，我是否需要等待很长时间而不是假设检查已挂起？为什么 inspect 关于 AutomationId 的行为会有所不同？
Inspect.exe 有多个版本。据我所知，最新版本是 2012 年的版本，在 help/about 对话框中显示版本 7.2.0.0。
旧版左侧没有树视图，所有检测到的自动化元素都显示在树中，因此很容易检查您使用的是正确的。
最新的一个工作得很好，但是恕我直言，迄今为止使用 UI 自动化的最佳工具是 Visual UI Automation Verify。这是一个 .NET 程序，他的源代码可以在这里找到：
UI 自动化验证（UIA 验证）测试自动化框架.
请注意，虽然它是一个 .NET 程序，但它不使用标准的 .NET 自动化 dll（更多信息请参见此处：）。
关于 AutomationId 属性，为了澄清我对问题的初步评论，我的意思是它的用处取决于您尝试自动化的程序。
如果您作为开发人员拥有它，那显然很有趣。例如，如果您正在使用 WPF，则可以使用 x:Uid 属性，这显然意味着 UI 自动化。在 Winforms space 中，它也非常有用，因为 UI Automation 将使用控件的 AccessibleName by default and revert to the Name 作为 AutomationId 值的后备。
但是有很多应用程序不依赖于 .NET（浏览器、本机应用程序等）。通常，对于这些应用程序，使用其他属性会更容易。
我在 Microsoft Surface Studio PC 上使用 inspect.exe 有一段时间了（运行 Windows 10），我的经验是 inspect.exe 会挂很多当 Windows 更新挂起时更频繁（有时总是）。当更新停止时，inspect.exe 仍然有些慢，但更稳定。
我正在尝试使用 MS UI Automation 来测试 WPF 应用程序，并且正在使用 Windows SDK 中包含的检查对象工具 (inspect.exe) 来查找某些元素上的 AutomationId 属性。
Inspect 对我来说表现得很奇怪：
如果我关闭所有应用程序并启动 WPF 应用程序和检查，检查能够看到各种 UI 元素的 AutomationId 属性。没有 AutomationId 的元素仅显示两个引号，表示空字符串 ("")。
在 WPF 应用程序中执行一些操作后，inspect.exe 挂起，我必须终止它并重新启动它。尽管机器的 CPU 和 RAM 利用率大约为 50% 或更少，但我已经尝试等待几分钟——有几次可能接近 20 或 30 分钟——但无济于事。
- 重新启动后，inspect.exe 无法再找到任何 UI 元素的 AutomationId，即使是那些以前有它们的元素。更重要的是，将鼠标悬停在 WPF 应用程序上时 属性 完全消失了——它根本不再列出，甚至没有空字符串值。
- 如果我将鼠标移动到另一个屏幕（具体来说，移动到另一台计算机，使用 Mouse Without Borders），AutomationId 属性 会重新出现，其值为 "FormDot"
- 如果我在 WPF 应用程序仍然 运行 时仅重新启动 inspect 额外次数，则 inspect 的行为与第一次重启后的行为相同。
- 如果我在检查仍然 运行 时仅重新启动 WPF 应用程序，检查的行为仍然与第一次重新启动后相同。
- 如果我同时关闭 inspect 和 WPF 应用程序，然后启动 inspect，然后启动 WPF 应用程序，一切都会正常工作一段时间，并且 inspect 在 WPF 应用程序的几个元素上找到 AutomationId ...直到检查再次挂起的点。
我已经尝试 运行 按照 中的建议以正常方式和以管理员身份进行检查，两种方式的行为都相同。
如果有的话，我做错了什么？我是不是太不耐烦了，我是否需要等待很长时间而不是假设检查已挂起？为什么 inspect 关于 AutomationId 的行为会有所不同？
Inspect.exe 有多个版本。据我所知，最新版本是 2012 年的版本，在 help/about 对话框中显示版本 7.2.0.0。
旧版左侧没有树视图，所有检测到的自动化元素都显示在树中，因此很容易检查您使用的是正确的。
最新的一个工作得很好，但是恕我直言，迄今为止使用 UI 自动化的最佳工具是 Visual UI Automation Verify。这是一个 .NET 程序，他的源代码可以在这里找到： UI 自动化验证（UIA 验证）测试自动化框架.
请注意，虽然它是一个 .NET 程序，但它不使用标准的 .NET 自动化 dll（更多信息请参见此处：
关于 AutomationId 属性，为了澄清我对问题的初步评论，我的意思是它的用处取决于您尝试自动化的程序。
如果您作为开发人员拥有它，那显然很有趣。例如，如果您正在使用 WPF，则可以使用 x:Uid 属性，这显然意味着 UI 自动化。在 Winforms space 中，它也非常有用，因为 UI Automation 将使用控件的 AccessibleName by default and revert to the Name 作为 AutomationId 值的后备。
但是有很多应用程序不依赖于 .NET（浏览器、本机应用程序等）。通常，对于这些应用程序，使用其他属性会更容易。
我在 Microsoft Surface Studio PC 上使用 inspect.exe 有一段时间了（运行 Windows 10），我的经验是 inspect.exe 会挂很多当 Windows 更新挂起时更频繁（有时总是）。当更新停止时，inspect.exe 仍然有些慢，但更稳定。