# 测试10年，10节课–第4课

# 第4课:GUI自动化测试不会模拟用户所做的事情

我无法相信我与其他测试人员讨论这个问题的频率有多高。此外，这种我们对GUI自动化的迷恋也到了必须停止的时机。

一些测试人员过于喜欢GUI端到端自动化测试，其推理通常是这样的：“如果我在GUI上自动化此测试，它将模仿用户的操作行为！” 真是这样的吗？未必。 用户通过应用程序中的所经历的流程，将在几秒钟内构建他们对于系统上下文的理解。他们会观察整个页面(寻找他们所感兴趣或者需要的话题)，如果用户体验是正确的，他们就会很清楚自己要做什么该怎么做。否则他们会立刻发现业务布局的不合理后者用户体验上的缺陷，直接吐槽或者放弃使用系统，然而我们编写的自动化脚本并不会关心这些，也无法测试这些。

该脚本将使用定位器在应用程序中进行操作，些定位器在屏幕上是否美观对计算机来说并不重要。真正的用户不会使用定位器来完成所需的操作：他们会单击屏幕上的某个位置，因为他们看到那里有一个按钮。如果按钮的可点击区域是错误的(比如，太小)，或者触发的部位不正确，，用户的操作就会被打断，然而对于脚本而言，只要脚本的定位器是enable并且是visible，计算机就会影响脚本的请求。

该脚本将按照您的指令执行操作：它不会被实际禁用的字段所阻碍，并且无需暂停即可构建上下文，它只是在前进。它具有真正用户没有的超能力：它确切知道应该在DOM树中单击哪个元素，并且不会因可能出现的弹出窗口而分散注意力。

在这些类型的测试中存在清晰的断言。你会冒着崩溃的风险在每个屏幕上断言东西吗?你是否只是随波逐流，看看你是否能成功地完成它?时间问题呢?您是否使用测试环境，该环境是否在您的控制之下?

所有这些麻烦都可以通过问自己一个问题来避免:我真的需要在UI中测试吗?还是我只是通过UI进行测试。

通常，UI不是测试自动化的最佳层。我非常偏爱API自动化，我非常喜欢它。那里的测试更容易维护，运行速度更快，而且这些测试仍然可以满足一些端到端需求。

如果您希望编写GUI端到端测试，那么我是最不可能阻止您的人。如果风险在于此，请剥离端到端部分并将它们隔离在GUI中，但我建议不要走端到端自动化的路线。这条路线充满了维护噩梦、假否定、时间问题。 这节课最重要的一点是:这些测试不会执行用户所执行的操作。

测试中的自动化有很多目的，但模仿人类并不是目的之一。