不知不觉，我已经介绍完了GUI测试相关的知识点，你可以先回顾一下这些知识点，是否还有不清楚的地方，也欢迎你给我留言进行讨论。同时，我希望这些知识点，已经帮你搭建了GUI自动化测试的知识体系。
那么，今天我将从实际工程应用的角度，和你一起聊聊GUI测试的稳定性问题。
如果你所在的公司已经规模化地开展了GUI测试，那我相信你们也一定遇到过测试稳定性的问题。GUI自动化测试稳定性，最典型的表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败。 这也是影响GUI测试健康发展的一个重要障碍，严重降低了GUI测试的可信性。
所以，今天我分享的主题就是，如何提高GUI测试的稳定性。虽然从理论上来讲，GUI测试有可能做到100%稳定，但在实际项目中，这是一个几乎无法达到的目标。根据我的经验，如果能够做到95%以上的稳定性，就已经非常不错了。
要提高GUI测试稳定性，首先你需要知道到底是什么原因引起的不稳定。你必须找出尽可能多的不稳定因素，然后找到每一类不稳定因素对应的解决方案。
为此，根据我的实践经验，以及所遇到的场景，我为你总结了五种造成GUI测试不稳定的因素：
非预计的弹出对话框；
页面控件属性的细微变化；
被测系统的A/B测试；
随机的页面延迟造成控件识别失败；
测试数据问题。
并且，我提供了针对这五种不稳定因素的解决思路。
非预计的弹出对话框，一般包含两种场景;
GUI自动化测试用例执行过程中，操作系统弹出的非预计对话框， 有可能会干扰GUI测试的自动化执行。
比如，GUI测试运行到一半，操作系统突然弹出杀毒软件更新请求、病毒告警信息、系统更新请求等对话框。这种对话框的弹出往往是难以预计的，但是一旦发生就有可能造成GUI自动化测试的不稳定。
被测软件本身也有可能在非预期的时间弹出预期的对话框， GUI自动化测试有可能会因此而失败。
比如，被测软件是一个电子商务网站，你在网站上进行操作时，很可能会随机弹出“用户调查”对话框。虽然这种对话框是可知的，但是具体会在哪一步弹出却是不可预期的。而这，往往会造成GUI自动化测试的不稳定。
怎么解决这类问题呢？
先试想一下，如果你在手工测试时，遇到了这种情况，会如何处理？很简单啊，直接点击对话框上的“确认”或者“取消”按钮，关闭对话框，然后继续相关的业务测试操作。
对GUI自动化测试来说，也是同样的道理。具体做法是：
需要注意的是：这种方式只能处理已知可能出现的对话框。而对于新类型的对话框，只能通过自动化的方式尝试点击上面的按钮进行处理。每当发现一种潜在会弹出的对话框，我们就把它的详细信息（包括对象定位信息等）更新到“异常场景恢复”库中，下次再遇到相同类型的对话框时，系统就可以自动关闭了。
如果页面控件的属性发生了变化，哪怕只是细微的变化，也会导致测试脚本的定位元素失效。
比如，“登录”按钮的ID从“Button_Login_001”变成了“Button_Login_888”，那么如果GUI自动化测试脚本还是按照原来的“Button_Login_001”来定位“登录”按钮，就会因为ID值的变化，定位不到它了，自动化测试用例自然就会失败。
如何解决这个问题呢？还是先试想一下，如果手动操作时遇到了这个问题会怎么处理，然后再把手动处理的方式用编程语言实现。
当“登录”按钮的ID 从“Button_Login_001”变成了 “Button_Login_888”，你手动操作时可能一眼就发现了。那你是怎么做到一眼发现的呢？
细想一下，你会发现人的思维过程应该是这样的：
你发现页面上的按钮（Button）就那么几个，而且从ID中包含的关键字（Login）可以看出是“登录”按钮，再加上这个按钮的ID是“Button_Login_001”，“Button_Login_888”怎么看都是同一个对象，只是ID最后的数字发生了变化而已。
现在，我来提炼一下这个定位控件的思路：
通过控件类型（Button）缩小了范围；
通过属性值中的关键字（Login）进一步缩小范围；
根据属性值变化前后的相似性，最终定位到该控件。
看到这里，你得到什么启发了吗？
采用“组合属性”定位控件会更精准，而且成功率会更高，如果能在此基础上加入“模糊匹配”技术，可以进一步提高控件的识别率。
“模糊匹配”是指，通过特定的相似度算法，控件属性发生细微变化时，这个控件依旧可以被准确定位。
目前，一些商用GUI自动化测试工具，比如UFT，已经实现了模糊匹配。通常情况下，你只需要启用“模糊匹配”选项即可。如果某个对象的定位是通过模糊匹配完成的，那么，测试报告中将会显示该信息，明确告知此次对象识别是基于模糊匹配完成的，因为GUI自动化工具并不能保证每次模糊匹配都一定正确。
但是，开源的GUI自动化测试框架，目前还没有现成的框架直接支持模糊匹配，通常需要你进行二次开发，实现思路是：实现自己的对象识别控制层，也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑。
通常，我不建议把模糊匹配逻辑以硬编码的方式写在代码里，而是引入规则引擎，将具体的规则通过配置文件的方式与代码逻辑解耦。
A/B测试，是互联网产品常用的一种测试方法。它为Web或App的界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本，并收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布。
A/B 测试通常会发布到实际生产环境，所以就会造成生产环境中GUI自动化测试的不稳定。
这种问题的解决思路是，在测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分A和B两个的不同版本，并做出相应的处理。
随机的页面延迟，也是GUI测试防不胜防的。既然是随机的，也就是说我们没有办法去控制它，那有没有什么办法去减少它造成的影响呢？
一个屡试不爽的办法就是，加入重试（retry）机制。重试机制是指，当某一步GUI操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
对于开源GUI测试框架，重试机制往往不是自带的功能，需要自己二次开发来实现。
比如，eBay的GUI自动化测试框架，分别实现了步骤级别、页面级别和业务流程级别的重试机制，默认情况下启用的是步骤级别的重试，页面级别和业务流程级别的重试可以通过测试发起时的命令行参数进行指定。
需要特别注意的是，对于那些会修改一次性使用数据的场景，切忌不要盲目启用页面级别和业务流程级别的重试。
测试数据问题，也是造成GUI自动化测试不稳定的一个重要原因。
比如，测试用例所依赖的数据被其他用例修改了；再比如，测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了。
这样的场景还有很多，我会在后面的测试数据准备系列文章中详细展开，并分析由此引入的测试不稳定性问题的解决思路。
根据我的实践经验，我归纳了五种造成GUI自动化测试不稳定的主要因素，并给出了对应的解决思路。
对于非预计的弹出对话框引起的不稳定，可以引入“异常场景恢复模式”来解决。
对于页面控件属性的细微变化造成的不稳定，可以使用“组合属性”定位控件，并且可以通过“模糊匹配技术”提高定位识别率。
对于A/B测试带来的不稳定，需要在测试用例脚本中做分支处理，并且需要脚本做到正确识别出不同的分支。
对于随机的页面延迟造成的不稳定，可以引入重试机制，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
对于测试数据引起的不稳定，我在这里没有详细展开，留到后续的测试数据准备系列文章中做专门介绍。
在工作中，你还遇到过哪些造成GUI测试不稳定的因素，你又是如何来解决的？
欢迎你给我留言。
评论