c# - 线程的编码 UI 测试问题/定期执行重复操作

Question

我在一个用 VB 构建的系统中进行自动化测试，所以我无法使用“编码的 UI 测试生成器”工具在这个系统中获得很多控件。话虽如此，我构建了一个方法来截取屏幕截图并比较区域以验证系统是否抛出错误窗口(不是真正的窗口，我也无法使用该工具获取此窗口)并且此函数在另一个中定期调用线程，但我收到了异常:

Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: The Coded UI Test is running in Single Thread Apartment (STA) mode of COM. In this mode, all the playback calls should happen from the TestMethod thread only and UITestControl should not be shared across TestMethods.

然后我发现UI Test不支持多线程，每次与系统交互后我都被迫调用函数来验证错误(例如生成报告，验证错误，关闭报告，验证错误).

可能是更好的方法或软件设计模式，但我才刚刚开始进行自动化测试，不知道应该怎么做才能改进该测试。

我的问题是:这是更好的方法吗？这是什么。

Answer 1

没错。编码的 UI 不支持多线程，因为它写在异常中，所以 UITestControl 不能在多个测试方法中共享。

但是，您可以启动另一个线程，在不使用编码 UI 及其播放的情况下制作屏幕截图。如果您正在寻找特定的消息框，您可以将编码的 UI 函数与 WinApi 函数结合使用。您可以从与您的编码 UI 并行运行的另一个线程调用 WinApi 函数。

我建议避免多线程并坚持使用编码的 UI 顺序方法。即当您执行某个操作(鼠标单击、键盘输入等)，然后验证与 UI 的交互是否按预期工作时。

如果您的错误消息偶尔出现并阻止其他控件，您可以考虑使用 Playback.Cleanup() ( about Cleanup() on MSDN )。当测试播放中断或完成时，将自动调用此方法。如果您的错误消息由模态对话框表示，那么我假设其他控件将被阻止。当 Playback 无法对控件执行所需的操作时，它会停止并调用 Cleanup() 方法，您可以在其中明确检查您的预期错误是否导致播放停止。

但我仍然建议使用顺序方法并检查 UI 与编码 UI 方法(断言等)交互的结果

希望其中之一能有所帮助。如果不是，请提供有关您正在努力处理的错误消息的附加信息。