GUI 测试的稳定性问题，影响 GUI 测试健康发展的一个重要障碍，严重降低了 GUI 测试的可信性。
要提高 GUI 测试稳定性，首先你需要知道到底是什么原因引起的不稳定。你必须找出尽可能多的不稳定因素，然后找到每一类不稳定因素对应的解决方案。
五种造成 GUI 自动化测试不稳定的因素
非预计的弹出对话框
一般包含两种场景：
-
操作系统弹出的非预计对话框
-
被测软件本身非预计对话框
如果你在手工测试时，遇到了这种情况，会如何处理？很简单啊，直接点击对话框上的“确认”或者“取消”按钮，关闭对话框，然后继续相关的业务测试操作。
GUI自动化测试具体做法是：
-
当自动化脚本发现控件无法正常定位，或者无法操作时，GUI 自动化框架自动进入“异常场景恢复模式”。
-
在“异常场景恢复模式”下，GUI 自动化框架依次检查各种可能出现的对话框，一旦确认了对话框的类型，立即执行预定义的操作（比如，单击“确定”按钮，关闭这个对话框），接着重试刚才失败的步骤。
-
每当发现一种潜在会弹出的对话框，我们就把它的详细信息（包括对象定位信息等）更新到“异常场景恢复”库中。
页面控件属性的细微变化
“登录”按钮的 ID 从“Button_Login_001”变成了“Button_Login_888”，那么如果 GUI 自动化测试脚本还是按照原来的“Button_Login_001”来定位“登录”按钮，就会因为 ID 值的变化，定位不到它了，自动化测试用例自然就会失败。
人工处理这种问题的思维：
你发现页面上的按钮（Button）就那么几个，而且从 ID 中包含的关键字（Login）可以看出是“登录”按钮，再加上这个按钮的 ID 是“Button_Login_001”，“Button_Login_888”怎么看都是同一个对象，只是 ID 最后的数字发生了变化而已。
GUI自动化测试具体做法是：
-
通过控件类型（Button）缩小了范围；
-
通过属性值中的关键字（Login）进一步缩小范围；
-
根据属性值变化前后的相似性，最终定位到该控件。
采用“组合属性”定位控件会更精准，而且成功率会更高，如果能在此基础上加入“模糊匹配”技术，可以进一步提高控件的识别率。
模糊匹配思路
-
实现自己的对象识别控制层，也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑。
-
引入规则引擎，将具体的模糊识别规则通过配置文件的方式与代码逻辑解耦，模糊匹配逻辑不硬编码再代码里。
被测系统的 A/B 测试
A/B 测试，为 Web 或 App 的界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本，并收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布。
在测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分 A 和 B 两个的不同版本，并做出相应的处理。
随机的页面延迟造成控件识别失败
加入重试（retry）机制。重试机制是指，当某一步 GUI 操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
测试数据问题
比如，测试用例所依赖的数据被其他用例修改了；再比如，测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了。
总结
对于非预计的弹出对话框引起的不稳定，可以引入“异常场景恢复模式”来解决。
对于页面控件属性的细微变化造成的不稳定，可以使用“组合属性”定位控件，并且可以通过“模糊匹配技术”提高定位识别率。
对于 A/B 测试带来的不稳定，需要在测试用例脚本中做分支处理，并且需要脚本做到正确识别出不同的分支。
对于随机的页面延迟造成的不稳定，可以引入重试机制，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
对于测试数据引起的不稳定，我在这里没有详细展开，留到后续的测试数据准备系列文章中做专门介绍。
来源于：极客时间 茹炳晟 软件测试52讲