标签（空格分隔）： GUI测试稳定性
GUI测试稳定性的关键技术
GUI 自动化测试稳定性，最典型的表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败。 这也是影响 GUI 测试健康发展的一个重要障碍，严重降低了 GUI 测试的可信性
- 要提高 GUI 测试稳定性，首先你需要知道到底是什么原因引起的不稳定。你必须找出尽可能多的不稳定因素，然后找到每一类不稳定因素对应的解决方案;
- 非预计的弹出对话框；
页面控件属性的细微变化；
被测系统的 A/B 测试；
随机的页面延迟造成控件识别失败；
测试数据问题
非预计的弹出对话框
GUI 自动化测试用例执行过程中，操作系统弹出的非预计对话框， 有可能会干扰 GUI 测试的自动化执行。比如，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 测试
/B 测试，是互联网产品常用的一种测试方法。它为 Web 或 App 的界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本，并收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布。
A/B 测试通常会发布到实际生产环境，所以就会造成生产环境中 GUI 自动化测试的不稳定。这种问题的解决思路是，在测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分 A 和 B 两个的不同版本，并做出相应的处理。
随机的页面延迟造成控件识别失败
机的页面延迟，也是 GUI 测试防不胜防的。既然是随机的，也就是说我们没有办法去控制它，那有没有什么办法去减少它造成的影响呢？一个屡试不爽的办法就是，加入重试（retry）机制。重试机制是指，当某一步 GUI 操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。对于开源 GUI 测试框架，重试机制往往不是自带的功能，需要自己二次开发来实现。
测试数据问题
测试数据问题，也是造成 GUI 自动化测试不稳定的一个重要原因。比如，测试用例所依赖的数据被其他用例修改了；再比如，测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了,后续继续讨论