0

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

我观察到的挑战很少 1) 每次执行测试时，我都会得到不同的数字。所以无法弄清楚基线 2）从编码的 UI 端来看，很少有服务员会影响这些差异 3）我的逻辑应该是什么才能采用更可预测和可衡量的基线？

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

4

1 回答 1

0

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

基本上，性能还有很多不足之处。主要的性能问题在于具有大量嵌套布局控件的复杂 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;

希望这可以帮助。

于 2015-02-02T22:53:59.267 回答