我在使用VB构建的系统中自动化测试，因此我无法使用＆＃34; Coded UI Test Builder＆＃34;在此系统中获得大量控件。工具。说，我构建了一个方法来截取屏幕截图并比较一个区域来验证系统是否抛出了一个错误窗口（不是真的是一个窗口，我也不能用这个工具得到这个）并定期调用这个函数在另一个线程中，但我收到了异常：
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不支持多线程，我被迫在每次与系统交互后调用该函数来验证错误（例如生成报告，验证错误，关闭报告，验证错误）。
可能是更好的方法或软件设计模式，但我只是从自动化测试开始，并且不知道我应该做些什么来改进测试。
我的问题是：这是一种更好的方法吗？它是什么。
答案 0 :(得分：1)
没错。编码的UI不支持多线程，并且由于它是在异常中编写的，因此无法在多个测试方法中共享UITestControl。
但是，您可以启动另一个线程，在该线程中您可以在不使用Coded UI及其播放的情况下制作屏幕截图。如果要查找特定的消息框，可以将编码的UI功能与WinApi功能结合使用。您可以从另一个与Coded UI并行运行的线程调用WinApi函数。
我建议避免使用多线程并坚持使用Coded UI顺序方法。这是当你做一个动作（鼠标点击，键盘输入等），然后验证与UI的交互是否按预期工作。
如果您的错误消息偶尔出现并阻止其他控件，您可以考虑使用Playback.Cleanup（）（about Cleanup() on MSDN）。当测试播放中断或完成时，将自动调用此方法。如果您的错误消息由模态对话框表示，那么我假设其他控件将被阻止。当Playback无法对控件执行所需操作时，它将停止并调用Cleanup（）方法，您可以在其中显式检查预期的错误是否导致播放停止。
但我仍然建议使用顺序方法并检查UI与Coded UI方法（Asserts等）的交互结果。
希望其中一个有所帮助。如果没有，请提供有关您正在努力处理的错误消息的其他信息。