干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)

  1. 常见痛点
  2. App 自动化测试中有些常见痛点问题,如果框架不能很好的处理,就可能出现元素定位超时找不到的情况,自动化也就被打断终止了。很容易打消做自动化的热情,导致从入门到放弃。比如下面的两个问题:

一是 App 启动加载时间较久(可能 App 本身加载慢,可能移动设备本身加载应用速度慢,也可能首页广告时间较长)。

另一个是各种弹框的出现,广告弹框,升级弹框,评价弹框等。在框架中如果不能处理好上面的情况,

以雪球 App 出现的几种弹框举例:

弹框一:干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第1张图片
弹框二:
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第2张图片
弹框三:
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第3张图片
2、弹框处理
2.1 处理方向

弹框的影响范围弹框对我们自动化的影响主要是用例执行的打断,而至于弹框中广告内容的跳转或评价信息填写等属于另外的测试,因此我们主要是要将弹框处理消失,使应用回到用例执行的 PO;
弹框的消失方式观察弹框,我们会发现一般为了保证用户体验,弹框都会方便用户进行一键消除,例如上述中雪球的各种弹框,可能点击一个叉号,可能任意点击其他地方,或者评价框这种直接点击“下次再说”等。
弹框的处理效果自动化执行的任何时候,任意的弹框都可能出现,在这个时候用例不能失败,需要将对应的弹框正确处理后继续执行原用例,原用例的执行过程不受影响。
2.2 处理思路与实操

2.2.1 循环判断

  1. 将需要处理的弹框元素加入到一个黑名单List中,遍历List,通过findElements方法得到的List大小来判断弹框元素是否存在,存在即点击处理

干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第4张图片
2. 将handleAlert()方法加到driver.findElement方法之前,使定位前先判断弹框的存在与否并进行处理
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第5张图片
上述方法初步解决了弹框问题,但是缺点也很明显。

缺点:每次定位元素前都需要处理弹框,影响执行效率,速度较慢 因此我们引入try catch来解决此问题

2.2.2 try catch 提升效率
我们利用try catch的异常捕获处理的机制,让元素仅在定位失败时才进入弹框处理handleAlert()方法,处理完毕后重新返回driver.findElement(by),对原case元素继续进行定位执行;这样就大大提升了处理效率,使处理更为精准。
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第6张图片
递归处理:一般情况下我们一次只会出现一个弹框,但是例外的是可能有一个以上的弹框同时出现,这样的话虽然处理了其中一个弹框,但是剩下的弹框依然会阻断用例的正常执行,这个时候就可以使用递归的方法,在处理完弹框后返回findElement方法自身,继续进行try catch,使之进入弹框处理逻辑
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第7张图片
注意:

使用递归方法后有一个问题,就是假如并不是因为某个弹框的出现而导致的定位失败,而这个时候通过try catch进入到弹框处理逻辑后,由于并未匹配到弹框元素,所以递归就会进入一个死循环,不断重复着弹框处理的逻辑,所以使用递归时我们也需要对其次数进行限制;一般两个弹框同时出现已经算多的了,所以建议可以将递归的次数限制到最多两次便退出。
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第8张图片
2.2.3 PageSource助力效率再提升
按照上面的方法,看似已经很好的解决了弹框的处理,但是可以注意到的是:

在检查弹框的时候依然使用的是appium的定位,在当前页面中根据元素的属性去一一查找定位
所有的黑名单中的弹框都会被定位查找一遍
而我们实际中最想要的也是最有效率的方法应该是:

只有在当前页面中存在的弹框才对其进行定位、操作、处理。为了达到我们想要的效果,就需要借助于PageSource了。
1)appium的driver提供了一个getPageSource方法,此方法可以在当前页面可以得到一个文本字符串,也可以理解为当前页面的xml,我们利用这种xml文本来进行判断,就比用appium一一定位的方式要快速和精准的多了

在这里插入图片描述

2)设置黑名单,黑名单要使用元素的xpath,用来和PageSource文本做匹配,判断此弹框是否存在当前页面
在这里插入图片描述
3)我们将黑名单中的 xpath作为弹框查找的标记符,另外再定义一个定位符,用来找到弹框后做定位处理使用;这里可以将标记符和定位符存入HashMap中
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第9张图片
4)遍历map,判断黑名单弹框元素是否存在于当前pageSource,存在即根据弹框处理方式进行点击或其他操作(如上述中的新功能提示弹框,点击弹框自身无法消除,需点击页面其余部分方可消除)处理
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第10张图片
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第11张图片
5)最后有一个小技巧,临时修改隐式等待时间,防止查找黑名单中元素过久,在弹框处理结束后再讲隐式等待时间复原;完整的方法实现如下:
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第12张图片
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第13张图片
6)最后将findElement方法中的handleAlert方法替换为handleAlertByPageSource方法即可干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第14张图片
3. 首页判断
再来解决首页加载时可能出现的坑。

App 启动加载时间较久(可能 App 本身加载慢,也可能是移动设备本身加载应用速度慢,也可能首页广告时间较长),导致定位超时,用例失败。对此我们又如下两步解决办法。

3.1 首页元素显示等待

如标题所述,对首页进入使用显示等待,利用搜索控件的出现来判断是否进入了首页,这样不影响其他元素隐式等待的时间,也解决了首页初始化加载时间过长的问题。

例如雪球仅在进入首页后会出现 id为user_profile_container的用户信息控件,那么我们就可以以此为依据来判断应用是否加载完成进入了首页。

干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第15张图片
在启动方法中加入显示等待上述首页控件 30 秒,到控件可被定位时确认进入首页。
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第16张图片
缺点:

但是这样有个情况不能解决:若加载完成后有弹框出现,可能就一直无法定位到首页元素,但是实际上已经加载完成,比如下图的首页广告弹框 。
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第17张图片
3.2 首页弹框判断

文章第二部分介绍了利用 PageSource 来判断弹框是否存在的方法,在这里依然适用,还是熟悉的味道,还是同样的套路,将弹框元素 xpath 也加入 PageSource 判断,这样无论首页控件和首页弹框哪一个被发现,就都可以判断应用已经加载完成,成功进入首页,剩下的就可以交给用例和其他处理逻辑了干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第18张图片
3.3 运行效果展示

好了,经过上面的分析之后,我们终于搞定了入门 APP 自动化测试时的老大难问题。搞定了弹框及首页启动时加载完成如何判断处理。
干货 | App 自动化测试痛点(弹框及首页启动加载完成判断处理)_第19张图片
(文章来源于霍格沃兹测试学院)

你可能感兴趣的:(软件测试,程序员)