App自动化测试的常见痛点 —— 弹框处理

很多同学在项目中落地实践 App 自动化测试时，会发现编写的自动化脚本无缘无故地执行失败、不稳定。而导致其问题很大原因是因为应用的各种弹窗（升级弹窗、使用过程提示弹窗、评价弹窗等等），比如这样的：

弹 框 处 理

处理方向

弹框的影响范围

弹框对我们自动化的影响主要是用例执行的打断，而至于弹框中广告内容的跳转或评价信息填写等属于另外的测试，因此我们主要是要将弹框处理消失，使应用回到用例执行的 PO。

弹框的消失方式

观察弹框，我们会发现一般为了保证用户体验，弹框都会方便用户进行一键消除，例如上述中雪球的各种弹框，可能点击一个叉号，可能任意点击其他地方，或者评价框这种直接点击“下次再说”等。

弹框的处理效果

自动化执行的任何时候，任意的弹框都可能出现，在这个时候用例不能失败，需要将对应的弹框正确处理后继续执行原用例，原用例的执行过程不受影响。

处理思路与实操

1. 循环判断

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

B. 将handleAlert()方法加到driver.findElement方法之前，使定位前先判断弹框的存在与否并进行处理上述方法初步解决了弹框问题，但是缺点也很明显。

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

try catch 提升效率

利用try catch的异常捕获处理的机制，让元素仅在定位失败时才进入弹框处理handleAlert()方法，处理完毕后重新返回driver.findElement(by)，对原case元素继续进行定位执行；这样就大大提升了处理效率，使处理更为精准。

递归处理

一般情况下我们一次只会出现一个弹框，但是例外的是可能有一个以上的弹框同时出现，这样的话虽然处理了其中一个弹框，但是剩下的弹框依然会阻断用例的正常执行，这个时候就可以使用递归的方法，在处理完弹框后返回findElement方法自身，继续进行try catch，使之进入弹框处理逻辑。

注意： 

使用递归方法后有一个问题，就是假如并不是因为某个弹框的出现而导致的定位失败，而这个时候通过try catch进入到弹框处理逻辑后，由于并未匹配到弹框元素，所以递归就会进入一个死循环，不断重复着弹框处理的逻辑，所以使用递归时我们也需要对其次数进行限制；一般两个弹框同时出现已经算多的了，所以建议可以将递归的次数限制到最多两次便退出。

---

绵薄之力

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助....