Visual studio 2013 CodedUI是否适用于性能测试？缺点是什么

我创建了一些自动化测试来测试使用MFC和WPF技术编写的大型桌面应用程序。UI测试执行一致，现在我们可以使用相同的测试来测量UI/控件加载的性能了吗？我正在添加秒表，然后单击按钮，并在看到下一个屏幕时将其停止。对于其他控件/窗口也是如此。通过这种方式，我计划在应用程序的每个新构建之后运行此测试，并比较性能

我观察到的一些挑战 1每次执行测试时，我都会得到不同的数字。所以我无法计算出底线 2从编码UI端来看，很少有服务员会影响这些差异 3我的逻辑应该是什么，以确定一个更可预测和可测量的基线

---

或者使用CodedUI进行性能测试是个坏主意？非常感谢您对此有任何想法。

我只能从WinForms使用DevExpress控件的经验谈起

基本上，性能还有很多不尽如人意之处。主要的性能问题是复杂的UI，它具有许多嵌套的布局控件

在编码UI中播放使用WinForms应用程序中的嵌套链查找系统。这意味着您不能简单地按Id搜索控件，而是需要通过父->子层次结构（也称为搜索限制器）

我可以想象，在web上，通过控件Id直接在DOM上搜索精确匹配的控件，播放速度会快得多

下一个巨大的性能问题是网格和树。或具有行/列的控件。在这里，在Winforms中，每当您希望可靠地获取控件时，测试引擎都会对该控件执行完整的查找。这使它变慢了

我的建议是使用记录器在WPF应用程序中定位深度嵌套的网格控件。一旦它出现在UI映射中，然后编写代码来迭代控件中的所有项-动态测试设置和获取

你可能会对表演感到满意。我在这里找到了使用本机Win32方法绕过性能的方法，并考虑了只使用单击路径进行导航，这样就不需要至少查找导航控件，但如果UI发生变化，这将需要额外的维护

我能说的一件事是，我发现最好的性能是：

private static WaitForReadyLevel _waitLevel = WaitForReadyLevel.Disabled;

Playback.PlaybackSettings.SearchTimeout = 12000;
Playback.PlaybackSettings.AlwaysSearchControls = false;
Playback.PlaybackSettings.WaitForReadyLevel = _waitLevel;
Playback.PlaybackSettings.DelayBetweenActions = 100;
Mouse.MouseDragSpeed = 9000;

---

希望这有帮助

如果您希望分析性能，为什么不使用VisualStudio附带的性能工具？