GUI 自动化测试稳定性，最典型的表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败。
造成 GUI 测试不稳定的因素
一、非预计的弹出对话框
1.1、GUI 自动化测试用例执行过程中，操作系统弹出的非预计对话框
比如，GUI 测试运行到一半，操作系统突然弹出杀毒软件更新请求、病毒告警信息、系统更新请求等对话框。这种对话框的弹出往往是难以预计的，但是一旦发生就有可能造成 GUI 自动化测试的不稳定。
1.2、被测软件本身也有可能在非预期的时间弹出预期的对话框
比如，被测软件是一个电子商务网站，在网站上进行操作时，很可能会随机弹出“用户调查”对话框。虽然这种对话框是可知的，但是具体会在哪一步弹出却是不可预期的。而这，往往会造成 GUI 自动化测试的不稳定。
解决方案：
1、当自动化脚本发现控件无法正常定位，或者无法操作时，GUI 自动化框架自动进入“异常场景恢复模式”。
2、在“异常场景恢复模式”下，GUI 自动化框架依次检查各种可能出现的对话框，一旦确认了对话框的类型，立即执行预定义的操作（比如，单击“确定”按钮，关闭这个对话框），接着重试刚才失败的步骤。
注：这种方式只能处理已知可能出现的对话框。
而对于新类型的对话框，只能通过自动化的方式尝试点击上面的按钮进行处理。每当发现一种潜在会弹出的对话框，我们就把它的详细信息（包括对象定位信息等）更新到“异常场景恢复”库中，下次再遇到相同类型的对话框时，系统就可以自动关闭了。
对于非预期的弹框也可以通过检查置顶窗口是否是预期软件窗口，从而确定是否被第三方弹框影响
二、页面控件属性的细微变化
比如，“登录”按钮的 ID 从“Button_Login_001”变成了“Button_Login_888”，那么如果 GUI 自动化测试脚本还是按照原来的“Button_Login_001”来定位“登录”按钮，就会因为 ID 值的变化，定位不到它了，自动化测试用例自然就会失败。
解决方案：
1、通过控件类型（Button）缩小了范围
2、通过属性值中的关键字（Login）进一步缩小范围
3、根据属性值变化前后的相似性，最终定位到该控件
采用“组合属性”定位控件会更精准，而且成功率会更高，如果能在此基础上加入“模糊匹配”技术，可以进一步提高控件的识别率。
“模糊匹配”是指，通过特定的相似度算法，控件属性发生细微变化时，这个控件依旧可以被准确定位。
但是，开源的 GUI 自动化测试框架，目前还没有现成的框架直接支持模糊匹配，通常需要你进行二次开发，实现思路是：实现自己的对象识别控制层，也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑。
如果是 selenium 的话，建议优先使用 xpath，这样就算 id、clases、name 等控件属性改变，只要不是页面改版，应该不会影响自动化稳定性。
三、被测系统的 A/B 测试
A/B 测试，是互联网产品常用的一种测试方法。它为 Web 或 App 的界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本，并收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布。
A/B 测试通常会发布到实际生产环境，所以就会造成生产环境中 GUI 自动化测试的不稳定。
解决思路：在测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分 A 和 B 两个的不同版本，并做出相应的处理。
四、随机页面延迟造成控件识别失败
加入重试（retry）机制，当某一步 GUI 操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
对于开源 GUI 测试框架，重试机制往往不是自带的功能，需要自己二次开发来实现。
注：对于那些会修改一次性使用数据的场景，切忌不要盲目启用页面级别和业务流程级别的重试。
重试机制确实是个好办法，但是如果用例都是因为重试才执行正确，有可能会漏出和缓存相关的问题，因为重试应该算一个独立测试场景了，现在是把它作为主要测试场景了。
五、测试数据问题
比如，测试用例所依赖的数据被其他用例修改了；再比如，测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了。
构造自动化数据时要特别注意，构造一些带特殊字段的数据库信息，最好是超出常人操作的数据信息，这样可以有效避免数据被误修改的风险，当然，还有一个处理办法就是先检查测试数据是否存在/异常，不存在或异常都进行重建即可，这部分也算是测试代码的兼容处理吧。
网友评论