桌面应用程序的UI自动化模式和最佳实践

背景

我目前正在针对MS Office插件自动化一些测试。我们将在VS 2010中创建编码的UI测试。我想我可以使用“ 编码的UI测试生成器 ”工具，但它实际上并不适合我的特定情况。

因此，我为每个UI控件/映射创建了自己的UI Map类和扩展方法，在其中添加了不同的操作功能。例如，按下按钮或声明一些UI值。

测试用例的场景在测试类中。

我是这个领域的新手，也是自动化测试员的新手。

问题

人们是否愿意从编程/设计的角度分享经验和对台式机应用程序测试自动化的一些好的实践建议？

UI自动化测试的最佳实践是尽可能少地做。UI经常更改，这意味着您经常需要更新自动化。通常，最好以一种无需UI自动化即可进行自动化测试的方式来构造产品代码。

就是说，您不能总是摆脱UI自动化。您提到办公室，所以我假设您正在为Windows编码并使用.Net。我在目前的工作中做了很多工作。这是我学到的一些东西。

1）查看.Net 3.0中引入的UIAutomation库。它们提供了广泛且相当简单的自动化库。（http://msdn.microsoft.com/zh-cn/library/ms753107.aspx）

2）下载UISpy（http://msdn.microsoft.com/zh-cn/library/ms727247.aspx）

3）使产品的UI自动化。

3a）如果是WPF，则将AutomationID放在所有内容上。

3b）尝试创建独特的控件和窗口类名称（UI类名称，而不是源代码类名称）。如果您不明白我的意思，请加载UI Spy并开始查看Windows。请注意，不同应用程序中有多少个窗口的类名称为＃32770。这是Windows对话框的类名。任何扩展对话框且未设置其自身名称的窗口均默认为该名称。从UI自动化的角度来看，这引起了各种各样的悲伤。

4）避免使用Thread.Sleep（）语句。尝试改用Waiters（请参阅UIAutomation文档）。

5）切勿将测试代码与UI自动化代码混合使用。创建单独的库以执行UI自动化。从测试中调用这些库。当用户界面更改时，这将使更新自动化变得更加容易。

6）在执行将导致事件触发的操作之前，请始终为UI事件注册一个侦听器。实际上，这意味着您将使用线程。

6a）示例：单击按钮打开窗口后，不要开始等待“窗口打开”事件。在注册服务员之前，该窗口可能会打开，并且永远不会收到事件。

7）永远不要以为刚打开的窗口就是您想要的那个。Windows中可能会意外打开各种窗口。

我可以继续做下去，但是这有点长了。

从可重复使用的用例构建功能测试

当需要对应用程序进行端到端现场测试时，您正在执行功能测试。通常，您将有一组要测试的需求，并且能够构造代表它们的各种用例。

例如，考虑“以标准用户身份登录”用例。您的测试框架将启动应用程序，等待登录屏幕，输入一些凭据，单击登录按钮，并验证相应的屏幕现在显示登录成功。

在完成“以标准用户身份登录”用例之后，您将需要在此基础上执行其他操作，也许是“编辑我的用户详细信息”用例。您将不想重复“以标准用户身份登录”用例中的所有代码，因此您只需引用执行该操作的测试框架代码即可。

这意味着您具有某种包含用例列表的总体功能测试。这些用例包含导致应用程序行为（单击按钮X）和验证行为（屏幕变为蓝色）的测试框架方法。

总体而言，您可以构建针对特定序列的一组可重复使用的用例并测试特定的响应，然后将它们聚合为与业务需求紧密相关的各种功能测试。一旦完成，就可以完全自动化整个构建过程。

如果您有兴趣进一步阅读，我已经在其他地方介绍了这种方法，但是本文主要针对Java中的Web应用程序（使用Maven和SeleniumRC），而不是您要求的桌面应用程序。