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

Question

背景

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

因此，我为每个UI Control/Map创建了自己的UI类和扩展方法，其中添加了不同的操作功能。例如，按下按钮或断言某些UI值。

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

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

问题

人们是否愿意从编程/设计的角度来分享他们在桌面应用程序测试自动化方面的经验和建议？

Answer 1

UI自动化测试的最佳实践是尽可能少做。UI经常变化，这意味着您必须不断地更新您的自动化。通常情况下，最好是以一种无需UI自动化而允许自动测试的方式来构造产品代码。

也就是说，您不可能总是摆脱UI自动化。您提到了office，所以我假设您正在为Windows编写代码并使用.Net。我在目前的工作中做了不少工作。以下是我学到的一些东西。

1)查看在UIAutomation 3.0中引入的.Net库。它们为自动化提供了一个广泛且相当简单的使用库。(http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2)下载UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3)使产品的UI自动化。

如果是WPF，就把AutomationID放在每件事上。

尝试创建不同的控件和窗口类名(UI类名，而不是源代码类名)。如果你不知道我的意思，加载UI间谍，并开始查看窗口。注意，不同应用程序之间有多少个窗口的类名为#32770。这是Windows对话框的类名。任何扩展对话框且不设置自己名称的窗口都默认为此。从UI自动化的角度来看，这会引起各种痛苦。

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

5)不要将测试代码与UI自动化代码混在一起。创建单独的库来执行UI自动化。从测试中调用这些库。当UI发生变化时，这将使更新自动化变得更加容易。

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

6a)示例:在单击打开窗口的按钮后，不要开始等待打开窗口的事件。在服务员登记之前，窗口可能会打开，而且永远不会得到活动。

不要以为刚打开的那扇窗户就是你想要的。在Windows中，各种窗口可能会意外打开。

我可以继续说更多，但这有点长。

Answer 2

从可重用的用例

构建功能测试。

到了测试应用程序端到端的时候，您正在执行功能测试。通常，您将有一组您正在测试的需求，并且您将能够构建各种表示它们的用例。

作为一个例子，考虑“登录为标准用户”用例。您的测试框架启动应用程序，等待登录屏幕，输入一些凭据，单击登录按钮并验证适当的屏幕现在显示登录成功。

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

这意味着您有某种包含用例列表的跨拱功能测试。这些用例包含测试框架方法，用于导致应用程序行为(单击按钮X)并验证行为(屏幕变为蓝色)。

总之，您可以构建一组可重用的用例，这些用例针对特定的序列并测试特定的响应，然后将它们聚合到与业务需求密切相关的各种功能测试中。一旦你准备好了，你就可以完全自动化你的整个构建过程了。

如果您对在其他地方进一步阅读我写过这种方法感兴趣，那么本文的目标是Java中的web应用程序(使用Maven和SeleniumRC)，而不是您请求的桌面应用程序。