免费建站的网站哪个好,wordpress顶插件,贵港购物网站开发设计,怎么搭建自己的服务器这篇文章将从实际工程应用的角度#xff0c;探讨GUI测试的稳定性问题。 GUI自动化测试稳定性#xff0c;最典型的表现形式就是#xff0c;同样的测试用例在同样的环境上#xff0c;时而测试通过#xff0c;时而测试失败。 这也是影响GUI测试健康发展的一个重要障碍#x… 这篇文章将从实际工程应用的角度探讨GUI测试的稳定性问题。 GUI自动化测试稳定性最典型的表现形式就是同样的测试用例在同样的环境上时而测试通过时而测试失败。 这也是影响GUI测试健康发展的一个重要障碍严重降低了GUI测试的可信性。 虽然从理论上来讲GUI测试有可能做到100%稳定但在实际项目中这是一个几乎无法达到的目标。根据经验如果能够做到95%以上的稳定性就已经非常不错了。 要提高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测试 A/B测试是互联网产品常用的一种测试方法。它为Web或App的界面或流程提供两个不同的版本然后让用户随机访问其中一个版本并收集两个版本的用户体验数据和业务数据最后分析评估出最好的版本用于正式发布。 A/B 测试通常会发布到实际生产环境所以就会造成生产环境中GUI自动化测试的不稳定。 这种问题的解决思路是在测试脚本内部对不同的被测版本做分支处理脚本需要能够区分A和B两个的不同版本并做出相应的处理。
随机的页面延迟造成控件识别失败 随机的页面延迟也是GUI测试防不胜防的。既然是随机的也就是说我们没有办法去控制它那有没有什么办法去减少它造成的影响呢
一个屡试不爽的办法就是加入重试retry机制。重试机制是指当某一步GUI操作失败时框架会自动发起重试重试可以是步骤级别的也可以是页面级别的甚至是业务流程级别的。
对于开源GUI测试框架重试机制往往不是自带的功能需要自己二次开发来实现。
比如eBay的GUI自动化测试框架分别实现了步骤级别、页面级别和业务流程级别的重试机制默认情况下启用的是步骤级别的重试页面级别和业务流程级别的重试可以通过测试发起时的命令行参数进行指定。
需要特别注意的是对于那些会修改一次性使用数据的场景切忌不要盲目启用页面级别和业务流程级别的重试。
测试数据问题
测试数据问题也是造成GUI自动化测试不稳定的一个重要原因。
比如测试用例所依赖的数据被其他用例修改了再比如测试过程中发生错误后自动进行了重试操作但是数据状态已经在第一次执行中被修改了。
这样的场景还有很多我会在后面的测试数据准备系列文章中详细展开并分析由此引入的测试不稳定性问题的解决思路。
总结
根据我的实践经验我归纳了五种造成GUI自动化测试不稳定的主要因素并给出了对应的解决思路。
对于非预计的弹出对话框引起的不稳定可以引入“异常场景恢复模式”来解决。对于页面控件属性的细微变化造成的不稳定可以使用“组合属性”定位控件并且可以通过“模糊匹配技术”提高定位识别率。对于A/B测试带来的不稳定需要在测试用例脚本中做分支处理并且需要脚本做到正确识别出不同的分支。对于随机的页面延迟造成的不稳定可以引入重试机制重试可以是步骤级别的也可以是页面级别的甚至是业务流程级别的。对于测试数据引起的不稳定我在这里没有详细展开留到后续的测试数据准备系列文章中做专门介绍。
