Appium实际测试中处理界面元素的异常，心得分享

Appium是一款极其强大的移动端自动化测试工具，它不仅支持多种语言，并且可以使用同一套API在不同操作系统平台上进行测试脚本的编写，完美的兼容了android和ios；但是要真正掌握并熟练Appium并不是一个简单的事情，在实际工作中往往会遇到学习过程中无法想象的情况，这次就分享一下我的工作心得

最近一直忙于整理公司接口测试框架，Appium被我疏远了好一阵子，前两天领导说以后可能要开展app端的自动化测试，于是今天花了一个下午梳理了一遍，最痛苦的莫过于前期规范的设计，几乎都是从0开始，好了不扯闲话，下面主要说一下遇到的几个问题：

众所周知appium是依赖于selenium的移动端自动化测试框架，所以它里面的方法基本上和selenium是一样的，不同的是它模拟的是app端的驱动而selenium是web端浏览器的驱动；通过脚本来实现模拟事件操作，所以对手机界面元素的定位对于appium测试来说是最重要的一个环节；appium提供的主要定位方法有xpah，id，name，classname以及对应控件中content-desc属性的accessibility_id方法；这些方法都有两个，个返回一个webelement对象（就是你要模拟操作的界面元素），另外一个返回一个包含多个webelement对象的列表（适用于没有唯一值属性的元素，通过遍历获得要操作的元素）；android系统可以通过谷歌原生的uiautomatorviewer（配置好androidsdk环境后即可使用）进行定位，如图所示

ios系统使用mac版appium自带的工具定位即可。
那么我们实际工作中会遇到什么棘手的问题呢？模拟的事件操作都是发生在元素定位后，那如果这个元素不存在呢？这是个很常见的场景，需求的更改或者开发自己的变动都会导致这种情况出现，
如果我们写好的脚本无法实现持续通用的话自动化测意义就不大了，所以我们要在appium的源码之上封装一层自己的代码来实现这些异常处理，原理很简单--就是在每次获取界面元素时判断一下是否存在
如果存在返回一个可操作的对象，如果不存在则进行异常处理；我们运气不错，强大的appium给我们提供了解决这个问题的异常判断NoSuchElementException.
还有一个问题就是time，我们每次去定位元素时都是在界面加载完成后才开始的，如果你不想每次刷新，跳转或重新打开界面后都来一句time.sleep（）来设置等待时间（这样也确实影响脚本美观）的话；
那就一起在封装层实现吧，appium这时又体现出它的强大之处了，它提供了一个全局的隐式等待时间implicitly_wait(time)，设置后appium驱动对象的生命周期内去定位元素都会使用此处的时间来作为最大等待时长
那么下面就让我们看看解决这两个问题的代码，可能还会有没有考虑到的地方，随着工作经验的增涨慢慢补充即可
然后写一个简单的case调用这个封装好的AppElement进行元素定位，并查看appium的log输入

怎么样，非常清楚的指出了失败的原因以及哪个元素“失踪”了，这样就能更好的反馈给我们的RD同学进行问题排查
类似于这样的封装函数也可以叫做公共资源，它们不仅可以减轻以后编写case的压力，最重要的是可以实现自动化最大的价值---通用，高效；接口自动化测公共资源更加复杂，我将在
下一篇博客中分享出来，前期的框架和规范设计好了不仅对后来的人使用起来方便，对自己也是极大的有益
不管怎么说，写这个东西还是有用的，它可以让我在繁忙中总结和分析自己做过的工作，对一个QA来说复盘可是很重要的，要养成这种习惯