这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。
17 精益求精：聊聊提高GUI测试稳定性的关键技术
GUI自动化测试稳定性，最典型的表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败。
五种造成GUI测试不稳定的因素：
- 非预计的弹出对话框
- 页面控件属性的细微变化
- 被测系统的 A/B 测试
- 随机的页面延迟造成控件识别失败
- 测试数据问题
解决思路
非预计的弹出对话框
- 操作系统弹出非预计对话框
- 被测软件在非预期的时间弹出预期的对话框
具体做法：
- 自动化脚本发现控件无法正常定位，或者无法操作时，GUI自动化框架自动进入“异常场景恢复模式”
- 在“异常场景恢复模式”，GUI自动化框架依次检查各种可能出现的对话框，确定类型后，执行预定义的操作，接着重试刚才失败的步骤。
注意：这种方式只能处理已知对话框，对于新类型的对话框，每发现一次，就把它的详细信息更新到“异常场景恢复模式”库中，下次再遇到相同类型的对话框时，就可以自动处理了。
页面控件属性的细微变化
如：登录按钮的ID从“button_login_001”变成了“button_login_888”，测试脚本还是按照原来的id进行定位，就会失败。
思路：
- 通过空间类型(Button)缩小范围
- 通过属性中的关键字(Login)进一步缩小范围
- 根据属性值变化前后的相似性，最终定位到该控件
因此，可以考虑采用“组合属性”和“模糊匹配”的技术，提高控件的识别率。
商用GUI自动化测试工具比如UFT已经实现了模糊匹配。对于开源框架，需要自己进行二次开发，实现思路是：实现自己的对象识别控制层，也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑。
通常，并不建议把模糊匹配逻辑以硬编码的方式写在代码里，而是引入规则引擎，将具体的规则通过配置文件的方式与代码逻辑解耦。
被测系统的 A/B 测试
A/B测试是互联网产品常用的一种测试方法。它为Web或App的界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本，并收集两个版本的用户体验数据和业务数据，最后分析评估出最好的版本用于正式发布。
解决思路：在测试脚本内部对不同的被测版本做分支处理，脚本能够区分出A和B两个不同的版本，并作出相应的处理。
随机的页面延迟造成控件识别失败
加入重试机制。当某一步GUI操作失败时，框架会自动发起重试，重试可以使步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
特别注意：对于那些会修改一次性使用数据的场景，切忌不要盲目启用页面级别和业务流程级别的重试。
测试数据问题
如：测试用例依赖的数据被其他用例修改了；测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了。
这部分本篇没有详细展开。
【心得】
自己做过的项目中，主要处理了页面延迟造成的控件识别失败，采用的方法是在步骤级别加入等待。至于页面级别和业务流程级别，由于自己的项目中并没有做到这一层，所以也没有从这种层面上来考虑过，所以作者能够考虑这么多，也是有基础的。
对于弹出对话框的那个，一般只是对运行自动化测试的机器做了检查，保证系统不会弹出这些奇怪的弹出框，并未从代码层面考虑过。也是由于项目比较小，人力所限。
至于 A/B 测试，我所做过的项目，会在自动化测试运行之前，先部署系统，所以就保证了部署的系统就是被测的版本，因此也没有必要在自动化测试框架中进行检查了。
至于页面控件属性的细微变化，这块没有做，不过我们的系统并不会出现这种id的细微变化，所以几乎没有影响。
关于测试数据问题，尽可能从用例设计级别保证依赖数据不会被其他自动化测试用例修改，并且也不会有人手工修改用例。
