UI自动化测试—问题解决经验、方法
近期一直在做有关推送的UI自动化测试，在组内小伙伴的共同努力下，我们成功完成了新增推送的用例编写以及已有用例的优化。在这过程中，我享受到用例运行通过所带来的喜悦，也遇到用例fail所带来的难题，最重要的是学到了解决问题的方法，提高了解决问题的能力。所谓“授人以鱼不如授人以渔”，感谢小伙伴在此过程中给予的帮助。
接下来，我来总结一下遇到的问题和一些解决方法，方便自己总结、记录，也可以给有需要的小伙伴借鉴：
1、在安卓中不能直接用Name
熟悉UIautomator的童鞋都知道，用text来定位控件元素是很好用的，可以简单准确得校验某个控件，对应到appium中就是name。但是经过实验，name不能被直接应用，所以就找到了一个其他的方法，即：findElementByAndroidUIAutomator("text(\"" + text + "\")")，它是一个强有力的元素定位方式，它是通过Android UIAutomator类库去找元素。
得出解决问题的方法：当最简单直接的方法不可用时，要学会去借助一些搜索工具，去网上查一下什么情况，看大家有没有遇到类似的问题以及解决办法。通常来说，在我们使用某些工具遇到的日常问题，基本在网上查阅的过程中都能够得到一定程度上的解决。所以，我们要学会查阅，借鉴他人的经验，不能钻牛角尖，要懂得变通。
2、在iOS中检验name时，提示该找不到
在测试推送时，遇到打开推送都的页面是一个RN页面，想要校验值为“动态”的name是否存在。其实想象一下，应该很简单，只需利用我们之前写好的一个module：iosmodules.verifyNameExist(driver, " 动态");即可，但是报错，从获取的日志上来看，是因为在该页面没有获取到“动态”二字。这让我百思不解，最终基本确定可能因为该页面是RN页面，可能这个方法不可用，于是我们开始探寻其他的办法。
等到过了一段时间后，再查询运行过程日志的时候，突然有一个发现，这让我们豁然开朗，觉得前面怀疑的RN界面问题可能完全努力错方向。原来，想要验证的name值竟是“ 动态”（前面有一空格），问题迎刃而解。
得出的解决问题的方法：当用例运行失败时，首先要检查一下有没有明显的可以看出来的错误，改正后若还报错，就要寻找隐藏的根本原因了。
（1） 打印：
借助System.out，打印出我们想要得到的信息。因为用例运行是一气呵成的，中间很多步骤运行完成后输出给我们一个最终结果。所以，首先要将用例拆分为几个部分，比如：将有关键字输出作为拆分标准。将怀疑出错的的地方的输出信息打印出来，再运行，根据打印出来的东西就可以准确判断与我们的预期结果是否相符，再逐一排查。
（2） 查看appium运行的终端
当运行自动化的用例时，终端也会体现出运行的过程与进度状态，这里面往往有很多有用的信息，值得我们去查阅和排查问题，这里的日志是非常清晰的。可以清楚得看到运行到哪个阶段，以及界面中得内容，同时，若失败，也可以清楚得看到失败原因及步骤。
3、WebDriver可能干扰
这是一个很诡异的问题，连上iOS手机跑自动化测试的时候，对于iOS11的手机，在通知页面打开推送时需要右滑即可打开跳转到相应页面。但是在通知页面根本找不到发送的推送，这令人感觉很诧异，因为之前一直是可以的，代码什么都没有动就发生了这一幕，在排查原因后还是不得其解。再一看手机，很多类似于WebDriver的软件，于是果断卸载掉。再次运行，奇迹出现了，正常运行。
得出的解决问题的方法：当检查完成后依然没有发现导致错误的问题，不妨就试试这种方法。这种方法谈不上有多高的技术性，但有时就是很神奇。如：重启服务，关掉与此次测试无关的其他进程，卸载可能干扰的软件等。
4、获取iOS当前页面
还有一个需要注意的地方，正如在安卓中我们可以借助UIAutomator来获取当前页面的控件元素一样，iOS也有属于自己的工具。鉴于iOS-inspectors安装非常困难与繁琐，所以我们暂时使用一个其他工具，此工具使用需注意：
需现将此工具打开，再运行case，当运行到想要获取的页面时在工具打开的界面刷新获取。一定要在运行case之间将工具打开，否则会获取不到，有时也可以尝试关掉重新打开。当然了，若有时间可以安装iOS-inspectors，它将是一个非常好用的工具。
