针对"GUI自动化测试稳定性问题"这个问题，最典型的情景就是：同样的测试用例，在同样的测试执行环境下，测试的结果有时是Success，有时是Fail，这严重降低了GUI测试的可信度，同时也是GUI层面的自动化测试位于金字塔最顶端的原因之一。

在实际的项目过程中，GUI测试几乎不可能做到100%稳定，根据我的经验，如果能够做到 90% 以上的稳定性，就已经非常不错了，这需要整个产品技术团队的共同努力才有希望达成。

要提高 GUI 测试稳定性，首先我们需要知道到底是什么原因引起的不稳定。我们必须找出尽可能多的不稳定因素，然后找到每一类不稳定因素对应的解决方案。

我列举了几种常见的造成GUI测试不稳定的因素，如下：

1、非预期的弹框

在用例执行过程中，操作系统或被测系统可能会突然弹出预期范围之外的对话框，GUI自动化测试有可能就会因此而失败。

解决方案：常用的解决方式，引入异常场景恢复模式或者采取*面GUI自动化测试来处理。

2、页面控件属性的细微变化

如果页面控件的属性发生了变化，哪怕只是细微的变化，也必定会导致测试脚本的元素定位失败。这可以说是GUI自动化测试最大的痛点。

目前，一些商用 GUI 自动化测试工具，比如 UFT(原QTP)，已经集成了模糊匹配的功能。通常情况下，只需要启用“模糊匹配”选项即可。如果某个对象的定位是通过模糊匹配完成的，那么，测试报告中将会显示该信息，明确告知此次对象识别是基于模糊匹配完成的，因为 GUI 自动化工具并不能保证每次模糊匹配都一定正确。

解决方案：元素定位时采用模糊匹配技术。

3、随机的页面延迟造成控件识别失败

随机的页面延迟，也是 GUI 测试防不胜防的。既然是随机的，也就是说我们没有办法去控制它，解决办法是加入重试（retry）机制。重试机制是指，当某一步 GUI操作失败时，框架会自动发起重试。对于Robot Framework+SeleniumLirary，可以使用有wait until系列的关键字（智能等待），尽量少的使用sleep。

Wait For Condition

Wait Until Element Contains

Wait Until Element Does Not Contain

Wait Until Element Is Enabled

Wait Until Element Is Not Visible

Wait Until Element Is Visible

Wait Until Page Contains

Wait Until Page Contains Element

Wait Until Page Does Not Contain

Wait Until Page Does Not Contain Element

解决方案：引入重试机制retry

4、测试数据问题

测试数据问题，也是造成 GUI 自动化测试不稳定的一个重要原因。比如，测试用例所依赖的数据被其他用例修改了。要解决此类的问题，就要回归到第一篇中所谈到的内容，必须要保证用例之间的独立性和尽量减少对执行环境的依赖。Robot框架本身不会规定Case执行的顺序，所以从某种程度上来说同一层级的Cases是随机执行的。很典型的情况就是，测试用例在本地调试时怎么跑怎么过，放到Server上所有Cases一起跑的时候就会Fail,还可能是偶发的，这种情况下就很可能是由于其他Case的痕迹影响到了它，查找问题的根源往往比较耗时。

解决方案：保证用例之间的独立性和尽量减少对执行环境的依赖

5、小结

界面自动化测试，它最接近用户真实场景，也容易发现问题，但它的实现成本最高且太容易受外部依赖，容易影响脚本成功率。总体来说，适当的界面自动化测试是有必要的，但是也大可不必在UI层投入太多精力。