单元测试和接口测试，测试结果一般比较明确，如果执行失败，要么是被测系统有bug，要么是测试用例本身需要修改维护。
唯独针对UI的自动化测试，当用例数目成百上千之后，你会发现，总是有些用例概率性的失败，你把运行失败的用例单独挑出来运行，又是成功的，查看报错信息，你发现大多是该加载出来的控件或者页面等没有加载出来，于是你想，是不是加一个sleep就好了，sleep 这个方法在UI自动化测试中被广泛应用。
但是，sleep也不是UI自动化测试中的银弹，每天仍然会有大量的失败，失败的原因可能有如下几点：
1、之前sleep 2s就OK了的，结果执行用例那天机器性能差了些，导致2s不够用
2、网络偶尔出现拥塞，导致sleep时间不够
3、测试框架偶尔出现问题，例如webdriver接口，特别是基于坐标的点击中，偶尔会出现失效
4、测试代码的兼容性问题，例如之前把手机向上滑动1000的长度，可以找到某一控件，但是换了一个型号的手机之后，原有的滑动定位方式失效。
除了上述问题以外，还有其他很多类型的问题，都是sleep的方式解决不了的。
那有没有什么好的方式，让UI自动化测试的结果尽可能的靠谱呢。这里，推荐两个思路：
1、针对概率性失败的问题，通过循环重试，最大超时时间的方式搞定。因为我们需要需要测试的是被测系统，中间层只是我们用来操作被测系统的，所以，我们得最大限度的容忍其失败，做好容错性。
2、针对基于坐标导致的兼容性问题，通过比例封装的方式搞定。因为控件在不同的手机上，其坐标会变，但其相对位置是不会变的，我们封装方法，基于相对位置定位。
实战举例：
一、概率性失败的问题
我们封装webdriver 下的find_element接口如下：
二、基于坐标导致的兼容性问题
我们基于向上滑动为例，每次固定的滑动半屏幕，n是滑动的次数，默认是1。基于如下的方式封装之后，不管换成什么型号的手机，就不用担心坐标不一致的问题了。
UI自动化测试，正是因为他存在很多坑，所以大规模推广应用的公司不是很多，还是推荐做强做好接口层的自动化测试。
UI层的自动化测试，封装好框架，做好容错性，也可以为产品质量做更高一层的保驾护航。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
