爱陪小樱桃

导航

 

标签(空格分隔): 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 自动化测试不稳定的一个重要原因。比如,测试用例所依赖的数据被其他用例修改了;再比如,测试过程中发生错误后自动进行了重试操作,但是数据状态已经在第一次执行中被修改了,后续继续讨论

posted on 2020-04-02 22:56  cherry小樱桃  阅读(325)  评论(0编辑  收藏  举报