编码的UI测试与线程有关/定期执行重复操作
本文关键字：执行 操作 UI 测试 线程 编码 | 更新日期: 2023-09-27 18:20:51
我正在VB中构建的系统中自动化测试，所以我无法使用"Coded UI Test Builder"工具在这个系统中获得很多控件。也就是说，我建立了一个方法来截图并比较一个区域，以验证系统是否抛出了一个错误窗口（不是真正的窗口，我也不能用工具得到这个窗口），并且这个函数在另一个线程中被周期性调用，但我收到了异常：
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测试不支持多线程，我被迫在每次与系统交互后调用该函数来验证错误（例如生成报告、验证错误、关闭报告、验证误差）。
也许这是一种更好的方法或软件设计模式，但我刚开始进行自动化测试，不知道该怎么做才能改进测试。
我的问题是：这样更好吗？它是什么。
没错。编码的UI不支持多线程，因为它是在异常中编写的，所以UITestControl不能在多个测试方法中共享。
但是，您可以启动另一个线程，在那里您可以在不使用编码UI及其播放的情况下进行屏幕截图。如果您正在寻找一个特定的消息框，您可以将Coded UI函数与WinApi函数相结合。您可以从与您的Coded UI并行运行的另一个线程调用WinApi函数。
我建议避免多线程，并坚持使用编码的UI顺序方法。也就是说，当你执行一个操作（鼠标点击、键盘输入等），然后验证与UI的交互是否如预期那样工作。
如果您的错误消息偶尔出现并阻止了其他控件，您可以考虑使用Playback.Cleanup（）（关于MSDN上的Cleanup））。当测试回放中断或结束时，将自动调用此方法。如果您的错误消息由模态对话框表示，那么我认为其他控件将被阻止。当"播放"无法对控件执行所需操作时，它将停止，并将调用Cleanup（）方法，在该方法中，您可以明确检查预期错误是否导致播放停止。
但我仍然建议使用顺序方法，并使用编码的UI方法（断言等）检查UI交互的结果
希望其中一个能有所帮助。如果没有，请提供有关您正在努力处理的错误消息的其他信息。